Re: [Intel-gfx] [PATCH v14 03/32] drm/i915: MEI interface implementation

2019-02-15 Thread kbuild test robot
Hi Ramalingam,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190215]
[cannot apply to v5.0-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20190216-090245
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-l1-02160931 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/drm/i915_component.h:27:0,
from drivers/gpu/drm/i915/intel_hdcp.c:10:
>> include/drm/drm_audio_component.h:22:27: warning: 'struct device' declared 
>> inside parameter list
 void (*get_power)(struct device *);
  ^
>> include/drm/drm_audio_component.h:22:27: warning: its scope is only this 
>> definition or declaration, which is probably not what you want
   include/drm/drm_audio_component.h:28:27: warning: 'struct device' declared 
inside parameter list
 void (*put_power)(struct device *);
  ^
   include/drm/drm_audio_component.h:32:37: warning: 'struct device' declared 
inside parameter list
 void (*codec_wake_override)(struct device *, bool enable);
^
   include/drm/drm_audio_component.h:36:31: warning: 'struct device' declared 
inside parameter list
 int (*get_cdclk_freq)(struct device *);
  ^
   include/drm/drm_audio_component.h:43:32: warning: 'struct device' declared 
inside parameter list
 int (*sync_audio_rate)(struct device *, int port, int pipe, int rate);
   ^
   include/drm/drm_audio_component.h:57:10: warning: 'struct device' declared 
inside parameter list
 unsigned char *buf, int max_bytes);
 ^
   include/drm/drm_audio_component.h:90:48: warning: 'struct device' declared 
inside parameter list
 int (*master_bind)(struct device *dev, struct drm_audio_component *);
   ^
   include/drm/drm_audio_component.h:97:51: warning: 'struct device' declared 
inside parameter list
 void (*master_unbind)(struct device *dev, struct drm_audio_component *);
  ^
   In file included from drivers/gpu/drm/i915/intel_drv.h:34:0,
from drivers/gpu/drm/i915/intel_hdcp.c:15:
   drivers/gpu/drm/i915/i915_drv.h:58:41: fatal error: 
drm/i915_mei_hdcp_interface.h: No such file or directory
   compilation terminated.
--
   In file included from include/drm/i915_component.h:27:0,
from drivers/gpu//drm/i915/intel_hdcp.c:10:
>> include/drm/drm_audio_component.h:22:27: warning: 'struct device' declared 
>> inside parameter list
 void (*get_power)(struct device *);
  ^
>> include/drm/drm_audio_component.h:22:27: warning: its scope is only this 
>> definition or declaration, which is probably not what you want
   include/drm/drm_audio_component.h:28:27: warning: 'struct device' declared 
inside parameter list
 void (*put_power)(struct device *);
  ^
   include/drm/drm_audio_component.h:32:37: warning: 'struct device' declared 
inside parameter list
 void (*codec_wake_override)(struct device *, bool enable);
^
   include/drm/drm_audio_component.h:36:31: warning: 'struct device' declared 
inside parameter list
 int (*get_cdclk_freq)(struct device *);
  ^
   include/drm/drm_audio_component.h:43:32: warning: 'struct device' declared 
inside parameter list
 int (*sync_audio_rate)(struct device *, int port, int pipe, int rate);
   ^
   include/drm/drm_audio_component.h:57:10: warning: 'struct device' declared 
inside parameter list
 unsigned char *buf, int max_bytes);
 ^
   include/drm/drm_audio_component.h:90:48: warning: 'struct device' declared 
inside parameter list
 int (*master_bind)(struct device *dev, struct drm_audio_component *);
   ^
   include/drm/drm_audio_component.h:97:51: warning: 'struct device' declared 
inside parameter list
 void (*master_unbind)(struct device *dev, struct drm_audio_component *);
  ^
   In file included from drivers/gpu//drm/i915/intel_drv.h:34:0,
from drivers/gpu//drm/i915/intel_hdcp.c:15:
   drivers/gpu//drm/i915/i915_drv.h:58:41: fatal error: 
drm/i915_mei_hdcp_interface.h: No such file or directory
   compilation 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reduce the RPS shock

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Reduce the RPS shock
URL   : https://patchwork.freedesktop.org/series/56740/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5611_full -> Patchwork_12228_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_color@pipe-b-ctm-negative:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624]

  * igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_cursor_crc@cursor-128x42-random:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl:  PASS -> FAIL [fdo#103232] +1

  * igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
- shard-apl:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +2

  * igt@kms_hdmi_inject@inject-audio:
- shard-iclb: NOTRUN -> FAIL [fdo#102370]

  * igt@kms_plane@pixel-format-pipe-a-planes:
- shard-iclb: NOTRUN -> FAIL [fdo#103166]

  * igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-iclb: PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk:  PASS -> FAIL [fdo#103166] +3

  * igt@kms_psr@no_drrs:
- shard-iclb: PASS -> FAIL [fdo#108341]

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  PASS -> FAIL [fdo#109016]

  * igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-iclb: PASS -> FAIL [fdo#109016]

  * igt@kms_setmode@basic:
- shard-kbl:  PASS -> FAIL [fdo#99912]

  * igt@kms_vblank@pipe-c-ts-continuation-modeset:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@pm_rpm@fences:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +2

  
 Possible fixes 

  * igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl:  FAIL [fdo#103191] / [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl:  FAIL [fdo#103232] -> PASS +2

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk:  FAIL [fdo#102887] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl:  FAIL [fdo#103167] -> PASS
- shard-glk:  FAIL [fdo#103167] -> PASS

  * igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk:  FAIL [fdo#103166] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl:  FAIL [fdo#103166] -> PASS +1

  * igt@kms_vblank@pipe-b-ts-continuation-modeset-rpm:
- shard-apl:  FAIL [fdo#104894] -> PASS +4

  * igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-hsw:  FAIL [fdo#104894] -> PASS

  * igt@pm_rpm@drm-resources-equal:
- shard-iclb: INCOMPLETE [fdo#108840] -> PASS

  * igt@pm_rpm@gem-pread:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +3

  
 Warnings 

  * igt@i915_suspend@shrink:
- shard-glk:  INCOMPLETE [fdo#103359] / [fdo#106886] / 
[k.org#198133] -> DMESG-WARN [fdo#109244]

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-iclb: INCOMPLETE [fdo#107713] -> FAIL [fdo#103232]

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

  [fdo#102370]: https://bugs.freedesktop.org/show_bug.cgi?id=102370
  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
  [fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894
  [fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
  [fdo#108840]: 

Re: [Intel-gfx] [PATCH v14 20/32] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

2019-02-15 Thread kbuild test robot
Hi Ramalingam,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.0-rc4 next-20190215]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20190216-090245
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-defconfig (attached as .config)
compiler: gcc-8 (Debian 8.2.0-20) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/misc/mei/hdcp/mei_hdcp.c:28:10: fatal error: 
>> drm/i915_mei_hdcp_interface.h: No such file or directory
#include 
 ^~~
   compilation terminated.
--
   In file included from drivers/gpu/drm/i915/i915_drv.c:50:
>> drivers/gpu/drm/i915/i915_drv.h:58:10: fatal error: 
>> drm/i915_mei_hdcp_interface.h: No such file or directory
#include 
 ^~~
   compilation terminated.
--
   In file included from include/drm/i915_component.h:27,
from drivers/gpu/drm/i915/intel_hdcp.c:10:
   include/drm/drm_audio_component.h:22:27: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*get_power)(struct device *);
  ^~
   include/drm/drm_audio_component.h:28:27: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*put_power)(struct device *);
  ^~
   include/drm/drm_audio_component.h:32:37: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*codec_wake_override)(struct device *, bool enable);
^~
   include/drm/drm_audio_component.h:36:31: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*get_cdclk_freq)(struct device *);
  ^~
   include/drm/drm_audio_component.h:43:32: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*sync_audio_rate)(struct device *, int port, int pipe, int rate);
   ^~
   include/drm/drm_audio_component.h:56:24: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*get_eld)(struct device *, int port, int pipe, bool *enabled,
   ^~
   include/drm/drm_audio_component.h:90:28: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*master_bind)(struct device *dev, struct drm_audio_component *);
   ^~
   include/drm/drm_audio_component.h:97:31: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*master_unbind)(struct device *dev, struct drm_audio_component *);
  ^~
   In file included from drivers/gpu/drm/i915/intel_drv.h:34,
from drivers/gpu/drm/i915/intel_hdcp.c:15:
>> drivers/gpu/drm/i915/i915_drv.h:58:10: fatal error: 
>> drm/i915_mei_hdcp_interface.h: No such file or directory
#include 
 ^~~
   compilation terminated.

vim +28 drivers/misc/mei/hdcp/mei_hdcp.c

  > 28  #include 
29  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
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/fbdev: Actually configure untiled displays

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915/fbdev: Actually configure untiled displays
URL   : https://patchwork.freedesktop.org/series/56728/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5611_full -> Patchwork_12227_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
- shard-apl:  PASS -> FAIL

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-glk:  PASS -> FAIL [fdo#108145]
- shard-iclb: NOTRUN -> FAIL [fdo#107725]

  * igt@kms_color@pipe-b-ctm-negative:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#109624]

  * igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-apl:  PASS -> FAIL [fdo#103232]

  * igt@kms_cursor_crc@cursor-128x42-random:
- shard-iclb: NOTRUN -> FAIL [fdo#103232]

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-hsw:  PASS -> FAIL [fdo#103355]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-kbl:  PASS -> FAIL [fdo#102887] / [fdo#105363]

  * igt@kms_hdmi_inject@inject-audio:
- shard-iclb: NOTRUN -> FAIL [fdo#102370]

  * igt@kms_plane@pixel-format-pipe-a-planes:
- shard-iclb: NOTRUN -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl:  PASS -> FAIL [fdo#103166] +3

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166] +1

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665] +1

  * igt@kms_setmode@basic:
- shard-apl:  PASS -> FAIL [fdo#99912]
- shard-kbl:  PASS -> FAIL [fdo#99912]

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-snb:  PASS -> FAIL [fdo#103375]

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-rpm:
- shard-apl:  PASS -> FAIL [fdo#104894] +2

  * igt@pm_rpm@legacy-planes:
- shard-iclb: PASS -> DMESG-WARN [fdo#108654]

  * igt@pm_rpm@modeset-lpsp-stress-no-wait:
- shard-iclb: PASS -> INCOMPLETE [fdo#107713]

  * igt@pm_rpm@modeset-stress-extra-wait:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107724]

  * igt@pm_rpm@system-suspend:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1

  
 Possible fixes 

  * igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl:  FAIL [fdo#103191] / [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-apl:  FAIL [fdo#103232] -> PASS +2

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-iclb: FAIL [fdo#103833] / [fdo#105681] -> PASS

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk:  FAIL [fdo#102887] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk:  FAIL [fdo#103167] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-tilingchange:
- shard-iclb: FAIL [fdo#103167] -> PASS

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-iclb: INCOMPLETE [fdo#107713] -> PASS

  * igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk:  FAIL [fdo#103166] -> PASS

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-apl:  FAIL [fdo#108145] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl:  FAIL [fdo#103166] -> PASS

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-iclb: FAIL [fdo#103166] -> PASS

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  DMESG-FAIL [fdo#105763] -> PASS

  * igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl:  FAIL [fdo#109016] -> PASS

  * igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-hsw:  FAIL [fdo#104894] -> PASS

  * igt@kms_vblank@pipe-c-ts-continuation-modeset-hang:
- shard-apl:  FAIL [fdo#104894] -> PASS +3

  * igt@pm_rpm@drm-resources-equal:
- shard-iclb: INCOMPLETE [fdo#108840] -> PASS

  * igt@pm_rpm@gem-pread:
- shard-iclb: 

Re: [Intel-gfx] [PATCH v14 03/32] drm/i915: MEI interface implementation

2019-02-15 Thread kbuild test robot
Hi Ramalingam,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190215]
[cannot apply to v5.0-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20190216-090245
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x007-201906 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-20) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/drm/i915_component.h:27,
from drivers/gpu/drm/i915/intel_hdcp.c:10:
>> include/drm/drm_audio_component.h:22:27: warning: 'struct device' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
 void (*get_power)(struct device *);
  ^~
   include/drm/drm_audio_component.h:28:27: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*put_power)(struct device *);
  ^~
   include/drm/drm_audio_component.h:32:37: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*codec_wake_override)(struct device *, bool enable);
^~
   include/drm/drm_audio_component.h:36:31: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*get_cdclk_freq)(struct device *);
  ^~
   include/drm/drm_audio_component.h:43:32: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*sync_audio_rate)(struct device *, int port, int pipe, int rate);
   ^~
   include/drm/drm_audio_component.h:56:24: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*get_eld)(struct device *, int port, int pipe, bool *enabled,
   ^~
   include/drm/drm_audio_component.h:90:28: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*master_bind)(struct device *dev, struct drm_audio_component *);
   ^~
   include/drm/drm_audio_component.h:97:31: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*master_unbind)(struct device *dev, struct drm_audio_component *);
  ^~
   In file included from drivers/gpu/drm/i915/intel_drv.h:34,
from drivers/gpu/drm/i915/intel_hdcp.c:15:
   drivers/gpu/drm/i915/i915_drv.h:58:10: fatal error: 
drm/i915_mei_hdcp_interface.h: No such file or directory
#include 
 ^~~
   compilation terminated.
--
   In file included from include/drm/i915_component.h:27,
from drivers/gpu//drm/i915/intel_hdcp.c:10:
>> include/drm/drm_audio_component.h:22:27: warning: 'struct device' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
 void (*get_power)(struct device *);
  ^~
   include/drm/drm_audio_component.h:28:27: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*put_power)(struct device *);
  ^~
   include/drm/drm_audio_component.h:32:37: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 void (*codec_wake_override)(struct device *, bool enable);
^~
   include/drm/drm_audio_component.h:36:31: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*get_cdclk_freq)(struct device *);
  ^~
   include/drm/drm_audio_component.h:43:32: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*sync_audio_rate)(struct device *, int port, int pipe, int rate);
   ^~
   include/drm/drm_audio_component.h:56:24: warning: 'struct device' declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int (*get_eld)(struct device *, int port, int pipe, bool *enabled,
   ^

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Calling guc_disable_communication in all suspend paths

2019-02-15 Thread Daniele Ceraolo Spurio



On 2/14/19 1:45 PM, Sujaritha Sundaresan wrote:

This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occured due to suspend late not being called in the hibernate devices
path.



And we shouldn't anyway talk to guc after telling it to prepare for suspend.

Reviewed-by: Daniele Ceraolo Spurio 

Daniele


Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Signed-off-by: Sujaritha Sundaresan 
---
  drivers/gpu/drm/i915/i915_reset.c |  2 +-
  drivers/gpu/drm/i915/intel_uc.c   | 23 +++
  drivers/gpu/drm/i915/intel_uc.h   |  1 +
  3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 12e74decd7a2..36e5c9c64285 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -673,7 +673,7 @@ static void reset_prepare(struct drm_i915_private *i915)
for_each_engine(engine, i915, id)
reset_prepare_engine(engine);
  
-	intel_uc_sanitize(i915);

+   intel_uc_reset_prepare(i915);
revoke_mmaps(i915);
  }
  
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c

index e711eb3268bc..2d360d53757f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -332,8 +332,6 @@ void intel_uc_sanitize(struct drm_i915_private *i915)
  
  	GEM_BUG_ON(!HAS_GUC(i915));
  
-	guc_disable_communication(guc);

-
intel_huc_sanitize(huc);
intel_guc_sanitize(guc);
  
@@ -451,6 +449,23 @@ void intel_uc_fini_hw(struct drm_i915_private *i915)

guc_disable_communication(guc);
  }
  
+/**

+ * intel_uc_reset_prepare - Prepare for reset
+ * @i915: device private
+ *
+ * Preparing for full gpu reset.
+ */
+void intel_uc_reset_prepare(struct drm_i915_private *i915)
+{
+   struct intel_guc *guc = >guc;
+
+   if (!USES_GUC(i915))
+   return;
+
+   guc_disable_communication(guc);
+   intel_uc_sanitize(i915);
+}
+
  int intel_uc_suspend(struct drm_i915_private *i915)
  {
struct intel_guc *guc = >guc;
@@ -468,7 +483,7 @@ int intel_uc_suspend(struct drm_i915_private *i915)
return err;
}
  
-	gen9_disable_guc_interrupts(i915);

+   guc_disable_communication(guc);
  
  	return 0;

  }
@@ -484,7 +499,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
  
-	gen9_enable_guc_interrupts(i915);

+   guc_enable_communication(guc);
  
  	err = intel_guc_resume(guc);

if (err) {
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 870faf9011b9..c14729786652 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -38,6 +38,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv);
  void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
  int intel_uc_init(struct drm_i915_private *dev_priv);
  void intel_uc_fini(struct drm_i915_private *dev_priv);
+void intel_uc_reset_prepare(struct drm_i915_private *i915);
  int intel_uc_suspend(struct drm_i915_private *dev_priv);
  int intel_uc_resume(struct drm_i915_private *dev_priv);
  


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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Remove preemption support for current fw

2019-02-15 Thread Daniele Ceraolo Spurio



On 2/15/19 2:48 PM, Chris Wilson wrote:

Preemption via GuC submission quickly degrades into confused firmware
and misordered requests. It is not being supported with no intention of
being fixed in its current incarnation, so remove the unstable code. By
removing the workqueue from the GuC submission path, we can now do
direct engine-resets and direct submission from atomic context.



Nothing against ripping out the current code, but the new code will 
still require an H2G, so the workqueue is most likely going to come 
back. I guess it's still fine to remove it now as long as we don't build 
on the fact that it isn't there for now.


Tomasz is looking at the new logic so he's probably the best person to 
comment/ack this.


Daniele


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108622
Signed-off-by: Chris Wilson 
Cc: Jon Ewins 
---
  drivers/gpu/drm/i915/i915_debugfs.c   |   5 -
  drivers/gpu/drm/i915/intel_guc.c  |  31 ---
  drivers/gpu/drm/i915/intel_guc.h  |   9 -
  drivers/gpu/drm/i915/intel_guc_submission.c   | 203 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |   2 -
  drivers/gpu/drm/i915/selftests/intel_guc.c|  17 +-
  .../gpu/drm/i915/selftests/intel_hangcheck.c  |   3 -
  7 files changed, 5 insertions(+), 265 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..636e28367980 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2233,11 +2233,6 @@ static int i915_guc_info(struct seq_file *m, void *data)
  
  	seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);

i915_guc_client_info(m, dev_priv, guc->execbuf_client);
-   if (guc->preempt_client) {
-   seq_printf(m, "\nGuC preempt client @ %p:\n",
-  guc->preempt_client);
-   i915_guc_client_info(m, dev_priv, guc->preempt_client);
-   }
  
  	/* Add more as required ... */
  
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c

index 8660af3fd755..8fa2de84d82e 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -76,8 +76,6 @@ void intel_guc_init_early(struct intel_guc *guc)
  
  static int guc_init_wq(struct intel_guc *guc)

  {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
/*
 * GuC log buffer flush work item has to do register access to
 * send the ack to GuC and this work item, if not synced before
@@ -97,31 +95,6 @@ static int guc_init_wq(struct intel_guc *guc)
return -ENOMEM;
}
  
-	/*

-* Even though both sending GuC action, and adding a new workitem to
-* GuC workqueue are serialized (each with its own locking), since
-* we're using mutliple engines, it's possible that we're going to
-* issue a preempt request with two (or more - each for different
-* engine) workitems in GuC queue. In this situation, GuC may submit
-* all of them, which will make us very confused.
-* Our preemption contexts may even already be complete - before we
-* even had the chance to sent the preempt action to GuC!. Rather
-* than introducing yet another lock, we can just use ordered workqueue
-* to make sure we're always sending a single preemption request with a
-* single workitem.
-*/
-   if (HAS_LOGICAL_RING_PREEMPTION(dev_priv) &&
-   USES_GUC_SUBMISSION(dev_priv)) {
-   guc->preempt_wq = alloc_ordered_workqueue("i915-guc_preempt",
- WQ_HIGHPRI);
-   if (!guc->preempt_wq) {
-   destroy_workqueue(guc->log.relay.flush_wq);
-   DRM_ERROR("Couldn't allocate workqueue for GuC "
- "preemption\n");
-   return -ENOMEM;
-   }
-   }
-
return 0;
  }
  
@@ -129,10 +102,6 @@ static void guc_fini_wq(struct intel_guc *guc)

  {
struct workqueue_struct *wq;
  
-	wq = fetch_and_zero(>preempt_wq);

-   if (wq)
-   destroy_workqueue(wq);
-
wq = fetch_and_zero(>log.relay.flush_wq);
if (wq)
destroy_workqueue(wq);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 744220296653..b8c4615715c0 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -34,11 +34,6 @@
  #include "intel_uc_fw.h"
  #include "i915_vma.h"
  
-struct guc_preempt_work {

-   struct work_struct work;
-   struct intel_engine_cs *engine;
-};
-
  /*
   * Top level structure of GuC. It handles firmware loading and manages client
   * pool and doorbells. intel_guc owns a intel_guc_client to replace the legacy
@@ -65,10 +60,6 @@ struct intel_guc {
void *shared_data_vaddr;
  
  	struct intel_guc_client 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Restore interrupt enabling after a reset (rev3)

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Restore interrupt enabling after a reset (rev3)
URL   : https://patchwork.freedesktop.org/series/56761/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12234


Summary
---

  **FAILURE**

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56761/revisions/3/mbox/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_force_connector_basic@force-connector-state:
- fi-elk-e7500:   PASS -> FAIL

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-ilk-650: PASS -> DMESG-WARN
- fi-ivb-3770:PASS -> DMESG-FAIL
- fi-hsw-4770:PASS -> DMESG-FAIL
- fi-ivb-3520m:   PASS -> DMESG-FAIL
- fi-snb-2520m:   PASS -> DMESG-WARN
- fi-snb-2600:PASS -> DMESG-WARN
- fi-byt-j1900:   PASS -> DMESG-WARN
- fi-elk-e7500:   PASS -> DMESG-WARN
- fi-hsw-4770r:   PASS -> DMESG-FAIL

  
 Suppressed 

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

  * {igt@runner@aborted}:
- fi-ilk-650: NOTRUN -> FAIL
- fi-snb-2520m:   NOTRUN -> FAIL
- fi-hsw-4770:NOTRUN -> FAIL
- fi-ivb-3770:NOTRUN -> FAIL
- fi-byt-j1900:   NOTRUN -> FAIL
- fi-hsw-4770r:   NOTRUN -> FAIL
- fi-ivb-3520m:   NOTRUN -> FAIL
- fi-elk-e7500:   NOTRUN -> FAIL

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  
 Possible fixes 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   {SKIP} [fdo#109271] -> PASS +33

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107469]: https://bugs.freedesktop.org/show_bug.cgi?id=107469
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380


Participating hosts (45 -> 43)
--

  Additional (1): fi-glk-j4005 
  Missing(3): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 


Build changes
-

* Linux: CI_DRM_5612 -> Patchwork_12234

  CI_DRM_5612: 6067ec567b3eda30cecc8e03b65c4783f8708a8c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4832: 324ab48e67065f0cf67525b3ab9c44fd3dcaef0a @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12234: 2d962bea39825329116cc8918a7496633315607b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2d962bea3982 drm/i915: Restore interrupt enabling after a reset

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12234/
___
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/icl: Fix checks for userspace ctm + ycbcr output

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915/icl: Fix checks for userspace ctm + ycbcr output
URL   : https://patchwork.freedesktop.org/series/56770/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12233


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56770/revisions/1/mbox/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]

  * igt@pm_rpm@basic-rte:
- fi-bsw-kefka:   PASS -> FAIL [fdo#108800]

  
 Possible fixes 

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

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

  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271


Participating hosts (45 -> 41)
--

  Additional (1): fi-glk-j4005 
  Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4770 fi-icl-y 


Build changes
-

* Linux: CI_DRM_5612 -> Patchwork_12233

  CI_DRM_5612: 6067ec567b3eda30cecc8e03b65c4783f8708a8c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4832: 324ab48e67065f0cf67525b3ab9c44fd3dcaef0a @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12233: b8e1a8bf7f52e1d4dbbaded78db7acf193646769 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b8e1a8bf7f52 drm/i915/icl: Fix checks for userspace ctm + ycbcr output

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12233/
___
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/guc: Remove preemption support for current fw

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Remove preemption support for current fw
URL   : https://patchwork.freedesktop.org/series/56767/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12232


Summary
---

  **WARNING**

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56767/revisions/1/mbox/

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> DMESG-FAIL

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   PASS -> FAIL [fdo#109485]

  * igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  
 Possible fixes 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   {SKIP} [fdo#109271] -> PASS +33

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485


Participating hosts (45 -> 42)
--

  Additional (1): fi-glk-j4005 
  Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-pnv-d510 


Build changes
-

* Linux: CI_DRM_5612 -> Patchwork_12232

  CI_DRM_5612: 6067ec567b3eda30cecc8e03b65c4783f8708a8c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4832: 324ab48e67065f0cf67525b3ab9c44fd3dcaef0a @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12232: 32015ac2a55d014a62d9fd415bd1d3799ed4e548 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

32015ac2a55d drm/i915/guc: Remove preemption support for current fw

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Disable PSR2 while getting pipe CRC

2019-02-15 Thread Souza, Jose
On Fri, 2019-02-15 at 00:17 +, Souza, Jose wrote:
> On Thu, 2019-02-14 at 16:10 -0800, Pandiyan, Dhinakaran wrote:
> > On Thu, 2019-02-14 at 15:19 -0800, Souza, Jose wrote:
> > > On Thu, 2019-02-14 at 11:00 -0800, Dhinakaran Pandiyan wrote:
> > > > On Wed, 2019-02-13 at 18:02 -0800, José Roberto de Souza wrote:
> > > > > As stated in CRC_CTL spec, after PSR entry state CRC will not
> > > > > be
> > > > > calculated anymore what is not a problem as IGT tests do some
> > > > > screen
> > > > > change and then request the pipe CRC right after the change
> > > > > so
> > > > > PSR
> > > > > will go to idle state and only will entry again after at
> > > > > least
> > > > > 6
> > > > > idles frames.
> > > > > 
> > > > > But for PSR2 it is more problematic as any change to the
> > > > > screen
> > > > > could
> > > > > trigger a selective/partial update causing the CRC value not
> > > > > to
> > > > > be
> > > > > calculated over the full frame.
> > > > 
> > > > Okay, that reasoning runs counter to my understanding. My
> > > > understanding
> > > > is that the whole frame is fetched and processed at the pipe
> > > > level
> > > > but
> > > > the DDI sends selective blocks of pixels. So, if the CRC's are
> > > > calculated at the pipe level, the CRC should be for the full
> > > > frame
> > > > with
> > > > PSR2 having no effect? Checking bspec, I see there are DDI CRCs
> > > > as
> > > > well, which should reflect the partial frame that PSR2 sends.
> > > > 
> > > > To get a better understanding, I'd like to know what the source
> > > > for
> > > > mismatching CRCs is?
> > > 
> > > Well the naming is misleading for newer gens, before BDW this was
> > > a
> > > pipe register(8067) but now it is a DDI register(7536) but the
> > > register
> > > offset was kept the same.
> > Do we even read this register DDI_CRC_CTL? Don't see it defined in
> > i915_reg.h or referenced in intel_pipe_crc.c.
> 
> We do: PIPE_CRC_CTL().
> #define _PIPE_CRC_CTL_A   0x60050

I was wrong, the first CRC generated is wrong but it is not read by
userspace as we skip it using pipe_crc->skipped it is docummented in
the code too.

The problem here is that after PSR2 is activated(after 'Frames Before
SU Entry') there is no more CRC interruptions so no calls to
drm_crtc_add_crc_entry(), what don't happen with PSR1 even setting a
'Idle Frames' to 1.

Other odd thing that I discovered it that we have CRC_CTL register in
DDI(Bspec 7536) and other in PIPE(Bspec 7646) with diferent bits and we
write in the transcoder offset using the pipe bits. I tried to use the
PIPE offset but it do not generate any interruption, anyone know more
about that?

> 
> > > In my testing hardware generate 4 interruptions with wrong CRC
> > > values
> > > then stops forever probably because vblank interruptions are off.
> > Yeah, my guess is that power management is affecting the CRC
> > generation
> > rather than pipe CRC's being calculated only on the SU update
> > blocks.
> > 
> > 
> > > > > So here it disables PSR2 and keep it disabled while user is
> > > > > requesting pipe CRC.
> > > > > 
> > > > > BSpec: 7536
> > > > > 
> > > > > Cc: Dhinakaran Pandiyan 
> > > > > Cc: Ville Syrjälä 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > > > >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> > > > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 10 ++
> > > > >  drivers/gpu/drm/i915/intel_psr.c  | 23
> > > > > +++
> > > > >  4 files changed, 35 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index 17fe942eaafa..609e9c5bd453 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -520,6 +520,7 @@ struct i915_psr {
> > > > >   bool sink_not_reliable;
> > > > >   bool irq_aux_error;
> > > > >   u16 su_x_granularity;
> > > > > + bool pipe_crc_enabled;
> > > > >  };
> > > > >  
> > > > >  enum intel_pch {
> > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > index 3398b28c053b..40ce7a600585 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > @@ -2103,6 +2103,7 @@ void intel_psr_short_pulse(struct
> > > > > intel_dp
> > > > > *intel_dp);
> > > > >  int intel_psr_wait_for_idle(const struct intel_crtc_state
> > > > > *new_crtc_state,
> > > > >   u32 *out_value);
> > > > >  bool intel_psr_enabled(struct intel_dp *intel_dp);
> > > > > +void intel_psr_crc_prepare_or_finish(struct drm_i915_private
> > > > > *dev_priv, enum pipe pipe, bool prepare);
> > > > >  
> > > > >  /* intel_quirks.c */
> > > > >  void intel_init_quirks(struct drm_i915_private *dev_priv);
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Restore interrupt enabling after a reset (rev2)

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Restore interrupt enabling after a reset (rev2)
URL   : https://patchwork.freedesktop.org/series/56761/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5612 -> Patchwork_12231


Summary
---

  **FAILURE**

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56761/revisions/2/mbox/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_hangman@error-state-basic:
- fi-bwr-2160:PASS -> INCOMPLETE
- fi-hsw-4770r:   PASS -> DMESG-WARN
- fi-ivb-3770:PASS -> DMESG-WARN
- fi-hsw-4770:PASS -> DMESG-WARN
- fi-snb-2520m:   PASS -> DMESG-WARN
- fi-pnv-d510:PASS -> INCOMPLETE
- fi-ilk-650: PASS -> DMESG-WARN
- fi-snb-2600:PASS -> DMESG-WARN
- fi-ivb-3520m:   PASS -> DMESG-WARN

  * igt@i915_selftest@live_workarounds:
- fi-bsw-n3050:   PASS -> INCOMPLETE
- fi-skl-6700hq:  PASS -> DMESG-WARN
- fi-bsw-kefka:   PASS -> INCOMPLETE
- fi-kbl-7500u:   PASS -> DMESG-WARN
- fi-cfl-8109u:   PASS -> DMESG-WARN
- fi-skl-6600u:   PASS -> DMESG-WARN
- fi-kbl-7560u:   PASS -> DMESG-WARN
- fi-bdw-5557u:   PASS -> DMESG-WARN
- fi-kbl-7567u:   PASS -> DMESG-WARN
- fi-skl-6700k2:  PASS -> DMESG-WARN
- fi-skl-iommu:   PASS -> DMESG-WARN
- fi-skl-6770hq:  PASS -> DMESG-WARN
- fi-kbl-x1275:   PASS -> DMESG-WARN
- fi-skl-6260u:   PASS -> DMESG-WARN
- fi-kbl-r:   PASS -> DMESG-WARN
- fi-skl-gvtdvm:  PASS -> DMESG-WARN
- fi-bdw-gvtdvm:  PASS -> DMESG-WARN
- fi-cfl-8700k:   PASS -> DMESG-WARN

  
 Suppressed 

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

  * igt@i915_selftest@live_workarounds:
- {fi-icl-y}: PASS -> DMESG-WARN
- {fi-whl-u}: PASS -> DMESG-WARN
- {fi-icl-u3}:PASS -> DMESG-WARN
- {fi-icl-u2}:PASS -> DMESG-WARN

  * {igt@runner@aborted}:
- fi-ilk-650: NOTRUN -> FAIL
- fi-bdw-gvtdvm:  NOTRUN -> FAIL
- fi-cfl-8109u:   NOTRUN -> FAIL
- {fi-icl-u2}:NOTRUN -> FAIL
- fi-snb-2520m:   NOTRUN -> FAIL
- fi-hsw-4770:NOTRUN -> FAIL
- fi-kbl-7500u:   NOTRUN -> FAIL
- {fi-whl-u}: NOTRUN -> FAIL
- {fi-icl-u3}:NOTRUN -> FAIL
- fi-ivb-3770:NOTRUN -> FAIL
- fi-kbl-7560u:   NOTRUN -> FAIL
- {fi-icl-y}: NOTRUN -> FAIL
- fi-kbl-7567u:   NOTRUN -> FAIL
- fi-kbl-x1275:   NOTRUN -> FAIL
- fi-cfl-8700k:   NOTRUN -> FAIL
- fi-hsw-4770r:   NOTRUN -> FAIL
- fi-kbl-r:   NOTRUN -> FAIL
- fi-bdw-5557u:   NOTRUN -> FAIL
- fi-ivb-3520m:   NOTRUN -> FAIL
- fi-snb-2600:NOTRUN -> FAIL

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   PASS -> DMESG-WARN [fdo#108965]

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@i915_hangman@error-state-basic:
- fi-byt-n2820:   PASS -> INCOMPLETE [fdo#102657]
- fi-byt-clapper: PASS -> INCOMPLETE [fdo#102657]
- fi-byt-j1900:   PASS -> INCOMPLETE [fdo#102657]
- fi-elk-e7500:   PASS -> INCOMPLETE [fdo#103989]

  * igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq:  PASS -> DMESG-WARN [fdo#105998]

  
 Possible fixes 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u:   WARN [fdo#109380] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u:   {SKIP} [fdo#109271] -> PASS +33

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

  [fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657
  [fdo#103989]: https://bugs.freedesktop.org/show_bug.cgi?id=103989
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Remove preemption support for current fw

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Remove preemption support for current fw
URL   : https://patchwork.freedesktop.org/series/56767/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/guc: Remove preemption support for current fw
-drivers/gpu/drm/i915/intel_ringbuffer.h:609:23: warning: expression using 
sizeof(void)

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

[Intel-gfx] [PATCH v3] drm/i915: Restore interrupt enabling after a reset

2019-02-15 Thread Chris Wilson
At least on i965g and i965gm, performing a device reset clobbers the IER
resulting in loss of interrupts thereafter. So, run the irq_postinstall
hook to restore them.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reset.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 5a067a4b3d5d..c5bb4a67a81b 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -994,10 +994,12 @@ void i915_reset(struct drm_i915_private *i915,
goto error;
}
 
+   intel_irq_uninstall(i915);
if (do_reset(i915, stalled_mask)) {
dev_err(i915->drm.dev, "Failed to reset chip\n");
goto taint;
}
+   intel_irq_install(i915);
 
intel_overlay_reset(i915);
 
-- 
2.20.1

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

[Intel-gfx] [PATCH] drm/i915/icl: Fix checks for userspace ctm + ycbcr output

2019-02-15 Thread Matt Roper
We recently added support for gen11's new "output csc" which can be used
independently of the regular pipe CSC.  The idea is that this new output
csc allows us to use a userspace-provided color transformation matrix at
the same time we drive a YCBCR display mode requiring RGB->YUV
conversion.  However when landing that support we only updated the color
management code and overlooked that there was an additional atomic check
in the modeset path (in intel_crtc_compute_config()) that still assumes
we only have a single CSC unit to work with.  Let's update that check to
only apply to pre-gen11 platforms and move it into the color management
code to ensure it gets called on all commits, not just modesets.

Also, if we're *only* using the output CSC and not the pipe CSC, there's
no need to set crtc_state->csc_enable, so let's also not consider the
output format when setting csc_enable on gen11+ platforms.

Fixes: a91de580541c ("drm/i915/icl: Enable pipe output csc")
Cc: Uma Shankar 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
It might also be worth moving the full->limited range RGB conversion
from the pipe CSC to the output CSC on gen11 at some point.

 drivers/gpu/drm/i915/intel_color.c   | 16 +---
 drivers/gpu/drm/i915/intel_display.c | 12 
 2 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index da7a07d5ccea..b47e6d1aaaec 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -780,9 +780,10 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
limited_color_range = crtc_state->limited_color_range;
 
-   crtc_state->csc_enable =
-   crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB ||
-   crtc_state->base.ctm || limited_color_range;
+   crtc_state->csc_enable = crtc_state->base.ctm || limited_color_range;
+   if (INTEL_GEN(dev_priv) < 11)
+   crtc_state->csc_enable |=
+   crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB;
 
ret = intel_color_add_affected_planes(crtc_state);
if (ret)
@@ -822,6 +823,15 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
crtc_state->csc_mode |= ICL_OUTPUT_CSC_ENABLE;
 
crtc_state->csc_mode |= ICL_CSC_ENABLE;
+   } else if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB &&
+  crtc_state->base.ctm) {
+   /*
+* There is only one pipe CSC unit per pipe on pre-gen11, and
+* we need that for output conversion from RGB->YCBCR. So if
+* CTM is already applied we can't support YCBCR output.
+*/
+   DRM_DEBUG_KMS("YCBCR420 and CTM together are not possible\n");
+   return -EINVAL;
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index afa21daaae51..81bfdbd99092 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6855,18 +6855,6 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
return -EINVAL;
}
 
-   if ((pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
-pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) &&
-pipe_config->base.ctm) {
-   /*
-* There is only one pipe CSC unit per pipe, and we need that
-* for output conversion from RGB->YCBCR. So if CTM is already
-* applied we can't support YCBCR420 output.
-*/
-   DRM_DEBUG_KMS("YCBCR420 and CTM together are not possible\n");
-   return -EINVAL;
-   }
-
/*
 * Pipe horizontal size must be even in:
 * - DVO ganged mode
-- 
2.14.5

___
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: Implement HDCP2.2

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Implement HDCP2.2
URL   : https://patchwork.freedesktop.org/series/56757/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/intel_hdcp.o
In file included from ./include/drm/i915_component.h:27:0,
 from drivers/gpu/drm/i915/intel_hdcp.c:10:
./include/drm/drm_audio_component.h:25:36: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  unsigned long (*get_power)(struct device *);
^~
./include/drm/drm_audio_component.h:31:27: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  void (*put_power)(struct device *, unsigned long);
   ^~
./include/drm/drm_audio_component.h:35:37: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  void (*codec_wake_override)(struct device *, bool enable);
 ^~
./include/drm/drm_audio_component.h:39:31: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  int (*get_cdclk_freq)(struct device *);
   ^~
./include/drm/drm_audio_component.h:46:32: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  int (*sync_audio_rate)(struct device *, int port, int pipe, int rate);
^~
./include/drm/drm_audio_component.h:59:24: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  int (*get_eld)(struct device *, int port, int pipe, bool *enabled,
^~
./include/drm/drm_audio_component.h:93:28: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  int (*master_bind)(struct device *dev, struct drm_audio_component *);
^~
./include/drm/drm_audio_component.h:100:31: error: ‘struct device’ declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]
  void (*master_unbind)(struct device *dev, struct drm_audio_component *);
   ^~
cc1: all warnings being treated as errors
scripts/Makefile.build:276: recipe for target 
'drivers/gpu/drm/i915/intel_hdcp.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_hdcp.o] Error 1
scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:492: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:492: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1043: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH] drm/i915/guc: Remove preemption support for current fw

2019-02-15 Thread Chris Wilson
Preemption via GuC submission quickly degrades into confused firmware
and misordered requests. It is not being supported with no intention of
being fixed in its current incarnation, so remove the unstable code. By
removing the workqueue from the GuC submission path, we can now do
direct engine-resets and direct submission from atomic context.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108622
Signed-off-by: Chris Wilson 
Cc: Jon Ewins 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   5 -
 drivers/gpu/drm/i915/intel_guc.c  |  31 ---
 drivers/gpu/drm/i915/intel_guc.h  |   9 -
 drivers/gpu/drm/i915/intel_guc_submission.c   | 203 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |   2 -
 drivers/gpu/drm/i915/selftests/intel_guc.c|  17 +-
 .../gpu/drm/i915/selftests/intel_hangcheck.c  |   3 -
 7 files changed, 5 insertions(+), 265 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..636e28367980 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2233,11 +2233,6 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
-   if (guc->preempt_client) {
-   seq_printf(m, "\nGuC preempt client @ %p:\n",
-  guc->preempt_client);
-   i915_guc_client_info(m, dev_priv, guc->preempt_client);
-   }
 
/* Add more as required ... */
 
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 8660af3fd755..8fa2de84d82e 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -76,8 +76,6 @@ void intel_guc_init_early(struct intel_guc *guc)
 
 static int guc_init_wq(struct intel_guc *guc)
 {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
/*
 * GuC log buffer flush work item has to do register access to
 * send the ack to GuC and this work item, if not synced before
@@ -97,31 +95,6 @@ static int guc_init_wq(struct intel_guc *guc)
return -ENOMEM;
}
 
-   /*
-* Even though both sending GuC action, and adding a new workitem to
-* GuC workqueue are serialized (each with its own locking), since
-* we're using mutliple engines, it's possible that we're going to
-* issue a preempt request with two (or more - each for different
-* engine) workitems in GuC queue. In this situation, GuC may submit
-* all of them, which will make us very confused.
-* Our preemption contexts may even already be complete - before we
-* even had the chance to sent the preempt action to GuC!. Rather
-* than introducing yet another lock, we can just use ordered workqueue
-* to make sure we're always sending a single preemption request with a
-* single workitem.
-*/
-   if (HAS_LOGICAL_RING_PREEMPTION(dev_priv) &&
-   USES_GUC_SUBMISSION(dev_priv)) {
-   guc->preempt_wq = alloc_ordered_workqueue("i915-guc_preempt",
- WQ_HIGHPRI);
-   if (!guc->preempt_wq) {
-   destroy_workqueue(guc->log.relay.flush_wq);
-   DRM_ERROR("Couldn't allocate workqueue for GuC "
- "preemption\n");
-   return -ENOMEM;
-   }
-   }
-
return 0;
 }
 
@@ -129,10 +102,6 @@ static void guc_fini_wq(struct intel_guc *guc)
 {
struct workqueue_struct *wq;
 
-   wq = fetch_and_zero(>preempt_wq);
-   if (wq)
-   destroy_workqueue(wq);
-
wq = fetch_and_zero(>log.relay.flush_wq);
if (wq)
destroy_workqueue(wq);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 744220296653..b8c4615715c0 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -34,11 +34,6 @@
 #include "intel_uc_fw.h"
 #include "i915_vma.h"
 
-struct guc_preempt_work {
-   struct work_struct work;
-   struct intel_engine_cs *engine;
-};
-
 /*
  * Top level structure of GuC. It handles firmware loading and manages client
  * pool and doorbells. intel_guc owns a intel_guc_client to replace the legacy
@@ -65,10 +60,6 @@ struct intel_guc {
void *shared_data_vaddr;
 
struct intel_guc_client *execbuf_client;
-   struct intel_guc_client *preempt_client;
-
-   struct guc_preempt_work preempt_work[I915_NUM_ENGINES];
-   struct workqueue_struct *preempt_wq;
 
DECLARE_BITMAP(doorbell_bitmap, GUC_NUM_DOORBELLS);
/* Cyclic counter mod pagesize  */
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 

[Intel-gfx] [PATCH v2] drm/i915: Restore interrupt enabling after a reset

2019-02-15 Thread Chris Wilson
At least on i965g and i965gm, performing a device reset clobbers the IER
resulting in loss of interrupts thereafter. So, run the irq_postinstall
hook to restore them.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
Put it back to restoring the GMCH first. Hmm, maybe that's the key as to
which platforms require this?
---
 drivers/gpu/drm/i915/i915_reset.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 5a067a4b3d5d..a1b74f605f2d 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -675,6 +675,7 @@ static int gt_reset(struct drm_i915_private *i915, unsigned 
int stalled_mask)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
+   unsigned long flags;
int err;
 
/*
@@ -685,12 +686,17 @@ static int gt_reset(struct drm_i915_private *i915, 
unsigned int stalled_mask)
if (err)
return err;
 
+   /* Restore IER as it may get clobbered on some platforms! (i965g[m]) */
+   spin_lock_irqsave(>irq_lock, flags);
+   i915->drm.driver->irq_postinstall(>drm);
+   spin_unlock_irqrestore(>irq_lock, flags);
+
for_each_engine(engine, i915, id)
intel_engine_reset(engine, stalled_mask & ENGINE_MASK(id));
 
i915_gem_restore_fences(i915);
 
-   return err;
+   return 0;
 }
 
 static void reset_finish_engine(struct intel_engine_cs *engine)
-- 
2.20.1

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

[Intel-gfx] [PATCH] drm/i915: Restore interrupt enabling after a reset

2019-02-15 Thread Chris Wilson
At least on i965g and i965gm, performing a device reset clobbers the IER
resulting in loss of interrupts thereafter. So, run the irq_postinstall
hook to restore them.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
This feels a bit hairy, so maybe limit it to
INTEL_INFO()->reset_clobbers_display? Or even introduce
reset_clobbers_interrupt with the same platforms as clobbers_display?
-Chris
---
 drivers/gpu/drm/i915/i915_reset.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reset.c 
b/drivers/gpu/drm/i915/i915_reset.c
index 5a067a4b3d5d..451233709d1a 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -675,8 +675,14 @@ static int gt_reset(struct drm_i915_private *i915, 
unsigned int stalled_mask)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
+   unsigned long flags;
int err;
 
+   /* Restore IER as it may get clobbered on some platforms! (i965g[m]) */
+   spin_lock_irqsave(>irq_lock, flags);
+   i915->drm.driver->irq_postinstall(>drm);
+   spin_unlock_irqrestore(>irq_lock, flags);
+
/*
 * Everything depends on having the GTT running, so we need to start
 * there.
@@ -690,7 +696,7 @@ static int gt_reset(struct drm_i915_private *i915, unsigned 
int stalled_mask)
 
i915_gem_restore_fences(i915);
 
-   return err;
+   return 0;
 }
 
 static void reset_finish_engine(struct intel_engine_cs *engine)
-- 
2.20.1

___
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/selftests: Fix resource leak in __sseu_prepare (rev2)

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Fix resource leak in __sseu_prepare (rev2)
URL   : https://patchwork.freedesktop.org/series/56755/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5611 -> Patchwork_12229


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56755/revisions/2/mbox/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   PASS -> DMESG-WARN [fdo#107709]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s4-devices:
- {fi-icl-y}: INCOMPLETE [fdo#107713] -> PASS

  * igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
  [fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567


Participating hosts (49 -> 42)
--

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-ivb-3770 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5611 -> Patchwork_12229

  CI_DRM_5611: c09679e398a860df940ba35ad5102e396bf4acb5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4831: 616842ef493ead76ac6c75b2a93337439724655f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12229: 6a3e00cd6a15ae426cc8006606c74367c077dff9 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6a3e00cd6a15 drm/i915/selftests: Always free spinner on __sseu_prepare error

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Reduce the RPS shock

2019-02-15 Thread Chris Wilson
Quoting Chris Wilson (2019-02-15 17:00:30)
> Limit deboosting and boosting to keep ourselves at the extremes
> when in the respective power modes (i.e. slowly decrease frequencies
> while in the HIGH_POWER zone and slowly increase frequencies while
> in the LOW_POWER zone). On idle, we will hit the timeout and drop
> to the next level quickly, and conversely if busy we expect to
> hit a waitboost and rapidly switch into max power.
> 
> This should improve the UX experience by keeping the GPU clocks higher
> than they ostensibly should be (based on simple busyness) by switching
> into the INTERACTIVE mode (due to waiting for pageflips) and increasing
> clocks via waitboosting. This will incur some additional power, our
> saving grace should be rc6 and powergating to keep the extra current
> draw in check.
> 
> Food for future thought would be deadline scheduling? If we know certain
> contexts (high priority compositors) absolutely must hit the next vblank
> then we can raise the frequencies ahead of time. Part of this is covered
> by per-context frequencies, where userspace is given control over the
> frequency range they want the GPU to execute at (for largely the same
> problem as this, where the workload is very latency sensitive but at the
> EI level appears mostly idle). Indeed, the per-context series does
> extend the modeset boosting to include a frequency range tweak which
> seems applicable to solving this jittery UX behaviour.
> 
> Reported-by: Lyude Paul 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408
> References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj")
> References: 60548c554be2 ("drm/i915: Interactive RPS mode")
> Signed-off-by: Chris Wilson 
> Cc: Lyude Paul 
> Cc: Eero Tamminen 
> Cc: Joonas Lahtinen 
> Cc: Michel Thierry 

Cribbed from Lyude on irc

before reverting 0d55babc8392754352f1058866dd4182ae587d11: [4.20]

35 measurements
Average: 33.65657142857143 FPS
FPS observed: 20.8 - 46.87 FPS
Percentage under 60 FPS: 100.0%
Percentage under 55 FPS: 100.0%
Percentage under 50 FPS: 100.0%
Percentage under 45 FPS: 97.14285714285714%
Percentage under 40 FPS: 97.14285714285714%
Percentage under 35 FPS: 45.714285714285715%
Percentage under 30 FPS: 11.428571428571429%
Percentage under 25 FPS: 2.857142857142857%

After reverting: [4.19 behaviour]

30 measurements
Average: 49.833 FPS
FPS observed: 33.85 - 60.0 FPS
Percentage under 60 FPS: 86.67%
Percentage under 55 FPS: 70.0%
Percentage under 50 FPS: 53.336%
Percentage under 45 FPS: 20.0%
Percentage under 40 FPS: 6.667%
Percentage under 35 FPS: 6.667%
Percentage under 30 FPS: 0%
Percentage under 25 FPS: 0%

Patched:
42 measurements
Average: 46.05428571428571 FPS
FPS observed: 1.82 - 59.98 FPS
Percentage under 60 FPS: 88.09523809523809%
Percentage under 55 FPS: 61.904761904761905%
Percentage under 50 FPS: 45.23809523809524%
Percentage under 45 FPS: 35.714285714285715%
Percentage under 40 FPS: 33.33%
Percentage under 35 FPS: 19.047619047619047%
Percentage under 30 FPS: 7.142857142857142%
Percentage under 25 FPS: 4.761904761904762%

Tested-by: Lyude Paul 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the broken DP CRC support for g4x

2019-02-15 Thread Pandiyan, Dhinakaran
On Fri, 2019-02-15 at 23:34 +0200, Ville Syrjälä wrote:
> On Fri, Feb 15, 2019 at 01:06:32PM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan
> > > wrote:
> > > > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > DP CRCs don't really work on g4x. If you want any CRCs on DP
> > > > > you
> > > > > must
> > > > > select the CRC source before the port is enabled, otherwise
> > > > > the
> > > > > CRC
> > > > > source select bits simply ignore any writes to them. And once
> > > > > the
> > > > > port
> > > > > is enabled we mustn't change the CRC source select until the
> > > > > port
> > > > > is
> > > > > disabled. That almost works, but not quite :( Eventually the
> > > > > CRC
> > > > > source
> > > > > select bits get permanently stuck one way or the other, and
> > > > > after
> > > > > that
> > > > > a reboot (or possibly a display reset) is needed to get
> > > > > working
> > > > > CRCs
> > > > > on that pipe (not matter which CRC source we try to use).
> > > > > 
> > > > > Additionally the DFT scrambler reset bits we're trying to use
> > > > > don't
> > > > > seem to exist on g4x. There are some potentially relevant
> > > > > looking
> > > > > bits
> > > > > in the pipe registers, but when I tried it I got stable
> > > > > looking
> > > > > CRCs
> > > > > without setting any bits for this.
> > > > > 
> > > > > If there is a way to make DP CRCs work reliably on g4x, I
> > > > > wasn't
> > > > > able to find it. So let's just remove the broken code we
> > > > > have.
> > > > 
> > > > 
> > > > I think we can modify i9xx_pipe_crc_auto_source() to pick
> > > > "pipe"
> > > > CRC
> > > > when userspace selects "auto" and the output is DP/eDP.
> > > 
> > > Nope. Spec says:
> > > "Pipe CRC should not be run when Display Port or TV is enabled on
> > > this
> > >  pipe."
> > > 
> > > and
> > > 
> > > "CRC Source Select: These bits select the source of the data to
> > > put
> > > into
> > >  the CRC logic.
> > >  000: Pipe A (Not available when DisplayPort or TV is enabled on
> > > this
> > >  pipe)"
> > > 
> > 
> > After digging through some old specs, I do see this restriction for
> > gen-4 and VLV, but for some reason not for gen-3 or CHV. 
> 
> gen3 predates DP (g4x being the first platform that has it). I don't
> think SDVO->DP was ever a thing. SDVO->HDMI did happen but even that
> one is quite rare.

TV? I see TV initialization for a couple of gen-3 platforms but the
spec does not say that pipe CRCs are not available.
> 
> The display engine side of CHV is 99.9% VLV, with a few extra
> bits and pieces glued on top.

Thanks for the clarification, the CHV spec for some reason make it a
point to specify VLV in paranthesis

: Pipe C (Not available when DisplayPort or TV is enabled on this
pipe) [VLV]

> 
> > 
> > There is no good choice for "auto" other than DP and since DP does
> > not
> > work, returning -EINVAL makes sense.
> > Reviewed-by: Dhinakaran Pandiyan 
> > 
> > > Though I must admit I've never actually tried it to see what
> > > actually
> > > happens.
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 80 -
> > > > > 
> > > > > 
> > > > > --
> > > > >  1 file changed, 11 insertions(+), 69 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > index fe0ff89b980b..66bb7b031537 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > > @@ -191,8 +191,6 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > > > drm_i915_private *dev_priv,
> > > > >enum intel_pipe_crc_source
> > > > > *source,
> > > > >u32 *val)
> > > > >  {
> > > > > - bool need_stable_symbols = false;
> > > > > -
> > > > >   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > > > >   int ret = i9xx_pipe_crc_auto_source(dev_priv,
> > > > > pipe,
> > > > > source);
> > > > >   if (ret)
> > > > > @@ -208,56 +206,23 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > > > drm_i915_private *dev_priv,
> > > > >   return -EINVAL;
> > > > >   *val = PIPE_CRC_ENABLE |
> > > > > PIPE_CRC_SOURCE_TV_PRE;
> > > > >   break;
> > > > > - case INTEL_PIPE_CRC_SOURCE_DP_B:
> > > > > - if (!IS_G4X(dev_priv))
> > > > > - return -EINVAL;
> > > > > - *val = PIPE_CRC_ENABLE |
> > > > > PIPE_CRC_SOURCE_DP_B_G4X;
> > > > > - need_stable_symbols = true;
> > > > > - break;
> > > > > - case INTEL_PIPE_CRC_SOURCE_DP_C:
> > > > > - if (!IS_G4X(dev_priv))
> > > > > - return -EINVAL;
> > > > > -

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the broken DP CRC support for g4x

2019-02-15 Thread Ville Syrjälä
On Fri, Feb 15, 2019 at 01:06:32PM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote:
> > On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > DP CRCs don't really work on g4x. If you want any CRCs on DP you
> > > > must
> > > > select the CRC source before the port is enabled, otherwise the
> > > > CRC
> > > > source select bits simply ignore any writes to them. And once the
> > > > port
> > > > is enabled we mustn't change the CRC source select until the port
> > > > is
> > > > disabled. That almost works, but not quite :( Eventually the CRC
> > > > source
> > > > select bits get permanently stuck one way or the other, and after
> > > > that
> > > > a reboot (or possibly a display reset) is needed to get working
> > > > CRCs
> > > > on that pipe (not matter which CRC source we try to use).
> > > > 
> > > > Additionally the DFT scrambler reset bits we're trying to use
> > > > don't
> > > > seem to exist on g4x. There are some potentially relevant looking
> > > > bits
> > > > in the pipe registers, but when I tried it I got stable looking
> > > > CRCs
> > > > without setting any bits for this.
> > > > 
> > > > If there is a way to make DP CRCs work reliably on g4x, I wasn't
> > > > able to find it. So let's just remove the broken code we have.
> > > 
> > > 
> > > I think we can modify i9xx_pipe_crc_auto_source() to pick "pipe"
> > > CRC
> > > when userspace selects "auto" and the output is DP/eDP.
> > 
> > Nope. Spec says:
> > "Pipe CRC should not be run when Display Port or TV is enabled on
> > this
> >  pipe."
> > 
> > and
> > 
> > "CRC Source Select: These bits select the source of the data to put
> > into
> >  the CRC logic.
> >  000: Pipe A (Not available when DisplayPort or TV is enabled on this
> >  pipe)"
> > 
> After digging through some old specs, I do see this restriction for
> gen-4 and VLV, but for some reason not for gen-3 or CHV. 

gen3 predates DP (g4x being the first platform that has it). I don't
think SDVO->DP was ever a thing. SDVO->HDMI did happen but even that
one is quite rare.

The display engine side of CHV is 99.9% VLV, with a few extra
bits and pieces glued on top.

> 
> There is no good choice for "auto" other than DP and since DP does not
> work, returning -EINVAL makes sense.
> Reviewed-by: Dhinakaran Pandiyan 
> 
> > Though I must admit I've never actually tried it to see what actually
> > happens.
> > 
> > > 
> > > 
> > > > 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 80 -
> > > > 
> > > > --
> > > >  1 file changed, 11 insertions(+), 69 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > index fe0ff89b980b..66bb7b031537 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > > @@ -191,8 +191,6 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > > drm_i915_private *dev_priv,
> > > >  enum intel_pipe_crc_source *source,
> > > >  u32 *val)
> > > >  {
> > > > -   bool need_stable_symbols = false;
> > > > -
> > > > if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > > > int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe,
> > > > source);
> > > > if (ret)
> > > > @@ -208,56 +206,23 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > > drm_i915_private *dev_priv,
> > > > return -EINVAL;
> > > > *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_TV_PRE;
> > > > break;
> > > > -   case INTEL_PIPE_CRC_SOURCE_DP_B:
> > > > -   if (!IS_G4X(dev_priv))
> > > > -   return -EINVAL;
> > > > -   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_B_G4X;
> > > > -   need_stable_symbols = true;
> > > > -   break;
> > > > -   case INTEL_PIPE_CRC_SOURCE_DP_C:
> > > > -   if (!IS_G4X(dev_priv))
> > > > -   return -EINVAL;
> > > > -   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_G4X;
> > > > -   need_stable_symbols = true;
> > > > -   break;
> > > > -   case INTEL_PIPE_CRC_SOURCE_DP_D:
> > > > -   if (!IS_G4X(dev_priv))
> > > > -   return -EINVAL;
> > > > -   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_G4X;
> > > > -   need_stable_symbols = true;
> > > > -   break;
> > > > case INTEL_PIPE_CRC_SOURCE_NONE:
> > > > *val = 0;
> > > > break;
> > > > default:
> > > > +   /*
> > > > +* The DP CRC source doesn't work on g4x.
> > > > +* It can be made to work to some degree by 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the broken DP CRC support for g4x

2019-02-15 Thread Dhinakaran Pandiyan
On Fri, 2019-02-15 at 14:47 +0200, Ville Syrjälä wrote:
> On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > DP CRCs don't really work on g4x. If you want any CRCs on DP you
> > > must
> > > select the CRC source before the port is enabled, otherwise the
> > > CRC
> > > source select bits simply ignore any writes to them. And once the
> > > port
> > > is enabled we mustn't change the CRC source select until the port
> > > is
> > > disabled. That almost works, but not quite :( Eventually the CRC
> > > source
> > > select bits get permanently stuck one way or the other, and after
> > > that
> > > a reboot (or possibly a display reset) is needed to get working
> > > CRCs
> > > on that pipe (not matter which CRC source we try to use).
> > > 
> > > Additionally the DFT scrambler reset bits we're trying to use
> > > don't
> > > seem to exist on g4x. There are some potentially relevant looking
> > > bits
> > > in the pipe registers, but when I tried it I got stable looking
> > > CRCs
> > > without setting any bits for this.
> > > 
> > > If there is a way to make DP CRCs work reliably on g4x, I wasn't
> > > able to find it. So let's just remove the broken code we have.
> > 
> > 
> > I think we can modify i9xx_pipe_crc_auto_source() to pick "pipe"
> > CRC
> > when userspace selects "auto" and the output is DP/eDP.
> 
> Nope. Spec says:
> "Pipe CRC should not be run when Display Port or TV is enabled on
> this
>  pipe."
> 
> and
> 
> "CRC Source Select: These bits select the source of the data to put
> into
>  the CRC logic.
>  000: Pipe A (Not available when DisplayPort or TV is enabled on this
>  pipe)"
> 
After digging through some old specs, I do see this restriction for
gen-4 and VLV, but for some reason not for gen-3 or CHV. 

There is no good choice for "auto" other than DP and since DP does not
work, returning -EINVAL makes sense.
Reviewed-by: Dhinakaran Pandiyan 

> Though I must admit I've never actually tried it to see what actually
> happens.
> 
> > 
> > 
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pipe_crc.c | 80 -
> > > 
> > > --
> > >  1 file changed, 11 insertions(+), 69 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > index fe0ff89b980b..66bb7b031537 100644
> > > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > > @@ -191,8 +191,6 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > drm_i915_private *dev_priv,
> > >enum intel_pipe_crc_source *source,
> > >u32 *val)
> > >  {
> > > - bool need_stable_symbols = false;
> > > -
> > >   if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > >   int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe,
> > > source);
> > >   if (ret)
> > > @@ -208,56 +206,23 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > > drm_i915_private *dev_priv,
> > >   return -EINVAL;
> > >   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_TV_PRE;
> > >   break;
> > > - case INTEL_PIPE_CRC_SOURCE_DP_B:
> > > - if (!IS_G4X(dev_priv))
> > > - return -EINVAL;
> > > - *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_B_G4X;
> > > - need_stable_symbols = true;
> > > - break;
> > > - case INTEL_PIPE_CRC_SOURCE_DP_C:
> > > - if (!IS_G4X(dev_priv))
> > > - return -EINVAL;
> > > - *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_G4X;
> > > - need_stable_symbols = true;
> > > - break;
> > > - case INTEL_PIPE_CRC_SOURCE_DP_D:
> > > - if (!IS_G4X(dev_priv))
> > > - return -EINVAL;
> > > - *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_G4X;
> > > - need_stable_symbols = true;
> > > - break;
> > >   case INTEL_PIPE_CRC_SOURCE_NONE:
> > >   *val = 0;
> > >   break;
> > >   default:
> > > + /*
> > > +  * The DP CRC source doesn't work on g4x.
> > > +  * It can be made to work to some degree by selecting
> > > +  * the correct CRC source before the port is enabled,
> > > +  * and not touching the CRC source bits again until
> > > +  * the port is disabled. But even then the bits
> > > +  * eventually get stuck and a reboot is needed to get
> > > +  * working CRCs on the pipe again. Let's simply
> > > +  * refuse to use DP CRCs on g4x.
> > > +  */z
> > >   return -EINVAL;
> > >   }
> > >  
> > > - /*
> > > -  * When the pipe CRC tap point is after the transcoders we need
> > > -  * to tweak symbol-level features to produce a deterministic
> > > series of
> > > -  * symbols for a given frame. We need to reset those features
> > > only once
> > > -  * a frame (instead of every nth 

[Intel-gfx] [PATCH v14 23/32] misc/mei/hdcp: Store the HDCP Pairing info

2019-02-15 Thread Ramalingam C
Provides Pairing info to ME to store.

Pairing is a process to fast track the subsequent authentication
with the same HDCP sink.

On Success, received HDCP pairing info is stored in non-volatile
memory of ME.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
  memcpy for const length.
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 60 +++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 0a4087a2efd5..1f5514244716 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -238,6 +238,64 @@ mei_hdcp_verify_hprime(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_hdcp_store_pairing_info() - Store pairing info received at ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @pairing_info: AKE_Send_Pairing_Info msg input to ME FW
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_hdcp_store_pairing_info(struct device *dev, struct hdcp_port_data *data,
+   struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+   struct wired_cmd_ake_send_pairing_info_in pairing_info_in = { { 0 } };
+   struct wired_cmd_ake_send_pairing_info_out pairing_info_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !pairing_info)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   pairing_info_in.header.api_version = HDCP_API_VERSION;
+   pairing_info_in.header.command_id = WIRED_AKE_SEND_PAIRING_INFO;
+   pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   pairing_info_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
+
+   pairing_info_in.port.integrated_port_type = data->port_type;
+   pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
+  HDCP_2_2_E_KH_KM_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_info_in,
+ sizeof(pairing_info_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_info_out,
+ sizeof(pairing_info_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_PAIRING_INFO,
+   pairing_info_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -245,7 +303,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_receiver_cert_prepare_km =
mei_hdcp_verify_receiver_cert_prepare_km,
.verify_hprime = mei_hdcp_verify_hprime,
-   .store_pairing_info = NULL,
+   .store_pairing_info = mei_hdcp_store_pairing_info,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
.get_session_key = NULL,
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 17/32] mei: bus: export to_mei_cl_device for mei client device drivers

2019-02-15 Thread Ramalingam C
From: Tomas Winkler 

Export to_mei_cl_device macro, it is needed also in mei client drivers.

Signed-off-by: Tomas Winkler 
Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/bus.c | 1 -
 include/linux/mei_cl_bus.h | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index fc3872fe7b25..e5456faf00e6 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -28,7 +28,6 @@
 #include "client.h"
 
 #define to_mei_cl_driver(d) container_of(d, struct mei_cl_driver, driver)
-#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
 
 /**
  * __mei_cl_send - internal client send (write)
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index 7fde40e17c8b..03b6ba2a63f8 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -55,6 +55,8 @@ struct mei_cl_device {
void *priv_data;
 };
 
+#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
+
 struct mei_cl_driver {
struct device_driver driver;
const char *name;
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 22/32] misc/mei/hdcp: Verify H_prime

2019-02-15 Thread Ramalingam C
Requests for the verification of AKE_Send_H_prime.

ME will calculate the H and comparing it with received H_Prime.
The result will be returned as status.

Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Styles and typos fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc Addition [Tomas]
  memcpy for const length.
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 58 +++-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 922c6a76bb9f..0a4087a2efd5 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -182,13 +182,69 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device 
*dev,
return 0;
 }
 
+/**
+ * mei_hdcp_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @rx_hprime: AKE_Send_H_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_hdcp_verify_hprime(struct device *dev, struct hdcp_port_data *data,
+  struct hdcp2_ake_send_hprime *rx_hprime)
+{
+   struct wired_cmd_ake_send_hprime_in send_hprime_in = { { 0 } };
+   struct wired_cmd_ake_send_hprime_out send_hprime_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !rx_hprime)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   send_hprime_in.header.api_version = HDCP_API_VERSION;
+   send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
+   send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
+
+   send_hprime_in.port.integrated_port_type = data->port_type;
+   send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
+  HDCP_2_2_H_PRIME_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_hprime_in,
+ sizeof(send_hprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_hprime_out,
+ sizeof(send_hprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_AKE_SEND_HPRIME, send_hprime_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_hdcp_initiate_session,
.verify_receiver_cert_prepare_km =
mei_hdcp_verify_receiver_cert_prepare_km,
-   .verify_hprime = NULL,
+   .verify_hprime = mei_hdcp_verify_hprime,
.store_pairing_info = NULL,
.initiate_locality_check = NULL,
.verify_lprime = NULL,
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 21/32] misc/mei/hdcp: Verify Receiver Cert and prepare km

2019-02-15 Thread Ramalingam C
Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.

On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else AKE_No_Stored_Km will be prepared.

Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd is used for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc Addition. [Tomas]
  memcpy for const length.
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  Fixed the conversion of u8 to bool [Tomas]
  K-Doc fix [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 83 +++-
 1 file changed, 82 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 952bae79dd02..922c6a76bb9f 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -102,11 +102,92 @@ mei_hdcp_initiate_session(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_hdcp_verify_receiver_cert_prepare_km() - Verify the Receiver Certificate
+ * AKE_Send_Cert and prepare AKE_Stored_Km/AKE_No_Stored_Km
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @rx_cert: AKE_Send_Cert for verification
+ * @km_stored: Pairing status flag output
+ * @ek_pub_km: AKE_Stored_Km/AKE_No_Stored_Km output msg
+ * @msg_sz : size of AKE_X_Km output msg
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
+struct hdcp_port_data *data,
+struct hdcp2_ake_send_cert *rx_cert,
+bool *km_stored,
+struct hdcp2_ake_no_stored_km
+   *ek_pub_km,
+size_t *msg_sz)
+{
+   struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
+   struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_rxcert_in.header.api_version = HDCP_API_VERSION;
+   verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
+   verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_rxcert_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
+
+   verify_rxcert_in.port.integrated_port_type = data->port_type;
+   verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   verify_rxcert_in.cert_rx = rx_cert->cert_rx;
+   memcpy(verify_rxcert_in.r_rx, _cert->r_rx, HDCP_2_2_RRX_LEN);
+   memcpy(verify_rxcert_in.rx_caps, rx_cert->rx_caps, HDCP_2_2_RXCAPS_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_rxcert_in,
+ sizeof(verify_rxcert_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed: %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_rxcert_out,
+ sizeof(verify_rxcert_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed: %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_VERIFY_RECEIVER_CERT,
+   verify_rxcert_out.header.status);
+   return -EIO;
+   }
+
+   *km_stored = !!verify_rxcert_out.km_stored;
+   if (verify_rxcert_out.km_stored) {
+   ek_pub_km->msg_id = HDCP_2_2_AKE_STORED_KM;
+   *msg_sz = sizeof(struct hdcp2_ake_stored_km);
+   } else {
+   ek_pub_km->msg_id = HDCP_2_2_AKE_NO_STORED_KM;
+   *msg_sz = sizeof(struct hdcp2_ake_no_stored_km);
+   }
+
+   memcpy(ek_pub_km->e_kpub_km, _rxcert_out.ekm_buff,
+  sizeof(verify_rxcert_out.ekm_buff));
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_hdcp_initiate_session,
-   .verify_receiver_cert_prepare_km = NULL,
+   

[Intel-gfx] [PATCH v14 18/32] misc/mei/hdcp: Client driver for HDCP application

2019-02-15 Thread Ramalingam C
ME FW contributes a vital role in HDCP2.2 authentication.
HDCP2.2 driver needs to communicate to ME FW for each step of the
HDCP2.2 authentication.

ME FW prepare and HDCP2.2 authentication  parameters and encrypt them
as per spec. With such parameter Driver prepares HDCP2.2 auth messages
and communicate with HDCP2.2 sink.

Similarly HDCP2.2 sink's response is shared with ME FW for decrypt and
verification.

Once All the steps of HDCP2.2 authentications are complete on driver's
request ME FW will configure the port as authenticated and supply the
HDCP keys to the Gen HW for encryption.

Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption
for a port.

ME FW is interfaced to kernel through MEI Bus Driver. To obtain the
HDCP2.2 services from the ME FW through MEI Bus driver MEI Client
Driver is developed.

v2:
  hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas]
v3:
  Squashed the Kbuild support [Tomas]
  UUID renamed and Module License is modified [Tomas]
  drv_data is set to null at remove [Tomas]
v4:
  Module name is changed to "MEI HDCP"
  I915 Selects the MEI_HDCP
v5:
  Remove redundant text from the License header
  Fix malformed licence
  Removed the drv_data resetting.
v6:
  K-Doc addition. [Tomas]
v7:
  %s/UUID_LE/GUID_INIT [Tomas]
  GPL Ver is 2.0 than 2.0+ [Tomas]

Signed-off-by: Ramalingam C 
Signed-off-by: Tomas Winkler 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/Kconfig |  7 +
 drivers/misc/mei/Makefile|  2 ++
 drivers/misc/mei/hdcp/Makefile   |  7 +
 drivers/misc/mei/hdcp/mei_hdcp.c | 64 
 4 files changed, 80 insertions(+)
 create mode 100644 drivers/misc/mei/hdcp/Makefile
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index c49e1d2269af..64a7b3483895 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -43,3 +43,10 @@ config INTEL_MEI_TXE
 
  Supported SoCs:
  Intel Bay Trail
+
+config INTEL_MEI_HDCP
+   tristate "Intel HDCP2.2 services of ME Interface"
+   select INTEL_MEI_ME
+   depends on DRM_I915
+   help
+ MEI Support for HDCP2.2 Services on Intel platforms.
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index d9215fc4e499..8c2d9565a4cb 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -24,3 +24,5 @@ mei-txe-objs += hw-txe.o
 
 mei-$(CONFIG_EVENT_TRACING) += mei-trace.o
 CFLAGS_mei-trace.o = -I$(src)
+
+obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
diff --git a/drivers/misc/mei/hdcp/Makefile b/drivers/misc/mei/hdcp/Makefile
new file mode 100644
index ..e27d10754dbf
--- /dev/null
+++ b/drivers/misc/mei/hdcp/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (c) 2017-2018, Intel Corporation.
+#
+# Makefile - HDCP client driver for Intel MEI Bus Driver.
+
+obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
new file mode 100644
index ..8df069c1b0cc
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: (GPL-2.0)
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Mei_hdcp.c: HDCP client driver for mei bus
+ *
+ * Author:
+ * Ramalingam C 
+ */
+
+/**
+ * DOC: MEI_HDCP Client Driver
+ *
+ * This is a client driver to the mei_bus to make the HDCP2.2 services of
+ * ME FW available for the interested consumers like I915.
+ *
+ * This module will act as a translation layer between HDCP protocol
+ * implementor(I915) and ME FW by translating HDCP2.2 authentication
+ * messages to ME FW command payloads and vice versa.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int mei_hdcp_probe(struct mei_cl_device *cldev,
+ const struct mei_cl_device_id *id)
+{
+   int ret;
+
+   ret = mei_cldev_enable(cldev);
+   if (ret < 0)
+   dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
+
+   return ret;
+}
+
+static int mei_hdcp_remove(struct mei_cl_device *cldev)
+{
+   return mei_cldev_disable(cldev);
+}
+
+#define MEI_UUID_HDCP GUID_INIT(0xB638AB7E, 0x94E2, 0x4EA2, 0xA5, \
+   0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
+
+static struct mei_cl_device_id mei_hdcp_tbl[] = {
+   { .uuid = MEI_UUID_HDCP, .version = MEI_CL_VERSION_ANY },
+   { }
+};
+MODULE_DEVICE_TABLE(mei, mei_hdcp_tbl);
+
+static struct mei_cl_driver mei_hdcp_driver = {
+   .id_table = mei_hdcp_tbl,
+   .name = KBUILD_MODNAME,
+   .probe = mei_hdcp_probe,
+   .remove = mei_hdcp_remove,
+};
+
+module_mei_cl_driver(mei_hdcp_driver);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MEI HDCP");
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 26/32] misc/mei/hdcp: Prepare Session Key

2019-02-15 Thread Ramalingam C
Request to ME to prepare the encrypted session key.

On Success, ME provides Encrypted session key. Function populates
the HDCP2.2 authentication msg SKE_Send_Eks.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 59 +++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 869a6f22f68d..fe5070f901e8 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -409,6 +409,63 @@ mei_hdcp_verify_lprime(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_hdcp_get_session_key() - Prepare SKE_Send_Eks.
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @ske_data: SKE_Send_Eks msg output from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_hdcp_get_session_key(struct device *dev,
+   struct hdcp_port_data *data,
+   struct hdcp2_ske_send_eks *ske_data)
+{
+   struct wired_cmd_get_session_key_in get_skey_in = { { 0 } };
+   struct wired_cmd_get_session_key_out get_skey_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !ske_data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   get_skey_in.header.api_version = HDCP_API_VERSION;
+   get_skey_in.header.command_id = WIRED_GET_SESSION_KEY;
+   get_skey_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   get_skey_in.header.buffer_len = WIRED_CMD_BUF_LEN_GET_SESSION_KEY_IN;
+
+   get_skey_in.port.integrated_port_type = data->port_type;
+   get_skey_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   byte = mei_cldev_send(cldev, (u8 *)_skey_in, sizeof(get_skey_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_skey_out, sizeof(get_skey_out));
+
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (get_skey_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_GET_SESSION_KEY, get_skey_out.header.status);
+   return -EIO;
+   }
+
+   ske_data->msg_id = HDCP_2_2_SKE_SEND_EKS;
+   memcpy(ske_data->e_dkey_ks, get_skey_out.e_dkey_ks,
+  HDCP_2_2_E_DKEY_KS_LEN);
+   memcpy(ske_data->riv, get_skey_out.r_iv, HDCP_2_2_RIV_LEN);
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -419,7 +476,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.store_pairing_info = mei_hdcp_store_pairing_info,
.initiate_locality_check = mei_hdcp_initiate_locality_check,
.verify_lprime = mei_hdcp_verify_lprime,
-   .get_session_key = NULL,
+   .get_session_key = mei_hdcp_get_session_key,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 28/32] misc/mei/hdcp: Verify M_prime

2019-02-15 Thread Ramalingam C
Request to ME to verify the M_Prime received from the HDCP sink.

ME FW will calculate the M and compare with M_prime received
as part of RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.

On successful completion of this stage, downstream propagation of
the stream management info is completed.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  endianness conversion func is moved to drm_hdcp.h [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
  drm_hdcp2_u32_to_seq_num() is used for u32 to seq_num.
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 67 +++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c06a9805ac85..721376fc9bf1 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -540,6 +540,71 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device 
*dev,
return 0;
 }
 
+/**
+ * mei_hdcp_verify_mprime() - Verify mprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @stream_ready: RepeaterAuth_Stream_Ready msg for ME FW verification.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_hdcp_verify_mprime(struct device *dev,
+ struct hdcp_port_data *data,
+ struct hdcp2_rep_stream_ready *stream_ready)
+{
+   struct wired_cmd_repeater_auth_stream_req_in
+   verify_mprime_in = { { 0 } };
+   struct wired_cmd_repeater_auth_stream_req_out
+   verify_mprime_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !stream_ready || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_mprime_in.header.api_version = HDCP_API_VERSION;
+   verify_mprime_in.header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
+   verify_mprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_mprime_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
+
+   verify_mprime_in.port.integrated_port_type = data->port_type;
+   verify_mprime_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
+  HDCP_2_2_MPRIME_LEN);
+   drm_hdcp2_u32_to_seq_num(verify_mprime_in.seq_num_m, data->seq_num_m);
+   memcpy(verify_mprime_in.streams, data->streams,
+  (data->k * sizeof(struct hdcp2_streamid_type)));
+
+   verify_mprime_in.k = __swab16(data->k);
+
+   byte = mei_cldev_send(cldev, (u8 *)_mprime_in,
+ sizeof(verify_mprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_mprime_out,
+ sizeof(verify_mprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_mprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_REPEATER_AUTH_STREAM_REQ,
+   verify_mprime_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -553,7 +618,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.get_session_key = mei_hdcp_get_session_key,
.repeater_check_flow_prepare_ack =
mei_hdcp_repeater_check_flow_prepare_ack,
-   .verify_mprime = NULL,
+   .verify_mprime = mei_hdcp_verify_mprime,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
 };
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 31/32] misc/mei/hdcp: Component framework for I915 Interface

2019-02-15 Thread Ramalingam C
Mei hdcp driver is designed as component slave for the I915 component
master.

v2: Rebased.
v3:
  Notifier chain is adopted for cldev state update [Tomas]
v4:
  Made static dummy functions as inline in mei_hdcp.h
  API for polling client device status
  IS_ENABLED used in header, for config status for mei_hdcp.
v5:
  Replacing the notifier with component framework. [Daniel]
v6:
  Rebased on the I915 comp master redesign.
v7:
  mei_hdcp_component_registered is made static [Uma]
  Need for global static variable mei_cldev is removed.
v8:
  master comp is added to be matched with i915 subcomponent [daniel]
v9:
  only comp_master is set and retrieved as driver_data [Daniel]
  Reviewed-by Daniel.
v10:
  small corrections at probe [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 82 +++-
 1 file changed, 80 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 2afc7d31dacc..ad55b41550d6 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -711,8 +712,7 @@ mei_hdcp_close_session(struct device *dev, struct 
hdcp_port_data *data)
return 0;
 }
 
-static __attribute__((unused))
-struct i915_hdcp_component_ops mei_hdcp_ops = {
+static struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_hdcp_initiate_session,
.verify_receiver_cert_prepare_km =
@@ -729,20 +729,98 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.close_hdcp_session = mei_hdcp_close_session,
 };
 
+static int mei_component_master_bind(struct device *dev)
+{
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct i915_hdcp_comp_master *comp_master =
+   mei_cldev_get_drvdata(cldev);
+   int ret;
+
+   dev_info(dev, "%s\n", __func__);
+   comp_master->ops = _hdcp_ops;
+   comp_master->mei_dev = dev;
+   ret = component_bind_all(dev, comp_master);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static void mei_component_master_unbind(struct device *dev)
+{
+   struct mei_cl_device *cldev = to_mei_cl_device(dev);
+   struct i915_hdcp_comp_master *comp_master =
+   mei_cldev_get_drvdata(cldev);
+
+   dev_info(dev, "%s\n", __func__);
+   component_unbind_all(dev, comp_master);
+}
+
+static const struct component_master_ops mei_component_master_ops = {
+   .bind = mei_component_master_bind,
+   .unbind = mei_component_master_unbind,
+};
+
+static int mei_hdcp_component_match(struct device *dev, int subcomponent,
+   void *data)
+{
+   return !strcmp(dev->driver->name, "i915") &&
+  subcomponent == I915_COMPONENT_HDCP;
+}
+
 static int mei_hdcp_probe(struct mei_cl_device *cldev,
  const struct mei_cl_device_id *id)
 {
+   struct i915_hdcp_comp_master *comp_master;
+   struct component_match *master_match;
int ret;
 
ret = mei_cldev_enable(cldev);
if (ret < 0)
dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
 
+   comp_master = kzalloc(sizeof(*comp_master), GFP_KERNEL);
+   if (!comp_master) {
+   ret = -ENOMEM;
+   goto err_exit;
+   }
+
+   master_match = NULL;
+   component_match_add_typed(>dev, _match,
+ mei_hdcp_component_match, comp_master);
+   if (IS_ERR_OR_NULL(master_match)) {
+   ret = -ENOMEM;
+   goto err_exit;
+   }
+
+   mei_cldev_set_drvdata(cldev, comp_master);
+   ret = component_master_add_with_match(>dev,
+ _component_master_ops,
+ master_match);
+   if (ret < 0) {
+   dev_err(>dev, "Master comp add failed %d\n", ret);
+   goto err_exit;
+   }
+
+   return 0;
+
+err_exit:
+   mei_cldev_set_drvdata(cldev, NULL);
+   kfree(comp_master);
+   mei_cldev_disable(cldev);
+
return ret;
 }
 
 static int mei_hdcp_remove(struct mei_cl_device *cldev)
 {
+   struct i915_hdcp_comp_master *comp_master =
+   mei_cldev_get_drvdata(cldev);
+
+   component_master_del(>dev, _component_master_ops);
+   kfree(comp_master);
+   mei_cldev_set_drvdata(cldev, NULL);
+
return mei_cldev_disable(cldev);
 }
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 24/32] misc/mei/hdcp: Initiate Locality check

2019-02-15 Thread Ramalingam C
Requests ME to start the second stage of HDCP2.2 authentication,
called Locality Check.

On Success, ME FW will provide LC_Init message to send to hdcp sink.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd used for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 57 +++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 1f5514244716..29ef61fd21d2 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -296,6 +296,61 @@ mei_hdcp_store_pairing_info(struct device *dev, struct 
hdcp_port_data *data,
return 0;
 }
 
+/**
+ * mei_hdcp_initiate_locality_check() - Prepare LC_Init
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @lc_init_data: LC_Init msg output
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_hdcp_initiate_locality_check(struct device *dev,
+struct hdcp_port_data *data,
+struct hdcp2_lc_init *lc_init_data)
+{
+   struct wired_cmd_init_locality_check_in lc_init_in = { { 0 } };
+   struct wired_cmd_init_locality_check_out lc_init_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !lc_init_data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   lc_init_in.header.api_version = HDCP_API_VERSION;
+   lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
+   lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
+
+   lc_init_in.port.integrated_port_type = data->port_type;
+   lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   byte = mei_cldev_send(cldev, (u8 *)_init_in, sizeof(lc_init_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_init_out, sizeof(lc_init_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (lc_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. status: 0x%X\n",
+   WIRED_INIT_LOCALITY_CHECK, lc_init_out.header.status);
+   return -EIO;
+   }
+
+   lc_init_data->msg_id = HDCP_2_2_LC_INIT;
+   memcpy(lc_init_data->r_n, lc_init_out.r_n, HDCP_2_2_RN_LEN);
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -304,7 +359,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
mei_hdcp_verify_receiver_cert_prepare_km,
.verify_hprime = mei_hdcp_verify_hprime,
.store_pairing_info = mei_hdcp_store_pairing_info,
-   .initiate_locality_check = NULL,
+   .initiate_locality_check = mei_hdcp_initiate_locality_check,
.verify_lprime = NULL,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 32/32] FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915

2019-02-15 Thread Ramalingam C
FOR TESTING PURPOSE ONLY.

By default INTEL_MEI_HDCP is set to y. This patch is created to
test the interface between I915 and MEI_HDCP.

Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index 64a7b3483895..e5defb2e1557 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -48,5 +48,6 @@ config INTEL_MEI_HDCP
tristate "Intel HDCP2.2 services of ME Interface"
select INTEL_MEI_ME
depends on DRM_I915
+   default y
help
  MEI Support for HDCP2.2 Services on Intel platforms.
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 19/32] misc/mei/hdcp: Define ME FW interface for HDCP2.2

2019-02-15 Thread Ramalingam C
Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.

This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.

v2: Rebased.
v3:
  Extra comments are removed.
v4:
  %s/\/\*\*/\/\*
v5:
  Extra lines are removed.
v6:
  Remove redundant text from the License header
  %s/LPRIME_HALF/V_PRIME_HALF
  %s/uintxx_t/uxx
v7:
  Extra taps removed.

Signed-off-by: Ramalingam C 
Acked-by Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.h | 366 +++
 1 file changed, 366 insertions(+)
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
new file mode 100644
index ..582a7e27ae29
--- /dev/null
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -0,0 +1,366 @@
+/* SPDX-License-Identifier: (GPL-2.0+) */
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Authors:
+ * Ramalingam C 
+ */
+
+#ifndef __MEI_HDCP_H__
+#define __MEI_HDCP_H__
+
+#include 
+
+/* me_hdcp_status: Enumeration of all HDCP Status Codes */
+enum me_hdcp_status {
+   ME_HDCP_STATUS_SUCCESS  = 0x,
+
+   /* WiDi Generic Status Codes */
+   ME_HDCP_STATUS_INTERNAL_ERROR   = 0x1000,
+   ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
+   ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
+   ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
+   ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
+   ME_HDCP_STATUS_INVALID_PARAMS   = 0x1005,
+   ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
+
+   /* WiDi Status Codes */
+   ME_HDCP_INVALID_SESSION_STATE   = 0x6000,
+   ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
+   ME_HDCP_SRM_INVALID_LENGTH  = 0x6002,
+   ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
+   ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
+   ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
+   ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
+   ME_HDCP_RX_REVOKED  = 0x6007,
+   ME_HDCP_H_VERIFICATION_FAILED   = 0x6008,
+   ME_HDCP_REPEATER_CHECK_UNEXPECTED   = 0x6009,
+   ME_HDCP_TOPOLOGY_MAX_EXCEEDED   = 0x600A,
+   ME_HDCP_V_VERIFICATION_FAILED   = 0x600B,
+   ME_HDCP_L_VERIFICATION_FAILED   = 0x600C,
+   ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
+   ME_HDCP_BASE_KEY_RESET_FAILED   = 0x600E,
+   ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
+   ME_HDCP_STATUS_INVALID_E_KEY_STATE  = 0x6010,
+   ME_HDCP_STATUS_INVALID_CS_ICV   = 0x6011,
+   ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
+   ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
+   ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
+   ME_HDCP_STATUS_LC_MAX_ATTEMPTS  = 0x6015,
+
+   /* New status for HDCP 2.1 */
+   ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
+
+   /* New status code for HDCP 2.2 Rx */
+   ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED  = 0x6017,
+   ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
+   ME_HDCP_RX_NEEDS_PROVISIONING   = 0x6019,
+   ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
+   ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
+   ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
+   ME_HDCP_FAIL_NOT_EXPECTED   = 0x6023,
+   ME_HDCP_FAIL_HDCP_OFF   = 0x6024,
+   ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE   = 0x6025,
+   ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
+   ME_HDCP_FEATURE_NOT_SUPPORTED   = 0x6027,
+   ME_HDCP_DMA_READ_ERROR  = 0x6028,
+   ME_HDCP_DMA_WRITE_ERROR = 0x6029,
+   ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
+   ME_HDCP_H264_PARSING_ERROR  = 0x6031,
+   ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
+   ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
+   ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
+   ME_HDCP_MODE_CHANGE_ERROR   = 0x6035,
+   ME_HDCP_STREAM_TYPE_ERROR   = 0x6036,
+   ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE  = 0x6037,
+
+   ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
+   ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
+   ME_HDCP_STATUS_INVALID_PORT_INDEX   = 0x603a,
+   ME_HDCP_STATUS_TX_AUTH_NEEDED   = 0x603b,
+   ME_HDCP_STATUS_NOT_INTEGRATED_PORT  = 0x603c,
+   ME_HDCP_STATUS_SESSION_MAX_REACHED  = 0x603d,
+
+   /* hdcp capable bit is not set in rx_caps(error is unique to DP) */
+   ME_HDCP_STATUS_NOT_HDCP_CAPABLE = 0x6041,
+
+   ME_HDCP_STATUS_INVALID_STREAM_COUNT = 0x6042,
+};
+
+#define HDCP_API_VERSION   0x0001
+
+#define HDCP_M_LEN 

[Intel-gfx] [PATCH v14 30/32] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session

2019-02-15 Thread Ramalingam C
Request the ME to terminate the HDCP2.2 session for a port.

On Success, ME FW will mark the intel port as Deauthenticated and
terminate the wired HDCP2.2 Tx session started due to the cmd
WIRED_INITIATE_HDCP2_SESSION.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style and typos fixed [Uma]
v5:
  Extra line is removed.
v6:
  Collected the Rb-ed by.
  Rebased.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition.[Tomas]
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 55 +++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index d8e04e0621a1..2afc7d31dacc 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -658,6 +658,59 @@ static int mei_hdcp_enable_authentication(struct device 
*dev,
return 0;
 }
 
+/**
+ * mei_hdcp_close_session() - Close the Wired HDCP Tx session of ME FW per 
port.
+ * This also disables the authenticated state of the port.
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_hdcp_close_session(struct device *dev, struct hdcp_port_data *data)
+{
+   struct wired_cmd_close_session_in session_close_in = { { 0 } };
+   struct wired_cmd_close_session_out session_close_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   session_close_in.header.api_version = HDCP_API_VERSION;
+   session_close_in.header.command_id = WIRED_CLOSE_SESSION;
+   session_close_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_close_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_CLOSE_SESSION_IN;
+
+   session_close_in.port.integrated_port_type = data->port_type;
+   session_close_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   byte = mei_cldev_send(cldev, (u8 *)_close_in,
+ sizeof(session_close_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_close_out,
+ sizeof(session_close_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (session_close_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "Session Close Failed. status: 0x%X\n",
+   session_close_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -673,7 +726,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
mei_hdcp_repeater_check_flow_prepare_ack,
.verify_mprime = mei_hdcp_verify_mprime,
.enable_hdcp_authentication = mei_hdcp_enable_authentication,
-   .close_hdcp_session = NULL,
+   .close_hdcp_session = mei_hdcp_close_session,
 };
 
 static int mei_hdcp_probe(struct mei_cl_device *cldev,
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 14/32] drm/i915: CP_IRQ handling for DP HDCP2.2 msgs

2019-02-15 Thread Ramalingam C
Implements the
Waitqueue is created to wait for CP_IRQ
Signaling the CP_IRQ arrival through atomic variable.
For applicable DP HDCP2.2 msgs read wait for CP_IRQ.

As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts
when they are received from HDCP Receivers"

Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted
while reading it based on corresponding status bit. This creates the
random failures in reading the DP HDCP2.2 msgs.

v2:
  CP_IRQ arrival is tracked based on the atomic val inc [daniel]
  Recording the reviewed-by Daniel from IRC.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c   | 31 +++
 drivers/gpu/drm/i915/intel_drv.h  |  8 
 drivers/gpu/drm/i915/intel_hdcp.c | 11 ---
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e9fe25f21200..e1a051c0fbfe 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5623,6 +5623,18 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
 }
 
+static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
+{
+   long ret;
+
+#define C (hdcp->cp_irq_count_cached != atomic_read(>cp_irq_count))
+   ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
+  msecs_to_jiffies(timeout));
+
+   if (!ret)
+   DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
+}
+
 static
 int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5967,14 +5979,13 @@ intel_dp_hdcp2_wait_for_msg(struct intel_digital_port 
*intel_dig_port,
mdelay(timeout);
ret = 0;
} else {
-   /* TODO: In case if you need to wait on CP_IRQ, do it here */
-   ret = __wait_for(ret =
-hdcp2_detect_msg_availability(intel_dig_port,
-  msg_id,
-  _ready),
-!ret && msg_ready, timeout * 1000,
-1000, 5 * 1000);
-
+   /*
+* As we want to check the msg availability at timeout, Ignoring
+* the timeout at wait for CP_IRQ.
+*/
+   intel_dp_hdcp_wait_for_cp_irq(hdcp, timeout);
+   ret = hdcp2_detect_msg_availability(intel_dig_port,
+   msg_id, _ready);
if (!msg_ready)
ret = -ETIMEDOUT;
}
@@ -6001,6 +6012,8 @@ static
 int intel_dp_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
 void *buf, size_t size)
 {
+   struct intel_dp *dp = _dig_port->dp;
+   struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
@@ -6016,6 +6029,8 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port 
*intel_dig_port,
bytes_to_write = size - 1;
byte++;
 
+   hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+
while (bytes_to_write) {
len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dfedcc2b076c..1d1ef7f04f93 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -474,6 +474,14 @@ struct intel_hdcp {
 * over re-Auth has to be triggered.
 */
u32 seq_num_m;
+
+   /*
+* Work queue to signal the CP_IRQ. Used for the waiters to read the
+* available information from HDCP DP sink.
+*/
+   wait_queue_head_t cp_irq_queue;
+   atomic_t cp_irq_count;
+   int cp_irq_count_cached;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index fe0445c0eaac..6178fe93f398 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1806,6 +1806,7 @@ int intel_hdcp_init(struct intel_connector *connector,
 
if (is_hdcp2_supported(dev_priv))
intel_hdcp2_init(connector);
+   init_waitqueue_head(>cp_irq_queue);
 
return 0;
 }
@@ -1935,12 +1936,8 @@ void intel_hdcp_handle_cp_irq(struct intel_connector 
*connector)
if (!hdcp->shim)
return;
 
-   /*
-* CP_IRQ could be triggered due to 1. HDCP2.2 auth msgs availability,
-* 2. link failure and 3. repeater reauth request. At present we dont
-* handle the CP_IRQ for the 

[Intel-gfx] [PATCH v14 12/32] drm/i915: Implement the HDCP2.2 support for DP

2019-02-15 Thread Ramalingam C
Implements the DP adaptation specific HDCP2.2 functions.

These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.

v2:
  wait for cp_irq is merged with this patch. Rebased.
v3:
  wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
  Style fixed.
  %s/PARING/PAIRING
  Few style fixes [Uma]
v5:
  Lookup table for DP HDCP2.2 msg details [Daniel].
  Extra lines are removed.
v6: Rebased.
v7:
  Fixed some regression introduced at v5. [Ankit]
  Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
  Converted a function to inline [Uma]
  %s/uintxx_t/uxx
v8:
  Error due to the sinks are reported as DEBUG logs.
  Adjust to the new mei interface.
v9:
  ARRAY_SIZE for no of array members [Jon & Daniel]
  return of the wait_for_cp_irq is made as void [Daniel]
  Wait for HDCP2.2 msg is done based on polling the reg bit than
CP_IRQ based. [Daniel]
  hdcp adaptation is added as a const in the hdcp_shim [Daniel]
v10:
  config_stream_type is redefined [Daniel]
  DP Errata specific defines are moved into intel_dp.c.

Signed-off-by: Ramalingam C 
Signed-off-by: Ankit K Nautiyal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dp.c | 333 
 1 file changed, 333 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9f73a4239574..e9fe25f21200 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5847,6 +5847,333 @@ int intel_dp_hdcp_capable(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
+struct hdcp2_dp_errata_stream_type {
+   u8  msg_id;
+   u8  stream_type;
+} __packed;
+
+static struct hdcp2_dp_msg_data {
+   u8 msg_id;
+   u32 offset;
+   bool msg_detectable;
+   u32 timeout;
+   u32 timeout2; /* Added for non_paired situation */
+   } hdcp2_msg_data[] = {
+   {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
+   {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
+   false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+   {HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
+   false, 0, 0},
+   {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
+   false, 0, 0},
+   {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
+   true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+   {HDCP_2_2_AKE_SEND_PAIRING_INFO,
+   DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
+   HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
+   {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
+   {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
+   false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
+   {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
+   0, 0},
+   {HDCP_2_2_REP_SEND_RECVID_LIST,
+   DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
+   HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+   {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
+   0, 0},
+   {HDCP_2_2_REP_STREAM_MANAGE,
+   DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
+   0, 0},
+   {HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
+   false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
+/* local define to shovel this through the write_2_2 interface */
+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
+   {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
+   DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
+   0, 0},
+   };
+
+static inline
+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ u8 *rx_status)
+{
+   ssize_t ret;
+
+   ret = drm_dp_dpcd_read(_dig_port->dp.aux,
+  DP_HDCP_2_2_REG_RXSTATUS_OFFSET, rx_status,
+  HDCP_2_2_DP_RXSTATUS_LEN);
+   if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
+   DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+
+   return 0;
+}
+
+static
+int hdcp2_detect_msg_availability(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool *msg_ready)
+{
+   u8 rx_status;
+   int ret;
+
+   *msg_ready = false;
+   ret = intel_dp_hdcp2_read_rx_status(intel_dig_port, _status);
+   if (ret < 0)
+   return ret;
+
+   switch (msg_id) 

[Intel-gfx] [PATCH v14 10/32] drm/i915: Handle HDCP2.2 downstream topology change

2019-02-15 Thread Ramalingam C
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone without disabling the hdcp
encryption. If that fails then complete reauthentication is executed.

v2:
  Rebased.
v3:
  Typo in commit msg is fixed [Uma]
v4:
  Rebased as part of patch reordering.
  Minor style fixes.
v5:
  Rebased.
v6:
  Rebased.
v7:
  Errors due to sinks are reported as DEBUG logs.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 00fae3963caf..fe0445c0eaac 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1626,8 +1626,24 @@ static int intel_hdcp2_check_link(struct intel_connector 
*connector)
goto out;
}
 
-   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
- connector->base.name, connector->base.base.id);
+   if (ret == HDCP_TOPOLOGY_CHANGE) {
+   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   goto out;
+
+   DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
+   ret = hdcp2_authenticate_repeater_topology(connector);
+   if (!ret) {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+   DRM_DEBUG_KMS("[%s:%d] Repeater topology auth failed.(%d)\n",
+ connector->base.name, connector->base.base.id,
+ ret);
+   } else {
+   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+   }
 
ret = _intel_hdcp2_disable(connector);
if (ret) {
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 16/32] mei: bus: whitelist hdcp client

2019-02-15 Thread Ramalingam C
From: Tomas Winkler 

Whitelist HDCP client for in kernel drm use

v2:
  Rebased.

Signed-off-by: Tomas Winkler 
Signed-off-by: Ramalingam C 
---
 drivers/misc/mei/bus-fixup.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 80215c312f0e..5fcac02233af 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -40,6 +40,9 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
 #define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
 
+#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, \
+ 0xA5, 0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
+
 #define MEI_UUID_ANY NULL_UUID_LE
 
 /**
@@ -71,6 +74,18 @@ static void blacklist(struct mei_cl_device *cldev)
cldev->do_match = 0;
 }
 
+/**
+ * whitelist - forcefully whitelist client
+ *
+ * @cldev: me clients device
+ */
+static void whitelist(struct mei_cl_device *cldev)
+{
+   dev_dbg(>dev, "running hook %s\n", __func__);
+
+   cldev->do_match = 1;
+}
+
 #define OSTYPE_LINUX2
 struct mei_os_ver {
__le16 build;
@@ -472,6 +487,7 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_NFC_HCI, mei_nfc),
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+   MEI_FIXUP(MEI_UUID_HDCP, whitelist),
 };
 
 /**
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 08/32] drm: HDCP2.2 link check period

2019-02-15 Thread Ramalingam C
Time period for HDCP2.2 link check.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
 include/drm/drm_hdcp.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 7260b31af276..d4e98b11b4aa 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -13,6 +13,7 @@
 
 /* Period of hdcp checks (to ensure we're still authenticated) */
 #define DRM_HDCP_CHECK_PERIOD_MS   (128 * 16)
+#define DRM_HDCP2_CHECK_PERIOD_MS  500
 
 /* Shared lengths/masks between HDMI/DVI/DisplayPort */
 #define DRM_HDCP_AN_LEN8
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 11/32] drm: removing the DP Errata msg and its msg id

2019-02-15 Thread Ramalingam C
Since DP ERRATA message is not defined at spec, those structure
definition is removed from drm_hdcp.h

Signed-off-by: Ramalingam C 
Suggested-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
 include/drm/drm_hdcp.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index d4e98b11b4aa..f243408ecf26 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -69,7 +69,6 @@
 #define HDCP_2_2_REP_SEND_ACK  15
 #define HDCP_2_2_REP_STREAM_MANAGE 16
 #define HDCP_2_2_REP_STREAM_READY  17
-#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
 
 #define HDCP_2_2_RTX_LEN   8
 #define HDCP_2_2_RRX_LEN   8
@@ -220,11 +219,6 @@ struct hdcp2_rep_stream_ready {
u8  m_prime[HDCP_2_2_MPRIME_LEN];
 } __packed;
 
-struct hdcp2_dp_errata_stream_type {
-   u8  msg_id;
-   u8  stream_type;
-} __packed;
-
 /* HDCP2.2 TIMEOUTs in mSec */
 #define HDCP_2_2_CERT_TIMEOUT_MS   100
 #define HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS   1000
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 15/32] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

2019-02-15 Thread Ramalingam C
HDCP transmitter is supposed to indicate the HDCP encryption status of
the link through enc_en signals in a window of time called "window of
opportunity" defined by HDCP HDMI spec.

But on KBL this timing of signalling has an issue. To fix the issue this
WA of resetting the signalling is required.

v2:
  WA is moved into the toggle_signalling [Daniel]
v3:
  Commit msg is rewritten with more information
v4:
  Reviewed-by Daniel.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6a3e400f54d7..c2c91e6645a5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct 
intel_digital_port *intel_dig_port,
return ret;
 }
 
+static int kbl_repositioning_enc_en_signal(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_crtc *crtc = connector->base.state->crtc;
+   struct intel_crtc *intel_crtc = container_of(crtc,
+struct intel_crtc, base);
+   u32 scanline;
+   int ret;
+
+   for (;;) {
+   scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
+   if (scanline > 100 && scanline < 200)
+   break;
+   usleep_range(25, 50);
+   }
+
+   ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, false);
+   if (ret) {
+   DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
+   return ret;
+   }
+   ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, true);
+   if (ret) {
+   DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static
 int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port 
*intel_dig_port,
  bool enable)
 {
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct intel_connector *connector = hdmi->attached_connector;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
int ret;
 
if (!enable)
@@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct 
intel_digital_port *intel_dig_port,
  enable ? "Enable" : "Disable", ret);
return ret;
}
+
+   /*
+* WA: To fix incorrect positioning of the window of
+* opportunity and enc_en signalling in KABYLAKE.
+*/
+   if (IS_KABYLAKE(dev_priv) && enable)
+   return kbl_repositioning_enc_en_signal(connector);
+
return 0;
 }
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 20/32] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

2019-02-15 Thread Ramalingam C
Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to ME FW.

On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.

v2: Rebased.
v3:
  cldev is add as a separate parameter [Tomas]
  Redundant comment and typecast are removed [Tomas]
v4:
  %zd is used for size [Alexander]
  %s/return -1/return -EIO [Alexander]
  Spellings in commit msg is fixed [Uma]
v5: Rebased.
v6:
  Collected the rb-ed by.
  Realigning the patches in the series.
v7:
  Adjust to the new mei interface.
  Fix for kdoc.
v8:
  K-Doc Addition.
  memcpy for const length.
v9:
  s/mei_hdcp_ddi/mei_fw_ddi
  s/i915_port/mei_i915_port [Tomas]
  renamed func as mei_hdcp_* [Tomas]
  Instead of macro, inline func for ddi index is used. [Tomas]
v10:
  Switch case for the coversion between i915_port to mei_ddi [Tomas]
  Kernel doc fix.

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 94 
 drivers/misc/mei/hdcp/mei_hdcp.h | 11 +
 2 files changed, 105 insertions(+)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 8df069c1b0cc..952bae79dd02 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,100 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+
+#include "mei_hdcp.h"
+
+static inline u8 mei_get_ddi_index(enum port port)
+{
+   switch (port) {
+   case PORT_A:
+   return MEI_DDI_A;
+   case PORT_B ... PORT_F:
+   return (u8)port;
+   default:
+   return MEI_DDI_INVALID_PORT;
+   }
+}
+
+/**
+ * mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @ake_data: AKE_Init msg output.
+ *
+ * Return:  0 on Success, <0 on Failure.
+ */
+static int
+mei_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
+ struct hdcp2_ake_init *ake_data)
+{
+   struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
+   struct wired_cmd_initiate_hdcp2_session_out
+   session_init_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !ake_data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   session_init_in.header.api_version = HDCP_API_VERSION;
+   session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
+   session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   session_init_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
+
+   session_init_in.port.integrated_port_type = data->port_type;
+   session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+   session_init_in.protocol = data->protocol;
+
+   byte = mei_cldev_send(cldev, (u8 *)_init_in,
+ sizeof(session_init_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_init_out,
+ sizeof(session_init_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+   WIRED_INITIATE_HDCP2_SESSION,
+   session_init_out.header.status);
+   return -EIO;
+   }
+
+   ake_data->msg_id = HDCP_2_2_AKE_INIT;
+   ake_data->tx_caps = session_init_out.tx_caps;
+   memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
+
+   return 0;
+}
+
+static __attribute__((unused))
+struct i915_hdcp_component_ops mei_hdcp_ops = {
+   .owner = THIS_MODULE,
+   .initiate_hdcp2_session = mei_hdcp_initiate_session,
+   .verify_receiver_cert_prepare_km = NULL,
+   .verify_hprime = NULL,
+   .store_pairing_info = NULL,
+   .initiate_locality_check = NULL,
+   .verify_lprime = NULL,
+   .get_session_key = NULL,
+   .repeater_check_flow_prepare_ack = NULL,
+   .verify_mprime = NULL,
+   .enable_hdcp_authentication = NULL,
+   .close_hdcp_session = NULL,
+};
 
 static int mei_hdcp_probe(struct mei_cl_device *cldev,
  const struct mei_cl_device_id *id)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
index 582a7e27ae29..1eca72a9c1c2 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.h
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -363,4 +363,15 @@ struct wired_cmd_repeater_auth_stream_req_out {
   

[Intel-gfx] [PATCH v14 13/32] drm/i915: Implement the HDCP2.2 support for HDMI

2019-02-15 Thread Ramalingam C
Implements the HDMI adaptation specific HDCP2.2 operations.

Basically these are DDC read and write for authenticating through
HDCP2.2 messages.

v2: Rebased.
v3:
  No more special handling of Gmbus burst read for AKE_SEND_CERT.
  Style fixed with few naming. [Uma]
  %s/PARING/PAIRING
v4:
  msg_sz is initialized at definition.
  Lookup table is defined for HDMI HDCP2.2 msgs [Daniel].
v5: Rebased.
v6:
  Make a function as inline [Uma]
  %s/uintxx_t/uxx
v7:
  Errors due to sinks are reported as DEBUG logs.
  Adjust to the new mei interface.
v8:
  ARRAY_SIZE for the # of array members [Jon & Daniel].
  hdcp adaptation is added as a const in the hdcp_shim [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 189 ++
 1 file changed, 189 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index faeedf76db99..6a3e400f54d7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1129,6 +1129,190 @@ bool intel_hdmi_hdcp_check_link(struct 
intel_digital_port *intel_dig_port)
return true;
 }
 
+static struct hdcp2_hdmi_msg_data {
+   u8 msg_id;
+   u32 timeout;
+   u32 timeout2;
+   } hdcp2_msg_data[] = {
+   {HDCP_2_2_AKE_INIT, 0, 0},
+   {HDCP_2_2_AKE_SEND_CERT, HDCP_2_2_CERT_TIMEOUT_MS, 0},
+   {HDCP_2_2_AKE_NO_STORED_KM, 0, 0},
+   {HDCP_2_2_AKE_STORED_KM, 0, 0},
+   {HDCP_2_2_AKE_SEND_HPRIME, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
+   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
+   {HDCP_2_2_AKE_SEND_PAIRING_INFO, HDCP_2_2_PAIRING_TIMEOUT_MS,
+   0},
+   {HDCP_2_2_LC_INIT, 0, 0},
+   {HDCP_2_2_LC_SEND_LPRIME, HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS, 0},
+   {HDCP_2_2_SKE_SEND_EKS, 0, 0},
+   {HDCP_2_2_REP_SEND_RECVID_LIST,
+   HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
+   {HDCP_2_2_REP_SEND_ACK, 0, 0},
+   {HDCP_2_2_REP_STREAM_MANAGE, 0, 0},
+   {HDCP_2_2_REP_STREAM_READY, HDCP_2_2_STREAM_READY_TIMEOUT_MS,
+   0},
+   };
+
+static
+int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+   uint8_t *rx_status)
+{
+   return intel_hdmi_hdcp_read(intel_dig_port,
+   HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
+   rx_status,
+   HDCP_2_2_HDMI_RXSTATUS_LEN);
+}
+
+static int get_hdcp2_msg_timeout(u8 msg_id, bool is_paired)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(hdcp2_msg_data); i++)
+   if (hdcp2_msg_data[i].msg_id == msg_id &&
+   (msg_id != HDCP_2_2_AKE_SEND_HPRIME || is_paired))
+   return hdcp2_msg_data[i].timeout;
+   else if (hdcp2_msg_data[i].msg_id == msg_id)
+   return hdcp2_msg_data[i].timeout2;
+
+   return -EINVAL;
+}
+
+static inline
+int hdcp2_detect_msg_availability(struct intel_digital_port 
*intel_digital_port,
+ u8 msg_id, bool *msg_ready,
+ ssize_t *msg_sz)
+{
+   u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
+   int ret;
+
+   ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
+   if (ret < 0) {
+   DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
+   return ret;
+   }
+
+   *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
+ rx_status[0]);
+
+   if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
+   *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
+*msg_sz);
+   else
+   *msg_ready = *msg_sz;
+
+   return 0;
+}
+
+static ssize_t
+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, bool paired)
+{
+   bool msg_ready = false;
+   int timeout, ret;
+   ssize_t msg_sz = 0;
+
+   timeout = get_hdcp2_msg_timeout(msg_id, paired);
+   if (timeout < 0)
+   return timeout;
+
+   ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
+msg_id, _ready,
+_sz),
+!ret && msg_ready && msg_sz, timeout * 1000,
+1000, 5 * 1000);
+   if (ret)
+   DRM_DEBUG_KMS("msg_id: %d, ret: %d, timeout: %d\n",
+ msg_id, ret, timeout);
+
+   return ret ? ret : msg_sz;
+}
+
+static
+int intel_hdmi_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+  void *buf, 

[Intel-gfx] [PATCH v14 29/32] misc/mei/hdcp: Enabling the HDCP authentication

2019-02-15 Thread Ramalingam C
Request to ME to configure a port as authenticated.

On Success, ME FW will mark the port as authenticated and provides
HDCP cipher with the encryption keys.

Enabling the Authentication can be requested once all stages of
HDCP2.2 authentication is completed by interacting with ME FW.

Only after this stage, driver can enable the HDCP encryption for
the port, through HW registers.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style and typos fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebased.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 55 +++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 721376fc9bf1..d8e04e0621a1 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -605,6 +605,59 @@ static int mei_hdcp_verify_mprime(struct device *dev,
return 0;
 }
 
+/**
+ * mei_hdcp_enable_authentication() - Mark a port as authenticated
+ * through ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int mei_hdcp_enable_authentication(struct device *dev,
+ struct hdcp_port_data *data)
+{
+   struct wired_cmd_enable_auth_in enable_auth_in = { { 0 } };
+   struct wired_cmd_enable_auth_out enable_auth_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   enable_auth_in.header.api_version = HDCP_API_VERSION;
+   enable_auth_in.header.command_id = WIRED_ENABLE_AUTH;
+   enable_auth_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   enable_auth_in.header.buffer_len = WIRED_CMD_BUF_LEN_ENABLE_AUTH_IN;
+
+   enable_auth_in.port.integrated_port_type = data->port_type;
+   enable_auth_in.port.physical_port = mei_get_ddi_index(data->port);
+   enable_auth_in.stream_type = data->streams[0].stream_type;
+
+   byte = mei_cldev_send(cldev, (u8 *)_auth_in,
+ sizeof(enable_auth_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_auth_out,
+ sizeof(enable_auth_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (enable_auth_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_ENABLE_AUTH, enable_auth_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -619,7 +672,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.repeater_check_flow_prepare_ack =
mei_hdcp_repeater_check_flow_prepare_ack,
.verify_mprime = mei_hdcp_verify_mprime,
-   .enable_hdcp_authentication = NULL,
+   .enable_hdcp_authentication = mei_hdcp_enable_authentication,
.close_hdcp_session = NULL,
 };
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 25/32] misc/mei/hdcp: Verify L_prime

2019-02-15 Thread Ramalingam C
Request to ME to verify the LPrime received from HDCP sink.

On Success, ME FW will verify the received Lprime by calculating and
comparing with L.

This represents the completion of Locality Check.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style fixed [Uma]
v5: Rebased.
v6:
  Collected the Rb-ed by.
  Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
  memcpy for const length.
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 60 +++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 29ef61fd21d2..869a6f22f68d 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -351,6 +351,64 @@ mei_hdcp_initiate_locality_check(struct device *dev,
return 0;
 }
 
+/**
+ * mei_hdcp_verify_lprime() - Verify lprime.
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @rx_lprime: LC_Send_L_prime msg for ME FW verification
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_hdcp_verify_lprime(struct device *dev, struct hdcp_port_data *data,
+  struct hdcp2_lc_send_lprime *rx_lprime)
+{
+   struct wired_cmd_validate_locality_in verify_lprime_in = { { 0 } };
+   struct wired_cmd_validate_locality_out verify_lprime_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !data || !rx_lprime)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_lprime_in.header.api_version = HDCP_API_VERSION;
+   verify_lprime_in.header.command_id = WIRED_VALIDATE_LOCALITY;
+   verify_lprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_lprime_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VALIDATE_LOCALITY_IN;
+
+   verify_lprime_in.port.integrated_port_type = data->port_type;
+   verify_lprime_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
+  HDCP_2_2_L_PRIME_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_lprime_in,
+ sizeof(verify_lprime_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_lprime_out,
+ sizeof(verify_lprime_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_lprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VALIDATE_LOCALITY,
+   verify_lprime_out.header.status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -360,7 +418,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.verify_hprime = mei_hdcp_verify_hprime,
.store_pairing_info = mei_hdcp_store_pairing_info,
.initiate_locality_check = mei_hdcp_initiate_locality_check,
-   .verify_lprime = NULL,
+   .verify_lprime = mei_hdcp_verify_lprime,
.get_session_key = NULL,
.repeater_check_flow_prepare_ack = NULL,
.verify_mprime = NULL,
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 27/32] misc/mei/hdcp: Repeater topology verification and ack

2019-02-15 Thread Ramalingam C
Request ME to verify the downstream topology information received.

ME FW will validate the Repeaters receiver id list and
downstream topology.

On Success ME FW will provide the Least Significant
128bits of VPrime, which forms the repeater ack.

v2: Rebased.
v3:
  cldev is passed as first parameter [Tomas]
  Redundant comments and cast are removed [Tomas]
v4:
  %zd for ssize_t [Alexander]
  %s/return -1/return -EIO [Alexander]
  Style and typos fixed [Uma]
v5: Rebased.
v6: Rebasing.
v7:
  Adjust to the new mei interface.
  Fix for Kdoc.
v8:
  K-Doc addition. [Tomas]
v9:
  renamed func as mei_hdcp_* [Tomas]
  Inline function is defined for DDI index [Tomas]
v10:
  K-Doc fix. [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
Acked-by: Tomas Winkler 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 77 +++-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index fe5070f901e8..c06a9805ac85 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -466,6 +466,80 @@ static int mei_hdcp_get_session_key(struct device *dev,
return 0;
 }
 
+/**
+ * mei_hdcp_repeater_check_flow_prepare_ack() - Validate the Downstream 
topology
+ * and prepare rep_ack.
+ * @dev: device corresponding to the mei_cl_device
+ * @data: Intel HW specific hdcp data
+ * @rep_topology: Receiver ID List to be validated
+ * @rep_send_ack : repeater ack from ME FW.
+ *
+ * Return: 0 on Success, <0 on Failure
+ */
+static int
+mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
+struct hdcp_port_data *data,
+struct hdcp2_rep_send_receiverid_list
+   *rep_topology,
+struct hdcp2_rep_send_ack
+   *rep_send_ack)
+{
+   struct wired_cmd_verify_repeater_in verify_repeater_in = { { 0 } };
+   struct wired_cmd_verify_repeater_out verify_repeater_out = { { 0 } };
+   struct mei_cl_device *cldev;
+   ssize_t byte;
+
+   if (!dev || !rep_topology || !rep_send_ack || !data)
+   return -EINVAL;
+
+   cldev = to_mei_cl_device(dev);
+
+   verify_repeater_in.header.api_version = HDCP_API_VERSION;
+   verify_repeater_in.header.command_id = WIRED_VERIFY_REPEATER;
+   verify_repeater_in.header.status = ME_HDCP_STATUS_SUCCESS;
+   verify_repeater_in.header.buffer_len =
+   WIRED_CMD_BUF_LEN_VERIFY_REPEATER_IN;
+
+   verify_repeater_in.port.integrated_port_type = data->port_type;
+   verify_repeater_in.port.physical_port = mei_get_ddi_index(data->port);
+
+   memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
+  HDCP_2_2_RXINFO_LEN);
+   memcpy(verify_repeater_in.seq_num_v, rep_topology->seq_num_v,
+  HDCP_2_2_SEQ_NUM_LEN);
+   memcpy(verify_repeater_in.v_prime, rep_topology->v_prime,
+  HDCP_2_2_V_PRIME_HALF_LEN);
+   memcpy(verify_repeater_in.receiver_ids, rep_topology->receiver_ids,
+  HDCP_2_2_RECEIVER_IDS_MAX_LEN);
+
+   byte = mei_cldev_send(cldev, (u8 *)_repeater_in,
+ sizeof(verify_repeater_in));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+   return byte;
+   }
+
+   byte = mei_cldev_recv(cldev, (u8 *)_repeater_out,
+ sizeof(verify_repeater_out));
+   if (byte < 0) {
+   dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+   return byte;
+   }
+
+   if (verify_repeater_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+   dev_dbg(dev, "ME cmd 0x%08X failed. status: 0x%X\n",
+   WIRED_VERIFY_REPEATER,
+   verify_repeater_out.header.status);
+   return -EIO;
+   }
+
+   memcpy(rep_send_ack->v, verify_repeater_out.v,
+  HDCP_2_2_V_PRIME_HALF_LEN);
+   rep_send_ack->msg_id = HDCP_2_2_REP_SEND_ACK;
+
+   return 0;
+}
+
 static __attribute__((unused))
 struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
@@ -477,7 +551,8 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.initiate_locality_check = mei_hdcp_initiate_locality_check,
.verify_lprime = mei_hdcp_verify_lprime,
.get_session_key = mei_hdcp_get_session_key,
-   .repeater_check_flow_prepare_ack = NULL,
+   .repeater_check_flow_prepare_ack =
+   mei_hdcp_repeater_check_flow_prepare_ack,
.verify_mprime = NULL,
.enable_hdcp_authentication = NULL,
.close_hdcp_session = NULL,
-- 
2.7.4

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

[Intel-gfx] [PATCH v14 07/32] drm/i915: Implement HDCP2.2 repeater authentication

2019-02-15 Thread Ramalingam C
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.

v2: Rebased.
v3:
  -EINVAL is returned for topology error and rollover scenario.
  Endianness conversion func from drm_hdcp.h is used [Uma]
v4:
  Rebased as part of patches reordering.
  Defined the mei service functions [Daniel]
v5:
  Redefined the mei service functions as per comp redesign.
v6:
  %s/uintxx_t/uxx
  Check for comp_master is removed.
v7:
  Adjust to the new mei interface.
  style issue fixed.
v8:
  drm_hdcp.h change is moved into separate patch [Daniel]
v9:
  %s/__swab16/cpu_to_be16. [Tomas]
  Reviewed-by Uma.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 125 +-
 1 file changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index d63f620581ad..24051120d3bb 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1041,7 +1041,7 @@ static int hdcp2_prepare_skey(struct intel_connector 
*connector,
return ret;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_verify_rep_topology_prepare_ack(struct intel_connector *connector,
  struct hdcp2_rep_send_receiverid_list
*rep_topology,
@@ -1070,7 +1070,7 @@ hdcp2_verify_rep_topology_prepare_ack(struct 
intel_connector *connector,
return ret;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_verify_mprime(struct intel_connector *connector,
struct hdcp2_rep_stream_ready *stream_ready)
 {
@@ -1279,6 +1279,119 @@ static int hdcp2_session_key_exchange(struct 
intel_connector *connector)
return 0;
 }
 
+static
+int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   union {
+   struct hdcp2_rep_stream_manage stream_manage;
+   struct hdcp2_rep_stream_ready stream_ready;
+   } msgs;
+   const struct intel_hdcp_shim *shim = hdcp->shim;
+   int ret;
+
+   /* Prepare RepeaterAuth_Stream_Manage msg */
+   msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
+   drm_hdcp2_u32_to_seq_num(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
+
+   /* K no of streams is fixed as 1. Stored as big-endian. */
+   msgs.stream_manage.k = cpu_to_be16(1);
+
+   /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+   msgs.stream_manage.streams[0].stream_id = 0;
+   msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
+
+   /* Send it to Repeater */
+   ret = shim->write_2_2_msg(intel_dig_port, _manage,
+ sizeof(msgs.stream_manage));
+   if (ret < 0)
+   return ret;
+
+   ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_STREAM_READY,
+_ready, sizeof(msgs.stream_ready));
+   if (ret < 0)
+   return ret;
+
+   hdcp->port_data.seq_num_m = hdcp->seq_num_m;
+   hdcp->port_data.streams[0].stream_type = hdcp->content_type;
+
+   ret = hdcp2_verify_mprime(connector, _ready);
+   if (ret < 0)
+   return ret;
+
+   hdcp->seq_num_m++;
+
+   if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+   DRM_DEBUG_KMS("seq_num_m roll over.\n");
+   return -1;
+   }
+
+   return 0;
+}
+
+static
+int hdcp2_authenticate_repeater_topology(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   union {
+   struct hdcp2_rep_send_receiverid_list recvid_list;
+   struct hdcp2_rep_send_ack rep_ack;
+   } msgs;
+   const struct intel_hdcp_shim *shim = hdcp->shim;
+   u8 *rx_info;
+   u32 seq_num_v;
+   int ret;
+
+   ret = shim->read_2_2_msg(intel_dig_port, HDCP_2_2_REP_SEND_RECVID_LIST,
+_list, sizeof(msgs.recvid_list));
+   if (ret < 0)
+   return ret;
+
+   rx_info = msgs.recvid_list.rx_info;
+
+   if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
+   HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
+   DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
+   return -EINVAL;
+   }
+
+   /* Converting and Storing the seq_num_v to local variable as DWORD */
+   seq_num_v = drm_hdcp2_seq_num_to_u32(msgs.recvid_list.seq_num_v);
+
+   if (seq_num_v < hdcp->seq_num_v) {
+   /* Roll over of the seq_num_v from repeater. Reauthenticate. */
+   DRM_DEBUG_KMS("Seq_num_v roll over.\n");
+   return 

[Intel-gfx] [PATCH v14 00/32] drm/i915: Implement HDCP2.2

2019-02-15 Thread Ramalingam C
This series enables the HDCP2.2 Type 0 for I915. The sequence for
HDCP2.2 authentication and encryption is implemented as a generic flow
between HDMI and DP. Encoder specific implementations are moved
into hdcp_shim.

Intel HWs supports HDCP2.2 through ME FW. Hence this series
introduces a client driver for mei bus, so that for HDCP2.2
authentication, HDCP2.2 stack in I915 can avail the services from
ME FW. To enable this client driver set the config variable
CONFIG_INTEL_MEI_HDCP.

Userspace interface remains unchanged as version agnostic. When
userspace request for HDCP enable, Kernel will detect the HDCP source
and sink's HDCP version(1.4/2.2)capability and enable the best capable
version for that combination.

This series enables the HDCP2.2 for Type0 content streams.

Test-with: <1549566452-30175-1-git-send-email-ramalinga...@intel.com>

Major changes in v14
  - enum port is moved into the drm/i915_drm.h
  - Small fixes for mei_hdcp Kernel-Doc
  - ICL device ID patch is already merged. So dropped it.
  - Couple of patches are merged already. So dropped them.

To ease the review process, series is hosted at
https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v14_rebased

Ramalingam C (30):
  drm/i915: Gathering the HDCP1.4 routines together
  drm/i915: Initialize HDCP2.2
  drm/i915: MEI interface implementation
  drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
  drm/i915: Enable and Disable of HDCP2.2
  drm/i915: Implement HDCP2.2 receiver authentication
  drm/i915: Implement HDCP2.2 repeater authentication
  drm: HDCP2.2 link check period
  drm/i915: Implement HDCP2.2 link integrity check
  drm/i915: Handle HDCP2.2 downstream topology change
  drm: removing the DP Errata msg and its msg id
  drm/i915: Implement the HDCP2.2 support for DP
  drm/i915: Implement the HDCP2.2 support for HDMI
  drm/i915: CP_IRQ handling for DP HDCP2.2 msgs
  drm/i915: Fix KBL HDCP2.2 encrypt status signalling
  misc/mei/hdcp: Client driver for HDCP application
  misc/mei/hdcp: Define ME FW interface for HDCP2.2
  misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
  misc/mei/hdcp: Verify Receiver Cert and prepare km
  misc/mei/hdcp: Verify H_prime
  misc/mei/hdcp: Store the HDCP Pairing info
  misc/mei/hdcp: Initiate Locality check
  misc/mei/hdcp: Verify L_prime
  misc/mei/hdcp: Prepare Session Key
  misc/mei/hdcp: Repeater topology verification and ack
  misc/mei/hdcp: Verify M_prime
  misc/mei/hdcp: Enabling the HDCP authentication
  misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
  misc/mei/hdcp: Component framework for I915 Interface
  FOR_TEST_ONLY: i915/Kconfig: Select mei_hdcp by I915

Tomas Winkler (2):
  mei: bus: whitelist hdcp client
  mei: bus: export to_mei_cl_device for mei client device drivers

 drivers/gpu/drm/i915/i915_drv.c|1 +
 drivers/gpu/drm/i915/i915_drv.h|7 +
 drivers/gpu/drm/i915/intel_connector.c |2 +
 drivers/gpu/drm/i915/intel_display.c   |4 +
 drivers/gpu/drm/i915/intel_dp.c|  350 -
 drivers/gpu/drm/i915/intel_drv.h   |   83 ++-
 drivers/gpu/drm/i915/intel_hdcp.c  | 1242 +---
 drivers/gpu/drm/i915/intel_hdmi.c  |  237 +-
 drivers/misc/mei/Kconfig   |8 +
 drivers/misc/mei/Makefile  |2 +
 drivers/misc/mei/bus-fixup.c   |   16 +
 drivers/misc/mei/bus.c |1 -
 drivers/misc/mei/hdcp/Makefile |7 +
 drivers/misc/mei/hdcp/mei_hdcp.c   |  847 ++
 drivers/misc/mei/hdcp/mei_hdcp.h   |  377 ++
 include/drm/drm_hdcp.h |7 +-
 include/linux/mei_cl_bus.h |2 +
 17 files changed, 3068 insertions(+), 125 deletions(-)
 create mode 100644 drivers/misc/mei/hdcp/Makefile
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.c
 create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h

-- 
2.7.4

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

[Intel-gfx] [PATCH v14 04/32] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

2019-02-15 Thread Ramalingam C
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.

On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in hdcp_check_link.
CP_IRQ corresponding to the authentication msg availability are ignored.

WARN_ON is added for the abrupt stop of HDCP encryption of a port.

v2:
  bool is used in struct for the cleaner coding. [Daniel]
  check_link work_fn is scheduled for cp_irq handling [Daniel]
v3:
  rebased.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dp.c   |  2 +-
 drivers/gpu/drm/i915/intel_drv.h  |  5 ++-
 drivers/gpu/drm/i915/intel_hdcp.c | 73 ---
 3 files changed, 58 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cf709835fb9a..9f73a4239574 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4780,7 +4780,7 @@ static void intel_dp_check_service_irq(struct intel_dp 
*intel_dp)
intel_dp_handle_test_request(intel_dp);
 
if (val & DP_CP_IRQ)
-   intel_hdcp_check_link(intel_dp->attached_connector);
+   intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
 
if (val & DP_SINK_SPECIFIC_IRQ)
DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f8e8482573c8..df2c88877480 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -409,6 +409,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;
 
+   /* HDCP1.4 Encryption status */
+   bool hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
@@ -2090,12 +2093,12 @@ int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *hdcp_shim);
 int intel_hdcp_enable(struct intel_connector *connector);
 int intel_hdcp_disable(struct intel_connector *connector);
-int intel_hdcp_check_link(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 bool intel_hdcp_capable(struct intel_connector *connector);
 void intel_hdcp_component_init(struct drm_i915_private *dev_priv);
 void intel_hdcp_component_fini(struct drm_i915_private *dev_priv);
 void intel_hdcp_cleanup(struct intel_connector *connector);
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
 
 /* intel_psr.c */
 #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index d06bef9d1ab2..66e3850a57a0 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
 }
 
+static inline bool intel_hdcp_in_use(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   enum port port = connector->encoder->port;
+   u32 reg;
+
+   reg = I915_READ(PORT_HDCP_STATUS(port));
+   return reg & HDCP_STATUS_ENC;
+}
+
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
 {
@@ -668,6 +678,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
  connector->base.name, connector->base.base.id);
 
+   hdcp->hdcp_encrypted = false;
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
@@ -713,8 +724,10 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
-   if (!ret)
+   if (!ret) {
+   hdcp->hdcp_encrypted = true;
return 0;
+   }
 
DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
 
@@ -741,16 +754,17 @@ int intel_hdcp_check_link(struct intel_connector 
*connector)
enum port port = intel_dig_port->base.port;
int ret = 0;
 
-   if (!hdcp->shim)
-   return -ENOENT;
-
mutex_lock(>mutex);
 
-   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   /* Check_link valid only when HDCP1.4 is enabled 

[Intel-gfx] [PATCH v14 06/32] drm/i915: Implement HDCP2.2 receiver authentication

2019-02-15 Thread Ramalingam C
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.

At AKE, the HDCP Receiver’s public key certificate is verified by the
HDCP Transmitter. A Master Key k m is exchanged.

At LC, the HDCP Transmitter enforces locality on the content by
requiring that the Round Trip Time (RTT) between a pair of messages
is not more than 20 ms.

At SKE, The HDCP Transmitter exchanges Session Key ks with
the HDCP Receiver.

In DP HDCP2.2 encryption and decryption logics use the stream type as
one of the parameter. So Before enabling the Encryption DP HDCP2.2
receiver needs to be communicated with stream type. This is added to
spec as ERRATA.

This generic implementation is complete only with the hdcp2 specific
functions defined at hdcp_shim.

v2: Rebased.
v3:
  %s/PARING/PAIRING
  Coding style fixing [Uma]
v4:
  Rebased as part of patch reordering.
  Defined the functions for mei services. [Daniel]
v5:
  Redefined the mei service functions as per comp redesign.
  Required intel_hdcp members are defined [Sean Paul]
v6:
  Typo of cipher is Fixed [Uma]
  %s/uintxx_t/uxx
  Check for comp_master is removed.
v7:
  Adjust to the new interface.
  Avoid using bool structure members. [Tomas]
v8: Rebased.
v9:
  bool is used in struct intel_hdcp [Daniel]
  config_stream_type is redesigned [Daniel]
  Reviewed-by Uma.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_drv.h  |  34 +++
 drivers/gpu/drm/i915/intel_hdcp.c | 197 +++---
 2 files changed, 216 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2c99f88b71a7..5797ee0078f2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -403,6 +403,22 @@ struct intel_hdcp_shim {
/* Detects whether sink is HDCP2.2 capable */
int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
bool *capable);
+
+   /* Write HDCP2.2 messages */
+   int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size);
+
+   /* Read HDCP2.2 messages */
+   int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
+   u8 msg_id, void *buf, size_t size);
+
+   /*
+* Implementation of DP HDCP2.2 Errata for the communication of stream
+* type to Receivers. In DP HDCP2.2 Stream type is one of the input to
+* the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
+*/
+   int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ bool is_repeater, u8 type);
 };
 
 struct intel_hdcp {
@@ -430,6 +446,24 @@ struct intel_hdcp {
 */
u8 content_type;
struct hdcp_port_data port_data;
+
+   bool is_paired;
+   bool is_repeater;
+
+   /*
+* Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
+* Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
+* When it rolls over re-auth has to be triggered.
+*/
+   u32 seq_num_v;
+
+   /*
+* Count of RepeaterAuth_Stream_Manage msg propagated.
+* Initialized to 0 on AKE_INIT. Incremented after every successful
+* transmission of RepeaterAuth_Stream_Manage message. When it rolls
+* over re-Auth has to be triggered.
+*/
+   u32 seq_num_m;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 0b6ccb3d24fe..d63f620581ad 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -17,6 +17,7 @@
 
 #define KEY_LOAD_TRIES 5
 #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS   50
+#define HDCP2_LC_RETRY_CNT 3
 
 static
 bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -862,7 +863,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv, 
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_prepare_ake_init(struct intel_connector *connector,
   struct hdcp2_ake_init *ake_data)
 {
@@ -887,7 +888,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
return ret;
 }
 
-static __attribute__((unused)) int
+static int
 hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
struct hdcp2_ake_send_cert *rx_cert,
bool *paired,
@@ -917,9 +918,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector 
*connector,
return ret;
 }
 
-static __attribute__((unused)) int
-hdcp2_verify_hprime(struct intel_connector 

[Intel-gfx] [PATCH v14 02/32] drm/i915: Initialize HDCP2.2

2019-02-15 Thread Ramalingam C
Add the HDCP2.2 initialization to the existing HDCP1.4 stack.

v2:
  mei interface handle is protected with mutex. [Chris Wilson]
v3:
  Notifiers are used for the mei interface state.
v4:
  Poll for mei client device state
  Error msg for out of mem [Uma]
  Inline req for init function removed [Uma]
v5:
  Rebase as Part of reordering.
  Component is used for the I915 and MEI_HDCP interface [Daniel]
v6:
  HDCP2.2 uses the I915 component master to communicate with mei_hdcp
- [Daniel]
  Required HDCP2.2 variables defined [Sean Paul]
v7:
  intel_hdcp2.2_init returns void [Uma]
  Realigning the codes.
v8:
  Avoid using bool structure members.
  MEI interface related changes are moved into separate patch.
  Commit msg is updated accordingly.
  intel_hdcp_exit is defined and used from i915_unload
v9:
  Movement of the hdcp_check_link is moved to new patch [Daniel]
  intel_hdcp2_exit is removed as mei_comp will be unbind in i915_unload.
v10:
  bool is used in struct to make coding simpler. [Daniel]
  hdmi hdcp init is placed correctly after encoder attachment.
v11:
  hdcp2_capability check is moved into hdcp.c [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_drv.h  | 11 +++
 drivers/gpu/drm/i915/intel_hdcp.c | 28 ++--
 drivers/gpu/drm/i915/intel_hdmi.c |  6 +++---
 3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3398b28c053b..11c696025085 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -404,6 +404,17 @@ struct intel_hdcp {
u64 value;
struct delayed_work check_work;
struct work_struct prop_work;
+
+   /* HDCP2.2 related definitions */
+   /* Flag indicates whether this connector supports HDCP2.2 or not. */
+   bool hdcp2_supported;
+
+   /*
+* Content Stream Type defined by content owner. TYPE0(0x0) content can
+* flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
+* content can flow only through a link protected by HDCP2.2.
+*/
+   u8 content_type;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 8cb85b07cfde..7b1097d79fb8 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -832,14 +832,34 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv, 
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
 }
 
+static bool is_hdcp2_supported(struct drm_i915_private *dev_priv)
+{
+   if (!IS_ENABLED(CONFIG_INTEL_MEI_HDCP))
+   return false;
+
+   return (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
+   IS_KABYLAKE(dev_priv));
+}
+
+static void intel_hdcp2_init(struct intel_connector *connector)
+{
+   struct intel_hdcp *hdcp = >hdcp;
+
+   /* TODO: MEI interface needs to be initialized here */
+   hdcp->hdcp2_supported = true;
+}
+
 int intel_hdcp_init(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
 {
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
int ret;
 
-   ret = drm_connector_attach_content_protection_property(
-   >base);
+   if (!shim)
+   return -EINVAL;
+
+   ret = 
drm_connector_attach_content_protection_property(>base);
if (ret)
return ret;
 
@@ -847,6 +867,10 @@ int intel_hdcp_init(struct intel_connector *connector,
mutex_init(>mutex);
INIT_DELAYED_WORK(>check_work, intel_hdcp_check_work);
INIT_WORK(>prop_work, intel_hdcp_prop_work);
+
+   if (is_hdcp2_supported(dev_priv))
+   intel_hdcp2_init(connector);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f125a62eba8c..faeedf76db99 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2427,6 +2427,9 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
 
intel_hdmi_add_properties(intel_hdmi, connector);
 
+   intel_connector_attach_encoder(intel_connector, intel_encoder);
+   intel_hdmi->attached_connector = intel_connector;
+
if (is_hdcp_supported(dev_priv, port)) {
int ret = intel_hdcp_init(intel_connector,
  _hdmi_hdcp_shim);
@@ -2434,9 +2437,6 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
 
-   intel_connector_attach_encoder(intel_connector, intel_encoder);
-   intel_hdmi->attached_connector = intel_connector;
-
/* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written
  

[Intel-gfx] [PATCH v14 01/32] drm/i915: Gathering the HDCP1.4 routines together

2019-02-15 Thread Ramalingam C
All HDCP1.4 routines are gathered together, followed by the generic
functions those can be extended for HDCP2.2 too.

Signed-off-by: Ramalingam C 
Acked-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
Reviewed-by: Tomas Winkler 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
 1 file changed, 59 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index ce7ba3a9c000..8cb85b07cfde 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -730,6 +730,65 @@ struct intel_connector *intel_hdcp_to_connector(struct 
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
 }
 
+/* Implements Part 3 of the HDCP authorization procedure */
+int intel_hdcp_check_link(struct intel_connector *connector)
+{
+   struct intel_hdcp *hdcp = >hdcp;
+   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   enum port port = intel_dig_port->base.port;
+   int ret = 0;
+
+   if (!hdcp->shim)
+   return -ENOENT;
+
+   mutex_lock(>mutex);
+
+   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   goto out;
+
+   if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
+   DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+ connector->base.name, connector->base.base.id,
+ I915_READ(PORT_HDCP_STATUS(port)));
+   ret = -ENXIO;
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+   if (hdcp->shim->check_link(intel_dig_port)) {
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>prop_work);
+   }
+   goto out;
+   }
+
+   DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
+ connector->base.name, connector->base.base.id);
+
+   ret = _intel_hdcp_disable(connector);
+   if (ret) {
+   DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+   ret = _intel_hdcp_enable(connector);
+   if (ret) {
+   DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+out:
+   mutex_unlock(>mutex);
+   return ret;
+}
+
 static void intel_hdcp_check_work(struct work_struct *work)
 {
struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
@@ -866,62 +925,3 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
   new_state->crtc);
crtc_state->mode_changed = true;
 }
-
-/* Implements Part 3 of the HDCP authorization procedure */
-int intel_hdcp_check_link(struct intel_connector *connector)
-{
-   struct intel_hdcp *hdcp = >hdcp;
-   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
-   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
-   enum port port = intel_dig_port->base.port;
-   int ret = 0;
-
-   if (!hdcp->shim)
-   return -ENOENT;
-
-   mutex_lock(>mutex);
-
-   if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
-   goto out;
-
-   if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
-   DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
- connector->base.name, connector->base.base.id,
- I915_READ(PORT_HDCP_STATUS(port)));
-   ret = -ENXIO;
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
-   goto out;
-   }
-
-   if (hdcp->shim->check_link(intel_dig_port)) {
-   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
-   schedule_work(>prop_work);
-   }
-   goto out;
-   }
-
-   DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
- connector->base.name, connector->base.base.id);
-
-   ret = _intel_hdcp_disable(connector);
-   if (ret) {
-   DRM_ERROR("Failed to disable hdcp (%d)\n", ret);
-   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
-   schedule_work(>prop_work);
-   goto out;
-   }
-
-   ret = 

[Intel-gfx] [PATCH v14 05/32] drm/i915: Enable and Disable of HDCP2.2

2019-02-15 Thread Ramalingam C
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.

When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.

This change implements a sequence of enabling and disabling of
HDCP2.2 authentication and HDCP2.2 port encryption.

v2:
  Included few optimization suggestions [Chris Wilson]
  Commit message is updated as per the rebased version.
  intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
  Extra comment added and Style issue fixed [Uma]
v4:
  Rebased as part of patch reordering.
  HDCP2 encryption status is tracked.
  HW state check is moved into WARN_ON [Daniel]
v5:
  Redefined the mei service functions as per comp redesign.
  Merged patches related to hdcp2.2 enabling and disabling [Sean Paul].
  Required shim functionality is defined [Sean Paul]
v6:
  Return values are handles [Uma]
  Realigned the code.
  Check for comp_master is removed.
v7:
  HDCP2.2 is attempted only if mei interface is up.
  Adjust to the new interface
  Avoid bool usage in struct [Tomas]
v8:
  mei_binded status check is removed.
  %s/hdcp2_in_use/hdcp2_encrypted
v9:
  bool is used in struct intel_hdcp. [Daniel]
v10:
  panel is replaced with sink [Uma]
  Mei interface decided the hdcp2_capability.
  WARN_ON if hdcp_enable is called when hdcp state is ENABLED.
  Reviewed-by Uma.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_drv.h  |   7 ++
 drivers/gpu/drm/i915/intel_hdcp.c | 212 +++---
 2 files changed, 205 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index df2c88877480..2c99f88b71a7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -399,6 +399,10 @@ struct intel_hdcp_shim {
 
/* HDCP adaptation(DP/HDMI) required on the port */
enum hdcp_wired_protocol protocol;
+
+   /* Detects whether sink is HDCP2.2 capable */
+   int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
+   bool *capable);
 };
 
 struct intel_hdcp {
@@ -416,6 +420,9 @@ struct intel_hdcp {
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
 
+   /* HDCP2.2 Encryption status */
+   bool hdcp2_encrypted;
+
/*
 * Content Stream Type defined by content owner. TYPE0(0x0) content can
 * flow in the link protected by HDCP2.2 or HDCP1.4, where as TYPE1(0x1)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 66e3850a57a0..0b6ccb3d24fe 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,32 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
 }
 
+/* Is HDCP2.2 capable on Platform and Sink */
+static bool intel_hdcp2_capable(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct intel_hdcp *hdcp = >hdcp;
+   bool capable = false;
+
+   /* I915 support for HDCP2.2 */
+   if (!hdcp->hdcp2_supported)
+   return false;
+
+   /* MEI interface is solid */
+   mutex_lock(_priv->hdcp_comp_mutex);
+   if (!dev_priv->hdcp_comp_added ||  !dev_priv->hdcp_master) {
+   mutex_unlock(_priv->hdcp_comp_mutex);
+   return false;
+   }
+   mutex_unlock(_priv->hdcp_comp_mutex);
+
+   /* Sink's capability for HDCP2.2 */
+   hdcp->shim->hdcp_2_2_capable(intel_dig_port, );
+
+   return capable;
+}
+
 static inline bool intel_hdcp_in_use(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1094,8 +1120,7 @@ int hdcp2_authenticate_port(struct intel_connector 
*connector)
return ret;
 }
 
-static __attribute__((unused))
-int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_mei_session(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
@@ -1116,12 +1141,157 @@ int hdcp2_close_mei_session(struct intel_connector 
*connector)
return ret;
 }
 
-static __attribute__((unused))
-int hdcp2_deauthenticate_port(struct intel_connector *connector)
+static int hdcp2_deauthenticate_port(struct intel_connector *connector)
 {
return hdcp2_close_mei_session(connector);
 }
 
+static int hdcp2_authenticate_sink(struct intel_connector *connector)
+{
+   DRM_ERROR("Sink authentication is done in subsequent patches\n");
+
+   return -EINVAL;
+}
+
+static int hdcp2_enable_encryption(struct intel_connector *connector)
+{
+   struct intel_digital_port 

[Intel-gfx] [PATCH v14 09/32] drm/i915: Implement HDCP2.2 link integrity check

2019-02-15 Thread Ramalingam C
Implements the link integrity check once in 500mSec.

Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.

On the detection of synchronization lost, the HDCP Receiver must assert
the corresponding bits of the RxStatus register. The Transmitter polls
the RxStatus register and it may initiate re-authentication.

v2:
  Rebased.
v3:
  enum check_link_response is used check the link status [Uma]
v4:
  Rebased as part of patch reordering.
v5:
  Required members of intel_hdcp is defined [Sean Paul]
v6:
  hdcp2_check_link is cancelled at required places.
v7:
  Rebased for the component i/f changes.
  Errors due to the sinks are reported as DEBUG logs.
v8:
  hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel]
  hdcp2.2 encryption status check is put under WARN_ON [Daniel]
  drm_hdcp.h changes are moved into separate patch [Daniel]
v9:
  enum check_link_status is defined at intel_drv.h [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_drv.h  | 10 +
 drivers/gpu/drm/i915/intel_hdcp.c | 88 ---
 2 files changed, 93 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5797ee0078f2..dfedcc2b076c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -324,6 +324,13 @@ struct intel_panel {
 
 struct intel_digital_port;
 
+enum check_link_response {
+   HDCP_LINK_PROTECTED = 0,
+   HDCP_TOPOLOGY_CHANGE,
+   HDCP_LINK_INTEGRITY_FAILURE,
+   HDCP_REAUTH_REQUEST
+};
+
 /*
  * This structure serves as a translation layer between the generic HDCP code
  * and the bus-specific code. What that means is that HDCP over HDMI differs
@@ -419,6 +426,9 @@ struct intel_hdcp_shim {
 */
int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
  bool is_repeater, u8 type);
+
+   /* HDCP2.2 Link Integrity Check */
+   int (*check_2_2_link)(struct intel_digital_port *intel_dig_port);
 };
 
 struct intel_hdcp {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 24051120d3bb..00fae3963caf 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -111,6 +111,16 @@ static inline bool intel_hdcp_in_use(struct 
intel_connector *connector)
return reg & HDCP_STATUS_ENC;
 }
 
+static inline bool intel_hdcp2_in_use(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   enum port port = connector->encoder->port;
+   u32 reg;
+
+   reg = I915_READ(HDCP2_STATUS_DDI(port));
+   return reg & LINK_ENCRYPTION_STATUS;
+}
+
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
 {
@@ -1580,6 +1590,69 @@ static int _intel_hdcp2_disable(struct intel_connector 
*connector)
return ret;
 }
 
+/* Implements the Link Integrity Check for HDCP2.2 */
+static int intel_hdcp2_check_link(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = >hdcp;
+   enum port port = connector->encoder->port;
+   int ret = 0;
+
+   mutex_lock(>mutex);
+
+   /* hdcp2_check_link is expected only when HDCP2.2 is Enabled */
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED ||
+   !hdcp->hdcp2_encrypted) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if (WARN_ON(!intel_hdcp2_in_use(connector))) {
+   DRM_ERROR("HDCP2.2 link stopped the encryption, %x\n",
+ I915_READ(HDCP2_STATUS_DDI(port)));
+   ret = -ENXIO;
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   schedule_work(>prop_work);
+   goto out;
+   }
+
+   ret = hdcp->shim->check_2_2_link(intel_dig_port);
+   if (ret == HDCP_LINK_PROTECTED) {
+   if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
+   schedule_work(>prop_work);
+   }
+   goto out;
+   }
+
+   DRM_DEBUG_KMS("[%s:%d] HDCP2.2 link failed, retrying auth\n",
+ connector->base.name, connector->base.base.id);
+
+   ret = _intel_hdcp2_disable(connector);
+   if (ret) {
+   DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
+   hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ 

[Intel-gfx] [PATCH v14 03/32] drm/i915: MEI interface implementation

2019-02-15 Thread Ramalingam C
Defining the mei-i915 interface functions and initialization of
the interface.

v2:
  Adjust to the new interface changes. [Tomas]
  Added further debug logs for the failures at MEI i/f.
  port in hdcp_port data is equipped to handle -ve values.
v3:
  mei comp is matched for global i915 comp master. [Daniel]
  In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
  mei wrappers are adjusted as per the i/f change [Daniel]
v4:
  port initialization is done only at hdcp2_init only [Danvet]
v5:
  I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
v6:
  HDCP_disable for all connectors incase of comp_unbind.
  Tear down HDCP comp interface at i915_unload [Daniel]
v7:
  Component init and fini are moved out of connector ops [Daniel]
  hdcp_disable is not called from unbind. [Daniel]
v8:
  subcomponent name is dropped as it is already merged.

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter  [v11]
---
 drivers/gpu/drm/i915/i915_drv.c|   1 +
 drivers/gpu/drm/i915/i915_drv.h|   7 +
 drivers/gpu/drm/i915/intel_connector.c |   2 +
 drivers/gpu/drm/i915/intel_display.c   |   4 +
 drivers/gpu/drm/i915/intel_drv.h   |   8 +
 drivers/gpu/drm/i915/intel_hdcp.c  | 398 -
 6 files changed, 419 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6630212f2faf..c6354f6cdbdb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -906,6 +906,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv)
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
mutex_init(_priv->pps_mutex);
+   mutex_init(_priv->hdcp_comp_mutex);
 
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c8d0489a1cd..d375d1cf86f5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_fixed.h"
 #include "i915_params.h"
@@ -2052,6 +2053,12 @@ struct drm_i915_private {
 
struct i915_pmu pmu;
 
+   struct i915_hdcp_comp_master *hdcp_master;
+   bool hdcp_comp_added;
+
+   /* Mutex to protect the above hdcp component related values. */
+   struct mutex hdcp_comp_mutex;
+
/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
 * will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758747c5..66ed3ee5998a 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector *connector)
 
kfree(intel_connector->detect_edid);
 
+   intel_hdcp_cleanup(intel_connector);
+
if (!IS_ERR_OR_NULL(intel_connector->edid))
kfree(intel_connector->edid);
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 73a107b6eb9a..acb993ce7eaa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15453,6 +15453,8 @@ int intel_modeset_init(struct drm_device *dev)
intel_update_czclk(dev_priv);
intel_modeset_init_hw(dev);
 
+   intel_hdcp_component_init(dev_priv);
+
if (dev_priv->max_cdclk_freq == 0)
intel_update_max_cdclk(dev_priv);
 
@@ -16314,6 +16316,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
/* flush any delayed tasks or pending work */
flush_scheduled_work();
 
+   intel_hdcp_component_fini(dev_priv);
+
drm_mode_config_cleanup(dev);
 
intel_overlay_cleanup(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 11c696025085..f8e8482573c8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct drm_printer;
@@ -395,6 +396,9 @@ struct intel_hdcp_shim {
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
bool *hdcp_capable);
+
+   /* HDCP adaptation(DP/HDMI) required on the port */
+   enum hdcp_wired_protocol protocol;
 };
 
 struct intel_hdcp {
@@ -415,6 +419,7 @@ struct intel_hdcp {
 * content can flow only through a link protected by HDCP2.2.
 */
u8 content_type;
+   struct hdcp_port_data port_data;
 };
 
 struct intel_connector {
@@ -2088,6 +2093,9 @@ int intel_hdcp_disable(struct intel_connector *connector);
 int intel_hdcp_check_link(struct intel_connector *connector);
 bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reduce the RPS shock

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Reduce the RPS shock
URL   : https://patchwork.freedesktop.org/series/56740/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5611 -> Patchwork_12228


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56740/revisions/1/mbox/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- fi-skl-6700k2:  PASS -> INCOMPLETE [fdo#104108]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s4-devices:
- {fi-icl-y}: INCOMPLETE [fdo#107713] -> PASS

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

  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528


Participating hosts (49 -> 43)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5611 -> Patchwork_12228

  CI_DRM_5611: c09679e398a860df940ba35ad5102e396bf4acb5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4831: 616842ef493ead76ac6c75b2a93337439724655f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12228: df5adf51e32141a30605b3daf6de4957bf347543 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

df5adf51e321 drm/i915: Reduce the RPS shock

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12228/
___
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: Reduce the RPS shock

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Reduce the RPS shock
URL   : https://patchwork.freedesktop.org/series/56740/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
df5adf51e321 drm/i915: Reduce the RPS shock
-:32: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0d55babc8392 ("drm/i915: Drop 
stray clearing of rps->last_adj")'
#32: 
References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj")

-:33: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 60548c554be2 ("drm/i915: 
Interactive RPS mode")'
#33: 
References: 60548c554be2 ("drm/i915: Interactive RPS mode")

total: 2 errors, 0 warnings, 0 checks, 18 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/fbdev: Actually configure untiled displays

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915/fbdev: Actually configure untiled displays
URL   : https://patchwork.freedesktop.org/series/56728/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5611 -> Patchwork_12227


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56728/revisions/1/mbox/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_hangcheck:
- fi-skl-iommu:   PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]

  * igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s4-devices:
- {fi-icl-y}: INCOMPLETE [fdo#107713] -> PASS

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

  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
  [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
  [fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567


Participating hosts (49 -> 41)
--

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5611 -> Patchwork_12227

  CI_DRM_5611: c09679e398a860df940ba35ad5102e396bf4acb5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4831: 616842ef493ead76ac6c75b2a93337439724655f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12227: 0de16260485cb0c3f5c93bc9fd55901c35b11af8 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0de16260485c drm/i915/fbdev: Actually configure untiled displays

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/fbdev: Actually configure untiled displays

2019-02-15 Thread Patchwork
== Series Details ==

Series: drm/i915/fbdev: Actually configure untiled displays
URL   : https://patchwork.freedesktop.org/series/56728/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/fbdev: Actually configure untiled displays
-O:drivers/gpu/drm/i915/intel_fbdev.c:342:30: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_fbdev.c:341:30: warning: expression using 
sizeof(void)

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

[Intel-gfx] [PATCH] drm/i915/selftests: Always free spinner on __sseu_prepare error

2019-02-15 Thread Chris Wilson
Prepare a nice little onion unwind to ensure that we always free the
spinner if we __sseu_prepare fails.

Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
Reported-by: Radhakrishna Sripada 
Signed-off-by: Chris Wilson 
Cc: Radhakrishna Sripada 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 .../gpu/drm/i915/selftests/i915_gem_context.c | 69 +--
 1 file changed, 34 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index d00d0bb07784..7eb58a9d1319 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -710,47 +710,45 @@ __sseu_prepare(struct drm_i915_private *i915,
   unsigned int flags,
   struct i915_gem_context *ctx,
   struct intel_engine_cs *engine,
-  struct igt_spinner **spin_out)
+  struct igt_spinner **spin)
 {
-   int ret = 0;
-
-   if (flags & (TEST_BUSY | TEST_RESET)) {
-   struct igt_spinner *spin;
-   struct i915_request *rq;
+   struct i915_request *rq;
+   int ret;
 
-   spin = kzalloc(sizeof(*spin), GFP_KERNEL);
-   if (!spin) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   *spin = NULL;
+   if (!(flags & (TEST_BUSY | TEST_RESET)))
+   return 0;
 
-   ret = igt_spinner_init(spin, i915);
-   if (ret)
-   return ret;
+   *spin = kzalloc(sizeof(**spin), GFP_KERNEL);
+   if (!*spin)
+   return -ENOMEM;
 
-   rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
-   if (IS_ERR(rq)) {
-   ret = PTR_ERR(rq);
-   igt_spinner_fini(spin);
-   kfree(spin);
-   goto out;
-   }
+   ret = igt_spinner_init(*spin, i915);
+   if (ret)
+   goto err_free;
 
-   i915_request_add(rq);
+   rq = igt_spinner_create_request(*spin, ctx, engine, MI_NOOP);
+   if (IS_ERR(rq)) {
+   ret = PTR_ERR(rq);
+   goto err_fini;
+   }
 
-   if (!igt_wait_for_spinner(spin, rq)) {
-   pr_err("%s: Spinner failed to start!\n", name);
-   igt_spinner_end(spin);
-   igt_spinner_fini(spin);
-   kfree(spin);
-   ret = -ETIMEDOUT;
-   goto out;
-   }
+   i915_request_add(rq);
 
-   *spin_out = spin;
+   if (!igt_wait_for_spinner(*spin, rq)) {
+   pr_err("%s: Spinner failed to start!\n", name);
+   ret = -ETIMEDOUT;
+   goto err_end;
}
 
-out:
+   return 0;
+
+err_end:
+   igt_spinner_end(*spin);
+err_fini:
+   igt_spinner_fini(*spin);
+err_free:
+   kfree(fetch_and_zero(spin));
return ret;
 }
 
@@ -897,22 +895,23 @@ __sseu_test(struct drm_i915_private *i915,
 
ret = __sseu_prepare(i915, name, flags, ctx, engine, );
if (ret)
-   goto out;
+   goto out_context;
 
ret = __i915_gem_context_reconfigure_sseu(ctx, engine, sseu);
if (ret)
-   goto out;
+   goto out_spin;
 
ret = __sseu_finish(i915, name, flags, ctx, kctx, engine, obj,
hweight32(sseu.slice_mask), spin);
 
-out:
+out_spin:
if (spin) {
igt_spinner_end(spin);
igt_spinner_fini(spin);
kfree(spin);
}
 
+out_context:
kernel_context_close(kctx);
 
return ret;
-- 
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/selftests: Fix resource leak in __sseu_prepare

2019-02-15 Thread Chris Wilson
Quoting Chris Wilson (2019-02-15 19:40:06)
> Quoting Radhakrishna Sripada (2019-02-15 19:35:54)
> > Fix the resource leak reported by static code checker.
> 
> The caller already frees spin on error, so you just need to set the
> output and report the error.

Nah, doesn't look at tidy as a proper onion unwind.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/3] Support 64 bpp half float formats

2019-02-15 Thread Adam Jackson
On Fri, 2019-02-08 at 13:49 -0800, Kevin Strasser wrote:
> This series defines new formats and adds implementation to the i915 driver.
> Since posting v1 I have removed the pixel normalize property, as it's not 
> needed
> for basic functionality. Also, I have been working on adding support to
> userspace, but we can't land any patches until drm_fourcc.h has been updated
> here.

Series is:

Reviewed-by: Adam Jackson 

- ajax

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix resource leak in __sseu_prepare

2019-02-15 Thread Chris Wilson
Quoting Radhakrishna Sripada (2019-02-15 19:35:54)
> Fix the resource leak reported by static code checker.

The caller already frees spin on error, so you just need to set the
output and report the error.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/selftests: Fix resource leak in __sseu_prepare

2019-02-15 Thread Radhakrishna Sripada
Fix the resource leak reported by static code checker.

Cc: Tvrtko Ursulin 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/selftests/i915_gem_context.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index d00d0bb07784..0d821a679f74 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -726,14 +726,13 @@ __sseu_prepare(struct drm_i915_private *i915,
 
ret = igt_spinner_init(spin, i915);
if (ret)
-   return ret;
+   goto clean;
 
rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
igt_spinner_fini(spin);
-   kfree(spin);
-   goto out;
+   goto clean;
}
 
i915_request_add(rq);
@@ -742,14 +741,16 @@ __sseu_prepare(struct drm_i915_private *i915,
pr_err("%s: Spinner failed to start!\n", name);
igt_spinner_end(spin);
igt_spinner_fini(spin);
-   kfree(spin);
ret = -ETIMEDOUT;
-   goto out;
+   goto clean;
}
 
*spin_out = spin;
+   goto out;
}
 
+clean:
+   kfree(spin);
 out:
return ret;
 }
-- 
2.20.0.rc2.7.g965798d1f299

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/selftests: Exercise resetting during non-user payloads

2019-02-15 Thread Chris Wilson
Quoting Patchwork (2019-02-15 18:11:23)
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915/selftests: Exercise resetting 
> during non-user payloads
> URL   : https://patchwork.freedesktop.org/series/56716/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_5608 -> Patchwork_12226
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_12226 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_12226, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   External URL: 
> https://patchwork.freedesktop.org/api/1.0/series/56716/revisions/1/mbox/
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_12226:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_selftest@live_hangcheck:
> - fi-bdw-gvtdvm:  PASS -> DMESG-FAIL
> - fi-bdw-5557u:   PASS -> DMESG-FAIL
> - fi-glk-j4005:   PASS -> DMESG-FAIL
> - fi-cfl-8109u:   PASS -> DMESG-FAIL
> - fi-cfl-8700k:   PASS -> DMESG-FAIL
> - fi-skl-iommu:   PASS -> DMESG-FAIL
> - fi-skl-gvtdvm:  PASS -> DMESG-FAIL
> - fi-bxt-j4205:   PASS -> DMESG-FAIL
> - fi-skl-6600u:   PASS -> DMESG-FAIL
> - fi-bsw-n3050:   PASS -> DMESG-FAIL
> - fi-skl-6770hq:  PASS -> DMESG-FAIL
> - fi-skl-6700k2:  PASS -> DMESG-FAIL
> - fi-skl-6260u:   PASS -> DMESG-FAIL

That does actually appear to be a genuine bug with us not writing the
global_seqno (context seqno is fine), and has occurred in the wild
https://bugs.freedesktop.org/show_bug.cgi?id=109606

Removal of global_seqno fixes \o/ (at least locally)
-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 series starting with [1/2] drm/i915/selftests: Exercise resetting during non-user payloads

2019-02-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Exercise resetting 
during non-user payloads
URL   : https://patchwork.freedesktop.org/series/56716/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5608 -> Patchwork_12226


Summary
---

  **FAILURE**

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/56716/revisions/1/mbox/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_hangcheck:
- fi-bdw-gvtdvm:  PASS -> DMESG-FAIL
- fi-bdw-5557u:   PASS -> DMESG-FAIL
- fi-glk-j4005:   PASS -> DMESG-FAIL
- fi-cfl-8109u:   PASS -> DMESG-FAIL
- fi-cfl-8700k:   PASS -> DMESG-FAIL
- fi-skl-iommu:   PASS -> DMESG-FAIL
- fi-skl-gvtdvm:  PASS -> DMESG-FAIL
- fi-bxt-j4205:   PASS -> DMESG-FAIL
- fi-skl-6600u:   PASS -> DMESG-FAIL
- fi-bsw-n3050:   PASS -> DMESG-FAIL
- fi-skl-6770hq:  PASS -> DMESG-FAIL
- fi-skl-6700k2:  PASS -> DMESG-FAIL
- fi-skl-6260u:   PASS -> DMESG-FAIL

  
 Suppressed 

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

  * igt@i915_selftest@live_hangcheck:
- {fi-whl-u}: PASS -> DMESG-FAIL
- {fi-icl-u2}:PASS -> DMESG-FAIL
- {fi-icl-u3}:PASS -> DMESG-FAIL

  * {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-r:   PASS -> DMESG-FAIL [fdo#107860]
- fi-kbl-7567u:   PASS -> DMESG-FAIL [fdo#107860]
- fi-kbl-x1275:   PASS -> DMESG-FAIL [fdo#107860]
- fi-kbl-7500u:   PASS -> DMESG-FAIL [fdo#107860]
- fi-kbl-8809g:   PASS -> DMESG-FAIL [fdo#107860]
- fi-kbl-7560u:   PASS -> DMESG-FAIL [fdo#107860]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- {fi-icl-u2}:FAIL [fdo#103375] -> PASS
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   DMESG-WARN [fdo#107709] -> PASS

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   FAIL [fdo#109485] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS

  * igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   {SKIP} [fdo#109271] -> PASS

  * igt@pm_rpm@basic-rte:
- fi-byt-j1900:   FAIL [fdo#108800] -> PASS

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

  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107860]: https://bugs.freedesktop.org/show_bug.cgi?id=107860
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
  [fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
  [fdo#109530]: 

Re: [Intel-gfx] [PATCH v14 09/35] drm: helper functions for hdcp2 seq_num to from u32

2019-02-15 Thread Daniel Vetter
On Fri, Feb 15, 2019 at 02:05:04PM +0530, Ramalingam C wrote:
> Library functions for endianness are aligned for 16/32/64 bits.
> But hdcp sequence numbers are 24bits(big endian).
> So for their conversion to and from u32 helper functions are developed.
> 
> v2:
>   Comment is updated. [Daniel]
>   Reviewed-by Uma.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Uma Shankar 

Merged into topic/mei-hdcp. With these four patches we have everything
from this series to create the mei-hdcp branch. At least worked out fine
when I tested it here locally.

Also means you need to rebase, but seems like CI ignored you anyway
:-(

Cheers, Daniel

> ---
>  include/drm/drm_hdcp.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index d6dfef8cff6a..7260b31af276 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -252,4 +252,22 @@ struct hdcp2_dp_errata_stream_type {
>  #define HDCP_2_2_HDMI_RXSTATUS_READY(x)  ((x) & BIT(2))
>  #define HDCP_2_2_HDMI_RXSTATUS_REAUTH_REQ(x) ((x) & BIT(3))
>  
> +/*
> + * Helper functions to convert 24bit big endian hdcp sequence number to
> + * host format and back
> + */
> +static inline
> +u32 drm_hdcp2_seq_num_to_u32(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN])
> +{
> + return (u32)(seq_num[2] | seq_num[1] << 8 | seq_num[0] << 16);
> +}
> +
> +static inline
> +void drm_hdcp2_u32_to_seq_num(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val)
> +{
> + seq_num[0] = val >> 16;
> + seq_num[1] = val >> 8;
> + seq_num[2] = val;
> +}
> +
>  #endif
> -- 
> 2.7.4
> 

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

Re: [Intel-gfx] [PATCH v14 05/35] drm/i915: MEI interface definition

2019-02-15 Thread Daniel Vetter
On Fri, Feb 15, 2019 at 02:05:00PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
> 
> v2:
>   Adjust to the new interface changes. [Tomas]
>   Added further debug logs for the failures at MEI i/f.
>   port in hdcp_port data is equipped to handle -ve values.
> v3:
>   mei comp is matched for global i915 comp master. [Daniel]
>   In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
>   mei wrappers are adjusted as per the i/f change [Daniel]
> v4:
>   port initialization is done only at hdcp2_init only [Danvet]
> v5:
>   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
> v6:
>   HDCP_disable for all connectors incase of comp_unbind.
>   Tear down HDCP comp interface at i915_unload [Daniel]
> v7:
>   Component init and fini are moved out of connector ops [Daniel]
>   hdcp_disable is not called from unbind. [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter  [v11]
> ---
>  drivers/gpu/drm/i915/i915_drv.c|   1 +
>  drivers/gpu/drm/i915/i915_drv.h|   7 +
>  drivers/gpu/drm/i915/intel_connector.c |   2 +
>  drivers/gpu/drm/i915/intel_display.c   |   4 +
>  drivers/gpu/drm/i915/intel_drv.h   |   8 +
>  drivers/gpu/drm/i915/intel_hdcp.c  | 398 
> -
>  include/drm/i915_component.h   |   3 +
>  7 files changed, 422 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6630212f2faf..c6354f6cdbdb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv)
>   mutex_init(_priv->av_mutex);
>   mutex_init(_priv->wm.wm_mutex);
>   mutex_init(_priv->pps_mutex);
> + mutex_init(_priv->hdcp_comp_mutex);
>  
>   i915_memcpy_init_early(dev_priv);
>   intel_runtime_pm_init_early(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 17fe942eaafa..a09c82c92ea5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "i915_fixed.h"
>  #include "i915_params.h"
> @@ -2051,6 +2052,12 @@ struct drm_i915_private {
>  
>   struct i915_pmu pmu;
>  
> + struct i915_hdcp_comp_master *hdcp_master;
> + bool hdcp_comp_added;
> +
> + /* Mutex to protect the above hdcp component related values. */
> + struct mutex hdcp_comp_mutex;
> +
>   /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> diff --git a/drivers/gpu/drm/i915/intel_connector.c 
> b/drivers/gpu/drm/i915/intel_connector.c
> index ee16758747c5..66ed3ee5998a 100644
> --- a/drivers/gpu/drm/i915/intel_connector.c
> +++ b/drivers/gpu/drm/i915/intel_connector.c
> @@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector 
> *connector)
>  
>   kfree(intel_connector->detect_edid);
>  
> + intel_hdcp_cleanup(intel_connector);
> +
>   if (!IS_ERR_OR_NULL(intel_connector->edid))
>   kfree(intel_connector->edid);
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 0a8913b2059e..97bce4707a4c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15459,6 +15459,8 @@ int intel_modeset_init(struct drm_device *dev)
>   intel_update_czclk(dev_priv);
>   intel_modeset_init_hw(dev);
>  
> + intel_hdcp_component_init(dev_priv);
> +
>   if (dev_priv->max_cdclk_freq == 0)
>   intel_update_max_cdclk(dev_priv);
>  
> @@ -16320,6 +16322,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
>   /* flush any delayed tasks or pending work */
>   flush_scheduled_work();
>  
> + intel_hdcp_component_fini(dev_priv);
> +
>   drm_mode_config_cleanup(dev);
>  
>   intel_overlay_cleanup(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 11c696025085..f8e8482573c8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct drm_printer;
> @@ -395,6 +396,9 @@ struct intel_hdcp_shim {
>   /* Detects panel's hdcp capability. This is optional for HDMI. */
>   int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
>   bool *hdcp_capable);
> +
> + /* HDCP adaptation(DP/HDMI) required on the port */
> + enum hdcp_wired_protocol protocol;
>  };
>  
>  struct intel_hdcp {
> @@ -415,6 +419,7 @@ struct intel_hdcp {
>* content can flow only through a link protected by HDCP2.2.
>*/
>   u8 content_type;
> + struct hdcp_port_data 

Re: [Intel-gfx] [PATCH v14 03/35] drm: header for i915 - MEI_HDCP interface

2019-02-15 Thread Daniel Vetter
On Fri, Feb 15, 2019 at 02:04:58PM +0530, Ramalingam C wrote:
> Header defines the interface for the I915 and MEI_HDCP drivers.
> This interface is specific to the usage of mei_hdcp from gen9+
> platforms for ME FW based HDCP2.2 services.
> 
> And Generic HDCP2.2 protocol specific definitions
> are added at drm/drm_hdcp.h.
> 
> v2:
>   Commit msg is enhanced [Daniel]
> v3:
>   i915_hdcp_comp_master is defined.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter  [v2]
> Reviewed-by: Uma Shankar  [v2]

Merged to topic/mei-hdcp. Again with the subject prefix fixed to drm/i915:

Thanks, Daniel

> ---
>  include/drm/i915_mei_hdcp_interface.h | 149 
> ++
>  1 file changed, 149 insertions(+)
>  create mode 100644 include/drm/i915_mei_hdcp_interface.h
> 
> diff --git a/include/drm/i915_mei_hdcp_interface.h 
> b/include/drm/i915_mei_hdcp_interface.h
> new file mode 100644
> index ..8c344255146a
> --- /dev/null
> +++ b/include/drm/i915_mei_hdcp_interface.h
> @@ -0,0 +1,149 @@
> +/* SPDX-License-Identifier: (GPL-2.0+) */
> +/*
> + * Copyright © 2017-2018 Intel Corporation
> + *
> + * Authors:
> + * Ramalingam C 
> + */
> +
> +#ifndef _I915_MEI_HDCP_INTERFACE_H_
> +#define _I915_MEI_HDCP_INTERFACE_H_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * enum hdcp_port_type - HDCP port implementation type defined by ME FW
> + * @HDCP_PORT_TYPE_INVALID: Invalid hdcp port type
> + * @HDCP_PORT_TYPE_INTEGRATED: In-Host HDCP2.x port
> + * @HDCP_PORT_TYPE_LSPCON: HDCP2.2 discrete wired Tx port with LSPCON
> + *  (HDMI 2.0) solution
> + * @HDCP_PORT_TYPE_CPDP: HDCP2.2 discrete wired Tx port using the CPDP (DP 
> 1.3)
> + *solution
> + */
> +enum hdcp_port_type {
> + HDCP_PORT_TYPE_INVALID,
> + HDCP_PORT_TYPE_INTEGRATED,
> + HDCP_PORT_TYPE_LSPCON,
> + HDCP_PORT_TYPE_CPDP
> +};
> +
> +/**
> + * enum hdcp_wired_protocol - HDCP adaptation used on the port
> + * @HDCP_PROTOCOL_INVALID: Invalid HDCP adaptation protocol
> + * @HDCP_PROTOCOL_HDMI: HDMI adaptation of HDCP used on the port
> + * @HDCP_PROTOCOL_DP: DP adaptation of HDCP used on the port
> + */
> +enum hdcp_wired_protocol {
> + HDCP_PROTOCOL_INVALID,
> + HDCP_PROTOCOL_HDMI,
> + HDCP_PROTOCOL_DP
> +};
> +
> +/**
> + * struct hdcp_port_data - intel specific HDCP port data
> + * @port: port index as per I915
> + * @port_type: HDCP port type as per ME FW classification
> + * @protocol: HDCP adaptation as per ME FW
> + * @k: No of streams transmitted on a port. Only on DP MST this is != 1
> + * @seq_num_m: Count of RepeaterAuth_Stream_Manage msg propagated.
> + *  Initialized to 0 on AKE_INIT. Incremented after every successful
> + *  transmission of RepeaterAuth_Stream_Manage message. When it rolls
> + *  over re-Auth has to be triggered.
> + * @streams: struct hdcp2_streamid_type[k]. Defines the type and id for the
> + *streams
> + */
> +struct hdcp_port_data {
> + enum port port;
> + u8 port_type;
> + u8 protocol;
> + u16 k;
> + u32 seq_num_m;
> + struct hdcp2_streamid_type *streams;
> +};
> +
> +/**
> + * struct i915_hdcp_component_ops- ops for HDCP2.2 services.
> + * @owner: Module providing the ops
> + * @initiate_hdcp2_session: Initiate a Wired HDCP2.2 Tx Session.
> + *   And Prepare AKE_Init.
> + * @verify_receiver_cert_prepare_km: Verify the Receiver Certificate
> + *AKE_Send_Cert and prepare
> +  AKE_Stored_Km/AKE_No_Stored_Km
> + * @verify_hprime: Verify AKE_Send_H_prime
> + * @store_pairing_info: Store pairing info received
> + * @initiate_locality_check: Prepare LC_Init
> + * @verify_lprime: Verify lprime
> + * @get_session_key: Prepare SKE_Send_Eks
> + * @repeater_check_flow_prepare_ack: Validate the Downstream topology
> + *and prepare rep_ack
> + * @verify_mprime: Verify mprime
> + * @enable_hdcp_authentication:  Mark a port as authenticated.
> + * @close_hdcp_session: Close the Wired HDCP Tx session per port.
> + *   This also disables the authenticated state of the port.
> + */
> +struct i915_hdcp_component_ops {
> + /**
> +  * @owner: mei_hdcp module
> +  */
> + struct module *owner;
> +
> + int (*initiate_hdcp2_session)(struct device *dev,
> +   struct hdcp_port_data *data,
> +   struct hdcp2_ake_init *ake_data);
> + int (*verify_receiver_cert_prepare_km)(struct device *dev,
> +struct hdcp_port_data *data,
> +struct hdcp2_ake_send_cert
> + *rx_cert,
> +bool *km_stored,
> +struct hdcp2_ake_no_stored_km
> + 

Re: [Intel-gfx] [PATCH v14 02/35] drm: enum port definition is moved into i915_drm.h

2019-02-15 Thread Daniel Vetter
On Fri, Feb 15, 2019 at 02:04:57PM +0530, Ramalingam C wrote:
> For the reusability of the enum port in other driver modules
> (like mei_hdcp), enum port definition is moved from I915 local header
> intel_display.h to drm/i915_drm.h
> 
> Signed-off-by: Ramalingam C 
> Acked-by: Daniel Vetter 

Applied to topic/mei-hdcp. I've fixed the subject prefix to drm/i915:
since this isn't a core drm change, only i915 related.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.h | 16 +---
>  include/drm/i915_drm.h   | 15 +++
>  2 files changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.h 
> b/drivers/gpu/drm/i915/intel_display.h
> index c7c068662288..2220588e86ac 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -26,6 +26,7 @@
>  #define _INTEL_DISPLAY_H_
>  
>  #include 
> +#include 
>  
>  enum i915_gpio {
>   GPIOA,
> @@ -150,21 +151,6 @@ enum plane_id {
>   for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
>   for_each_if((__crtc)->plane_ids_mask & BIT(__p))
>  
> -enum port {
> - PORT_NONE = -1,
> -
> - PORT_A = 0,
> - PORT_B,
> - PORT_C,
> - PORT_D,
> - PORT_E,
> - PORT_F,
> -
> - I915_MAX_PORTS
> -};
> -
> -#define port_name(p) ((p) + 'A')
> -
>  /*
>   * Ports identifier referenced from other drivers.
>   * Expected to remain stable over time
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index c44703f471b3..7523e9a7b6e2 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -100,4 +100,19 @@ extern struct resource intel_graphics_stolen_res;
>  #define INTEL_GEN11_BSM_DW1  0xc4
>  #define   INTEL_BSM_MASK (-(1u << 20))
>  
> +enum port {
> + PORT_NONE = -1,
> +
> + PORT_A = 0,
> + PORT_B,
> + PORT_C,
> + PORT_D,
> + PORT_E,
> + PORT_F,
> +
> + I915_MAX_PORTS
> +};
> +
> +#define port_name(p) ((p) + 'A')
> +
>  #endif   /* _I915_DRM_H_ */
> -- 
> 2.7.4
> 

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Exercise resetting during non-user payloads

2019-02-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Exercise resetting 
during non-user payloads
URL   : https://patchwork.freedesktop.org/series/56716/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3473db45d1ed drm/i915/selftests: Exercise resetting during non-user payloads
-:35: WARNING:LINE_SPACING: Missing a blank line after declarations
#35: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:427:
+   struct drm_file *file;
+   IGT_TIMEOUT(end_time);

-:153: WARNING:LINE_SPACING: Missing a blank line after declarations
#153: FILE: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:545:
+   unsigned int count;
+   IGT_TIMEOUT(end_time);

total: 0 errors, 2 warnings, 0 checks, 229 lines checked
fc54b0e0ee61 drm/i915/selftests: Drop unnecessary struct_mutex around 
i915_reset()

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

[Intel-gfx] [PATCH v2 3/3] drm/dsc: Split DSC PPS and SDP header initialisations

2019-02-15 Thread David Francis
The DP 1.4 spec defines the SDP header and SDP contents for
a Picture Parameter Set (PPS) that must be sent in advance
of DSC transmission to define the encoding characteristics.

This was done in one struct, drm_dsc_pps_infoframe, which
conatined the SDP header and PPS.  Because the PPS is
a property of DSC over any connector, not just DP, and because
drm drivers may have their own SDP structs they wish to use,
make the functions that initialise SDP and PPS headers take
the components they operate on, not drm_dsc_pps_infoframe,

Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dsc.c | 117 +++---
 drivers/gpu/drm/i915/intel_vdsc.c |   4 +-
 include/drm/drm_dsc.h |   4 +-
 3 files changed, 62 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index d77570bf6ac4..77f4e5ae4197 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -32,66 +32,65 @@
 /**
  * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
  * for DisplayPort as per the DP 1.4 spec.
- * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
- *   as defined in  drm_dsc_pps_infoframe
+ * @pps_header: Secondary data packet header for DSC Picture
+ *  Parameter Set as defined in  dp_sdp_header
  *
  * DP 1.4 spec defines the secondary data packet for sending the
  * picture parameter infoframes from the source to the sink.
- * This function populates the pps header defined in
- *  drm_dsc_pps_infoframe as per the header bytes defined
- * in  dp_sdp_header.
+ * This function populates the SDP header defined in
+ *  dp_sdp_header.
  */
-void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
+void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header)
 {
-   memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
+   memset(pps_header, 0, sizeof(*pps_header));
 
-   pps_sdp->pps_header.HB1 = DP_SDP_PPS;
-   pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
+   pps_header->HB1 = DP_SDP_PPS;
+   pps_header->HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
 }
 EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
 
 /**
- * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
+ * drm_dsc_pps_payload_pack() - Populates the DSC PPS
  *
- * @pps_sdp:
- * Secondary data packet for DSC Picture Parameter Set. This is defined
- * by  drm_dsc_pps_infoframe
+ * @pps_payload:
+ * Bitwise struct for DSC Picture Parameter Set. This is defined
+ * by  drm_dsc_picture_parameter_set
  * @dsc_cfg:
  * DSC Configuration data filled by driver as defined by
  *  drm_dsc_config
  *
- * DSC source device sends a secondary data packet filled with all the
- * picture parameter set (PPS) information required by the sink to decode
- * the compressed frame. Driver populates the dsC PPS infoframe using the DSC
- * configuration parameters in the order expected by the DSC Display Sink
- * device. For the DSC, the sink device expects the PPS payload in the big
- * endian format for the fields that span more than 1 byte.
+ * DSC source device sends a picture parameter set (PPS) containing the
+ * information required by the sink to decode the compressed frame. Driver
+ * populates the DSC PPS struct using the DSC configuration parameters in
+ * the order expected by the DSC Display Sink device. For the DSC, the sink
+ * device expects the PPS payload in big endian format for fields
+ * that span more than 1 byte.
  */
-void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
+void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set 
*pps_payload,
const struct drm_dsc_config *dsc_cfg)
 {
int i;
 
/* Protect against someone accidently changing struct size */
-   BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
+   BUILD_BUG_ON(sizeof(*pps_payload) !=
 DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
 
-   memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
+   memset(pps_payload, 0, sizeof(*pps_payload));
 
/* PPS 0 */
-   pps_sdp->pps_payload.dsc_version =
+   pps_payload->dsc_version =
dsc_cfg->dsc_version_minor |
dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
 
/* PPS 1, 2 is 0 */
 
/* PPS 3 */
-   pps_sdp->pps_payload.pps_3 =
+   pps_payload->pps_3 =
dsc_cfg->line_buf_depth |
dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
 
/* PPS 4 */
-   pps_sdp->pps_payload.pps_4 =
+   pps_payload->pps_4 =
((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
 DSC_PPS_MSB_SHIFT) |
dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
@@ -100,7 +99,7 @@ void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe 
*pps_sdp,
dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
 
  

[Intel-gfx] [PATCH v2 0/3] Make DRM DSC helpers more generally usable

2019-02-15 Thread David Francis
drm_dsc could use some work so that drm drivers other than
i915 can make use of it their own DSC implementations

Move rc compute, a function that forms part of the DSC spec,
into drm. Update it to DSC 1.2. Also split the PPS packing and
SDP header init functions, to allow for drivers with
their own SDP struct headers

v2:
Rebase onto drm-next
Refactor drm_dsc_dp_pps_header_init
Clean up documentation on new drm function

David Francis (3):
  drm/i915: Move dsc rate params compute into drm
  drm/dsc: Add native 420 and 422 support to compute_rc_params
  drm/dsc: Split DSC PPS and SDP header initialisations

 drivers/gpu/drm/drm_dsc.c | 269 +++---
 drivers/gpu/drm/i915/intel_vdsc.c | 133 +--
 include/drm/drm_dsc.h |   9 +-
 3 files changed, 219 insertions(+), 192 deletions(-)

-- 
2.17.1

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

[Intel-gfx] [PATCH v2 1/3] drm/i915: Move dsc rate params compute into drm

2019-02-15 Thread David Francis
The function intel_compute_rc_parameters is part of the dsc spec
and is not driver-specific. Other drm drivers might like to use
it.  The function is not changed; just moved and renamed.

Reviewed-by: Harry Wentland 
Signed-off-by: David Francis 
---
 drivers/gpu/drm/drm_dsc.c | 135 ++
 drivers/gpu/drm/i915/intel_vdsc.c | 125 +--
 include/drm/drm_dsc.h |   1 +
 3 files changed, 137 insertions(+), 124 deletions(-)

diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index bce99f95c1a3..b7f1903508a4 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -244,3 +245,137 @@ void drm_dsc_pps_infoframe_pack(struct 
drm_dsc_pps_infoframe *pps_sdp,
/* PPS 94 - 127 are O */
 }
 EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
+
+/**
+ * drm_dsc_compute_rc_parameters() - Write rate control
+ * parameters to the dsc configuration defined in
+ *  drm_dsc_config in accordance with the DSC 1.1
+ * specification. Some configuration fields must be present
+ * beforehand.
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
+{
+   unsigned long groups_per_line = 0;
+   unsigned long groups_total = 0;
+   unsigned long num_extra_mux_bits = 0;
+   unsigned long slice_bits = 0;
+   unsigned long hrd_delay = 0;
+   unsigned long final_scale = 0;
+   unsigned long rbs_min = 0;
+
+   /* Number of groups used to code each line of a slice */
+   groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
+  DSC_RC_PIXELS_PER_GROUP);
+
+   /* chunksize in Bytes */
+   vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
+ vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+
+   if (vdsc_cfg->convert_rgb)
+   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
+ (4 * vdsc_cfg->bits_per_component + 4)
+ - 2);
+   else
+   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
+   (4 * vdsc_cfg->bits_per_component + 4) +
+   2 * (4 * vdsc_cfg->bits_per_component) - 2;
+   /* Number of bits in one Slice */
+   slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
+
+   while ((num_extra_mux_bits > 0) &&
+  ((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
+   num_extra_mux_bits--;
+
+   if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
+   vdsc_cfg->initial_scale_value = groups_per_line + 8;
+
+   /* scale_decrement_interval calculation according to DSC spec 1.11 */
+   if (vdsc_cfg->initial_scale_value > 8)
+   vdsc_cfg->scale_decrement_interval = groups_per_line /
+   (vdsc_cfg->initial_scale_value - 8);
+   else
+   vdsc_cfg->scale_decrement_interval = 
DSC_SCALE_DECREMENT_INTERVAL_MAX;
+
+   vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
+   (vdsc_cfg->initial_xmit_delay *
+vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
+
+   if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
+   DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
InitialXmitDelay\n");
+   return -ERANGE;
+   }
+
+   final_scale = (vdsc_cfg->rc_model_size * 8) /
+   (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
+   if (vdsc_cfg->slice_height > 1)
+   /*
+* NflBpgOffset is 16 bit value with 11 fractional bits
+* hence we multiply by 2^11 for preserving the
+* fractional part
+*/
+   vdsc_cfg->nfl_bpg_offset = 
DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
+   (vdsc_cfg->slice_height 
- 1));
+   else
+   vdsc_cfg->nfl_bpg_offset = 0;
+
+   /* 2^16 - 1 */
+   if (vdsc_cfg->nfl_bpg_offset > 65535) {
+   DRM_DEBUG_KMS("NflBpgOffset is too large for this slice 
height\n");
+   return -ERANGE;
+   }
+
+   /* Number of groups used to code the entire slice */
+   groups_total = groups_per_line * vdsc_cfg->slice_height;
+
+   /* slice_bpg_offset is 16 bit value with 11 fractional bits */
+   vdsc_cfg->slice_bpg_offset = DIV_ROUND_UP(((vdsc_cfg->rc_model_size -
+   vdsc_cfg->initial_offset +
+   num_extra_mux_bits) << 11),
+ groups_total);
+
+   if (final_scale > 9) {
+   

[Intel-gfx] [PATCH] drm/i915: Reduce the RPS shock

2019-02-15 Thread Chris Wilson
Limit deboosting and boosting to keep ourselves at the extremes
when in the respective power modes (i.e. slowly decrease frequencies
while in the HIGH_POWER zone and slowly increase frequencies while
in the LOW_POWER zone). On idle, we will hit the timeout and drop
to the next level quickly, and conversely if busy we expect to
hit a waitboost and rapidly switch into max power.

This should improve the UX experience by keeping the GPU clocks higher
than they ostensibly should be (based on simple busyness) by switching
into the INTERACTIVE mode (due to waiting for pageflips) and increasing
clocks via waitboosting. This will incur some additional power, our
saving grace should be rc6 and powergating to keep the extra current
draw in check.

Food for future thought would be deadline scheduling? If we know certain
contexts (high priority compositors) absolutely must hit the next vblank
then we can raise the frequencies ahead of time. Part of this is covered
by per-context frequencies, where userspace is given control over the
frequency range they want the GPU to execute at (for largely the same
problem as this, where the workload is very latency sensitive but at the
EI level appears mostly idle). Indeed, the per-context series does
extend the modeset boosting to include a frequency range tweak which
seems applicable to solving this jittery UX behaviour.

Reported-by: Lyude Paul 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408
References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj")
References: 60548c554be2 ("drm/i915: Interactive RPS mode")
Signed-off-by: Chris Wilson 
Cc: Lyude Paul 
Cc: Eero Tamminen 
Cc: Joonas Lahtinen 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_irq.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 441d2674b272..d26e3d19c993 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1288,6 +1288,18 @@ static void gen6_pm_rps_work(struct work_struct *work)
 
rps->last_adj = adj;
 
+   /*
+* Limit deboosting and boosting to keep ourselves at the extremes
+* when in the respective power modes (i.e. slowly decrease frequencies
+* while in the HIGH_POWER zone and slowly increase frequencies while
+* in the LOW_POWER zone). On idle, we will hit the timeout and drop
+* to the next level quickly, and conversely if busy we expect to
+* hit a waitboost and rapidly switch into max power.
+*/
+   if ((adj < 0 && rps->power.mode == HIGH_POWER) ||
+   (adj > 0 && rps->power.mode == LOW_POWER))
+   rps->last_adj = 0;
+
/* sysfs frequency interfaces may have snuck in while servicing the
 * interrupt
 */
-- 
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/fbdev: Actually configure untiled displays

2019-02-15 Thread Chris Wilson
Quoting Maarten Lankhorst (2019-02-15 16:02:40)
> Op 15-02-2019 om 13:30 schreef Chris Wilson:
> > If we skipped all the connectors that were not part of a tile, we would
> > leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> > had stagnated in our configuration attempts. Avoid this situation by
> > starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
> > connectors to configure.
> >
> > Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on 
> > stagnation")
> > Reported-by: Maarten Lankhorst 
> > Signed-off-by: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index 376ffe842e26..e8f694b57b8a 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -338,8 +338,8 @@ static bool intel_fb_initial_config(struct 
> > drm_fb_helper *fb_helper,
> >   bool *enabled, int width, int height)
> >  {
> >   struct drm_i915_private *dev_priv = to_i915(fb_helper->dev);
> > - unsigned long conn_configured, conn_seq, mask;
> >   unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
> > + unsigned long conn_configured, conn_seq;
> >   int i, j;
> >   bool *save_enabled;
> >   bool fallback = true, ret = true;
> > @@ -357,10 +357,9 @@ static bool intel_fb_initial_config(struct 
> > drm_fb_helper *fb_helper,
> >   drm_modeset_backoff();
> >  
> >   memcpy(save_enabled, enabled, count);
> > - mask = GENMASK(count - 1, 0);
> > + conn_seq = GENMASK(count - 1, 0);
> >   conn_configured = 0;
> >  retry:
> > - conn_seq = conn_configured;
> >   for (i = 0; i < count; i++) {
> >   struct drm_fb_helper_connector *fb_conn;
> >   struct drm_connector *connector;
> > @@ -373,7 +372,8 @@ static bool intel_fb_initial_config(struct 
> > drm_fb_helper *fb_helper,
> >   if (conn_configured & BIT(i))
> >   continue;
> >  
> > - if (conn_seq == 0 && !connector->has_tile)
> > + /* First pass, only consider tiled connectors */
> > + if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
> >   continue;
> >  
> >   if (connector->status == connector_status_connected)
> > @@ -477,8 +477,10 @@ static bool intel_fb_initial_config(struct 
> > drm_fb_helper *fb_helper,
> >   conn_configured |= BIT(i);
> >   }
> >  
> > - if ((conn_configured & mask) != mask && conn_configured != conn_seq)
> > + if (conn_configured != conn_seq) { /* repeat until no more are found 
> > */
> > + conn_seq = conn_configured;
> >   goto retry;
> > + }
> >  
> >   /*
> >* If the BIOS didn't enable everything it could, fall back to have 
> > the
> 
> Also Cc:  # v3.19+ , because it fixes a previous 
> stable fix?

I put the fixes there, the rest I leave to maintainers and AUTOSEL :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Actually configure untiled displays

2019-02-15 Thread Maarten Lankhorst
Op 15-02-2019 om 13:30 schreef Chris Wilson:
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation by
> starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
> connectors to configure.
>
> Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on 
> stagnation")
> Reported-by: Maarten Lankhorst 
> Signed-off-by: Chris Wilson 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 376ffe842e26..e8f694b57b8a 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -338,8 +338,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   bool *enabled, int width, int height)
>  {
>   struct drm_i915_private *dev_priv = to_i915(fb_helper->dev);
> - unsigned long conn_configured, conn_seq, mask;
>   unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
> + unsigned long conn_configured, conn_seq;
>   int i, j;
>   bool *save_enabled;
>   bool fallback = true, ret = true;
> @@ -357,10 +357,9 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   drm_modeset_backoff();
>  
>   memcpy(save_enabled, enabled, count);
> - mask = GENMASK(count - 1, 0);
> + conn_seq = GENMASK(count - 1, 0);
>   conn_configured = 0;
>  retry:
> - conn_seq = conn_configured;
>   for (i = 0; i < count; i++) {
>   struct drm_fb_helper_connector *fb_conn;
>   struct drm_connector *connector;
> @@ -373,7 +372,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   if (conn_configured & BIT(i))
>   continue;
>  
> - if (conn_seq == 0 && !connector->has_tile)
> + /* First pass, only consider tiled connectors */
> + if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
>   continue;
>  
>   if (connector->status == connector_status_connected)
> @@ -477,8 +477,10 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   conn_configured |= BIT(i);
>   }
>  
> - if ((conn_configured & mask) != mask && conn_configured != conn_seq)
> + if (conn_configured != conn_seq) { /* repeat until no more are found */
> + conn_seq = conn_configured;
>   goto retry;
> + }
>  
>   /*
>* If the BIOS didn't enable everything it could, fall back to have the

Also Cc:  # v3.19+ , because it fixes a previous stable 
fix?

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

Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Actually configure untiled displays

2019-02-15 Thread Maarten Lankhorst
Op 15-02-2019 om 13:30 schreef Chris Wilson:
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation by
> starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
> connectors to configure.
>
> Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on 
> stagnation")
> Reported-by: Maarten Lankhorst 
> Signed-off-by: Chris Wilson 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 376ffe842e26..e8f694b57b8a 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -338,8 +338,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   bool *enabled, int width, int height)
>  {
>   struct drm_i915_private *dev_priv = to_i915(fb_helper->dev);
> - unsigned long conn_configured, conn_seq, mask;
>   unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
> + unsigned long conn_configured, conn_seq;
>   int i, j;
>   bool *save_enabled;
>   bool fallback = true, ret = true;
> @@ -357,10 +357,9 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   drm_modeset_backoff();
>  
>   memcpy(save_enabled, enabled, count);
> - mask = GENMASK(count - 1, 0);
> + conn_seq = GENMASK(count - 1, 0);
>   conn_configured = 0;
>  retry:
> - conn_seq = conn_configured;
>   for (i = 0; i < count; i++) {
>   struct drm_fb_helper_connector *fb_conn;
>   struct drm_connector *connector;
> @@ -373,7 +372,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   if (conn_configured & BIT(i))
>   continue;
>  
> - if (conn_seq == 0 && !connector->has_tile)
> + /* First pass, only consider tiled connectors */
> + if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
>   continue;
>  
>   if (connector->status == connector_status_connected)
> @@ -477,8 +477,10 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
> *fb_helper,
>   conn_configured |= BIT(i);
>   }
>  
> - if ((conn_configured & mask) != mask && conn_configured != conn_seq)
> + if (conn_configured != conn_seq) { /* repeat until no more are found */
> + conn_seq = conn_configured;
>   goto retry;
> + }
>  
>   /*
>* If the BIOS didn't enable everything it could, fall back to have the

Seems safer than the previous version.

We should really unloop this in a helper, but this is ok for now if BAT passes.

Reviewed-by: Maarten Lankhorst 

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftests: Drop unnecessary struct_mutex around i915_reset()

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-02-15 15:21:11)
>> Chris Wilson  writes:
>> 
>> > Since we no longer need to hold struct_mutex to perform a global device
>> > reset, don't do so for igt_reset_wedge().
>> >
>> 
>> Oh but the interesting question is not about need, but should =)
>> Do it both ways?
>
> Just doing it without should be enough for lockdep, and specifically
> remember to guard everything with lockdep_assert_held() when required.
> The reverse case of testing with it held can only prove a deadlock by
> hitting it! (At which point CI reboots the machine.)

Not much value to prove that the old model works with new rules,
Reviewed-by: Mika Kuoppala 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Exercise resetting during non-user payloads

2019-02-15 Thread Chris Wilson
Quoting Mika Kuoppala (2019-02-15 15:18:08)
> Chris Wilson  writes:
> 
> > In selftests/live_hangcheck, we have a lot of tests for resetting simple
> > spinners, but nothing quite prepared us for how the GPU reacted to
> > triggering a reset outside of the safe spinner. These two subtests fill
> > the ring with plain old empty, non-spinning requests, and then triggers
> > a reset. Without a user-payload to blame, these requests will exercise
> > the 'non-started' paths and mostly be replayed verbatim.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  .../gpu/drm/i915/selftests/intel_hangcheck.c  | 217 ++
> >  1 file changed, 217 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > index 92475596ff40..f75cb56ff8ad 100644
> > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > @@ -415,6 +415,221 @@ static bool wait_for_idle(struct intel_engine_cs 
> > *engine)
> >   return wait_for(intel_engine_is_idle(engine), IGT_IDLE_TIMEOUT) == 0;
> >  }
> >  
> > +static int igt_reset_nop(void *arg)
> > +{
> > + struct drm_i915_private *i915 = arg;
> > + struct intel_engine_cs *engine;
> > + struct i915_gem_context *ctx;
> > + unsigned int reset_count, count;
> > + enum intel_engine_id id;
> > + intel_wakeref_t wakeref;
> > + struct drm_file *file;
> > + IGT_TIMEOUT(end_time);
> > + int err = 0;
> > +
> > + /* Check that we can reset during non-user portions of requests */
> > +
> > + file = mock_file(i915);
> > + if (IS_ERR(file))
> > + return PTR_ERR(file);
> > +
> > + mutex_lock(>drm.struct_mutex);
> > + ctx = live_context(i915, file);
> > + mutex_unlock(>drm.struct_mutex);
> > + if (IS_ERR(ctx)) {
> > + err = PTR_ERR(ctx);
> > + goto out;
> > + }
> > +
> > + wakeref = intel_runtime_pm_get(i915);
> > +
> > + reset_count = i915_reset_count(>gpu_error);
> > + count = 0;
> > + do {
> > + mutex_lock(>drm.struct_mutex);
> > + for_each_engine(engine, i915, id) {
> > + int i;
> > +
> > + for (i = 0; i < 16; i++) {
> > + struct i915_request *rq;
> > +
> > + rq = i915_request_alloc(engine, ctx);
> > + if (IS_ERR(rq)) {
> > + err = PTR_ERR(rq);
> > + break;
> > + }
> > +
> > + i915_request_add(rq);
> > + }
> > + }
> > + mutex_unlock(>drm.struct_mutex);
> > +
> > + igt_global_reset_lock(i915);
> > + i915_reset(i915, ALL_ENGINES, NULL);
> > + igt_global_reset_unlock(i915);
> > + if (i915_terminally_wedged(>gpu_error)) {
> > + err = -EIO;
> > + break;
> > + }
> > +
> > + if (i915_reset_count(>gpu_error) !=
> > + reset_count + ++count) {
> > + pr_err("Full GPU reset not recorded!\n");
> > + err = -EINVAL;
> > + break;
> > + }
> > +
> > + if (!i915_reset_flush(i915)) {
> > + struct drm_printer p =
> > + drm_info_printer(i915->drm.dev);
> > +
> > + pr_err("%s failed to idle after reset\n",
> > +engine->name);
> > + intel_engine_dump(engine, ,
> > +   "%s\n", engine->name);
> > +
> > + err = -EIO;
> > + break;
> > + }
> > +
> > + err = igt_flush_test(i915, 0);
> > + if (err)
> > + break;
> > + } while (time_before(jiffies, end_time));
> > + pr_info("%s: %d resets\n", __func__, count);
> > +
> > + mutex_lock(>drm.struct_mutex);
> > + err = igt_flush_test(i915, I915_WAIT_LOCKED);
> > + mutex_unlock(>drm.struct_mutex);
> > +
> > + intel_runtime_pm_put(i915, wakeref);
> > +
> > +out:
> > + mock_file_free(i915, file);
> > + if (i915_terminally_wedged(>gpu_error))
> > + err = -EIO;
> > + return err;
> > +}
> > +
> > +static int igt_reset_nop_engine(void *arg)
> > +{
> > + struct drm_i915_private *i915 = arg;
> > + struct intel_engine_cs *engine;
> > + struct i915_gem_context *ctx;
> > + enum intel_engine_id id;
> > + intel_wakeref_t wakeref;
> > + struct drm_file *file;
> > + int err = 0;
> 
> err = 0 for the gcc as it seems unnecessary. Regardless
> I didn't spot anything out of place in this patch. 

It's copy'n'paste. There probably isn't a path where it isn't set, but
I've been 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftests: Drop unnecessary struct_mutex around i915_reset()

2019-02-15 Thread Chris Wilson
Quoting Mika Kuoppala (2019-02-15 15:21:11)
> Chris Wilson  writes:
> 
> > Since we no longer need to hold struct_mutex to perform a global device
> > reset, don't do so for igt_reset_wedge().
> >
> 
> Oh but the interesting question is not about need, but should =)
> Do it both ways?

Just doing it without should be enough for lockdep, and specifically
remember to guard everything with lockdep_assert_held() when required.
The reverse case of testing with it held can only prove a deadlock by
hitting it! (At which point CI reboots the machine.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftests: Drop unnecessary struct_mutex around i915_reset()

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> Since we no longer need to hold struct_mutex to perform a global device
> reset, don't do so for igt_reset_wedge().
>

Oh but the interesting question is not about need, but should =)
Do it both ways?

-Mika

> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index f75cb56ff8ad..57e02840be9e 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -399,10 +399,8 @@ static int igt_wedged_reset(void *arg)
>  
>   i915_gem_set_wedged(i915);
>  
> - mutex_lock(>drm.struct_mutex);
>   GEM_BUG_ON(!i915_terminally_wedged(>gpu_error));
>   i915_reset(i915, ALL_ENGINES, NULL);
> - mutex_unlock(>drm.struct_mutex);
>  
>   intel_runtime_pm_put(i915, wakeref);
>   igt_global_reset_unlock(i915);
> -- 
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Exercise resetting during non-user payloads

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> In selftests/live_hangcheck, we have a lot of tests for resetting simple
> spinners, but nothing quite prepared us for how the GPU reacted to
> triggering a reset outside of the safe spinner. These two subtests fill
> the ring with plain old empty, non-spinning requests, and then triggers
> a reset. Without a user-payload to blame, these requests will exercise
> the 'non-started' paths and mostly be replayed verbatim.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  .../gpu/drm/i915/selftests/intel_hangcheck.c  | 217 ++
>  1 file changed, 217 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index 92475596ff40..f75cb56ff8ad 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -415,6 +415,221 @@ static bool wait_for_idle(struct intel_engine_cs 
> *engine)
>   return wait_for(intel_engine_is_idle(engine), IGT_IDLE_TIMEOUT) == 0;
>  }
>  
> +static int igt_reset_nop(void *arg)
> +{
> + struct drm_i915_private *i915 = arg;
> + struct intel_engine_cs *engine;
> + struct i915_gem_context *ctx;
> + unsigned int reset_count, count;
> + enum intel_engine_id id;
> + intel_wakeref_t wakeref;
> + struct drm_file *file;
> + IGT_TIMEOUT(end_time);
> + int err = 0;
> +
> + /* Check that we can reset during non-user portions of requests */
> +
> + file = mock_file(i915);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + mutex_lock(>drm.struct_mutex);
> + ctx = live_context(i915, file);
> + mutex_unlock(>drm.struct_mutex);
> + if (IS_ERR(ctx)) {
> + err = PTR_ERR(ctx);
> + goto out;
> + }
> +
> + wakeref = intel_runtime_pm_get(i915);
> +
> + reset_count = i915_reset_count(>gpu_error);
> + count = 0;
> + do {
> + mutex_lock(>drm.struct_mutex);
> + for_each_engine(engine, i915, id) {
> + int i;
> +
> + for (i = 0; i < 16; i++) {
> + struct i915_request *rq;
> +
> + rq = i915_request_alloc(engine, ctx);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + break;
> + }
> +
> + i915_request_add(rq);
> + }
> + }
> + mutex_unlock(>drm.struct_mutex);
> +
> + igt_global_reset_lock(i915);
> + i915_reset(i915, ALL_ENGINES, NULL);
> + igt_global_reset_unlock(i915);
> + if (i915_terminally_wedged(>gpu_error)) {
> + err = -EIO;
> + break;
> + }
> +
> + if (i915_reset_count(>gpu_error) !=
> + reset_count + ++count) {
> + pr_err("Full GPU reset not recorded!\n");
> + err = -EINVAL;
> + break;
> + }
> +
> + if (!i915_reset_flush(i915)) {
> + struct drm_printer p =
> + drm_info_printer(i915->drm.dev);
> +
> + pr_err("%s failed to idle after reset\n",
> +engine->name);
> + intel_engine_dump(engine, ,
> +   "%s\n", engine->name);
> +
> + err = -EIO;
> + break;
> + }
> +
> + err = igt_flush_test(i915, 0);
> + if (err)
> + break;
> + } while (time_before(jiffies, end_time));
> + pr_info("%s: %d resets\n", __func__, count);
> +
> + mutex_lock(>drm.struct_mutex);
> + err = igt_flush_test(i915, I915_WAIT_LOCKED);
> + mutex_unlock(>drm.struct_mutex);
> +
> + intel_runtime_pm_put(i915, wakeref);
> +
> +out:
> + mock_file_free(i915, file);
> + if (i915_terminally_wedged(>gpu_error))
> + err = -EIO;
> + return err;
> +}
> +
> +static int igt_reset_nop_engine(void *arg)
> +{
> + struct drm_i915_private *i915 = arg;
> + struct intel_engine_cs *engine;
> + struct i915_gem_context *ctx;
> + enum intel_engine_id id;
> + intel_wakeref_t wakeref;
> + struct drm_file *file;
> + int err = 0;

err = 0 for the gcc as it seems unnecessary. Regardless
I didn't spot anything out of place in this patch. 

The amount of 16 requests feels low as a number but
we should have plenty of time to hit the button during.

Nice addition to reset tests. And as you mentioned
we should have plenty of resets going in on idle engines
on other tests. Not that someone would object one explicit
test into this file :)

Reviewed-by: Mika Kuoppala 


> +
> + /* Check that we can engine-reset during non-user 

Re: [Intel-gfx] [RFC PATCH 03/42] drm/i915: buddy allocator

2019-02-15 Thread Chris Wilson
Quoting Jani Nikula (2019-02-15 12:34:02)
> Please replace the above with
> 
> // SPDX-License-Identifier: MIT
> /*
>  * Copyright © 2019 Intel Corporation
>  */
> 
> Ditto for all new files being added. (Except .h which will need to have
> old style /* ... */ comments around the first line.)

Rebel against the overlords imposing C++ comments upon us; we will
remain clean! I really do not see the point in using C++ for this one
instance, the perl regex is not any harder to write...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/2] i915/gem_eio: Check average reset times

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-02-15 14:40:30)
>> Chris Wilson  writes:
>> 
>> > As we have moved to rcu/srcu to serialise the resets, individual resets
>> > are subject to small variations in system grace periods. Allow for this
>> > by only expecting the median reset time to be within our target, thereby
>> > excluding noisy outliers from perturbing our results (but keep the
>> > maximum capped to prevent horrid failures!)
>> >
>> > Signed-off-by: Chris Wilson 
>> > ---
>> >  tests/i915/gem_eio.c | 53 ++--
>> >  1 file changed, 41 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
>> > index 61054a07e..bd5266104 100644
>> > --- a/tests/i915/gem_eio.c
>> > +++ b/tests/i915/gem_eio.c
>> > @@ -42,6 +42,7 @@
>> >  
>> >  #include "igt.h"
>> >  #include "igt_device.h"
>> > +#include "igt_stats.h"
>> >  #include "igt_sysfs.h"
>> >  #include "sw_sync.h"
>> >  #include "i915/gem_ring.h"
>> > @@ -239,10 +240,9 @@ static void hang_after(int fd, unsigned int us, 
>> > struct timespec *ts)
>> >   igt_assert_eq(timer_settime(ctx->timer, 0, , NULL), 0);
>> >  }
>> >  
>> > -static void check_wait(int fd, uint32_t bo, unsigned int wait)
>> > +static void check_wait(int fd, uint32_t bo, unsigned int wait, 
>> > igt_stats_t *st)
>> >  {
>> >   struct timespec ts = {};
>> > - uint64_t elapsed;
>> >  
>> >   if (wait) {
>> >   hang_after(fd, wait, );
>> > @@ -253,10 +253,34 @@ static void check_wait(int fd, uint32_t bo, unsigned 
>> > int wait)
>> >  
>> >   gem_sync(fd, bo);
>> >  
>> > - elapsed = igt_nsec_elapsed();
>> > - igt_assert_f(elapsed < 250e6,
>> > -  "Wake up following reset+wedge took %.3fms\n",
>> > -  elapsed*1e-6);
>> > + if (st)
>> > + igt_stats_push(st, igt_nsec_elapsed());
>> 
>> You prolly want igt_nsec_elapsed() primed regardless
>> of wait, otherwise I see -1 pushed polluting the stats.
>
> It is...
>
> if (wait)
>   hang_after() sets ts start point
> else
>   we set ts start point.

Indeed. It would have helped to read the
parameters for hang_after.

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

Re: [Intel-gfx] [PATCH i-g-t 1/2] i915/gem_eio: Check average reset times

2019-02-15 Thread Chris Wilson
Quoting Mika Kuoppala (2019-02-15 14:40:30)
> Chris Wilson  writes:
> 
> > As we have moved to rcu/srcu to serialise the resets, individual resets
> > are subject to small variations in system grace periods. Allow for this
> > by only expecting the median reset time to be within our target, thereby
> > excluding noisy outliers from perturbing our results (but keep the
> > maximum capped to prevent horrid failures!)
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  tests/i915/gem_eio.c | 53 ++--
> >  1 file changed, 41 insertions(+), 12 deletions(-)
> >
> > diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> > index 61054a07e..bd5266104 100644
> > --- a/tests/i915/gem_eio.c
> > +++ b/tests/i915/gem_eio.c
> > @@ -42,6 +42,7 @@
> >  
> >  #include "igt.h"
> >  #include "igt_device.h"
> > +#include "igt_stats.h"
> >  #include "igt_sysfs.h"
> >  #include "sw_sync.h"
> >  #include "i915/gem_ring.h"
> > @@ -239,10 +240,9 @@ static void hang_after(int fd, unsigned int us, struct 
> > timespec *ts)
> >   igt_assert_eq(timer_settime(ctx->timer, 0, , NULL), 0);
> >  }
> >  
> > -static void check_wait(int fd, uint32_t bo, unsigned int wait)
> > +static void check_wait(int fd, uint32_t bo, unsigned int wait, igt_stats_t 
> > *st)
> >  {
> >   struct timespec ts = {};
> > - uint64_t elapsed;
> >  
> >   if (wait) {
> >   hang_after(fd, wait, );
> > @@ -253,10 +253,34 @@ static void check_wait(int fd, uint32_t bo, unsigned 
> > int wait)
> >  
> >   gem_sync(fd, bo);
> >  
> > - elapsed = igt_nsec_elapsed();
> > - igt_assert_f(elapsed < 250e6,
> > -  "Wake up following reset+wedge took %.3fms\n",
> > -  elapsed*1e-6);
> > + if (st)
> > + igt_stats_push(st, igt_nsec_elapsed());
> 
> You prolly want igt_nsec_elapsed() primed regardless
> of wait, otherwise I see -1 pushed polluting the stats.

It is...

if (wait)
hang_after() sets ts start point
else
we set ts start point.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove the broken DP CRC support for g4x

2019-02-15 Thread Ville Syrjälä
On Thu, Feb 14, 2019 at 06:26:29PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > DP CRCs don't really work on g4x. If you want any CRCs on DP you must
> > select the CRC source before the port is enabled, otherwise the CRC
> > source select bits simply ignore any writes to them. And once the
> > port
> > is enabled we mustn't change the CRC source select until the port is
> > disabled. That almost works, but not quite :( Eventually the CRC
> > source
> > select bits get permanently stuck one way or the other, and after
> > that
> > a reboot (or possibly a display reset) is needed to get working CRCs
> > on that pipe (not matter which CRC source we try to use).
> > 
> > Additionally the DFT scrambler reset bits we're trying to use don't
> > seem to exist on g4x. There are some potentially relevant looking
> > bits
> > in the pipe registers, but when I tried it I got stable looking CRCs
> > without setting any bits for this.
> > 
> > If there is a way to make DP CRCs work reliably on g4x, I wasn't
> > able to find it. So let's just remove the broken code we have.
> 
> 
> I think we can modify i9xx_pipe_crc_auto_source() to pick "pipe" CRC
> when userspace selects "auto" and the output is DP/eDP.

Nope. Spec says:
"Pipe CRC should not be run when Display Port or TV is enabled on this
 pipe."

and

"CRC Source Select: These bits select the source of the data to put into
 the CRC logic.
 000: Pipe A (Not available when DisplayPort or TV is enabled on this
 pipe)"

Though I must admit I've never actually tried it to see what actually
happens.

> 
> 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_pipe_crc.c | 80 -
> > --
> >  1 file changed, 11 insertions(+), 69 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > index fe0ff89b980b..66bb7b031537 100644
> > --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> > +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> > @@ -191,8 +191,6 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > drm_i915_private *dev_priv,
> >  enum intel_pipe_crc_source *source,
> >  u32 *val)
> >  {
> > -   bool need_stable_symbols = false;
> > -
> > if (*source == INTEL_PIPE_CRC_SOURCE_AUTO) {
> > int ret = i9xx_pipe_crc_auto_source(dev_priv, pipe,
> > source);
> > if (ret)
> > @@ -208,56 +206,23 @@ static int i9xx_pipe_crc_ctl_reg(struct
> > drm_i915_private *dev_priv,
> > return -EINVAL;
> > *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_TV_PRE;
> > break;
> > -   case INTEL_PIPE_CRC_SOURCE_DP_B:
> > -   if (!IS_G4X(dev_priv))
> > -   return -EINVAL;
> > -   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_B_G4X;
> > -   need_stable_symbols = true;
> > -   break;
> > -   case INTEL_PIPE_CRC_SOURCE_DP_C:
> > -   if (!IS_G4X(dev_priv))
> > -   return -EINVAL;
> > -   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_G4X;
> > -   need_stable_symbols = true;
> > -   break;
> > -   case INTEL_PIPE_CRC_SOURCE_DP_D:
> > -   if (!IS_G4X(dev_priv))
> > -   return -EINVAL;
> > -   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_G4X;
> > -   need_stable_symbols = true;
> > -   break;
> > case INTEL_PIPE_CRC_SOURCE_NONE:
> > *val = 0;
> > break;
> > default:
> > +   /*
> > +* The DP CRC source doesn't work on g4x.
> > +* It can be made to work to some degree by selecting
> > +* the correct CRC source before the port is enabled,
> > +* and not touching the CRC source bits again until
> > +* the port is disabled. But even then the bits
> > +* eventually get stuck and a reboot is needed to get
> > +* working CRCs on the pipe again. Let's simply
> > +* refuse to use DP CRCs on g4x.
> > +*/z
> > return -EINVAL;
> > }
> >  
> > -   /*
> > -* When the pipe CRC tap point is after the transcoders we need
> > -* to tweak symbol-level features to produce a deterministic
> > series of
> > -* symbols for a given frame. We need to reset those features
> > only once
> > -* a frame (instead of every nth symbol):
> > -*   - DC-balance: used to ensure a better clock recovery from
> > the data
> > -* link (SDVO)
> > -*   - DisplayPort scrambling: used for EMI reduction
> > -*/
> > -   if (need_stable_symbols) {
> > -   u32 tmp = I915_READ(PORT_DFT2_G4X);
> > -
> > -   WARN_ON(!IS_G4X(dev_priv));
> > -
> > -   I915_WRITE(PORT_DFT_I9XX,
> > -  I915_READ(PORT_DFT_I9XX) |
> > DC_BALANCE_RESET);
> > -
> > -   if (pipe == PIPE_A)
> > -  

Re: [Intel-gfx] PR - GuC v31.3.0

2019-02-15 Thread Michal Wajdeczko
On Fri, 15 Feb 2019 05:32:14 +0100, Srivatsa, Anusha  
 wrote:




Resending this again, didn’t get Delivered the last time I sent.


Sending PR for latest Guc v31.3.0 for ICL and Gen9 platforms.

The following changes since commit  
710963fe53ee3f227556d36839df3858daf6e232:


 Merge https://github.com/ajaykuee/linux-firmware (2019-02-13 07:42:20  
-0500)


are available in the Git repository at:

 icl_guc
for you to fetch changes up to 523dc102fcf4a896c0ba9712537f9a371b1086b2:

 firmware/guc/icl: Add new interface guc for ICL (2019-02-14 15:18:53  
-0800)



Anusha Srivatsa (6):
 firmware/guc/bxt: Add new interface guc for BXT
 firmware/guc/skl: Add new interface guc for SKL
 firmware/guc/kbl: Add new interface guc for KBL
 firmware/guc/glk: Add new interface guc for GLK
 firmware/huc/glk: Add huC Supprt for GLK
 firmware/guc/icl: Add new interface guc for ICL

WHENCE |  19 +++
i915/bxt_guc_ver31_3_0.bin | Bin 0 -> 176448 bytes
i915/glk_guc_ver31_3_0.bin | Bin 0 -> 176832 bytes
i915/glk_huc_ver03_01_2893.bin | Bin 0 -> 222080 bytes
i915/icl_guc_31.3.0.bin| Bin 0 -> 378304 bytes
i915/kbl_guc_31.3.0.bin| Bin 0 -> 176448 bytes
i915/skl_guc_31.3.0.bin| Bin 0 -> 175552 bytes
7 files changed, 19 insertions(+)
create mode 100644 i915/bxt_guc_ver31_3_0.bin
create mode 100644 i915/glk_guc_ver31_3_0.bin

There is something wrong with these two fw filenames, driver will expect:

bxt_guc_31.3.0.bin
glk_guc_31.3.0.bin

icl/kbl/skl firmwares listed below are fine.

Michal




create mode 100644 i915/glk_huc_ver03_01_2893.bin

create mode 100644 i915/icl_guc_31.3.0.bin
create mode 100644 i915/kbl_guc_31.3.0.bin
create mode 100644 i915/skl_guc_31.3.0.bin


Thanks,

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove the "pf" crc source

2019-02-15 Thread Ville Syrjälä
On Thu, Feb 14, 2019 at 05:45:31PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-02-14 at 17:32 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2019-02-14 at 21:22 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > The "pipe" and "pf" crc sources are in fact the same thing.
> > > Remove the "pf" one.
> > 
> > And BDW+ seem to call it DMUX output.
> 
> Oh, we need to remove this in IGT too.

Hrm. I wonder why we even have any hardcoded names in igt. It should
only really care about "auto", and if there is any test that wants
something more specific it could just hardocode the string.

-- 
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: Defer application of request banning to submission

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> As we currently do not check on submission whether the context is banned
> in a timely manner it is possible for some requests to escape
> cancellation after their parent context is banned. By moving the ban
> into the request submission under the engine->timeline.lock, we
> serialise it with the reset and setting of the context ban.
>
> References: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on 
> struct_mutex")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_request.c |  3 +++
>  drivers/gpu/drm/i915/i915_reset.c   | 19 +--
>  2 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index 0acd6baa3c88..5ab4e1c01618 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -366,6 +366,9 @@ void __i915_request_submit(struct i915_request *request)
>   GEM_BUG_ON(!irqs_disabled());
>   lockdep_assert_held(>timeline.lock);
>  
> + if (i915_gem_context_is_banned(request->gem_context))
> + i915_request_skip(request, -EIO);
> +
>   GEM_BUG_ON(request->global_seqno);
>  
>   seqno = next_global_seqno(>timeline);
> diff --git a/drivers/gpu/drm/i915/i915_reset.c 
> b/drivers/gpu/drm/i915/i915_reset.c
> index 12e74decd7a2..7fa97ce19bfd 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -22,24 +22,15 @@ static void engine_skip_context(struct i915_request *rq)
>  {
>   struct intel_engine_cs *engine = rq->engine;
>   struct i915_gem_context *hung_ctx = rq->gem_context;
> - struct i915_timeline *timeline = rq->timeline;
>  
>   lockdep_assert_held(>timeline.lock);

This was golden.

> - GEM_BUG_ON(timeline == >timeline);
>  
> - spin_lock(>lock);
> -
> - if (i915_request_is_active(rq)) {
> - list_for_each_entry_continue(rq,
> -  >timeline.requests, link)
> - if (rq->gem_context == hung_ctx)
> - i915_request_skip(rq, -EIO);
> - }
> -
> - list_for_each_entry(rq, >requests, link)
> - i915_request_skip(rq, -EIO);
> + if (!i915_request_is_active(rq))
> + return;

Only thing that got me actually pondering was that
we don't flush anything after we have modify the ring.

But that is not about this patch

Reviewed-by: Mika Kuoppala 


>  
> - spin_unlock(>lock);
> + list_for_each_entry_continue(rq, >timeline.requests, link)
> + if (rq->gem_context == hung_ctx)
> + i915_request_skip(rq, -EIO);
>  }
>  
>  static void client_mark_guilty(struct drm_i915_file_private *file_priv,
> -- 
> 2.20.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

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Ignore performance-only pread/pwrite "tests"

2019-02-15 Thread Chris Wilson
Quoting Petri Latvala (2019-02-15 10:47:09)
> On Fri, Feb 15, 2019 at 10:41:58AM +, Chris Wilson wrote:
> > We don't need to waste time running perf-only test cases when we are not
> > manually checking results. ezbench is that away!
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=109640
> > Signed-off-by: Chris Wilson 
> > ---
> 
> Remove those subtests, put them in benchmarks/ along with an ezbench
> integration script?

It's almost as if they are already there. Except the ezbench integration
scripts predate v1.0, and there's no semi-CI feedback yet so no
motivation...

Though I do like having them around in the test binary as well;
something interesting to read. But I'm weird.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Ignore performance-only pread/pwrite "tests"

2019-02-15 Thread Petri Latvala
On Fri, Feb 15, 2019 at 10:41:58AM +, Chris Wilson wrote:
> We don't need to waste time running perf-only test cases when we are not
> manually checking results. ezbench is that away!
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109640
> Signed-off-by: Chris Wilson 
> ---

Remove those subtests, put them in benchmarks/ along with an ezbench
integration script?

Acked-by: Petri Latvala 


>  tests/intel-ci/blacklist.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
> index 0e6beeae4..2bdc0b25b 100644
> --- a/tests/intel-ci/blacklist.txt
> +++ b/tests/intel-ci/blacklist.txt
> @@ -50,6 +50,7 @@ igt@gem_mmap@.*(swap|huge).*
>  igt@gem_mocs_settings@.*(suspend|hibernate).*
>  igt@gem_pin(@.*)?
>  igt@gem_pread_after_blit(@.*)?
> +igt@gem_pwrite_pread@.*performance.*
>  igt@gem_read_read_speed(@.*)?
>  igt@gem_reloc_overflow(@.*)?
>  igt@gem_reloc_vs_gpu(@.*)?
> -- 
> 2.20.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/2] i915/gem_eio: Allow older platforms more leniency in reset latency

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> Older platforms need to clobber the display around a reset (incl. a
> modeset to off, and a modeset back on), which can be much slower than
> the reset itself. Give these platforms (gen2-4) some leniency and allow
> them a higher limit before declaring them a failure.
>
> Signed-off-by: Chris Wilson 
> ---
>  tests/i915/gem_eio.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> index bd5266104..ac85a2eff 100644
> --- a/tests/i915/gem_eio.c
> +++ b/tests/i915/gem_eio.c
> @@ -259,7 +259,7 @@ static void check_wait(int fd, uint32_t bo, unsigned int 
> wait, igt_stats_t *st)
>  
>  static void check_wait_elapsed(int fd, igt_stats_t *st)
>  {
> - double med, max;
> + double med, max, limit;
>  
>   igt_info("Completed %d resets, wakeups took %.3f+-%.3fms (min:%.3fms, 
> median:%.3fms, max:%.3fms)\n",
>st->n_values,
> @@ -272,15 +272,24 @@ static void check_wait_elapsed(int fd, igt_stats_t *st)
>   if (st->n_values < 9)
>   return; /* too few for stable median */
>  
> + /*
> +  * Older platforms need to reset the display (incl. modeset to off,
> +  * modeset back on) around resets, so may take a lot longer.
> +  */
> + limit = 250e6;
> + if (intel_gen(intel_get_drm_devid(fd)) < 5)
> + limit += 300e6; /* guestimate for 2x worstcase modeset */

Don't have any insight to offer for the hard cap. 550ms sounds
reasonable!

Reviewed-by: Mika Kuoppala 

> +
>   med = igt_stats_get_median(st);
>   max = igt_stats_get_max(st);
> - igt_assert_f(med < 250e6 && max < 1250e6,
> -  "Wake up following reset+wedge took %.3f+-%.3fms 
> (min:%.3fms, median:%.3fms, max:%.3fms)\n",
> + igt_assert_f(med < limit && max < 5 * limit,
> +  "Wake up following reset+wedge took %.3f+-%.3fms 
> (min:%.3fms, median:%.3fms, max:%.3fms); limit set to %.0fms on average and 
> %.0fms maximum\n",
>igt_stats_get_mean(st)*1e-6,
>igt_stats_get_std_deviation(st)*1e-6,
>igt_stats_get_min(st)*1e-6,
>igt_stats_get_median(st)*1e-6,
> -  igt_stats_get_max(st)*1e-6);
> +  igt_stats_get_max(st)*1e-6,
> +  limit*1e-6, limit*5e-6);
>  }
>  
>  static void __test_banned(int fd)
> -- 
> 2.20.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

[Intel-gfx] [PATCH i-g-t] lib: Restore the i915.reset modparam before cleaning up

2019-02-15 Thread Chris Wilson
We force a reset on test exit so that we can rapidly cleanup after a
naughty test, it is not unknown for us to leave a queue of hanging
batches around. However, if we have also fiddled with the i915.reset
parameter in the meantime, this can leave the kernel unable to fulfil
our request (and those naughty batches continue to disrupt testing).

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Petri Latvala 
---
 lib/drmtest.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 1964795a6..6c0a0e381 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -54,6 +54,7 @@
 #include "igt_device.h"
 #include "igt_gt.h"
 #include "igt_kmod.h"
+#include "igt_sysfs.h"
 #include "version.h"
 #include "config.h"
 #include "intel_reg.h"
@@ -345,6 +346,7 @@ static void __cancel_work_at_exit(int fd)
 {
igt_terminate_spin_batches(); /* for older kernels */
 
+   igt_sysfs_set_parameter(fd, "reset", "%x", -1u /* any method */);
igt_drop_caches_set(fd,
/* cancel everything */
DROP_RESET_ACTIVE | DROP_RESET_SEQNO |
-- 
2.20.1

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

Re: [Intel-gfx] [RFC PATCH 03/42] drm/i915: buddy allocator

2019-02-15 Thread Jani Nikula
On Thu, 14 Feb 2019, Matthew Auld  wrote:
> Really simply buddy allocator.
>
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Abdiel Janulgue 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/i915_gem_buddy.c | 206 +
>  drivers/gpu/drm/i915/i915_gem_buddy.h | 118 ++
>  .../gpu/drm/i915/selftests/i915_gem_buddy.c   | 209 ++
>  .../drm/i915/selftests/i915_mock_selftests.h  |   1 +
>  5 files changed, 535 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/i915_gem_buddy.c
>  create mode 100644 drivers/gpu/drm/i915/i915_gem_buddy.h
>  create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_buddy.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 1787e1299b1b..e5ce813d1936 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -61,6 +61,7 @@ i915-y += \
> i915_active.o \
> i915_cmd_parser.o \
> i915_gem_batch_pool.o \
> +   i915_gem_buddy.o \
> i915_gem_clflush.o \
> i915_gem_context.o \
> i915_gem_dmabuf.o \
> diff --git a/drivers/gpu/drm/i915/i915_gem_buddy.c 
> b/drivers/gpu/drm/i915/i915_gem_buddy.c
> new file mode 100644
> index ..4dc688c091a2
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_gem_buddy.c
> @@ -0,0 +1,206 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */

Please replace the above with

// SPDX-License-Identifier: MIT
/*
 * Copyright © 2019 Intel Corporation
 */

Ditto for all new files being added. (Except .h which will need to have
old style /* ... */ comments around the first line.)

BR,
Jani.


> +
> +#include 
> +#include 
> +
> +#include "i915_gem_buddy.h"
> +#include "i915_gem.h"
> +
> +int i915_gem_buddy_init(struct i915_gem_buddy_mm *mm, u64 size, u64 min_size)
> +{
> + unsigned int i;
> +
> + /*
> +  * XXX: if not a power of 2, maybe split into power of 2 blocks,
> +  * effectively having multiple roots, similar to if we had a global
> +  * MAX_ORDER.
> +  */
> + size = rounddown_pow_of_two(size);
> + min_size = roundup_pow_of_two(min_size);
> +
> + if (size < min_size)
> + return -EINVAL;
> +
> + if (min_size < PAGE_SIZE)
> + return -EINVAL;
> +
> + mm->max_order = ilog2(size) - ilog2(min_size);
> + mm->min_size = min_size;
> +
> + mm->free_list = kmalloc_array(mm->max_order + 1,
> +   sizeof(struct list_head),
> +   GFP_KERNEL);
> + if (!mm->free_list)
> + return -ENOMEM;
> +
> + for (i = 0; i <= mm->max_order; ++i)
> + INIT_LIST_HEAD(>free_list[i]);
> +
> + mm->blocks = KMEM_CACHE(i915_gem_buddy_block, SLAB_HWCACHE_ALIGN);
> + if (!mm->blocks)
> + goto out_free_list;
> +
> + mm->root = kmem_cache_zalloc(mm->blocks, GFP_KERNEL);
> + if (!mm->root)
> + goto out_free_blocks;
> +
> + mm->root->header = mm->max_order;
> +
> + list_add(>root->link, >free_list[mm->max_order]);
> +
> + return 0;
> +
> +out_free_blocks:
> + kmem_cache_destroy(mm->blocks);
> +out_free_list:
> + kfree(mm->free_list);
> +
> + return -ENOMEM;
> +}
> +
> +void i915_gem_buddy_fini(struct i915_gem_buddy_mm *mm)
> +{
> + if (WARN_ON(i915_gem_buddy_block_allocated(mm->root)))
> + return;
> +
> + kfree(mm->free_list);
> + kmem_cache_free(mm->blocks, mm->root);
> + kmem_cache_destroy(mm->blocks);
> +}
> +
> +/*
> + * The 'order' here means:
> + *
> + * 0 = 2^0 * mm->min_size
> + * 1 = 2^1 * mm->min_size
> + * 2 = 2^2 * mm->min_size
> + * ...
> + */
> +struct i915_gem_buddy_block *
> +i915_gem_buddy_alloc(struct i915_gem_buddy_mm *mm, unsigned int 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Always use an active engine while resetting

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> Currently, we only try to reset a live engine for checking the whitelist
> retention across a per-engine reset. For safety, it appears we need to
> prime the system with a hanging spinner before performing a full-device
> reset. (Figuring out the root cause behind the instability with handling
> a reset during a no-op request is a challenge for another test, the
> whitelist test has its own purpose.)
>

Agreed on the sentiment and it does what it says on the tin.
Reviewed-by: Mika Kuoppala 

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109626
> Signed-off-by: Chris Wilson 
> ---
>  .../drm/i915/selftests/intel_workarounds.c| 27 ++-
>  1 file changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c 
> b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
> index b15c4f26c593..d6bb2005024d 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_workarounds.c
> @@ -237,14 +237,8 @@ switch_to_scratch_context(struct intel_engine_cs *engine,
>   return PTR_ERR(ctx);
>  
>   rq = ERR_PTR(-ENODEV);
> - with_intel_runtime_pm(engine->i915, wakeref) {
> - if (spin)
> - rq = igt_spinner_create_request(spin,
> - ctx, engine,
> - MI_NOOP);
> - else
> - rq = i915_request_alloc(engine, ctx);
> - }
> + with_intel_runtime_pm(engine->i915, wakeref)
> + rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
>  
>   kernel_context_close(ctx);
>  
> @@ -273,7 +267,6 @@ static int check_whitelist_across_reset(struct 
> intel_engine_cs *engine,
>   const char *name)
>  {
>   struct drm_i915_private *i915 = engine->i915;
> - bool want_spin = reset == do_engine_reset;
>   struct i915_gem_context *ctx;
>   struct igt_spinner spin;
>   intel_wakeref_t wakeref;
> @@ -282,11 +275,9 @@ static int check_whitelist_across_reset(struct 
> intel_engine_cs *engine,
>   pr_info("Checking %d whitelisted registers (RING_NONPRIV) [%s]\n",
>   engine->whitelist.count, name);
>  
> - if (want_spin) {
> - err = igt_spinner_init(, i915);
> - if (err)
> - return err;
> - }
> + err = igt_spinner_init(, i915);
> + if (err)
> + return err;
>  
>   ctx = kernel_context(i915);
>   if (IS_ERR(ctx))
> @@ -298,17 +289,15 @@ static int check_whitelist_across_reset(struct 
> intel_engine_cs *engine,
>   goto out;
>   }
>  
> - err = switch_to_scratch_context(engine, want_spin ?  : NULL);
> + err = switch_to_scratch_context(engine, );
>   if (err)
>   goto out;
>  
>   with_intel_runtime_pm(i915, wakeref)
>   err = reset(engine);
>  
> - if (want_spin) {
> - igt_spinner_end();
> - igt_spinner_fini();
> - }
> + igt_spinner_end();
> + igt_spinner_fini();
>  
>   if (err) {
>   pr_err("%s reset failed\n", name);
> -- 
> 2.20.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

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Drop unnecessary struct_mutex around i915_reset()

2019-02-15 Thread Chris Wilson
Since we no longer need to hold struct_mutex to perform a global device
reset, don't do so for igt_reset_wedge().

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index f75cb56ff8ad..57e02840be9e 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -399,10 +399,8 @@ static int igt_wedged_reset(void *arg)
 
i915_gem_set_wedged(i915);
 
-   mutex_lock(>drm.struct_mutex);
GEM_BUG_ON(!i915_terminally_wedged(>gpu_error));
i915_reset(i915, ALL_ENGINES, NULL);
-   mutex_unlock(>drm.struct_mutex);
 
intel_runtime_pm_put(i915, wakeref);
igt_global_reset_unlock(i915);
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH i-g-t 1/2] i915/gem_eio: Check average reset times

2019-02-15 Thread Mika Kuoppala
Chris Wilson  writes:

> As we have moved to rcu/srcu to serialise the resets, individual resets
> are subject to small variations in system grace periods. Allow for this
> by only expecting the median reset time to be within our target, thereby
> excluding noisy outliers from perturbing our results (but keep the
> maximum capped to prevent horrid failures!)
>
> Signed-off-by: Chris Wilson 
> ---
>  tests/i915/gem_eio.c | 53 ++--
>  1 file changed, 41 insertions(+), 12 deletions(-)
>
> diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> index 61054a07e..bd5266104 100644
> --- a/tests/i915/gem_eio.c
> +++ b/tests/i915/gem_eio.c
> @@ -42,6 +42,7 @@
>  
>  #include "igt.h"
>  #include "igt_device.h"
> +#include "igt_stats.h"
>  #include "igt_sysfs.h"
>  #include "sw_sync.h"
>  #include "i915/gem_ring.h"
> @@ -239,10 +240,9 @@ static void hang_after(int fd, unsigned int us, struct 
> timespec *ts)
>   igt_assert_eq(timer_settime(ctx->timer, 0, , NULL), 0);
>  }
>  
> -static void check_wait(int fd, uint32_t bo, unsigned int wait)
> +static void check_wait(int fd, uint32_t bo, unsigned int wait, igt_stats_t 
> *st)
>  {
>   struct timespec ts = {};
> - uint64_t elapsed;
>  
>   if (wait) {
>   hang_after(fd, wait, );
> @@ -253,10 +253,34 @@ static void check_wait(int fd, uint32_t bo, unsigned 
> int wait)
>  
>   gem_sync(fd, bo);
>  
> - elapsed = igt_nsec_elapsed();
> - igt_assert_f(elapsed < 250e6,
> -  "Wake up following reset+wedge took %.3fms\n",
> -  elapsed*1e-6);
> + if (st)
> + igt_stats_push(st, igt_nsec_elapsed());

You prolly want igt_nsec_elapsed() primed regardless
of wait, otherwise I see -1 pushed polluting the stats.

-Mika


> +}
> +
> +static void check_wait_elapsed(int fd, igt_stats_t *st)
> +{
> + double med, max;
> +
> + igt_info("Completed %d resets, wakeups took %.3f+-%.3fms (min:%.3fms, 
> median:%.3fms, max:%.3fms)\n",
> +  st->n_values,
> +  igt_stats_get_mean(st)*1e-6,
> +  igt_stats_get_std_deviation(st)*1e-6,
> +  igt_stats_get_min(st)*1e-6,
> +  igt_stats_get_median(st)*1e-6,
> +  igt_stats_get_max(st)*1e-6);
> +
> + if (st->n_values < 9)
> + return; /* too few for stable median */
> +
> + med = igt_stats_get_median(st);
> + max = igt_stats_get_max(st);
> + igt_assert_f(med < 250e6 && max < 1250e6,
> +  "Wake up following reset+wedge took %.3f+-%.3fms 
> (min:%.3fms, median:%.3fms, max:%.3fms)\n",
> +  igt_stats_get_mean(st)*1e-6,
> +  igt_stats_get_std_deviation(st)*1e-6,
> +  igt_stats_get_min(st)*1e-6,
> +  igt_stats_get_median(st)*1e-6,
> +  igt_stats_get_max(st)*1e-6);
>  }
>  
>  static void __test_banned(int fd)
> @@ -326,7 +350,7 @@ static void test_wait(int fd, unsigned int flags, 
> unsigned int wait)
>  
>   hang = spin_sync(fd, 0, I915_EXEC_DEFAULT);
>  
> - check_wait(fd, hang->handle, wait);
> + check_wait(fd, hang->handle, wait, NULL);
>  
>   igt_spin_batch_free(fd, hang);
>  
> @@ -401,7 +425,7 @@ static void test_inflight(int fd, unsigned int wait)
>   igt_assert(fence[n] != -1);
>   }
>  
> - check_wait(fd, obj[1].handle, wait);
> + check_wait(fd, obj[1].handle, wait, NULL);
>  
>   for (unsigned int n = 0; n < max; n++) {
>   igt_assert_eq(sync_fence_status(fence[n]), -EIO);
> @@ -457,7 +481,7 @@ static void test_inflight_suspend(int fd)
>   igt_set_autoresume_delay(30);
>   igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
>  
> - check_wait(fd, obj[1].handle, 10);
> + check_wait(fd, obj[1].handle, 10, NULL);
>  
>   for (unsigned int n = 0; n < max; n++) {
>   igt_assert_eq(sync_fence_status(fence[n]), -EIO);
> @@ -535,7 +559,7 @@ static void test_inflight_contexts(int fd, unsigned int 
> wait)
>   igt_assert(fence[n] != -1);
>   }
>  
> - check_wait(fd, obj[1].handle, wait);
> + check_wait(fd, obj[1].handle, wait, NULL);
>  
>   for (unsigned int n = 0; n < ARRAY_SIZE(fence); n++) {
>   igt_assert_eq(sync_fence_status(fence[n]), -EIO);
> @@ -644,7 +668,7 @@ static void test_inflight_internal(int fd, unsigned int 
> wait)
>   nfence++;
>   }
>  
> - check_wait(fd, obj[1].handle, wait);
> + check_wait(fd, obj[1].handle, wait, NULL);
>  
>   while (nfence--) {
>   igt_assert_eq(sync_fence_status(fences[nfence]), -EIO);
> @@ -670,8 +694,11 @@ static void reset_stress(int fd,
>   .buffer_count = 1,
>   .flags = engine,
>   };
> + igt_stats_t stats;
> +
>   gem_write(fd, obj.handle, 0, , sizeof(bbe));
>  
> + 

  1   2   >