On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:
> "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
On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> +void component_match_add_typed(struct device *master,
> + struct component_match **matchptr,
> + int (*compare_typed)(struct device *, int, void *), void *compare_data)
> +{
> + __component_match_add(master, matchptr,
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
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
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
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
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
Implement the required WA sequence for KBL to fix the
incorrect positioning of the window of oppurtunity and enc_en
signalling.
v2:
WA is moved into the toggle_signalling [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 42 +++
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
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
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
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
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
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_t
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
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 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
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
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
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
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.
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
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
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
---
include/drm/drm_hdcp.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
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
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
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
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
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
"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
---
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/include/drm/drm_hdcp.h
+++
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]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
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
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:
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
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
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
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
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
---
drivers/gpu/drm/i915/intel_hdcp.c | 118 +++---
1 file changed, 59 insertions(+), 59
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #9 from Clément Guérin (li...@protonmail.com) ---
I just tested built `drm-next-5.1-wip` (8054c54a6), it's flickering/stuttering
as well.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #8 from Clément Guérin (li...@protonmail.com) ---
Strange. It looks like this commit has been merged in the mainline kernel
before rc1.
https://bugs.freedesktop.org/show_bug.cgi?id=108487
--- Comment #13 from Daniel Stone ---
A Weston patch is available here, but needs testing:
https://gitlab.freedesktop.org/wayland/weston/merge_requests/92
--
You are receiving this mail because:
You are the assignee for the
On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > Some display controllers can be programmed to present non-black colors
> > for pixels not covered by any plane (or pixels covered by the
> > transparent regions of
For the series
Reviewed-by: Deepak Rawat
On Tue, 2019-01-29 at 14:35 +0100, Thomas Hellstrom wrote:
> Previously we set only the dma mask and not the coherent mask. Fix
> that.
> Also, for clarity, make sure both are initially set to 64 bits.
>
> Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the
On Wed, Jan 30, 2019 at 09:57:10PM +0100, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> > On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> > > Previous patch series was here:
> > >
> > >
On Wed, Jan 30, 2019 at 10:51:55PM +, Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 05:47:05PM -0500, Jerome Glisse wrote:
> > On Wed, Jan 30, 2019 at 10:33:04PM +, Jason Gunthorpe wrote:
> > > On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote:
> > >
> > > > > What is the
On Wed, Jan 30, 2019 at 10:33:04PM +, Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote:
>
> > > What is the problem in the HMM mirror that it needs this restriction?
> >
> > No restriction at all here. I think i just wasn't understood.
>
> Are you are
On Wed, Jan 30, 2019 at 09:56:07PM +, Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 04:45:25PM -0500, Jerome Glisse wrote:
> > On Wed, Jan 30, 2019 at 08:50:00PM +, Jason Gunthorpe wrote:
> > > On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote:
> > > > On Wed, Jan 30, 2019
On Wed, Jan 30, 2019 at 08:50:00PM +, Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote:
> > On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote:
> > > On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote:
> > >
> > > > We never
On Wed, Jan 30, 2019 at 05:13:13PM +, Kazlauskas, Nicholas wrote:
> On 1/30/19 11:30 AM, Daniel Vetter wrote:
> > .. next to all the other sink helpers. The rect library is more used
> > for handling plane clipping, so belongs to those imo.
> >
> > Signed-off-by: Daniel Vetter
>
>
On Wed, Jan 30, 2019 at 09:04:23PM +, Kazlauskas, Nicholas wrote:
> On 1/30/19 4:02 PM, Daniel Vetter wrote:
> > On Wed, Jan 30, 2019 at 05:33:00PM +, Kazlauskas, Nicholas wrote:
> >> On 1/30/19 11:30 AM, Daniel Vetter wrote:
> >>> It only talks about crtc, brings up intel as an exampel
On Wed, Jan 30, 2019 at 10:51:22AM -0800, Matt Roper wrote:
> Gen9+ platforms allow CRTC's to be programmed with a background/canvas
> color below the programmable planes. Let's expose this for use by
> compositors.
>
> v2:
> - Split out bgcolor sanitization and programming of csc/gamma bits to
On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes). Compositors that want a UI with
> a solid color background
On Wed, Jan 30, 2019 at 05:33:00PM +, Kazlauskas, Nicholas wrote:
> On 1/30/19 11:30 AM, Daniel Vetter wrote:
> > It only talks about crtc, brings up intel as an exampel and I think is
>
> nit: Should be "example".
Will fix when applying.
> > more misleading than useful really. Plus we have
On 1/30/19 4:02 PM, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 05:33:00PM +, Kazlauskas, Nicholas wrote:
>> On 1/30/19 11:30 AM, Daniel Vetter wrote:
>>> It only talks about crtc, brings up intel as an exampel and I think is
>>
>> nit: Should be "example".
>
> Will fix when applying.
>
On Wed, Jan 30, 2019 at 10:51:20AM -0800, Matt Roper wrote:
> We don't yet allow userspace to control the CRTC background color, but
> we should manually program the color to black to ensure the BIOS didn't
> leave us with some other color. We should also set the pipe gamma and
> pipe CSC bits so
On Wed, Jan 30, 2019 at 10:56:26AM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> > Previous patch series was here:
> > https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
> >
> > I'm told the ChromeOS userspace code to make use
On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote:
>
> > We never changed SGLs. We still use them to pass p2pdma pages, only we
> > need to be a bit careful where we send the entire SGL. I see no reason
> > why we
On Wed, Jan 30, 2019 at 12:52:44PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-30 12:22 p.m., Jerome Glisse wrote:
> > On Wed, Jan 30, 2019 at 06:56:59PM +, Jason Gunthorpe wrote:
> >> On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote:
> >>>
> >>>
> >>> On 2019-01-29 9:18
https://bugzilla.kernel.org/show_bug.cgi?id=202449
--- Comment #8 from Haxk20 (haxk...@gmail.com) ---
Also is there any way i can test if variable refresh rate is working on linux
right now ?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=202449
--- Comment #7 from Haxk20 (haxk...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #5)
> Created attachment 280873 [details]
> 0001-drm-amd-display-Attach-VRR-properties-for-eDP-connec.patch
>
> I'm not sure if this will actually
https://bugzilla.kernel.org/show_bug.cgi?id=202449
--- Comment #6 from Haxk20 (haxk...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #5)
> Created attachment 280873 [details]
> 0001-drm-amd-display-Attach-VRR-properties-for-eDP-connec.patch
>
> I'm not sure if this will actually
Hi,
On 1/30/19 11:55 AM, Thomas Hellstrom wrote:
Dave, Daniel
A fix for a DMA API change from Christoph Hellwig for vmwgfx, and
Two stable fixes for regressions in the vmwgfx driver
The following changes since commit f0e7ce1eef5854584dfb59b3824a67edee37580f:
Merge tag
On Wed, Jan 30, 2019 at 06:56:59PM +, Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote:
> >
> >
> > On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote:
> > > Every attempt to give BAR memory to struct page has run into major
> > > trouble, IMHO, so I like
On Wed, Jan 30, 2019 at 10:51:19AM -0800, Matt Roper wrote:
> Previous patch series was here:
> https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
>
> I'm told the ChromeOS userspace code to make use of the background color
> has been reviewed and is ready for use:
> *
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready
Previous patch series was here:
https://lists.freedesktop.org/archives/dri-devel/2018-December/201949.html
I'm told the ChromeOS userspace code to make use of the background color
has been reviewed and is ready for use:
* https://chromium-review.googlesource.com/c/chromium/src/+/1278858
*
We don't yet allow userspace to control the CRTC background color, but
we should manually program the color to black to ensure the BIOS didn't
leave us with some other color. We should also set the pipe gamma and
pipe CSC bits so that the background color goes through the same color
management
On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote:
> > I don't see why a special case with a VMA is really that different.
>
> Well one *really* big difference is the VMA changes necessarily expose
> specialized new
On Wed, Jan 30, 2019 at 01:06:57PM -0500, Sean Paul wrote:
> On Wed, Jan 30, 2019 at 12:06:45PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 19, 2018 at 7:54 PM Daniel Vetter wrote:
> > >
> > > On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> > > > This patch adds inline functions
On Wed, Jan 30, 2019 at 12:06:45PM +0100, Daniel Vetter wrote:
> On Wed, Dec 19, 2018 at 7:54 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> > > This patch adds inline functions and helpers for obtaining
> > > DP sink's supported DSC parameters
On Wed, Jan 30, 2019 at 03:53:04PM +, Brian Starkey wrote:
> Hi Russell,
>
> On Fri, Jan 25, 2019 at 09:43:29AM +, Russell King wrote:
> > CEA-861 says: "A Source shall not send a non-zero Q value that does
> > not correspond to the default RGB Quantization Range for the
> > transmitted
On Wed, Jan 30, 2019 at 12:06:45PM +0100, Daniel Vetter wrote:
> On Wed, Dec 19, 2018 at 7:54 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> > > This patch adds inline functions and helpers for obtaining
> > > DP sink's supported DSC parameters
On Wed, Jan 30, 2019 at 06:26:53PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote:
> > Even outside GPU driver, device driver like RDMA just want to share their
> > doorbell to other device and they do not want to see those doorbell page
> > use in
On Wed, Jan 30, 2019 at 05:23:40PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 30, 2019 at 03:41:04PM +, Brian Starkey wrote:
> > Hi Russell,
> >
> > These did eventually reach me on Saturday evening.
> >
> > On Fri, Jan 25, 2019 at 09:43:19AM +, Russell King wrote:
> > >
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> It only talks about crtc, brings up intel as an exampel and I think is
nit: Should be "example".
> more misleading than useful really. Plus we have lots of discussion
> about how your standard kms driver should be initialized/cleaned up,
> so maybe
On Wed, Jan 30, 2019 at 03:41:04PM +, Brian Starkey wrote:
> Hi Russell,
>
> These did eventually reach me on Saturday evening.
>
> On Fri, Jan 25, 2019 at 09:43:19AM +, Russell King wrote:
> > Add support for writing the SPD infoframe to the TDA998x. Identify us
> > as "Generic" vendor
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> .. next to all the other sink helpers. The rect library is more used
> for handling plane clipping, so belongs to those imo.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Nicholas Kazlauskas
Looks better than being sandwiched between the HDMI
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #7 from Clément Guérin (li...@protonmail.com) ---
Thanks. I'll try it out asap. I strongly feel that this feature should be
backported to 5.0 since the freesync implementation seems broken without it. I
understand if that's not
On Wed, Jan 30, 2019 at 04:57:48PM +, Kazlauskas, Nicholas wrote:
> On 1/30/19 11:30 AM, Daniel Vetter wrote:
> > Yes it's inconsitent with vrr_capable, but this is the actual uapi as
> > exercise by igt.
> >
> > Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
> > Cc:
On 1/30/19 11:30 AM, Daniel Vetter wrote:
> Yes it's inconsitent with vrr_capable, but this is the actual uapi as
> exercise by igt.
>
> Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
> Cc: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Alex Deucher
>
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #6 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Should be:
https://patchwork.freedesktop.org/series/53559/
"drm/amd/display: Add below the range support for FreeSync"
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #5 from Clément Guérin (li...@protonmail.com) ---
Can you point me to the commits introducing this feature? Thanks.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, 22 Jan 2019 15:25:46 +, Biju Das wrote:
> Document the RZ/G1N (R8A7744) LVDS bindings.
>
> Signed-off-by: Biju Das
> ---
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring
On Tue, Jan 22, 2019 at 05:44:28PM +0200, Laurent Pinchart wrote:
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Jan 22, 2019 at 03:25:46PM +, Biju Das wrote:
> > Document the RZ/G1N (R8A7744) LVDS bindings.
> >
> > Signed-off-by: Biju Das
>
> Reviewed-by: Laurent Pinchart
>
> and
On Tue, Jan 29, 2019 at 02:20:06PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/gpu/drm/savage/savage_state.c:301:8: warning: this
From: Sean Paul
The frame_busy mask is used in frame_done event handling, which is not
invoked for async commits. So an async commit will leave the
frame_busy mask populated after it completes and future commits will start
with the busy mask incorrect.
This showed up on disable after cursor
.. next to all the other sink helpers. The rect library is more used
for handling plane clipping, so belongs to those imo.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
Yes it's inconsitent with vrr_capable, but this is the actual uapi as
exercise by igt.
Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Pekka Paalanen
Cc: Alex Deucher
Signed-off-by: Daniel Vetter
---
It only talks about crtc, brings up intel as an exampel and I think is
more misleading than useful really. Plus we have lots of discussion
about how your standard kms driver should be initialized/cleaned up,
so maybe better to document this when we have a better idea.
Signed-off-by: Daniel Vetter
https://bugs.freedesktop.org/show_bug.cgi?id=108889
--- Comment #6 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* BLB BWR HSW BSW: Incomplete - igt_stop_helper: Assertion
`helper_was_alive(proc, status) failed
-
https://bugs.freedesktop.org/show_bug.cgi?id=109493
--- Comment #4 from Chris Wilson ---
Found the skip, patch sent.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
kms_flip tests are breaking on vkms when simulate vblank because vblank
event sequence count returns one extra frame after arm vblank event to
make a page flip.
When vblank interrupt happens, userspace processes the vblank event and
issues the next page flip command. Kernel calls queue_work to
When the vblank irq happens, kernel time subsystem executes
`vkms_vblank_simulate`. In parallel or not, it prepares all stuff
necessary to the next vblank with arm, and it must flush these
stuff before the next vblank irq. However, vblank counter is ahead
when arm is executed in parallel with
This patchset contains patches to fix the extra frame bug on kms_flip
igt-test. First patch solves the extra vblank frame that breaks many
tests on kms_flip and second patch solves the race condition caused
by the solution added in the first one.
Shayenne Moura (2):
drm/vkms: Bugfix extra
1 - 100 of 184 matches
Mail list logo
