== Series Details ==
Series: drm/i915: Deprecate I915_SET_COLORKEY_NONE
URL : https://patchwork.freedesktop.org/series/37584/
State : warning
== Summary ==
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
fail -> PASS (shard-hsw) fdo#102670 +1
Test km
== Series Details ==
Series: drm/i915: nuke pch type :o
URL : https://patchwork.freedesktop.org/series/37581/
State : success
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7869/shards.html
___
Intel-gfx mailing
== Series Details ==
Series: series starting with [01/10] drm/vblank: Data type fixes for 64-bit
vblank sequences.
URL : https://patchwork.freedesktop.org/series/37598/
State : success
== Summary ==
Series 37598v1 series starting with [01/10] drm/vblank: Data type fixes for
64-bit vblank seq
== Series Details ==
Series: drm/i915/selftests: Flush old resets between engines
URL : https://patchwork.freedesktop.org/series/37591/
State : success
== Summary ==
Series 37591v1 drm/i915/selftests: Flush old resets between engines
https://patchwork.freedesktop.org/api/1.0/series/37591/revis
== Series Details ==
Series: Adhering to HDCP1.4 Compliance Test Spec (rev3)
URL : https://patchwork.freedesktop.org/series/37539/
State : success
== Summary ==
Series 37539v3 Adhering to HDCP1.4 Compliance Test Spec
https://patchwork.freedesktop.org/api/1.0/series/37539/revisions/3/mbox/
Tes
On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> > On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
> > wrote:
> >> Quoting Andy Lutomirski (2018-02-01 21:04:30)
> >>> I got this after a recent suspend/resume:
> >>>
> >>> Feb 01 09
From: "Pandiyan, Dhinakaran"
The frame counter may have got reset between disabling and enabling vblank
interrupts due to DMC putting the hardware to DC5/6 states if PSR was
active. The frame counter could also have stalled if PSR was active in case
there was no DMC. The frame counter resetting h
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64.
The flip ioctl receives a 32-bit target sequence from user space and is
compared against the current sequence from drm_crtc_vblank_count(). So,
typecast return from drm_crtc_vblank_
From: "Pandiyan, Dhinakaran"
The HW frame counter can get reset if device enters a low power state after
vblank interrupts were disabled. This messes up any following vblank count
update as a negative diff (huge unsigned diff) is calculated from the HW
frame counter change. We cannot ignore negat
From: "Pandiyan, Dhinakaran"
Updating vblank counts requires register reads and these reads may not
return meaningful values if the device was in a low power state after
vblank interrupts were last disabled. So, update the count only if vblank
interrupts are enabled. Secondly, this means the regi
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this
down to u32 either fixes
Core returns a u64 vblank count and intel_crtc_get_vblank_counter()
expects a 32-bit value. Make the typecast explicit to add clarity.
Cc: Keith Packard
Cc: Rodrigo Vivi
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
From: "Pandiyan, Dhinakaran"
drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is >= 2^32) as reference, the requeste
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes
570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64, store all the bits
without truncating. There is no need to type cast this value down to
32-bits.
Cc: Keith Packard
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Signed-off-by: Dhinakaran Pan
When injecting rapid resets, we must be careful to at least wait for the
previous reset to have taken effect and the engine restarted. If we
perform a second reset before that has happened, we will notice that the
engine hasn't recovered and declare it lost, wedging the device and
failing. In pract
Quoting Jani Nikula (2018-02-02 19:13:53)
> On Fri, 02 Feb 2018, dom.const...@free.fr wrote:
> > For my HTPC setup, I'm using the option "CustomEDID".
> > With this option, output attaching and destroying events leads to crashes.
> >
> > The following sequence leads to a crash:
> > - In xorg.conf:
== Series Details ==
Series: series starting with disable-gem-trace (rev3)
URL : https://patchwork.freedesktop.org/series/37473/
State : success
== Summary ==
Series 37473v3 series starting with disable-gem-trace
https://patchwork.freedesktop.org/api/1.0/series/37473/revisions/3/mbox/
Test ge
Quoting Jani Nikula (2018-02-02 20:01:00)
> The PCH type is an unnecessary level of abstraction that's an extra
> maintenance burden. Switch to using PCH ids directly. This also
> simplifies the virtual PCH detection.
But you are still using the PCH type, just computing it from the id
inside the c
Incase of HDCP authentication failure, HDCP spec expects
reauthentication. Hence this patch adds the reauthentications
to be compliance with spec.
v2:
do-while to for loop for simplicity. [Seanpaul]
v3:
positioning the logs effectively. [Seanpaul]
Signed-off-by: Ramalingam C
---
drivers/gp
DP HDCP1.4 spec mandates that An can be written to panel only after
detecting the panel's hdcp capability.
For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
For HDMI valid BKSV indicates the panel's hdcp capability.
For HDMI it is optional to detect the panel's hdcp capabilit
This patch aligns all definitions of hdcp registers and their bits.
v2:
No changes. Added reviewed-by tag.
v3:
No change.
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/i915_reg.h | 58 -
1 file changed, 29 insertions(+),
HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.
This patch adds the above mentioned re-read for bksv.
v2:
Rephrased the commit msg [Seanpaul]
v3:
do-while to for-loop [Seanpaul]
Signed-off-by: Ramalingam C
---
drivers/
HDCP key need not be cleared on each hdcp disable. And HDCP key Load
is skipped if key is already loaded.
v2:
No change. Added Reviewed-by tag.
v3:
No change.
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_hdcp.c | 6 --
1 file changed, 4 insertions(
When HDCP authentication is triggered on multiple connector, having
connector name and ID in debug message will be more informative.
v2:
Added logs with connector info at the start of en/disable [Seanpaul]
Added the connector info into Check link failure msgs too.
v3:
No Changes. Added Revi
If a HDCP repeater is detected with zero downstream devices,
HDCP spec approves either of below actions:
1. Dont continue on second stage authentication. Disable encryption.
2. Continue with second stage authentication excluding the KSV list and
on success, continue encryption.
Since disable e
We enable the HDCP encryption as a part of first stage authentication.
So when second stage authentication fails, we need to disable the HDCP
encryption and signalling.
This patch ensures that, when hdcp authentication fails, HDCP encryption
and signalling is turned off.
v2:
Dropped connector r
This series is developed to address the expectations from HDCP compliance
test specification.
6/8 patches are for fixing failures in one or more compliance test cases
2 patches are Good to have kind. Not related to compliance.
Thanks to Seanpaul for immediate review comments on v1 and v2.
Ramali
On Fri, Feb 02, 2018 at 05:57:02PM -0200, Paulo Zanoni wrote:
> This commit adds the basic CDCLK functions, but it's still missing
> pieces of the display initialization sequence.
>
> v2:
> - Implement the voltage levels.
> - Rebase.
> v3:
> - Adjust to the new "bypass" clock (Imre).
> - Call
Quoting Andy Lutomirski (2018-02-02 19:23:33)
> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> > On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> >> Anyway, this is all on a 4.14 kernel. I should update to 4.16 and see
> >> what happens.
> >
> > I updated to 4.15, and the situa
Quoting Tvrtko Ursulin (2018-02-02 18:38:16)
> From: Tvrtko Ursulin
>
> Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking
> inside for busy-stats") added a tasklet_disable call in busy stats
> enabling, but we failed to understand that the PMU enable callback runs
> as an ha
== Series Details ==
Series: drm/i915/pmu: Fix PMU enable vs execlists tasklet race
URL : https://patchwork.freedesktop.org/series/37575/
State : success
== Summary ==
Test perf:
Subgroup enable-disable:
fail -> PASS (shard-apl) fdo#103715
Subgroup b
== Series Details ==
Series: drm/i915: Deprecate I915_SET_COLORKEY_NONE
URL : https://patchwork.freedesktop.org/series/37584/
State : success
== Summary ==
Series 37584v1 drm/i915: Deprecate I915_SET_COLORKEY_NONE
https://patchwork.freedesktop.org/api/1.0/series/37584/revisions/1/mbox/
Test g
Quoting dom.const...@free.fr (2018-02-02 18:37:12)
> Hello,
>
> For my HTPC setup, I'm using the option "CustomEDID".
> With this option, output attaching and destroying events leads to crashes.
>
> The following sequence leads to a crash:
> - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edi
== Series Details ==
Series: Adhering to HDCP1.4 Compliance Test Spec (rev2)
URL : https://patchwork.freedesktop.org/series/37539/
State : warning
== Summary ==
Series 37539v2 Adhering to HDCP1.4 Compliance Test Spec
https://patchwork.freedesktop.org/api/1.0/series/37539/revisions/2/mbox/
Tes
Quoting Ville Syrjala (2018-02-02 20:42:31)
> From: Ville Syrjälä
>
> Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious
> way to disable colorkey is to just set flags to 0, which is
> exactly what the intel ddx has been doing all along.
I can confirm that I never realised the flag exi
Quoting Ville Syrjala (2018-02-02 20:42:52)
> From: Ville Syrjälä
>
> SKL reintroduced plane scaling once more. Let's try to make use of it.
>
> The one annoying caveat is that you can't do colorkeying and scaling at
> the same time :( For now we'll leave the choice of colorkey vs.
> scaling to
Quoting Patchwork (2018-02-02 20:25:31)
> == Series Details ==
>
> Series: drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset
> URL : https://patchwork.freedesktop.org/series/37552/
> State : success
>
> == Summary ==
>
> Test perf:
> Subgroup blocking:
>
On Sat, Feb 03, 2018 at 01:41:30AM +0530, Ramalingam C wrote:
> If a HDCP repeater is detected with zero downstream devices,
> HDCP spec approves either of below actions:
>
> 1. Dont continue on second stage authentication. Disable encryption.
> 2. Continue with second stage authentication excludi
On Sat, Feb 03, 2018 at 01:41:31AM +0530, Ramalingam C wrote:
> When HDCP authentication is triggered on multiple connector, having
> connector name and ID in debug message will be more informative.
>
> v2:
> Added logs with connector info at the start of en/disable [Seanpaul]
> Added the conn
On Sat, Feb 03, 2018 at 01:41:29AM +0530, Ramalingam C wrote:
> We enable the HDCP encryption as a part of first stage authentication.
> So when second stage authentication fails, we need to disable the HDCP
> encryption and signalling.
>
> This patch ensures that, when hdcp authentication fails,
On Sat, Feb 03, 2018 at 01:41:35AM +0530, Ramalingam C wrote:
> Incase of HDCP authentication failure, HDCP spec expects
> reauthentication. Hence this patch adds the reauthentications
> to be compliance with spec.
>
> v2:
> do-while to for loop for simplicity. [Seanpaul].
>
> Signed-off-by: Ra
On Sat, Feb 03, 2018 at 01:41:34AM +0530, Ramalingam C wrote:
> DP HDCP1.4 spec mandates that An can be written to panel only after
> detecting the panel's hdcp capability.
>
> For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
> For HDMI valid BKSV indicates the panel's hdcp c
On Sat, Feb 03, 2018 at 01:41:32AM +0530, Ramalingam C wrote:
> HDCP specification says that when bksv is identified as invalid
> (not with 20 1s), bksv should be re-read and verified.
>
> This patch adds the above mentioned re-read for bksv.
>
> v2:
> Rephrased the commit msg [Seanpaul]
>
> S
From: Ville Syrjälä
SKL reintroduced plane scaling once more. Let's try to make use of it.
The one annoying caveat is that you can't do colorkeying and scaling at
the same time :( For now we'll leave the choice of colorkey vs.
scaling to the user via that XV_ALWAYS_ON_TOP attribute.
One possib
From: Ville Syrjälä
Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious
way to disable colorkey is to just set flags to 0, which is
exactly what the intel ddx has been doing all along.
Currently when userspace sets the flags to 0, we end up in a
funny state where colorkey is disabled, b
== Series Details ==
Series: drm/i915: nuke pch type :o
URL : https://patchwork.freedesktop.org/series/37581/
State : success
== Summary ==
Series 37581v1 drm/i915: nuke pch type :o
https://patchwork.freedesktop.org/api/1.0/series/37581/revisions/1/mbox/
Test debugfs_test:
Subgroup re
Quoting Ville Syrjälä (2018-02-02 17:44:58)
> On Fri, Feb 02, 2018 at 05:31:57PM +, Chris Wilson wrote:
> > I think we're okay with just using the master IIR for IRQ_NONE /
> > IRQ_HANDLED as that is the interrupt generator aiui. If the child
> > sources disagree that's another issue, but as fa
== Series Details ==
Series: drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
URL : https://patchwork.freedesktop.org/series/37558/
State : warning
== Summary ==
Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
fail -> PASS (shard-hsw)
Sub
== Series Details ==
Series: drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset
URL : https://patchwork.freedesktop.org/series/37552/
State : success
== Summary ==
Test perf:
Subgroup blocking:
fail -> PASS (shard-hsw) fdo#102252
== Series Details ==
Series: ICL display initialization and some plane bits (rev5)
URL : https://patchwork.freedesktop.org/series/36993/
State : failure
== Summary ==
Series 36993v5 ICL display initialization and some plane bits
https://patchwork.freedesktop.org/api/1.0/series/36993/revisions/
DP HDCP1.4 spec mandates that An can be written to panel only after
detecting the panel's hdcp capability.
For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
For HDMI valid BKSV indicates the panel's hdcp capability.
For HDMI it is optional to detect the panel's hdcp capabilit
Incase of HDCP authentication failure, HDCP spec expects
reauthentication. Hence this patch adds the reauthentications
to be compliance with spec.
v2:
do-while to for loop for simplicity. [Seanpaul].
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 23 --
This patch aligns all definitions of hdcp registers and their bits.
v2:
No changes. Added reviewed-by tag.
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/i915_reg.h | 58 -
1 file changed, 29 insertions(+), 29 deletions(-)
HDCP key need not be cleared on each hdcp disable. And HDCP key Load
is skipped if key is already loaded.
v2:
No change. Added Reviewed-by tag.
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_hdcp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.
This patch adds the above mentioned re-read for bksv.
v2:
Rephrased the commit msg [Seanpaul]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 13
If a HDCP repeater is detected with zero downstream devices,
HDCP spec approves either of below actions:
1. Dont continue on second stage authentication. Disable encryption.
2. Continue with second stage authentication excluding the KSV list and
on success, continue encryption.
Since disable e
When HDCP authentication is triggered on multiple connector, having
connector name and ID in debug message will be more informative.
v2:
Added logs with connector info at the start of en/disable [Seanpaul]
Added the connector info into Check link failure msgs too.
Signed-off-by: Ramalingam C
This series is developed to address the expectations from HDCP compliance
test specification.
6/8 patches are for fixing failures in one or more compliance test cases
2 patches are Good to have kind. Not related to compliance.
Thanks to Seanpaul for immediate review comments on v1.
Ramalingam C
We enable the HDCP encryption as a part of first stage authentication.
So when second stage authentication fails, we need to disable the HDCP
encryption and signalling.
This patch ensures that, when hdcp authentication fails, HDCP encryption
and signalling is turned off.
v2:
Dropped connector r
Prepare for more widespread use of PCH id. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4e158aab36d6..a
I was wondering how to clean up intel_virt_detect_pch(), also in a more future
compatible manner, and came up with this idea.
Is the text size increase in patch 3/3 too bad, that is the question.
BR,
Jani.
Jani Nikula (3):
drm/i915: introduce INTEL_PCH_ID() and use it
drm/i915/debugfs: prin
The PCH type is an unnecessary level of abstraction that's an extra
maintenance burden. Switch to using PCH ids directly. This also
simplifies the virtual PCH detection.
The downside is code size increase for conditions that match several PCH
ids:
text data bss dec hex f
Preparation for future patches. Split this out to highlight the debugfs
change.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index
This commit adds the basic CDCLK functions, but it's still missing
pieces of the display initialization sequence.
v2:
- Implement the voltage levels.
- Rebase.
v3:
- Adjust to the new "bypass" clock (Imre).
- Call intel_dump_cdclk_state() too.
- Rename a variable to avoid confusion.
- Simpli
On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
>> wrote:
>>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
I got this after a recent suspend/resume:
Feb 01 09:44:34 la
On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote:
>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>> I got this after a recent suspend/resume:
>>>
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>>> Feb 01 09:44:34 laptop s
On Fri, 02 Feb 2018, dom.const...@free.fr wrote:
> For my HTPC setup, I'm using the option "CustomEDID".
> With this option, output attaching and destroying events leads to crashes.
>
> The following sequence leads to a crash:
> - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"
I know n
== Series Details ==
Series: drm/i915/pmu: Fix PMU enable vs execlists tasklet race
URL : https://patchwork.freedesktop.org/series/37575/
State : success
== Summary ==
Series 37575v1 drm/i915/pmu: Fix PMU enable vs execlists tasklet race
https://patchwork.freedesktop.org/api/1.0/series/37575/r
On Fri, 02 Feb 2018, Ville Syrjälä wrote:
> On Mon, Jan 29, 2018 at 03:47:35PM +0100, Hans de Goede wrote:
>> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
>> index = 3, one of which has been kindly provided to me by Jan Brummer,
>> where not working with the i915 driver, giv
From: Tvrtko Ursulin
Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking
inside for busy-stats") added a tasklet_disable call in busy stats
enabling, but we failed to understand that the PMU enable callback runs
as an hard IRQ (IPI).
Consequence of this is that the PMU enable
Hello,
For my HTPC setup, I'm using the option "CustomEDID".
With this option, output attaching and destroying events leads to crashes.
The following sequence leads to a crash:
- In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"
- Starting Xorg
- Connect HDMI2
- Disconnect HDMI2
- Recon
On Fri, Feb 02, 2018 at 02:23:04PM -0200, Paulo Zanoni wrote:
> On ICL we have two sets of registers: one for port A and another for
> port B. The set of port A registers is the same as the CNL registers.
>
> Since the procmon table on ICL is the same we want to reuse the CNL
> function. To do tha
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Tuesday, January 30, 2018 1:06 AM
>To: Vivi, Rodrigo
>Cc: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove Firmware URL.
>
>Quoting Rodrigo Vivi (2018-
On Fri, Feb 02, 2018 at 05:31:57PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-02 16:03:36)
> > On Fri, Feb 02, 2018 at 03:34:48PM +, Chris Wilson wrote:
> > > As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> > > is possible for the master IIR to indica
Quoting Michel Thierry (2018-02-02 16:49:49)
> On 2/2/2018 6:54 AM, Chris Wilson wrote:
> > Be paranoid and flush the GTIIR after clearing the CS interrupt to be
> > sure it has taken before we re-enable the interrupt handler. We still
> > see early interrupts following reset, the tasklet handling
Quoting Ville Syrjälä (2018-02-02 16:03:36)
> On Fri, Feb 02, 2018 at 03:34:48PM +, Chris Wilson wrote:
> > As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> > is possible for the master IIR to indicate a pending IRQ for which we
> > have already cleared from the GTIIR.
== Series Details ==
Series: ICL display initialization and some plane bits (rev4)
URL : https://patchwork.freedesktop.org/series/36993/
State : failure
== Summary ==
Series 36993v4 ICL display initialization and some plane bits
https://patchwork.freedesktop.org/api/1.0/series/36993/revisions/
== Series Details ==
Series: ICL display initialization and some plane bits (rev4)
URL : https://patchwork.freedesktop.org/series/36993/
State : failure
== Summary ==
Series 36993v4 ICL display initialization and some plane bits
https://patchwork.freedesktop.org/api/1.0/series/36993/revisions/
== Series Details ==
Series: drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
URL : https://patchwork.freedesktop.org/series/37558/
State : success
== Summary ==
Series 37558v1 drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
https://patchwork.freedesktop.org/api/1.0/se
On 2/2/2018 6:54 AM, Chris Wilson wrote:
Be paranoid and flush the GTIIR after clearing the CS interrupt to be
sure it has taken before we re-enable the interrupt handler. We still
see early interrupts following reset, the tasklet handling the mmio read
before it has been written by the CS. This
== Series Details ==
Series: tools/intel_reg: Fix segfault in intel_reg dump (rev2)
URL : https://patchwork.freedesktop.org/series/37537/
State : warning
== Summary ==
Test kms_flip_tiling:
Subgroup flip-changes-tiling-yf:
pass -> FAIL (shard-apl) fdo#103822
== Series Details ==
Series: drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset
URL : https://patchwork.freedesktop.org/series/37552/
State : success
== Summary ==
Series 37552v1 drm/i915/execlists: Flush GTIIR on clearing CS interrupts during
reset
https://patchwork.freed
On ICL we have two sets of registers: one for port A and another for
port B. The set of port A registers is the same as the CNL registers.
Since the procmon table on ICL is the same we want to reuse the CNL
function. To do that we add a port argument and make CNL always call
the function passing p
On Mon, Jan 29, 2018 at 03:47:35PM +0100, Hans de Goede wrote:
> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
> index = 3, one of which has been kindly provided to me by Jan Brummer,
> where not working with the i915 driver, giving a black screen on the
> first modeset.
>
>
== Series Details ==
Series: drm/crc: Add support for polling on the data fd.
URL : https://patchwork.freedesktop.org/series/37550/
State : warning
== Summary ==
Series 37550v1 drm/crc: Add support for polling on the data fd.
https://patchwork.freedesktop.org/api/1.0/series/37550/revisions/1/m
On Mon, Jan 29, 2018 at 03:47:34PM +0100, Hans de Goede wrote:
> Add a new intel_bios_cleanup function to free memdup-ed bios data
> structures and call it from i915_driver_unload().
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 ++
> drivers/gpu/drm/i915/i915_d
== Series Details ==
Series: series starting with disable-gem-trace (rev3)
URL : https://patchwork.freedesktop.org/series/37473/
State : failure
== Summary ==
Test kms_flip:
Subgroup 2x-flip-vs-blocking-wf-vblank:
pass -> FAIL (shard-hsw)
Subgroup pl
On Fri, Feb 02, 2018 at 03:34:48PM +, Chris Wilson wrote:
> As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> is possible for the master IIR to indicate a pending IRQ for which we
> have already cleared from the GTIIR. In this case, the DRM_ERROR are
> intended and shou
On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> On Fri, 02 Feb 2018, Greg KH wrote:
> > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> >>
> >> +Knut, Fengguang
> >>
> >> On Fri, 02 Feb 2018, Greg KH wrote:
> >> > - If clang now builds the kernel "cleanly", yes, I
On Fri, Feb 02, 2018 at 08:08:44PM +0530, Ramalingam C wrote:
>
>
> On Friday 02 February 2018 07:54 PM, Sean Paul wrote:
> > On Fri, Feb 02, 2018 at 04:15:18PM +0530, Ramalingam C wrote:
> > > As a first step of HDCP authentication detects the panel's HDCP
> > > capability. This is mandated for
As we ourselves cancel interrupts during reset by clearing the GTIIR, it
is possible for the master IIR to indicate a pending IRQ for which we
have already cleared from the GTIIR. In this case, the DRM_ERROR are
intended and should not be flagged as an error.
Signed-off-by: Chris Wilson
Cc: Joona
On Friday 02 February 2018 08:52 PM, Sean Paul wrote:
On Fri, Feb 2, 2018 at 9:51 AM, Ramalingam C wrote:
On Friday 02 February 2018 08:15 PM, Sean Paul wrote:
On Fri, Feb 02, 2018 at 07:52:24PM +0530, Ramalingam C wrote:
On Friday 02 February 2018 07:39 PM, Sean Paul wrote:
On Fri, Feb
On Fri, Feb 2, 2018 at 9:33 AM, Ramalingam C wrote:
>
>
> On Friday 02 February 2018 07:48 PM, Sean Paul wrote:
>>
>> On Fri, Feb 02, 2018 at 04:15:17PM +0530, Ramalingam C wrote:
>>>
>>> HDCP key need not be cleared on each hdcp disable. And HDCP key Load
>>> is skipped if key is already loaded.
On Fri, Feb 2, 2018 at 9:51 AM, Ramalingam C wrote:
>
>
> On Friday 02 February 2018 08:15 PM, Sean Paul wrote:
>>
>> On Fri, Feb 02, 2018 at 07:52:24PM +0530, Ramalingam C wrote:
>>>
>>>
>>> On Friday 02 February 2018 07:39 PM, Sean Paul wrote:
On Fri, Feb 02, 2018 at 04:15:13PM +0530,
On Fri, Feb 02, 2018 at 08:33:38PM +0530, Ramalingam C wrote:
>
>
> On Friday 02 February 2018 08:18 PM, Sean Paul wrote:
> > On Fri, Feb 02, 2018 at 07:42:47PM +0530, Ramalingam C wrote:
> > >
> > > On Friday 02 February 2018 07:43 PM, Sean Paul wrote:
> > > > On Fri, Feb 02, 2018 at 04:15:14PM
On Friday 02 February 2018 08:07 PM, Sean Paul wrote:
On Fri, Feb 02, 2018 at 04:15:19PM +0530, Ramalingam C wrote:
When HDCP authentication fails, we add two more reauthentication.
This will address all reauth expectation from compliance perspective.
Signed-off-by: Ramalingam C
---
driver
On Friday 02 February 2018 08:18 PM, Sean Paul wrote:
On Fri, Feb 02, 2018 at 07:42:47PM +0530, Ramalingam C wrote:
On Friday 02 February 2018 07:43 PM, Sean Paul wrote:
On Fri, Feb 02, 2018 at 04:15:14PM +0530, Ramalingam C wrote:
If a HDCP repeater is detected with zero hdcp authenticated
On Friday 02 February 2018 08:15 PM, Sean Paul wrote:
On Fri, Feb 02, 2018 at 07:52:24PM +0530, Ramalingam C wrote:
On Friday 02 February 2018 07:39 PM, Sean Paul wrote:
On Fri, Feb 02, 2018 at 04:15:13PM +0530, Ramalingam C wrote:
We enable the HDCP encryption as a part of first stage auth
1 - 100 of 161 matches
Mail list logo
