== Series Details ==
Series: drm/i915: Infoframe precompute/check (rev6)
URL : https://patchwork.freedesktop.org/series/49983/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5397_full -> Patchwork_11276_full
Summary
---
== Series Details ==
Series: Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
URL : https://patchwork.freedesktop.org/series/55035/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5401 -> Patchwork_11279
Summary
== Series Details ==
Series: Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
URL : https://patchwork.freedesktop.org/series/55035/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
74f4fde246cb drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
-:46:
From: Swati Sharma
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_display.c | 30 ++
drivers/gpu/drm/i915/intel_sprite.c | 61 ++--
2 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
From: Swati Sharma
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.
Y210: For each component, valid data occupies MSB 10 bits.
LSB 6 bits are filled with
From: Swati Sharma
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
inde
From: Swati Sharma
These patches enable packed format YUV422-Y210, Y212 and Y216
and YUV444-Y410, Y412, Y416 for 10, 12 and 16 bits for ICL+.
IGT needs libraries for Pixman and Cairo to support more than 8bpc.
Work going on from Maarten Lankhorst.
Initial review for Y2xx done https://patchwork.
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev6)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5396_full -> Patchwork_11275_full
Summary
--
On 1/10/2019 10:02 PM, Michał Winiarski wrote:
On Tue, Jan 08, 2019 at 03:13:02PM +, Tvrtko Ursulin wrote:
From: Tony Ye
Simple test which exercises the VME fixed function block.
v2: (Tvrtko Ursulin)
* Small cleanups like copyright date, tabs, remove unused bits.
v3: (Tony Ye)
* Add
On Mon, 2019-01-07 at 16:58 +, Tvrtko Ursulin wrote:
> On 07/01/2019 13:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
> > >
> > > On 07/01/2019 11:58, Tvrtko Ursulin wrote:
> > >
> > > [snip]
> > >
> > > > > Note about future interaction with preemption: Preemption
On Mon, 2019-01-07 at 12:50 +, Tvrtko Ursulin wrote:
> On 05/01/2019 02:40, Carlos Santa wrote:
> > From: Michel Thierry
> >
> > On command streams that could potentially hang the GPU after a last
> > flush command, it's best not to cancel the watchdog
> > until after all commands have execut
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev7)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5400 -> Patchwork_11278
Summary
---
**SUC
Quoting John Harrison (2019-01-11 00:16:16)
> On 1/10/2019 02:11, Chris Wilson wrote:
> > Track where and when we acquire and release the power well for pps
> > access along the dp aux link, with a view to detecting if we leak any
> > wakerefs.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jani Niku
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev7)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4dc81bd3d040 drm/dp_mst: Fix some formatting in drm_dp_add_port()
5613e665e2e0 drm/dp_mst: Fix some for
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Dani
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1 del
== Series Details ==
Series: drm/i915/cnl: Fix CNL macros for Voltage Swing programming (rev2)
URL : https://patchwork.freedesktop.org/series/54092/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5400 -> Patchwork_11277
Summ
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc:
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed wi
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Reviewed-By: Ben Skeggs
Cc: Daniel Vetter
Cc: David Ai
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is al
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Changes since v1:
* Move drm_dp_mst_get_port_malloc() to where we assign
intel_connector->port - danvet
Sig
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks a
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment that
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actual
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and t
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
Reindent some stuff, and split some stuff across multiple lines so we
aren't going over the text width limit.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting w
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming scheme,
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
1 file changed, 8 insertions(+)
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current s
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
d
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
On 07/01/2019 11:58, Tvrtko Ursulin wrote:
[snip]
Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog
For the nouveau patches in the series:
Reviewed-By: Ben Skeggs
On Fri, 11 Jan 2019 at 05:59, Lyude Paul wrote:
>
> This is the series I've been working on for a while now to get all of
> the atomic DRM drivers in the tree to use the atomic MST helpers, and to
> make the atomic MST helpers actua
== Series Details ==
Series: drm/i915/cnl: Fix CNL macros for Voltage Swing programming (rev2)
URL : https://patchwork.freedesktop.org/series/54092/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8b810fada4b5 drm/i915/cnl: Fix CNL macros for Voltage Swing programming
-:26: ERROR
On 1/10/2019 02:11, Chris Wilson wrote:
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 231 +--
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/omapdrm/omap_encoder.c
between commit:
3c613a3bddd3 ("drm/omap: fix incorrect union usage")
from Linus' tree and commit:
13d0add333af ("drm/edid: Pass connector to AVI infoframe functions")
from th
Quoting Antonio Argenziano (2019-01-10 21:58:52)
>
>
> On 10/01/19 13:29, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-01-10 21:27:54)
> >> Quoting Antonio Argenziano (2019-01-10 21:24:56)
> >>>
> >>>
> >>> On 07/01/19 04:41, Chris Wilson wrote:
> On Skylake, BB_OFFSET seems to be unst
Quoting John Harrison (2019-01-10 23:15:31)
> On 1/10/2019 02:11, Chris Wilson wrote:
> > @@ -4054,18 +4055,20 @@ void intel_power_domains_init_hw(struct
> > drm_i915_private *dev_priv, bool resume)
> >* resources powered until display HW readout is complete. We drop
> >* this refe
On 1/10/2019 02:11, Chris Wilson wrote:
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-o
CNL macros for register groups CNL_PORT_TX_DW2_* / CNL_PORT_TX_DW5_* are
configured incorrectly wrt definition of _CNL_PORT_TX_DW_GRP.
v2: Jani suggested to keep the macros organized semantically i.e., by
function, secondarily by port/pipe/transcoder.->(dw, port)
Cc: Clint Taylor
Cc: Imre Deak
On Wed, 2019-01-09 at 17:24 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> > PSR2 only trigger interruptions for AUX error, so let's not print
> > useless information in debugfs.
> > Also adding a comment to intel_psr_irq_handler() about that.
On Wed, 2019-01-09 at 18:18 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> > This register contains how many blocks was sent in the past
> > selective
> > updates.
> > Those registers are not kept set all the times but pulling it
> > after
> I
On Tue, Jan 08, 2019 at 01:07:29PM +0530, Uma Shankar wrote:
> Sanitize crtc gamma mode and update the mode in driver in case
> BIOS has setup a different gamma mode as to what is expected by
> driver. There is restriction on HSW platform not to read/write
> color LUT's if ips is enabled. Handled t
On Wed, 2019-01-09 at 18:11 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> > The value of this registers will be used to test if PSR2 is doing
> > selective update and if the number of blocks match with the
> > expected.
> >
> > v2:
> > - Usin
On Tue, Jan 08, 2019 at 01:07:28PM +0530, Uma Shankar wrote:
> Check if de-gamma/gamma lut callback is assigned before
> calling the same.
>
> Signed-off-by: Uma Shankar
Is it possible for this test to fail? intel_color_init() seems to
always assign a value (even for platforms that don't actual
On 10/01/19 01:19, Chris Wilson wrote:
Some kernels may have to disable error capture for some hardware or by
it being configured out. Since it is conditionally available, asserting
it exists is not an actual requirement. For hardware where we are unable
to provide error state capture, skip.
S
On 10/01/19 13:29, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-10 21:27:54)
Quoting Antonio Argenziano (2019-01-10 21:24:56)
On 07/01/19 04:41, Chris Wilson wrote:
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it shoul
== Series Details ==
Series: drm/i915: Infoframe precompute/check (rev6)
URL : https://patchwork.freedesktop.org/series/49983/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5397 -> Patchwork_11276
Summary
---
**SUCCE
On 09.01.2019 14:11, Chris Wilson wrote:
> Hi, we've hit a snag with
>
> commit 2b3e88ea65287ba738a798622405b15344871085
> Author: Heiner Kallweit
> Date: Sun Dec 16 18:30:14 2018 +0100
>
> net: phy: improve phy state checking
>
> as it is detecting that the call from tg3 during suspend i
== Series Details ==
Series: drm/i915: Infoframe precompute/check (rev6)
URL : https://patchwork.freedesktop.org/series/49983/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: video/hdmi: Add an enum for HDMI packet types
Okay!
Commit: drm/i915: Add the
== Series Details ==
Series: drm/i915: Infoframe precompute/check (rev6)
URL : https://patchwork.freedesktop.org/series/49983/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5bf207115074 video/hdmi: Add an enum for HDMI packet types
94c8aca5d9c0 drm/i915: Add the missing HDMI ga
Quoting Chris Wilson (2019-01-10 21:27:54)
> Quoting Antonio Argenziano (2019-01-10 21:24:56)
> >
> >
> > On 07/01/19 04:41, Chris Wilson wrote:
> > > On Skylake, BB_OFFSET seems to be unstable. Since this is an
> > > offset into the batch at the time of CS execution, it should be actively
> > >
Quoting Antonio Argenziano (2019-01-10 21:24:56)
>
>
> On 07/01/19 04:41, Chris Wilson wrote:
> > On Skylake, BB_OFFSET seems to be unstable. Since this is an
> > offset into the batch at the time of CS execution, it should be actively
> > written to as we read from the register so allow it a qwo
On 07/01/19 04:41, Chris Wilson wrote:
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it should be actively
written to as we read from the register so allow it a qword of
discrepancy (since the CS should be reading in qwords). Thi
From: Ville Syrjälä
We have definitions and low level code for everything except the gamut
metadata HDMI packet. Add the missing bits.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 8 +---
drivers/gpu/drm/i915/intel_hdmi.c | 12 ++
From: Ville Syrjälä
Add code to read the infoframes from the video DIP and unpack them into
the crtc state.
v2: Make the read funcs return void (Daniel)
Drop the duplicate infoframe enabled checks (Daniel)
Add a FIXME for lspcon infoframe readout
Signed-off-by: Ville Syrjälä
Reviewed-b
From: Ville Syrjälä
Store the mask of enabled infoframes in the crtc state. We'll start
with just the readout for HDMI encoder, and we'll expand this
to compute the bitmask in .compute_config() later. SDVO will also
follow later.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
dri
From: Ville Syrjälä
Check the infoframes and infoframe enable state when comparing two
crtc states.
We'll use the infoframe logging functions from video/hdmi.c to
show the infoframes as part of the state dump.
TODO: Try to better integrate the infoframe dumps with
drm state dumps
v2: drm
From: Ville Syrjälä
As with regular HDMI encoders, let's precompute the infoframes
(actually just AVI infoframe for the time being) with SDVO HDMI
encoders.
v2: Drop the WARN_ON() from drm_hdmi_avi_infoframe_from_display_mode()
return since that could genuinely fail due to user asking
fo
From: Ville Syrjälä
Dump out the infoframes in the normal crtc state dump.
TODO: Try to better integrate the infoframe dumps with
drm state dumps
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 26 ++
1 file cha
From: Ville Syrjälä
Read the HDMI infoframes from the hbuf and unpack them into
the crtc state.
Well, actually just AVI infoframe for now but let's write the
infoframe readout code in a more generic fashion in case we
expand this later.
Note that Daniel was sceptical about the benefit if this a
From: Ville Syrjälä
Store the infoframes in the crtc state and precompute them in
.compute_config(). While precomputing we'll also fill out the
inforames.enable bitmask appropriately.
v2: Drop the null packet stuff (Daniel)
Add a FIXME for lspcon
Signed-off-by: Ville Syrjälä
Reviewed-by: D
From: Ville Syrjälä
We want to start tracking which infoframes are enabled, so let's replace
the boolean flag with a bitmask.
We'll abstract the bitmask so that it's not platform dependent. That
will allow us to examine the bitmask later in platform independent code.
v2: Don't map VIDEO_DIP_ENA
From: Ville Syrjälä
We'll be wanting to send more than just infoframes over HDMI. So add an
enum for other packet types.
TODO: Maybe just include the infoframe types in the packet type enum
and get rid of the infoframe type enum?
v2: s/AUDIO_CP/ACP/ (Shashank)
Cc: Thierry Reding
Cc: Han
From: Ville Syrjälä
Remainder of the infoframe precompute/readout stuff. Addressed
the review comments (I hope) and massaged a few things that had
changed. The main thing was lspcon appearing in the meantime.
Note that I didn't implement precompute+readout for lspcon.
That'll probably need to hap
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev6)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5396 -> Patchwork_11275
Summary
---
**SUC
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev6)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bc4462c0913d drm/dp_mst: Fix some formatting in drm_dp_add_port()
2816687b107d drm/dp_mst: Fix some for
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is al
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc:
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airl
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actual
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc:
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1 del
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks a
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and t
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Changes since v1:
* Move drm_dp_mst_get_port_malloc() to where we assign
intel_connector->port - danvet
Sig
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current s
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment that
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed wi
Fix some indenting, split some stuff across multiple lines.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
d
Split some stuff across multiple lines
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Split some stuff across multiple lines, remove some unnecessary braces
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
1 file changed, 8 insertions(+)
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming scheme,
Reindent some stuff, and split some stuff across multiple lines so we
aren't going over the text width limit.
Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 18
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting w
Hi Ville,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-i915-Try-to-sanitize-bogus-DPLL-state-left-over-by-broken-SNB-BIOSen/20190109-222838
base: git://anongit.freedesktop.org/drm-intel for-linux-next
New smatch warn
== Series Details ==
Series: drm/i915: Guard error capture against unpinned vma
URL : https://patchwork.freedesktop.org/series/54994/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5392_full -> Patchwork_11274_full
Summary
-
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-10 15:51:33)
>> Chris Wilson writes:
>> > @@ -680,6 +682,8 @@ static int i915_interrupt_info(struct seq_file *m,
>> > void *data)
>> > wakeref = intel_runtime_pm_get(dev_priv);
>> >
>> > if (IS_CHERRYVIEW(dev_priv)) {
>> > +
Quoting Ville Syrjälä (2019-01-10 16:03:21)
> On Thu, Jan 10, 2019 at 10:38:07AM +, Chris Wilson wrote:
> > Broadwater and the rest of gen4 do support being able to saving and
> > reloading context specific registers between contexts, providing isolation
> > of the basic GPU state (as programm
Quoting Mika Kuoppala (2019-01-10 15:51:33)
> Chris Wilson writes:
> > @@ -680,6 +682,8 @@ static int i915_interrupt_info(struct seq_file *m, void
> > *data)
> > wakeref = intel_runtime_pm_get(dev_priv);
> >
> > if (IS_CHERRYVIEW(dev_priv)) {
> > + intel_wakeref_t pref;
On Thu, Jan 10, 2019 at 10:38:07AM +, Chris Wilson wrote:
> Broadwater and the rest of gen4 do support being able to saving and
> reloading context specific registers between contexts, providing isolation
> of the basic GPU state (as programmable by userspace). This allows
> userspace to assum
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/54991/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5391_full -> Patchwork_11273_full
=
1 - 100 of 172 matches
Mail list logo
