On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote:
> 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 f
On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
>
>
> On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
> > On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
> > > Initialize HDCP2.2 support. This includes the mei interface
> > > initialization along with required n
On 05/29/2018 01:45 PM, Jani Nikula wrote:
On Wed, 30 May 2018, Colin Xu wrote:
On 05/28/2018 09:42 PM, Jani Nikula wrote:
On Mon, 28 May 2018, Jani Nikula wrote:
On Mon, 28 May 2018, Jani Nikula wrote:
On Tue, 29 May 2018, colin...@intel.com wrote:
From: Colin Xu
The existing way to u
On Wed, 30 May 2018, Colin Xu wrote:
> On 05/28/2018 09:42 PM, Jani Nikula wrote:
>> On Mon, 28 May 2018, Jani Nikula wrote:
>>> On Mon, 28 May 2018, Jani Nikula wrote:
On Tue, 29 May 2018, colin...@intel.com wrote:
> From: Colin Xu
>
> The existing way to update virtual PCH wi
On 05/28/2018 09:42 PM, Jani Nikula wrote:
On Mon, 28 May 2018, Jani Nikula wrote:
On Mon, 28 May 2018, Jani Nikula wrote:
On Tue, 29 May 2018, colin...@intel.com wrote:
From: Colin Xu
The existing way to update virtual PCH will return wrong PCH type
in case the host doesn't have PCH:
-
== Series Details ==
Series: drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
URL : https://patchwork.freedesktop.org/series/43865/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4249 -> Patchwork_9135 =
== Summary - FAILURE ==
Serious unknown changes coming with P
SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
those events are now handled by intel_guc_to_host_event_handler_mmio().
We should not try to read it on MMIO action error as 1) we may be using
different set of registers for GuC MMIO communication, and 2) GuC may
use CTB mech
== Series Details ==
Series: drm/i915: Fix incorrect virtual PCH_NONE/PCH_NOP assignment (rev2)
URL : https://patchwork.freedesktop.org/series/43833/
State : failure
== Summary ==
Applying: drm/i915: Update virtual PCH in single function
Applying: drm/i915: Assign PCH_NONE for BXT in virtualiz
On Mon, 28 May 2018, Jani Nikula wrote:
> On Mon, 28 May 2018, Jani Nikula wrote:
>> On Tue, 29 May 2018, colin...@intel.com wrote:
>>> From: Colin Xu
>>>
>>> The existing way to update virtual PCH will return wrong PCH type
>>> in case the host doesn't have PCH:
>>> - intel_virt_detect_pch re
Den 24.05.2018 10.42, skrev Daniel Vetter:
On Wed, May 23, 2018 at 04:34:06PM +0200, Noralf Trønnes wrote:
This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.
Only GEM drivers are supported.
The original idea of using an exported
On Mon, 28 May 2018, Jani Nikula wrote:
> On Tue, 29 May 2018, colin...@intel.com wrote:
>> From: Colin Xu
>>
>> The existing way to update virtual PCH will return wrong PCH type
>> in case the host doesn't have PCH:
>> - intel_virt_detect_pch returns guessed PCH id 0
>> - id 0 maps to PCH_NO
On Tue, 29 May 2018, colin...@intel.com wrote:
> From: Colin Xu
>
> The existing way to update virtual PCH will return wrong PCH type
> in case the host doesn't have PCH:
> - intel_virt_detect_pch returns guessed PCH id 0
> - id 0 maps to PCH_NOP. >> should be PCH_NONE.
> Since PCH_NONE and PC
12 matches
Mail list logo