Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_

On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote: > > > On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote: > > > >

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman > > wrote: > > > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > > Hi Daniel, > > > > > > > > Thank

[Intel-gfx] [PATCH 2/2] drm/i915/pmu: Avoid using globals for PMU events

Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915, will cause us to try and double free the global state, hitting null ptr deref in free_event_attributes. Let's move it to i915_pmu. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple

[Intel-gfx] [PATCH 1/2] drm/i915/pmu: Avoid using globals for CPU hotplug state

Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915 can lead to leaks and warnings from cpuhp: Error: Removing state XXX which has instances left. Let's move the state to i915_pmu. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple

[Intel-gfx] [PATCH i-g-t] tests/gem_userptr_blits: Refresh map-fixed-invalidate* subtests

map-fixed-invalidate* subtests utilize gem_set_tiling() which may fail, e.g. on hardware with no mappable aperture, due to missing fences. Skip those subtests if fences are not available. Moreover, those subtests use GEM_MMAP_GTT IOCTL which has been replaced by GEM_MMAP_OFFSET that supports

Re: [Intel-gfx] [PATCH 34/52] drm/mcde: More devm_drm_dev_init

On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > 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

Re: [Intel-gfx] [PATCH 13/52] drm/mcde: Use drmm_add_final_kfree

On Wed, Feb 19, 2020 at 11:21 AM Daniel Vetter wrote: > With this we can drop the final kfree from the release function. > > Signed-off-by: Daniel Vetter > Cc: Linus Walleij Reviewed-by: Linus Walleij Yours, Linus Walleij ___ Intel-gfx mailing

Re: [Intel-gfx] [PATCH 33/52] drm/mcde: Drop explicit drm_mode_config_cleanup call

On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > Allows us to drop the drm_driver.release callback. > > Signed-off-by: Daniel Vetter > Cc: Linus Walleij Reviewed-by: Linus Walleij Yours, Linus Walleij ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman > wrote: > > > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > > Hi Daniel, > > > > > > Thank you for the patch. > > > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100,

Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_

Hi Daniel, On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote: > > > drm_mode_config_cleanup is idempotent, so no harm in calling this > > > twice. This allows

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches (rev2) URL : https://patchwork.freedesktop.org/series/73637/ State : failure == Summary == Applying: drm/i915/selftest: Analyse timestamp behaviour across context

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Refactor Gen11+ SAGV support (rev2)

== Series Details == Series: Refactor Gen11+ SAGV support (rev2) URL : https://patchwork.freedesktop.org/series/73584/ State : failure == Summary == Applying: drm/i915: Start passing latency as parameter Applying: drm/i915: Introduce skl_plane_wm_level accessor. Applying: drm/i915: Init obj

Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_

On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote: > > drm_mode_config_cleanup is idempotent, so no harm in calling this > > twice. This allows us to gradually switch drivers over

[Intel-gfx] [PATCH] drm/i915: make dbuf configurations const

Ensure const data goes to rodata. Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes") Cc: Matt Roper Cc: Stanislav Lisovskiy Cc: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup

On Wed, Feb 19, 2020 at 4:38 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 04:27:57PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 3:35 PM Laurent Pinchart wrote: > > > On Wed, Feb 19, 2020 at 11:20:52AM +0100, Daniel Vetter wrote: > > > > Well for the simple

Re: [Intel-gfx] [PATCH 52/52] drm: Add docs for managed resources

On Wed, Feb 19, 2020 at 4:08 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:21:22AM +0100, Daniel Vetter wrote: > > All collected together to provide a consistent story in one patch, > > instead of the somewhat bumpy refactor-evolution

Re: [Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup

Hi Daniel, On Wed, Feb 19, 2020 at 04:27:57PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 3:35 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:52AM +0100, Daniel Vetter wrote: > > > Well for the simple stuff at least, vblank, gem and minor cleanup I > > > want to further

Re: [Intel-gfx] [PATCH 23/52] drm: manage drm_minor cleanup with drmm_

On Wed, Feb 19, 2020 at 3:47 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:53AM +0100, Daniel Vetter wrote: > > The cleanup here is somewhat tricky, since we can't tell apart the > > allocated minor index from 0. So register a cleanup

Re: [Intel-gfx] [PATCH 19/52] drm/: Use drmm_add_final_kfree

On Wed, Feb 19, 2020 at 3:39 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 03:30:59PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 3:11 PM Laurent Pinchart wrote: > > > On Wed, Feb 19, 2020 at 11:20:49AM +0100, Daniel Vetter wrote: > > > > These are the leftover

Re: [Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup

On Wed, Feb 19, 2020 at 3:35 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:52AM +0100, Daniel Vetter wrote: > > Well for the simple stuff at least, vblank, gem and minor cleanup I > > want to further split up as a demonstration. > > > >

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Avoid using globals for per-device state

Quoting Michał Winiarski (2020-02-19 15:08:04) > Attempting to bind / unbind module from devices where we have both > integrated and discreete GPU handed by i915 may lead to interesting > results where we're keeping per-device state in per-module globals. > > Fixes: 05488673a4d4 ("drm/i915/pmu:

Re: [Intel-gfx] [PATCH 21/52] drm: Handle dev->unique with drmm_

On Wed, Feb 19, 2020 at 3:28 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:51AM +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

[Intel-gfx] [PATCH] drm/i915/pmu: Avoid using globals for per-device state

Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handed by i915 may lead to interesting results where we're keeping per-device state in per-module globals. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Michał Winiarski

Re: [Intel-gfx] [PATCH 52/52] drm: Add docs for managed resources

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:21:22AM +0100, Daniel Vetter wrote: > 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: >

Re: [Intel-gfx] [PATCH 24/52] drm: Manage drm_gem_init with drmm_

On Wed, Feb 19, 2020 at 3:52 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 03:37:46PM +0100, Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 3:22 PM Laurent Pinchart wrote: > > > On Wed, Feb 19, 2020 at 11:20:54AM +0100, Daniel Vetter wrote: > > > > We might want to look

Re: [Intel-gfx] [PATCH 24/52] drm: Manage drm_gem_init with drmm_

Hi Daniel, On Wed, Feb 19, 2020 at 03:37:46PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 3:22 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:54AM +0100, Daniel Vetter wrote: > > > We might want to look into pushing this down into drm_mm_init, but > > > that would mean

Re: [Intel-gfx] [PATCH 23/52] drm: manage drm_minor cleanup with drmm_

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:53AM +0100, Daniel Vetter wrote: > 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

Re: [Intel-gfx] [PATCH 07/52] drm/udl: Use drmm_add_final_kfree

On Wed, Feb 19, 2020 at 2:42 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:37AM +0100, Daniel Vetter wrote: > > With this we can drop the final kfree from the release function. > > > > v2: We need drm_dev_put to unroll the driver creation

Re: [Intel-gfx] [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc

On Wed, Feb 19, 2020 at 2:39 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:34AM +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

Re: [Intel-gfx] [PATCH 19/52] drm/: Use drmm_add_final_kfree

Hi Daniel, On Wed, Feb 19, 2020 at 03:30:59PM +0100, Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 3:11 PM Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:49AM +0100, Daniel Vetter wrote: > > > These are the leftover drivers that didn't have a ->release hook that > > > needed to be

Re: [Intel-gfx] [PATCH 24/52] drm: Manage drm_gem_init with drmm_

On Wed, Feb 19, 2020 at 3:22 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:54AM +0100, Daniel Vetter wrote: > > 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

Re: [Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:52AM +0100, Daniel Vetter wrote: > 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 >

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

On Wed, Feb 19, 2020 at 2:29 PM Thomas Zimmermann wrote: > > Hi > > Am 19.02.20 um 14:23 schrieb Daniel Vetter: > > On Wed, Feb 19, 2020 at 12:47 PM Thomas Zimmermann > > wrote: > >> > >> Hi Daniel, > >> > >> good idea. I guess it's the simple encoder's fault. :) I only read > >> briefly over

Re: [Intel-gfx] [PATCH 19/52] drm/: Use drmm_add_final_kfree

On Wed, Feb 19, 2020 at 3:11 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:49AM +0100, Daniel Vetter wrote: > > These are the leftover drivers that didn't have a ->release hook that > > needed to be updated. > > > > Signed-off-by: Daniel

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

On Wed, Feb 19, 2020 at 2:53 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:21:07AM +0100, Daniel Vetter wrote: > > It's right above the drm_dev_put(). > > Could you mention in the commit message that the call can be dropped > because

Re: [Intel-gfx] [PATCH 21/52] drm: Handle dev->unique with drmm_

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:51AM +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 matter at all. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > Hi Daniel, > > > > Thank you for the patch. > > > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > > We have lots of these. And the cleanup code

Re: [Intel-gfx] [PATCH 24/52] drm: Manage drm_gem_init with drmm_

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:54AM +0100, Daniel Vetter wrote: > 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. > >

[Intel-gfx] [RFC PATCH v2] drm/i915/userptr: Activate MMU notifier only after pages are set

The purpose of userptr MMU notifier is to invalidate object pages as soon as someone unpins them from memory. While doing that, obj->mm.lock is acquired. If the notifier was called with obj->mm.lock already held, a lockdep loop would be triggered. That scenario is believed to be possible in

Re: [Intel-gfx] [PATCH 19/52] drm/: Use drmm_add_final_kfree

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:49AM +0100, Daniel Vetter wrote: > 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

Re: [Intel-gfx] [PATCH 40/52] drm/shmob: Drop explicit drm_mode_config_cleanup call

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:21:10AM +0100, Daniel Vetter wrote: > It's right above the drm_dev_put(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... With the same comments as the one for the

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 2:29 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:21:07AM +0100, Daniel Vetter wrote: > It's right above the drm_dev_put(). Could you mention in the commit message that the call can be dropped because drm_mode_config_init() uses the managed API to handle cleaning automatically,

Re: [Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote: > 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

Re: [Intel-gfx] [PATCH 07/52] drm/udl: Use drmm_add_final_kfree

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:37AM +0100, Daniel Vetter wrote: > 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 >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

== Series Details == Series: drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired URL : https://patchwork.freedesktop.org/series/73641/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16620

Re: [Intel-gfx] [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:34AM +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. I'd split this patch in two then, with the Xen first coming

[Intel-gfx] [CI] drm/i915: split i915_driver_modeset_probe() to pre/post irq install

Pair the irq install and uninstall in the same layer. There are no functional changes in the happy day scenario. The cleanup paths are currently a mess though. Note that modeset probe pre-irq + post-irq install are matched by modeset driver remove pre-irq + post-irq uninstall, together, but not

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Deactive FBC in fastsets when disabled by parameter

On Tue, Feb 18, 2020 at 05:42:28PM -0800, José Roberto de Souza wrote: > Most of the kms_frontbuffer_tracking tests disables the feature being > tested, draw, get the CRC then enable the feature, draw again, get the > CRC and check if it matches. > Some times it is able to do that with a fastset,

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that

Re: [Intel-gfx] [PATCH] drm/i915: Read rawclk_freq earlier

On Sun, Feb 16, 2020 at 04:34:45PM +, Chris Wilson wrote: > Read the rawclk_freq during runtime info probing, prior to its first use > in computing the CS timestamp frequency. Then store it in the runtime > info, and include it in the debug printouts. > > Closes:

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

Hi Am 19.02.20 um 14:23 schrieb Daniel Vetter: > On Wed, Feb 19, 2020 at 12:47 PM Thomas Zimmermann > wrote: >> >> Hi Daniel, >> >> good idea. I guess it's the simple encoder's fault. :) I only read >> briefly over the whole thing. >> >> Am 19.02.20 um 11:20 schrieb Daniel Vetter: >>> They all

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

Hi Daniel, Thank you for the patch. On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > 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

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

On Wed, Feb 19, 2020 at 1:31 PM Neil Armstrong wrote: > > Hi, > > On 19/02/2020 11:20, Daniel Vetter wrote: > > 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

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

On Wed, Feb 19, 2020 at 12:47 PM Thomas Zimmermann wrote: > > Hi Daniel, > > good idea. I guess it's the simple encoder's fault. :) I only read > briefly over the whole thing. > > Am 19.02.20 um 11:20 schrieb Daniel Vetter: > > They all share mipi_dbi_release so we need to switch them all > >

Re: [Intel-gfx] [PATCH] drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx

Hi Chris, On Wed, Feb 19, 2020 at 01:01:19PM +, Chris Wilson wrote: > For dgfx, we do not need to reconfigure the IA/ring frequencies of the > main processors as they are distinct devices. > > Signed-off-by: Chris Wilson > Cc: Andi Shyti > Cc: Tvrtko Ursulin looks good: Reveiwed-by:

Re: [Intel-gfx] [CI 1/2] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall

On Fri, 14 Feb 2020, Jani Nikula wrote: > Split intel_modeset_driver_remove() to two, the part with working irqs > before irq uninstall, and the part after irq uninstall. Move > irq_unintall() closer to the layer it belongs. > > The error path in i915_driver_modeset_probe() looks obviously weird

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Iterate over pipe and skip the disabled one

On Tue, Feb 18, 2020 at 11:23:43PM +0530, Anshuman Gupta wrote: > On 2020-02-07 at 16:47:53 +0200, Ville Syrjälä wrote: > > On Fri, Feb 07, 2020 at 07:50:37PM +0530, Anshuman Gupta wrote: > > > It should not be assumed that a disabled display pipe will be > > > always last the pipe. > > >

Re: [Intel-gfx] [PATCH] drm/i915/gem: use spinlock_t instead of struct spinlock

On Tue, 18 Feb 2020, Jani Nikula wrote: > On Mon, 17 Feb 2020, Chris Wilson wrote: >> Quoting Jani Nikula (2020-02-17 18:42:19) >>> spinlock_t is one case where the typedef is to be preferred over struct >>> spinlock. >>> >>> Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent

Re: [Intel-gfx] [RFC PATCH] drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

Hi Chris, On Wednesday, February 19, 2020 1:17:12 PM CET Chris Wilson wrote: > Quoting Janusz Krzysztofik (2020-02-19 12:09:44) > > The purpose of userptr MMU notifier is to invalidate object pages as > > soon as someone unpins them from memory. While doing that, > > obj->mm.lock is acquired.

[Intel-gfx] [PATCH] drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx

For dgfx, we do not need to reconfigure the IA/ring frequencies of the main processors as they are distinct devices. Signed-off-by: Chris Wilson Cc: Andi Shyti Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_llc.c| 6 -- drivers/gpu/drm/i915/gt/selftest_llc.c | 11 ++- 2

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

Am 19.02.20 um 12:47 schrieb Thomas Zimmermann: > Hi Daniel, > > good idea. I guess it's the simple encoder's fault. :) I only read > briefly over the whole thing. > > Am 19.02.20 um 11:20 schrieb Daniel Vetter: >> They all share mipi_dbi_release so we need to switch them all >> together. With

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

On Wed, Feb 19, 2020 at 02:17:27PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Wed, Feb 19, 2020 at 12:10:18PM +0100, Geert Uytterhoeven wrote: > > On Wed, Feb 19, 2020 at 11:57 AM Daniel Vetter wrote: > > > On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven wrote: > > > > On Wed, Feb 19,

[Intel-gfx] [PATCH v2] drm/i915/selftests: Mark GPR checking more hostile

Currently, we check that a new context has a clear set of general purpose registers. Add a little bit of hostility by preempting our new context and re-poisoning the GPR to ensure that there is no context leakage from preemption. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

Hi, On 19/02/2020 11:20, Daniel Vetter wrote: > 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

[Intel-gfx] [PATCH v16 4/7] drm/i915: Refactor intel_can_enable_sagv

Currently intel_can_enable_sagv function contains a mix of workarounds for different platforms some of them are not valid for gens >= 11 already, so lets split it into separate functions. v2: - Rework watermark calculation algorithm to attempt to calculate Level 0 watermark with

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, On Wed, Feb 19, 2020 at 12:10:18PM +0100, Geert Uytterhoeven wrote: > On Wed, Feb 19, 2020 at 11:57 AM Daniel Vetter wrote: > > On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven wrote: > > > On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > > > > It's right above the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches

== Series Details == Series: series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches URL : https://patchwork.freedesktop.org/series/73637/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16619

Re: [Intel-gfx] [RFC PATCH] drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

Quoting Janusz Krzysztofik (2020-02-19 12:09:44) > The purpose of userptr MMU notifier is to invalidate object pages as > soon as someone unpins them from memory. While doing that, > obj->mm.lock is acquired. If the notifier was called with obj->mm.lock > already held, a lockdep loop would be

[Intel-gfx] [PATCH i-g-t] i915/gem_vm_create: Call set-domain manually

Since we are secretly using execbuf to write into an object's location, then read back from the object we must manually handle the domain changes. Closes: https://gitlab.freedesktop.org/drm/intel/issues/314 Signed-off-by: Chris Wilson --- tests/i915/gem_vm_create.c | 4 1 file changed, 4

[Intel-gfx] [RFC PATCH] drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired

The purpose of userptr MMU notifier is to invalidate object pages as soon as someone unpins them from memory. While doing that, obj->mm.lock is acquired. If the notifier was called with obj->mm.lock already held, a lockdep loop would be triggered. That scenario is believed to be possible in

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: use spinlock_t instead of struct spinlock

== Series Details == Series: drm/i915/gem: use spinlock_t instead of struct spinlock URL : https://patchwork.freedesktop.org/series/73546/ State : success == Summary == CI Bug Log - changes from CI_DRM_7957_full -> Patchwork_16595_full

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches

== Series Details == Series: series starting with [1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches URL : https://patchwork.freedesktop.org/series/73637/ State : warning == Summary == $ dim checkpatch origin/drm-tip e360e7c59c3d drm/i915/selftest: Analyse timestamp

[Intel-gfx] ✓ Fi.CI.BAT: success for drm_device managed resources

== Series Details == Series: drm_device managed resources URL : https://patchwork.freedesktop.org/series/73633/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16618 Summary --- **SUCCESS** No

Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers

Hi Daniel, good idea. I guess it's the simple encoder's fault. :) I only read briefly over the whole thing. Am 19.02.20 um 11:20 schrieb Daniel Vetter: > 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. >

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm_device managed resources

== Series Details == Series: drm_device managed resources URL : https://patchwork.freedesktop.org/series/73633/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: mm/sl[uo]b: export __kmalloc_track(_node)_caller Okay!

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm_device managed resources

== Series Details == Series: drm_device managed resources URL : https://patchwork.freedesktop.org/series/73633/ State : warning == Summary == $ dim checkpatch origin/drm-tip 913ef020101d mm/sl[uo]b: export __kmalloc_track(_node)_caller -:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by:

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Mark GPR checking more hostile

Currently, we check that a new context has a clear set of general purpose registers. Add a little bit of hostility by preempting our new context and re-poisoning the GPR to ensure that there is no context leakage from preemption. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 1/2] drm/i915/selftest: Analyse timestamp behaviour across context switches

Check that the CTX_TIMESTAMP is monotonic across context save/restore and upon preemption. References: https://gitlab.freedesktop.org/drm/intel/issues/1233 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 229 + 1 file changed, 229 insertions(+)

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, On Wed, Feb 19, 2020 at 11:57 AM Daniel Vetter wrote: > On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven > wrote: > > On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter > > wrote: > > > It's right above the drm_dev_put(). > > > > > > Aside: Another driver with a bit much

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: conversion to struct drm_device based logging macros. (rev2)

== Series Details == Series: drm/i915/perf: conversion to struct drm_device based logging macros. (rev2) URL : https://patchwork.freedesktop.org/series/73589/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16617

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Introduce struct drm_device based WARN* and use them in i915 (rev6)

> -Original Message- > From: Jani Nikula > Sent: 19 February 2020 16:25 > To: Patchwork ; Laxminarayan Bharadiya, > Pankaj > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Introduce struct > drm_device based WARN* and use them in i915

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

On Wed, Feb 19, 2020 at 11:30 AM Geert Uytterhoeven wrote: > > Hi Daniel, > > On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > > It's right above the drm_dev_put(). > > > > Aside: Another driver with a bit much devm_kzalloc, which should > > probably use drmm_kzalloc instead ... > >

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Introduce struct drm_device based WARN* and use them in i915 (rev6)

On Wed, 05 Feb 2020, Patchwork wrote: > == Series Details == > > Series: drm: Introduce struct drm_device based WARN* and use them in i915 > (rev6) > URL : https://patchwork.freedesktop.org/series/72035/ > State : failure > > == Summary == > > Applying: drm/i915/display/cdclk: Make WARN* drm

Re: [Intel-gfx] [PATCH 35/52] drm/meson: Drop explicit drm_mode_config_cleanup call

On 19/02/2020 11:21, Daniel Vetter wrote: > It's right above the drm_dev_put(). > > Aside: This driver gets its devm_ stuff all wrong wrt drm_device and > anything hanging off that. Not the only one unfortunately. > > Signed-off-by: Daniel Vetter > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc:

Re: [Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

Hi Daniel, On Wed, Feb 19, 2020 at 11:22 AM Daniel Vetter wrote: > It's right above the drm_dev_put(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... What's drmm_kzalloc()? The only references I can find are in this patch series.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: conversion to struct drm_device based logging macros. (rev2)

== Series Details == Series: drm/i915/perf: conversion to struct drm_device based logging macros. (rev2) URL : https://patchwork.freedesktop.org/series/73589/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9139cc1d6f24 drm/i915/perf: conversion to struct drm_device based

[Intel-gfx] [PATCH 22/52] drm: Use drmm_ for drm_dev_init cleanup

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

[Intel-gfx] [PATCH 29/52] drm/bochs: Drop explicit drm_mode_config_cleanup

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. Signed-off-by: Daniel Vetter Cc: Gerd Hoffmann Cc:

[Intel-gfx] [PATCH 52/52] drm: Add docs for managed resources

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();

[Intel-gfx] [PATCH 30/52] drm/cirrus: Drop explicit drm_mode_config_cleanup call

We can even delete the drm_driver.release hook now! Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Daniel Vetter Cc: "Noralf Trønnes" Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: virtualizat...@lists.linux-foundation.org --- drivers/gpu/drm/cirrus/cirrus.c | 21

[Intel-gfx] [PATCH 41/52] drm/mtk: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git

[Intel-gfx] [PATCH 37/52] drm/rcar-du: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1

[Intel-gfx] [PATCH 51/52] drm/udl: drop drm_driver.release hook

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

[Intel-gfx] [PATCH 40/52] drm/shmob: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/shmobile/shmob_drm_drv.c |

[Intel-gfx] [PATCH 43/52] drm/gm12u320: More drmm_

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" ---

[Intel-gfx] [PATCH 45/52] drm/gm12u320: Use helpers for shutdown/suspend/resume

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:

[Intel-gfx] [PATCH 48/52] drm/mipi-dbi: Move drm_mode_config_init into mipi library

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. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mipi_dbi.c | 4 drivers/gpu/drm/tiny/hx8357d.c | 2 --

[Intel-gfx] [PATCH 34/52] drm/mcde: More devm_drm_dev_init

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. Signed-off-by: Daniel Vetter Cc: Linus Walleij ---

[Intel-gfx] [PATCH 35/52] drm/meson: Drop explicit drm_mode_config_cleanup call

It's right above the drm_dev_put(). Aside: This driver gets its devm_ stuff all wrong wrt drm_device and anything hanging off that. Not the only one unfortunately. Signed-off-by: Daniel Vetter Cc: Neil Armstrong Cc: Kevin Hilman Cc: linux-amlo...@lists.infradead.org Cc:

<    1   2   3   >