Add connector debugfs attributes for each intel
connector which is getting register.
v2:
- adding connector debugfs for each connector in
intel_connector_register() to fix CI failure for legacy connectors.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_connector.c | 3 ++
Gen11 onwards PG3 is contains functions for pipe B,
external displays, and VGA. It make sense to add
a power well id with name ICL_DISP_PW_3 rather then
TGL_DISP_PW_3, Also PG3 power well id requires to
know if lpsp is enabled.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an output is
capable of driving lpsp and exposes lpsp enablement info.
v2:
- CI fixup.
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_debugfs.c | 102 +
This series adds i915_lpsp_info connector debugfs.
Test-with: 20200323063248.5261-2-anshuman.gu...@intel.com
Anshuman Gupta (3):
drm/i915: Power well id for ICL PG3
drm/i915: Add i915_lpsp_info debugfs
drm/i915: Add connector dbgfs for all connectors
.../gpu/drm/i915/display/intel_connect
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, March 18, 2020 3:09 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/edp: Ignore short pulse when
> panel
> powered off
>
> On Wed, 18 Mar
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready prior to actually inserting it
(as soon as it
In some cases we want to hold onto the wakeref for a little after the
last user so that we can avoid having to drop and then immediately
reacquire it. Allow the last user to specify if they would like to keep
the wakeref alive for a short hysteresis.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
Abuse^W Take advantage that we know we are inside the GT wakeref and
that prevents any client execbuf from reopening the i915_vma in order to
claim all the vma to close without having to drop the spinlock to free
each one individually. By keeping the spinlock, we do not have to
restart if we run co
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we sti
Since we take advantage of RCU for some i915_active objects, like the
intel_timeline_cacheline, we need to delay the i915_active_fini until
after the RCU grace period and we perform the kfree -- that is until
after all RCU protected readers.
<3> [108.204873] ODEBUG: assert_init not available (acti
Drop the pretense of kicking the tasklet (used only for the defunct guc
submission backend, it should just take ownership of the submit!) and so
remove the bh-kicking from around submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 --
drivers/gpu/drm/i9
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct subm
Keep the engine-pm awake until the next jiffie, to avoid immediate
ping-pong under moderate load. (Forcing the idle barrier excerbates the
moderate load, dramatically increasing the driver overhead.) On the
other hand, delaying the idle-barrier slightly incurs longer rc6-off
and so more power consu
On Mon, 23 Mar 2020 at 09:29, Chris Wilson wrote:
>
> Since we take advantage of RCU for some i915_active objects, like the
> intel_timeline_cacheline, we need to delay the i915_active_fini until
> after the RCU grace period and we perform the kfree -- that is until
> after all RCU protected reade
Quoting Francisco Jerez (2020-03-20 22:14:51)
> Francisco Jerez writes:
>
> > Chris Wilson writes:
> >
> >> We dropped calling process_csb prior to handling direct submission in
> >> order to avoid the nesting of spinlocks and lift process_csb() and the
> >> majority of the tasklet out of irq-of
On 23/03/2020 09:28, Chris Wilson wrote:
Abuse^W Take advantage that we know we are inside the GT wakeref and
that prevents any client execbuf from reopening the i915_vma in order to
claim all the vma to close without having to drop the spinlock to free
each one individually. By keeping the spi
On 23/03/2020 09:28, Chris Wilson wrote:
In some cases we want to hold onto the wakeref for a little after the
last user so that we can avoid having to drop and then immediately
reacquire it. Allow the last user to specify if they would like to keep
the wakeref alive for a short hysteresis.
Si
On 23/03/2020 09:28, Chris Wilson wrote:
Keep the engine-pm awake until the next jiffie, to avoid immediate
ping-pong under moderate load. (Forcing the idle barrier excerbates the
moderate load, dramatically increasing the driver overhead.) On the
other hand, delaying the idle-barrier slightly
On 23/03/2020 09:28, Chris Wilson wrote:
Drop the pretense of kicking the tasklet (used only for the defunct guc
submission backend, it should just take ownership of the submit!) and so
remove the bh-kicking from around submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i9
In some cases we want to hold onto the wakeref for a little after the
last user so that we can avoid having to drop and then immediately
reacquire it. Allow the last user to specify if they would like to keep
the wakeref alive for a short hysteresis.
v2: Embrace bitfield.h for adjustable flags.
S
On 23/03/2020 09:28, Chris Wilson wrote:
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back
On 23/03/2020 09:28, Chris Wilson wrote:
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready p
Quoting Tvrtko Ursulin (2020-03-23 10:37:22)
>
> On 23/03/2020 09:28, Chris Wilson wrote:
> > If the caller allows and we do not have to wait for any signals,
> > immediately execute the work within the caller's process. By doing so we
> > avoid the overhead of scheduling a new task, and the laten
On Fri, Mar 06, 2020 at 09:37:10PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 02, 2020 at 11:26:00PM +0100, Daniel Vetter wrote:
> > We need to add a drmm_kstrdup for this, but let's start somewhere.
> >
> > This is not exactly perfect onion unwinding, but it's jsut a kfree so
> > doesn't really mat
On Sat, Mar 07, 2020 at 09:06:08AM +0100, Sam Ravnborg wrote:
> On Mon, Mar 02, 2020 at 11:25:44PM +0100, Daniel Vetter wrote:
> > I also did a full review of all callers, and only the xen driver
> > forgot to call drm_dev_put in the failure path. Fix that up too.
>
> So ~40 callers - phew..
>
>
Stolen memory is allocated at creation, returning -ENOSPC if we run out
space.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1424
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/intel_memory_region.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we sti
Quoting Matthew Auld (2020-03-23 11:03:01)
> Stolen memory is allocated at creation, returning -ENOSPC if we run out
> space.
Sigh. Eviction was always a planned feature for stolen, for when we
exposed it to userspace. We should have just done that to flesh out the
driver APIs and uAPI.
> Closes:
== Series Details ==
Series: i915 lpsp support for lpsp igt (rev3)
URL : https://patchwork.freedesktop.org/series/74648/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bf39cdd33479 drm/i915: Power well id for ICL PG3
6711ab7084cf drm/i915: Add i915_lpsp_info debugfs
-:143: WARNI
== Series Details ==
Series: i915 lpsp support for lpsp igt (rev3)
URL : https://patchwork.freedesktop.org/series/74648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8175 -> Patchwork_17049
Summary
---
**SUCCESS**
The subtest shrink_boom was added as a regression test for some missing
refcounting on the paging structures, however since the binding is
potentially async, setting the vm->fault_attr might apply to the purge
vma, and not the intended explode vma. Also it looks like it might also
be possible to hi
Quoting Matthew Auld (2020-03-23 11:38:09)
> The subtest shrink_boom was added as a regression test for some missing
> refcounting on the paging structures, however since the binding is
> potentially async, setting the vm->fault_attr might apply to the purge
> vma, and not the intended explode vma.
Quoting Matthew Auld (2020-03-23 11:38:09)
> The subtest shrink_boom was added as a regression test for some missing
> refcounting on the paging structures, however since the binding is
> potentially async, setting the vm->fault_attr might apply to the purge
> vma, and not the intended explode vma.
On 23/03/2020 10:32, Chris Wilson wrote:
In some cases we want to hold onto the wakeref for a little after the
last user so that we can avoid having to drop and then immediately
reacquire it. Allow the last user to specify if they would like to keep
the wakeref alive for a short hysteresis.
v2
== Series Details ==
Series: drm/i915/selftests/perf: watch out for stolen objects
URL : https://patchwork.freedesktop.org/series/74968/
State : failure
== Summary ==
Applying: drm/i915/selftests/perf: watch out for stolen objects
Using index info to reconstruct a base tree...
M drivers/
== Series Details ==
Series: series starting with [1/8] drm/i915/gt: Mark timeline->cacheline as
destroyed after rcu grace period (rev3)
URL : https://patchwork.freedesktop.org/series/74967/
State : failure
== Summary ==
Applying: drm/i915/gt: Mark timeline->cacheline as destroyed after rcu g
It looks like the callers expect a non-volatile object, but it looks the
shrinker will discard the object pages anyway, thinking that the pages
can be swapped out if the object is marked as WILLNEED. If that's true
then it might be better to mark it as volatile and fix the callers
instead, but on t
A nasty issue was found with the way we serialise the update of the GTT
(GPU virtual address space) on the GEM context and with execution via
execbuf. On update we serialise with ctx->mutex and attempt to rewrite
the GTT addresses stored within the context from inside a request (along
that context)
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we sti
Allow some users the discretion to not immediately return on a normal
signal. Hopefully, they will opt to use TASK_KILLABLE instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 6 --
drivers/gpu/drm/i915/i915_active.h | 6 +-
2 files changed, 9 insertions(+), 3 d
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct subm
On Wed, Feb 26, 2020 at 11:09:59AM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 01:59:04PM +0100, Christian König wrote:
> > On the exporter side we add optional explicit pinning callbacks. Which are
> > called when the importer doesn't implement dynamic handling, move
> > notification
>
On Mon, 23 Mar 2020 at 11:43, Chris Wilson wrote:
>
> Quoting Matthew Auld (2020-03-23 11:38:09)
> > The subtest shrink_boom was added as a regression test for some missing
> > refcounting on the paging structures, however since the binding is
> > potentially async, setting the vm->fault_attr migh
Quoting Matthew Auld (2020-03-23 13:08:21)
> It looks like the callers expect a non-volatile object, but it looks the
> shrinker will discard the object pages anyway, thinking that the pages
> can be swapped out if the object is marked as WILLNEED. If that's true
> then it might be better to mark i
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
v2: Also measure throughput using only one thread.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716 insertions(+)
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11 ins
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilso
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gp
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct cont
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Signed-off-by: Chris Wilson
Reviewed-by:
On Mon, 23 Mar 2020 at 13:17, Chris Wilson wrote:
>
> Quoting Matthew Auld (2020-03-23 13:08:21)
> > It looks like the callers expect a non-volatile object, but it looks the
> > shrinker will discard the object pages anyway, thinking that the pages
> > can be swapped out if the object is marked as
Quoting Matthew Auld (2020-03-23 13:53:13)
> On Mon, 23 Mar 2020 at 13:17, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2020-03-23 13:08:21)
> > > It looks like the callers expect a non-volatile object, but it looks the
> > > shrinker will discard the object pages anyway, thinking that the pa
== Series Details ==
Series: drm/i915/selftests: add some vma_sync
URL : https://patchwork.freedesktop.org/series/74969/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8178 -> Patchwork_17052
Summary
---
**FAILURE**
On Fri, Mar 20, 2020 at 02:51:41PM +0200, Lisovskiy, Stanislav wrote:
> On Wed, Mar 11, 2020 at 06:31:30PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 09, 2020 at 06:12:00PM +0200, Stanislav Lisovskiy wrote:
> > > Currently intel_can_enable_sagv function contains
> > > a mix of workarounds for diff
On Thu, Mar 19, 2020 at 03:50:59PM +0530, Pankaj Bharadiya wrote:
> Introduce new plane and CRTC scaling filter properties to allow
> userspace to select the driver's default scaling filter or
> Nearest-neighbor(NN) filter for upscaling operations on CRTC and
> plane.
>
> Drivers can set up this p
Hi Ville,
You are right, your suggestion will fix this issue.
#Based on dmesg log, uapi mode private flags change is captured
...
[ 11.404578] fbcon: i915drmfb (fb0) is primary device
[ 11.404743] [drm] SA: intel_atomic_check: uapi change
[ 11.404744] [drm] SA2: intel_atomic_check:
new_c
On Thu, Mar 19, 2020 at 03:51:01PM +0530, Pankaj Bharadiya wrote:
> Introduce scaler registers and bit fields needed to configure the
> scaling filter in prgrammed mode and configure scaling filter
> coefficients.
>
> changes since v1:
> * None
> changes since RFC:
> * Parametrize scaler coeffient
On Mon, Mar 23, 2020 at 04:18:36PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 20, 2020 at 02:51:41PM +0200, Lisovskiy, Stanislav wrote:
> > On Wed, Mar 11, 2020 at 06:31:30PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 09, 2020 at 06:12:00PM +0200, Stanislav Lisovskiy wrote:
> > > > Currently inte
On Thu, Mar 19, 2020 at 03:51:02PM +0530, Pankaj Bharadiya wrote:
> Integer scaling (IS) is a nearest-neighbor upscaling technique that
> simply scales up the existing pixels by an integer
> (i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
> works by filling in the missing color
On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> GEN >= 10 hardware supports the programmable scaler filter.
>
> Attach scaling filter property for CRTC and plane for GEN >= 10
> hardwares and program scaler filter based on the selected filter
> type.
>
> changes since v1:
> *
slab does this already, and I want to use this in a memory allocation
tracker in drm for stuff that's tied to the lifetime of a drm_device,
not the underlying struct device. Kinda like devres, but for drm.
Acked-by: Andrew Morton
Signed-off-by: Daniel Vetter
Cc: Christoph Lameter
Cc: Pekka Enbe
For two reasons:
- The driver core clears this already for us after we're unloaded in
__device_release_driver().
- It's way too late, the drm_device ->release callback might massively
outlive the underlying physical device, since a drm_device can't be
kept alive by open drm_file or well rea
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Acked-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Ve
With this we can drop the final kfree from the release function.
Reviewed-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Reviewed-by: Rodrigo Siqueira
Tested-by: Rodrigo Siqueira
Signed-off-by: Daniel Vetter
Cc: Ro
With this we can drop the final kfree from the release function.
I also noticed that the unwind code is wrong, after drm_dev_init the
drm_device owns the v3d allocation, so the kfree(v3d) is a double-free.
Reorder the setup to fix this issue.
After a bit more prep in drivers and drm core v3d shou
Hi all,
Another round, another set of polish all over. intel-gfx-ci was happy last
time around (after I fixed a fumble), so really just review and comments
needed now. There's still a few patches at the beginning holding the
entire thing up and preventing merging of the driver patches which have
a
On Mon, Mar 23, 2020 at 04:36:16PM +0200, Lisovskiy, Stanislav wrote:
> On Mon, Mar 23, 2020 at 04:18:36PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 20, 2020 at 02:51:41PM +0200, Lisovskiy, Stanislav wrote:
> > > On Wed, Mar 11, 2020 at 06:31:30PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Mar 0
With this we can drop the final kfree from the release function.
Acked-by: Jyri Sarha
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
With this we can drop the final kfree from the release function.
v2: We need drm_dev_put to unroll the driver creation (once
drm_dev_init and drmm_add_final_kfree suceeded), otherwise
the drmm_ magic doesn't happen.
v3: Actually squash in the fixup (Laurent).
Acked-by: Thomas Zimmermann
Acked-b
They all share mipi_dbi_release so we need to switch them all
together. With this we can drop the final kfree from the release
function.
Aside, I think we could perhaps have a tiny additional helper for
these mipi_dbi drivers, the first few lines around devm_drm_dev_init
are all the same (except f
With this we can drop the final kfree from the release function.
Acked-by: Sam Ravnborg
Reviewed-by: Paul Cercueil
Signed-off-by: Daniel Vetter
Cc: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/
I also did a full review of all callers, and only the xen driver
forgot to call drm_dev_put in the failure path. Fix that up too.
v2: I noticed that xen has a drm_driver.release hook, and uses
drm_dev_alloc(). We need to remove the kfree from
xen_drm_drv_release().
bochs also has a release hook,
The cleanup here is somewhat tricky, since we can't tell apart the
allocated minor index from 0. So register a cleanup action first, and
if the index allocation fails, unregister that cleanup action again to
avoid bad mistakes.
The kdev for the minor already handles NULL, so no problem there.
Hen
With this we can drop the final kfree from the release function.
Acked-by: Sam Ravnborg
Reviewed-by: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/tiny/gm12u320.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/gm12
With this we can drop the final kfree from the release function.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 --
drivers/gpu/drm
We might want to look into pushing this down into drm_mm_init, but
that would mean rolling out return codes to a pile of functions
unfortunately. So let's leave that for now.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 8 +---
drivers/gpu/drm/dr
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after a
With this we can drop the final kfree from the release function.
Acked-by: Sam Ravnborg
Reviewed-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/repaper.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tin
With this we can drop the final kfree from the release function.
The mock device in the selftests needed it's pci_device split
up from the drm_device. In the future we could simplify this again
by allocating the pci_device as a managed allocation too.
v2: I overlooked that i915_driver_destroy is
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside: This dr
It's (almost, there's some iommu stuff without significance) right
above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup
Auto-unwind ftw, now possible with the fixed drm_device related
management.
Aside, clk/regulator seem to be missing devm versions for a bunch of
functions, preventing a pile of these simpler drivers from outright
losing their ->remove hook.
Reviewed-by: Linus Walleij
Signed-off-by: Daniel Vetter
Small mistake that crept into
commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab
Author: Gerd Hoffmann
Date: Tue Feb 11 14:52:18 2020 +0100
drm/bochs: add drm_driver.release callback
where drm_atomic_helper_shutdown was left in both places. The
->release callback really shouldn't touch hardw
Nothing special here, except that this is the first time that we
automatically clean up something that's initialized with an explicit
driver call. But the cleanup was done at the very end of the release
sequence for all drivers, and that's still the case. At least without
more uses of drmm_ through
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside: Another
A few things:
- Update the example driver in the documentation.
- We can drop the old kfree in drm_dev_release.
- Add a WARN_ON check in drm_dev_register to make sure everyone calls
drmm_add_final_kfree and there's no leaks.
v2: Restore the full cleanup, I accidentally left some moved code
behin
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: C
It has become empty. Given the few users I figured not much point
splitting this up.
v2: Rebase over i915 changes.
v3: Rebase over patch split fix.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus.c | 1 -
drivers/gpu/drm/drm_drv.c
We need to add a drmm_kstrdup for this, but let's start somewhere.
This is not exactly perfect onion unwinding, but it's jsut a kfree so
doesn't really matter at all.
Reviewed-by: Sam Ravnborg
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 5 ++--
Well for the simple stuff at least, vblank, gem and minor cleanup I
want to further split up as a demonstration.
v2: We need to clear drm_device->dev otherwise the debug drm printing
after our cleanup hook (e.g. in drm_manged_release) will chase
released memory and result in a use-after-free. Not
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc:
1 - 100 of 159 matches
Mail list logo
