On Tue, Aug 18, 2020 at 6:13 PM Dave Airlie wrote:
>
> I think there's been some discussion about reverting that change for
> other reasons, but it's quite likely the culprit.
Hmm. It reverts cleanly, but the end result doesn't work, because of
other changes.
Reverting all of
763fedd6a216
On Tue, 2020-08-18 at 14:29 -0700, Navare, Manasi wrote:
> On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> > Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source
> > tests.
> >
> > v2: uniform bit names TP4a/b/c (Manasi)
> >
> > Signed-off-by: Khaled Almahallawy
>
On Wed, 19 Aug 2020 at 10:38, Linus Torvalds
wrote:
>
> Ping on this?
>
> The code disassembles to
>
> 24: 8b 85 d0 fd ff ffmov-0x230(%ebp),%eax
> 2a:* c7 03 01 00 40 10movl $0x1041,(%ebx) <-- trapping instruction
> 30: 89 43 04 mov%eax,0x4(%ebx)
> 33:
Ping on this?
The code disassembles to
24: 8b 85 d0 fd ff ffmov-0x230(%ebp),%eax
2a:* c7 03 01 00 40 10movl $0x1041,(%ebx) <-- trapping instruction
30: 89 43 04 mov%eax,0x4(%ebx)
33: 8b 85 b4 fd ff ffmov-0x24c(%ebp),%eax
39: 89 43 08
Just one small comment
On Tue, 2020-08-18 at 11:39 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Used to query whether an MST stream is encrypted or not.
>
> Cc: Lyude Paul
> Reviewed-by: Anshuman Gupta
> Signed-off-by: Sean Paul
>
> Link:
>
== Series Details ==
Series: drm/i915/selftests: Push the fake iommu device from the stack to data
URL : https://patchwork.freedesktop.org/series/80756/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8900_full -> Patchwork_18369_full
On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
>
> v2: uniform bit names TP4a/b/c (Manasi)
>
> Signed-off-by: Khaled Almahallawy
Looks good to me,
Reviewed-by: Manasi Navare
Khaled, could you also
On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote:
> On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> > > On 8/17/20 12:48 PM, Kees Cook wrote:
> > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > > >
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> On 8/17/20 12:48 PM, Kees Cook wrote:
> > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > On 8/17/20 12:29 PM, Kees Cook wrote:
> > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
> > > > > On 8/17/20 2:15 AM,
On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote:
> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> > On 8/17/20 12:48 PM, Kees Cook wrote:
> > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > > On 8/17/20 12:29 PM, Kees Cook wrote:
> > > > > On Mon, Aug
== Series Details ==
Series: drm/i915/selftests: Push the fake iommu device from the stack to data
URL : https://patchwork.freedesktop.org/series/80756/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8900 -> Patchwork_18369
On Tue, 18 Aug 2020 at 19:43, Chris Wilson wrote:
>
> Since we store a pointer to the fake iommu device that is allocated on
> the stack, as soon as we leave the function it goes out of scope and any
> future dereference is undefined behaviour. Just in case we may need to
> look at the fake iommu
Since we store a pointer to the fake iommu device that is allocated on
the stack, as soon as we leave the function it goes out of scope and any
future dereference is undefined behaviour. Just in case we may need to
look at the fake iommu device after initialiation, move the allocation
from the
Quoting Rodrigo Vivi (2020-08-18 18:49:19)
> On Tue, Aug 18, 2020 at 12:58:00PM +0100, Chris Wilson wrote:
> > Quoting Marcin Ślusarz (2020-08-18 12:36:07)
> > > From: Marcin Ślusarz
> > >
> > > For some reason intel_gt_reset attempts to reset the GPU twice.
> > > On one code path (do_reset)
On Tue, Aug 18, 2020 at 12:58:00PM +0100, Chris Wilson wrote:
> Quoting Marcin Ślusarz (2020-08-18 12:36:07)
> > From: Marcin Ślusarz
> >
> > For some reason intel_gt_reset attempts to reset the GPU twice.
> > On one code path (do_reset) "reset" parameter is obeyed, but is
> > not on the other
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev2)
URL : https://patchwork.freedesktop.org/series/78749/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8898_full -> Patchwork_18368_full
Summary
On Tue, Aug 18, 2020 at 02:46:23PM +0530, Allen wrote:
> > >
> > > Signed-off-by: Romain Perier
> > > Signed-off-by: Allen Pais
> >
> > This looks good to me.
> >
> > Reviewed-by: Corey Minyard
> >
> > Are you planning to push this, or do you want me to take it? If you
> > want me to take it,
> >
> > Signed-off-by: Romain Perier
> > Signed-off-by: Allen Pais
>
> This looks good to me.
>
> Reviewed-by: Corey Minyard
>
> Are you planning to push this, or do you want me to take it? If you
> want me to take it, what is the urgency?
Thanks. Well, not hurry, as long as it goes into 5.9
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev2)
URL : https://patchwork.freedesktop.org/series/78749/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8898 -> Patchwork_18368
Summary
---
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev2)
URL : https://patchwork.freedesktop.org/series/78749/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST (rev2)
URL : https://patchwork.freedesktop.org/series/78749/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ad446f228d24 drm/i915: Fix sha_text population code
-:72: WARNING:LINE_SPACING: Missing a blank
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Link:
From: Sean Paul
Only one functional change, reversed the hdcp_1x/2x_present bits in the
QUERY_STREAM_ENCRYPTION_STATUS parsing with a comment explaining my
confusion.
Other than that, lots of rebasing, the most notable being the
s/intel_dig_port/dig_port/ rename.
Every patch now has a
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean
On Mon, Aug 17, 2020 at 09:17:55PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/tgl+: Fix Combo PHY DPLL fractional divider for 38.4MHz ref
> clock (rev2)
> URL : https://patchwork.freedesktop.org/series/79486/
> State : failure
>
> == Summary ==
>
> CI Bug Log -
Quoting Marcin Ślusarz (2020-08-18 12:36:07)
> From: Marcin Ślusarz
>
> For some reason intel_gt_reset attempts to reset the GPU twice.
> On one code path (do_reset) "reset" parameter is obeyed, but is
> not on the other one (__intel_gt_set_wedged).
It's not that simple, we do want to force
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: obey "reset" module parameter
URL : https://patchwork.freedesktop.org/series/80734/
State : failure
== Summary ==
Applying: drm/i915/gt: obey "reset" module parameter
error: git diff header lacks filename information when
Quoting Marcin Ślusarz (2020-08-18 12:37:20)
> From: Marcin Ślusarz
>
> Few lines above there's drm_notice saying that the gpu will be reset.
> Printing "gpu reset disabled" using lower logging level makes it
> harder to figure out what happened.
It's disabled by user request, and we may do
From: Marcin Ślusarz
Few lines above there's drm_notice saying that the gpu will be reset.
Printing "gpu reset disabled" using lower logging level makes it
harder to figure out what happened.
Signed-off-by: Marcin Ślusarz
---
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
1 file changed, 1
From: Marcin Ślusarz
For some reason intel_gt_reset attempts to reset the GPU twice.
On one code path (do_reset) "reset" parameter is obeyed, but is
not on the other one (__intel_gt_set_wedged).
Fix this.
I noticed this because I stumbled on a bug which completely locks
up a machine on reset
45 matches
Mail list logo
