Re: [Intel-gfx] [PATCH 03/10] drm/syncobj: add new drm_syncobj_add_point interface v2

2018-12-12 Thread Chunming Zhou
在 2018/12/12 20:24, Daniel Vetter 写道: > On Wed, Dec 12, 2018 at 12:40 PM Zhou, David(ChunMing) > wrote: >> + Daniel Rakos and Jason Ekstrand. >> >> Below is the background, which is from Daniel R should be able to explain >> that's why: >> " ISVs, especially those coming from D3D12, are

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well

2018-12-12 Thread Ville Syrjälä
On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan wrote: > On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Fill out the AVI infoframe quantization range bits using > > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well. > > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Implement HDCP2.2 (rev11)

2018-12-12 Thread Patchwork
== Series Details == Series: drm/i915: Implement HDCP2.2 (rev11) URL : https://patchwork.freedesktop.org/series/38254/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5310 -> Patchwork_11081 Summary --- **FAILURE**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Implement HDCP2.2 (rev11)

2018-12-12 Thread Patchwork
== Series Details == Series: drm/i915: Implement HDCP2.2 (rev11) URL : https://patchwork.freedesktop.org/series/38254/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Gathering the HDCP1.4 routines together Okay! Commit: drm: header for i915

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Implement HDCP2.2 (rev11)

2018-12-12 Thread Patchwork
== Series Details == Series: drm/i915: Implement HDCP2.2 (rev11) URL : https://patchwork.freedesktop.org/series/38254/ State : warning == Summary == $ dim checkpatch origin/drm-tip bcb5b8686be3 drm/i915: Gathering the HDCP1.4 routines together 83df45d26858 drm: header for i915 - MEI_HDCP

[Intel-gfx] [PATCH v9 26/39] misc/mei/hdcp: Verify H_prime

2018-12-12 Thread Ramalingam C
Requests for the verification of AKE_Send_H_prime. ME will calculate the H and comparing it with received H_Prime. The result will be returned as status. Here AKE_Send_H_prime is a HDCP2.2 Authentication msg. v2: Rebased. v3: cldev is passed as first parameter [Tomas] Redundant comments and

[Intel-gfx] [PATCH v9 34/39] misc/mei/hdcp: Closing wired HDCP2.2 Tx Session

2018-12-12 Thread Ramalingam C
Request the ME to terminate the HDCP2.2 session for a port. On Success, ME FW will mark the intel port as Deauthenticated and terminate the wired HDCP2.2 Tx session started due to the cmd WIRED_INITIATE_HDCP2_SESSION. v2: Rebased. v3: cldev is passed as first parameter [Tomas] Redundant

[Intel-gfx] [PATCH v9 39/39] FOR_TESTING_ONLY: debugfs: Excluding the LSPCon for HDCP1.4

2018-12-12 Thread Ramalingam C
Just excluding the LSPCon HDMI ports from the HDCP1.4 testing. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/i915_debugfs.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index

[Intel-gfx] [PATCH v9 30/39] misc/mei/hdcp: Prepare Session Key

2018-12-12 Thread Ramalingam C
Request to ME to prepare the encrypted session key. On Success, ME provides Encrypted session key. Function populates the HDCP2.2 authentication msg SKE_Send_Eks. v2: Rebased. v3: cldev is passed as first parameter [Tomas] Redundant comments and cast are removed [Tomas] v4: %zd for ssize_t

[Intel-gfx] [PATCH v9 33/39] misc/mei/hdcp: Enabling the HDCP authentication

2018-12-12 Thread Ramalingam C
Request to ME to configure a port as authenticated. On Success, ME FW will mark the port as authenticated and provides HDCP cipher with the encryption keys. Enabling the Authentication can be requested once all stages of HDCP2.2 authentication is completed by interacting with ME FW. Only after

[Intel-gfx] [PATCH v9 32/39] misc/mei/hdcp: Verify M_prime

2018-12-12 Thread Ramalingam C
Request to ME to verify the M_Prime received from the HDCP sink. ME FW will calculate the M and compare with M_prime received as part of RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg. On successful completion of this stage, downstream propagation of the stream management info is

[Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface

2018-12-12 Thread Ramalingam C
Mei hdcp driver is designed as component slave for the I915 component master. v2: Rebased. v3: Notifier chain is adopted for cldev state update [Tomas] v4: Made static dummy functions as inline in mei_hdcp.h API for polling client device status IS_ENABLED used in header, for config status

[Intel-gfx] [PATCH v9 27/39] misc/mei/hdcp: Store the HDCP Pairing info

2018-12-12 Thread Ramalingam C
Provides Pairing info to ME to store. Pairing is a process to fast track the subsequent authentication with the same HDCP sink. On Success, received HDCP pairing info is stored in non-volatile memory of ME. v2: Rebased. v3: cldev is passed as first parameter [Tomas] Redundant comments and

[Intel-gfx] [PATCH v9 28/39] misc/mei/hdcp: Initiate Locality check

2018-12-12 Thread Ramalingam C
Requests ME to start the second stage of HDCP2.2 authentication, called Locality Check. On Success, ME FW will provide LC_Init message to send to hdcp sink. v2: Rebased. v3: cldev is passed as first parameter [Tomas] Redundant comments and cast are removed [Tomas] v4: %zd used for ssize_t

[Intel-gfx] [PATCH v9 38/39] FOR_TEST: i915/Kconfig: Select mei_hdcp by I915

2018-12-12 Thread Ramalingam C
FOR TESTING PURPOSE ONLY. By default INTEL_MEI_HDCP is set to y. This patch is created to test the interface between I915 and MEI_HDCP. Signed-off-by: Ramalingam C --- drivers/misc/mei/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/mei/Kconfig

[Intel-gfx] [PATCH v9 24/39] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session

2018-12-12 Thread Ramalingam C
Request ME FW to start the HDCP2.2 session for an intel port. Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends to ME FW. On Success, ME FW will start a HDCP2.2 session for the port and provides the content for HDCP2.2 AKE_Init message. v2: Rebased. v3: cldev is add as a

[Intel-gfx] [PATCH v9 37/39] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

2018-12-12 Thread Ramalingam C
Implement the required WA sequence for KBL to fix the incorrect positioning of the window of oppurtunity and enc_en signalling. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 29 + 1 file changed, 29 insertions(+) diff --git

[Intel-gfx] [PATCH v9 29/39] misc/mei/hdcp: Verify L_prime

2018-12-12 Thread Ramalingam C
Request to ME to verify the LPrime received from HDCP sink. On Success, ME FW will verify the received Lprime by calculating and comparing with L. This represents the completion of Locality Check. v2: Rebased. v3: cldev is passed as first parameter [Tomas] Redundant comments and cast are

[Intel-gfx] [PATCH v9 31/39] misc/mei/hdcp: Repeater topology verification and ack

2018-12-12 Thread Ramalingam C
Request ME to verify the downstream topology information received. ME FW will validate the Repeaters receiver id list and downstream topology. On Success ME FW will provide the Least Significant 128bits of VPrime, which forms the repeater ack. v2: Rebased. v3: cldev is passed as first

[Intel-gfx] [PATCH v9 36/39] drm/i915: Commit CP without modeset

2018-12-12 Thread Ramalingam C
Commits the content protection change of a connector, without crtc modeset. This improves the user experience. Originally proposed by Sean Paul at v3 of HDCP1.4 framework https://patchwork.freedesktop.org/patch/191759/. For some reason this was dropped, but needed for the proper functionality of

[Intel-gfx] [PATCH v9 16/39] drm/i915: Implement the HDCP2.2 support for DP

2018-12-12 Thread Ramalingam C
Implements the DP adaptation specific HDCP2.2 functions. These functions perform the DPCD read and write for communicating the HDCP2.2 auth message back and forth. v2: wait for cp_irq is merged with this patch. Rebased. v3: wait_queue is used for wait for cp_irq [Chris Wilson] v4: Style

[Intel-gfx] [PATCH v9 13/39] drm: HDCP2.2 link check related constants

2018-12-12 Thread Ramalingam C
Enums and macros are defined for HDCP2.2 link check. Signed-off-by: Ramalingam C --- include/drm/drm_hdcp.h | 8 1 file changed, 8 insertions(+) diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index d8093ecf3ddc..21a128e7020a 100644 --- a/include/drm/drm_hdcp.h +++

[Intel-gfx] [PATCH v9 22/39] misc/mei/hdcp: Client driver for HDCP application

2018-12-12 Thread Ramalingam C
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

[Intel-gfx] [PATCH v9 18/39] drm/i915: Add HDCP2.2 support for DP connectors

2018-12-12 Thread Ramalingam C
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

[Intel-gfx] [PATCH v9 25/39] misc/mei/hdcp: Verify Receiver Cert and prepare km

2018-12-12 Thread Ramalingam C
Requests for verification for receiver certification and also the preparation for next AKE auth message with km. On Success ME FW validate the HDCP2.2 receivers certificate and do the revocation check on the receiver ID. AKE_Stored_Km will be prepared if the receiver is already paired, else

[Intel-gfx] [PATCH v9 19/39] drm/i915: Add HDCP2.2 support for HDMI connectors

2018-12-12 Thread Ramalingam C
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

[Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication

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

[Intel-gfx] [PATCH v9 15/39] drm/i915: Handle HDCP2.2 downstream topology change

2018-12-12 Thread Ramalingam C
When repeater notifies a downstream topology change, this patch reauthenticate the repeater alone without disabling the hdcp encryption. If that fails then complete reauthentication is executed. v2: Rebased. v3: Typo in commit msg is fixed [Uma] v4: Rebased as part of patch reordering.

[Intel-gfx] [PATCH v9 09/39] drm/i915: Enable and Disable of HDCP2.2

2018-12-12 Thread Ramalingam C
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled. When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is enabled. This change implements a sequence of enabling and disabling of HDCP2.2 authentication and HDCP2.2

[Intel-gfx] [PATCH v9 21/39] mei: bus: export to_mei_cl_device for mei client device drivers

2018-12-12 Thread Ramalingam C
From: Tomas Winkler Export to_mei_cl_device macro, it is needed also in mei client drivers. Signed-off-by: Tomas Winkler --- drivers/misc/mei/bus.c | 1 - include/linux/mei_cl_bus.h | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/misc/mei/bus.c

[Intel-gfx] [PATCH v9 17/39] drm/i915: Implement the HDCP2.2 support for HDMI

2018-12-12 Thread Ramalingam C
Implements the HDMI adaptation specific HDCP2.2 operations. Basically these are DDC read and write for authenticating through HDCP2.2 messages. v2: Rebased. v3: No more special handling of Gmbus burst read for AKE_SEND_CERT. Style fixed with few naming. [Uma] %s/PARING/PAIRING v4: msg_sz

[Intel-gfx] [PATCH v9 14/39] drm/i915: Implement HDCP2.2 link integrity check

2018-12-12 Thread Ramalingam C
Implements the link integrity check once in 500mSec. Once encryption is enabled, an ongoing Link Integrity Check is performed by the HDCP Receiver to check that cipher synchronization is maintained between the HDCP Transmitter and the HDCP Receiver. On the detection of synchronization lost, the

[Intel-gfx] [PATCH v9 23/39] misc/mei/hdcp: Define ME FW interface for HDCP2.2

2018-12-12 Thread Ramalingam C
Defines the HDCP specific ME FW interfaces such as Request CMDs, payload structure for CMDs and their response status codes. This patch defines payload size(Excluding the Header)for each WIRED HDCP2.2 CMDs. v2: Rebased. v3: Extra comments are removed. v4: %s/\/\*\*/\/\* v5: Extra lines are

[Intel-gfx] [PATCH v9 20/39] mei: bus: whitelist hdcp client

2018-12-12 Thread Ramalingam C
From: Tomas Winkler Whitelist HDCP client for in kernel drm use v2: Rebased. Signed-off-by: Tomas Winkler --- drivers/misc/mei/bus-fixup.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c index

[Intel-gfx] [PATCH v9 12/39] drm/i915: Implement HDCP2.2 repeater authentication

2018-12-12 Thread Ramalingam C
Implements the HDCP2.2 repeaters authentication steps such as verifying the downstream topology and sending stream management information. v2: Rebased. v3: -EINVAL is returned for topology error and rollover scenario. Endianness conversion func from drm_hdcp.h is used [Uma] v4: Rebased as

[Intel-gfx] [PATCH v9 11/39] drm: helper functions for hdcp2 seq_num to from u32

2018-12-12 Thread Ramalingam C
Library functions for endianness are aligned for 16/32/64 bits. But hdcp sequence numbers are 24bits(big endian). So for their conversion to and from u32 helper functions are developed. Signed-off-by: Ramalingam C --- include/drm/drm_hdcp.h | 18 ++ 1 file changed, 18

[Intel-gfx] [PATCH v9 08/39] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

2018-12-12 Thread Ramalingam C
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status. This SW tracking is used to determine the need for real hdcp1.4 disable and hdcp_check_link upon CP_IRQ. On CP_IRQ we filter the CP_IRQ related to the states like Link failure and reauthentication req etc and handle them in

[Intel-gfx] [PATCH v9 00/39] drm/i915: Implement HDCP2.2

2018-12-12 Thread Ramalingam C
This series enables the HDCP2.2 for I915. The sequence for HDCP2.2 authentication and encryption is implemented as a generic flow between HDMI and DP. Encoder specific implementations are moved into hdcp_shim. Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces a client driver

[Intel-gfx] [PATCH v9 05/39] drm/i915: component master at i915 driver load

2018-12-12 Thread Ramalingam C
A generic component master is added to hold the i915 registration until all required kernel modules are up and active. This is achieved through following steps: - moving the i915 driver registration to the component master's bind call - all required kernel modules will add one component

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

2018-12-12 Thread Ramalingam C
All HDCP1.4 routines are gathered together, followed by the generic functions those can be extended for HDCP2.2 too. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 118 +++--- 1 file changed, 59 insertions(+), 59 deletions(-) diff --git

[Intel-gfx] [PATCH v9 06/39] drm/i915: Initialize HDCP2.2

2018-12-12 Thread Ramalingam C
Add the HDCP2.2 initialization to the existing HDCP1.4 stack. v2: mei interface handle is protected with mutex. [Chris Wilson] v3: Notifiers are used for the mei interface state. v4: Poll for mei client device state Error msg for out of mem [Uma] Inline req for init function removed

[Intel-gfx] [PATCH v9 07/39] drm/i915: MEI interface definition

2018-12-12 Thread Ramalingam C
Defining the mei-i915 interface functions and initialization of the interface. v2: Adjust to the new interface changes. [Tomas] Added further debug logs for the failures at MEI i/f. port in hdcp_port data is equipped to handle -ve values. v3: mei comp is matched for global i915 comp

[Intel-gfx] [PATCH v9 04/39] component: alloc component_match without any comp to match

2018-12-12 Thread Ramalingam C
If all the components associated to a component master is not added to the component framework due to the HW capability or Kconfig selection, component_match will be NULL at component_master_add_with_match(). To avoid this, component_match_alloc() is added to the framework, to allcoate the struct

[Intel-gfx] [PATCH v9 02/39] drm: header for i915 - MEI_HDCP interface

2018-12-12 Thread Ramalingam C
Header defines the interface for the I915 and MEI_HDCP drivers. Signed-off-by: Ramalingam C --- include/drm/i915_mei_hdcp_interface.h | 132 ++ 1 file changed, 132 insertions(+) create mode 100644 include/drm/i915_mei_hdcp_interface.h diff --git

[Intel-gfx] [PATCH v9 03/39] drivers/base: use a worker for sysfs unbind

2018-12-12 Thread Ramalingam C
From: Daniel Vetter Drivers might want to remove some sysfs files, which needs the same locks and ends up angering lockdep. Relevant snippet of the stack trace: kernfs_remove_by_name_ns+0x3b/0x80 bus_remove_driver+0x92/0xa0 acpi_video_unregister+0x24/0x40 i915_driver_unload+0x42/0x130

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

2018-12-12 Thread C, Ramalingam
On 12/12/2018 4:34 PM, C, Ramalingam wrote: On 12/12/2018 4:08 PM, Daniel Vetter wrote: On Wed, Dec 12, 2018 at 02:28:29PM +0530, C, Ramalingam wrote: On 12/7/2018 7:59 PM, Daniel Vetter wrote: On Fri, Dec 07, 2018 at 11:22:44AM +0530, C, Ramalingam wrote: On 12/6/2018 3:53 PM, Daniel

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers

2018-12-12 Thread Lucas De Marchi
On Wed, Dec 12, 2018 at 11:17:38PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Remove the hand rolled array of WM0_PIPE register offsets > and use the standard _MMIO_PIPE3() instead. > > v2: Take care of gvt too > > Signed-off-by: Ville Syrjälä Reviewed-by: Lucas De Marchi Lucas

Re: [Intel-gfx] [PATCH 7/7] drm/i915/psr: Disable DRRS if enabled when enabling PSR from debugfs

2018-12-12 Thread Dhinakaran Pandiyan
On Wed, 2018-12-12 at 05:02 -0800, Souza, Jose wrote: > On Tue, 2018-12-11 at 14:02 -0800, Dhinakaran Pandiyan wrote: > > On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote: > > > Op 09-11-18 om 21:20 schreef José Roberto de Souza: > > > > If panel supports DRRS and PSR and if driver is

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: merge gen checks to use range

2018-12-12 Thread Rodrigo Vivi
On Tue, Dec 11, 2018 at 04:35:57PM +0200, Jani Nikula wrote: > On Wed, 05 Dec 2018, Lucas De Marchi wrote: > > Instead of using IS_GEN() for consecutive gen checks, let's pass the > > range to IS_GEN_RANGE(). By code inspection these were the ranges deemed > > necessary for spatch: > > > > @@ > >

Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

2018-12-12 Thread Hwang, Dongseong
On Wed, Dec 12, 2018 at 1:15 PM Ville Syrjälä wrote: > > On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote: > > On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä > > wrote: > > > > > > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote: > > > > framebuffer for NV12 requires

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well

2018-12-12 Thread Dhinakaran Pandiyan
On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Fill out the AVI infoframe quantization range bits using > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_sdvo.c | 19

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 (rev2)

2018-12-12 Thread Patchwork
== Series Details == Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 (rev2) URL : https://patchwork.freedesktop.org/series/53962/ State : success == Summary == CI Bug Log - changes from CI_DRM_5308 -> Patchwork_11080

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 (rev2)

2018-12-12 Thread Patchwork
== Series Details == Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 (rev2) URL : https://patchwork.freedesktop.org/series/53962/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Shrink ilk-bdw wm storage

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Don't forget to reset blocks when testing lower wm levels

2018-12-12 Thread Patchwork
== Series Details == Series: drm/i915: Don't forget to reset blocks when testing lower wm levels URL : https://patchwork.freedesktop.org/series/53961/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5307_full -> Patchwork_11078_full

[Intel-gfx] [PATCH v2 6/6] drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers

2018-12-12 Thread Ville Syrjala
From: Ville Syrjälä Remove the hand rolled array of WM0_PIPE register offsets and use the standard _MMIO_PIPE3() instead. v2: Take care of gvt too Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gvt/handlers.c | 6 +++--- drivers/gpu/drm/i915/i915_reg.h | 9 +

Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

2018-12-12 Thread Ville Syrjälä
On Wed, Dec 12, 2018 at 09:33:49PM +0100, Daniel Vetter wrote: > On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä > wrote: > > > > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote: > > > framebuffer for NV12 requires the pitch to the multiplier of 4, instead > > > of the width. This

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

2018-12-12 Thread Sean Paul
Hi Dave, One lonely patch to fix a new WARN on rockchip rk3399 chromebooks. drm-misc-fixes-2018-12-12: - rockchip: Revert change causing WARN on shutdown (Brian) Cc: Brian Norris Cheers, Sean The following changes since commit b31a3ca745a4a47ba63208d37cd50abffe58280f: drm/fb-helper: Fix

Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

2018-12-12 Thread Daniel Vetter
On Wed, Dec 12, 2018 at 9:24 PM Ville Syrjälä wrote: > > On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote: > > framebuffer for NV12 requires the pitch to the multiplier of 4, instead > > of the width. This patch corrects it. > > > > For instance, a 480p video, whose width and pitch

Re: [Intel-gfx] [PATCH] drm/i915: Don't forget to reset blocks when testing lower wm levels

2018-12-12 Thread Matt Roper
On Wed, Dec 12, 2018 at 09:23:38PM +0200, Ville Syrjälä wrote: > On Wed, Dec 12, 2018 at 11:17:20AM -0800, Matt Roper wrote: > > During DDB allocation, we try to distribute enough blocks for each plane > > to hit the highest watermark level; if that fails, we retry each lower > > level (which

Re: [Intel-gfx] [PATCH v2] drm/i915: correct the pitch check for NV12 framebuffer

2018-12-12 Thread Ville Syrjälä
On Tue, Dec 11, 2018 at 04:39:05PM -0800, Dongseong Hwang wrote: > framebuffer for NV12 requires the pitch to the multiplier of 4, instead > of the width. This patch corrects it. > > For instance, a 480p video, whose width and pitch are 854 and 896 > respectively, is excluded for NV12 plane so

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16

2018-12-12 Thread Patchwork
== Series Details == Series: series starting with [1/6] drm/i915: Shrink ilk-bdw wm storage by using u16 URL : https://patchwork.freedesktop.org/series/53962/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M]

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't forget to reset blocks when testing lower wm levels

2018-12-12 Thread Patchwork
== Series Details == Series: drm/i915: Don't forget to reset blocks when testing lower wm levels URL : https://patchwork.freedesktop.org/series/53961/ State : success == Summary == CI Bug Log - changes from CI_DRM_5307 -> Patchwork_11078

[Intel-gfx] [PATCH 4/6] drm/i915: Remove gen6_check_mch_setup()

2018-12-12 Thread Ville Syrjala
From: Ville Syrjälä snb_wm_latency_quirk() already boosts up the latency values so the extra warning about the SSKPD value being insufficient is now redundant. Drop it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 2 -- drivers/gpu/drm/i915/intel_pm.c | 14

[Intel-gfx] [PATCH 6/6] drm/i915: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registers

2018-12-12 Thread Ville Syrjala
From: Ville Syrjälä Remove the hand rolled array of WM0_PIPE register offsets and use the standard _MMIO_PIPE3() instead. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 9 + drivers/gpu/drm/i915/intel_pm.c | 13 - 2 files changed, 9 insertions(+), 13

[Intel-gfx] [PATCH 5/6] drm/i915: Clean up SSKPD defines

2018-12-12 Thread Ville Syrjala
From: Ville Syrjälä Give names to the HSW/BDW SSKPD mask/shift values, give and _SNB suffix to the SNB/IVB mask/shift values, and drop the bogus non-mirrored SSKPD register define. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 26 +-

[Intel-gfx] [PATCH 2/6] drm/i915: Rename ilk watermark structs/enums

2018-12-12 Thread Ville Syrjala
From: Ville Syrjälä Rename all the watermark related structs/enums specific to ilk-bdw to have an ilk_ prefix rather than an intel_ prefix. Should make it less confusing for everyone when it's clear where these things get used. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 1/6] drm/i915: Shrink ilk-bdw wm storage by using u16

2018-12-12 Thread Ville Syrjala
From: Ville Syrjälä The maximum watermark value we can ever have on ilk-bdw is 11 bits. Thus we can safely store all of these values in u16. Also toss in a few s/uint16_t/u16/ etc. while at it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 16 ++---

[Intel-gfx] [PATCH 3/6] drm/i915: Stash away the original SSKPD latency values

2018-12-12 Thread Ville Syrjala
From: Ville Syrjälä On ILK-IVB we must write the latency value read from SSKPD into the latency field in the WM_LP registers. While bspec was never clear on how the punit (or whatever) interprets these values empirical evidence has shown that these are treated as a cookie rather than as a

Re: [Intel-gfx] [PATCH] drm/i915: Don't forget to reset blocks when testing lower wm levels

2018-12-12 Thread Ville Syrjälä
On Wed, Dec 12, 2018 at 11:17:20AM -0800, Matt Roper wrote: > During DDB allocation, we try to distribute enough blocks for each plane > to hit the highest watermark level; if that fails, we retry each lower > level (which should require fewer blocks) until we find one that's > possible (or until

[Intel-gfx] [PATCH] drm/i915: Don't forget to reset blocks when testing lower wm levels

2018-12-12 Thread Matt Roper
During DDB allocation, we try to distribute enough blocks for each plane to hit the highest watermark level; if that fails, we retry each lower level (which should require fewer blocks) until we find one that's possible (or until the whole commit is rejected as impossible). We need to reset our

[Intel-gfx] 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

2018-12-12 Thread Pavel Machek
Hi! > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > > > genuine > > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > > > > > Any extra information would be of

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim

2018-12-12 Thread Patchwork
== Series Details == Series: series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/53953/ State : success == Summary == CI Bug Log - changes from CI_DRM_5296_full -> Patchwork_11077_full

Re: [Intel-gfx] [PATCH 07/19] drm/i915/icl: Mind the SFC units when resetting VD or VEBox engines

2018-12-12 Thread Tvrtko Ursulin
On 12/12/2018 13:41, Chris Wilson wrote: From: Oscar Mateo SFC (Scaler & Format Converter) units are shared between VD and VEBoxes. They also happen to have separate reset bits. So, whenever we want to reset one or more of the media engines, we have to make sure the SFCs do not change owner

Re: [Intel-gfx] [PATCH 06/19] drm/i915/icl: Record the valid VDBoxes with SFC capability

2018-12-12 Thread Tvrtko Ursulin
On 12/12/2018 13:41, Chris Wilson wrote: From: Oscar Mateo In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC (Scaler & Format Converter) unit. We will use this information to decide when the SFC units need to be reset. BSpec: 20189 Signed-off-by: Tomasz Lis

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim

2018-12-12 Thread Patchwork
== Series Details == Series: series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/53953/ State : success == Summary == CI Bug Log - changes from CI_DRM_5296 -> Patchwork_11077

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC mipi sequences

2018-12-12 Thread Hans de Goede
Hi, On 07-12-18 18:17, Ville Syrjälä wrote: On Thu, Dec 06, 2018 at 02:47:05PM +0100, Hans de Goede wrote: Add support for PMIC mipi sequences using the new intel_soc_pmic_exec_mipi_pmic_seq_element function. Please document somewhere which machines you've found to need this (commit msg

Re: [Intel-gfx] [PATCH v2 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements

2018-12-12 Thread Hans de Goede
Hi, On 07-12-18 12:39, Mika Westerberg wrote: On Thu, Dec 06, 2018 at 02:47:03PM +0100, Hans de Goede wrote: DSI LCD panels describe an initialization sequence in the Video BIOS Tables using so called MIPI sequences. One possible element in these sequences is a PMIC specific element of 15

Re: [Intel-gfx] [PATCH v2 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC

2018-12-12 Thread Hans de Goede
Hi, On 07-12-18 12:40, Mika Westerberg wrote: On Thu, Dec 06, 2018 at 02:47:04PM +0100, Hans de Goede wrote: Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove PMIC. On some CHT devices this fixes the LCD panel not lighting up when it was not initialized by the GOP,

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim

2018-12-12 Thread Patchwork
== Series Details == Series: series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/53953/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Return

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim

2018-12-12 Thread Patchwork
== Series Details == Series: series starting with [01/19] drm/i915: Return immediately if trylock fails for direct-reclaim URL : https://patchwork.freedesktop.org/series/53953/ State : warning == Summary == $ dim checkpatch origin/drm-tip 916a3be212e3 drm/i915: Return immediately if trylock

Re: [Intel-gfx] [drm-intel:for-linux-next-fixes 5/5] drivers/gpu//drm/i915/intel_ringbuffer.c:89:11: error: implicit declaration of function 'i915_scratch_offset'; did you mean 'i915_ggtt_offset'?

2018-12-12 Thread Joonas Lahtinen
Should be fixed already with an updated -fixes. Regards, Joonas Quoting kbuild test robot (2018-12-12 10:31:58) > tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes > head: eeb139ca4b24d515265ad75f668333431896b1aa > commit: eeb139ca4b24d515265ad75f668333431896b1aa [5/5]

[Intel-gfx] [PATCH 02/19] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start

2018-12-12 Thread Chris Wilson
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers") we have been able to report failure from mmu_invalidate_range_start which allows us to use a trylock on the struct_mutex to avoid potential recursion and report -EBUSY instead. Furthermore, this allows us to pull

[Intel-gfx] [PATCH 14/19] drm/i915: Markup paired operations on display power domains

2018-12-12 Thread Chris Wilson
The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various

[Intel-gfx] [PATCH 11/19] drm/i915: Track all held rpm wakerefs

2018-12-12 Thread Chris Wilson
Everytime we take a wakeref, record the stack trace of where it was taken; clearing the set if we ever drop back to no owners. For debugging a rpm leak, we can look at all the current wakerefs and check if they have a matching rpm_put. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 15/19] drm/i915: Track the wakeref used to initialise display power domains

2018-12-12 Thread Chris Wilson
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and transfer them to the runtime-pm code. We can use our wakeref tracking to verify that the wakeref is indeed passed from init to enable, and disable to fini; and across suspend. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 18/19] drm/i915: Complain if hsw_get_pipe_config acquires the same power well twice

2018-12-12 Thread Chris Wilson
As we only release each power well once, we assume that each transcoder maps to a different domain. Complain if this is not so. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH 08/19] drm/i915: Always try to reset the GPU on takeover

2018-12-12 Thread Chris Wilson
When we first introduced the reset to sanitize the GPU on taking over from the BIOS and before returning control to third parties (the BIOS!), we restricted it to only systems utilizing HW contexts as we were uncertain of how stable our reset mechanism truly was. We now have reasonable coverage

[Intel-gfx] [PATCH 17/19] drm/i915/dp: Markup pps lock power well

2018-12-12 Thread Chris Wilson
Track where and when we acquire and release the power well for pps access along the dp aux link, with a view to detecting if we leak any wakerefs. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_dp.c | 231 +--- 1 file changed, 121 insertions(+), 110

[Intel-gfx] [PATCH 10/19] drm/i915: Remove debugfs/i915_ppgtt_info

2018-12-12 Thread Chris Wilson
The information presented here is not relevant to current development. We can either use the context information, but more often we want to inspect the active gpu state. The ulterior motive is to eradicate dev->filelist. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 119

[Intel-gfx] [PATCH 13/19] drm/i915: Syntatic sugar for using intel_runtime_pm

2018-12-12 Thread Chris Wilson
Frequently, we use intel_runtime_pm_get/_put around a small block. Formalise that usage by providing a macro to define such a block with an automatic closure to scope the intel_runtime_pm wakeref to that block, i.e. macro abuse smelling of python. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 03/19] drm/i915/userptr: Probe vma range before gup

2018-12-12 Thread Chris Wilson
We want to exclude any GGTT objects from being present on our internal lists to avoid the deadlock we may run into with our requirement for struct_mutex during invalidate. However, if the gup_fast fails, we put the userptr onto the workqueue and mark it as active, so that we remember to serialise

[Intel-gfx] [PATCH 04/19] drm/i915/selftests: Check we can recover a wedged device

2018-12-12 Thread Chris Wilson
After declaring a terminally wedged device, we allow ourselves to recover on the next GPU reset (manually triggered), or resume. Check that resetting a wedged device does work. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- .../gpu/drm/i915/selftests/intel_hangcheck.c | 23

[Intel-gfx] [PATCH 05/19] drm/i915/selftests: Verify we can perform resets from atomic context

2018-12-12 Thread Chris Wilson
We currently require that our per-engine reset can be called from any context, even hardirq, and in the future wish to perform the device reset without holding struct_mutex (which requires some lockless shenanigans that demand the lowlevel intel_reset_gpu() be able to be used in atomic context).

[Intel-gfx] [PATCH 12/19] drm/i915: Markup paired operations on wakerefs

2018-12-12 Thread Chris Wilson
The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various

[Intel-gfx] [PATCH 09/19] drm/i915: Report the number of closed vma held by each context in debugfs

2018-12-12 Thread Chris Wilson
Include the total size of closed vma when reporting the per_ctx_stats of debugfs/i915_gem_objects. Whilst adjusting the context tracking, note that we can simply use our list of contexts in i915->contexts rather than circumlocute via dev->filelist and the per-file context idr, with the result

[Intel-gfx] [PATCH 01/19] drm/i915: Return immediately if trylock fails for direct-reclaim

2018-12-12 Thread Chris Wilson
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex in the shrinker while performing direct-reclaim. The trade-off being (much) lower latency for non-i915 clients at an increased risk of being unable to obtain a page from direct-reclaim without hitting the oom-notifier. The

[Intel-gfx] [PATCH 16/19] drm/i915: Combined gt.awake/gt.power wakerefs

2018-12-12 Thread Chris Wilson
As the GT_IRQ power domain implies a wakeref, we can use it inplace of our existing redundant rpm grab. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem.c | 11 ---

[Intel-gfx] [PATCH 07/19] drm/i915/icl: Mind the SFC units when resetting VD or VEBox engines

2018-12-12 Thread Chris Wilson
From: Oscar Mateo SFC (Scaler & Format Converter) units are shared between VD and VEBoxes. They also happen to have separate reset bits. So, whenever we want to reset one or more of the media engines, we have to make sure the SFCs do not change owner in the process and, if this owner happens to

[Intel-gfx] [PATCH 06/19] drm/i915/icl: Record the valid VDBoxes with SFC capability

2018-12-12 Thread Chris Wilson
From: Oscar Mateo In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC (Scaler & Format Converter) unit. We will use this information to decide when the SFC units need to be reset. BSpec: 20189 Signed-off-by: Tomasz Lis Signed-off-by: Oscar Mateo Signed-off-by: Michel

[Intel-gfx] A collection of pending bug [fixes]

2018-12-12 Thread Chris Wilson
Hopefully more fixes than bugs, but these have been annoying CI and users for yonks (the ilk-m has been known for a few _years_, but only recently did CI start to pick up on the error and now refuses to run on ilk-m because of it). -Chris ___ Intel-gfx

  1   2   >