Quoting Zhenyu Wang (2018-05-21 04:44:34)
> On 2018.05.18 11:22:06 +0100, Chris Wilson wrote:
> > Quoting Zhenyu Wang (2018-05-18 11:13:05)
> > > When we do shadowing, workload's request might not be allocated yet,
> > > so we still require shadow context's object. And when complete workload,
> > >
If we can use an unmappable ring, try to pin it out of the mappable
aperture. This simple layout preference is to try and keep the mappable
aperture reserved and available to handle GGTT mmapping requests from
userspace without causing evictions and GPU stalls.
Signed-off-by: Chris Wilson
Cc: Joo
To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
times), doing a search by address over a pathologically fragmented
address space is exceeding slow. To protect ourselves from nearly
unbounded latency (think searching a million holes while under
struct_mutex), limit the search
As we keep an rbtree of available holes sorted by their size, we can
very easily determine if there is any hole large enough that might
satisfy the allocation request. This helps when dealing with a highly
fragmented address space and a request for a search by address.
To cache the largest size, w
Searching for an available hole by address is slow, as there no
guarantee that a hole will be available and so we must walk over all
nodes in the rbtree before we determine the search was futile. In many
cases, the caller doesn't strictly care for the highest available hole
and was just opportunist
When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.
v2: Move request alloc earlier as already try to track shadow status
depending
== Series Details ==
Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL : https://patchwork.freedesktop.org/series/43406/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4eec44c20bac drm/i915/gvt: Fix crash after request->hw_context change
-:8: WARNING:CO
On Friday 18 May 2018 06:19 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-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
On Friday 18 May 2018 09:29 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
Hi Sean,
On 18/05/2018 17:48, Sean Paul wrote:
> On Fri, May 18, 2018 at 03:05:00PM +0200, Neil Armstrong wrote:
>> 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 fun
== Series Details ==
Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL : https://patchwork.freedesktop.org/series/43406/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4211 -> Patchwork_9062 =
== Summary - SUCCESS ==
No regressions found.
Exte
Hi Ville,
On 18/05/2018 15:24, Ville Syrjälä wrote:
> On Fri, May 18, 2018 at 03:05:01PM +0200, Neil Armstrong wrote:
>> 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.
>> T
On Friday 18 May 2018 09:45 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
Hi Enric,
On 18/05/2018 18:19, Enric Balletbo Serra wrote:
> Hi Neil,
>
> 2018-05-18 15:05 GMT+02:00 Neil Armstrong :
>> 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
Hi Enric,
On 18/05/2018 17:02, Enric Balletbo Serra wrote:
> Hi Neil,
>
> 2018-05-18 15:05 GMT+02:00 Neil Armstrong :
>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
>
> A minor nit, there is a "consensus" on tell cros-ec as "ChromeOS
> Embedded Controller" or "Chro
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 communicate
>> with it and get
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-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
== Series Details ==
Series: series starting with [v2,1/4] drm/mm: Reject over-sized allocation
requests early
URL : https://patchwork.freedesktop.org/series/43497/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b023636132bb drm/mm: Reject over-sized allocation requests early
e
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-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chromiu
== Series Details ==
Series: series starting with [v2,1/4] drm/mm: Reject over-sized allocation
requests early
URL : https://patchwork.freedesktop.org/series/43497/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4211 -> Patchwork_9063 =
== Summary - WARNING ==
Minor unkn
== Series Details ==
Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL : https://patchwork.freedesktop.org/series/43406/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4211_full -> Patchwork_9062_full =
== Summary - WARNING ==
Minor unknown chang
Quoting Zhenyu Wang (2018-05-21 09:17:52)
> When we do shadowing, workload's request might not be allocated yet,
> so we still require shadow context's object. And when complete workload,
> delay to zero workload's request pointer after used for update guest context.
>
> v2: Move request alloc ear
Quoting Chris Wilson (2018-05-21 10:54:57)
> Quoting Zhenyu Wang (2018-05-21 09:17:52)
> > When we do shadowing, workload's request might not be allocated yet,
> > so we still require shadow context's object. And when complete workload,
> > delay to zero workload's request pointer after used for up
On 2018-05-18 23:08, Daniele Ceraolo Spurio wrote:
On 11/05/18 08:45, Tomasz Lis wrote:
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result
from
Context Status Buffer.
Preemption in previous gens re
== Series Details ==
Series: series starting with [v2,1/4] drm/mm: Reject over-sized allocation
requests early
URL : https://patchwork.freedesktop.org/series/43497/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4211_full -> Patchwork_9063_full =
== Summary - WARNING ==
From: "Kumar, Mahesh"
This patch implements new DDB allocation algorithm as per HW team
recommendation. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level f
On Gen8+ this register is not priviledged and we want to use it in
Mesa to implement a feature required by GPA called Null Hardware. The
idea is to have the command parser turn 3DPRIMITIVE/GPGPU_WALKER into
NOOPs.
This patch just whitelists the bits that we need and that are
currently not used by
All connectors may not have best_encoder attached, so don't dereference
encoder pointer for each connector.
Fixes: c27e917e2bda (drm/i915/icl: add basic support for the ICL clocks)
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_ddi.c | 6 --
1 file changed, 4 insertions(+), 2 del
On Thu, May 17, 2018 at 10:40 AM, Souptick Joarder wrote:
> On Thu, May 17, 2018 at 12:48 AM, Chris Wilson
> wrote:
>> Quoting Souptick Joarder (2018-05-16 20:12:20)
>>> Use new return type vm_fault_t for fault handler. For
>>> now, this is just documenting that the function returns
>>> a VM_FAU
== Series Details ==
Series: drm/i915/skl+: ddb allocation algorithm optimization
URL : https://patchwork.freedesktop.org/series/43508/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
73a56949d33f drm/i915/skl+: ddb allocation algorithm optimization
-:51: CHECK:LOGICAL_CONTINUATI
== Series Details ==
Series: drm/i915/skl+: ddb allocation algorithm optimization
URL : https://patchwork.freedesktop.org/series/43508/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/skl+: ddb allocation algorithm optimization
-drivers/gpu/drm/i915/i915_drv.h:159:19
== Series Details ==
Series: drm/i915/skl+: ddb allocation algorithm optimization
URL : https://patchwork.freedesktop.org/series/43508/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4212 -> Patchwork_9064 =
== Summary - FAILURE ==
Serious unknown changes coming with Patc
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" wrote:
+/*
== Series Details ==
Series: drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
(rev3)
URL : https://patchwork.freedesktop.org/series/43420/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4212 -> Patchwork_9065 =
== Summary - FAILURE ==
Serious unknown
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 ca
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
---
include/drm
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]
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 fu
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 --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/me
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 co
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 se
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 ++
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: Rama
Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.
On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else AKE_No
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 an
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
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
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_
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 parame
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 r
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 comple
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:
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 t
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 com
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 r
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
1 file
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 certif
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 ++
1 fil
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 H
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 [Uma]
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
---
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 insertions(+)
diff --git a/dr
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
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
---
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
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
---
drivers/gpu/drm/i915/intel_h
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
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu
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 changed, 3 insertions(+), 1 deletion(-)
diff -
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 that,
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 f
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
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
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
---
drivers/gpu/drm/i915/intel_dp.c | 9 -
1 file chang
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]
%s/PARING/P
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
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 f
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
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
driver
== Series Details ==
Series: drm/i915/icl: fix icl_unmap/map_plls_to_ports
URL : https://patchwork.freedesktop.org/series/43510/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4212 -> Patchwork_9066 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev5)
URL : https://patchwork.freedesktop.org/series/38254/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5534d5c8130b drm: hdcp2.2 authentication msg definitions
e1983dd17552 drm: HDMI and DP specific HDCP2.2 defines
05
On 15/05/18 10:05, Tvrtko Ursulin wrote:
On 14/05/2018 16:56, Lionel Landwerlin wrote:
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within t
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev5)
URL : https://patchwork.freedesktop.org/series/38254/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: hdcp2.2 authentication msg definitions
Okay!
Commit: drm: HDMI and DP specific HDCP2.2 defines
Okay!
Co
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev5)
URL : https://patchwork.freedesktop.org/series/38254/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4212 -> Patchwork_9067 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9067 absolut
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
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 lea
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
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 changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev
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 reg
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.
Signed-off-
== Series Details ==
Series: drm/i915/icl: fix icl_unmap/map_plls_to_ports
URL : https://patchwork.freedesktop.org/series/43510/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4212 -> Patchwork_9068 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_906
== Series Details ==
Series: drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
(rev3)
URL : https://patchwork.freedesktop.org/series/43420/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4212 -> Patchwork_9069 =
== Summary - WARNING ==
Minor unknown c
== Series Details ==
Series: drm/i915/skl+: ddb allocation algorithm optimization
URL : https://patchwork.freedesktop.org/series/43508/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4212 -> Patchwork_9070 =
== Summary - WARNING ==
Minor unknown changes coming with Patchw
== Series Details ==
Series: Add ChromeOS EC CEC Support (rev5)
URL : https://patchwork.freedesktop.org/series/43162/
State : failure
== Summary ==
Applying: media: cec-notifier: Get notifier by device and connector name
Applying: drm/i915: hdmi: add CEC notifier to intel_hdmi
Applying: mfd: c
On Monday 21 May 2018 06:53 PM, Patchwork wrote:
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev5)
URL : https://patchwork.freedesktop.org/series/38254/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: hdcp2.2 authentication msg definitions
Okay!
Commit
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Monday, May 21, 2018 8:34 PM
>To: intel-gfx@lists.freedesktop.org; Patchwork
>; lkp ; Jani Nikula
>
>Subject: Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Imple
== Series Details ==
Series: drm/i915/icl: fix icl_unmap/map_plls_to_ports
URL : https://patchwork.freedesktop.org/series/43510/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4212_full -> Patchwork_9068_full =
== Summary - WARNING ==
Minor unknown changes coming with Pat
On 21/05/2018 14:22, Lionel Landwerlin wrote:
On 15/05/18 10:05, Tvrtko Ursulin wrote:
On 14/05/2018 16:56, Lionel Landwerlin wrote:
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
On 21/05/18 17:00, Tvrtko Ursulin wrote:
On 21/05/2018 14:22, Lionel Landwerlin wrote:
On 15/05/18 10:05, Tvrtko Ursulin wrote:
On 14/05/2018 16:56, Lionel Landwerlin wrote:
From: Chris Wilson
We want to allow userspace to reconfigure the subslice
configuration for
its own use case. To d
== Series Details ==
Series: drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
(rev3)
URL : https://patchwork.freedesktop.org/series/43420/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4212_full -> Patchwork_9069_full =
== Summary - WARNING ==
Minor
== Series Details ==
Series: drm/i915/skl+: ddb allocation algorithm optimization
URL : https://patchwork.freedesktop.org/series/43508/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4212_full -> Patchwork_9070_full =
== Summary - WARNING ==
Minor unknown changes coming w
Em Sex, 2018-05-18 às 13:15 -0700, José Roberto de Souza escreveu:
> 'Pipe CSC enable' bit is more than just deprecated in ICL+, it was
> disabled in 077ef1f09c25 'drm/i915/icl: Don't set pipe CSC/Gamma in
> PLANE_COLOR_CTL' for primary and sprite planes as it was causing
> those planes to be rende
From: Ville Syrjälä
Set up the SKL+ scaler initial phase registers correctly. Otherwise
we start fetching the data from the center of the first pixel instead
of the top-left corner, which obviously then leads to right/bottom edges
replicating data excessively as the data runs out half a pixel too
1 - 100 of 143 matches
Mail list logo
