On 2/21/20 9:49 PM, Masahiro Yamada wrote:
> On Sat, Feb 22, 2020 at 2:25 PM Randy Dunlap wrote:
>>
>> On 2/21/20 8:53 PM, Masahiro Yamada wrote:
>>> On Sat, Feb 22, 2020 at 1:43 PM Masahiro Yamada
>>> wrote:
Hi Jani,
On Fri, Feb 21, 2020 at 7:54 PM Jani Nikula wrote:
>
On 2/21/20 8:53 PM, Masahiro Yamada wrote:
> On Sat, Feb 22, 2020 at 1:43 PM Masahiro Yamada wrote:
>>
>> Hi Jani,
>>
>> On Fri, Feb 21, 2020 at 7:54 PM Jani Nikula wrote:
>>>
>>> $(CC) with $(CFLAGS_GCOV) assumes the output filename with .gcno suffix
>>> appended is writable. This is not the
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73686/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7969_full -> Patchwork_16639_full
Summary
---
== Series Details ==
Series: series starting with [1/8] drm/i915/tgl: Extend Wa_1409825376 stepping
URL : https://patchwork.freedesktop.org/series/73802/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16675
== Series Details ==
Series: drm/i915/tgl: Add Wa_1608008084
URL : https://patchwork.freedesktop.org/series/73801/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16674
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/gt: Push the GPU cancellation to the backend (rev2)
URL : https://patchwork.freedesktop.org/series/73800/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16673
Summary
On Wed, 19 Feb 2020, Daniel Vetter wrote:
> 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.
Would be better to export it without
== Series Details ==
Series: drm/i915: Avoid recursing onto active vma from the shrinker
URL : https://patchwork.freedesktop.org/series/73799/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16672
Summary
== Series Details ==
Series: drm/i915/ehl: Donot reuse icl get and put dplls (rev2)
URL : https://patchwork.freedesktop.org/series/73681/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7968_full -> Patchwork_16638_full
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev7)
URL : https://patchwork.freedesktop.org/series/73436/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16671
== Series Details ==
Series: drm managed resources, v2
URL : https://patchwork.freedesktop.org/series/73794/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16670
Summary
---
**SUCCESS**
No
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip v5.6-rc2 next-20200221]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also
== Series Details ==
Series: drm managed resources, v2
URL : https://patchwork.freedesktop.org/series/73794/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: mm/sl[uo]b: export __kmalloc_track(_node)_caller
Okay!
== Series Details ==
Series: drm managed resources, v2
URL : https://patchwork.freedesktop.org/series/73794/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d65ee94cba2c mm/sl[uo]b: export __kmalloc_track(_node)_caller
-:58: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by:
This Wa will also be needed by B0 stepping.
BSpec: 52890
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
This workaround is only fixed in C0 stepping to extend it to B0 too.
BSpec: 52890
Cc: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Anusha Srivatsa
According to BSpec. Wa_1606931601 applies for all
TGL steppings.This patch moves the WA implementation
out of A0 only block of rcs_engine_wa_init().
The WA is has also been referred to by an alternate name
Wa_1607090982.
Bspec: 46045, 52890
Fixes: 3873fd1a43c7
From: Matt Atwood
Disable Push Constant buffer addition for TGL.
v2: typos, add additional Wa reference
v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit
message.
Bspec: 52890
Cc: Rafael Antognolli
Cc: Matt Roper
Signed-off-by: Matt Atwood
Signed-off-by: José Roberto de
This workaround the CS not done issue on PIPE_CONTROL.
BSpec: 52890
BSpec: 46218
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
2 files changed, 9 insertions(+), 2
This will whitelist the HIZ_CHICKEN register so mesa can disable the
optimizations and void hang when using D16_UNORM.
Cc: Matt Roper
Cc: Rafael Antognolli
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4
drivers/gpu/drm/i915/i915_reg.h
This issue workaround in Wa_1607063988 has the same fix as
Wa_1607138336, so just adding a note in the code.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Add note about the confliting information in BSpec about this WA.
BSpec: 52890
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
== Series Details ==
Series: drm/i915/selftests: Verify LRC isolation
URL : https://patchwork.freedesktop.org/series/73788/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16669
Summary
---
On Fri, Feb 21, 2020 at 04:36:53PM -0800, Jose Souza wrote:
+ CCing people involved in the patch fixed.
On Fri, 2020-02-21 at 16:28 -0800, Lucas De Marchi wrote:
Wa_1608008084 is an additional WA that applies to writes on FF_MODE2
register. We can't read it back either from CPU or GPU. Since
== Series Details ==
Series: drm/i915/selftests: Verify LRC isolation
URL : https://patchwork.freedesktop.org/series/73788/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
14585105911e drm/i915/selftests: Verify LRC isolation
-:123: CHECK:PARENTHESIS_ALIGNMENT: Alignment should
== Series Details ==
Series: series starting with [resend,1/2] drm/i915: panel: Use
intel_panel_compute_brightness() from pwm_setup_backlight()
URL : https://patchwork.freedesktop.org/series/73784/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16668
== Series Details ==
Series: series starting with [1/7] dma-buf: add dynamic DMA-buf handling v15
(rev2)
URL : https://patchwork.freedesktop.org/series/73665/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16667
== Series Details ==
Series: series starting with [resend,1/2] drm/i915: panel: Use
intel_panel_compute_brightness() from pwm_setup_backlight()
URL : https://patchwork.freedesktop.org/series/73784/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8beab9ed3934 drm/i915: panel:
On Tue, 2020-02-18 at 17:02 -0500, Sean Paul wrote:
> From: Sean Paul
>
> Hey all,
> Back with a v4. Rebased on latest drm-tip.
>
> Biggest change was adding the QUERY_STREAM_ENCRYPTION_STATUS check
> which
> ensures not only the link to the first branch is encrypted, but also
> that the
== Series Details ==
Series: series starting with [1/7] dma-buf: add dynamic DMA-buf handling v15
(rev2)
URL : https://patchwork.freedesktop.org/series/73665/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bbe4554189c9 dma-buf: add dynamic DMA-buf handling v15
-:10:
+ CCing people involved in the patch fixed.
On Fri, 2020-02-21 at 16:28 -0800, Lucas De Marchi wrote:
> Wa_1608008084 is an additional WA that applies to writes on FF_MODE2
> register. We can't read it back either from CPU or GPU. Since the
> other
> bits should be 0, recommendation to handle
Hi Chris,
On Fri, Feb 21, 2020 at 11:51:35PM +, Chris Wilson wrote:
> Upon unregistering the user interface, we mark the GPU as wedged to
> ensure we push no new work to the GPU, and to flush all current work
> from the GPU. Move this call to the GT backend.
>
> Signed-off-by: Chris Wilson
== Series Details ==
Series: drm/i915: Correctly terminate connector iteration
URL : https://patchwork.freedesktop.org/series/73779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_1
Summary
---
Wa_1608008084 is an additional WA that applies to writes on FF_MODE2
register. We can't read it back either from CPU or GPU. Since the other
bits should be 0, recommendation to handle Wa_1604555607 is to actually
just write the timer value.
Do a write only and don't try to read it, neither before
== Series Details ==
Series: drm/i915/huc: Fix error reported by I915_PARAM_HUC_STATUS (rev2)
URL : https://patchwork.freedesktop.org/series/72419/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7984 -> Patchwork_16665
Upon unregistering the user interface, we mark the GPU as wedged to
ensure we push no new work to the GPU, and to flush all current work
from the GPU. Move this call to the GT backend.
Signed-off-by: Chris Wilson
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.c | 7 +++
== Series Details ==
Series: drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev4)
URL : https://patchwork.freedesktop.org/series/72747/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7967_full -> Patchwork_16637_full
== Series Details ==
Series: drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev3)
URL : https://patchwork.freedesktop.org/series/73718/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7983 -> Patchwork_16664
On Fri, Feb 21, 2020 at 10:45:07PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/tgl: Add Wa_22010178259:tgl (rev2)
> URL : https://patchwork.freedesktop.org/series/73255/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7967_full ->
Upon unregistering the user interface, we mark the GPU as wedged to
ensure we push no new work to the GPU, and to flush all current work
from the GPU. Move this call to the GT backend.
Signed-off-by: Chris Wilson
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.c | 7 +++
== Series Details ==
Series: drm/i915/tgl: Add Wa_22010178259:tgl (rev2)
URL : https://patchwork.freedesktop.org/series/73255/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7967_full -> Patchwork_16634_full
Summary
---
We mark the vma as active while binding it in order to protect outselves
from being shrunk under mempressure. This only works if we are strict in
not attempting to shrink active objects.
<6> [472.618968] Workqueue: events_unbound fence_work [i915]
<4> [472.618970] Call Trace:
<4> [472.618974] ?
== Series Details ==
Series: dma-buf: Precheck for a valid dma_fence before acquiring the reference
URL : https://patchwork.freedesktop.org/series/73772/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7983 -> Patchwork_16663
On 2/14/20 6:33 PM, Dale B Stimson wrote:
From: Chris Wilson
Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.
Subsequent to sign-off by Chris Wilson,
On 2/14/20 6:33 PM, Dale B Stimson wrote:
Signed-off-by: Dale B Stimson
Acked-by: Robert M. Fosha
---
lib/Makefile.sources | 2 +
lib/i915/gem_mmio_base.c | 353 +++
lib/i915/gem_mmio_base.h | 19 +++
lib/igt.h| 1 +
== Series Details ==
Series: drm/i915/gt: Protect signaler walk with RCU (rev2)
URL : https://patchwork.freedesktop.org/series/73601/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7967_full -> Patchwork_16633_full
Summary
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev2)
URL : https://patchwork.freedesktop.org/series/73703/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7983 -> Patchwork_16662
Summary
---
**SUCCESS**
Quoting Daniel Vetter (2020-02-21 21:02:30)
> For two reasons:
>
> - The driver core clears this already for us after we're unloaded in
> __device_release_driver().
Even if we abort before loading?
History notes that i915_pci_remove was called with a stale pointer on
error.
-Chris
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev2)
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Introduce
Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
once to enable PSR") was forcing the state compute too earlier
causing errors because not everything was initialized, so here
moving to the end of i915_driver_modeset_probe() when the display is
all initialized.
Also fixing the
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev2)
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ba1e4cbe4558 drm/i915: Start passing latency as parameter
2712b33bd072 drm/i915: Introduce skl_plane_wm_level
On Fri, 2020-02-21 at 12:11 -0800, Souza, Jose wrote:
> On Fri, 2020-02-21 at 20:04 +, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-02-20 at 15:15 -0800, José Roberto de Souza wrote:
> > > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
> > > phase
> > > once to enable PSR") was
== Series Details ==
Series: series starting with [1/3] drm/i915: Flush idle barriers when waiting
(rev2)
URL : https://patchwork.freedesktop.org/series/73751/
State : failure
== Summary ==
Applying: drm/i915: Flush idle barriers when waiting
Applying: drm/i915: Allow userspace to specify
Hi Daniel.
> What I miss in all of this is how do other subsystems deal
> with the different lifetime of their stuff?
> Or maybe only drm really has this issue?
> Anything we could learn from others?
Reading through the thread - this is all covered in more than sufficient
details in other mails.
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:
Also there's a race in the disconnect implemenation. First shut
down, then unplug, leaves a window where userspace could sneak
in and restart the entire machinery.
With this we can also delete the very un-atomic global pipe_enabled
tracking.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc:
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
Allows us to drop the drm_driver.release callback from all
drivers, and remove the mipi_dbi_release() function.
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
7/7 drivers agree that's the right choice, let's do this.
This avoids duplicating the same old error checking code over all 7
drivers, which is the motivation here.
Reviewed-by: Noralf Trønnes
Tested-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc:
The drm_mode_config_cleanup call we can drop, and all the allocations
we can switch over to drmm_kzalloc. Unfortunately the work queue is
still present, so can't get rid of the drm_driver->release function
outright.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
---
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().
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:
All collected together to provide a consistent story in one patch,
instead of the somewhat bumpy refactor-evolution leading to this.
Also some thoughts on what the next steps could be:
- Create a macro called devm_drm_dev_alloc() which essentially wraps
the kzalloc(); devm_drm_dev_init();
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().
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
Instead of having a work item that never stops (which really should be
a kthread), with a dedicated workqueue to not upset anyone else, use a
delayed work. A bunch of changes:
- We can throw out all the custom wakeup and requeue logic and state
tracking. If we schedule the work with a 0 delay
Only drops the drm_dev_put, but hey a few lines!
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/gm12u320.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c
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
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:
We can even delete the drm_driver.release hook now!
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
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
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 of the release
sequence for all drivers, and that's still the case. At least without
more uses of drmm_ through
There's only two functions called from that:
drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are
also called from the ubs_driver->disconnect hook, so entirely
pointless to do the same again in the ->release hook.
Furthermore by the time we clean up the drm_driver we really
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.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 11
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.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 8 +---
drivers/gpu/drm/drm_gem.c | 21
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.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc:
It has become empty. Given the few users I figured not much point
splitting this up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus.c | 1 -
drivers/gpu/drm/drm_drv.c | 23 +--
drivers/gpu/drm/drm_mipi_dbi.c| 1
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:
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
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:
drm_mode_config_cleanup is idempotent, so no harm in calling this
twice. This allows us to gradually switch drivers over by removing
explicit drm_mode_config_cleanup calls.
With this step it's not also possible that (at least for simple
drivers) automatic resource cleanup can be done correctly
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
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().
It's right above the drm_dev_put().
This allows us to delete a bit of onion unwinding in
udl_modeset_init().
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
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.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 5 ++---
drivers/gpu/drm/drm_managed.c | 16
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.
Instead rely on the automatic clean, for which we just need to check
that drm_mode_config_init succeeded. To avoid an inversion in the
cleanup we also have to move the dev_private allocation over to
drmm_kzalloc.
This is made possible by a preceeding patch which added a drmm_
cleanup action to
With this we can drop the final kfree from the release function.
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/tiny/repaper.c
With this we can drop the final kfree from the release function.
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/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index
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
With this we can drop the final kfree from the release function.
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.
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
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).
Signed-off-by: Daniel Vetter
Cc:
With this we can drop the final kfree from the release function.
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/ingenic/ingenic-drm.c
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.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Chris Wilson
Cc: Sean
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
These are the leftover drivers that didn't have a ->release hook that
needed to be updated.
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Cc: Russell King
Cc: Hans de Goede
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 ++
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
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.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc:
With this we can drop the final kfree from the release function.
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/qxl/qxl_kms.c | 2 ++
2
1 - 100 of 200 matches
Mail list logo
