>
> >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
On 05/02/2019 19:58, Tony Lindgren wrote:
> * Tomi Valkeinen [190205 11:07]:
>> Yep... So there's the DSI internal code which needs to deal with ulps
>> and disconnect_lanes, and then the external interface to the DSI PLL (so
>> that DPI can use DSI PLL) without ulps/disconnect.
>>
>> I think your
On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard
> wrote:
> >
> > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote:
> > > > >> IIRC, from the previous discu
On Tue, Feb 05, 2019 at 01:44:44PM +0100, Wolfram Sang wrote:
> On Fri, Jan 25, 2019 at 02:11:42PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > If an I2C adapter doesn't match the provided device tree node, also try
> > matching the parent's device tree node. This allows finding
> And there is a regression! Good that I didn't push out before
> double-checking. No one noticed that this breaks registering child
> devices because of_i2c_register_devices() doesn't have a pointer to work
> with anymore?
Well, sorry, I forgot an important detail. There is no regression
because
>
> > >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.
> >
Hi,
On 11/01/2019 05:50, Laurent Pinchart wrote:
> Hello,
>
> This patch series consolidates the three pending series for the omapdrm and
> tfp410 drivers that all together implement drm_bridge and drm_panel support
> for omapdrm.
>
> The series starts with four patches not posted before as part
On Wed, Feb 06, 2019 at 10:16:08AM +0100, Maxime Ripard wrote:
> On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > > On Mon, Feb 4, 201
On Wed, Feb 06, 2019 at 10:49:12AM +0100, Wolfram Sang wrote:
>
> > And there is a regression! Good that I didn't push out before
> > double-checking. No one noticed that this breaks registering child
> > devices because of_i2c_register_devices() doesn't have a pointer to work
> > with anymore?
>
Hi Kishon,
On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote:
> On 05/02/19 2:16 PM, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote:
> >>
> >>
> >> On 21/01/19 9:15 PM, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> Here is a set of
On Tue, Feb 05, 2019 at 07:29:21PM -0800, Kevin Strasser wrote:
> Change the api in order to enable callers that can't supply a valid
> intel_plane pointer, as would be the case prior to calling
> drm_universal_plane_init.
>
> Cc: Uma Shankar
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
> Cc: Davi
On Tue, Feb 05, 2019 at 07:29:22PM -0800, Kevin Strasser wrote:
> 64 bpp half float formats are supported on hdr planes only and are subject
> to the following restrictions:
> * 90/270 rotation not supported
> * Yf Tiling not supported
> * Frame Buffer Compression not supported
> * Color Ke
Kernel DRM driver for ARM Mali 400/450 GPUs.
Since last RFC, all feedback has been addressed. Most Mali DTS
changes are already upstreamed by SoC maintainers. The kernel
driver and user-kernel interface are quite stable for several
months, so I think it's ready to be upstreamed.
This implementati
Signed-off-by: Qiang Yu
---
include/uapi/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0b44260a5ee9..953b59eb3fd2 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #66 from Lefteris Chatzimparmpas ---
While the workaround with power_dpm_force_performance_level/pp_dpm_mclk works
for me, I found another way to stop the flickering, which I mention here in
case it helps debugging.
My monitor has a
Fixes license inconsistent related to the VKMS driver and remove the
redundant boilerplate comment.
Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization")
Cc: sta...@vger.kernel.org
Signed-off-by: Rodrigo Siqueira
---
Changes in V2:
- Add "Cc: sta...@vger.kernel.org" tag
drivers/gpu
Hi Chen-Yu,
On Wed, Feb 06, 2019 at 12:48:21AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jan 30, 2019 at 11:23 AM Chen-Yu Tsai wrote:
> >
> > On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
> > wrote:
> > >
> > > The current calculation for the video start delay in the current DSI
> > > driver
> > >
On Tue, Feb 05, 2019 at 11:16:34PM -0800, Manasi Navare wrote:
> This patch adds appropiate kernel documentation for DRM DP helpers
> used for enabling Display Stream compression functionality in
> drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
> related structure definitions and h
On Wed, Feb 6, 2019 at 10:12 PM Maxime Ripard wrote:
>
> Hi Chen-Yu,
>
> On Wed, Feb 06, 2019 at 12:48:21AM +0800, Chen-Yu Tsai wrote:
> > On Wed, Jan 30, 2019 at 11:23 AM Chen-Yu Tsai wrote:
> > >
> > > On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
> > > wrote:
> > > >
> > > > The current calc
Hi,
Here is a fourth iteration of the VC4 load tracking series, which was
initially developed by Boris Brezillon and that I have now taken over.
This new iteration takes in account comments from v3 and comes with a
new approach for avoiding underrun reports when reconfiguring the
pipeline. It is
From: Boris Brezillon
Add a debugfs entry and helper for reporting HVS underrun errors as
well as helpers for masking and unmasking the underrun interrupts.
Add an IRQ handler and initial IRQ configuration.
Rework related register definitions to take the channel number.
Signed-off-by: Boris Brez
From: Boris Brezillon
The HVS block is supposed to fill the pixelvalve FIFOs fast enough to
meet the requested framerate. The problem is, the HVS and memory bus
bandwidths are limited, and if we don't take these limitations into
account we might end up with HVS underflow errors.
This patch is tr
In order to test whether the load tracker is working as expected, we
need the ability to compare the commit result with the underrun
indication. With the load tracker always enabled, commits that are
expected to trigger an underrun are always rejected, so userspace
cannot get the actual underrun in
When the pipeline is reconfigured with a different mode, changes take
effect immediately for the CRTC and encoder while the HVS takes some
time to switch the active display list. This results in a period of
time where the pipeline is out of sync, that is very likely to cause
an underrun to be repor
On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
>
>
> Den 05.02.2019 17.31, skrev Daniel Vetter:
> > On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 05.02.2019 10.11, skrev Daniel Vetter:
> >>> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trø
On Wed, Feb 06, 2019 at 12:01:16PM -0200, Rodrigo Siqueira wrote:
> Fixes license inconsistent related to the VKMS driver and remove the
> redundant boilerplate comment.
>
> Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization")
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rodrigo Siq
On Mon, Feb 04, 2019 at 07:54:16PM +0100, Sam Ravnborg wrote:
> Hi Daniel
>
> On Mon, Feb 04, 2019 at 11:31:14AM +0100, Daniel Vetter wrote:
> > Noticed why wonder what vboxvideo is using the ->master_set/drop hooks
> > for.
> Can you improve the gammar a little, I find it hard to read.
>
> >
>
On 06/02/2019 18:00, Tony Lindgren wrote:
> OK I'll give it a try. Based on a quick glance, we need to still
> check for enabled regulator to avoid unpaired calls.
>
>> static int dsi_dump_dsi_clocks(struct seq_file *s, void *p)
>> @@ -4108,6 +4094,10 @@ static int dsi_display_init_dsi(struct ds
Hi,
On 06-02-19 16:58, Daniel Vetter wrote:
On Mon, Feb 04, 2019 at 07:54:16PM +0100, Sam Ravnborg wrote:
Hi Daniel
On Mon, Feb 04, 2019 at 11:31:14AM +0100, Daniel Vetter wrote:
Noticed why wonder what vboxvideo is using the ->master_set/drop hooks
for.
Can you improve the gammar a little,
Someone owes me a beer ...
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes mu
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst| 5 +
drivers/gpu/drm
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be matched to two
differe
Den 06.02.2019 16.26, skrev Daniel Vetter:
> On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 05.02.2019 17.31, skrev Daniel Vetter:
>>> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
Den 05.02.2019 10.11, skrev Daniel Vetter:
> On M
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes much more the "assemble a pile
https://bugs.freedesktop.org/show_bug.cgi?id=109554
--- Comment #1 from Rafał Miłecki ---
Created attachment 143319
--> https://bugs.freedesktop.org/attachment.cgi?id=143319&action=edit
Corruption photo
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=107956
--- Comment #5 from Maarten Lankhorst ---
Doing some more investigation. This is expected behavior. So the dmesg-warn in
this case is invalid..
--
You are receiving this mail because:
You are the assignee for the bug.__
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
https://patchwork.kernel.o
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't use
Change the api in order to enable callers that can't supply a valid
intel_plane pointer, as would be the case prior to calling
drm_universal_plane_init.
v4:
- Rename variables and move a declaration (Ville)
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vett
This series defines new formats and adds implementation to the i915 driver.
Since posting v1 I have removed the pixel normalize property, as it's not needed
for basic functionality. Also, I have been working on adding support to
userspace, but we can't land any patches until drm_fourcc.h has been u
Daniel Vetter writes:
>
> Zooming out more looking at the big picture I'd say all your work in the
> past few years has enormously simplified drm for simple drivers already.
> If we can't resolve this one here right now that just means you "only"
> made drm 98% simpler instead of maybe 99%. It's s
Looks like when making the final revision of:
022debad063e ("drm/atomic: Add drm_atomic_state->duplicated")
I forgot to remove some of the comments that I had added to
drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots()
that were no longer valid due to us having removed the sta
From: Ville Syrjälä
The fuzzy drm_calc_{h,v}scale_relaxed() helpers are no longer used.
Throw them in the bin.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 108 -
include/drm/drm_rect.h | 6 ---
2 files changed, 114 deletions(-)
diff
On Wed, Feb 6, 2019 at 1:32 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The fuzzy drm_calc_{h,v}scale_relaxed() helpers are no longer used.
> Throw them in the bin.
>
> Signed-off-by: Ville Syrjälä
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_rect.c | 108 --
Am 06.02.19 um 18:23 schrieb Ard Biesheuvel:
On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel wrote:
On Fri, 25 Jan 2019 at 12:30, Christian König
wrote:
Am 25.01.19 um 09:43 schrieb Ard Biesheuvel:
On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote:
On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuve
On 2019-01-28 12:42, Sean Paul wrote:
From: Sean Paul
Use the drm_mode_vrefresh helper where we need refresh rate in case
vrefresh is empty.
Signed-off-by: Sean Paul
Reviewed-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +++---
drivers/gpu/drm/msm/d
Qiang Yu writes:
> From: Lima Project Developers
>
> Signed-off-by: Andreas Baierl
> Signed-off-by: Erico Nunes
> Signed-off-by: Heiko Stuebner
> Signed-off-by: Marek Vasut
> Signed-off-by: Neil Armstrong
> Signed-off-by: Qiang Yu
> Signed-off-by: Simon Shields
> Signed-off-by: Vasily Kho
Remove the list of broken tests on VKMS solved by patchset
https://patchwork.freedesktop.org/series/55994/
Signed-off-by: Shayenne Moura
---
Documentation/gpu/vkms.rst | 11 ---
1 file changed, 11 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 7d
On Tue, Jan 29, 2019 at 02:10:00PM -0500, Lyude Paul wrote:
> We have a bad habit of calling drm_fb_helper_hotplug_event() far more
> then we actually need to. MST appears to be one of these cases, where we
> call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
> topology in inte
On Tue, Jan 29, 2019 at 02:10:01PM -0500, Lyude Paul wrote:
> This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
> already sends a hotplug on its own from drm_dp_destroy_connector_work()
> after destroying connectors in the MST topology.
>
> Signed-off-by: Lyude Paul
> Cc: Imre Dea
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #13 from Paul Dufresne ---
I am comparing PLL values for a not flickering kernel:
Linux version 3.14.79-031479-generic
and version 4.15 (recent one):
Linux 4.15:
Flickering values
[5.554557] [drm:radeon_compute_pll_avivo [radeon
On 2019-01-28 12:42, Sean Paul wrote:
From: Sean Paul
Instead of setting the timeout and then immediately reading it back
(along with the hand-rolled msecs_to_jiffies calculation), just
calculate it once and set it in both places at the same time.
Signed-off-by: Sean Paul
---
drivers/gpu/drm
Now that we can express our DMA topology, rely on those property instead of
hardcoding an offset from the dma_addr_t which wasn't really great.
We still need to add some code to deal with the old DT that would lack that
property, but we move the offset to the DRM device dma_pfn_offset to be
able t
Some SoCs have devices that are using a separate bus from the main bus to
perform DMA.
These buses might have some restrictions and/or different mapping than from
the CPU side, so we'd need to express those using the usual dma-ranges, but
using a different DT node than the node's parent.
Add supp
The MBUS (and its associated controller) is the bus in the Allwinner SoCs
that DMA devices use in the system to access the memory.
Among other things (and depending on the SoC generation), it can also
enforce priorities or report bandwidth usages on a per-master basis.
One of the most notable thi
The current DT bindings assume that the DMA will be performed by the
devices through their parent DT node, and rely on that assumption for the
address translation using dma-ranges.
However, some SoCs have devices that will perform DMA through another bus,
with separate address translation rules. W
Hi,
We've had for quite some time to hack around in our drivers to take into
account the fact that our DMA accesses are not done through the parent
node, but through another bus with a different mapping than the CPU for the
RAM (0 instead of 0x4000 for most SoCs).
After some discussion after
The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/arm/sunxi/sunxi-
Hi, Dave
Two minor fixes for the previous vmwgfx-next pull:
The following changes since commit 9a01135b98b9d5a7033c544245da7aad0d886758:
drm/vmwgfx: Use the standard atomic helpers for page-flip (2018-12-05
10:09:55 +0100)
are available in the Git repository at:
git://people.freedesktop.o
Old pull message. Please ignore. The correct one coming up.
/Thomas
On Wed, 2019-02-06 at 20:42 +0100, Thomas Hellstrom wrote:
> Hi, Dave
>
> Two minor fixes for the previous vmwgfx-next pull:
>
> The following changes since commit
> 9a01135b98b9d5a7033c544245da7aad0d886758:
>
> drm/vmwgfx
Dave, Daniel
A patch set from Christoph for vmwgfx dma mode detection breakage with the
new dma code restructuring in 5.0
A couple of fixes also CC'd stable
Finally an improved IOMMU detection that automatically enables dma mapping
also with other vIOMMUS than the intel one if present and enable
On 2019-01-28 12:42, Sean Paul wrote:
From: Sean Paul
There exists a bunch of confusion as to what the actual units of
frame_done is:
- The definition states it's in # of frames
- CRTC treats it like it's ms
- frame_done_timeout comment thinks it's Hz, but it stores ms
- frame_done timer is se
On 2019-01-28 12:42, Sean Paul wrote:
From: Sean Paul
In the case of an async/cursor update, we don't wait for the frame_done
event, which means handle_frame_done is never called, and the
frame_done
watchdog isn't canceled. Currently, this results in a frame_done
timeout
every time the curso
The MBUS clock is used by the MBUS controller, so let's export it so that
we can use it in our DT node.
Reviewed-by: Rob Herring
Signed-off-by: Maxime Ripard
---
drivers/clk/sunxi-ng/ccu-sun5i.h | 4
include/dt-bindings/clock/sun5i-ccu.h | 2 +-
2 files changed, 1 insertion(+), 5 dele
The __of_translate_address function is used to translate the device tree
addresses to physical addresses using the various ranges property to create
the offset.
However, it's shared between the CPU addresses (based on the ranges
property) and the DMA addresses (based on dma-ranges). Since we're go
Make the variable have the same type of function hrtimer_forward_now
return.
Add a warn to verify the hrtimer_forward_now return.
Signed-off-by: Shayenne Moura
---
drivers/gpu/drm/vkms/vkms_crtc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_c
On Wed, Feb 06, 2019 at 05:46:51PM +0100, Noralf Trønnes wrote:
>
>
> Den 06.02.2019 16.26, skrev Daniel Vetter:
> > On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 05.02.2019 17.31, skrev Daniel Vetter:
> >>> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trø
On Wed, Feb 06, 2019 at 05:31:57PM -0200, Shayenne Moura wrote:
> Remove the list of broken tests on VKMS solved by patchset
> https://patchwork.freedesktop.org/series/55994/
>
> Signed-off-by: Shayenne Moura
Excellent work from you!
> ---
> Documentation/gpu/vkms.rst | 11 ---
> 1 fil
https://bugs.freedesktop.org/show_bug.cgi?id=109561
Timothy Arceri changed:
What|Removed |Added
Blocks||109535
Referenced Bugs:
https://bugs
On Wed, Feb 6, 2019 at 1:42 PM Maxime Ripard wrote:
>
> Some SoCs have devices that are using a separate bus from the main bus to
> perform DMA.
>
> These buses might have some restrictions and/or different mapping than from
> the CPU side, so we'd need to express those using the usual dma-ranges,
From: Daniel Vetter
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes much mor
From: Daniel Vetter
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst| 5
From: Daniel Vetter
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be
From: Daniel Vetter
Since we need multiple components for I915 for different purposes
(Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
by the previous patch (mentioned below).
Author: Daniel Vetter
Date: Mon Jan 28 17:08:20 2019 +0530
componen
This series enables the HDCP2.2 Type 0 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 d
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
Acked-by: Daniel Vetter
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
1 file changed,
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 [Uma
Header defines the interface for the I915 and MEI_HDCP drivers.
This interface is specific to the usage of mei_hdcp from gen9+
platforms for ME FW based HDCP2.2 services.
And Generic HDCP2.2 protocol specific definitions
are added at drm/drm_hdcp.h.
v2:
Commit msg is enhanced [Daniel]
v3:
i91
"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
Time period for HDCP2.2 link check.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
Reviewed-by: Uma Shankar
---
include/drm/drm_hdcp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 7260b31af276..d4e98b11b4aa 100644
--- a/inclu
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 pa
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.
v2:
Comment is updated. [Daniel]
Reviewed-by Uma.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
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 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 fix
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.
Min
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
Since DP ERRATA message is not defined at spec, those structure
definition is removed from drm_hdcp.h
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Reviewed-by: Uma Shankar
---
include/drm/drm_hdcp.h | 6 --
1 file changed, 6 deletions(-)
diff --git a
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
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 por
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 master
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 80215c312f0e..5f
ME FW 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 commu
From: Tomas Winkler
Add icelake device ids: ICP LP, N and H
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw-me-regs.h | 4
drivers/misc/mei/pci-me.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
index 23739a
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
HDCP transmitter is supposed to indicate the HDCP encryption status of
the link through enc_en signals in a window of time called "window of
opportunity" defined by HDCP HDMI spec.
But on KBL this timing of signalling has an issue. To fix the issue this
WA of resetting the signalling is required.
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 sepa
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 ca
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 rem
Implements the
Waitqueue is created to wait for CP_IRQ
Signaling the CP_IRQ arrival through atomic variable.
For applicable DP HDCP2.2 msgs read wait for CP_IRQ.
As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts
when they are received from HDCP Receivers
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 b/drivers/misc/
1 - 100 of 136 matches
Mail list logo
