On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark wrote:
> Add an atomic helper to implement dirtyfb support. This is needed to
> support DSI command-mode panels with x11 userspace (ie. when we can't
> rely on pageflips to trigger a flush to the panel).
>
> To signal to the driver that the async atomic
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, April 03, 2018 16:57
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
> Usyskin, Alexander
On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
>> On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
>> > Hi!
>> >
>> > [I got to v2 sooner than expected]
>> >
>> > I have an Atmel sama5d31 hooked u
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, April 03, 2018 16:57
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
> Usyskin, Alexander
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
https://bugs.freedesktop.org/show_bug.cgi?id=98520
MirceaKitsune changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=105425
MirceaKitsune changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=98520
--- Comment #43 from MirceaKitsune ---
(In reply to Timothy Arceri from comment #42)
Sorry, I actually forgot about this report. I have a new one with fresh data
and ongoing testing, which I'm trying to get more help with as I don't know
what to
https://bugs.freedesktop.org/show_bug.cgi?id=98520
Timothy Arceri changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Fixes: ca998fc3888e ("misc/mei/hdcp: Notifier chain for mei cldev state change")
Signed-off-by: Fengguang Wu
---
mei_hdcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 2811a25..452e60d 100644
---
On Tue, Mar 27, 2018 at 6:39 PM, Leonard Crestez
wrote:
> When the definition of this struct was removed a forward declaration and an
> unused struct member were still left around. Remove them because they serve
> no purpose.
>
> Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and
> imx
https://bugs.freedesktop.org/show_bug.cgi?id=103276
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Christian König writes:
> Hi Eric,
>
> nice to see that the scheduler gets used more and more.
>
> The feature your need to solve both your binning/rendering as well as
> your MMU problem is dependency handling. See the "dependency" callback
> of the backend operations.
>
> With this callback t
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On Tue, Apr 03, 2018 at 11:38:45PM +0100, Ben Hutchings wrote:
> Commit 62e3a3e342af changed get_pages() to initialise
> msm_gem_object::pages before trying to initialise msm_gem_object::sgt,
> so that put_pages() would properly clean up pages in the failure
> case.
>
> However, this means that pu
Add an atomic helper to implement dirtyfb support. This is needed to
support DSI command-mode panels with x11 userspace (ie. when we can't
rely on pageflips to trigger a flush to the panel).
To signal to the driver that the async atomic update needs to
synchronize with fences, even though the fb
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Hi again,
On Wednesday, 4 April 2018 01:28:29 EEST Laurent Pinchart wrote:
> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> > On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> > > Hi!
> > >
> > > [I got to v2 sooner than expected]
> > >
> > > I have an Atmel sama5d
Hi Daniel,
On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> > Hi!
> >
> > [I got to v2 sooner than expected]
> >
> > I have an Atmel sama5d31 hooked up to an lvds encoder and then
> > on to an lvds panel. Which seems
Hi Peter,
Thank you for the patch.
On Tuesday, 27 March 2018 00:24:43 EEST Peter Rosin wrote:
> Start list of actual chips compatible with "lvds-encoder".
>
> Signed-off-by: Peter Rosin
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/bridge/lvds-transmitter.txt |
Hi Jacopo,
On Tuesday, 27 March 2018 11:16:01 EEST jacopo mondi wrote:
> On Mon, Mar 26, 2018 at 10:03:31PM +0300, Laurent Pinchart wrote:
> > On Sunday, 25 March 2018 15:01:11 EEST Peter Rosin wrote:
> >> On 2018-03-20 14:56, Laurent Pinchart wrote:
> >>> On Sunday, 18 March 2018 00:15:24 EET Pet
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On Fri, Mar 23, 2018 at 12:49:51PM +0530, Sharat Masetty wrote:
> The last level system cache can be partitioned to 32
> different slices of which GPU has two slices preallocated.
> The "gpu" slice is used for caching GPU buffers and
> the "gpuhtw" slice is used for caching the GPU SMMU
> pagetable
On Fri, Mar 23, 2018 at 12:49:50PM +0530, Sharat Masetty wrote:
> Allow different Adreno targets the ability to pass
> specific mmu features to the generic layers. This will
> help conditionally configure certain iommu features for
> certain Adreno targets.
>
> Also Add a few simple support functi
On Fri, Mar 23, 2018 at 12:49:49PM +0530, Sharat Masetty wrote:
> Add the registers needed for configuring the system cache slice info and
> other parameters in the GPU.
>
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4
> 1 fi
On Fri, Mar 23, 2018 at 12:49:48PM +0530, Sharat Masetty wrote:
> Add client side bindings required for the GPU to use the last level
> system cache. Also add a register range in the GPU CX domain.
Reviewed-by: Jordan Crouse
Also, these should go the the devicetree lists for review (but maybe wa
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On Fri, Mar 23, 2018 at 12:49:47PM +0530, Sharat Masetty wrote:
> The register read-modify-write construct is generic enough
> that it can be used by other subsystems as needed, create
> a more generic rmw() function and have the gpu_rmw() use
> this new function.
Reviewed-by: Jordan Crouse
> S
On Mon, Feb 26, 2018 at 01:08:23PM +0530, Sharat Masetty wrote:
> This patch simply increases the number of available ringbuffers,
> therefore enabling preemption.
>
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> 1 file chang
On Mon, Feb 26, 2018 at 01:08:22PM +0530, Sharat Masetty wrote:
> This patch implements preemption feature for A6xx targets, this allows
> the GPU to switch to a higher priority ringbuffer if one is ready. A6XX
> hardware as such supports multiple levels of preemption granularities,
> ranging from
On Mon, Feb 26, 2018 at 01:08:21PM +0530, Sharat Masetty wrote:
> This patch adds the following two opcodes:
>
> CP_SET_MARKER opcode is a way to tell CP the current mode of GPU
> operation(useful if preemption is in use).
>
> CP_SET_PSEUDO_REG opcode will instruct CP to set a bunch of internal
>
On Mon, Feb 26, 2018 at 01:08:20PM +0530, Sharat Masetty wrote:
> This patch adds a bit of infrastructure to give the different Adreno
> targets the flexibility to setup the submitqueues per their needs.
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Hi Peter,
Thank you for the patch.
On Thursday, 22 March 2018 15:42:06 EEST Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a pr
https://bugs.freedesktop.org/show_bug.cgi?id=105869
Vedran Miletić changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
https://bugs.
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Vedran Miletić changed:
What|Removed |Added
Depends on||105869
Referenced Bugs:
https://bugs.
https://bugs.freedesktop.org/show_bug.cgi?id=105869
Bug ID: 105869
Summary: clang crashes when compiling OpenCL kernel
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
Hi Peter,
On Friday, 23 March 2018 10:31:53 EEST Peter Ujfalusi wrote:
> On 2018-03-22 15:42, Peter Ujfalusi wrote:
> > From: Tomi Valkeinen
> >
> > Define unique compatible string for the DMM in DRA7xx family.
> >
> > The new compatible can be used to apply DRA7xx specific workarounds for
> >
Hi Peter,
Thank you for the patch.
On Thursday, 22 March 2018 15:42:05 EEST Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Define unique compatible string for the DMM in DRA7xx family.
>
> The new compatible can be used to apply DRA7xx specific workarounds for
> ERRATAs, like i878 (MPU Locku
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Berillions (berilli...@gmail.com) changed:
What|Removed |Added
CC||berilli...@gmail.com
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On Tue, Apr 3, 2018 at 8:53 PM, Laurent Pinchart
wrote:
> Hello Emre,
>
> Thank you for the patch.
>
> On Tuesday, 3 April 2018 12:14:33 EEST Emre Ucan wrote:
>> We have to check dma-buf reservation objects
>> of our framebuffers before we use them.
>> Otherwise, another driver might be writing
>>
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180403]
[cannot apply to v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
On Tue, Apr 03, 2018 at 11:15:13AM +0100, Liviu Dudau wrote:
> Hi Daniel,
>
> On Tue, Apr 03, 2018 at 11:58:17AM +0200, Daniel Vetter wrote:
> > On Thu, Mar 29, 2018 at 11:15:50AM +1000, Dave Airlie wrote:
> > > Hi Linus,
> > >
> > > This is the main drm pull request for 4.17-rc1.
> > >
> > > I'm
Hello Emre,
Thank you for the patch.
On Tuesday, 3 April 2018 12:14:33 EEST Emre Ucan wrote:
> We have to check dma-buf reservation objects
> of our framebuffers before we use them.
> Otherwise, another driver might be writing
> on the same buffer which we are using.
> This would cause visible te
On Tue, Apr 03, 2018 at 01:06:45PM -0400, Jerome Glisse wrote:
> On Tue, Apr 03, 2018 at 11:09:09AM +0200, Daniel Vetter wrote:
> > On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote:
> > > Am 29.03.2018 um 08:57 schrieb Daniel Vetter:
> > > > On Sun, Mar 25, 2018 at 12:59:56PM +0200,
On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake wrote:
> On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote:
>>> It seems that we are not alone seeing amdgpu-induced stability
>>> problems on multiple Raven Ridge platforms.
>>> https://www.phoronix.com/scan.php?page=news_item&px=AMD-Raven-Ridge-M
On 29 March 2018 at 12:17, Laszlo Ersek wrote:
> On 03/28/18 16:35, Emil Velikov wrote:
>> On 28 March 2018 at 11:27, Laszlo Ersek wrote:
>>> On 03/28/18 03:24, Emil Velikov wrote:
>
Gents, can someone double-check this please? Just in case.
>>>
>>> I guess I should test whether this series
On Tue, Apr 03, 2018 at 11:09:09AM +0200, Daniel Vetter wrote:
> On Thu, Mar 29, 2018 at 01:34:24PM +0200, Christian König wrote:
> > Am 29.03.2018 um 08:57 schrieb Daniel Vetter:
> > > On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote:
> > > > Add a peer2peer flag noting that the imp
On Tue, Apr 03, 2018 at 05:02:35PM +0200, Daniel Vetter wrote:
> On Tue, Apr 03, 2018 at 05:06:03PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote:
> > > On 2018-04-03 03:39 PM, Ilia Mirkin wrote:
> > > > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer
On Tue, Apr 03, 2018 at 07:27:49PM +0530, Ramalingam C wrote:
> Implements a interface for single burst read of data that is larger
> than 512 Bytes through gmbus.
>
> HDCP2.2 spec expects HDCP2.2 transmitter to read 522Bytes of HDCP
> receiver certificates in single burst read. On gmbus, to read
On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard wrote:
> 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 in
On Monday, 2018-03-26 15:00:01 +0100, Emil Velikov wrote:
> On 26 March 2018 at 14:57, Jani Nikula wrote:
> > On Mon, 26 Mar 2018, Eric Engestrom wrote:
> >> Signed-off-by: Eric Engestrom
> >> ---
> >> xf86drm.c | 28 ++--
> >> 1 file changed, 14 insertions(+), 14 deleti
https://bugs.freedesktop.org/show_bug.cgi?id=102885
--- Comment #13 from Thomas J. Moore ---
(In reply to Timothy Arceri from comment #11)
> Deleting the trace means no one else can investigate the bug. Is this still
> a problem?
I assumed Samuel Pitoiset already figured out what the problem was
On Tue, Apr 03, 2018 at 07:27:18PM +0530, Ramalingam C wrote:
> 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:
> Notif
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #26 from Matt Arsenault ---
Can you attach the temp dumps with/without the vectorizer enabled?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailin
On 28 March 2018 at 17:22, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently the error pointer returned by msm_alloc_stolen_fb gets passed
> to drm_framebuffer_remove. The latter handles only NULL pointers, thus
> a nasty crash will occur.
>
> Drop the unnecessary fail label and the associat
On Tue, Apr 03, 2018 at 07:48:29AM -0700, Matthew Wilcox wrote:
> On Tue, Apr 03, 2018 at 03:12:35PM +0200, Thomas Hellstrom wrote:
> > I think the TTM page fault handler originally set the standard for this.
> > First, IMO any critical section that waits for the GPU (like typically the
> > page fa
On 2018-04-03 04:06 PM, Ville Syrjälä wrote:
> On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote:
>> On 2018-04-03 03:39 PM, Ilia Mirkin wrote:
>>> On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote:
On 2018-04-03 03:26 PM, Ilia Mirkin wrote:
> On Tue, Apr 3, 2018 at 5:29 AM,
On Tue, Apr 03, 2018 at 05:06:03PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote:
> > On 2018-04-03 03:39 PM, Ilia Mirkin wrote:
> > > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote:
> > >> On 2018-04-03 03:26 PM, Ilia Mirkin wrote:
> > >>> On Tue
On Tue, Apr 03, 2018 at 03:29:18PM +0200, Maxime Ripard wrote:
> 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
> prope
On Tue, Apr 3, 2018 at 3:23 PM, Jani Nikula wrote:
> On Tue, 03 Apr 2018, Lucas Stach wrote:
>> My _feeling_ is that the review economy in drm-misc, which gets DRM the
>> bragging rights of 80% reviewed patches, has already lowered the weight
>> associated with those reviews, as most of them are
Implements a interface for single burst read of data that is larger
than 512 Bytes through gmbus.
HDCP2.2 spec expects HDCP2.2 transmitter to read 522Bytes of HDCP
receiver certificates in single burst read. On gmbus, to read more
than 511Bytes, HW provides a workaround for burst read.
This patch
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdcp.c
On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote:
> On 2018-04-03 03:39 PM, Ilia Mirkin wrote:
> > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer wrote:
> >> On 2018-04-03 03:26 PM, Ilia Mirkin wrote:
> >>> On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter wrote:
> On Sun, Apr 01, 20
Implements the HDMI adapatation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 203 ++
1 fi
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,
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
d
HDCP check link is invoked only on CP_IRQ detection, instead of all
short pulses.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/dr
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.
Signed-off-by: Ramalingam C
---
drivers/
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 11 +++
1 file changed, 7 i
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/int
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 135 ++
1 file chan
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone with out disabling the hdcp
encryption. If that fails then complete reauthentication is executed.
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 38
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 a sequence of enabling and disabling the HDCP2.2
(auth and encryption).
v2:
Rebased.
v3:
No Changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/i915
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 54 +++
1 file chan
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key enchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type confuguration for receivers.
At AKE, the HDCP Receiver’s public key certif
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 32
1 file changed, 32 insertions(+)
diff --git a/dri
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
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
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 ot ME to verify the downatream 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 par
Request to ME to configure a port as authenticated.
On Success, ME FW will mark th eport as authenticated and provides
HDCP chiper of the port with the encryption keys.
Enabling the Authentication can be requested once the all
stages of HDCP2.2 authentication is completed by interating with
ME FW
Considering the upcoming significant no HDCP2.2 variables, it will
be clean to have separate struct fo HDCP.
New structure called intel_hdcp is introduced.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
No Changes.
Sign
Adds the wrapper for all mei hdcp2.2 service functions.
v2:
Rebased.
v3:
cldev is moved from mei_hdcp_data to hdcp.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 194 ++
1 file changed, 194 insertions(+)
diff --git a/drivers/gpu/drm
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
Request to ME to prepare the encrypted session key.
On Success, ME provides Encrypted session key. Functions 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]
Signed-off-by: Ram
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
Requests for the verifcation of AKE_Send_H_prime.
ME will calculation the H and comparing it with received H_Prime.
Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
v2:
Rebased.
v3:
cldev is passed as first parameter [Tomas]
Redundant comments and cast are removed [Tomas]
Signed-off-
Request ME FW to start the HDCP2.2 session for a intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent
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
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]
Signed-off-by: Ramalingam
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
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
v3:
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/mei/bus-fixup.c
inde
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]
Signed-off-by: Ramalingam C
---
include/linux/mei_hdcp.h | 70
1 file changed, 70 insertions(+)
dif
1 - 100 of 208 matches
Mail list logo
