[Bug 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.

https://bugs.freedesktop.org/show_bug.cgi?id=104854 José Pekkarinen changed: What|Removed |Added Attachment #137911|0 |1 is

Re: [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

On Thu, Mar 08, 2018 at 06:41:22PM -0500, Lyude Paul wrote: > While having the modeset_retry_work in intel_connector makes sense with > SST, this paradigm doesn't make a whole ton of sense when it comes to > MST since we have to deal with multiple connectors. In most cases, it's > more useful to

Re: [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

On Thu, Mar 08, 2018 at 06:24:15PM -0500, Lyude Paul wrote: > Signed-off-by: Lyude Paul > Cc: Manasi Navare > Cc: Ville Syrjälä Reviewed-by: Manasi Navare > --- >

[git pull] drm fixes for 4.16-rc5

Hi Linus, There are a small set of sun4i and i915 fixes: sun4i: divide by zero, clock and LVDS fixes i915: 1 fix for perf and a 1 race fix However amdgpu is a bit more than we are normally comfortable with at this point, however it does fix a lot of display issues with the new DC code which

[PATCH v7 5/9] drm: Handle aspect-ratio info in getblob

From: Ankit Nautiyal If the user-space does not support aspect-ratio, then getblob called with the blob id of a user-mode, should clear the aspect-ratio information in the blob data. Currently for a given blob id, there is no way to determine if the blob stores

linux-next: Signed-off-by missing for commit in the drm tree

Hi all, Commit 37a94791a097 ("drm/amd/pp: Add #ifdef checks for CONFIG_ACPI") is missing a Signed-off-by from its committer. -- Cheers, Stephen Rothwell pgpu1EfZWi3LI.pgp Description: OpenPGP digital signature ___ dri-devel mailing list

Re: [DPU PATCH 10/11] drm/msm: Switch to atomic_helper_commit()

On 2018-02-28 11:19, Sean Paul wrote: Now that all of the msm-specific goo is tucked safely away we can switch over to using the atomic helper commit directly. \o/ [Abhinav] Can we say something like "Move remaining msm-specific operations to private handles and switch to atomic helper commit

Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

Hi Sylwester, 2018년 03월 08일 20:22에 Sylwester Nawrocki 이(가) 쓴 글: > Hi Inki, > > Cc: alsa-de...@alsa-project.org > > On 03/08/2018 09:15 AM, Inki Dae wrote: >> By the way, it seems 'sound-dai-cells' property never affect >> Exynos4210/4212> 5420/5433. It seems that even through ALSA TM2 audio

Re: [DPU PATCH 07/11] drm/msm: Use atomic private_obj instead of subclassing

On 2018-02-28 11:19, Sean Paul wrote: Instead of subclassing atomic state, store driver private data in private_obj/state. This allows us to remove the swap_state driver hook for mdp5 and get closer to using the atomic helpers entirely. Change-Id: I65a4a2887593ae257d584e00b352b5daf00e4e61

Re: [DPU PATCH 09/11] drm/msm: Remove prepare_fence kms_function

On 2018-02-28 11:19, Sean Paul wrote: This is the last piece that is keeping us from matching the atomic helper commit function. By removing this (now unused) hook, we can switch to drm_atomic_helper_commit() Change-Id: I081056a6e1689807871f5deedc76499bb91b6969 Signed-off-by: Sean Paul

Re: [DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit

On 2018-03-02 06:56, Sean Paul wrote: On Thu, Mar 01, 2018 at 07:37:10PM -0500, Rob Clark wrote: On Thu, Mar 1, 2018 at 3:37 PM, wrote: > On 2018-03-01 07:27, Sean Paul wrote: >> >> On Wed, Feb 28, 2018 at 08:07:00PM -0800, jsa...@codeaurora.org wrote: >>> >>> On

Re: [DPU PATCH 03/11] drm/msm: Refactor complete_commit() to look more the helpers

On 2018-02-28 11:18, Sean Paul wrote: Factor out the commit_tail() portions of complete_commit() into a separate function to facilitate moving to the atomic helpers in future patches. Change-Id: I4b858ad9fe356b31ed0ed9eecdb394a61048e39c Signed-off-by: Sean Paul

Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper

On 2018-02-28 11:18, Sean Paul wrote: Instead, shuffle things around so we kickoff crtc after enabling encoder during modesets. Also moves the vblank wait to after the frame. Change-Id: I16c7b7f9390d04f6050aa20e17a5335fbf49eba3 Signed-off-by: Sean Paul ---

[PATCH v2 3/4] drm/vc4: Move plane state to header

We need to reference it from the CRTC to make a decision for enabling background color fill. Signed-off-by: Stefan Schake --- drivers/gpu/drm/vc4/vc4_drv.h | 60 + drivers/gpu/drm/vc4/vc4_plane.c | 60

[PATCH v2 4/4] drm/vc4: Enable background color fill when necessary

Using the hint from the plane state, we turn on the background color to avoid display corruption from planes blending with the background. Changes from v1: - Use needs_bg_fill from plane state Signed-off-by: Stefan Schake --- drivers/gpu/drm/vc4/vc4_crtc.c | 25

[PATCH v2 1/4] drm/vc4: Set premultiplied for alpha formats

Alpha formats in DRM are assumed to be premultiplied, so we should be setting the PREMULT bit in the plane configuration for HVS. Changes from v1: - Use correct has_alpha Signed-off-by: Stefan Schake --- drivers/gpu/drm/vc4/vc4_plane.c | 3 ++-

[PATCH v2 2/4] drm/vc4: Check if plane requires background fill

Considering a single plane only, we have to enable background color when the plane has an alpha format and could be blending from the background or when it doesn't cover the entire screen. Changes from v1: - Drop unrelated change - Move needs_bg_fill to plane state Signed-off-by: Stefan Schake

[PATCH v2 0/4] drm/vc4: Improve alpha format plane support

This series improves the handling of alpha formats with the VC4 HVS compositor. Alpha formats are marked as premultiplied as is standard for DRM. Further fix a display corruption issue when planes with per-pixel alpha try blending from the (nonexistent) background by selectively enabling a black

[PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[PATCH 6/6] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[PATCH 4/6] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[PATCH 0/6] Implement proper MST fallback retraining in i915

This is the first version of my patch series to implement MST fallback retraining in i915, along with improving the stability of i915's mst retraining in general. Additionally, it also introduces helpers into DRM to help with correctly handling MST fallback retraining so that other drivers may

[PATCH 2/6] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c

[PATCH 3/6] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

[PATCH 5/6] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()

Retraining MST is rather difficult. In order to do it properly while guaranteeing that we'll never run into a spot where we commit a physically impossible configuration, we have to do a lot of checks on atomic commits which affect MST topologies. All of this work is going to need to be repeated

Re: [PATCH v4 03/38] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

Hi Enric, Am Montag, 5. März 2018, 23:22:55 CET schrieb Enric Balletbo i Serra: > From: Yakir Yang > > Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() > function, or print the sink PSR error state if we failed to apply the > requested PSR setting.

Re: [PATCH v4 02/38] drm/rockchip: Don't use atomic constructs for psr

Am Montag, 5. März 2018, 23:22:54 CET schrieb Enric Balletbo i Serra: > From: Sean Paul > > Instead of using timer and spinlocks, use delayed_work and > mutexes for rockchip psr. This allows us to make blocking > calls when enabling/disabling psr (which is sort of

Re: [PATCH v4 01/38] drm/bridge: analogix_dp: set psr activate/deactivate when enable/disable bridge

Am Montag, 5. März 2018, 23:22:53 CET schrieb Enric Balletbo i Serra: > From: zain wang > > There's a race between when bridge_disable and when vop_crtc_disable > are called. If the flush timer triggers a new psr work between these, > we will operate eDP without power

Re: [RFC][PATCH 2/2 v4] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

On Thu, Mar 8, 2018 at 3:16 AM, Robert Foss wrote: > Hey John, > > This patch looks good to me. > > I have yet to build it, and I haven't brought my HiKey960 up for testing > quite yet. > > > On 03/07/2018 12:19 AM, John Stultz wrote: >> >> This allows for importing

[Bug 93727] [Regression] [r600g] Core profile is 3.2 instead of 3.3 in Big Endian PPC

https://bugs.freedesktop.org/show_bug.cgi?id=93727 --- Comment #5 from erhar...@mailbox.org --- Still core profile 3.2 on r600g, Mesa 18.0.0-rc4 $ glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: AMD CAICOS (DRM 2.49.0 / 4.9.85-gentoo) OpenGL core profile version

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

https://bugs.freedesktop.org/show_bug.cgi?id=105401 Timothy Pearson changed: What|Removed |Added Status|NEW

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

https://bugs.freedesktop.org/show_bug.cgi?id=105401 --- Comment #3 from Andrey Grodzovsky --- Please check your libdrm and verify it's version is 2.4.91 https://lists.freedesktop.org/archives/dri-devel/2018-March/168156.html I believe it should be fixed by amdgpu:

Re: [patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue

On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula wrote: > On Wed, 07 Mar 2018, a...@linux-foundation.org wrote: > > From: Andrew Morton > > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union > > initializer issue >

[Bug 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.

https://bugs.freedesktop.org/show_bug.cgi?id=104854 --- Comment #3 from Alex Deucher --- What kernel are you using? I don't see any way the fw loading type could not be set correctly for any chip unless a module parameter was provided. Please attach your full dmesg

[Bug 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.

https://bugs.freedesktop.org/show_bug.cgi?id=104854 --- Comment #2 from José Pekkarinen --- Created attachment 137911 --> https://bugs.freedesktop.org/attachment.cgi?id=137911=edit Initialization output on SMU firmware load. Seems that autodetection of firmware method to

Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU

On Wed, Mar 07, 2018 at 10:36:24AM +0530, Viresh Kumar wrote: > On 06-03-18, 08:37, Jordan Crouse wrote: > > I'll try to explain but I might need Stephen or some of the other folks to > > jump > > in and save me. > > Maybe you should start using his kernel.org address then ? :) > > > On sdm845

[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume

https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #7 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to Alex Deucher from comment #6) > Created attachment 274621 [details] > possible fix > > Does this fix it? Yes, fixed with this patch. -- You are receiving this

[PATCH] drm/meson: Add support for DMT modes on HDMI

This patch adds support for DMT display modes over HDMI. The modes timings configurations are from the Amlogic Vendor linux tree and tested over multiples monitors. Previously only a selected number of CEA modes were supported. Only these following modes are supported with these changes: -

Re: [RFC][PATCH 1/2] drm_hwcomposer: Error out on YUV layer as it would fail for single planes

On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote: > Hey John, > > > On 03/07/2018 12:19 AM, John Stultz wrote: >> >> As suggested by Alexandru-Cosmin Gheorghe: >> >> ConvertHALFormatToDrm logic would work only for 1 plane formats, >> and probably gets rejected by

Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

On Thu, Mar 08, 2018 at 06:55:34PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 18:48:51) > > Quoting Matt Roper (2018-03-08 18:22:06) > > > * Option 2: Allow priority offset to be set in a much larger range > > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

https://bugs.freedesktop.org/show_bug.cgi?id=105401 Alex Deucher changed: What|Removed |Added Product|DRI |Mesa

[Bug 105273] [r350] missing background, transparency not working & other glitches in ETR (AGP, ppc, mesa-18.0.0_rc4)

https://bugs.freedesktop.org/show_bug.cgi?id=105273 --- Comment #6 from erhar...@mailbox.org --- Tried a Radeon HD 6450 on my PCIe PowerMac G5 11,2 for another comparison. Graphics are rendered correctly! So it seems this bug is a specific r300 driver problem, not a generic Big Endian problem. $

Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

Quoting Chris Wilson (2018-03-08 18:48:51) > Quoting Matt Roper (2018-03-08 18:22:06) > > * Option 2: Allow priority offset to be set in a much larger range > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have > >effective priority ranges that don't overlap. cgroup

[Bug 99859] Glamor Crashes on big endian Hardware

https://bugs.freedesktop.org/show_bug.cgi?id=99859 --- Comment #23 from erhar...@mailbox.org --- Tried Glamor on a more recent xorg stack on my PM G5 11,2 which works perfectly well! It's on a Radeon HD 6450 however, so a r600 card and not a radeonsi as the HD 7750. I am running:

Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

Quoting Matt Roper (2018-03-08 18:22:06) > On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-08 11:32:04) > > > Quoting Matt Roper (2018-03-06 23:46:59) > > > > There are cases where a system integrator may wish to raise/lower the > > > > priority of

[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"

https://bugs.freedesktop.org/show_bug.cgi?id=105308 --- Comment #12 from Michel Dänzer --- This might work better if you enable DC with amdgpu.dc=1 on the kernel command line. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 11:32:04) > > Quoting Matt Roper (2018-03-06 23:46:59) > > > There are cases where a system integrator may wish to raise/lower the > > > priority of GPU workloads being submitted by specific OS

Re: [PATCH libdrm] freedreno: add missing symbols to symbol-check

On 7 March 2018 at 08:48, Christian Gmeiner wrote: > 2018-03-06 16:37 GMT+01:00 Eric Engestrom : >> Fixes: 1384c081233751569473 "freedreno: add interface to get buffer address" >> Signed-off-by: Eric Engestrom > >

Re: [PATCH libdrm] meson: use pkg-config to detect libatomic_ops

On 5 March 2018 at 12:03, Eric Engestrom wrote: > Ping? :) > Both for this patch and the equivalent autotools patch it replies to. > The autotools one needs the CFLAGS added - meson does it automatically for us. > On Wednesday, 2018-02-07 14:24:33 +, Eric Engestrom

Re: [PATCH] configure/Makefile.am: use pkg-config to discover libatomic_ops

On 6 February 2018 at 21:19, Peter Seiderer wrote: > From: Thomas Petazzoni > > The configure script currently tests the availability of libatomic_ops > by checking the presence of atomic_ops.h. While this is good enough as > an

Re: nouveau 30bpp / deep color status

Hi, On 8 March 2018 at 17:08, Ilia Mirkin wrote: > On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner > wrote: >> Under EGL there is matching of channel masks, so only X11+GLX is >> problematic. Not sure if anything special would need to be done for

Re: [RFC v3 09/12] drm: Add API for in-kernel clients

Den 06.03.2018 09.56, skrev Daniel Vetter: On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Trønnes wrote: This adds an API for writing in-kernel clients. TODO: - Flesh out and complete documentation. - Cloned displays is not tested. - Complete tiled display support and test it. - Test

Re: nouveau 30bpp / deep color status

On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner wrote: > Cc'ing mesa-dev, which was left out. > > > On 03/05/2018 01:40 PM, Ilia Mirkin wrote: >> >> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner >> wrote: >>> Afaics EGL does the right thing

Re: nouveau 30bpp / deep color status

Cc'ing mesa-dev, which was left out. On 03/05/2018 01:40 PM, Ilia Mirkin wrote: On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner wrote: On 02/05/2018 12:50 AM, Ilia Mirkin wrote: In case anyone's curious about 30bpp framebuffer support, here's the current status:

Re: [PATCH v9 4/5] drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind()

Am Freitag, 2. März 2018, 18:57:56 CET schrieb Enric Balletbo i Serra: > From: Jeffy Chen > > The HDMI vpll clock should be enabled when bind() is called. So move the > clk_prepare_enable of that clock to bind() function and add the missing > clk_disable_unprepare()

Re: [PATCH v9 3/5] drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind

Am Freitag, 2. März 2018, 18:57:55 CET schrieb Enric Balletbo i Serra: > From: Jeffy Chen > > In bind the clk_prepare_enable of the HDMI pclk is called before adding the > i2c_adapter. So it should be the other way around in unbind, first remove > the i2c_adapter and

Re: [PATCH v9 1/5] drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup.

Am Freitag, 2. März 2018, 18:57:53 CET schrieb Enric Balletbo i Serra: > From: Jeffy Chen > > In bind()'s error handling path call destroy functions instead of > cleanup functions for encoder and connector and reorder to match how is > called in bind(). > > In

Re: [PATCH v9 2/5] drm/rockchip: inno_hdmi: Fix error handling path.

Am Freitag, 2. März 2018, 18:57:54 CET schrieb Enric Balletbo i Serra: > From: Jeffy Chen > > Add missing error handling in bind(). > > Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support") > Signed-off-by: Jeffy Chen >

Re: [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

On Tue, Feb 27, 2018 at 10:49:39AM +0200, Ville Syrjälä wrote: > On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote: > > On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin wrote: > > > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > > >

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

https://bugs.freedesktop.org/show_bug.cgi?id=105401 Timothy Pearson changed: What|Removed |Added Hardware|Other

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

https://bugs.freedesktop.org/show_bug.cgi?id=105401 --- Comment #2 from Timothy Pearson --- Created attachment 137901 --> https://bugs.freedesktop.org/attachment.cgi?id=137901=edit Xorg.0.log after load attempt -- You are receiving this mail because: You are

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

https://bugs.freedesktop.org/show_bug.cgi?id=105401 --- Comment #1 from Timothy Pearson --- Created attachment 137900 --> https://bugs.freedesktop.org/attachment.cgi?id=137900=edit dmesg after xorg load attempt -- You are receiving this mail because: You are

[Bug 105401] Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed

https://bugs.freedesktop.org/show_bug.cgi?id=105401 Bug ID: 105401 Summary: Unable to start X on Vega AMDGPU(0): amdgpu_setup_kernel_mem failed Product: DRI Version: XOrg git Hardware: Other OS: All

[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume

https://bugzilla.kernel.org/show_bug.cgi?id=199047 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 274621 --> https://bugzilla.kernel.org/attachment.cgi?id=274621=edit possible fix Does this fix it? -- You are receiving this mail because: You are watching the

[Bug 103953] [DC] Polaris10: Missing modes when enabling DC

https://bugs.freedesktop.org/show_bug.cgi?id=103953 --- Comment #12 from Alex Deucher --- (In reply to Aleksei from comment #11) > I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is > that fixed too? > > Monitor 1920x1080 144Hz, GPU RX 560,

RE: [PATCH v2 10/42] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

> > Request ME FW to start the HDCP2.2 session for a intel port. > Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent > 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. > >

RE: [PATCH v2 09/42] linux/mei: Header for mei_hdcp driver interface

> Data structures and Enum for the I915-MEI_HDCP interface are defined at > > > v2: > Rebased. > > Signed-off-by: Ramalingam C > --- > include/linux/mei_hdcp.h | 71 > > 1 file changed, 71 insertions(+) > > diff --git

Re: [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

Quoting Chris Wilson (2018-03-08 11:32:04) > Quoting Matt Roper (2018-03-06 23:46:59) > > There are cases where a system integrator may wish to raise/lower the > > priority of GPU workloads being submitted by specific OS process(es), > > independently of how the software self-classifies its own

RE: [PATCH v2 07/42] misc/mei/hdcp: Get & Put for mei cl_device

> Interfaces to obtain and release the cl_device reference is developed. > Using these interfaces intel hdcp driver will get the reference to the mei > client devices, so that hdcp2.2 service calls can be routed to that client > device. > > During registration, call back function will be

RE: [PATCH v2 04/42] misc/mei/hdcp: Client driver for HDCP application

> Subject: [PATCH v2 04/42] misc/mei/hdcp: Client driver for HDCP application I prefer this will be squashed together with [PATCH v2 05/42] misc/mei/hdcp: Add KBuild for mei hdcp driver so it can be compiled. > > ME FW is contributes a vital role in HDCP2.2 authentication. > HDCP2.2 driver

RE: [PATCH v2 06/42] misc/mei/hdcp: Verify mei client device status

> > v2: > Rebased. > > Signed-off-by: Ramalingam C > --- > drivers/misc/mei/hdcp/mei_hdcp.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c > b/drivers/misc/mei/hdcp/mei_hdcp.c > index aa211763e520..25df7034cfb4

[Bug 103953] [DC] Polaris10: Missing modes when enabling DC

https://bugs.freedesktop.org/show_bug.cgi?id=103953 --- Comment #11 from Aleksei --- I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is that fixed too? Monitor 1920x1080 144Hz, GPU RX 560, connection over DVI-D. With dc=0 I can set 1920x1080 144Hz, with

Re: [PATCH v2 00/42] drm/i915: Implement HDCP2.2

On Thursday 08 March 2018 06:00 PM, Winkler, Tomas wrote: -Original Message- From: C, Ramalingam Sent: Thursday, March 08, 2018 13:58 To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas

RE: [PATCH v2 00/42] drm/i915: Implement HDCP2.2

> -Original Message- > From: C, Ramalingam > Sent: Thursday, March 08, 2018 13:58 > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas > ; jani.nik...@linux.intel.com > Cc: Vivi,

[PATCH v2 42/42] 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. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdmi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH v2 40/42] drm/i915: Implement the HDCP2.2 support for HDMI

Implements the HDMI adapatation specific HDCP2.2 operations. Basically these are DDC read and write for authenticating through HDCP2.2 messages. v2: Rebased. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdmi.c | 203

[PATCH v2 41/42] 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. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_dp.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 1 +

[PATCH v2 39/42] 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. Note: Chris Wilson suggested alternate method for waiting for CP_IRQ, than completions concept. WIP to understand and implement

[PATCH v2 35/42] drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure

When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is enabled. v2: Rebased. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdcp.c

[PATCH v2 38/42] drm/i915: Implement gmbus burst read

Implements a interface for single burst read of data that is larger than 512 Bytes through gmbus. HDCP2.2 spec expects HDCP2.2 transmitter to read 522Bytes of HDCP receiver certificates in single burst read. On gmbus, to read more than 511Bytes, HW provides a workaround for burst read. This

[PATCH v2 36/42] drm/i915: hdcp_check_link only on CP_IRQ

HDCP check link is invoked only on CP_IRQ detection, instead of all short pulses. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_dp.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c

[PATCH v2 37/42] drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ

On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link integrity check for the HDCP version that is enabled. v2: Rebased. Function name is changed. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_dp.c | 2 +- drivers/gpu/drm/i915/intel_drv.h |

[PATCH v2 33/42] drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable

As a preparation for making the intel_hdcp_enable as common function for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved into _intel_hdcp_enable() function. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 11 +++ 1 file

[PATCH v2 34/42] drm/i915: Enable superior HDCP ver that is capable

Considering that HDCP2.2 is more secure than HDCP1.4, When a setup supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled. v2: Included few optimization suggestions [Chris Wilson] Commit message is updated as per the rebased version. Signed-off-by: Ramalingam C ---

[PATCH v2 30/42] drm/i915: Handle HDCP2.2 downstream topology change

When repeater notifies a downstream topology change, this patch reauthenticate the repeater alone with out disabling the hdcp encryption. If that fails then complete reauthentication is executed. v2: Rebased. Signed-off-by: Ramalingam C ---

[PATCH v2 29/42] 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

[PATCH v2 32/42] drm/i915: Initialize HDCP2.2 and its MEI interface

Initialize HDCP2.2 support. This includes the mei interface initialization also. v2: mei interface handle is protected with mutex. [Chris Wilson] Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 7 +++

[PATCH v2 31/42] drm/i915: Pullout the bksv read and validation

For reusability purpose, this patch implements the hdcp1.4 bksv's read and validation as a functions. For detecting the HDMI panel's HDCP capability this fucntions will be used. v2: Rebased. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 38

[PATCH v2 27/42] drm/i915: Enable and Disable HDCP2.2 port encryption

Implements the enable and disable functions for HDCP2.2 encryption of the PORT. v2: intel_wait_for_register is used instead of wait_for. [Chris Wilson] Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 54 +++ 1

[PATCH v2 28/42] drm/i915: Implement HDCP2.2 En/Dis-able

Implements a sequence of enabling and disabling the HDCP2.2 (auth and encryption). v2: Rebased. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 75 +++ 1 file changed, 75 insertions(+) diff --git

[PATCH v2 26/42] drm/i915: Implement HDCP2.2 repeater authentication

Implements the HDCP2.2 repeaters authentication steps such as verifying the downstream topology and sending stream management information. v2: Rebased. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 135 ++ 1

[PATCH v2 25/42] drm/i915: Implement HDCP2.2 receiver authentication

Implements HDCP2.2 authentication for hdcp2.2 receivers, with following steps: Authentication and Key enchange (AKE). Locality Check (LC). Session Key Exchange(SKE). DP Errata for stream type confuguration for receivers. At AKE, the HDCP Receiver’s public key

[PATCH v2 21/42] drm/i915: wrapping all hdcp var into intel_hdcp

Considering the upcoming significant no HDCP2.2 variables, it will be clean to have separate struct fo HDCP. New structure called intel_hdcp is introduced. v2: struct hdcp statically allocated. [Sean Paul] enable and disable function parameters are retained.[Sean Paul] Signed-off-by:

[PATCH v2 24/42] drm/i915: Wrappers for mei HDCP2.2 services

Adds the wrapper for all mei hdcp2.2 service functions. v2: Rebased. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 194 ++ 1 file changed, 194 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdcp.c

[PATCH v2 23/42] drm/i915: Define Intel HDCP2.2 registers

Intel HDCP2.2 registers are defined with addr offsets and bit details. v2: Replaced the arith calc with _PICK [Sean Paul] Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/i915_reg.h | 32 1 file changed, 32 insertions(+) diff

[PATCH v2 20/42] 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. Signed-off-by: Ramalingam C ---

[PATCH v2 22/42] drm/i915: Define HDCP2.2 related variables

For upcoming implementation of HDCP2.2 in I915, important variable required for HDCP2.2 are defined. HDCP_shim is extended to support encoder specific HDCP2.2 flows. v2: 1.4 shim is extended to support hdcp2.2. [Sean Paul] platform's/panel's hdcp ver capability is removed. [Sean Paul] mei

[PATCH v2 19/42] misc/mei/hdcp: Enabling the HDCP authentication

Request to ME to configure a port as authenticated. On Success, ME FW will mark th eport as authenticated and provides HDCP chiper of the port with the encryption keys. Enabling the Authentication can be requested once the all stages of HDCP2.2 authentication is completed by interating with ME

[PATCH v2 18/42] 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

  1   2   >