On Tue, Jan 08, 2019 at 07:35:03PM -0500, Lyude Paul wrote:
> 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
On Tue, Jan 08, 2019 at 07:35:04PM -0500, Lyude Paul wrote:
> 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 up
On Tue, Jan 08, 2019 at 07:35:01PM -0500, Lyude Paul wrote:
> Split some stuff across multiple lines
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Harry Wentland
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Juston Li
On patches 1-4: Reviewed-by: Daniel Vetter
> ---
> driver
On Tue, Jan 08, 2019 at 07:35:05PM -0500, Lyude Paul wrote:
> 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
> Cc
On 10/01/2019 01:57, Patchwork wrote:
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: recreate WA lists
inside the selftest
URL : https://patchwork.freedesktop.org/series/54967/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_
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.
Signed-off-by: Chris Wilson
---
tests/i915
On Tue, Jan 08, 2019 at 07:35:14PM -0500, Lyude Paul wrote:
> 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
On Tue, Jan 08, 2019 at 07:35:16PM -0500, Lyude Paul wrote:
> 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
Reviewed-by: Dan
On Tue, Jan 08, 2019 at 07:35:15PM -0500, Lyude Paul wrote:
> 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
>* bran
OpenBSD, FreeBSD and NetBSD don't contains file byteswap.h.
Used specifics of them.
Fixes: 746ab3bb131d (sna: Added AYUV format support for textured and sprite
video adapters.)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109268
CC: Stanislav Lisovskiy
CC: Chris Wilson
Signed-off-by:
Quoting Daniele Ceraolo Spurio (2019-01-09 21:31:47)
> The only gen8+ platform that has the feature is BDW, but we don't define
> the feature flag on any BDW platform and we only have partial support in
> the gen8 path (irq enabling code, but no handler).
> The only thing we could do in the irq han
On 10/01/2019 01:32, Daniele Ceraolo Spurio wrote:
By using the wa lists inside the live driver structures, we won't
catch issues where those are incorrectly setup or corrupted.
To cover this gap, update the workaround framework to allow saving the
wa lists to independent structures and use them
Quoting John Harrison (2019-01-10 01:10:09)
> On 1/9/2019 16:24, John Harrison wrote:
> > On 1/7/2019 03:54, Chris Wilson wrote:
> >> Frequently, we use intel_runtime_pm_get/_put around a small block.
> >> Formalise that usage by providing a macro to define such a block with an
> >> automatic closu
Quoting John Harrison (2019-01-10 00:55:07)
> On 1/7/2019 03:54, Chris Wilson wrote:
> > The majority of runtime-pm operations are bounded and scoped within a
> > function; these are easy to verify that the wakeref are handled
> > correctly. We can employ the compiler to help us, and reduce the num
Quoting Sergii Romantsov (2019-01-10 09:42:45)
> OpenBSD, FreeBSD and NetBSD don't contains file byteswap.h.
> Used specifics of them.
>
> Fixes: 746ab3bb131d (sna: Added AYUV format support for textured and sprite
> video adapters.)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109268
Quoting Tvrtko Ursulin (2019-01-10 09:46:56)
>
> On 10/01/2019 01:32, Daniele Ceraolo Spurio wrote:
> > -static bool verify_gt_engine_wa(struct drm_i915_private *i915, const char
> > *str)
> > +static bool verify_gt_engine_wa(struct drm_i915_private *i915,
> > + struct
Keep track of our acquired wakeref for interacting with the guc, so that
we can cancel it upon release and so clearly identify leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_guc_log.c | 15 +--
drivers/gpu/drm/i915/intel
As sysfs has a simple pattern of taking a rpm wakeref around the user
access, we can track the local reference and drop it as soon as
possible.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_sysfs.c | 24 ++--
1 file cha
Keep track of our wakeref used to keep the device awake so we can catch
any leak.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_perf.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
d
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
v2: Use skip=0 for unwinding the stack as it appears our noinl
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
Keep hold of the local wakeref used in error handling, to cancel
the tracking upon release so that leaks can be identified.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
dif
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/int
If we keep a cookie for every time we acquire a wakeref, we can use that
to keep track of who holds a wakeref and more importantly who still
holds one at important junctures (when the rpm count unexpectedly goes
to zero!)
Culminating in a bugfix for Ironlake which CI has been tripping over for
man
As the GT_IRQ power domain implies a wakeref, we can use it inplace of
our existing redundant rpm grab.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 11 ---
drivers/gpu/drm/i91
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
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 +---
1 file changed, 121 insertio
Keep track of the rpm wakeref used for framebuffer access so that we can
cancel upon release and so more clearly identify leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
drivers/gpu/drm/i915/intel_fbdev.c | 9 +
Track the wakeref used for temporary access to the device, and discard
it upon release so that leaks can be identified.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pmu.c | 26 +-
1 file changed, 17 insertions(+),
Keep track of the temporary rpm wakerefs used for user access to the
device, so that we can cancel them upon release and clearly identify any
leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c| 47 +-
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
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-off-by: Chris Wilson
Cc: Jani Nikula
---
Record the wakeref used for keeping the device awake as the GPU is
executing requests and be sure to cancel the tracking upon parking.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 11 ++
Keep track of the temporary rpm wakeref inside hotplug detection, so
that we can cancel it immediately upon release and so clearly identify
leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_hotplug.c | 5 +++--
1 file changed, 3 insert
Track the temporary wakerefs used within the selftests so that leaks are
clear.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/huge_pages.c | 5 ++--
drivers/gpu/drm/i915/selftests/i915_gem.c | 29 ---
.../drm/i9
Keep track of the temporary rpm wakeref used for panel backlight access,
so that we can cancel it immediately upon release and so more clearly
identify leaks.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_panel.c | 5 +++--
1 file changed
Chris Wilson writes:
> The majority of runtime-pm operations are bounded and scoped within a
> function; these are easy to verify that the wakeref are handled
> correctly. We can employ the compiler to help us, and reduce the number
> of wakerefs tracked when debugging, by passing around cookies
On 09/01/2019 16:42, Chris Wilson wrote:
If the current process is being killed (it was interrupted with SIGKILL
or equivalent), it will not make any progress in page allocation and we
can abort performing the shrinking on its behalf. So we can use
mutex_lock_killable() instead (although this pa
On 09/01/2019 16:42, Chris Wilson wrote:
The wait-for-idle used from within the shrinker_lock_uninterruptible
depends on the struct_mutex locking state being known and declared to
i915_request_wait(). As it is conceivable that we reach the vmap
notifier from underneath struct_mutex (and so keep
As debugfs has a simple pattern of taking a rpm wakeref around the user
access, we can track the local reference and drop it as soon as
possible.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 135 +---
1
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Revi
Despite what I think the prm recommends, commit f2253bd9859b
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active
I've completed a run through with piglit on Crestline, Cantiga and
Ironlake (missing desktops Broadwater, Eaglelake) and fixed up the fails
found. Currently piglit seems happy with both contexts disabled (so just
using the per-fd default context isolation) and contexts enabled in mesa.
-Chris
___
Ironlake does 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 assume that the
GPU retains their state from one batch to the next, minimising the
amount of stat
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 assume that the GPU retains their state from one batch to the
next, minimis
Quoting Tvrtko Ursulin (2019-01-10 10:28:14)
>
> On 09/01/2019 16:42, Chris Wilson wrote:
> > The wait-for-idle used from within the shrinker_lock_uninterruptible
> > depends on the struct_mutex locking state being known and declared to
> > i915_request_wait(). As it is conceivable that we reach t
Hi Uma,
On Tue, Jan 08, 2019 at 02:41:20PM +0530, Uma Shankar wrote:
> Hardware may have HDR capability on certain plane
> engines. Enabling the same in drm plane structure
> so that this can be communicated to user space.
>
> Each drm driver should set this flag to true for planes
> which suppor
Quoting Tvrtko Ursulin (2019-01-10 10:24:09)
>
> On 09/01/2019 16:42, Chris Wilson wrote:
> > If the current process is being killed (it was interrupted with SIGKILL
> > or equivalent), it will not make any progress in page allocation and we
> > can abort performing the shrinking on its behalf. So
On Mon, 7 Jan 2019 at 11:55, Chris Wilson wrote:
>
> Currently we only allocate an object and vma if we are using a GGTT
> virtual HWSP, and a plain struct page for a physical HWSP. For
> convenience later on with global timelines, it will be useful to always
> have the status page being tracked b
On 10/01/2019 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-10 10:24:09)
On 09/01/2019 16:42, Chris Wilson wrote:
If the current process is being killed (it was interrupted with SIGKILL
or equivalent), it will not make any progress in page allocation and we
can abort performing t
On Tue, Jan 08, 2019 at 02:41:16PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
>
> v3:
Quoting Matthew Auld (2019-01-10 10:52:48)
> On Mon, 7 Jan 2019 at 11:55, Chris Wilson wrote:
> >
> > Currently we only allocate an object and vma if we are using a GGTT
> > virtual HWSP, and a plain struct page for a physical HWSP. For
> > convenience later on with global timelines, it will be us
If we find an incompletely setup vma inside the request/engine at the
time of a hang, it may not have vma->pages initialised, so skip
capturing the object before we iterate over NULL.
Spotted by Matthew in preparation for using unpinned vma to track engine
state.
Signed-off-by: Chris Wilson
Cc:
Quoting Tvrtko Ursulin (2019-01-10 10:54:33)
>
> On 10/01/2019 10:47, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-10 10:24:09)
> >>
> >> On 09/01/2019 16:42, Chris Wilson wrote:
> >>> If the current process is being killed (it was interrupted with SIGKILL
> >>> or equivalent), it will
On Thu, 10 Jan 2019 at 11:15, Chris Wilson wrote:
>
> If we find an incompletely setup vma inside the request/engine at the
> time of a hang, it may not have vma->pages initialised, so skip
> capturing the object before we iterate over NULL.
>
> Spotted by Matthew in preparation for using unpinned
On Mon, 7 Jan 2019 at 11:55, Chris Wilson wrote:
>
> Currently we only allocate an object and vma if we are using a GGTT
> virtual HWSP, and a plain struct page for a physical HWSP. For
> convenience later on with global timelines, it will be useful to always
> have the status page being tracked b
>-Original Message-
>From: Liviu Dudau [mailto:li...@dudau.co.uk]
>Sent: Thursday, January 10, 2019 4:17 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 05/12]
== Series Details ==
Series: series starting with [01/21] drm/i915: Track all held rpm wakerefs
URL : https://patchwork.freedesktop.org/series/54986/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7870145b7f82 drm/i915: Track all held rpm wakerefs
-:131: CHECK:UNCOMMENTED_DEFINI
== Series Details ==
Series: series starting with [01/21] drm/i915: Track all held rpm wakerefs
URL : https://patchwork.freedesktop.org/series/54986/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Track all held rpm wakerefs
-drivers/gpu/drm/
== Series Details ==
Series: series starting with [01/21] drm/i915: Track all held rpm wakerefs
URL : https://patchwork.freedesktop.org/series/54986/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5391 -> Patchwork_11272
Sum
== 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 -> Patchwork_11273
===
== Series Details ==
Series: drm/i915: Guard error capture against unpinned vma
URL : https://patchwork.freedesktop.org/series/54994/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Guard error capture against unpinned vma
-O:drivers/gpu/drm/i
On Wed, 09 Jan 2019, Zhenyu Wang wrote:
> Hi,
>
> Here's one race fix for gvt to handle request properly
> between pre-scan of workload and submission.
Pulled, thanks.
BR,
Jani.
>
> Thanks.
> --
> The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
>
> Linux 5.0-rc1 (
On 10/01/2019 11:15, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-10 10:54:33)
On 10/01/2019 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-10 10:24:09)
On 09/01/2019 16:42, Chris Wilson wrote:
If the current process is being killed (it was interrupted with SIGKILL
or eq
On 10/01/2019 10:39, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-10 10:28:14)
On 09/01/2019 16:42, Chris Wilson wrote:
The wait-for-idle used from within the shrinker_lock_uninterruptible
depends on the struct_mutex locking state being known and declared to
i915_request_wait(). As it
== 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 -> Patchwork_11274
Summary
---
Quoting Tvrtko Ursulin (2019-01-10 13:16:30)
>
> On 10/01/2019 10:39, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-10 10:28:14)
> >>
> >> On 09/01/2019 16:42, Chris Wilson wrote:
> >>> The wait-for-idle used from within the shrinker_lock_uninterruptible
> >>> depends on the struct_mutex
Hi Dave/Daniel,
Some patches were pushed today to drm-misc-fixes, and I think it would be nice
if they are part of the pull req for v5.0-rc2. :)
drm-misc-fixes-2019-01-10-1:
Second pull request, drm-misc-fixes for v5.0-rc2:
- Fix fb-helper to work correctly with SDL 1.2 bugs.
- Fix lockdep warnin
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)
> * Added curbe data entry for dst surface
On Wed, Jan 09, 2019 at 02:34:36PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> > The old debugfs fields was not following a naming partern and it was
> > a bit confusing.
> >
> > So it went from:
> > ~$ sudo more /sys/kernel/debug/dri/0/i91
On Thu, 27 Dec 2018, Jani Nikula wrote:
> DRM_DEBUG() was intended to be used by the drm core code only, but we
> weren't careful. Today, the driver usage of DRM_DEBUG() trumps drm core
> usage about 10:1. It's easier to swith the core over to a new
> DRM_DEBUG_CORE() macro than the drivers over t
Chris Wilson writes:
> The majority of runtime-pm operations are bounded and scoped within a
> function; these are easy to verify that the wakeref are handled
> correctly. We can employ the compiler to help us, and reduce the number
> of wakerefs tracked when debugging, by passing around cookies
== 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
=
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
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;
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
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)) {
>> > +
== 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
-
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
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,
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
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(+)
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
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
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
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
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
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:
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
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
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
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
1 - 100 of 172 matches
Mail list logo
