Re: [Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote: > > Quoting Joonas Lahtinen (2019-01-15 16:47:27) > > > Hi all, > > > > > > I would like to have some Acked-by's from you, the distro media > > > folks Cc'd here, to document your intent to start using Intel's > > > new media driver[1]. So if you recognize yourself (or are otherwise > > > interested), please read on. > > > > > > TL;DR Distro folks, please give your Acked-by on patch [5/6] > > > > A gentle reminder, I'm still looking to hear back from Stephane > > and Dave. > > > > We'd like to have this included in the final 5.1 drm-intel-next > > pull request this week. > > > > If there are no further comments by Wed, I will conclude that we > > have reached a silent agreement, and merge this to give enough > > time for Rodrigo to send the PR. > > Maybe should add that ubunut/suse folks seem ok. Also, it's for libva, in > the past that's been very far down the list of contentious topics. Mostly > positive meh seems plenty good enough feedback I think. FWIW I think the API changes are fine. Sure it feels a bit odd at first, but there's no better alternative that I can see either. Acked-by: Stéphane Marchesin > -Daniel > > > > > Regards, Joonas > > > > > I believe most are already aware of the situation that Intel > > > is moving to the new codebase for libva backend to support new Intel > > > integrated graphics devices. The existing intel-libva-driver will > > > be continue to be be supported for pre-Icelake platforms ( > > Icelake and further platforms will only be supported from the > > > new codebase. > > > > > > There's the complication that some Icelake features of the new > > > driver will require new kernel uAPIs to work... But the new driver > > > has not yet been well-established in the community from perspective > > > of fulfilling [2]. This is very much due to the demand being low > > > as Icelake is not widely available yet. So it's bit of a chicken > > > and egg problem as we have a new platform *and* a new codebase for > > > it simultaneously. > > > > > > Ahead of that community adoption, to ensure that Icelake has good > > > kernel support from day one, we'd like to merge kernel support for > > > the parts that have functional effect (this series). This is to > > > avoid the scenario where end users have to update their distro > > > kernels, like happened with Skylake. > > > > > > So if I could get Acked-by's from distro folks on the patch [5/6] that > > > adds the new uAPI. That would document their intent to become an active > > > user of the media-driver[1]. If that happens in the next week or two, > > > it would mean that Icelake hardware features would be supported in > > > kernel version 5.1 fully from kernel driver point of view. > > > > > > The new uAPI is needed to make VME feature functionally work > > > on Icelake. It's pretty much a simple enable/disable switch for > > > hardware configuration that only includes hardware slices compatible > > > with the VME workload. So it's currently limited to the required on/off > > > choice to keep things straightforward. The uAPI can be extended in the > > > future for possible performance gains for more fine-grained control. > > > > > > VME is shared function to handle motion estimation. One intended > > > usercase is in Hierarchical Motion Estimation (HME) media kernel. It > > > provides a bigger search range with reduced cost for the search. HME > > > should improve the encode quality with scenarios where the video has > > > a lot of motion in it. Carl (Cc'd) can provide more details if needed. > > > > > > The respective IGT tests are reviewed and can be found at: > > > > > > https://patchwork.freedesktop.org/series/49190/ > > > > > > The userspace changes are reviewed and rebased here: > > > > > > https://github.com/intel/media-driver/pull/271 > > > https://github.com/intel/media-driver/pull/463 > > > > > > Best Regards, Joonas Lahtinen > > > > > > Cc: dri-de...@lists.freedesktop.org > > > Cc: Timo Aaltonen > > > Cc: Takashi Iwai > > > Cc: Stephane Marchesin > > > Cc: Dave Airlie > > > Cc: Daniel Vetter > > > > > > PS. This series might result in some CI failures reported as it adds new > > > uAPI > > > and Patchwork / CI synchronization of tests and kernel is currently > > > WIP. > > > > > > [1] https://github.com/intel/media-driver > > > [2] > > > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > > > > > Lionel Landwerlin (2): > > > drm/i915: Record the sseu configuration per-context & engine > > > drm/i915/perf: lock powergating configuration to default when active > > > > > > Tvrtko Ursulin (4): > > > drm/i915/execlists: Move RPCS setup to context pin > > > drm/i915: Add timeline barrier support > > > drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) > > > drm/i915/selftests: Context SSEU reconfiguration tests
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dsc: Add kernel documentation for DRM DP DSC helpers
== Series Details ==
Series: drm/dsc: Add kernel documentation for DRM DP DSC helpers
URL : https://patchwork.freedesktop.org/series/56206/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5537_full -> Patchwork_12133_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12133_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@runner@aborted}:
- shard-apl: NOTRUN -> ( 10 FAIL ) [fdo#109373]
Known issues
Here are the changes found in Patchwork_12133_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@reset-stress:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@gem_exec_reuse@baggage:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: PASS -> FAIL [fdo#104873]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
Possible fixes
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_cursor_crc@cursor-128x42-random:
- shard-glk: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-64x64-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl: FAIL [fdo#109350] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-apl: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-hsw: FAIL [fdo#99912] -> PASS
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: {SKIP} [fdo#109271] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-glk: DMESG-WARN [fdo#109244] -> INCOMPLETE [fdo#103359] /
[fdo#106886] / [k.org#198133]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-hsw: DMESG-WARN [fdo#107956] -> INCOMPLETE [fdo#103540]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[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#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
[fdo#109373]: https://bugs.freedesktop.org/show_bug.cgi?id=109373
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5537 -> Patchwork_12133
CI_DRM_5537: dad705dfb9e5af94237708a355df8f10851b4187 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4807:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Rename HAS_GMCH
== Series Details ==
Series: drm/i915: Rename HAS_GMCH
URL : https://patchwork.freedesktop.org/series/56203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5537_full -> Patchwork_12132_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12132_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-a-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-hsw: PASS -> INCOMPLETE [fdo#103540]
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +3
* igt@kms_flip@flip-vs-blocking-wf-vblank:
- shard-glk: PASS -> FAIL [fdo#100368]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_vblank@pipe-c-ts-continuation-idle-hang:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665]
Possible fixes
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-kbl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: FAIL [fdo#108147] -> PASS
* igt@kms_cursor_crc@cursor-128x42-random:
- shard-glk: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-64x64-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-alpha-opaque:
- shard-apl: FAIL [fdo#109350] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-apl: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-apl: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[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#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5537 -> Patchwork_12132
CI_DRM_5537: dad705dfb9e5af94237708a355df8f10851b4187 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4807: b2920f54dc410d5fde705713c7d7eb76ae23dc1a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12132: 95ec42fb699e3b69da66cb0739166908fb3569ea @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12132/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rename HAS_GMCH
On Mon, 2019-02-04 at 14:25 -0800, Rodrigo Vivi wrote:
> First of all GMCH can be considered a feature by itself
> since it is a chip present in some platforms that connects
> the IA processor to memory and other components in PC.
>
> Also with the introduction of display block at device info,
> we got a redundant definition:
>
> .display.has_gmch_display = 1,
>
> So, let's clean up things a bit and use the standardized
> way of has_feature on displays side.
>
> No functional change and no manual interaction to generate
> this patch.
>
> It is only:
>
> sed -si -e 's/has_gmch_display/has_gmch/g' \
> -e 's/HAS_GMCH_DISPLAY/HAS_GMCH/g' drivers/gpu/drm/i915/*{c,h}
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Ville Syrjälä
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
> drivers/gpu/drm/i915/i915_drv.h| 4 ++--
> drivers/gpu/drm/i915/i915_pci.c| 10
> drivers/gpu/drm/i915/i915_suspend.c| 4 ++--
> drivers/gpu/drm/i915/intel_color.c | 6 ++---
> drivers/gpu/drm/i915/intel_device_info.h | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 28 +++-
> --
> drivers/gpu/drm/i915/intel_dp.c| 12 +-
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 6 ++---
> drivers/gpu/drm/i915/intel_hdmi.c | 6 ++---
> drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
> drivers/gpu/drm/i915/intel_i2c.c | 2 +-
> drivers/gpu/drm/i915/vlv_dsi.c | 4 ++--
> 13 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index fa2c226fc779..eff2e7f6762c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3728,7 +3728,7 @@ static int spr_wm_latency_open(struct inode
> *inode, struct file *file)
> {
> struct drm_i915_private *dev_priv = inode->i_private;
>
> - if (HAS_GMCH_DISPLAY(dev_priv))
> + if (HAS_GMCH(dev_priv))
> return -ENODEV;
>
> return single_open(file, spr_wm_latency_show, dev_priv);
> @@ -3738,7 +3738,7 @@ static int cur_wm_latency_open(struct inode
> *inode, struct file *file)
> {
> struct drm_i915_private *dev_priv = inode->i_private;
>
> - if (HAS_GMCH_DISPLAY(dev_priv))
> + if (HAS_GMCH(dev_priv))
> return -ENODEV;
>
> return single_open(file, cur_wm_latency_show, dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 534e52e3a8da..9f6954512547 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2490,7 +2490,7 @@ static inline unsigned int
> i915_sg_segment_size(void)
>
> #define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2)
> #define HAS_FBC(dev_priv)(INTEL_INFO(dev_priv)->display.has_fbc)
> -#define HAS_CUR_FBC(dev_priv)(!HAS_GMCH_DISPLAY(dev_priv) &&
> INTEL_GEN(dev_priv) >= 7)
> +#define HAS_CUR_FBC(dev_priv)(!HAS_GMCH(dev_priv) &&
> INTEL_GEN(dev_priv) >= 7)
>
> #define HAS_IPS(dev_priv)(IS_HSW_ULT(dev_priv) ||
> IS_BROADWELL(dev_priv))
>
> @@ -2570,7 +2570,7 @@ static inline unsigned int
> i915_sg_segment_size(void)
> #define HAS_PCH_NOP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_NOP)
> #define HAS_PCH_SPLIT(dev_priv) (INTEL_PCH_TYPE(dev_priv) !=
> PCH_NONE)
>
> -#define HAS_GMCH_DISPLAY(dev_priv) (INTEL_INFO(dev_priv)-
> >display.has_gmch_display)
> +#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
>
> #define HAS_LSPCON(dev_priv) (INTEL_GEN(dev_priv) >= 9)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index 5d05572c9ff4..cd5a779289c2 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -89,7 +89,7 @@
> .num_pipes = 1, \
> .display.has_overlay = 1, \
> .display.overlay_needs_physical = 1, \
> - .display.has_gmch_display = 1, \
> + .display.has_gmch = 1, \
> .gpu_reset_clobbers_display = true, \
> .hws_needs_physical = 1, \
> .unfenced_needs_alignment = 1, \
> @@ -130,7 +130,7 @@ static const struct intel_device_info
> intel_i865g_info = {
> #define GEN3_FEATURES \
> GEN(3), \
> .num_pipes = 2, \
> - .display.has_gmch_display = 1, \
> + .display.has_gmch = 1, \
> .gpu_reset_clobbers_display = true, \
> .ring_mask = RENDER_RING, \
> .has_snoop = true, \
> @@ -207,7 +207,7 @@ static const struct intel_device_info
> intel_pineview_info = {
> GEN(4), \
> .num_pipes = 2, \
> .display.has_hotplug = 1, \
> - .display.has_gmch_display = 1, \
> + .display.has_gmch = 1, \
> .gpu_reset_clobbers_display = true, \
> .ring_mask = RENDER_RING, \
> .has_snoop = true, \
> @@ -383,7 +383,7 @@ static const struct intel_device_info
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dsc: Add kernel documentation for DRM DP DSC helpers
== Series Details ==
Series: drm/dsc: Add kernel documentation for DRM DP DSC helpers
URL : https://patchwork.freedesktop.org/series/56206/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5537 -> Patchwork_12133
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56206/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12133 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#107362]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
Participating hosts (45 -> 44)
--
Additional (4): fi-hsw-peppy fi-skl-6770hq fi-byt-clapper fi-bwr-2160
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-snb-2600
Build changes
-
* Linux: CI_DRM_5537 -> Patchwork_12133
CI_DRM_5537: dad705dfb9e5af94237708a355df8f10851b4187 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4807: b2920f54dc410d5fde705713c7d7eb76ae23dc1a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12133: c4d880a3c1477e1775bb79f3e1f0ddfa4025d3b9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c4d880a3c147 drm/dsc: Add kernel documentation for DRM DP DSC helpers
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12133/
___
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/dsc: Add kernel documentation for DRM DP DSC helpers
== Series Details == Series: drm/dsc: Add kernel documentation for DRM DP DSC helpers URL : https://patchwork.freedesktop.org/series/56206/ State : warning == Summary == $ dim checkpatch origin/drm-tip c4d880a3c147 drm/dsc: Add kernel documentation for DRM DP DSC helpers -:6: WARNING:TYPO_SPELLING: 'appropiate' may be misspelled - perhaps 'appropriate'? #6: This patch adds appropiate kernel documentation for DRM DP helpers total: 0 errors, 1 warnings, 0 checks, 314 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/dsc: Add kernel documentation for DRM DP DSC helpers
This patch adds appropiate kernel documentation for DRM DP helpers
used for enabling Display Stream compression functionality in
drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
related structure definitions and helpers in drm_dsc.c and drm_dsc.h
Also add links between the functions and structures in the documentation.
Suggested-by: Daniel Vetter
Suggested-by: Sean Paul
Cc: Daniel Vetter
Cc: Sean Paul
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_dp_helper.c | 42 +-
drivers/gpu/drm/drm_dsc.c | 13 ++-
include/drm/drm_dp_helper.h | 15 +++-
include/drm/drm_dsc.h | 138 ++--
4 files changed, 142 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 54120b6319e7..e9e0233f5b2f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1360,7 +1360,20 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
drm_dp_desc *desc,
EXPORT_SYMBOL(drm_dp_read_desc);
/**
- * DRM DP Helpers for DSC
+ * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
+ * supported by the DSC sink.
+ * @dsc_dpcd: DSC capabilities from DPCD
+ * @is_edp: true if its eDP, false for DP
+ *
+ * Read the slice capabilities DPCD register from DSC sink to get
+ * the maximum slice count supported. This is used to populate
+ * the DSC parameters in the drm_dsc_config by the driver.
+ * Driver creates an infoframe using these parameters to populate
+ * drm_dsc_pps_infoframe. These are sent to the sink using DSC
+ * infoframe using the helper function drm_dsc_pps_infoframe_pack()
+ *
+ * Returns:
+ * Maximum slice count supported by DSC sink or 0 its invalid
*/
u8 drm_dp_dsc_sink_max_slice_count(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
bool is_edp)
@@ -1405,6 +1418,19 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
}
EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
+/**
+ * drm_dp_dsc_sink_line_buf_depth() - Get the line buffer depth in bits which
is
+ * number of bits of precision within the decoder line buffer supported by
+ * the DSC sink. This is used to populate the DSC parameters in the
+ * drm_dsc_config by the driver.
+ * Driver creates an infoframe using these parameters to populate
+ * drm_dsc_pps_infoframe. These are sent to the sink using DSC
+ * infoframe using the helper function drm_dsc_pps_infoframe_pack()
+ * @dsc_dpcd: DSC capabilities from DPCD
+ *
+ * Returns:
+ * Line buffer depth supported by DSC panel or 0 its invalid
+ */
u8 drm_dp_dsc_sink_line_buf_depth(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
{
u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
DP_DSC_SUPPORT];
@@ -1434,6 +1460,20 @@ u8 drm_dp_dsc_sink_line_buf_depth(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
}
EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
+/**
+ * drm_dp_dsc_sink_supported_input_bpcs() - Get all the input bits per
component
+ * values supported by the DSC sink. This is used to populate the DSC
parameters
+ * in the drm_dsc_config by the driver.
+ * Driver creates an infoframe using these parameters to populate
+ * drm_dsc_pps_infoframe. These are sent to the sink using DSC
+ * infoframe using the helper function drm_dsc_pps_infoframe_pack()
+ * @dsc_dpcd: DSC capabilities from DPCD
+ * @dsc_bpc: An array to be filled by this helper with supported
+ * input bpcs.
+ *
+ * Returns:
+ * Number of input BPC values parsed from the DPCD
+ */
int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
u8 dsc_bpc[3])
{
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index bc2b23adb072..0fd56fbdf9b4 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -17,6 +17,12 @@
/**
* DOC: dsc helpers
*
+ * VESA specification for DP 1.4 adds a new feature called Display Stream
+ * Compression (DSC) used to compress the pixel bits before sending it on
+ * DP/eDP/MIPI DSI interface. DSC is required to be enabled so that the
existing
+ * display interfaces can support high resolutions at higher frames rates uisng
+ * the maximum available link capacity of these interfaces.
+ *
* These functions contain some common logic and helpers to deal with VESA
* Display Stream Compression standard required for DSC on Display Port/eDP or
* MIPI display interfaces.
@@ -26,6 +32,7 @@
* 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
*/
void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
{
@@ -44,9 +51,11 @@ EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
* that span more than 1 byte.
*
* @pps_sdp:
- * Secondary data packet for DSC Picture Parameter Set
+ *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Rename HAS_GMCH
== Series Details ==
Series: drm/i915: Rename HAS_GMCH
URL : https://patchwork.freedesktop.org/series/56203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5537 -> Patchwork_12132
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56203/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12132 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: PASS -> WARN [fdo#109380]
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[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
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
Participating hosts (45 -> 43)
--
Additional (4): fi-hsw-peppy fi-skl-6770hq fi-byt-clapper fi-bwr-2160
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-snb-2600
Build changes
-
* Linux: CI_DRM_5537 -> Patchwork_12132
CI_DRM_5537: dad705dfb9e5af94237708a355df8f10851b4187 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4807: b2920f54dc410d5fde705713c7d7eb76ae23dc1a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12132: 95ec42fb699e3b69da66cb0739166908fb3569ea @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
95ec42fb699e drm/i915: Rename HAS_GMCH
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12132/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: W/A for underruns with WM1+ disabled on icl
On Mon, Feb 04, 2019 at 10:22:32PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Disabling WM1+ on ICL causes tons of underruns with
> linear/X-tiled framebuffers. We can avoid this by flipping
> on a chicken bit affecting the way the hw fill the FIFO.
> This may not be the final solution but should hopefully
> avoid some underruns in the meantime.
>
> v2: Apparently PIPE_CHICKEN is icl+ only
>
> Signed-off-by: Ville Syrjälä
I can't speak for what this register actually does, but your patch
accurately implements the recommendation from the hardware guys, so
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ede54fdc1676..12964b0fbc54 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7618,6 +7618,7 @@ enum {
> #define _PIPEB_CHICKEN 0x71038
> #define _PIPEC_CHICKEN 0x72038
> #define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
> +#define PM_FILL_MAINTAIN_DBUF_FULLNESS (1 << 0)
> #define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
> _PIPEB_CHICKEN)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5b9b9791d290..b825ceed7f1d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3911,6 +3911,12 @@ static void icl_set_pipe_chicken(struct intel_crtc
> *crtc)
>*/
> tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
>
> + /*
> + * W/A for underruns with linear/X-tiled with
> + * WM1+ disabled.
> + */
> + tmp |= PM_FILL_MAINTAIN_DBUF_FULLNESS;
> +
> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> }
>
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Setup PIPE_CHICKEN for fastsets too
On Mon, Feb 04, 2019 at 10:22:14PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Configure PIPE_CHICKEN during intel_update_pipe_config() to make > sure we have our chickens in a row with fastboot too. > > v2: Apparently PIPE_CHICKEN is icl+ only > > Signed-off-by: Ville Syrjälä Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/intel_display.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 4087d54ea943..5b9b9791d290 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -3958,6 +3958,9 @@ static void intel_update_pipe_config(const struct > intel_crtc_state *old_crtc_sta > I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), > SKL_BOTTOM_COLOR_GAMMA_ENABLE | > SKL_BOTTOM_COLOR_CSC_ENABLE); > + > + if (INTEL_GEN(dev_priv) >= 11) > + icl_set_pipe_chicken(crtc); > } > > static void intel_fdi_normal_train(struct intel_crtc *crtc) > -- > 2.19.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Extract icl_set_pipe_chicken()
On Mon, Feb 04, 2019 at 10:21:39PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We need configure PIPE_CHICKEN during fastboot as well. Let's extract
> it to a helper.
>
> v2: Apparently PIPE_CHICKEN is icl+ only
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_display.c | 31 ++--
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index df7a7a310f2f..4087d54ea943 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3896,6 +3896,24 @@ void intel_finish_reset(struct drm_i915_private
> *dev_priv)
> clear_bit(I915_RESET_MODESET, _priv->gpu_error.flags);
> }
>
> +static void icl_set_pipe_chicken(struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + u32 tmp;
> +
> + tmp = I915_READ(PIPE_CHICKEN(pipe));
> +
> + /*
> + * Display WA #1153: icl
> + * enable hardware to bypass the alpha math
> + * and rounding for per-pixel values 00 and 0xff
> + */
> + tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
> +
> + I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> +}
> +
> static void intel_update_pipe_config(const struct intel_crtc_state
> *old_crtc_state,
>const struct intel_crtc_state
> *new_crtc_state)
> {
> @@ -5782,7 +5800,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> struct intel_atomic_state *old_intel_state =
> to_intel_atomic_state(old_state);
> bool psl_clkgate_wa;
> - u32 pipe_chicken;
>
> if (WARN_ON(intel_crtc->active))
> return;
> @@ -5839,16 +5856,8 @@ static void haswell_crtc_enable(struct
> intel_crtc_state *pipe_config,
>*/
> intel_color_load_luts(pipe_config);
>
> - /*
> - * Display WA #1153: enable hardware to bypass the alpha math
> - * and rounding for per-pixel values 00 and 0xff
> - */
> - if (INTEL_GEN(dev_priv) >= 11) {
> - pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
> - if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
> - I915_WRITE_FW(PIPE_CHICKEN(pipe),
> - pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN);
> - }
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_set_pipe_chicken(intel_crtc);
>
> intel_ddi_set_pipe_settings(pipe_config);
> if (!transcoder_is_dsi(cpu_transcoder))
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
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: Fix wm latency==0 disable on skl+
On Mon, Feb 04, 2019 at 08:45:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When adding the early latency==0 check back I neglected to
> realize that we no longer have a way to return a failure
> from the wm computation like we had in the past (since we
> now calculate wms before ddb allocations). Also plane_en
> being false doesn't actually indicate that the level is
> invalid as it wil also happen when the plane is not
> enabled.
>
> skl_allocate_pipe_ddb() starts scanning from the maximum
> watermark level and it stops as soon as it finds a level
> that is deemed viable. The assumption being that if level
> n+1 is valid then level n is valid as well. Thus if we
> now disable any watermark level by zeroing its latency
> the code will think that level to be actually valid
> and won't confirm whether the actually enabled lower
> watermark level(s) actually fit into the allotted ddb
> space. This results in hilarious watermark values that
> exceed the ddb allocation of the plane.
>
> The way we must now indicate a failure is to assign an
> unreasoanbly big value to min_ddb_alloc which will then
> make skl_allocate_pipe_ddb() reject the entire level.
>
> Cc: Matt Roper
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
Similarly, isn't the
if (res_lines > 31)
return;
farther down the function going to also cause a problem? If we fail the
line requirement then result->min_ddb_alloc and such never get set for
this plane, which screws up the block sum at block allocation time.
Matt
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ed9786241307..d6186c90bc10 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4694,8 +4694,11 @@ static void skl_compute_plane_wm(const struct
> intel_crtc_state *cstate,
> uint_fixed_16_16_t selected_result;
> u32 res_blocks, res_lines, min_ddb_alloc = 0;
>
> - if (latency == 0)
> + if (latency == 0) {
> + /* reject it */
> + result->min_ddb_alloc = U16_MAX;
> return;
> + }
>
> /* Display WA #1141: kbl,cfl */
> if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> --
> 2.19.2
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
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: Rename HAS_GMCH
== Series Details == Series: drm/i915: Rename HAS_GMCH URL : https://patchwork.freedesktop.org/series/56203/ State : warning == Summary == $ dim checkpatch origin/drm-tip 95ec42fb699e drm/i915: Rename HAS_GMCH -:64: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #64: FILE: drivers/gpu/drm/i915/i915_drv.h:2493: +#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && INTEL_GEN(dev_priv) >= 7) total: 0 errors, 0 warnings, 1 checks, 360 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Include register polling in reg_rw traces
== Series Details ==
Series: drm/i915: Include register polling in reg_rw traces
URL : https://patchwork.freedesktop.org/series/56201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536_full -> Patchwork_12131_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12131_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-b-legacy-gamma-reset:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: PASS -> FAIL [fdo#104873]
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: PASS -> FAIL [fdo#102887] / [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-apl: NOTRUN -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-none:
- shard-apl: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@gem_pwrite_pread@uncached-copy-performance:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-snb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-b-ctm-max:
- shard-apl: FAIL [fdo#108147] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS +3
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- shard-kbl: DMESG-WARN [fdo#103313] / [fdo#105345] / [fdo#108473]
-> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-apl: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +3
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-kbl: DMESG-WARN [fdo#109244] -> INCOMPLETE [fdo#103665] /
[fdo#106886]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[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#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105345]: https://bugs.freedesktop.org/show_bug.cgi?id=105345
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build
[Intel-gfx] [PATCH] drm/i915: Rename HAS_GMCH
First of all GMCH can be considered a feature by itself
since it is a chip present in some platforms that connects
the IA processor to memory and other components in PC.
Also with the introduction of display block at device info,
we got a redundant definition:
.display.has_gmch_display = 1,
So, let's clean up things a bit and use the standardized
way of has_feature on displays side.
No functional change and no manual interaction to generate
this patch.
It is only:
sed -si -e 's/has_gmch_display/has_gmch/g' \
-e 's/HAS_GMCH_DISPLAY/HAS_GMCH/g' drivers/gpu/drm/i915/*{c,h}
Cc: José Roberto de Souza
Cc: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
drivers/gpu/drm/i915/i915_drv.h| 4 ++--
drivers/gpu/drm/i915/i915_pci.c| 10
drivers/gpu/drm/i915/i915_suspend.c| 4 ++--
drivers/gpu/drm/i915/intel_color.c | 6 ++---
drivers/gpu/drm/i915/intel_device_info.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 28 +++---
drivers/gpu/drm/i915/intel_dp.c| 12 +-
drivers/gpu/drm/i915/intel_fifo_underrun.c | 6 ++---
drivers/gpu/drm/i915/intel_hdmi.c | 6 ++---
drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
drivers/gpu/drm/i915/intel_i2c.c | 2 +-
drivers/gpu/drm/i915/vlv_dsi.c | 4 ++--
13 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fa2c226fc779..eff2e7f6762c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3728,7 +3728,7 @@ static int spr_wm_latency_open(struct inode *inode,
struct file *file)
{
struct drm_i915_private *dev_priv = inode->i_private;
- if (HAS_GMCH_DISPLAY(dev_priv))
+ if (HAS_GMCH(dev_priv))
return -ENODEV;
return single_open(file, spr_wm_latency_show, dev_priv);
@@ -3738,7 +3738,7 @@ static int cur_wm_latency_open(struct inode *inode,
struct file *file)
{
struct drm_i915_private *dev_priv = inode->i_private;
- if (HAS_GMCH_DISPLAY(dev_priv))
+ if (HAS_GMCH(dev_priv))
return -ENODEV;
return single_open(file, cur_wm_latency_show, dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 534e52e3a8da..9f6954512547 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2490,7 +2490,7 @@ static inline unsigned int i915_sg_segment_size(void)
#define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2)
#define HAS_FBC(dev_priv) (INTEL_INFO(dev_priv)->display.has_fbc)
-#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH_DISPLAY(dev_priv) &&
INTEL_GEN(dev_priv) >= 7)
+#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && INTEL_GEN(dev_priv) >=
7)
#define HAS_IPS(dev_priv) (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv))
@@ -2570,7 +2570,7 @@ static inline unsigned int i915_sg_segment_size(void)
#define HAS_PCH_NOP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_NOP)
#define HAS_PCH_SPLIT(dev_priv) (INTEL_PCH_TYPE(dev_priv) != PCH_NONE)
-#define HAS_GMCH_DISPLAY(dev_priv)
(INTEL_INFO(dev_priv)->display.has_gmch_display)
+#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
#define HAS_LSPCON(dev_priv) (INTEL_GEN(dev_priv) >= 9)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 5d05572c9ff4..cd5a779289c2 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -89,7 +89,7 @@
.num_pipes = 1, \
.display.has_overlay = 1, \
.display.overlay_needs_physical = 1, \
- .display.has_gmch_display = 1, \
+ .display.has_gmch = 1, \
.gpu_reset_clobbers_display = true, \
.hws_needs_physical = 1, \
.unfenced_needs_alignment = 1, \
@@ -130,7 +130,7 @@ static const struct intel_device_info intel_i865g_info = {
#define GEN3_FEATURES \
GEN(3), \
.num_pipes = 2, \
- .display.has_gmch_display = 1, \
+ .display.has_gmch = 1, \
.gpu_reset_clobbers_display = true, \
.ring_mask = RENDER_RING, \
.has_snoop = true, \
@@ -207,7 +207,7 @@ static const struct intel_device_info intel_pineview_info =
{
GEN(4), \
.num_pipes = 2, \
.display.has_hotplug = 1, \
- .display.has_gmch_display = 1, \
+ .display.has_gmch = 1, \
.gpu_reset_clobbers_display = true, \
.ring_mask = RENDER_RING, \
.has_snoop = true, \
@@ -383,7 +383,7 @@ static const struct intel_device_info intel_valleyview_info
= {
.num_pipes = 2,
.has_runtime_pm = 1,
.has_rc6 = 1,
- .display.has_gmch_display = 1,
+ .display.has_gmch = 1,
.display.has_hotplug = 1,
.ppgtt = INTEL_PPGTT_FULL,
.has_snoop = true,
@@ -475,7 +475,7 @@ static const struct
Re: [Intel-gfx] [PATCH v2 RESEND 2/2] drm/i915/icl: Implement half float formats
Ville Syrjälä wrote: > Kevin Strasser wrote: > > Ville Syrjälä wrote: > > > is_hdr_plane() is around now, please use it. > > > > I don't think I can use icl_is_hdr_plane here without some refactoring. It > > requires the plane->base to be initialized through drm_universal_plane_init, > > which depends on formats/num_formats pointers to be already set. > > Hmm. We should probably just convert it into > > icl_is_hdr_plane(struct drm_i915_private *dev_priv, > enum plane_id plane_id); That sounds reasonable, I'll include this in v3. Thanks, Kevin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Fix wm latency==0 disable on skl+ (rev4)
== Series Details ==
Series: series starting with [1/4] drm/i915: Fix wm latency==0 disable on skl+
(rev4)
URL : https://patchwork.freedesktop.org/series/56199/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536_full -> Patchwork_12130_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12130_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-kbl: NOTRUN -> FAIL [fdo#103158]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-dpms:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-hsw: PASS -> FAIL [fdo#104894]
* igt@perf@blocking:
- shard-hsw: PASS -> FAIL [fdo#102252]
Possible fixes
* igt@gem_pwrite_pread@uncached-copy-performance:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- shard-kbl: DMESG-WARN [fdo#103313] / [fdo#105345] / [fdo#108473]
-> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-apl: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
- shard-kbl: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102252]: https://bugs.freedesktop.org/show_bug.cgi?id=102252
[fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
[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#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894
[fdo#105345]: https://bugs.freedesktop.org/show_bug.cgi?id=105345
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108590]: https://bugs.freedesktop.org/show_bug.cgi?id=108590
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12130
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include register polling in reg_rw traces
== Series Details ==
Series: drm/i915: Include register polling in reg_rw traces
URL : https://patchwork.freedesktop.org/series/56201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12131
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56201/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12131 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-skl-guc: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[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#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]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (46 -> 43)
--
Additional (1): fi-icl-y
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12131
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12131: 1052a40a1a7d0249b1b80070f82c73d8e642abeb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1052a40a1a7d drm/i915: Include register polling in reg_rw traces
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12131/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Include register polling in reg_rw traces
Quoting Ville Syrjala (2019-02-04 21:16:44)
> From: Ville Syrjälä
>
> We generally omit register polling from the i915_reg_rw tracepoint.
> Understandable since polling could generate a lot of noise in the
> trace. The downside is that the trace is incomplete. As a compromise
> let's trace the final register value observed while polling. That
> should be generally sufficient to observe what the code should be
> doing next.
Fair compromise; I admit the subject line had me freaking out.
> I suppose in some cases it might make sense to also trace the initial
> register value, and maybe the number of times we polled. But that
> would require a separate tracepoint so let's leave it for the future.
I postulate when you get down to wanting that amount of detail, you
throw in dedicated debug.
> The other users of _NOTRACE() are i915_pmu and i2c bitbanging,
> which I decided to leave alone.
>
> Next we should do something to claw back the tracepoints for
> planes and whatnot which were switched to _FW() a while back.
> I guess just new macros for raw_rw+trace. The question is
> what to call it?
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.c | 12 ++--
> drivers/gpu/drm/i915/intel_dp.c | 6 ++
> drivers/gpu/drm/i915/intel_uncore.c | 3 +++
> 3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7aaa1ac4c99..7de90701f6f1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2543,6 +2543,10 @@ static void vlv_restore_gunit_s0ix_state(struct
> drm_i915_private *dev_priv)
> static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
> u32 mask, u32 val)
> {
> + i915_reg_t reg = VLV_GTLC_PW_STATUS;
> + u32 reg_value;
> + int ret;
> +
> /* The HW does not like us polling for PW_STATUS frequently, so
> * use the sleeping loop rather than risk the busy spin within
> * intel_wait_for_register().
> @@ -2550,8 +2554,12 @@ static int vlv_wait_for_pw_status(struct
> drm_i915_private *dev_priv,
> * Transitioning between RC6 states should be at most 2ms (see
> * valleyview_enable_rps) so use a 3ms timeout.
> */
> - return wait_for((I915_READ_NOTRACE(VLV_GTLC_PW_STATUS) & mask) == val,
> - 3);
> + ret = wait_for(((reg_value = I915_READ_NOTRACE(reg)) & mask) == val,
> 3);
> +
> + /* just trace the final value */
> + trace_i915_reg_rw(false, reg, reg_value, sizeof(reg_value), true);
I feel like there's a pattern here that could benefit from a convenient
macro. Nevertheless,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/22] drm/i915: Make request allocation caches global
Quoting Tvrtko Ursulin (2019-02-04 18:48:50)
>
> On 04/02/2019 13:22, Chris Wilson wrote
> > -int __init i915_global_active_init(void)
> > +int i915_global_active_init(void)
>
> These can't remain __init, since they are only called from the global
> __init one?
I ran into problems, and removed __init until it stopped complaining and
I stopped caring.
> > @@ -2916,12 +2917,11 @@ static void shrink_caches(struct drm_i915_private
> > *i915)
> >* filled slabs to prioritise allocating from the mostly full slabs,
> >* with the aim of reducing fragmentation.
> >*/
> > - kmem_cache_shrink(i915->priorities);
> > - kmem_cache_shrink(i915->dependencies);
> > - kmem_cache_shrink(i915->requests);
> > kmem_cache_shrink(i915->luts);
> > kmem_cache_shrink(i915->vmas);
> > kmem_cache_shrink(i915->objects);
> > +
> > + i915_globals_shrink();
>
> This is the main bit which worries me.
>
> Global caches are what we want I think, exactly for what you wrote in
> the commit message. But would one device going idle have the potential
> to inject some latency into another potentially very busy client?
>
> Perhaps we could have some sort of aggregated idle signal and defer
> shrinking cached to that point. Like a bitmask of global clients
> reporting their idle/active status to global core, and then shrink
> happens only if all are idle.
I had mixed feelings too. I didn't want to completely discard the
current logic, but this should be shrinking only when idle across all
future stakeholders... or we demonstrate that shrinking has no effect on
concurrent allocation latency.
An active counter for unparking seems an easy way out. (Which today is
this imaginary 1bit counter.) What I thought helped save this was this
is done from a post-rcu worker, the system has to be pretty stable for
us to start shrinking. We only clash with the first user to wake up.
In the caller it does a loop over each cpu removing the local cpu cache
and then the global slab cache. That is clearly going to increase
latency for a concurrent caller.
> > +int i915_global_scheduler_init(void)
> > +{
> > + global.slab_dependencies = KMEM_CACHE(i915_dependency,
> > + SLAB_HWCACHE_ALIGN);
> > + if (!global.slab_dependencies)
> > + return -ENOMEM;
>
> Right, so this slab is duplicated. It could end up merged by the core,
> but I am thinking if this is the direction we want to go just to avoid
> some pointer chasing.
"some pointer chasing" :)
The slab isn't necessary duplicated, that depends on compiletime policy.
In debug environments or those more sensitive to performance, it will be
private so that we can catch stray writes and what not.
add/remove: 11/0 grow/shrink: 11/20 up/down: 595/-668 (-73)
Function old new delta
i915_global_request_init - 116+116
i915_global_scheduler_init - 111+111
igt_mock_ppgtt_misaligned_dma679 748 +69
i915_globals_init - 53 +53
global 8 40 +32
i915_global_scheduler_shrink - 29 +29
i915_global_scheduler_exit - 29 +29
i915_global_request_shrink - 29 +29
i915_global_request_exit - 29 +29
i915_globals_shrink- 20 +20
__i915_priolist_free - 20 +20
i915_global_active_shrink - 17 +17
i915_globals_exit - 15 +15
live_suppress_wait_preempt.part.cold 202 211 +9
__err_print_to_sgl 41754181 +6
i915_global_active_exit 12 17 +5
intel_engine_lookup_user 54 55 +1
init_module 88 89 +1
igt_mock_ppgtt_misaligned_dma.cold 246 247 +1
i915_init 88 89 +1
gen11_irq_handler733 734 +1
g4x_pre_enable_dp345 346 +1
ring_request_alloc 18991898 -1
live_suppress_wait_preempt.part 12911290 -1
i915_sched_lookup_priolist 482 479 -3
i915_request_retire 13771373 -4
i915_request_await_dma_fence 547 543 -4
i915_fence_release45 41 -4
__execlists_submission_tasklet 21212111 -10
i915_request_alloc 817 806 -11
i915_request_alloc_slow.isra 76 64 -12
i915_sched_node_add_dependency 114 101 -13
execlists_cancel_requests
Re: [Intel-gfx] [PATCH v2 RESEND 2/2] drm/i915/icl: Implement half float formats
On Fri, Feb 01, 2019 at 09:38:57PM +, Strasser, Kevin wrote:
> Ville Syrjälä wrote:
> > > @@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
> > >DRM_FORMAT_NV12,
> > > };
> > >
> > > +static const uint32_t icl_hdr_plane_formats[] = {
> >
> > Please switch to u32 & co. We recently had a mass conversion in the
> > driver.
>
> Will do. Looks like the CI caught that too.
>
> > > static const u64 skl_plane_format_modifiers_noccs[] = {
> > >I915_FORMAT_MOD_Yf_TILED,
> > >I915_FORMAT_MOD_Y_TILED,
> > > @@ -1917,6 +1958,10 @@ static bool skl_plane_format_mod_supported(struct
> > > drm_plane *_plane,
> > >return true;
> > >/* fall through */
> > >case DRM_FORMAT_C8:
> > > + case DRM_FORMAT_XBGR16161616F:
> > > + case DRM_FORMAT_ABGR16161616F:
> > > + case DRM_FORMAT_XRGB16161616F:
> > > + case DRM_FORMAT_ARGB16161616F:
> > >if (modifier == DRM_FORMAT_MOD_LINEAR ||
> > >modifier == I915_FORMAT_MOD_X_TILED ||
> > >modifier == I915_FORMAT_MOD_Y_TILED)
> > > @@ -2053,11 +2098,21 @@ skl_universal_plane_create(struct drm_i915_private
> > > *dev_priv,
> > >plane->update_slave = icl_update_slave;
> > >
> > >if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
> > > - formats = skl_planar_formats;
> > > - num_formats = ARRAY_SIZE(skl_planar_formats);
> > > + if (INTEL_GEN(dev_priv) > 10 && plane_id < PLANE_SPRITE2) {
> >
> > is_hdr_plane() is around now, please use it.
>
> I don't think I can use icl_is_hdr_plane here without some refactoring. It
> requires the plane->base to be initialized through drm_universal_plane_init,
> which depends on formats/num_formats pointers to be already set.
Hmm. We should probably just convert it into
icl_is_hdr_plane(struct drm_i915_private *dev_priv,
enum plane_id plane_id);
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Include register polling in reg_rw traces
From: Ville Syrjälä
We generally omit register polling from the i915_reg_rw tracepoint.
Understandable since polling could generate a lot of noise in the
trace. The downside is that the trace is incomplete. As a compromise
let's trace the final register value observed while polling. That
should be generally sufficient to observe what the code should be
doing next.
I suppose in some cases it might make sense to also trace the initial
register value, and maybe the number of times we polled. But that
would require a separate tracepoint so let's leave it for the future.
The other users of _NOTRACE() are i915_pmu and i2c bitbanging,
which I decided to leave alone.
Next we should do something to claw back the tracepoints for
planes and whatnot which were switched to _FW() a while back.
I guess just new macros for raw_rw+trace. The question is
what to call it?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 12 ++--
drivers/gpu/drm/i915/intel_dp.c | 6 ++
drivers/gpu/drm/i915/intel_uncore.c | 3 +++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7aaa1ac4c99..7de90701f6f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2543,6 +2543,10 @@ static void vlv_restore_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
static int vlv_wait_for_pw_status(struct drm_i915_private *dev_priv,
u32 mask, u32 val)
{
+ i915_reg_t reg = VLV_GTLC_PW_STATUS;
+ u32 reg_value;
+ int ret;
+
/* The HW does not like us polling for PW_STATUS frequently, so
* use the sleeping loop rather than risk the busy spin within
* intel_wait_for_register().
@@ -2550,8 +2554,12 @@ static int vlv_wait_for_pw_status(struct
drm_i915_private *dev_priv,
* Transitioning between RC6 states should be at most 2ms (see
* valleyview_enable_rps) so use a 3ms timeout.
*/
- return wait_for((I915_READ_NOTRACE(VLV_GTLC_PW_STATUS) & mask) == val,
- 3);
+ ret = wait_for(((reg_value = I915_READ_NOTRACE(reg)) & mask) == val, 3);
+
+ /* just trace the final value */
+ trace_i915_reg_rw(false, reg, reg_value, sizeof(reg_value), true);
+
+ return ret;
}
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool force_on)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 681e88405ada..36e3d99abc2b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1061,6 +1061,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) ==
0)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
+
+ /* just trace the final value */
+ trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
+
if (!done)
DRM_ERROR("dp aux hw did not signal timeout!\n");
#undef C
@@ -1227,6 +1231,8 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
break;
msleep(1);
}
+ /* just trace the final value */
+ trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
if (try == 3) {
static u32 last_status = -1;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e88f0252d77e..75646a1e0051 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1819,6 +1819,9 @@ int __intel_wait_for_register(struct drm_i915_private
*dev_priv,
(reg_value & mask) == value,
slow_timeout_ms * 1000, 10, 1000);
+ /* just trace the final value */
+ trace_i915_reg_rw(false, reg, reg_value, sizeof(reg_value), true);
+
if (out_value)
*out_value = reg_value;
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Fix wm latency==0 disable on skl+ (rev4)
== Series Details ==
Series: series starting with [1/4] drm/i915: Fix wm latency==0 disable on skl+
(rev4)
URL : https://patchwork.freedesktop.org/series/56199/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12130
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56199/revisions/4/mbox/
Known issues
Here are the changes found in Patchwork_12130 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-skl-guc: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[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#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]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (46 -> 44)
--
Additional (3): fi-icl-y fi-byt-j1900 fi-pnv-d510
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-kbl-7560u
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12130
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12130: 842b6e3123756d29c2f40e30ca1e38c0b6a0bd9e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
842b6e312375 drm/i915: W/A for underruns with WM1+ disabled on icl
f14a675def45 drm/i915: Setup PIPE_CHICKEN for fastsets too
65fdbc2fb2d3 drm/i915: Extract icl_set_pipe_chicken()
b157cc17b7f0 drm/i915: Fix wm latency==0 disable on skl+
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12130/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/i915: W/A for underruns with WM1+ disabled on icl
From: Ville Syrjälä
Disabling WM1+ on ICL causes tons of underruns with
linear/X-tiled framebuffers. We can avoid this by flipping
on a chicken bit affecting the way the hw fill the FIFO.
This may not be the final solution but should hopefully
avoid some underruns in the meantime.
v2: Apparently PIPE_CHICKEN is icl+ only
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ede54fdc1676..12964b0fbc54 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7618,6 +7618,7 @@ enum {
#define _PIPEB_CHICKEN 0x71038
#define _PIPEC_CHICKEN 0x72038
#define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
+#define PM_FILL_MAINTAIN_DBUF_FULLNESS(1 << 0)
#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
_PIPEB_CHICKEN)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5b9b9791d290..b825ceed7f1d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3911,6 +3911,12 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
*/
tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
+ /*
+* W/A for underruns with linear/X-tiled with
+* WM1+ disabled.
+*/
+ tmp |= PM_FILL_MAINTAIN_DBUF_FULLNESS;
+
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915: Setup PIPE_CHICKEN for fastsets too
From: Ville Syrjälä Configure PIPE_CHICKEN during intel_update_pipe_config() to make sure we have our chickens in a row with fastboot too. v2: Apparently PIPE_CHICKEN is icl+ only Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4087d54ea943..5b9b9791d290 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3958,6 +3958,9 @@ static void intel_update_pipe_config(const struct intel_crtc_state *old_crtc_sta I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), SKL_BOTTOM_COLOR_GAMMA_ENABLE | SKL_BOTTOM_COLOR_CSC_ENABLE); + + if (INTEL_GEN(dev_priv) >= 11) + icl_set_pipe_chicken(crtc); } static void intel_fdi_normal_train(struct intel_crtc *crtc) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915: Extract icl_set_pipe_chicken()
From: Ville Syrjälä
We need configure PIPE_CHICKEN during fastboot as well. Let's extract
it to a helper.
v2: Apparently PIPE_CHICKEN is icl+ only
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 31 ++--
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df7a7a310f2f..4087d54ea943 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3896,6 +3896,24 @@ void intel_finish_reset(struct drm_i915_private
*dev_priv)
clear_bit(I915_RESET_MODESET, _priv->gpu_error.flags);
}
+static void icl_set_pipe_chicken(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tmp;
+
+ tmp = I915_READ(PIPE_CHICKEN(pipe));
+
+ /*
+* Display WA #1153: icl
+* enable hardware to bypass the alpha math
+* and rounding for per-pixel values 00 and 0xff
+*/
+ tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
+
+ I915_WRITE(PIPE_CHICKEN(pipe), tmp);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -5782,7 +5800,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
struct intel_atomic_state *old_intel_state =
to_intel_atomic_state(old_state);
bool psl_clkgate_wa;
- u32 pipe_chicken;
if (WARN_ON(intel_crtc->active))
return;
@@ -5839,16 +5856,8 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
*/
intel_color_load_luts(pipe_config);
- /*
-* Display WA #1153: enable hardware to bypass the alpha math
-* and rounding for per-pixel values 00 and 0xff
-*/
- if (INTEL_GEN(dev_priv) >= 11) {
- pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
- if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
- I915_WRITE_FW(PIPE_CHICKEN(pipe),
- pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN);
- }
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_set_pipe_chicken(intel_crtc);
intel_ddi_set_pipe_settings(pipe_config);
if (!transcoder_is_dsi(cpu_transcoder))
--
2.19.2
___
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/4] drm/i915: Fix wm latency==0 disable on skl+
== Series Details ==
Series: series starting with [1/4] drm/i915: Fix wm latency==0 disable on skl+
URL : https://patchwork.freedesktop.org/series/56199/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12129
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12129 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12129, 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/56199/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12129:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-skl-6770hq: PASS -> DMESG-WARN
- fi-cfl-8109u: PASS -> DMESG-WARN
- fi-skl-6260u: PASS -> DMESG-WARN
- fi-cfl-guc: PASS -> DMESG-WARN
- fi-kbl-7567u: PASS -> DMESG-WARN
- fi-skl-guc: PASS -> DMESG-WARN
- fi-glk-j4005: PASS -> DMESG-WARN
- fi-kbl-x1275: PASS -> DMESG-WARN
- fi-cfl-8700k: PASS -> DMESG-WARN
- fi-kbl-7500u: PASS -> DMESG-WARN
- fi-skl-gvtdvm: PASS -> DMESG-WARN
- fi-bxt-j4205: PASS -> DMESG-WARN
- fi-skl-6700k2: PASS -> DMESG-WARN
- fi-apl-guc: PASS -> DMESG-WARN
* igt@gem_exec_suspend@basic-s4-devices:
- fi-skl-iommu: PASS -> DMESG-WARN
- fi-skl-6700hq: PASS -> DMESG-WARN
- fi-skl-6600u: PASS -> DMESG-WARN
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_basic@basic-blt:
- {fi-whl-u}: PASS -> INCOMPLETE
* igt@gem_exec_suspend@basic-s3:
- {fi-whl-u}: PASS -> DMESG-WARN
* {igt@runner@aborted}:
- fi-bxt-j4205: NOTRUN -> FAIL
- {fi-whl-u}: NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_12129 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-r: PASS -> DMESG-WARN [fdo#107139]
- fi-kbl-7560u: PASS -> DMESG-WARN [fdo#107139]
* igt@i915_module_load@reload:
- fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: PASS -> DMESG-WARN [fdo#107709]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: PASS -> DMESG-FAIL [fdo#103182]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[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#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108756]: https://bugs.freedesktop.org/show_bug.cgi?id=108756
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109383]: https://bugs.freedesktop.org/show_bug.cgi?id=109383
[k.org#201919]: https://bugzilla.kernel.org/show_bug.cgi?id=201919
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (46 -> 44)
--
Additional (2): fi-byt-j1900 fi-pnv-d510
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12129
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12129: 4b8ca9ecbade242ef033f7d5e39abd865ef22387 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4b8ca9ecbade
Re: [Intel-gfx] [PATCH] drm/i915: Trim NEWCLIENT boosting
On 04/02/2019 15:01, Chris Wilson wrote:
Limit the NEWCLIENT boost to only give its small priority boost to fresh
clients only that have no dependencies.
The idea for using NEWCLIENT boosting, commit b16c765122f9 ("drm/i915:
Priority boost for new clients"), is that short-lived streams are often
interactive and require lower latency -- and that by executing those
ahead of the long running hogs, the short-lived clients do little
interfere with the system throughput by virtue of their short-lived
nature. However, we were only considering the client's own timeline for
determining whether or not it was a fresh stream. This allowed for
compositors to wake up before their vblank and bump all of its client
streams. However in testing with media-bench this results in chaining
all cooperating contexts together preventing us from being able to
reorder contexts to reduce bubbles (pipeline stalls), overall increasing
latency, and reducing system throughput. The exact opposite of our
intent. The compromise of applying the NEWCLIENT boost to strictly fresh
clients (that do not wait upon anything else) should maintain the
real-time response under load characteristics of FQ_CODEL, without
locking together the long chains of dependencies across the system.
References: b16c765122f9 ("drm/i915: Priority boost for new clients")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d14a1b225f47..04c65e6d83b9 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -980,7 +980,7 @@ void i915_request_add(struct i915_request *request)
* Allow interactive/synchronous clients to jump ahead of
* the bulk clients. (FQ_CODEL)
*/
- if (!prev || i915_request_completed(prev))
+ if (list_empty(>sched.signalers_list))
attr.priority |= I915_PRIORITY_NEWCLIENT;
engine->schedule(request, );
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/22] drm/i915/execlists: Refactor out can_merge_rq()
On 04/02/2019 13:22, Chris Wilson wrote:
In the next patch, we add another user that wants to check whether
requests can be merge into a single HW execution, and in the future we
want to add more conditions under which requests from the same context
cannot be merge. In preparation, extract out can_merge_rq().
v2: Reorder tests to decide if we can continue filling ELSP and bonus
comments.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 35 ++--
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e37f207afb5a..66d465708bc6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -285,12 +285,11 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
}
__maybe_unused static inline bool
-assert_priority_queue(const struct intel_engine_execlists *execlists,
- const struct i915_request *prev,
+assert_priority_queue(const struct i915_request *prev,
const struct i915_request *next)
{
- if (!prev)
- return true;
+ const struct intel_engine_execlists *execlists =
+ >engine->execlists;
/*
* Without preemption, the prev may refer to the still active element
@@ -601,6 +600,17 @@ static bool can_merge_ctx(const struct intel_context *prev,
return true;
}
+static bool can_merge_rq(const struct i915_request *prev,
+const struct i915_request *next)
+{
+ GEM_BUG_ON(!assert_priority_queue(prev, next));
+
+ if (!can_merge_ctx(prev->hw_context, next->hw_context))
+ return false;
+
+ return true;
+}
+
static void port_assign(struct execlist_port *port, struct i915_request *rq)
{
GEM_BUG_ON(rq == port_request(port));
@@ -753,8 +763,6 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
int i;
priolist_for_each_request_consume(rq, rn, p, i) {
- GEM_BUG_ON(!assert_priority_queue(execlists, last, rq));
-
/*
* Can we combine this request with the current port?
* It has to be the same context/ringbuffer and not
@@ -766,8 +774,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* second request, and so we never need to tell the
* hardware about the first.
*/
- if (last &&
- !can_merge_ctx(rq->hw_context, last->hw_context)) {
+ if (last && !can_merge_rq(last, rq)) {
/*
* If we are on the second port and cannot
* combine this request with the last, then we
@@ -776,6 +783,14 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (port == last_port)
goto done;
+/*
+* We must not populate both ELSP[] with the
+* same LRCA, i.e. we must submit 2 different
+* contexts if we submit 2 ELSP.
+*/
+ if (last->hw_context == rq->hw_context)
+ goto done;
+
/*
* If GVT overrides us we only ever submit
* port[0], leaving port[1] empty. Note that we
@@ -787,7 +802,6 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
ctx_single_port_submission(rq->hw_context))
goto done;
-GEM_BUG_ON(last->hw_context == rq->hw_context);
if (submit)
port_assign(port, last);
@@ -826,8 +840,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* request triggering preemption on the next dequeue (or subsequent
* interrupt for secondary ports).
*/
- execlists->queue_priority_hint =
- port != execlists->port ? rq_prio(last) : INT_MIN;
+ execlists->queue_priority_hint = queue_prio(execlists);
if (submit) {
port_assign(port, last);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/22] drm/i915: Keep timeline HWSP allocated until idle across the system
On 04/02/2019 13:22, Chris Wilson wrote:
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay recycling available
cachelines and unpinning old HWSP until the next idle point.
An easy option would be to simply keep all used HWSP until the system as
a whole was idle, i.e. we could release them all at once on parking.
However, on a busy system, we may never see a global idle point,
essentially meaning the resource will be leaked until we are forced to
do a GC pass. We already employ a fine-grained idle detection mechanism
for vma, which we can reuse here so that each cacheline can be freed
immediately after the last request using it is retired.
v3: Keep track of the activity of each cacheline.
v4: cacheline_free() on canceling the seqno tracking
v5: Finally with a testcase to exercise wraparound
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 30 +-
drivers/gpu/drm/i915/i915_timeline.c | 264 --
drivers/gpu/drm/i915/i915_timeline.h | 9 +-
.../gpu/drm/i915/selftests/i915_timeline.c| 110
4 files changed, 374 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ed9f16bca4fe..057bffa56700 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -331,11 +331,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (tmp != rq);
}
-static u32 timeline_get_seqno(struct i915_timeline *tl)
-{
- return tl->seqno += 1 + tl->has_initial_breadcrumb;
-}
-
static void move_to_timeline(struct i915_request *request,
struct i915_timeline *timeline)
{
@@ -556,8 +551,10 @@ struct i915_request *
i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context
*ctx)
{
struct drm_i915_private *i915 = engine->i915;
- struct i915_request *rq;
struct intel_context *ce;
+ struct i915_timeline *tl;
+ struct i915_request *rq;
+ u32 seqno;
int ret;
lockdep_assert_held(>drm.struct_mutex);
@@ -632,24 +629,26 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
}
}
- rq->rcustate = get_state_synchronize_rcu();
-
INIT_LIST_HEAD(>active_list);
+
+ tl = ce->ring->timeline;
+ ret = i915_timeline_get_seqno(tl, rq, );
+ if (ret)
+ goto err_free;
+
rq->i915 = i915;
rq->engine = engine;
rq->gem_context = ctx;
rq->hw_context = ce;
rq->ring = ce->ring;
- rq->timeline = ce->ring->timeline;
+ rq->timeline = tl;
GEM_BUG_ON(rq->timeline == >timeline);
- rq->hwsp_seqno = rq->timeline->hwsp_seqno;
+ rq->hwsp_seqno = tl->hwsp_seqno;
+ rq->rcustate = get_state_synchronize_rcu(); /* acts as smp_mb() */
spin_lock_init(>lock);
- dma_fence_init(>fence,
- _fence_ops,
- >lock,
- rq->timeline->fence_context,
- timeline_get_seqno(rq->timeline));
+ dma_fence_init(>fence, _fence_ops, >lock,
+ tl->fence_context, seqno);
/* We bump the ref for the fence chain */
i915_sw_fence_init(_request_get(rq)->submit, submit_notify);
@@ -710,6 +709,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
GEM_BUG_ON(!list_empty(>sched.signalers_list));
GEM_BUG_ON(!list_empty(>sched.waiters_list));
+err_free:
kmem_cache_free(global.slab_requests, rq);
err_unreserve:
unreserve_gt(i915);
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index b2202d2e58a2..3608e544012f 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -6,19 +6,29 @@
#include "i915_drv.h"
-#include "i915_timeline.h"
+#include "i915_active.h"
#include "i915_syncmap.h"
+#include "i915_timeline.h"
struct i915_timeline_hwsp {
- struct i915_vma *vma;
+ struct i915_gt_timelines *gt;
struct list_head free_link;
+ struct i915_vma *vma;
u64 free_bitmap;
};
-static inline struct i915_timeline_hwsp *
-i915_timeline_hwsp(const struct i915_timeline *tl)
+struct i915_timeline_cacheline {
+ struct i915_active active;
+ struct i915_timeline_hwsp *hwsp;
+ void *vaddr;
+ unsigned int cacheline : 6;
+ unsigned int free : 1;
+};
+
+static inline struct drm_i915_private *
+hwsp_to_i915(struct i915_timeline_hwsp *hwsp)
{
- return tl->hwsp_ggtt->private;
+ return container_of(hwsp->gt, struct drm_i915_private, gt.timelines);
}
static struct
Re: [Intel-gfx] [PATCH 17/22] drm/i915: Pull i915_gem_active into the i915_active family
On 04/02/2019 13:22, Chris Wilson wrote:
Looking forward, we need to break the struct_mutex dependency on
i915_gem_active. In the meantime, external use of i915_gem_active is
quite beguiling, little do new users suspect that it implies a barrier
as each request it tracks must be ordered wrt the previous one. As one
of many, it can be used to track activity across multiple timelines, a
shared fence, which fits our unordered request submission much better. We
need to steer external users away from the singular, exclusive fence
imposed by i915_gem_active to i915_active instead. As part of that
process, we move i915_gem_active out of i915_request.c into
i915_active.c to start separating the two concepts, and rename it to
i915_active_request (both to tie it to the concept of tracking just one
request, and to give it a longer, less appealing name).
Signed-off-by: Chris Wilson
Assuming the patch was unchanged, I'll copy from last round:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_active.c| 62 ++-
drivers/gpu/drm/i915/i915_active.h| 349
drivers/gpu/drm/i915/i915_active_types.h | 16 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_context.c | 4 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 4 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_gem_object.h| 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 10 +-
drivers/gpu/drm/i915/i915_request.c | 35 +-
drivers/gpu/drm/i915/i915_request.h | 383 --
drivers/gpu/drm/i915/i915_reset.c | 2 +-
drivers/gpu/drm/i915/i915_timeline.c | 25 +-
drivers/gpu/drm/i915/i915_timeline.h | 14 +-
drivers/gpu/drm/i915/i915_vma.c | 12 +-
drivers/gpu/drm/i915/i915_vma.h | 2 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 33 +-
drivers/gpu/drm/i915/selftests/intel_lrc.c| 4 +-
.../gpu/drm/i915/selftests/mock_timeline.c| 4 +-
21 files changed, 474 insertions(+), 503 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d23092d8c89f..846900535d10 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -21,7 +21,7 @@ static struct i915_global_active {
} global;
struct active_node {
- struct i915_gem_active base;
+ struct i915_active_request base;
struct i915_active *ref;
struct rb_node node;
u64 timeline;
@@ -33,7 +33,7 @@ __active_park(struct i915_active *ref)
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
- GEM_BUG_ON(i915_gem_active_isset(>base));
+ GEM_BUG_ON(i915_active_request_isset(>base));
kmem_cache_free(global.slab_cache, it);
}
ref->tree = RB_ROOT;
@@ -53,18 +53,18 @@ __active_retire(struct i915_active *ref)
}
static void
-node_retire(struct i915_gem_active *base, struct i915_request *rq)
+node_retire(struct i915_active_request *base, struct i915_request *rq)
{
__active_retire(container_of(base, struct active_node, base)->ref);
}
static void
-last_retire(struct i915_gem_active *base, struct i915_request *rq)
+last_retire(struct i915_active_request *base, struct i915_request *rq)
{
__active_retire(container_of(base, struct i915_active, last));
}
-static struct i915_gem_active *
+static struct i915_active_request *
active_instance(struct i915_active *ref, u64 idx)
{
struct active_node *node;
@@ -85,7 +85,7 @@ active_instance(struct i915_active *ref, u64 idx)
* twice for the same timeline (as the older rbtree element will be
* retired before the new request added to last).
*/
- old = i915_gem_active_raw(>last, BKL(ref));
+ old = i915_active_request_raw(>last, BKL(ref));
if (!old || old->fence.context == idx)
goto out;
@@ -110,7 +110,7 @@ active_instance(struct i915_active *ref, u64 idx)
node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
/* kmalloc may retire the ref->last (thanks shrinker)! */
- if (unlikely(!i915_gem_active_raw(>last, BKL(ref {
+ if (unlikely(!i915_active_request_raw(>last, BKL(ref {
kmem_cache_free(global.slab_cache, node);
goto out;
}
@@ -118,7 +118,7 @@ active_instance(struct i915_active *ref, u64 idx)
if (unlikely(!node))
return ERR_PTR(-ENOMEM);
- init_request_active(>base, node_retire);
+ i915_active_request_init(>base, NULL, node_retire);
node->ref = ref;
node->timeline = idx;
@@ -133,7 +133,7 @@
Re: [Intel-gfx] [PATCH 15/22] drm/i915: Make request allocation caches global
On 04/02/2019 13:22, Chris Wilson wrote
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity is temporal across the system) it is the
default behaviour of the system at large to amalgamate matching caches.
The benefit for us is much reduced pointer dancing along the frequent
allocation paths.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_active.c| 9 ++-
drivers/gpu/drm/i915/i915_active.h| 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 32 +
drivers/gpu/drm/i915/i915_globals.c | 49 ++
drivers/gpu/drm/i915/i915_globals.h | 14
drivers/gpu/drm/i915/i915_pci.c | 8 ++-
drivers/gpu/drm/i915/i915_request.c | 53 ---
drivers/gpu/drm/i915/i915_request.h | 10 +++
drivers/gpu/drm/i915/i915_scheduler.c | 66 +++
drivers/gpu/drm/i915/i915_scheduler.h | 34 --
drivers/gpu/drm/i915/intel_guc_submission.c | 3 +-
drivers/gpu/drm/i915/intel_lrc.c | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 17 -
drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 48 +++---
.../gpu/drm/i915/selftests/mock_gem_device.c | 26
drivers/gpu/drm/i915/selftests/mock_request.c | 12 ++--
drivers/gpu/drm/i915/selftests/mock_request.h | 7 --
20 files changed, 248 insertions(+), 153 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_globals.c
create mode 100644 drivers/gpu/drm/i915/i915_globals.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1787e1299b1b..a1d834068765 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -77,6 +77,7 @@ i915-y += \
i915_gem_tiling.o \
i915_gem_userptr.o \
i915_gemfs.o \
+ i915_globals.o \
i915_query.o \
i915_request.o \
i915_scheduler.o \
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 64661c41532b..d23092d8c89f 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -251,7 +251,7 @@ void i915_active_fini(struct i915_active *ref)
#include "selftests/i915_active.c"
#endif
-int __init i915_global_active_init(void)
+int i915_global_active_init(void)
These can't remain __init, since they are only called from the global
__init one?
{
global.slab_cache = KMEM_CACHE(active_node, SLAB_HWCACHE_ALIGN);
if (!global.slab_cache)
@@ -260,7 +260,12 @@ int __init i915_global_active_init(void)
return 0;
}
-void __exit i915_global_active_exit(void)
+void i915_global_active_shrink(void)
+{
+ kmem_cache_shrink(global.slab_cache);
+}
+
+void i915_global_active_exit(void)
{
kmem_cache_destroy(global.slab_cache);
}
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 179b47aeec33..6c56d10b1f59 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -71,6 +71,7 @@ static inline void i915_active_fini(struct i915_active *ref)
{ }
#endif
int i915_global_active_init(void);
+void i915_global_active_shrink(void);
void i915_global_active_exit(void);
#endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3e4538ce5276..e48e3c228d9c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1459,9 +1459,6 @@ struct drm_i915_private {
struct kmem_cache *objects;
struct kmem_cache *vmas;
struct kmem_cache *luts;
- struct kmem_cache *requests;
- struct kmem_cache *dependencies;
- struct kmem_cache *priorities;
const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2c6161c89cc7..d82e4f990586 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -42,6 +42,7 @@
#include "i915_drv.h"
#include "i915_gem_clflush.h"
#include "i915_gemfs.h"
+#include "i915_globals.h"
#include "i915_reset.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
@@ -2916,12 +2917,11 @@ static void shrink_caches(struct drm_i915_private *i915)
* filled slabs to prioritise allocating from the mostly full slabs,
* with the aim of reducing fragmentation.
*/
-
[Intel-gfx] [PATCH 4/4] drm/i915: W/A for underruns with WM1+ disabled on icl
From: Ville Syrjälä
Disabling WM1+ on ICL causes tons of underruns with
linear/X-tiled framebuffers. We can avoid this by flipping
on a chicken bit affecting the way the hw fill the FIFO.
This may not be the final solution but should hopefully
avoid some underruns in the meantime.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ede54fdc1676..12964b0fbc54 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7618,6 +7618,7 @@ enum {
#define _PIPEB_CHICKEN 0x71038
#define _PIPEC_CHICKEN 0x72038
#define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
+#define PM_FILL_MAINTAIN_DBUF_FULLNESS(1 << 0)
#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
_PIPEB_CHICKEN)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5df035fce2d0..c5d5309ff789 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3912,6 +3912,13 @@ static void skl_set_pipe_chicken(struct intel_crtc *crtc)
if (INTEL_GEN(dev_priv) >= 11)
tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
+ /*
+* W/A for underruns with linear/X-tiled with
+* WM1+ disabled.
+*/
+ if (INTEL_GEN(dev_priv) >= 11)
+ tmp |= PM_FILL_MAINTAIN_DBUF_FULLNESS;
+
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Extract skl_set_pipe_chicken()
From: Ville Syrjälä
We need configure PIPE_CHICKEN during fastboot as well. Let's extract
it to a helper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 32 ++--
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df7a7a310f2f..2c867a93903d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3896,6 +3896,25 @@ void intel_finish_reset(struct drm_i915_private
*dev_priv)
clear_bit(I915_RESET_MODESET, _priv->gpu_error.flags);
}
+static void skl_set_pipe_chicken(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tmp;
+
+ tmp = I915_READ(PIPE_CHICKEN(pipe));
+
+ /*
+* Display WA #1153: icl
+* enable hardware to bypass the alpha math
+* and rounding for per-pixel values 00 and 0xff
+*/
+ if (INTEL_GEN(dev_priv) >= 11)
+ tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
+
+ I915_WRITE(PIPE_CHICKEN(pipe), tmp);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -5782,7 +5801,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
struct intel_atomic_state *old_intel_state =
to_intel_atomic_state(old_state);
bool psl_clkgate_wa;
- u32 pipe_chicken;
if (WARN_ON(intel_crtc->active))
return;
@@ -5839,16 +5857,8 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
*/
intel_color_load_luts(pipe_config);
- /*
-* Display WA #1153: enable hardware to bypass the alpha math
-* and rounding for per-pixel values 00 and 0xff
-*/
- if (INTEL_GEN(dev_priv) >= 11) {
- pipe_chicken = I915_READ(PIPE_CHICKEN(pipe));
- if (!(pipe_chicken & PER_PIXEL_ALPHA_BYPASS_EN))
- I915_WRITE_FW(PIPE_CHICKEN(pipe),
- pipe_chicken | PER_PIXEL_ALPHA_BYPASS_EN);
- }
+ if (INTEL_GEN(dev_priv) >= 9)
+ skl_set_pipe_chicken(intel_crtc);
intel_ddi_set_pipe_settings(pipe_config);
if (!transcoder_is_dsi(cpu_transcoder))
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Fix wm latency==0 disable on skl+
From: Ville Syrjälä
When adding the early latency==0 check back I neglected to
realize that we no longer have a way to return a failure
from the wm computation like we had in the past (since we
now calculate wms before ddb allocations). Also plane_en
being false doesn't actually indicate that the level is
invalid as it wil also happen when the plane is not
enabled.
skl_allocate_pipe_ddb() starts scanning from the maximum
watermark level and it stops as soon as it finds a level
that is deemed viable. The assumption being that if level
n+1 is valid then level n is valid as well. Thus if we
now disable any watermark level by zeroing its latency
the code will think that level to be actually valid
and won't confirm whether the actually enabled lower
watermark level(s) actually fit into the allotted ddb
space. This results in hilarious watermark values that
exceed the ddb allocation of the plane.
The way we must now indicate a failure is to assign an
unreasoanbly big value to min_ddb_alloc which will then
make skl_allocate_pipe_ddb() reject the entire level.
Cc: Matt Roper
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ed9786241307..d6186c90bc10 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4694,8 +4694,11 @@ static void skl_compute_plane_wm(const struct
intel_crtc_state *cstate,
uint_fixed_16_16_t selected_result;
u32 res_blocks, res_lines, min_ddb_alloc = 0;
- if (latency == 0)
+ if (latency == 0) {
+ /* reject it */
+ result->min_ddb_alloc = U16_MAX;
return;
+ }
/* Display WA #1141: kbl,cfl */
if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Setup PIPE_CHICKEN for fastsets too
From: Ville Syrjälä Configure PIPE_CHICKEN during intel_update_pipe_config() to make sure we have our chickens in a row with fastboot too. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 2c867a93903d..5df035fce2d0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3959,6 +3959,9 @@ static void intel_update_pipe_config(const struct intel_crtc_state *old_crtc_sta I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), SKL_BOTTOM_COLOR_GAMMA_ENABLE | SKL_BOTTOM_COLOR_CSC_ENABLE); + + if (INTEL_GEN(dev_priv) >= 9) + skl_set_pipe_chicken(crtc); } static void intel_fdi_normal_train(struct intel_crtc *crtc) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/22] drm/i915: Allocate active tracking nodes from a slabcache
On 04/02/2019 13:22, Chris Wilson wrote:
Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and hopefully better fragmentation reduction.
v3: Nothing device specific left, it's just a slabcache that we can
make global.
v4: Include i915_active.h and don't put the initfunc under DEBUG_GEM
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 31 +++---
drivers/gpu/drm/i915/i915_active.h | 3 +++
drivers/gpu/drm/i915/i915_pci.c| 4
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index b1fefe98f9a6..64661c41532b 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -9,6 +9,17 @@
#define BKL(ref) (&(ref)->i915->drm.struct_mutex)
+/*
+ * Active refs memory management
+ *
+ * To be more economical with memory, we reap all the i915_active trees as
+ * they idle (when we know the active requests are inactive) and allocate the
+ * nodes from a local slab cache to hopefully reduce the fragmentation.
+ */
+static struct i915_global_active {
+ struct kmem_cache *slab_cache;
+} global;
+
struct active_node {
struct i915_gem_active base;
struct i915_active *ref;
@@ -23,7 +34,7 @@ __active_park(struct i915_active *ref)
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
GEM_BUG_ON(i915_gem_active_isset(>base));
- kfree(it);
+ kmem_cache_free(global.slab_cache, it);
}
ref->tree = RB_ROOT;
}
@@ -96,11 +107,11 @@ active_instance(struct i915_active *ref, u64 idx)
p = >rb_left;
}
- node = kmalloc(sizeof(*node), GFP_KERNEL);
+ node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
/* kmalloc may retire the ref->last (thanks shrinker)! */
if (unlikely(!i915_gem_active_raw(>last, BKL(ref {
- kfree(node);
+ kmem_cache_free(global.slab_cache, node);
goto out;
}
@@ -239,3 +250,17 @@ void i915_active_fini(struct i915_active *ref)
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/i915_active.c"
#endif
+
+int __init i915_global_active_init(void)
+{
+ global.slab_cache = KMEM_CACHE(active_node, SLAB_HWCACHE_ALIGN);
+ if (!global.slab_cache)
+ return -ENOMEM;
+
+ return 0;
+}
+
+void __exit i915_global_active_exit(void)
+{
+ kmem_cache_destroy(global.slab_cache);
+}
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index ec4b66efd9a7..179b47aeec33 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -70,4 +70,7 @@ void i915_active_fini(struct i915_active *ref);
static inline void i915_active_fini(struct i915_active *ref) { }
#endif
+int i915_global_active_init(void);
+void i915_global_active_exit(void);
+
#endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 5d05572c9ff4..852b6b4e8ed8 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -28,6 +28,7 @@
#include
+#include "i915_active.h"
#include "i915_drv.h"
#include "i915_selftest.h"
@@ -800,6 +801,8 @@ static int __init i915_init(void)
bool use_kms = true;
int err;
+ i915_global_active_init();
+
err = i915_mock_selftests();
if (err)
return err > 0 ? 0 : err;
@@ -831,6 +834,7 @@ static void __exit i915_exit(void)
return;
pci_unregister_driver(_pci_driver);
+ i915_global_active_exit();
}
module_init(i915_init);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Monday, February 4, 2019 10:54 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>dri-
>de...@lists.freedesktop.org; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>
>On Mon, Feb 04, 2019 at 05:08:40PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Monday, February 4, 2019 8:55 PM
>> >To: Shankar, Uma
>> >Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
>> >; Lankhorst, Maarten
>> >; dri- de...@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>> >
>> >On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
>> >> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
>> >> > Create a new connector property to program colorspace to sink
>> >> > devices. Modern sink devices support more than 1 type of
>> >> > colorspace like 601, 709, BT2020 etc. This helps to switch based
>> >> > on content type which is to be displayed. The decision lies with
>> >> > compositors as to in which scenarios, a particular colorspace will be
>picked.
>> >> >
>> >> > This will be helpful mostly to switch to higher gamut colorspaces
>> >> > like BT2020 when the media content is encoded as BT2020. Thereby
>> >> > giving a good visual experience to users.
>> >> >
>> >> > The expectation from userspace is that it should parse the EDID
>> >> > and get supported colorspaces. Use this property and switch to
>> >> > the one supported. Sink supported colorspaces should be retrieved
>> >> > by userspace from EDID and driver will not explicitly expose them.
>> >> >
>> >> > Basically the expectation from userspace is:
>> >> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >> >colorspace
>> >> > - Set this new property to let the sink know what it
>> >> >converted the CRTC output to.
>> >> >
>> >> > v2: Addressed Maarten and Ville's review comments. Enhanced the
>> >> > colorspace enum to incorporate both HDMI and DP supported
>> >> > colorspaces. Also, added a default option for colorspace.
>> >> >
>> >> > v3: Removed Adobe references from enum definitions as per Ville,
>> >> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
>> >> > unset state where driver will assign the colorspace is not chosen
>> >> > by user, suggested by Ville and Maarten. Addressed other misc
>> >> > review comments from Maarten. Split the changes to have separate
>> >> > colorspace property for DP and HDMI.
>> >> >
>> >> > v4: Addressed Chris and Ville's review comments, and created a
>> >> > common colorspace property for DP and HDMI, filtered the list
>> >> > based on the colorspaces supported by the respective protocol standard.
>> >> >
>> >> > v5: Made the property creation helper accept enum list based on
>> >> > platform capabilties as suggested by Shashank. Consolidated HDMI
>> >> > and DP property creation in the common helper.
>> >> >
>> >> > v6: Addressed Shashank's review comments.
>> >> >
>> >> > v7: Added defines instead of enum in uapi as per Brian Starkey's
>> >> > suggestion in order to go with string matching at userspace.
>> >> > Updated the commit message to add more details as well kernel docs.
>> >> >
>> >> > v8: Addressed Maarten's review comments.
>> >> >
>> >> > v9: Removed macro defines from uapi as per Brian Starkey and
>> >> > Daniel Stone's comments and moved to drm include file. Moved back
>> >> > to older design with exposing all HDMI colorspaces to userspace
>> >> > since infoframe capability is there even on legacy platforms, as
>> >> > per Ville's review comments.
>> >> >
>> >> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >> >
>> >> > Signed-off-by: Uma Shankar
>> >> > Acked-by: Jani Nikula
>> >> > Reviewed-by: Shashank Sharma
>> >> > Reviewed-by: Maarten Lankhorst
>> >> >
>> >> > ---
>> >> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
>> >> > drivers/gpu/drm/drm_connector.c | 75
>> >+++
>> >> > include/drm/drm_connector.h | 46
>> >> > 3 files changed, 125 insertions(+)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > index 9a1f41a..9b5d44f 100644
>> >> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> > @@ -746,6 +746,8 @@ static int
>> >> > drm_atomic_connector_set_property(struct
>> >drm_connector *connector,
>> >> > return -EINVAL;
>> >> > }
>> >> > state->content_protection = val;
>> >> > + } else if (property == connector->colorspace_property) {
>> >> > + state->colorspace = val;
>> >> > } else if (property ==
Re: [Intel-gfx] [PATCH] drm/i915: do not return invalid pointers as a *dentry
On Thu, Jan 31, 2019 at 07:17:02PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote: > > On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote: > > > When calling debugfs functions, they can now return error values if > > > something went wrong. If that happens, return a NULL as a *dentry to > > > the relay core instead of passing it an illegal pointer. > > > > > > The relay core should be able to handle an illegal pointer, but add this > > > check to be safe. > > > > > > Cc: Jani Nikula > > > Cc: Joonas Lahtinen > > > Cc: Rodrigo Vivi > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Cc: intel-gfx@lists.freedesktop.org > > > Cc: dri-de...@lists.freedesktop.org > > > Signed-off-by: Greg Kroah-Hartman > > > --- > > > drivers/gpu/drm/i915/intel_guc_log.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c > > > b/drivers/gpu/drm/i915/intel_guc_log.c > > > index d3ebdbc0182e..8bf03497dcd8 100644 > > > --- a/drivers/gpu/drm/i915/intel_guc_log.c > > > +++ b/drivers/gpu/drm/i915/intel_guc_log.c > > > @@ -140,6 +140,9 @@ static struct dentry *create_buf_file_callback(const > > > char *filename, > > > > > > buf_file = debugfs_create_file(filename, mode, > > > parent, buf, _file_operations); > > > + if (IS_ERR(buf_file)) > > > + return NULL; > > > > I still see a return NULL inside debugfs_create_file on master, > > but probably you are ahead with some change that I didn't see yet right? > > Yes, this patch is in linux-next now and should go to Linus for > 5.0-final: > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=driver-core-linus=ff9fb72bc07705c00795ca48631f7fffe24d2c6b > > > I'm just wondering if it wouldn't be better for now to go with > > > > if (IS_ERR_OR_NULL(buf_file)) > > Not really, because the next line is: > > > > return buf_file; > > So it's the same thing :) > > > apparently we also need it on i915_debugfs.c i915_debugfs_register() > > I have a bunch of patches I'm working on to go through and fix up all of > this (you shouldn't be checking the return value at all, unless you > really want to use it as a "real" dentry and not just something that > debugfs uses internally. > > But for now, you should be fine, that call will only fail if you are out > of memory, or did something really wrong. Reviewed-by: Rodrigo Vivi do you wanna push this with your own stuff or do you want me to pick up on drm-intel-next? > > thanks, > > greg k-h > ___ > 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 6/6] drm/drv: Remove drm_dev_unplug()
On 2/3/19 5:42 PM, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index e0941200edc6..87210d4a9e53 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -354,23 +354,6 @@ void drm_dev_exit(int idx)
> }
> EXPORT_SYMBOL(drm_dev_exit);
>
> -/**
> - * drm_dev_unplug - unplug a DRM device
> - * @dev: DRM device
> - *
> - * This unplugs a hotpluggable DRM device, which makes it inaccessible to
> - * userspace operations. Entry-points can use drm_dev_enter() and
> - * drm_dev_exit() to protect device resources in a race free manner. This
> - * essentially unregisters the device like drm_dev_unregister(), but can be
> - * called while there are still open users of @dev.
> - */
> -void drm_dev_unplug(struct drm_device *dev)
> -{
> - drm_dev_unregister(dev);
> - drm_dev_put(dev);
> -}
> -EXPORT_SYMBOL(drm_dev_unplug);
> -
> /*
>* DRM internal mount
>* We want to be able to allocate our own "struct address_space" to control
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index c50696c82a42..b8765a6fc092 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -730,7 +730,6 @@ void drm_dev_put(struct drm_device *dev);
> void drm_put_dev(struct drm_device *dev);
> bool drm_dev_enter(struct drm_device *dev, int *idx);
> void drm_dev_exit(int idx);
> -void drm_dev_unplug(struct drm_device *dev);
>
> /**
>* drm_dev_is_unplugged - is a DRM device unplugged
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/xen: Use drm_dev_unregister()
On 2/3/19 5:41 PM, Noralf Trønnes wrote: > drm_dev_unplug() has been stripped down and is going away. Open code its > 2 remaining function calls. > > Also remove the drm_dev_is_unplugged() check since this can't be true > before drm_dev_unregister() is called which happens after the check. > > Cc: Oleksandr Andrushchenko > Signed-off-by: Noralf Trønnes > --- > drivers/gpu/drm/xen/xen_drm_front.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 3e78a832d7f9..5c5eb24c6342 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -576,12 +576,9 @@ static void xen_drm_drv_fini(struct xen_drm_front_info > *front_info) > if (!dev) > return; > > - /* Nothing to do if device is already unplugged */ > - if (drm_dev_is_unplugged(dev)) > - return; xen_drm_drv_fini is called when the backend changes its state [1], so I just use the check above to prevent possible race conditions here, e.g. do not allow to run unregister code if it is already in progress So, I think we should keep this and probably just add a comment why it is here > - > drm_kms_helper_poll_fini(dev); > - drm_dev_unplug(dev); > + drm_dev_unregister(dev); > + drm_dev_put(dev); > > front_info->drm_info = NULL; > [1] https://elixir.bootlin.com/linux/v5.0-rc5/ident/displback_disconnect ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
>
> Maybe s/unplugged/unregistered/ ?
>
> I looked at drm_device->registered, but using that would mean that
> drm_dev_is_unplugged() would return before drm_device is registered.
> And given that its current purpose is to prevent race against connector
> registration, I stayed away from it.
>
> Noralf.
>
>
> drivers/gpu/drm/drm_drv.c | 27 +++
> include/drm/drm_drv.h | 10 --
> 2 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05bbc2b622fc..e0941200edc6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
>*/
> void drm_dev_unplug(struct drm_device *dev)
> {
> - /*
> - * After synchronizing any critical read section is guaranteed to see
> - * the new value of ->unplugged, and any critical section which might
> - * still have seen the old value of ->unplugged is guaranteed to have
> - * finished.
> - */
> - dev->unplugged = true;
> - synchronize_srcu(_unplug_srcu);
> -
> drm_dev_unregister(dev);
> drm_dev_put(dev);
> }
> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
>* drm_dev_register() but does not deallocate the device. The caller must
> call
>* drm_dev_put() to drop their final reference.
>*
> - * A special form of unregistering for hotpluggable devices is
> drm_dev_unplug(),
> - * which can be called while there are still open users of @dev.
> + * This function can be called while there are still open users of @dev as
> long
> + * as the driver protects its device resources using drm_dev_enter() and
> + * drm_dev_exit().
>*
>* This should be called first in the device teardown code to make sure
> - * userspace can't access the device instance any more.
> + * userspace can't access the device instance any more. Drivers that support
> + * device unplug will probably want to call drm_atomic_helper_shutdown()
> first
> + * in order to disable the hardware on regular driver module unload.
>*/
> void drm_dev_unregister(struct drm_device *dev)
> {
> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_LEGACY))
> drm_lastclose(dev);
>
> + /*
> + * After synchronizing any critical read section is guaranteed to see
> + * the new value of ->unplugged, and any critical section which might
> + * still have seen the old value of ->unplugged is guaranteed to have
> + * finished.
> + */
> + dev->unplugged = true;
> + synchronize_srcu(_unplug_srcu);
> +
> dev->registered = false;
>
> drm_client_dev_unregister(dev);
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index ca46a45a9cce..c50696c82a42 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
>* drm_dev_is_unplugged - is a DRM device unplugged
>* @dev: DRM device
>*
> - * This function can be called to check whether a hotpluggable is unplugged.
> - * Unplugging itself is singalled through drm_dev_unplug(). If a device is
> - * unplugged, these two functions guarantee that any store before calling
> - * drm_dev_unplug() is visible to callers of this function after it completes
> + * This function can be called to check whether @dev is unregistered. This
> can
> + * be used to detect that the underlying parent device is gone.
>*
> - * WARNING: This function fundamentally races against drm_dev_unplug(). It is
> - * recommended that drivers instead use the underlying drm_dev_enter() and
> + * WARNING: This function fundamentally races against drm_dev_unregister().
> It
> + * is recommended that drivers instead use the underlying drm_dev_enter() and
>* drm_dev_exit() function pairs.
>*/
> static inline bool drm_dev_is_unplugged(struct drm_device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm: Fix drm_release() and device unplug
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspace already holds a ref on drm_device through the drm_minor,
> it's not necessary to add extra ref counting based on no open file
> handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().
>
> We now has this:
s/has/have ?
> - Userpace holds a ref on drm_device as long as there's open fd(s)
> - The driver holds a ref on drm_device as long as it's bound to the
>struct device
>
> When both sides are done with drm_device, it is released.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 6 +-
> drivers/gpu/drm/drm_file.c | 6 ++
> 2 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 381581b01d48..05bbc2b622fc 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -376,11 +376,7 @@ void drm_dev_unplug(struct drm_device *dev)
> synchronize_srcu(_unplug_srcu);
>
> drm_dev_unregister(dev);
> -
> - mutex_lock(_global_mutex);
> - if (dev->open_count == 0)
> - drm_dev_put(dev);
> - mutex_unlock(_global_mutex);
> + drm_dev_put(dev);
> }
> EXPORT_SYMBOL(drm_dev_unplug);
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 46f48f245eb5..3f20f598cd7c 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -479,11 +479,9 @@ int drm_release(struct inode *inode, struct file *filp)
>
> drm_file_free(file_priv);
>
> - if (!--dev->open_count) {
> + if (!--dev->open_count)
> drm_lastclose(dev);
> - if (drm_dev_is_unplugged(dev))
> - drm_put_dev(dev);
> - }
> +
> mutex_unlock(_global_mutex);
>
> drm_minor_release(minor);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Drop WaIncreaseLatencyIPCEnabled/1140 for cnl
On Mon, Feb 04, 2019 at 09:49:42AM -0800, Rodrigo Vivi wrote: > On Mon, Feb 04, 2019 at 07:40:56PM +0200, Ville Syrjälä wrote: > > On Thu, Jan 31, 2019 at 10:10:47AM -0800, Rodrigo Vivi wrote: > > > On Thu, Jan 31, 2019 at 09:42:16AM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for > > > > early cnl steppings. Also switch the kbl/cfl case to check > > > > for IS_GEN9_BC() for brevity. It ends up being the same thing > > > > because IPC is disabled on SKL due to w/a #0477. > > > > > > I think this deserves a commend in the code, otherwise someone > > > in the future might not notice that and send a patch to replace > > > 9_BC per KBL || CFL... > > > > > > anyway: > > > > > > Reviewed-by: Rodrigo Vivi > > > > Ta. I just noticed there were some other IS_KBL||IS_CFL cases in the > > code as well. So maybe I'll just leave it as is here too. > > > > One thing I don't like is that w/a #0477 is in the device info. I think > > I'll want to move that into ipc code to make it less confusing what's > > going on. > > > yeap, I think it makes more sense to have the wa inside ipc code rather > than inside device info. But on the other hand it gets confuse if we > end up reading has_ipc=1 and then we have to go inside ipc to find > out that actually has_ipc is lying :/ It's not really lying though. The hw has it, we're just not supposed to use it. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Ville Syrjälä > > > > --- > > > > drivers/gpu/drm/i915/intel_pm.c | 4 +--- > > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > > b/drivers/gpu/drm/i915/intel_pm.c > > > > index 306e41ccc50e..55491e2d5134 100644 > > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > > @@ -4701,9 +4701,7 @@ static void skl_compute_plane_wm(const struct > > > > intel_crtc_state *cstate, > > > > * WaIncreaseLatencyIPCEnabled: kbl,cfl > > > > * Display WA #1141: kbl,cfl > > > > */ > > > > - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) || > > > > - IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) && > > > > - dev_priv->ipc_enabled) > > > > + if (IS_GEN9_BC(dev_priv) && dev_priv->ipc_enabled) > > > > latency += 4; > > > > > > > > if (skl_needs_memory_bw_wa(dev_priv) && wp->x_tiled) > > > > -- > > > > 2.19.2 > > > > > > > > ___ > > > > Intel-gfx mailing list > > > > Intel-gfx@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Ville Syrjälä > > Intel > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: HDCP state handling in ddi_update_pipe (rev2)
== Series Details ==
Series: drm/i915: HDCP state handling in ddi_update_pipe (rev2)
URL : https://patchwork.freedesktop.org/series/56182/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536_full -> Patchwork_12128_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12128_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@reset-stress:
- shard-snb: PASS -> INCOMPLETE [fdo#105411]
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-kbl: NOTRUN -> FAIL [fdo#103158]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-glk: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw: PASS -> FAIL [fdo#103355]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: PASS -> FAIL [fdo#103167] +4
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk: PASS -> FAIL [fdo#103166] +2
Possible fixes
* igt@gem_pwrite_pread@uncached-copy-performance:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@extended-pageflip-hang-newfb-render-b:
- shard-glk: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-kbl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- shard-kbl: DMESG-WARN [fdo#103313] / [fdo#105345] / [fdo#108473]
-> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-apl: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_setmode@basic:
- shard-kbl: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
* igt@pm_rc6_residency@rc6-accuracy:
- shard-kbl: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
[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#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
[fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105345]: https://bugs.freedesktop.org/show_bug.cgi?id=105345
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108590]: https://bugs.freedesktop.org/show_bug.cgi?id=108590
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/22] drm/i915/execlists: Suppress mere WAIT preemption (rev2)
== Series Details ==
Series: series starting with [01/22] drm/i915/execlists: Suppress mere WAIT
preemption (rev2)
URL : https://patchwork.freedesktop.org/series/56183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536_full -> Patchwork_12127_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12127_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-kbl: NOTRUN -> FAIL [fdo#103158]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-glk: PASS -> FAIL [fdo#103167] +4
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-apl: NOTRUN -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-glk: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@gem_busy@extended-semaphore-blt:
- shard-kbl: {SKIP} [fdo#109271] -> PASS +5
- shard-glk: {SKIP} [fdo#109271] -> PASS +3
* igt@gem_busy@extended-semaphore-vebox:
- shard-apl: {SKIP} [fdo#109271] -> PASS +3
* igt@gem_mmap_gtt@hang:
- shard-kbl: FAIL [fdo#109469] -> PASS
- shard-hsw: FAIL [fdo#109469] -> PASS
- shard-snb: FAIL [fdo#109469] -> PASS
- shard-apl: FAIL [fdo#109469] -> PASS
* igt@gem_pwrite_pread@uncached-copy-performance:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS +1
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- shard-kbl: DMESG-WARN [fdo#103313] / [fdo#105345] / [fdo#108473]
-> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-kbl: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105345]: https://bugs.freedesktop.org/show_bug.cgi?id=105345
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108590]: https://bugs.freedesktop.org/show_bug.cgi?id=108590
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109469]: https://bugs.freedesktop.org/show_bug.cgi?id=109469
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12127
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Drop WaIncreaseLatencyIPCEnabled/1140 for cnl
On Mon, Feb 04, 2019 at 07:40:56PM +0200, Ville Syrjälä wrote: > On Thu, Jan 31, 2019 at 10:10:47AM -0800, Rodrigo Vivi wrote: > > On Thu, Jan 31, 2019 at 09:42:16AM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for > > > early cnl steppings. Also switch the kbl/cfl case to check > > > for IS_GEN9_BC() for brevity. It ends up being the same thing > > > because IPC is disabled on SKL due to w/a #0477. > > > > I think this deserves a commend in the code, otherwise someone > > in the future might not notice that and send a patch to replace > > 9_BC per KBL || CFL... > > > > anyway: > > > > Reviewed-by: Rodrigo Vivi > > Ta. I just noticed there were some other IS_KBL||IS_CFL cases in the > code as well. So maybe I'll just leave it as is here too. > > One thing I don't like is that w/a #0477 is in the device info. I think > I'll want to move that into ipc code to make it less confusing what's > going on. yeap, I think it makes more sense to have the wa inside ipc code rather than inside device info. But on the other hand it gets confuse if we end up reading has_ipc=1 and then we have to go inside ipc to find out that actually has_ipc is lying :/ > > > > > > > > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/intel_pm.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > b/drivers/gpu/drm/i915/intel_pm.c > > > index 306e41ccc50e..55491e2d5134 100644 > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > @@ -4701,9 +4701,7 @@ static void skl_compute_plane_wm(const struct > > > intel_crtc_state *cstate, > > >* WaIncreaseLatencyIPCEnabled: kbl,cfl > > >* Display WA #1141: kbl,cfl > > >*/ > > > - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) || > > > - IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) && > > > - dev_priv->ipc_enabled) > > > + if (IS_GEN9_BC(dev_priv) && dev_priv->ipc_enabled) > > > latency += 4; > > > > > > if (skl_needs_memory_bw_wa(dev_priv) && wp->x_tiled) > > > -- > > > 2.19.2 > > > > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel > ___ > 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] ✓ Fi.CI.IGT: success for drm/i915: HDCP state handling in ddi_update_pipe
== Series Details ==
Series: drm/i915: HDCP state handling in ddi_update_pipe
URL : https://patchwork.freedesktop.org/series/56182/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536_full -> Patchwork_12125_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12125_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_flip@flip-vs-suspend-interruptible}:
- shard-kbl: PASS -> DMESG-WARN
Known issues
Here are the changes found in Patchwork_12125_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@pi-ringfull-blt:
- shard-kbl: NOTRUN -> FAIL [fdo#103158]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-apl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@gem_pwrite_pread@uncached-copy-performance:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: FAIL [fdo#103232] -> PASS +3
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_flip@basic-flip-vs-dpms:
- shard-kbl: DMESG-WARN [fdo#103313] / [fdo#105345] / [fdo#108473]
-> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-apl: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +3
* igt@kms_setmode@basic:
- shard-kbl: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-snb: INCOMPLETE [fdo#105411] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
[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#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105345]: https://bugs.freedesktop.org/show_bug.cgi?id=105345
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108590]: https://bugs.freedesktop.org/show_bug.cgi?id=108590
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12125
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Drop WaIncreaseLatencyIPCEnabled/1140 for cnl
On Thu, Jan 31, 2019 at 10:10:47AM -0800, Rodrigo Vivi wrote: > On Thu, Jan 31, 2019 at 09:42:16AM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for > > early cnl steppings. Also switch the kbl/cfl case to check > > for IS_GEN9_BC() for brevity. It ends up being the same thing > > because IPC is disabled on SKL due to w/a #0477. > > I think this deserves a commend in the code, otherwise someone > in the future might not notice that and send a patch to replace > 9_BC per KBL || CFL... > > anyway: > > Reviewed-by: Rodrigo Vivi Ta. I just noticed there were some other IS_KBL||IS_CFL cases in the code as well. So maybe I'll just leave it as is here too. One thing I don't like is that w/a #0477 is in the device info. I think I'll want to move that into ipc code to make it less confusing what's going on. > > > > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_pm.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index 306e41ccc50e..55491e2d5134 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -4701,9 +4701,7 @@ static void skl_compute_plane_wm(const struct > > intel_crtc_state *cstate, > > * WaIncreaseLatencyIPCEnabled: kbl,cfl > > * Display WA #1141: kbl,cfl > > */ > > - if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) || > > - IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) && > > - dev_priv->ipc_enabled) > > + if (IS_GEN9_BC(dev_priv) && dev_priv->ipc_enabled) > > latency += 4; > > > > if (skl_needs_memory_bw_wa(dev_priv) && wp->x_tiled) > > -- > > 2.19.2 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Enable transition watermarks for glk
On Thu, Jan 31, 2019 at 08:07:35PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/4] drm/i915: Enable transition watermarks for
> glk
> URL : https://patchwork.freedesktop.org/series/56025/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12103_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_12103_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_12103_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_12103_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy:
> - shard-glk: PASS -> FAIL +2
(kms_cursor_legacy:2984) CRITICAL: Test assertion failure function
two_screens_cursor_vs_flip, file ../tests/kms_cursor_legacy.c:1207:
(kms_cursor_legacy:2984) CRITICAL: Failed assertion: shared[child] >
vrefresh[child]*target[child] / 2
(kms_cursor_legacy:2984) CRITICAL: completed 382 cursor updated in a period of
30 flips, we expect to complete approximately 3840 updates, with the threshold
set at 1920
Subtest 2x-cursor-vs-flip-legacy failed.
2x-cursor-vs-flip-atomic and 2x-long-cursor-vs-flip-atomic also flipped
to fail but that fact is not reflected here for some reason.
Anyways, this failure doesn't seem directly related to watermarks.
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_12103_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_schedule@pi-ringfull-render:
> - shard-apl: NOTRUN -> FAIL [fdo#103158]
>
> * igt@gem_ppgtt@blt-vs-render-ctx0:
> - shard-glk: PASS -> DMESG-WARN [fdo#105763] / [fdo#106538]
>
> * igt@kms_cursor_crc@cursor-64x64-suspend:
> - shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
>
> * igt@kms_plane_multiple@atomic-pipe-a-tiling-none:
> - shard-apl: NOTRUN -> FAIL [fdo#103166]
>
> * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
> - shard-apl: PASS -> FAIL [fdo#103166]
> - shard-glk: PASS -> FAIL [fdo#103166]
>
>
> Possible fixes
>
> * igt@gem_eio@reset-stress:
> - shard-hsw: INCOMPLETE [fdo#103540] / [fdo#109482] -> PASS
>
> * igt@gem_workarounds@suspend-resume:
> - shard-kbl: INCOMPLETE [fdo#103665] -> PASS
>
> * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
> - shard-apl: DMESG-WARN [fdo#107956] -> PASS
>
> * igt@kms_color@pipe-b-ctm-max:
> - shard-apl: FAIL [fdo#108147] -> PASS
>
> * igt@kms_cursor_crc@cursor-256x256-suspend:
> - shard-hsw: INCOMPLETE [fdo#103540] -> PASS
>
> * igt@kms_flip@flip-vs-blocking-wf-vblank:
> - shard-snb: DMESG-WARN [fdo#107469] -> PASS
>
> * igt@kms_flip@flip-vs-panning-interruptible:
> - shard-hsw: DMESG-WARN [fdo#102614] -> PASS
>
> * igt@kms_plane@plane-position-covered-pipe-c-planes:
> - shard-apl: FAIL [fdo#103166] -> PASS +1
>
> * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
> - shard-glk: FAIL [fdo#103166] -> PASS
>
> * igt@kms_setmode@basic:
> - shard-apl: FAIL [fdo#99912] -> PASS
>
> * igt@pm_rc6_residency@rc6-accuracy:
> - shard-snb: {SKIP} [fdo#109271] -> PASS
>
> * igt@sw_sync@sync_busy_fork:
> - shard-snb: INCOMPLETE [fdo#105411] -> PASS +1
>
>
> Warnings
>
> * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
> - shard-snb: {SKIP} [fdo#109271] / [fdo#109278] -> DMESG-WARN
> [fdo#107956]
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
> [fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
> [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
> [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
> [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
> [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
> [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
> [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
> [fdo#106538]: https://bugs.freedesktop.org/show_bug.cgi?id=106538
> [fdo#107469]: https://bugs.freedesktop.org/show_bug.cgi?id=107469
> [fdo#107956]:
Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
Den 04.02.2019 16.41, skrev Daniel Vetter:
> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
>> The only thing now that makes drm_dev_unplug() special is that it sets
>> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
>> can remove drm_dev_unplug().
>>
>> Signed-off-by: Noralf Trønnes
>> ---
[...]
>> drivers/gpu/drm/drm_drv.c | 27 +++
>> include/drm/drm_drv.h | 10 --
>> 2 files changed, 19 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 05bbc2b622fc..e0941200edc6 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
>> */
>> void drm_dev_unplug(struct drm_device *dev)
>> {
>> -/*
>> - * After synchronizing any critical read section is guaranteed to see
>> - * the new value of ->unplugged, and any critical section which might
>> - * still have seen the old value of ->unplugged is guaranteed to have
>> - * finished.
>> - */
>> -dev->unplugged = true;
>> -synchronize_srcu(_unplug_srcu);
>> -
>> drm_dev_unregister(dev);
>> drm_dev_put(dev);
>> }
>> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
>> * drm_dev_register() but does not deallocate the device. The caller must
>> call
>> * drm_dev_put() to drop their final reference.
>> *
>> - * A special form of unregistering for hotpluggable devices is
>> drm_dev_unplug(),
>> - * which can be called while there are still open users of @dev.
>> + * This function can be called while there are still open users of @dev as
>> long
>> + * as the driver protects its device resources using drm_dev_enter() and
>> + * drm_dev_exit().
>> *
>> * This should be called first in the device teardown code to make sure
>> - * userspace can't access the device instance any more.
>> + * userspace can't access the device instance any more. Drivers that support
>> + * device unplug will probably want to call drm_atomic_helper_shutdown()
>> first
>
> Read once more with a bit more coffee, spotted this:
>
> s/first/afterwards/ - shutting down the hw before we've taken it away from
> userspace is kinda the wrong way round. It should be the inverse of driver
> load, which is 1) allocate structures 2) prep hw 3) register driver with
> the world (simplified ofc).
>
The problem is that drm_dev_unregister() sets the device as unplugged
and if drm_atomic_helper_shutdown() is called afterwards it's not
allowed to touch hardware.
I know it's the wrong order, but the only way to do it in the right
order is to have a separate function that sets unplugged:
drm_dev_unregister();
drm_atomic_helper_shutdown();
drm_dev_set_unplugged();
Noralf.
>> + * in order to disable the hardware on regular driver module unload.
>> */
>> void drm_dev_unregister(struct drm_device *dev)
>> {
>> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
>> if (drm_core_check_feature(dev, DRIVER_LEGACY))
>> drm_lastclose(dev);
>>
>> +/*
>> + * After synchronizing any critical read section is guaranteed to see
>> + * the new value of ->unplugged, and any critical section which might
>> + * still have seen the old value of ->unplugged is guaranteed to have
>> + * finished.
>> + */
>> +dev->unplugged = true;
>> +synchronize_srcu(_unplug_srcu);
>> +
>> dev->registered = false;
>>
>> drm_client_dev_unregister(dev);
>> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>> index ca46a45a9cce..c50696c82a42 100644
>> --- a/include/drm/drm_drv.h
>> +++ b/include/drm/drm_drv.h
>> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
>> * drm_dev_is_unplugged - is a DRM device unplugged
>> * @dev: DRM device
>> *
>> - * This function can be called to check whether a hotpluggable is unplugged.
>> - * Unplugging itself is singalled through drm_dev_unplug(). If a device is
>> - * unplugged, these two functions guarantee that any store before calling
>> - * drm_dev_unplug() is visible to callers of this function after it
>> completes
>> + * This function can be called to check whether @dev is unregistered. This
>> can
>> + * be used to detect that the underlying parent device is gone.
>
> I think it'd be good to keep the first part, and just update the reference
> to drm_dev_unregister. So:
>
> * This function can be called to check whether a hotpluggable is unplugged.
> * Unplugging itself is singalled through drm_dev_unregister(). If a device is
> * unplugged, these two functions guarantee that any store before calling
> * drm_dev_unregister() is visible to callers of this function after it
> * completes.
>
> I think your version shrugs a few important details under the rug. With
> those nits addressed:
>
> Reviewed-by: Daniel Vetter
>
> Cheers, Daniel
>
>> *
>> - * WARNING: This function
Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
On Mon, Feb 04, 2019 at 05:08:40PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Monday, February 4, 2019 8:55 PM
> >To: Shankar, Uma
> >Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> >;
> >Lankhorst, Maarten ; dri-
> >de...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
> >
> >On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
> >> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> >> > Create a new connector property to program colorspace to sink
> >> > devices. Modern sink devices support more than 1 type of colorspace
> >> > like 601, 709, BT2020 etc. This helps to switch based on content
> >> > type which is to be displayed. The decision lies with compositors as
> >> > to in which scenarios, a particular colorspace will be picked.
> >> >
> >> > This will be helpful mostly to switch to higher gamut colorspaces
> >> > like BT2020 when the media content is encoded as BT2020. Thereby
> >> > giving a good visual experience to users.
> >> >
> >> > The expectation from userspace is that it should parse the EDID and
> >> > get supported colorspaces. Use this property and switch to the one
> >> > supported. Sink supported colorspaces should be retrieved by
> >> > userspace from EDID and driver will not explicitly expose them.
> >> >
> >> > Basically the expectation from userspace is:
> >> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >> >colorspace
> >> > - Set this new property to let the sink know what it
> >> >converted the CRTC output to.
> >> >
> >> > v2: Addressed Maarten and Ville's review comments. Enhanced the
> >> > colorspace enum to incorporate both HDMI and DP supported
> >> > colorspaces. Also, added a default option for colorspace.
> >> >
> >> > v3: Removed Adobe references from enum definitions as per Ville,
> >> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
> >> > unset state where driver will assign the colorspace is not chosen by
> >> > user, suggested by Ville and Maarten. Addressed other misc review
> >> > comments from Maarten. Split the changes to have separate colorspace
> >> > property for DP and HDMI.
> >> >
> >> > v4: Addressed Chris and Ville's review comments, and created a
> >> > common colorspace property for DP and HDMI, filtered the list based
> >> > on the colorspaces supported by the respective protocol standard.
> >> >
> >> > v5: Made the property creation helper accept enum list based on
> >> > platform capabilties as suggested by Shashank. Consolidated HDMI and
> >> > DP property creation in the common helper.
> >> >
> >> > v6: Addressed Shashank's review comments.
> >> >
> >> > v7: Added defines instead of enum in uapi as per Brian Starkey's
> >> > suggestion in order to go with string matching at userspace. Updated
> >> > the commit message to add more details as well kernel docs.
> >> >
> >> > v8: Addressed Maarten's review comments.
> >> >
> >> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> >> > Stone's comments and moved to drm include file. Moved back to older
> >> > design with exposing all HDMI colorspaces to userspace since
> >> > infoframe capability is there even on legacy platforms, as per
> >> > Ville's review comments.
> >> >
> >> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> >> >
> >> > Signed-off-by: Uma Shankar
> >> > Acked-by: Jani Nikula
> >> > Reviewed-by: Shashank Sharma
> >> > Reviewed-by: Maarten Lankhorst
> >> > ---
> >> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> >> > drivers/gpu/drm/drm_connector.c | 75
> >+++
> >> > include/drm/drm_connector.h | 46
> >> > 3 files changed, 125 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> > b/drivers/gpu/drm/drm_atomic_uapi.c
> >> > index 9a1f41a..9b5d44f 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >> > return -EINVAL;
> >> > }
> >> > state->content_protection = val;
> >> > +} else if (property == connector->colorspace_property) {
> >> > +state->colorspace = val;
> >> > } else if (property == config->writeback_fb_id_property) {
> >> > struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
> >NULL, val);
> >> > int ret =
> >> > drm_atomic_set_writeback_fb_for_connector(state,
> >fb);
> >> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >> > *val = state->picture_aspect_ratio;
> >> > } else if (property == config->content_type_property) {
> >> > *val
Re: [Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe
On 2/4/2019 10:34 PM, Maarten Lankhorst wrote:
Op 04-02-2019 om 17:51 schreef C, Ramalingam:
On 2/4/2019 10:13 PM, Maarten Lankhorst wrote:
Op 04-02-2019 om 16:44 schreef Ramalingam C:
The downgrade of the fullmodeset into fastset
intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
DDI. Hence breaks the HDCP state change handling.
We also don't have any hdcp tests in CI, because the shard runs don't
have hdcp capable outputs :-/
So this change fixs it by handling the HDCP state change request at
intel_encoder->update_pipe too along with enable and disable of the DDI.
Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
v2:
Added commit id that broke the HDCP [Daniel]
Signed-off-by: Ramalingam C
cc: Maarten Lankhorst
cc: Hans de Goede
cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca705546a0ab..2323b7cb1d38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
{
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED)
+ intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ else if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ intel_hdcp_disable(to_intel_connector(conn_state->connector));
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
Does anything bad happen if we enable HDCP when it's already enabled? Might
want to have a test for that. :)
nothing will happen. intel_hdcp_atomic_check will prune the request.
mode_changed is not set in such case.
There are other reasons than HDCP that could cause fastsets, so what happens if
update_pipe is called and content protection stays the same?
If the HDCP is enabled we dont trigger the HDCP_enable from the fastset.
But if the HDCP is failed every fastset will be triggering the HDCP
enable. But that is the expectation. If user dont want further attempt
on hdcp auth, user will set it to undesired.
--Ram
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Saturday, February 2, 2019 12:31 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and
>enable modeset
>
>On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
>> This patch attaches the colorspace connector property to the hdmi
>> connector. Based on colorspace change, modeset will be triggered to
>> switch to new colorspace.
>>
>> Based on colorspace property value create an infoframe with
>> appropriate colorspace. This can be used to send an infoframe packet
>> with proper colorspace value set which will help to enable wider color
>> gamut like BT2020 on sink.
>>
>> This patch attaches and enables HDMI colorspace, DP will be taken care
>> separately.
>>
>> v2: Merged the changes of creating infoframe as well to this patch as
>> per Maarten's suggestion.
>>
>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> colorspaces as suggested by Ville and Maarten.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handle the
>> default case properly.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed a checkpatch complaint, Addressed Maarten' review comment,
>> updated the RB from Maarten and Jani's ack.
>>
>> Signed-off-by: Uma Shankar
>> Acked-by: Jani Nikula
>> Reviewed-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>> drivers/gpu/drm/i915/intel_connector.c | 8
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_hdmi.c | 25 +
>> 4 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 16263ad..a4bb906 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>drm_connector *conn,
>> */
>> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>> ||
>> +new_conn_state->base.colorspace !=
>> +old_conn_state->base.colorspace ||
>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>base.picture_aspect_ratio ||
>> new_conn_state->base.content_type != old_conn_state-
>>base.content_type ||
>> new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode)
>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> b/drivers/gpu/drm/i915/intel_connector.c
>> index ee16758..8352d0b 100644
>> --- a/drivers/gpu/drm/i915/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> @@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector
>*connector,
>> connector->dev->mode_config.aspect_ratio_property,
>> DRM_MODE_PICTURE_ASPECT_NONE);
>> }
>> +
>> +void
>> +intel_attach_colorspace_property(struct drm_connector *connector) {
>> +if (!drm_mode_create_colorspace_property(connector))
>> +drm_object_attach_property(>base,
>> + connector->colorspace_property, 0); }
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 85b913e..5178a9a 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct
>> drm_connector *connector, void
>> intel_attach_force_audio_property(struct drm_connector *connector);
>> void intel_attach_broadcast_rgb_property(struct drm_connector
>> *connector); void intel_attach_aspect_ratio_property(struct
>> drm_connector *connector);
>> +void intel_attach_colorspace_property(struct drm_connector
>> +*connector);
>>
>> /* intel_csr.c */
>> void intel_csr_ucode_init(struct drm_i915_private *); diff --git
>> a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 97a98e1..5c5009d 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct
>intel_encoder *encoder,
>> else
>> frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>
>> +if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
>> +/* Set ITU 709 as default for HDMI */
>> +frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;
>
>Default should map
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Verify that waiters do not report as busy
If we queue requests that must wait for the current spinner to finish,
those waiting engines should not be reported as busy (or else we perturb
scheduling logic that tries to distribute workloads onto idle engines --
if all engines are busy, even those waiting, it degrades into a
round-robin free-for-all).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/perf_pmu.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/tests/i915/perf_pmu.c b/tests/i915/perf_pmu.c
index 755e1b9ee..aa2583205 100644
--- a/tests/i915/perf_pmu.c
+++ b/tests/i915/perf_pmu.c
@@ -541,6 +541,67 @@ most_busy_check_all(int gem_fd, const struct
intel_execution_engine2 *e,
gem_quiescent_gpu(gem_fd);
}
+static void
+busy_wait_check_all(int gem_fd,
+ const struct intel_execution_engine2 *e,
+ const unsigned int num_engines)
+{
+ const struct intel_execution_engine2 *e_;
+ uint64_t tval[2][num_engines];
+ uint64_t val[num_engines];
+ int fd[num_engines];
+ unsigned long slept;
+ igt_spin_t *spin;
+ unsigned int busy_idx, i;
+
+ /*
+* One engine busy spins, all others waiting for the spinner, with
+* the expected result that only active spinner is reported as busy.
+*/
+
+ spin = __spin_poll(gem_fd, 0, e2ring(gem_fd, e));
+ spin->obj[0].flags |= EXEC_OBJECT_WRITE;
+
+ i = 0;
+ for_each_engine_class_instance(gem_fd, e_) {
+ if (e == e_)
+ busy_idx = i;
+ else
+ __submit_spin_batch(gem_fd, spin, e_, 64);
+
+ val[i++] = I915_PMU_ENGINE_BUSY(e_->class, e_->instance);
+ }
+ igt_assert(i == num_engines);
+
+ fd[0] = -1;
+ for (i = 0; i < num_engines; i++)
+ fd[i] = open_group(val[i], fd[0]);
+
+ /* Small delay to allow engines to start. */
+ usleep(__spin_wait(gem_fd, spin) * num_engines / 1e3);
+
+ pmu_read_multi(fd[0], num_engines, tval[0]);
+ slept = measured_usleep(batch_duration_ns / 1000);
+ pmu_read_multi(fd[0], num_engines, tval[1]);
+
+ end_spin(gem_fd, spin, FLAG_SYNC);
+ igt_spin_batch_free(gem_fd, spin);
+ close(fd[0]);
+
+ for (i = 0; i < num_engines; i++)
+ val[i] = tval[1][i] - tval[0][i];
+
+ log_busy(num_engines, val);
+
+ for (i = 0; i < num_engines; i++) {
+ if (i == busy_idx)
+ assert_within_epsilon(val[i], slept, tolerance);
+ else
+ assert_within_epsilon(val[i], 0.0f, tolerance);
+ }
+ gem_quiescent_gpu(gem_fd);
+}
+
static void
all_busy_check_all(int gem_fd, const unsigned int num_engines,
unsigned int flags)
@@ -1742,6 +1803,9 @@ igt_main
busy_check_all(fd, e, num_engines,
TEST_BUSY | TEST_TRAILING_IDLE);
+ igt_subtest_f("busy-wait-check-all-%s", e->name)
+ busy_wait_check_all(fd, e, num_engines);
+
/**
* Test that when all except one engine are loaded all
* loads are correctly reported.
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v10 2/3] drm: Add DP colorspace property
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Saturday, February 2, 2019 12:48 AM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-gfx@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-de...@lists.freedesktop.org
>Subject: Re: [v10 2/3] drm: Add DP colorspace property
>
>On Wed, Jan 30, 2019 at 06:24:25PM +0530, Uma Shankar wrote:
>> This patch adds a DP colorspace property, enabling userspace to switch
>> to various supported colorspaces.
>> This will help enable BT2020 along with other colorspaces.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced
>> the colorspace enum to incorporate both HDMI and DP supported
>> colorspaces. Also, added a default option for colorspace.
>>
>> v3: Split the changes to have separate colorspace property for DP and
>> HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Merged the DP handling along with platform colorspace handling as
>> per Shashank's comments.
>>
>> v6: Reverted to old design of exposing all colorspaces to userspace as
>> per Ville's review comment
>>
>> v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>>
>> Signed-off-by: Uma Shankar
>> Acked-by: Jani Nikula
>> Reviewed-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_connector.c | 31 +++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index ed10dd9..b331be8 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct
>drm_display_info *info,
>> { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>>
>> +static const struct drm_prop_enum_list dp_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> +{ DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>
>What's with the duplicated 601/709 values? I think in the HDMI verison you had
>only these ones here. Maybe we want to actually state explicitly that they are
>for
>YCbCr, if only to be consistent with the
>BT2020 values.
Yeah they are for YCbCr, will add that detail to be clear.
>
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> +/* DP MSA Colorimetry */
>> +{ DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601"
>},
>> +{ DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709"
>},
>> +{ DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
>> +{ DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide
>Gamut" },
>> +{ DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
>> +{ DRM_MODE_DP_COLORIMETRY_DCI_P3, "DCI-P3" },
>> +{ DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom
>Profile" },
>
>I don't think we want this last one since we don't implement anything that
>could
>transmit the custom profile.
>
>The MSA bits are have "CEA RGB" which we probably want to keep hidden since it
>seems to be just a poorly specced limited range vs. full range knob, and we
>already have a mechanism for that. The Y-only and RAW I guess we can skip. Not
>sure anyone would ever have use for those.
Ok Sure, Will drop this.
Regards,
Uma Shankar
>
>> +};
>> +
>> +
>> /**
>> * DOC: standard connector properties
>> *
>> @@ -1611,6 +1634,14 @@ int drm_mode_create_colorspace_property(struct
>drm_connector *connector)
>>
> ARRAY_SIZE(hdmi_colorspaces));
>> if (!prop)
>> return -ENOMEM;
>> +} else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP
>||
>> + connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort) {
>> +prop = drm_property_create_enum(dev,
>DRM_MODE_PROP_ENUM,
>> +"Colorspace", dp_colorspaces,
>> +ARRAY_SIZE(dp_colorspaces));
>> +
>> +if (!prop)
>> +return -ENOMEM;
>> } else {
>> DRM_DEBUG_KMS("Colorspace property not supported\n");
>> return 0;
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Ville Syrjälä
>Intel
Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, February 4, 2019 8:55 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v10 1/3] drm: Add HDMI colorspace property
>
>On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
>> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
>> > Create a new connector property to program colorspace to sink
>> > devices. Modern sink devices support more than 1 type of colorspace
>> > like 601, 709, BT2020 etc. This helps to switch based on content
>> > type which is to be displayed. The decision lies with compositors as
>> > to in which scenarios, a particular colorspace will be picked.
>> >
>> > This will be helpful mostly to switch to higher gamut colorspaces
>> > like BT2020 when the media content is encoded as BT2020. Thereby
>> > giving a good visual experience to users.
>> >
>> > The expectation from userspace is that it should parse the EDID and
>> > get supported colorspaces. Use this property and switch to the one
>> > supported. Sink supported colorspaces should be retrieved by
>> > userspace from EDID and driver will not explicitly expose them.
>> >
>> > Basically the expectation from userspace is:
>> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >colorspace
>> > - Set this new property to let the sink know what it
>> >converted the CRTC output to.
>> >
>> > v2: Addressed Maarten and Ville's review comments. Enhanced the
>> > colorspace enum to incorporate both HDMI and DP supported
>> > colorspaces. Also, added a default option for colorspace.
>> >
>> > v3: Removed Adobe references from enum definitions as per Ville,
>> > Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
>> > unset state where driver will assign the colorspace is not chosen by
>> > user, suggested by Ville and Maarten. Addressed other misc review
>> > comments from Maarten. Split the changes to have separate colorspace
>> > property for DP and HDMI.
>> >
>> > v4: Addressed Chris and Ville's review comments, and created a
>> > common colorspace property for DP and HDMI, filtered the list based
>> > on the colorspaces supported by the respective protocol standard.
>> >
>> > v5: Made the property creation helper accept enum list based on
>> > platform capabilties as suggested by Shashank. Consolidated HDMI and
>> > DP property creation in the common helper.
>> >
>> > v6: Addressed Shashank's review comments.
>> >
>> > v7: Added defines instead of enum in uapi as per Brian Starkey's
>> > suggestion in order to go with string matching at userspace. Updated
>> > the commit message to add more details as well kernel docs.
>> >
>> > v8: Addressed Maarten's review comments.
>> >
>> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
>> > Stone's comments and moved to drm include file. Moved back to older
>> > design with exposing all HDMI colorspaces to userspace since
>> > infoframe capability is there even on legacy platforms, as per
>> > Ville's review comments.
>> >
>> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >
>> > Signed-off-by: Uma Shankar
>> > Acked-by: Jani Nikula
>> > Reviewed-by: Shashank Sharma
>> > Reviewed-by: Maarten Lankhorst
>> > ---
>> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
>> > drivers/gpu/drm/drm_connector.c | 75
>+++
>> > include/drm/drm_connector.h | 46
>> > 3 files changed, 125 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> > b/drivers/gpu/drm/drm_atomic_uapi.c
>> > index 9a1f41a..9b5d44f 100644
>> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> >return -EINVAL;
>> >}
>> >state->content_protection = val;
>> > + } else if (property == connector->colorspace_property) {
>> > + state->colorspace = val;
>> >} else if (property == config->writeback_fb_id_property) {
>> >struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>> >int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb);
>> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> >*val = state->picture_aspect_ratio;
>> >} else if (property == config->content_type_property) {
>> >*val = state->content_type;
>> > + } else if (property == connector->colorspace_property) {
>> > + *val = state->colorspace;
>> >} else if (property == connector->scaling_mode_property) {
>> >*val = state->scaling_mode;
>> >} else if (property == connector->content_protection_property) {
>> > diff --git
Re: [Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe
Op 04-02-2019 om 17:51 schreef C, Ramalingam:
>
>
> On 2/4/2019 10:13 PM, Maarten Lankhorst wrote:
>> Op 04-02-2019 om 16:44 schreef Ramalingam C:
>>> The downgrade of the fullmodeset into fastset
>>> intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
>>> DDI. Hence breaks the HDCP state change handling.
>>>
>>> We also don't have any hdcp tests in CI, because the shard runs don't
>>> have hdcp capable outputs :-/
>>>
>>> So this change fixs it by handling the HDCP state change request at
>>> intel_encoder->update_pipe too along with enable and disable of the DDI.
>>>
>>> Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
>>>
>>> v2:
>>> Added commit id that broke the HDCP [Daniel]
>>>
>>> Signed-off-by: Ramalingam C
>>> cc: Maarten Lankhorst
>>> cc: Hans de Goede
>>> cc: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/i915/intel_ddi.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>>> b/drivers/gpu/drm/i915/intel_ddi.c
>>> index ca705546a0ab..2323b7cb1d38 100644
>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>>> @@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct
>>> intel_encoder *encoder,
>>> {
>>> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
>>> intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
>>> +
>>> + if (conn_state->content_protection ==
>>> + DRM_MODE_CONTENT_PROTECTION_DESIRED)
>>> + intel_hdcp_enable(to_intel_connector(conn_state->connector));
>>> + else if (conn_state->content_protection ==
>>> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
>>> + intel_hdcp_disable(to_intel_connector(conn_state->connector));
>>> }
>>> static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
>> Does anything bad happen if we enable HDCP when it's already enabled? Might
>> want to have a test for that. :)
> nothing will happen. intel_hdcp_atomic_check will prune the request.
> mode_changed is not set in such case.
There are other reasons than HDCP that could cause fastsets, so what happens if
update_pipe is called and content protection stays the same?
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe
On 2/4/2019 10:13 PM, Maarten Lankhorst wrote:
Op 04-02-2019 om 16:44 schreef Ramalingam C:
The downgrade of the fullmodeset into fastset
intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
DDI. Hence breaks the HDCP state change handling.
We also don't have any hdcp tests in CI, because the shard runs don't
have hdcp capable outputs :-/
So this change fixs it by handling the HDCP state change request at
intel_encoder->update_pipe too along with enable and disable of the DDI.
Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
v2:
Added commit id that broke the HDCP [Daniel]
Signed-off-by: Ramalingam C
cc: Maarten Lankhorst
cc: Hans de Goede
cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca705546a0ab..2323b7cb1d38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
{
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED)
+ intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ else if (conn_state->content_protection ==
+DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ intel_hdcp_disable(to_intel_connector(conn_state->connector));
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
Does anything bad happen if we enable HDCP when it's already enabled? Might
want to have a test for that. :)
nothing will happen. intel_hdcp_atomic_check will prune the request.
mode_changed is not set in such case.
--Ram
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/22] drm/i915: Show support for accurate sw PMU busyness tracking
Quoting Chris Wilson (2019-02-04 13:21:57) > Expose whether or not we support the PMU software tracking in our > scheduler capabilities, so userspace can query at runtime. Another datum: /* * Also there is software busyness tracking available we do not * need the timer for I915_SAMPLE_BUSY counter. * * Use RCS as proxy for all engines. */ else if (intel_engine_supports_stats(i915->engine[RCS])) enable &= ~BIT(I915_SAMPLE_BUSY); becomes a global check rather than a proxy. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe
Op 04-02-2019 om 16:44 schreef Ramalingam C:
> The downgrade of the fullmodeset into fastset
> intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
> DDI. Hence breaks the HDCP state change handling.
>
> We also don't have any hdcp tests in CI, because the shard runs don't
> have hdcp capable outputs :-/
>
> So this change fixs it by handling the HDCP state change request at
> intel_encoder->update_pipe too along with enable and disable of the DDI.
>
> Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
>
> v2:
> Added commit id that broke the HDCP [Daniel]
>
> Signed-off-by: Ramalingam C
> cc: Maarten Lankhorst
> cc: Hans de Goede
> cc: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ca705546a0ab..2323b7cb1d38 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct intel_encoder
> *encoder,
> {
> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
> +
> + if (conn_state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_DESIRED)
> + intel_hdcp_enable(to_intel_connector(conn_state->connector));
> + else if (conn_state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + intel_hdcp_disable(to_intel_connector(conn_state->connector));
> }
>
> static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
Does anything bad happen if we enable HDCP when it's already enabled? Might
want to have a test for that. :)
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
>
>Implement the required WA sequence for KBL to fix the incorrect positioning of
>the window of oppurtunity and enc_en signalling.
Typo in opportunity.
>
>v2:
> WA is moved into the toggle_signalling [Daniel]
>
>Signed-off-by: Ramalingam C
>---
> 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 2c4bf6d0c39f..ae20288f7bbf 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;
> }
>
Would be good to add a comment here as to what exactly is the WA and what
you are trying to do here.
>+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
Re: [Intel-gfx] [PATCH v10 36/40] misc/mei/hdcp: Component framework for I915 Interface
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 36/40] misc/mei/hdcp: Component framework for I915
>Interface
>
>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]
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
This is a new interface change and definitely a lot is changed from the time I
reviewed.
You can drop my RB and I would suggest to go with Daniel and Tomas's feedback
for the same.
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 90
>+++-
> drivers/misc/mei/hdcp/mei_hdcp.h | 5 +++
> 2 files changed, 93 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index edfc70fb0617..be2ce12ca460 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 @@ -692,8 +693,7 @@
>mei_close_hdcp_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_initiate_hdcp2_session,
> .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
>@@ -708,20 +708,106 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .close_hdcp_session = mei_close_hdcp_session, };
>
>+static int mei_component_master_bind(struct device *dev) {
>+ struct mei_cl_device *cldev = to_mei_cl_device(dev);
>+ struct mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
>+ int ret;
>+
>+ dev_info(dev, "%s\n", __func__);
>+ drv_data->comp_master->ops = _hdcp_ops;
>+ drv_data->comp_master->mei_dev = dev;
>+ ret = component_bind_all(dev, drv_data->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 mei_hdcp_drv_data *drv_data = mei_cldev_get_drvdata(cldev);
>+
>+ dev_info(dev, "%s\n", __func__);
>+ component_unbind_all(dev, drv_data->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 mei_hdcp_drv_data *drv_data;
> int ret;
>
> ret = mei_cldev_enable(cldev);
> if (ret < 0)
> dev_err(>dev, "mei_cldev_enable Failed. %d\n", ret);
>
>+ drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
>+ if (!drv_data) {
>+ ret = -ENOMEM;
>+ goto drv_data_exit;
>+ }
>+
>+ drv_data->comp_master = kzalloc(sizeof(*drv_data->comp_master),
>+ GFP_KERNEL);
>+ if (!drv_data->comp_master) {
>+ ret = -ENOMEM;
>+ goto comp_master_exit;
>+ }
>+
>+ drv_data->master_match = NULL;
>+ component_match_add_typed(>dev, _data->master_match,
>+mei_hdcp_component_match,
>+drv_data->comp_master);
>+ if (IS_ERR_OR_NULL(drv_data->master_match)) {
>+ ret = -ENOMEM;
>+ goto match_add_exit;
>+ }
>+
>+ mei_cldev_set_drvdata(cldev, drv_data);
>+ ret = component_master_add_with_match(>dev,
>+_component_master_ops,
>+drv_data->master_match);
>+ if (ret < 0) {
>+ dev_err(>dev, "Master comp add failed %d\n", ret);
>+ mei_cldev_set_drvdata(cldev, NULL);
>+ goto match_add_exit;
>+ }
>+
>+ return 0;
>+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: HDCP state handling in ddi_update_pipe (rev2)
== Series Details ==
Series: drm/i915: HDCP state handling in ddi_update_pipe (rev2)
URL : https://patchwork.freedesktop.org/series/56182/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12128
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56182/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12128 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-skl-guc: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> 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#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[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#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (46 -> 43)
--
Additional (1): fi-byt-j1900
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12128
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12128: b24df62c2118222da94175659678715148fffcdc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b24df62c2118 drm/i915: HDCP state handling in ddi_update_pipe
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12128/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 35/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 35/40] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session
>
>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]
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> 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 5303c729612b..edfc70fb0617 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -639,6 +639,59 @@ mei_enable_hdcp_authentication(struct device *dev,
>struct hdcp_port_data *data)
> return 0;
> }
>
>+/**
>+ * mei_close_hdcp_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
>+ * @hdcp_data: Intel HW specific hdcp data
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_close_hdcp_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 =
>+(u8)GET_MEI_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,
>@@ -652,7 +705,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .repeater_check_flow_prepare_ack =
>mei_repeater_check_flow_prepare_ack,
> .verify_mprime = mei_verify_mprime,
> .enable_hdcp_authentication = mei_enable_hdcp_authentication,
>- .close_hdcp_session = NULL,
>+ .close_hdcp_session = mei_close_hdcp_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
Re: [Intel-gfx] [PATCH v10 34/40] misc/mei/hdcp: Enabling the HDCP authentication
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 34/40] misc/mei/hdcp: Enabling the HDCP authentication
>
>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]
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 54
>+++-
> 1 file changed, 53 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 91f7b08d1df1..5303c729612b 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -587,6 +587,58 @@ static int mei_verify_mprime(struct device *dev, struct
>hdcp_port_data *data,
> return 0;
> }
>
>+/**
>+ * mei_enable_hdcp_authentication() - Mark a port as authenticated
>+through ME FW
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_enable_hdcp_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 = (u8)GET_MEI_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,
>@@ -599,7 +651,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .get_session_key = mei_get_session_key,
> .repeater_check_flow_prepare_ack =
>mei_repeater_check_flow_prepare_ack,
> .verify_mprime = mei_verify_mprime,
>- .enable_hdcp_authentication = NULL,
>+ .enable_hdcp_authentication = mei_enable_hdcp_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
Re: [Intel-gfx] [PATCH v10 33/40] misc/mei/hdcp: Verify M_prime
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 33/40] misc/mei/hdcp: Verify M_prime
>
>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.
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 66
>+++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index c157c18371b4..91f7b08d1df1 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -523,6 +523,70 @@ mei_repeater_check_flow_prepare_ack(struct device
>*dev,
> return 0;
> }
>
>+/**
>+ * mei_verify_mprime() - Verify mprime.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_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_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 =
>+(u8)GET_MEI_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,
>@@ -534,7 +598,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .verify_lprime = mei_verify_lprime,
> .get_session_key = mei_get_session_key,
> .repeater_check_flow_prepare_ack =
>mei_repeater_check_flow_prepare_ack,
>- .verify_mprime = NULL,
>+ .verify_mprime = mei_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
Re: [Intel-gfx] [PATCH v10 32/40] misc/mei/hdcp: Repeater topology verification and ack
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 32/40] misc/mei/hdcp: Repeater topology verification and
>ack
>
>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]
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 76
>+++-
> 1 file changed, 75 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 2be7b6b949c2..c157c18371b4 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -449,6 +449,80 @@ static int mei_get_session_key(struct device *dev,
>struct hdcp_port_data *data,
> return 0;
> }
>
>+/**
>+ * mei_repeater_check_flow_prepare_ack() - Validate the Downstream
>+topology
>+ * and prepare rep_ack.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_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_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 =
>+ (u8)GET_MEI_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,
>@@ -459,7 +533,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .initiate_locality_check = mei_initiate_locality_check,
> .verify_lprime = mei_verify_lprime,
> .get_session_key = mei_get_session_key,
>- .repeater_check_flow_prepare_ack = NULL,
>+ .repeater_check_flow_prepare_ack =
>+mei_repeater_check_flow_prepare_ack,
> .verify_mprime = NULL,
>
Re: [Intel-gfx] [PATCH v10 31/40] misc/mei/hdcp: Prepare Session Key
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 31/40] misc/mei/hdcp: Prepare Session Key
>
>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]
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> 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 3d7767d944dc..2be7b6b949c2 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -393,6 +393,62 @@ static int mei_verify_lprime(struct device *dev, struct
>hdcp_port_data *data,
> return 0;
> }
>
>+/**
>+ * mei_get_session_key() - Prepare SKE_Send_Eks.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_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_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 = (u8)GET_MEI_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,
>@@ -402,7 +458,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .store_pairing_info = mei_store_pairing_info,
> .initiate_locality_check = mei_initiate_locality_check,
> .verify_lprime = mei_verify_lprime,
>- .get_session_key = NULL,
>+ .get_session_key = mei_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
Re: [Intel-gfx] [PATCH v10 30/40] misc/mei/hdcp: Verify L_prime
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 30/40] misc/mei/hdcp: Verify L_prime
>
>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.
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> 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 412a33e29d7d..3d7767d944dc 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -336,6 +336,63 @@ mei_initiate_locality_check(struct device *dev, struct
>hdcp_port_data *data,
> return 0;
> }
>
>+/**
>+ * mei_verify_lprime() - Verify lprime.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_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_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 =
>+(u8)GET_MEI_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,
>@@ -344,7 +401,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .verify_hprime = mei_verify_hprime,
> .store_pairing_info = mei_store_pairing_info,
> .initiate_locality_check = mei_initiate_locality_check,
>- .verify_lprime = NULL,
>+ .verify_lprime = mei_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
Re: [Intel-gfx] [PATCH v10 29/40] misc/mei/hdcp: Initiate Locality check
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 29/40] misc/mei/hdcp: Initiate Locality check
>
>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]
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 56
>+++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index e8396c723ab0..412a33e29d7d 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -282,6 +282,60 @@ mei_store_pairing_info(struct device *dev, struct
>hdcp_port_data *data,
> return 0;
> }
>
>+/**
>+ * mei_initiate_locality_check() - Prepare LC_Init
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @lc_init_data: LC_Init msg output
>+ *
>+ * Return: 0 on Success, <0 on Failure
>+ */
>+static int
>+mei_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 = (u8)GET_MEI_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,
>@@ -289,7 +343,7 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
> .verify_hprime = mei_verify_hprime,
> .store_pairing_info = mei_store_pairing_info,
>- .initiate_locality_check = NULL,
>+ .initiate_locality_check = mei_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
Re: [Intel-gfx] [PATCH v10 28/40] misc/mei/hdcp: Store the HDCP Pairing info
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Subject: [PATCH v10 28/40] misc/mei/hdcp: Store the HDCP Pairing info
>
>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.
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set looks ok. You can keep the RB.
>---
> 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 74219e1487d3..e8396c723ab0 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -224,13 +224,71 @@ static int mei_verify_hprime(struct device *dev, struct
>hdcp_port_data *data,
> return 0;
> }
>
>+/**
>+ * mei_store_pairing_info() - Store pairing info received at ME FW
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_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_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 =
>+(u8)GET_MEI_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,
> .initiate_hdcp2_session = mei_initiate_hdcp2_session,
> .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
> .verify_hprime = mei_verify_hprime,
>- .store_pairing_info = NULL,
>+ .store_pairing_info = mei_store_pairing_info,
> .initiate_locality_check = NULL,
> .verify_lprime = NULL,
> .get_session_key = NULL,
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 20/40] drm/i915: Add HDCP2.2 support for HDMI connectors
On 2/4/2019 9:34 PM, Winkler, Tomas wrote:
On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
v3:
Collected the reviewed-by received.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3b4fe7048af9..2c4bf6d0c39f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2621,7 +2621,8 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
if (is_hdcp_supported(dev_priv, port)) {
int ret = intel_hdcp_init(intel_connector,
- _hdmi_hdcp_shim, false);
+_hdmi_hdcp_shim,
+is_hdcp2_supported(dev_priv));
intel_hdcp_init is always called with is_hdcp2_supported() both for DP and
HDMI, so you can just remove the argument it's redundant.
Thanks for the review Tomas.
Sure. That will reduce a parameter in hdcp_init.
--Ram
if (is_hdcp2_supported())
intel_hdcp2_init(connector);
They are both defied in intel_hdcp.c.
Thanks
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 27/40] misc/mei/hdcp: Verify H_prime
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 27/40] misc/mei/hdcp: Verify H_prime
>
>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.
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set look ok. You can keep the RB.
>---
> 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 24665fff640d..74219e1487d3 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -169,12 +169,67 @@ mei_verify_receiver_cert_prepare_km(struct device
>*dev,
> return 0;
> }
>
>+/**
>+ * mei_verify_hprime() - Verify AKE_Send_H_prime at ME FW.
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_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_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 = (u8)GET_MEI_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_initiate_hdcp2_session,
> .verify_receiver_cert_prepare_km =
>mei_verify_receiver_cert_prepare_km,
>- .verify_hprime = NULL,
>+ .verify_hprime = mei_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
Re: [Intel-gfx] [PATCH v10 26/40] misc/mei/hdcp: Verify Receiver Cert and prepare km
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 26/40] misc/mei/hdcp: Verify Receiver Cert and prepare km
>
>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.
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set look ok. You can keep the RB.
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 81
>+++-
> 1 file changed, 80 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index 534d29c8ee86..24665fff640d 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -90,11 +90,90 @@ mei_initiate_hdcp2_session(struct device *dev, struct
>hdcp_port_data *data,
> return 0;
> }
>
>+/**
>+ * mei_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
>+ * @hdcp_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_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 =
>+(u8)GET_MEI_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 = {
>
Re: [Intel-gfx] [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
>
>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.
>
>Signed-off-by: Ramalingam C
>Reviewed-by: Uma Shankar
Latest set look ok. You can keep the RB.
>---
> drivers/misc/mei/hdcp/mei_hdcp.c | 82
>
> drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
> 2 files changed, 110 insertions(+)
>
>diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
>b/drivers/misc/mei/hdcp/mei_hdcp.c
>index ca5010ad7dd7..534d29c8ee86 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.c
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>@@ -23,6 +23,88 @@
> #include
> #include
> #include
>+#include
>+#include
>+#include
>+
>+#include "mei_hdcp.h"
>+
>+/**
>+ * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session
>+in ME FW
>+ * @dev: device corresponding to the mei_cl_device
>+ * @hdcp_data: Intel HW specific hdcp data
>+ * @ake_data: AKE_Init msg output.
>+ *
>+ * Return: 0 on Success, <0 on Failure.
>+ */
>+static int
>+mei_initiate_hdcp2_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 = (u8)GET_MEI_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_initiate_hdcp2_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..f831db3cbd54 100644
>--- a/drivers/misc/mei/hdcp/mei_hdcp.h
>+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
>@@ -363,4 +363,32 @@ struct wired_cmd_repeater_auth_stream_req_out {
> struct hdcp_port_id port;
> } __packed;
>
>+enum mei_hdcp_ddi {
>+
Re: [Intel-gfx] [PATCH v10 19/40] drm/i915: Add HDCP2.2 support for DP connectors
> -Original Message-
> From: C, Ramalingam
> Sent: Thursday, January 31, 2019 09:00
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma
> Cc: C, Ramalingam
> Subject: [PATCH v10 19/40] drm/i915: Add HDCP2.2 support for DP connectors
>
> On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
> support
> based on the platform capability.
>
> v2:
> Rebased.
> v3:
> Collected the reviewed-by received.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4e36df266ab3..88c889770517 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -7301,7 +7301,7 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
>
> if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
> int ret = intel_hdcp_init(intel_connector,
> _dp_hdcp_shim,
> - false);
> + is_hdcp2_supported(dev_priv));
intel_hdcp_init is always called with is_hdcp2_supported() both for DP and
HDMI, so you can just remove the argument it's redundant.
Thanks
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for HDCP2.2
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for HDCP2.2
>
>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
Looks ok to me.
Reviewed-by: Uma Shankar
>---
> 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
Re: [Intel-gfx] [PATCH v10 20/40] drm/i915: Add HDCP2.2 support for HDMI connectors
>
> On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
> support based on the platform capability.
>
> v2:
> Rebased.
> v3:
> Collected the reviewed-by received.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 3b4fe7048af9..2c4bf6d0c39f 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2621,7 +2621,8 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
>
> if (is_hdcp_supported(dev_priv, port)) {
> int ret = intel_hdcp_init(intel_connector,
> - _hdmi_hdcp_shim, false);
> + _hdmi_hdcp_shim,
> + is_hdcp2_supported(dev_priv));
intel_hdcp_init is always called with is_hdcp2_supported() both for DP and
HDMI, so you can just remove the argument it's redundant.
if (is_hdcp2_supported())
intel_hdcp2_init(connector);
They are both defied in intel_hdcp.c.
Thanks
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 17/40] drm/i915: Implement the HDCP2.2 support for HDMI
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 17/40] drm/i915: Implement the HDCP2.2 support for HDMI
>
>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
Latest set looks ok. You can keep my RB.
>---
> 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 ab376a31cdab..3b4fe7048af9 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),
>+
Re: [Intel-gfx] [PATCH v10 16/40] drm/i915: Implement the HDCP2.2 support for DP
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 16/40] drm/i915: Implement the HDCP2.2 support for DP
>
>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
Latest set looks ok. You can keep my RB.
>---
> 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 9ce05819fc11..b13c41220ce0 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -5843,6 +5843,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_TYPE50
>+ {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;
>+}
>+
[Intel-gfx] [PATCH] drm/i915: HDCP state handling in ddi_update_pipe
The downgrade of the fullmodeset into fastset
intel_encoder->update_pipe, in possible scenario, skips the En/Dis-able
DDI. Hence breaks the HDCP state change handling.
We also don't have any hdcp tests in CI, because the shard runs don't
have hdcp capable outputs :-/
So this change fixs it by handling the HDCP state change request at
intel_encoder->update_pipe too along with enable and disable of the DDI.
Fixes: d19f958db23c ("drm/i915: Enable fastset for non-boot modesets.")
v2:
Added commit id that broke the HDCP [Daniel]
Signed-off-by: Ramalingam C
cc: Maarten Lankhorst
cc: Hans de Goede
cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ca705546a0ab..2323b7cb1d38 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3568,6 +3568,13 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
{
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED)
+ intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ else if (conn_state->content_protection ==
+DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ intel_hdcp_disable(to_intel_connector(conn_state->connector));
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/22] drm/i915/execlists: Suppress mere WAIT preemption (rev2)
== Series Details ==
Series: series starting with [01/22] drm/i915/execlists: Suppress mere WAIT
preemption (rev2)
URL : https://patchwork.freedesktop.org/series/56183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12127
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56183/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12127:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live_timelines}:
- fi-gdg-551: PASS -> DMESG-FAIL
Known issues
Here are the changes found in Patchwork_12127 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-skl-guc: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (46 -> 44)
--
Additional (2): fi-byt-j1900 fi-pnv-d510
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12127
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12127: 8691b315727abf059962d96dfa06c7421977bb61 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8691b315727a semaphore-no-stats
9f920e3ee91d drm/i915: Prioritise non-busywait semaphore workloads
06fce125dbeb drm/i915: Use HW semaphores for inter-engine synchronisation on
gen8+
aa9e7124f366 drm/i915/execlists: Refactor out can_merge_rq()
1b79b880ddc3 drm/i915: Keep timeline HWSP allocated until idle across the system
9bd42aa88e72 drm/i915: Pull i915_gem_active into the i915_active family
86e2bc88638e drm/i915: Add timeline barrier support
7e5abacea1b5 drm/i915: Make request allocation caches global
a765b74ee2e7 drm/i915: Allocate active tracking nodes from a slabcache
2904cb59aa0b drm/i915: Release the active tracker tree upon idling
29a005168925 drm/i915: Generalise GPU activity tracking
d2d2d640906f drm/i915: Don't claim an unstarted request was guilty
4aebd50e5449 drm/i915: Serialise resets with wedging
4abf66518fa5 drm/i915: Wait for old resets before applying debugfs/i915_wedged
50864356bb78 drm/i915: Uninterruptibly drain the timelines on unwedging
fa66be4a0eee drm/i915: Force the GPU reset upon wedging
1680182854c0 drm/i915: Revoke mmaps and prevent access to fence registers
across reset
31eba806a7c5 drm/i915: Show support for accurate sw PMU busyness tracking
a3bddbf1dfc2 drm/i915: Trim NEWCLIENT boosting
cf832a1bbb4e drm/i915/selftests: Exercise some AB...BA preemption chains
c7869190b4c8 drm/i915/execlists: Suppress redundant preemption
1436da54695c drm/i915/execlists: Suppress mere WAIT preemption
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12127/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Maybe s/unplugged/unregistered/ ?
>
> I looked at drm_device->registered, but using that would mean that
> drm_dev_is_unplugged() would return before drm_device is registered.
> And given that its current purpose is to prevent race against connector
> registration, I stayed away from it.
Yeah I think we need to keep the registered state separate from unplugged.
Iirc this exact scenario is what we discussed when you revamped the
unplug infrastructure.
>
> Noralf.
>
>
> drivers/gpu/drm/drm_drv.c | 27 +++
> include/drm/drm_drv.h | 10 --
> 2 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05bbc2b622fc..e0941200edc6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
> */
> void drm_dev_unplug(struct drm_device *dev)
> {
> - /*
> - * After synchronizing any critical read section is guaranteed to see
> - * the new value of ->unplugged, and any critical section which might
> - * still have seen the old value of ->unplugged is guaranteed to have
> - * finished.
> - */
> - dev->unplugged = true;
> - synchronize_srcu(_unplug_srcu);
> -
> drm_dev_unregister(dev);
> drm_dev_put(dev);
> }
> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
> * drm_dev_register() but does not deallocate the device. The caller must
> call
> * drm_dev_put() to drop their final reference.
> *
> - * A special form of unregistering for hotpluggable devices is
> drm_dev_unplug(),
> - * which can be called while there are still open users of @dev.
> + * This function can be called while there are still open users of @dev as
> long
> + * as the driver protects its device resources using drm_dev_enter() and
> + * drm_dev_exit().
> *
> * This should be called first in the device teardown code to make sure
> - * userspace can't access the device instance any more.
> + * userspace can't access the device instance any more. Drivers that support
> + * device unplug will probably want to call drm_atomic_helper_shutdown()
> first
Read once more with a bit more coffee, spotted this:
s/first/afterwards/ - shutting down the hw before we've taken it away from
userspace is kinda the wrong way round. It should be the inverse of driver
load, which is 1) allocate structures 2) prep hw 3) register driver with
the world (simplified ofc).
> + * in order to disable the hardware on regular driver module unload.
> */
> void drm_dev_unregister(struct drm_device *dev)
> {
> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_LEGACY))
> drm_lastclose(dev);
>
> + /*
> + * After synchronizing any critical read section is guaranteed to see
> + * the new value of ->unplugged, and any critical section which might
> + * still have seen the old value of ->unplugged is guaranteed to have
> + * finished.
> + */
> + dev->unplugged = true;
> + synchronize_srcu(_unplug_srcu);
> +
> dev->registered = false;
>
> drm_client_dev_unregister(dev);
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index ca46a45a9cce..c50696c82a42 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
> * drm_dev_is_unplugged - is a DRM device unplugged
> * @dev: DRM device
> *
> - * This function can be called to check whether a hotpluggable is unplugged.
> - * Unplugging itself is singalled through drm_dev_unplug(). If a device is
> - * unplugged, these two functions guarantee that any store before calling
> - * drm_dev_unplug() is visible to callers of this function after it completes
> + * This function can be called to check whether @dev is unregistered. This
> can
> + * be used to detect that the underlying parent device is gone.
I think it'd be good to keep the first part, and just update the reference
to drm_dev_unregister. So:
* This function can be called to check whether a hotpluggable is unplugged.
* Unplugging itself is singalled through drm_dev_unregister(). If a device is
* unplugged, these two functions guarantee that any store before calling
* drm_dev_unregister() is visible to callers of this function after it
* completes.
I think your version shrugs a few important details under the rug. With
those nits addressed:
Reviewed-by: Daniel Vetter
Cheers, Daniel
> *
> - * WARNING: This function fundamentally races against drm_dev_unplug(). It is
> - * recommended that drivers instead use the
Re: [Intel-gfx] [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
daniel,
Could you please review this patch too.? Already Updated this as per
your previous review comment.
--Ram
On 1/31/2019 12:29 PM, Ramalingam C wrote:
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
v2:
WA is moved into the toggle_signalling [Daniel]
Signed-off-by: Ramalingam C
---
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 2c4bf6d0c39f..ae20288f7bbf 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;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/22] drm/i915/execlists: Suppress mere WAIT preemption (rev2)
== Series Details == Series: series starting with [01/22] drm/i915/execlists: Suppress mere WAIT preemption (rev2) URL : https://patchwork.freedesktop.org/series/56183/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Suppress mere WAIT preemption Okay! Commit: drm/i915/execlists: Suppress redundant preemption Okay! Commit: drm/i915/selftests: Exercise some AB...BA preemption chains Okay! Commit: drm/i915: Trim NEWCLIENT boosting Okay! Commit: drm/i915: Show support for accurate sw PMU busyness tracking Okay! Commit: drm/i915: Revoke mmaps and prevent access to fence registers across reset -drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:986:39: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_reset.c:1304:5: warning: context imbalance in 'i915_reset_trylock' - different lock contexts for basic block -drivers/gpu/drm/i915/selftests/../i915_drv.h:3551:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3545:16: warning: expression using sizeof(void) Commit: drm/i915: Force the GPU reset upon wedging Okay! Commit: drm/i915: Uninterruptibly drain the timelines on unwedging Okay! Commit: drm/i915: Wait for old resets before applying debugfs/i915_wedged Okay! Commit: drm/i915: Serialise resets with wedging Okay! Commit: drm/i915: Don't claim an unstarted request was guilty Okay! Commit: drm/i915: Generalise GPU activity tracking +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Release the active tracker tree upon idling Okay! Commit: drm/i915: Allocate active tracking nodes from a slabcache Okay! Commit: drm/i915: Make request allocation caches global -drivers/gpu/drm/i915/selftests/../i915_drv.h:3545:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3542:16: warning: expression using sizeof(void) Commit: drm/i915: Add timeline barrier support Okay! Commit: drm/i915: Pull i915_gem_active into the i915_active family Okay! Commit: drm/i915: Keep timeline HWSP allocated until idle across the system Okay! Commit: drm/i915/execlists: Refactor out can_merge_rq() Okay! Commit: drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ -O:drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:349:25: warning: expression using sizeof(void) Commit: drm/i915: Prioritise non-busywait semaphore workloads Okay! Commit: semaphore-no-stats Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl
On 22/01/2019 16:25, Joonas Lahtinen wrote:
Quoting Lionel Landwerlin (2019-01-16 17:36:22)
With the currently available parameters for the i915-perf stream,
there are still situations that are not well covered :
If an application opens the stream with polling disable or at very low
frequency and OA interrupt enabled, no data will be available even
though somewhere between nothing and half of the OA buffer worth of
data might have landed in memory.
To solve this issue we have a new flush ioctl on the perf stream that
forces the i915-perf driver to look at the state of the buffer when
called and makes any data available through both poll() & read() type
syscalls.
Signed-off-by: Lionel Landwerlin
Link to userspace changes?
Regards, Joonas
Hey Joonas,
I'm about to make the changes in gputop for the high frequency sampling
use case.
One thing I would like to know is whether these new features should be
reported through a flag.
So far we haven't added any new option to the i915/perf driver since the
initial upstreaming series.
The way I'm currently detecting newly added parameters is by using
trying to open the stream with a value that I know will report ENOENT
rather than EINVAL when the feature is not available :
https://github.com/djdeath/intel-gpu-tools/blob/wip/djdeath/oa-interrupts/tests/perf.c#L4345
Is there a better way to do this?
Thanks,
-Lionel
---
drivers/gpu/drm/i915/i915_perf.c | 17 +
include/uapi/drm/i915_drm.h | 19 +++
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index da721fce2543..6c98ffa2135e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2433,6 +2433,20 @@ static void i915_perf_disable_locked(struct
i915_perf_stream *stream)
stream->ops->disable(stream);
}
+/**
+ * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
+ * @stream: An enabled i915 perf stream
+ *
+ * The intention is to flush all the data available for reading from the OA
+ * buffer
+ */
+static void i915_perf_flush_data(struct i915_perf_stream *stream)
+{
+ struct drm_i915_private *dev_priv = stream->dev_priv;
+
+ dev_priv->perf.oa.pollin = oa_buffer_check(stream->dev_priv, true);
+}
+
/**
* i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
* @stream: An i915 perf stream
@@ -2456,6 +2470,9 @@ static long i915_perf_ioctl_locked(struct
i915_perf_stream *stream,
case I915_PERF_IOCTL_DISABLE:
i915_perf_disable_locked(stream);
return 0;
+ case I915_PERF_IOCTL_FLUSH_DATA:
+ i915_perf_flush_data(stream);
+ return 0;
}
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b6db5e544a35..0f0d20080572 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1594,6 +1594,25 @@ struct drm_i915_perf_open_param {
*/
#define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
+/**
+ * Actively check the availability of data from a stream.
+ *
+ * A stream data availability can be driven by two types of events :
+ *
+ * - if enabled, the kernel's hrtimer checking the amount of available data
+ * in the OA buffer through head/tail registers.
+ *
+ * - if enabled, the OA unit's interrupt mechanism
+ *
+ * The kernel hrtimer incur a cost of running callback at fixed time
+ * intervals, while the OA interrupt might only happen rarely. In the
+ * situation where the application has disabled the kernel's hrtimer and only
+ * uses the OA interrupt to know about available data, the application can
+ * request an active check of the available OA data through this ioctl. This
+ * will make any data in the OA buffer available with either poll() or read().
+ */
+#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x2)
+
/**
* Common to all i915 perf records
*/
--
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] [v10 1/3] drm: Add HDMI colorspace property
On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> > Create a new connector property to program colorspace to sink
> > devices. Modern sink devices support more than 1 type of
> > colorspace like 601, 709, BT2020 etc. This helps to switch
> > based on content type which is to be displayed. The decision
> > lies with compositors as to in which scenarios, a particular
> > colorspace will be picked.
> >
> > This will be helpful mostly to switch to higher gamut colorspaces
> > like BT2020 when the media content is encoded as BT2020. Thereby
> > giving a good visual experience to users.
> >
> > The expectation from userspace is that it should parse the EDID
> > and get supported colorspaces. Use this property and switch to the
> > one supported. Sink supported colorspaces should be retrieved by
> > userspace from EDID and driver will not explicitly expose them.
> >
> > Basically the expectation from userspace is:
> > - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >colorspace
> > - Set this new property to let the sink know what it
> >converted the CRTC output to.
> >
> > v2: Addressed Maarten and Ville's review comments. Enhanced
> > the colorspace enum to incorporate both HDMI and DP supported
> > colorspaces. Also, added a default option for colorspace.
> >
> > v3: Removed Adobe references from enum definitions as per
> > Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> > Default to an unset state where driver will assign the colorspace
> > is not chosen by user, suggested by Ville and Maarten. Addressed
> > other misc review comments from Maarten. Split the changes to
> > have separate colorspace property for DP and HDMI.
> >
> > v4: Addressed Chris and Ville's review comments, and created a
> > common colorspace property for DP and HDMI, filtered the list
> > based on the colorspaces supported by the respective protocol
> > standard.
> >
> > v5: Made the property creation helper accept enum list based on
> > platform capabilties as suggested by Shashank. Consolidated HDMI
> > and DP property creation in the common helper.
> >
> > v6: Addressed Shashank's review comments.
> >
> > v7: Added defines instead of enum in uapi as per Brian Starkey's
> > suggestion in order to go with string matching at userspace. Updated
> > the commit message to add more details as well kernel docs.
> >
> > v8: Addressed Maarten's review comments.
> >
> > v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> > Stone's comments and moved to drm include file. Moved back to older
> > design with exposing all HDMI colorspaces to userspace since infoframe
> > capability is there even on legacy platforms, as per Ville's review
> > comments.
> >
> > v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> >
> > Signed-off-by: Uma Shankar
> > Acked-by: Jani Nikula
> > Reviewed-by: Shashank Sharma
> > Reviewed-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > drivers/gpu/drm/drm_connector.c | 75
> > +++
> > include/drm/drm_connector.h | 46
> > 3 files changed, 125 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9a1f41a..9b5d44f 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > return -EINVAL;
> > }
> > state->content_protection = val;
> > + } else if (property == connector->colorspace_property) {
> > + state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) {
> > struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
> > val);
> > int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> > @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > *val = state->picture_aspect_ratio;
> > } else if (property == config->content_type_property) {
> > *val = state->content_type;
> > + } else if (property == connector->colorspace_property) {
> > + *val = state->colorspace;
> > } else if (property == connector->scaling_mode_property) {
> > *val = state->scaling_mode;
> > } else if (property == connector->content_protection_property) {
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 8475396..ed10dd9 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct
> > drm_display_info *info,
> > };
> > DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> >
> >
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/22] drm/i915/execlists: Suppress mere WAIT preemption (rev2)
== Series Details ==
Series: series starting with [01/22] drm/i915/execlists: Suppress mere WAIT
preemption (rev2)
URL : https://patchwork.freedesktop.org/series/56183/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1436da54695c drm/i915/execlists: Suppress mere WAIT preemption
c7869190b4c8 drm/i915/execlists: Suppress redundant preemption
cf832a1bbb4e drm/i915/selftests: Exercise some AB...BA preemption chains
a3bddbf1dfc2 drm/i915: Trim NEWCLIENT boosting
-:26: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b16c765122f9 ("drm/i915:
Priority boost for new clients")'
#26:
References: b16c765122f9 ("drm/i915: Priority boost for new clients")
total: 1 errors, 0 warnings, 0 checks, 8 lines checked
31eba806a7c5 drm/i915: Show support for accurate sw PMU busyness tracking
1680182854c0 drm/i915: Revoke mmaps and prevent access to fence registers
across reset
fa66be4a0eee drm/i915: Force the GPU reset upon wedging
50864356bb78 drm/i915: Uninterruptibly drain the timelines on unwedging
4abf66518fa5 drm/i915: Wait for old resets before applying debugfs/i915_wedged
4aebd50e5449 drm/i915: Serialise resets with wedging
d2d2d640906f drm/i915: Don't claim an unstarted request was guilty
29a005168925 drm/i915: Generalise GPU activity tracking
-:31: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#31:
new file mode 100644
-:36: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#36: FILE: drivers/gpu/drm/i915/i915_active.c:1:
+/*
-:270: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#270: FILE: drivers/gpu/drm/i915/i915_active.h:1:
+/*
-:345: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#345: FILE: drivers/gpu/drm/i915/i915_active_types.h:1:
+/*
-:700: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#700: FILE: drivers/gpu/drm/i915/selftests/i915_active.c:1:
+/*
total: 0 errors, 5 warnings, 0 checks, 798 lines checked
2904cb59aa0b drm/i915: Release the active tracker tree upon idling
a765b74ee2e7 drm/i915: Allocate active tracking nodes from a slabcache
7e5abacea1b5 drm/i915: Make request allocation caches global
-:158: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#158:
new file mode 100644
-:163: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#163: FILE: drivers/gpu/drm/i915/i915_globals.c:1:
+/*
-:218: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#218: FILE: drivers/gpu/drm/i915/i915_globals.h:1:
+/*
-:558: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible
side-effects?
#558: FILE: drivers/gpu/drm/i915/i915_scheduler.h:95:
+#define priolist_for_each_request(it, plist, idx) \
+ for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \
+ list_for_each_entry(it, &(plist)->requests[idx], sched.link)
-:558: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible
side-effects?
#558: FILE: drivers/gpu/drm/i915/i915_scheduler.h:95:
+#define priolist_for_each_request(it, plist, idx) \
+ for (idx = 0; idx < ARRAY_SIZE((plist)->requests); idx++) \
+ list_for_each_entry(it, &(plist)->requests[idx], sched.link)
-:562: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'plist' - possible
side-effects?
#562: FILE: drivers/gpu/drm/i915/i915_scheduler.h:99:
+#define priolist_for_each_request_consume(it, n, plist, idx) \
+ for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+ list_for_each_entry_safe(it, n, \
+&(plist)->requests[idx - 1], \
+sched.link)
-:562: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'idx' - possible
side-effects?
#562: FILE: drivers/gpu/drm/i915/i915_scheduler.h:99:
+#define priolist_for_each_request_consume(it, n, plist, idx) \
+ for (; (idx = ffs((plist)->used)); (plist)->used &= ~BIT(idx - 1)) \
+ list_for_each_entry_safe(it, n, \
+&(plist)->requests[idx - 1], \
+sched.link)
total: 0 errors, 3 warnings, 4 checks, 746 lines checked
86e2bc88638e drm/i915: Add timeline barrier support
9bd42aa88e72 drm/i915: Pull i915_gem_active into the i915_active family
-:690: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#690: FILE: drivers/gpu/drm/i915/i915_gem_fence_reg.c:227:
+ ret = i915_active_request_retire(>last_fence,
>obj->base.dev->struct_mutex);
-:699: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#699: FILE: drivers/gpu/drm/i915/i915_gem_fence_reg.c:236:
+ ret = i915_active_request_retire(>last_fence,
Re: [Intel-gfx] [PATCH v10 02/40] i915/snd_hdac: I915 subcomponent for the snd_hdac
On Mon, 04 Feb 2019 16:00:18 +0100, Daniel Vetter wrote: > > On Thu, Jan 31, 2019 at 12:29:18PM +0530, Ramalingam C wrote: > > From: Daniel Vetter > > > > Since we need multiple components for I915 for different purposes > > (Audio & Mei_hdcp), we adopt the subcomponents methodology introduced > > by the previous patch (mentioned below). > > > > Author: Daniel Vetter > > Date: Mon Jan 28 17:08:20 2019 +0530 > > > > components: multiple components for a device > > > > Signed-off-by: Daniel Vetter > > Signed-off-by: Ramalingam C > > cc: Greg Kroah-Hartman > > cc: Russell King > > cc: Rafael J. Wysocki > > cc: Jaroslav Kysela > > cc: Takashi Iwai > > cc: Rodrigo Vivi > > cc: Jani Nikula > > Takashi, can you pls take a look and ack for merging through drm-intel? We > can also do a topic branch in case this conflicts with something on the > audio side. I'm fine with the change as long as others agree with this API extension. Reviewed-by: Takashi Iwai thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Trim NEWCLIENT boosting
Limit the NEWCLIENT boost to only give its small priority boost to fresh
clients only that have no dependencies.
The idea for using NEWCLIENT boosting, commit b16c765122f9 ("drm/i915:
Priority boost for new clients"), is that short-lived streams are often
interactive and require lower latency -- and that by executing those
ahead of the long running hogs, the short-lived clients do little
interfere with the system throughput by virtue of their short-lived
nature. However, we were only considering the client's own timeline for
determining whether or not it was a fresh stream. This allowed for
compositors to wake up before their vblank and bump all of its client
streams. However in testing with media-bench this results in chaining
all cooperating contexts together preventing us from being able to
reorder contexts to reduce bubbles (pipeline stalls), overall increasing
latency, and reducing system throughput. The exact opposite of our
intent. The compromise of applying the NEWCLIENT boost to strictly fresh
clients (that do not wait upon anything else) should maintain the
real-time response under load characteristics of FQ_CODEL, without
locking together the long chains of dependencies across the system.
References: b16c765122f9 ("drm/i915: Priority boost for new clients")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d14a1b225f47..04c65e6d83b9 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -980,7 +980,7 @@ void i915_request_add(struct i915_request *request)
* Allow interactive/synchronous clients to jump ahead of
* the bulk clients. (FQ_CODEL)
*/
- if (!prev || i915_request_completed(prev))
+ if (list_empty(>sched.signalers_list))
attr.priority |= I915_PRIORITY_NEWCLIENT;
engine->schedule(request, );
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 02/40] i915/snd_hdac: I915 subcomponent for the snd_hdac
On Thu, Jan 31, 2019 at 12:29:18PM +0530, Ramalingam C wrote:
> From: Daniel Vetter
>
> Since we need multiple components for I915 for different purposes
> (Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
> by the previous patch (mentioned below).
>
> Author: Daniel Vetter
> Date: Mon Jan 28 17:08:20 2019 +0530
>
> components: multiple components for a device
>
> Signed-off-by: Daniel Vetter
> Signed-off-by: Ramalingam C
> cc: Greg Kroah-Hartman
> cc: Russell King
> cc: Rafael J. Wysocki
> cc: Jaroslav Kysela
> cc: Takashi Iwai
> cc: Rodrigo Vivi
> cc: Jani Nikula
Takashi, can you pls take a look and ack for merging through drm-intel? We
can also do a topic branch in case this conflicts with something on the
audio side.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_audio.c | 4 +++-
> include/drm/i915_component.h | 4
> include/sound/hda_component.h | 5 +++--
> sound/hda/hdac_component.c | 4 ++--
> sound/hda/hdac_i915.c | 6 --
> 5 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index de26cd0a5497..5104c6bbd66f 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -984,7 +984,9 @@ void i915_audio_component_init(struct drm_i915_private
> *dev_priv)
> {
> int ret;
>
> - ret = component_add(dev_priv->drm.dev, _audio_component_bind_ops);
> + ret = component_add_typed(dev_priv->drm.dev,
> + _audio_component_bind_ops,
> + I915_COMPONENT_AUDIO);
> if (ret < 0) {
> DRM_ERROR("failed to add audio component (%d)\n", ret);
> /* continue with reduced functionality */
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index fca22d463e1b..72fbb037f9b3 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -26,6 +26,10 @@
>
> #include "drm_audio_component.h"
>
> +enum i915_component_type {
> + I915_COMPONENT_AUDIO = 1,
> +};
> +
> /* MAX_PORT is the number of port
> * It must be sync with I915_MAX_PORTS defined i915_drv.h
> */
> diff --git a/include/sound/hda_component.h b/include/sound/hda_component.h
> index 2ec31b358950..d4804c72d959 100644
> --- a/include/sound/hda_component.h
> +++ b/include/sound/hda_component.h
> @@ -20,7 +20,7 @@ int snd_hdac_acomp_get_eld(struct hdac_device *codec,
> hda_nid_t nid, int dev_id,
> bool *audio_enabled, char *buffer, int max_bytes);
> int snd_hdac_acomp_init(struct hdac_bus *bus,
> const struct drm_audio_component_audio_ops *aops,
> - int (*match_master)(struct device *, void *),
> + int (*match_master)(struct device *, int, void *),
> size_t extra_size);
> int snd_hdac_acomp_exit(struct hdac_bus *bus);
> int snd_hdac_acomp_register_notifier(struct hdac_bus *bus,
> @@ -47,7 +47,8 @@ static inline int snd_hdac_acomp_get_eld(struct hdac_device
> *codec, hda_nid_t ni
> }
> static inline int snd_hdac_acomp_init(struct hdac_bus *bus,
> const struct
> drm_audio_component_audio_ops *aops,
> - int (*match_master)(struct device *, void
> *),
> + int (*match_master)(struct device *,
> + int, void *),
> size_t extra_size)
> {
> return -ENODEV;
> diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c
> index a6d37b9d6413..5c95933e739a 100644
> --- a/sound/hda/hdac_component.c
> +++ b/sound/hda/hdac_component.c
> @@ -269,7 +269,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_acomp_register_notifier);
> */
> int snd_hdac_acomp_init(struct hdac_bus *bus,
> const struct drm_audio_component_audio_ops *aops,
> - int (*match_master)(struct device *, void *),
> + int (*match_master)(struct device *, int, void *),
> size_t extra_size)
> {
> struct component_match *match = NULL;
> @@ -288,7 +288,7 @@ int snd_hdac_acomp_init(struct hdac_bus *bus,
> bus->audio_component = acomp;
> devres_add(dev, acomp);
>
> - component_match_add(dev, , match_master, bus);
> + component_match_add_typed(dev, , match_master, bus);
> ret = component_master_add_with_match(dev, _component_master_ops,
> match);
> if (ret < 0)
> diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> index 617ff1aa818f..7aee090e3d27 100644
> --- a/sound/hda/hdac_i915.c
> +++ b/sound/hda/hdac_i915.c
> @@ -82,9 +82,11 @@ void snd_hdac_i915_set_bclk(struct hdac_bus *bus)
> }
> EXPORT_SYMBOL_GPL(snd_hdac_i915_set_bclk);
>
> -static int
Re: [Intel-gfx] [PATCH v10 12/40] drm: HDCP2.2 link check period
On 2/4/2019 7:54 PM, Shankar, Uma wrote: -Original Message- From: C, Ramalingam Sent: Thursday, January 31, 2019 12:29 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar, Uma Cc: C, Ramalingam Subject: [PATCH v10 12/40] drm: HDCP2.2 link check period Time period for HDCP2.2 link check. Signed-off-by: Ramalingam C Reviewed-by: Daniel Vetter Not sure if we need a separate patch for this. Could be merged where check_link is introduced for hdcp2.2. If there is a valid reasoning, no hard objection and it looks ok in general. So drm level change is convenient to have in separate patch to get approval from dri-devel. --Ram 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_LEN 8 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/22] drm/i915/execlists: Suppress mere WAIT preemption
== Series Details ==
Series: series starting with [01/22] drm/i915/execlists: Suppress mere WAIT
preemption
URL : https://patchwork.freedesktop.org/series/56183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12126
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56183/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12126:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live_timelines}:
- fi-gdg-551: PASS -> DMESG-FAIL
Known issues
Here are the changes found in Patchwork_12126 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: NOTRUN -> FAIL [fdo#108800]
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL [fdo#108511]
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
Possible fixes
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-skl-guc: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109226]: https://bugs.freedesktop.org/show_bug.cgi?id=109226
[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]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (46 -> 42)
--
Additional (3): fi-icl-y fi-byt-j1900 fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-kbl-7560u fi-byt-clapper
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12126
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12126: 5d4fa784226829bb9a4e129d835c22c2c7176ee4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5d4fa7842268 semaphore-no-stats
842b32511f09 drm/i915: Prioritise non-busywait semaphore workloads
b08aeb9031a5 drm/i915: Use HW semaphores for inter-engine synchronisation on
gen8+
a68b8158d4d9 drm/i915/execlists: Refactor out can_merge_rq()
fca21928c6b9 drm/i915: Keep timeline HWSP allocated until idle across the system
7072ed37f6b4 drm/i915: Pull i915_gem_active into the i915_active family
74cb3e7eceba drm/i915: Add timeline barrier support
6e02a325bf2e drm/i915: Make request allocation caches global
6131355f9bde drm/i915: Allocate active tracking nodes from a slabcache
02cb9e1dad1c drm/i915: Release the active tracker tree upon idling
f524044f24ff drm/i915: Generalise GPU activity tracking
c2307ce3ed5b drm/i915: Don't claim an unstarted request was guilty
3f8a64bf2876 drm/i915: Serialise resets with wedging
2054755a2346
Re: [Intel-gfx] [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking
On 2/4/2019 7:39 PM, Shankar, Uma wrote:
-Original Message-
From: C, Ramalingam
Sent: Thursday, January 31, 2019 12:29 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
Uma
Cc: C, Ramalingam
Subject: [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW
encryption tracking
"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]
Signed-off-by: Ramalingam C
---
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 815ee68efa2f..9ce05819fc11 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4776,7 +4776,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 63e009286d5f..13a41e8cf4ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -399,6 +399,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;
@@ -2073,10 +2076,10 @@ int intel_hdcp_init(struct intel_connector
*connector,
bool hdcp2_supported);
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); bool
is_hdcp2_supported(struct drm_i915_private *dev_priv);
+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 e0bb5f32ba90..c1b057f1501b 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);
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: HDCP state handling in ddi_update_pipe
== Series Details ==
Series: drm/i915: HDCP state handling in ddi_update_pipe
URL : https://patchwork.freedesktop.org/series/56182/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5536 -> Patchwork_12125
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56182/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12125 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108529] / [fdo#108566]
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-skl-guc: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: FAIL [fdo#104008] -> 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#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[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]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (46 -> 45)
--
Additional (3): fi-icl-y fi-byt-j1900 fi-pnv-d510
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5536 -> Patchwork_12125
CI_DRM_5536: 0a5caf6e62fb99d027b3e6af226abb47be732f15 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4805: cb6610f5a91a08b1d7f8ae910875891003c6f67c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12125: 0a719b4f7a0dc40e8be1909dd933612db5076cc5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0a719b4f7a0d drm/i915: HDCP state handling in ddi_update_pipe
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12125/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 15/40] drm: removing the DP Errata msg and its msg id
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 15/40] drm: removing the DP Errata msg and its msg id
>
>Since DP ERRATA message is not defined at spec, those structure definition is
>removed from drm_hdcp.h
I believe we still want to have it but inside the driver isn't it ?, would be
good to
add a comment on that.
With that fixed.
Reviewed-by: Uma Shankar
>
>Signed-off-by: Ramalingam C
>Suggested-by: Daniel Vetter
>---
> 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_MANAGE16
> #define HDCP_2_2_REP_STREAM_READY 17
>-#define HDCP_2_2_ERRATA_DP_STREAM_TYPE50
>
> #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
Re: [Intel-gfx] [PATCH v10 14/40] drm/i915: Handle HDCP2.2 downstream topology change
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:30 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 14/40] drm/i915: Handle HDCP2.2 downstream topology
>change
>
>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
The latest version is ok. You can keep the RB.
>---
> 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 3feff921a547..7ff29fb0aa2f 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -1617,8 +1617,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
Re: [Intel-gfx] [PATCH v10 13/40] drm/i915: Implement HDCP2.2 link integrity check
>-Original Message-
>From: C, Ramalingam
>Sent: Thursday, January 31, 2019 12:29 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
>Uma
>Cc: C, Ramalingam
>Subject: [PATCH v10 13/40] drm/i915: Implement HDCP2.2 link integrity check
>
>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
The latest version also looks ok. You can keep my RB.
>---
> 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 e6792304520a..747fe7361287 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -314,6 +314,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
>@@ -409,6 +416,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 3b8d3a4b5e6e..3feff921a547 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -102,6 +102,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) { @@ -
>1571,6 +1581,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);
>+ }
>+
Re: [Intel-gfx] [PATCH v10 12/40] drm: HDCP2.2 link check period
>-Original Message- >From: C, Ramalingam >Sent: Thursday, January 31, 2019 12:29 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar, >Uma >Cc: C, Ramalingam >Subject: [PATCH v10 12/40] drm: HDCP2.2 link check period > >Time period for HDCP2.2 link check. > >Signed-off-by: Ramalingam C >Reviewed-by: Daniel Vetter Not sure if we need a separate patch for this. Could be merged where check_link is introduced for hdcp2.2. If there is a valid reasoning, no hard objection and it looks ok in general. So 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_LEN 8 >-- >2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
