[Bug 199781] nouveau: cannot boot without nouveau.modeset=0 and cannot use HDMI output

https://bugzilla.kernel.org/show_bug.cgi?id=199781 Karol Herbst (karolher...@gmail.com) changed: What|Removed |Added CC|

[PATCH v4 17/41] 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

[PATCH v4 23/41] drm/i915: Implement HDCP2.2 receiver authentication

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

[PATCH v4 22/41] drm/i915: Wrappers for mei HDCP2.2 services

Adds the wrapper for all mei hdcp2.2 service functions. v2: Rebased. v3: cldev is moved from mei_hdcp_data to hdcp. v4: %s/hdcp2_store_paring_info/hdcp2_store_pairing_info Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 194

[PATCH v4 16/41] 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

[PATCH v4 12/41] 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

[Bug 106499] [regression, bisected] Several games crash on start

https://bugs.freedesktop.org/show_bug.cgi?id=106499 --- Comment #3 from Bas Nieuwenhuizen --- This should be fixed with https://patchwork.freedesktop.org/patch/224584/ -- You are receiving this mail because: You are the assignee for the

[Bug 104920] Broken hardware video encoding with vaapi/ffmpeg

https://bugs.freedesktop.org/show_bug.cgi?id=104920 --- Comment #7 from gr...@sub.red --- NOTABUG? IMHO, it's a documentation issue, *at least*. Please add the info to https://wiki.freedesktop.org/xorg/RadeonFeature/ or somewhere else. Also, why is it possible to use radeonsi/vaapi for encoding

Re: [PATCH RFC 04/24] arm64/dts: add switch-delay for meson mali

Hi Yuq, On 18/05/2018 11:27, Qiang Yu wrote: > From: Andrei Paulau <7134...@gmail.com> > > Meson mali GPU operate in high clock frequency, need > this value be high to work in a stable state. > > Signed-off-by: Andrei Paulau <7134...@gmail.com> > --- >

Re: [PATCH RFC 03/24] arm64/dts: add switch-delay for meson mali

Hi Yuq, On 18/05/2018 11:27, Qiang Yu wrote: > Meson mali GPU operate in high clock frequency, need > this value be high to work in a stable state. > > Signed-off-by: Qiang Yu > --- > arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi | 1 + > 1 file changed, 1 insertion(+) > >

[PATCH v4 1/5] media: cec-notifier: Get notifier by device and connector name

In non device-tree world, we can need to get the notifier by the driver name directly and eventually defer probe if not yet created. This patch adds a variant of the get function by using the device name instead and will not create a notifier if not yet created. But the i915 driver exposes at

[PATCH v4 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device when the CEC feature bit is present. Signed-off-by: Neil Armstrong Reviewed-by: Enric Balletbo i Serra --- drivers/mfd/cros_ec_dev.c | 16 1 file

[PATCH v4 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

The EC can expose a CEC bus, this patch adds the CEC related definitions needed by the cros-ec-cec driver. Having a 16 byte mkbp event size makes it possible to send CEC messages from the EC to the AP directly inside the mkbp event instead of first doing a notification and then a read.

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

On Mon, May 21, 2018 at 01:17:04AM +0800, Randy Li wrote: > This pixel format is a fully packed and 10bits variant of NV12. > A luma pixel would take 10bits in memory, without any > filled bits between pixels in a stride. The color gamut > follows the BT.2020 standard. > > Signed-off-by: Randy Li

[PATCH] drm/gma500: Fix Medfield for drm_framebuffer move

bc61c97502e2 moved the gtt_range structure, from being in psb_framebuffer and embedding the GEM object, to being placed in the drm_framebuffer with the gtt_range being derived from the GEM object. The conversion missed out the Medfield subdriver, which was not being built in the default drm-misc

[Bug 106594] [radeonsi,regression,apitrace] Prison Architect exhibits glitches

https://bugs.freedesktop.org/show_bug.cgi?id=106594 Bug ID: 106594 Summary: [radeonsi,regression,apitrace] Prison Architect exhibits glitches Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux

[Bug 106594] [radeonsi,regression,apitrace] Prison Architect exhibits glitches

https://bugs.freedesktop.org/show_bug.cgi?id=106594 --- Comment #1 from Kai --- Created attachment 139661 --> https://bugs.freedesktop.org/attachment.cgi?id=139661=edit Glitch while placing new staff on the map -- You are receiving this mail because: You are the

[Bug 106594] [radeonsi,regression,apitrace] Prison Architect exhibits glitches

https://bugs.freedesktop.org/show_bug.cgi?id=106594 --- Comment #2 from Kai --- Created attachment 139662 --> https://bugs.freedesktop.org/attachment.cgi?id=139662=edit Game output to STDOUT and STDERR -- You are receiving this mail because: You are the assignee

Re: [PATCH v6 4/5] phy: rockchip-typec: support variable phy config value

Hi Lin, 2018-05-21 11:37 GMT+02:00 Lin Huang : > the phy config values used to fix in dp firmware, but some boards > need change these values to do training and get the better eye diagram > result. So support that in phy driver. > > Signed-off-by: Chris Zhong

Re: [PATCH v6 5/5] drm/rockchip: support dp training outside dp firmware

Hi Lin, 2018-05-21 11:37 GMT+02:00 Lin Huang : > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead of

[PATCH v4 5/5] media: platform: Add ChromeOS EC CEC driver

The ChromeOS Embedded Controller can expose a CEC bus, this patch add the driver for such feature of the Embedded Controller. This driver is part of the cros-ec MFD and will be add as a sub-device when the feature bit is exposed by the EC. The controller will only handle a single logical address

[PATCH v4 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

This patchs adds the cec_notifier feature to the intel_hdmi part of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate between each HDMI ports. The changes will allow the i915 HDMI code to notify EDID and HPD changes to an eventual CEC adapter. Signed-off-by: Neil Armstrong

[PATCH v4 0/5] Add ChromeOS EC CEC Support

Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support through it's Embedded Controller, to enable the Linux CEC Core to communicate with it and get the CEC Physical Address from the correct HDMI Connector, the following must be added/changed: - Add the CEC sub-device

Re: [PATCH v2 0/5] Add ChromeOS EC CEC Support

On 18/05/2018 16:04, Enric Balletbo Serra wrote: > Hi Neil, > > 2018-05-18 15:04 GMT+02:00 Neil Armstrong : >> Hi All, >> >> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >> through it's Embedded Controller, to enable the Linux CEC Core to

[PATCH v4 36/41] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of enabling the 511Bytes per RD/WR cycle on legacy platforms for no absolute ROIs, this change allows the max bytes per op upto 511Bytes from Gen9 onwards. v2: No Change. v3: Inline function for max_xfer_size and renaming of

[Bug 199781] nouveau: cannot boot without nouveau.modeset=0 and cannot use HDMI output

https://bugzilla.kernel.org/show_bug.cgi?id=199781 --- Comment #2 from Frédéric Pierret (frederic.epi...@orange.fr) --- Created attachment 276085 --> https://bugzilla.kernel.org/attachment.cgi?id=276085=edit dmesg log with nouveau.runpm=0 dmesg log with nouveau.runpm=0 -- You are receiving

[PATCH v4 35/41] 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. v3: No Changes. v4: No Changes. Signed-off-by: Ramalingam C cc: Sean Paul ---

[PATCH v4 40/41] 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: No Changes. v4: Collected the reviewed-by received. Signed-off-by: Ramalingam C Reviewed-by: Uma Shankar ---

[PATCH v4 39/41] 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 Changes. v4: No more special handling of Gmbus burst read for AKE_SEND_CERT. Style fixed with few naming. [Uma]

[PATCH v4 38/41] 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 v4 37/41] drm/i915/gmbus: Enable burst read

Support for Burst read in HW is added for HDCP2.2 compliance requirement. This patch enables the burst read for all the gmbus read of more than 511Bytes, on capable platforms. v2: Extra line is removed. v3: Macro is added for detecting the BURST_READ Support [Jani] Runtime detection of the

[PATCH v4 32/41] 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. v3: No changes. v4: Extra comment added and Style issue

[PATCH v4 34/41] drm/i915: hdcp_check_link only on CP_IRQ

HDCP check link is invoked only on CP_IRQ detection, instead of all short pulses. v3: No Changes. v4: Added sean in cc and collected the reviewed-by received. Signed-off-by: Ramalingam C cc: Sean Paul Reviewed-by: Uma Shankar

Re: [Intel-gfx] [PATCH v3 39/40] drm/i915: Add HDCP2.2 support for DP connectors

On Friday 18 May 2018 10:07 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;

Re: [PATCH v4 2/2] drm/panel: Add device_link from panel device to drm device

On 21.05.2018 10:53, Peter Rosin wrote: > On 2018-05-21 10:15, Andrzej Hajda wrote: >> On 19.05.2018 18:48, Peter Rosin wrote: >>> On 2018-05-18 13:51, Andrzej Hajda wrote: On 26.04.2018 10:07, Jyri Sarha wrote: > Add device_link from panel device (supplier) to drm device (consumer) >

Re: [PATCH v4 2/2] drm/panel: Add device_link from panel device to drm device

On 2018-05-21 10:15, Andrzej Hajda wrote: > On 19.05.2018 18:48, Peter Rosin wrote: >> On 2018-05-18 13:51, Andrzej Hajda wrote: >>> On 26.04.2018 10:07, Jyri Sarha wrote: Add device_link from panel device (supplier) to drm device (consumer) when drm_panel_attach() is called. This patch

[PATCH v6 4/5] phy: rockchip-typec: support variable phy config value

the phy config values used to fix in dp firmware, but some boards need change these values to do training and get the better eye diagram result. So support that in phy driver. Signed-off-by: Chris Zhong Signed-off-by: Lin Huang --- Changes in v2: -

[PATCH v6 2/5] Documentation: dt-bindings: phy: add phy_config for Rockchip USB Type-C PHY

If want to do training outside DP Firmware, need phy voltage swing and pre_emphasis value. Signed-off-by: Lin Huang --- Changes in v2: - None Changes in v3: - modify property description and add this property to Example Changes in v4: - None Changes in v5: - None Changes in

[PATCH v6 3/5] soc: rockchip: split rockchip_typec_phy struct to separate header

we may use rockchip_phy_typec struct in other driver, so split it to separate header. Signed-off-by: Lin Huang --- Changes in v2: - None Changes in v3: - None Changes in v4: - None Changes in v5: - None Changes in v6: - new patch here

[PATCH 22/33] drm/i915: use match_string() helper

match_string() returns the index of an array for a matching string, which can be used intead of open coded variant. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: David Airlie Cc:

[PATCH 23/33] drm: i2c: ch7006: use match_string() helper

match_string() returns the index of an array for a matching string, which can be used intead of open coded variant. Cc: David Airlie Cc: Yisheng Xie Cc: Daniel Vetter Cc: Arvind Yadav Cc:

Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info

Thanks Jani. I will use free form comments in v4, meanwhile i will explore the required stuff for kernel-doc and add kernel-doc entries where ever it makes sense, in upcoming versions. --Ram On Thursday 17 May 2018 01:47 PM, Jani Nikula wrote: On Thu, 17 May 2018, "C, Ramalingam"

[PATCH 21/33] drm/nouveau: use match_string() helper

match_string() returns the index of an array for a matching string, which can be used intead of open coded variant. Cc: Ben Skeggs Cc: David Airlie Cc: dri-devel@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Signed-off-by: Yisheng Xie

Re: [PATCH libdrm] xf86drm: Be sure to closedir before return

On Friday, 2018-05-18 12:48:17 -0700, Kevin Strasser wrote: > removed in commit bb45ce4e3ac751315bfd7fbfd9e1425bf515ec0d > > Adding it back as it is still needed in the case where we don't find a > match. > > Signed-off-by: Kevin Strasser Good catch, thanks! Fixes:

Re: [PATCH v6 3/5] soc: rockchip: split rockchip_typec_phy struct to separate header

Hi Lin, 2018-05-21 11:37 GMT+02:00 Lin Huang : > we may use rockchip_phy_typec struct in other driver, so split > it to separate header. > That patch does more than just split some structs to a public header, it also introduces new structs and new parameters related to the

[Bug 106589] HP w2207 monitor not waking from sleep

https://bugs.freedesktop.org/show_bug.cgi?id=106589 --- Comment #4 from Sylvain BERTRAND --- I have a similar pb: once my monitor (iiyama g-master) gets into DPMS off mode from the xserver, _often_ (it does work sometimes) the monitor video mode won't be re-programmed

[Bug 199781] New: nouveau: cannot boot without nouveau.modeset=0 and cannot use HDMI output

https://bugzilla.kernel.org/show_bug.cgi?id=199781 Bug ID: 199781 Summary: nouveau: cannot boot without nouveau.modeset=0 and cannot use HDMI output Product: Drivers Version: 2.5 Kernel Version: 4.16.x Hardware: x86-64

[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI

https://bugs.freedesktop.org/show_bug.cgi?id=106548 Francesco Balestrieri changed: What|Removed |Added Priority|medium

[PATCH v4 05/41] misc/mei/hdcp: Notifier chain for mei cldev state change

Notifier Chain is defined to inform all its clients about the mei client device state change. Routine is defined for the clients to register and unregister for the notification on state change. v2: Rebased. v3: Notifier chain is adopted for cldev state update [Tomas] v4: Made static dummy

[PATCH v4 03/41] mei: bus: whitelist hdcp client

From: Tomas Winkler Whitelist HDCP client for in kernel drm use v2: Rebased. v3: No changes. v4: No changes. Signed-off-by: Tomas Winkler --- drivers/misc/mei/bus-fixup.c | 16 1 file changed, 16 insertions(+) diff

[PATCH v4 06/41] 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/\/\*\*/\/\* Signed-off-by:

[PATCH v4 00/41] drm/i915: Implement HDCP2.2

The sequence for HDCP2.2 authentication and encryption is implemented in I915. Encoder specific implementations are moved into hdcp_shim. Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces a client driver for mei bus, so that for HDCP2.2 authentication, HDCP2.2 stack in I915

[PATCH v4 01/41] drm: hdcp2.2 authentication msg definitions

This patch defines the hdcp2.2 protocol messages for authentication. v2: bit_fields are removed. Instead bitmasking used. [Tomas and Jani] prefix HDCP_2_2_ is added to the macros. [Tomas] v3: No Changes. v4: Style and spellings are fixed [Uma] Signed-off-by: Ramalingam C

[PATCH v4 02/41] drm: HDMI and DP specific HDCP2.2 defines

This patch adds HDCP register definitions for HDMI and DP HDCP adaptations. HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h, where as HDCP2.2 register offsets in DPCD offsets are defined at drm_dp_helper.h. v2: bit_field definitions are replaced by macros. [Tomas and Jani]

[PATCH v6 5/5] drm/rockchip: support dp training outside dp firmware

DP firmware uses fixed phy config values to do training, but some boards need to adjust these values to fit for their unique hardware design. So get phy config values from dts and use software link training instead of relying on firmware, if software training fail, keep firmware training as a

[PATCH v6 1/5] drm/rockchip: add transfer function for cdn-dp

From: Chris Zhong We may support training outside firmware, so we need support dpcd read/write to get the message or do some setting with display. Signed-off-by: Chris Zhong Signed-off-by: Lin Huang Reviewed-by: Sean Paul

[PATCH 24/33] drm: use match_string() helper

match_string() returns the index of an array for a matching string, which can be used intead of open coded variant. Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc:

[PATCH 20/33] video: fbdev: pxafb: use match_string() helper

match_string() returns the index of an array for a matching string, which can be used intead of open coded variant. Cc: Bartlomiej Zolnierkiewicz Cc: Arvind Yadav Cc: dri-devel@lists.freedesktop.org linux-fb...@vger.kernel.org Signed-off-by:

[PATCH v4 07/41] linux/mei: Header for mei_hdcp driver interface

Data structures and Enum for the I915-MEI_HDCP interface are defined at v2: Rebased. v3: mei_cl_device is removed from mei_hdcp_data [Tomas] v4: Comment style and typo fixed [Uma] Signed-off-by: Ramalingam C --- include/linux/mei_hdcp.h | 70

[PATCH v4 13/41] 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

[PATCH v4 14/41] 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

[PATCH v4 15/41] 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

[PATCH v4 04/41] misc/mei/hdcp: Client driver for HDCP application

ME FW is contributes a vital role in HDCP2.2 authentication. HDCP2.2 driver needs to communicate to ME FW for each step of the HDCP2.2 authentication. ME FW prepare and HDCP2.2 authentication parameters and encrypt them as per spec. With such parameter Driver prepares HDCP2.2 auth messages and

[PATCH v4 09/41] 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

[PATCH v4 10/41] 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

[PATCH v4 08/41] 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

[PATCH v4 11/41] 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

[PATCH v4 19/41] drm/i915: wrapping all hdcp var into intel_hdcp

Considering significant number of HDCP specific variables, it will be clean to have separate struct for HDCP. New structure called intel_hdcp is added within intel_connector. v2: struct hdcp statically allocated. [Sean Paul] enable and disable function parameters are retained.[Sean Paul] v3:

[PATCH v4 20/41] 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 v4 18/41] 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

[PATCH v4 21/41] 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] v3: No changes. v4: %s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma] Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/i915_reg.h | 32

[PATCH v4 29/41] 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. v3: No Changes. v4: inline tag is removed with modified error msg. Signed-off-by: Ramalingam C

[PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface

Initialize HDCP2.2 support. This includes the mei interface initialization along with required notifier registration. v2: mei interface handle is protected with mutex. [Chris Wilson] v3: Notifiers are used for the mei interface state. v4: Poll for mei client device state Error msg for out

[PATCH v4 28/41] 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: No Changes. v4: Typo in commit msg is fixed [Uma] Signed-off-by: Ramalingam C

[PATCH v4 27/41] 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 v4 25/41] 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] v3: No Changes. v4: Debug msg is added for timeout at Disable of Encryption [Uma] %s/HDCP2_CTL/HDCP2_CTL Signed-off-by: Ramalingam C

[PATCH v4 26/41] drm/i915: Implement HDCP2.2 En/Dis-able

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

[PATCH v4 24/41] 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. v3: No Changes. v4: -EINVAL is returned for topology error and rollover scenario. Endianness conversion func from drm_hdcp.h is used

[PATCH v4 31/41] 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. v3: No Changes. v4: Style fix. Signed-off-by: Ramalingam C Reviewed-by: Uma Shankar

[PATCH v4 33/41] 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. v3: No Changes. v4: Reviewed-by is collected. Signed-off-by: Ramalingam C Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdcp.c | 4 +++- 1 file

Re: [Intel-gfx] [PATCH v3 38/40] drm/i915: Implement the HDCP2.2 support for HDMI

On Friday 18 May 2018 09:59 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;

[Bug 199781] nouveau: cannot boot without nouveau.modeset=0 and cannot use HDMI output

https://bugzilla.kernel.org/show_bug.cgi?id=199781 --- Comment #3 from Frédéric Pierret (frederic.epi...@orange.fr) --- Thank for your answer. Some progress but now freeze with two type of errors: May 21 14:51:58 dom0 kernel: [ cut here ] May 21 14:51:58 dom0 kernel:

[PATCH v4 41/41] 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: No Changes. v4: Collected the reviewed-by received. Signed-off-by: Ramalingam C Reviewed-by: Uma Shankar ---

[Bug 106589] HP w2207 monitor not waking from sleep

https://bugs.freedesktop.org/show_bug.cgi?id=106589 --- Comment #6 from Sylvain BERTRAND --- Created attachment 139665 --> https://bugs.freedesktop.org/attachment.cgi?id=139665=edit kernel log -- You are receiving this mail because: You are the assignee for the

Re: [PATCH RFC 06/24] drm/lima: add lima uapi header

Qiang Yu writes: > Signed-off-by: Qiang Yu > --- > include/uapi/drm/lima_drm.h | 195 > 1 file changed, 195 insertions(+) > create mode 100644 include/uapi/drm/lima_drm.h > > diff --git a/include/uapi/drm/lima_drm.h

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/21/2018 07:35 PM, Boris Ostrovsky wrote: On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote: On 05/19/2018 01:04 AM, Boris Ostrovsky wrote: On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko A commit message would

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

https://bugs.freedesktop.org/show_bug.cgi?id=105760 --- Comment #10 from taij...@posteo.de --- This seems to be fixed an the current drm-next-4.18-wip branch. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel

[Bug 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

https://bugs.freedesktop.org/show_bug.cgi?id=105500 --- Comment #5 from Balázs Vinarz --- GCN2 based APUs are not affected with none AMDGPU or Radeon kernel modules. -- You are receiving this mail because: You are the assignee for the

[Bug 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI

https://bugs.freedesktop.org/show_bug.cgi?id=106402 --- Comment #4 from taij...@posteo.de --- to get a kernel log from a previous boot attempt, try something like: journalctl -kb -1 > error.log where -1 would be the previous boot, -2 the one before that, etc. -- You are receiving this mail

Re: [PATCH v8 2/3] drm: writeback: Add out-fences for writeback connectors

Liviu Dudau writes: > From: Brian Starkey > > Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to > enable userspace to get a fence which will signal once the writeback is > complete. It is not allowed to request an out-fence without

Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"

Qiang Yu writes: > This reverts commit 45c3d213a400c952ab7119f394c5293bb6877e6b. > > lima driver need preclose to wait all task in the context > created within closing file to finish before free all the > buffer object. Otherwise pending tesk may fail and get > noisy MMU fault

[Bug 101262] Need help in running Dying Light

https://bugs.freedesktop.org/show_bug.cgi?id=101262 --- Comment #6 from Mariusz Ceier --- That bug is due to missing /usr/bin/lspci. Dying Light tries to execve /usr/bin/lspci in a fork and when it fails it calls exit function instead of _exit. exit calls exit

Re: [PATCH] drm/v3d: Checking for NULL vs IS_ERR()

Dan Carpenter writes: > The v3d_fence_create() only returns error pointers on error. It never > returns NULL. > > Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D > V3.x+") > Signed-off-by: Dan Carpenter Pushed to

[Bug 105433] Unreliable Modesetting on Tonga with two DVI Screens

https://bugs.freedesktop.org/show_bug.cgi?id=105433 --- Comment #5 from Thomas R. --- Hm. Well the current state of this machine is: I got an old working AMD DC kernel (4.11) that is starting to give me trouble, and nothing current that works. I'd be willing

[Bug 106589] HP w2207 monitor not waking from sleep

https://bugs.freedesktop.org/show_bug.cgi?id=106589 --- Comment #7 from Sylvain BERTRAND --- I provide the logs since it happened today with the latest code. -- You are receiving this mail because: You are the assignee for the

Re: vc4: Detect working driver from cmdline

Stefan Wahren writes: > Hi, > in order to improve kernelci.org results and avoid false positive cases like > this [1], i suggested to also test for a working VC4 driver. In order to keep > it simple, we should do it from userspace. > > My first idea was: > > test -d

[Bug 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI

https://bugs.freedesktop.org/show_bug.cgi?id=106402 --- Comment #5 from taij...@posteo.de --- Also, this is a duplicate of Bug 105760 which is fixed in the current drm-next-4.18-wip. -- You are receiving this mail because: You are the assignee for the

[Bug 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI

https://bugs.freedesktop.org/show_bug.cgi?id=106402 taij...@posteo.de changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

https://bugs.freedesktop.org/show_bug.cgi?id=105760 taij...@posteo.de changed: What|Removed |Added CC||ratch...@gmail.com --- Comment #11

[Bug 106589] HP w2207 monitor not waking from sleep

https://bugs.freedesktop.org/show_bug.cgi?id=106589 --- Comment #5 from Sylvain BERTRAND --- Created attachment 139664 --> https://bugs.freedesktop.org/attachment.cgi?id=139664=edit Xorg.log -- You are receiving this mail because: You are the assignee for the

  1   2   3   >