- 21 Jun, 2016 9 commits
-
-
Daniel Vetter authored
Rockchip just blew up here on testing, because I removed some "is this crtc already disabled/enabled" state tracking from callbacks (not needed with atomic). Turns out that was needed to work around rockchip still calling legacy helper code. Since me explaining on irc/mailing-list plus kerneldoc isn't enough, be more verbose and add dmesg output. Not that anyone actually reads that, either. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-26-git-send-email-daniel.vetter@ffwll.ch
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Tested-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Tomasz Figa authored
Currently the driver calls drm_dev_register() directly after allocating the DRM device and then continues with further initialization. This is incorrect, because drm_dev_register() is supposed to be called after all initialization is done. This problem was masked by the fact that drm_dev_register() did not use to do anything special before, but recently it started to call drm_connector_register_all(), which leads to a crash if the driver is not fully initialized. This patch fixes the problem by moving the call to drm_dev_register() to the end of the initialization sequence and also removing the, now unnecessary, call to drm_connector_register_all() from driver code. Fixes: f706974a ("drm/rockchip: Drop drm_driver.load/unload callbacks") Signed-off-by:
Tomasz Figa <tfiga@chromium.org> [danvet: Fix up cleanup labels a bit.] Signed-off-by:
-
Daniel Vetter authored
It's a legacy helper function which won't do good with atomic helpers. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465510479-21180-1-git-send-email-daniel.vetter@ffwll.ch
-
- 20 Jun, 2016 11 commits
-
-
Daniel Vetter authored
Again this is neatly protected by the dev->master_mutex now. There is a driver callback both for set and drop, but it's only used by vmwgfx. And vmwgfx has it's own solid locking for shared resources (besides dev->master_mutex), hence is all safe. Let's drop another place where the drm legacy bkl is used. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Daniel Vetter authored
All protected by dev->master_mutex. And there's no driver callbacks, which means no need to sync with old dri1 horror show drivers at all. Hence safe to drop the drm legacy BKL from these paths. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
Simplifies cleanup, and there's no reason drivers should ever care about authmagic at all - it's all handled in the core. And with that, Ladies and Gentlemen, it's time to pop the champagen and celebrate: dev->struct_mutex is now officially gone from modern drivers, and if a driver is using gem_free_object_unlocked and doesn't do anything else silly it's positively impossible to ever touch dev->struct_mutex at runtime, anywhere. Well except for the mutex_init on driver load ;-) v2: Rebased. Cc: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by:
-
Daniel Vetter authored
It's related, and soon authmagic will also use the master_mutex. There is an ever-so-slightly semantic change here: - authmagic will only be cleaned up for primary_client drm_minors. But it's impossible to create authmagic on render/control nodes, so this is fine. - The cleanup is moved down a bit in the release processing. Doesn't matter at all since authmagic is purely internal logic used by the core ioctl access checks, and when we're in a file's release callback no one can do ioctls any more. v2: Rebased. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by:
-
Daniel Vetter authored
Another place gone where modern drivers could have hit dev->struct_mutex. To avoid too deeply nesting control flow rework it a bit. v2: Review from Chris: - remove spurious newline. - fix file_priv->master like for the !file_priv->is_master case. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
If a driver does not have a parent, or never sets the unique name for itself, then we may proceed to chase a NULL dereference through debugfs/.../name. Testcase: igt/vgem_basic/debugfs Signed-off-by:
-
Matthew Auld authored
The drm_pending_event can be freed by drm_send_event_locked, as a result we should call trace_drm_vblank_event_delivered before this to avoid hitting a user-after-free error when accessing the pid member: [ 378.438497] BUG: KASAN: use-after-free in send_vblank_event+0xf0/0x310 [drm] at addr ffff8801ac7e50a0 [ 378.438500] Read of size 4 by task Xorg/1562 [ 378.438501] ============================================================================= [ 378.438504] BUG kmalloc-128 (Tainted: G B ): kasan: bad access detected [ 378.438506] ----------------------------------------------------------------------------- [ 378.438509] INFO: Freed in 0x10001309c age=18446737369265680575 cpu=0 pid=0 [ 378.438541] drm_send_event_locked+0x207/0x2f0 [drm] [ 378.438544] __slab_free+0x24c/0x650 [ 378.438546] kfree+0x3a2/0x760 [ 378.438578] drm_send_event_locked+0x207/0x2f0 [drm] [ 378.438610] send_vblank_event+0xb7/0x310 [drm] [ 378.438643] drm_crtc_send_vblank_event+0x130/0x1f0 [drm] [ 378.438722] intel_atomic_commit_tail+0x23b5/0x53f0 [i915] [ 378.438802] intel_atomic_commit+0xbae/0x12f0 [i915] [ 378.438839] drm_atomic_commit+0xb0/0x120 [drm] [ 378.438855] drm_atomic_helper_connector_dpms+0x339/0x5d0 [drm_kms_helper] [ 378.438891] drm_mode_obj_set_property_ioctl+0x8f1/0xcc0 [drm] [ 378.438927] drm_mode_connector_property_set_ioctl+0xf3/0x170 [drm] [ 378.438959] drm_ioctl+0x2d7/0xae0 [drm] [ 378.438962] do_vfs_ioctl+0x1c9/0x1280 [ 378.438964] SyS_ioctl+0x79/0x90 [ 378.438967] entry_SYSCALL_64_fastpath+0x1a/0xa4 Cc: dri-devel@lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Mathias Krause authored
There is only a single user of dma_buf_debugfs_create_file() and that one got the function pointer cast wrong. With that one fixed, there is no need to have a wrapper for debugfs_create_file(), just call it directly. With no users left, we can remove dma_buf_debugfs_create_file(). While at it, simplify the error handling in dma_buf_init_debugfs() slightly. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/1466339491-12639-2-git-send-email-minipli@googlemail.com
-
Mathias Krause authored
Change the error handling in dma_buf_init_debugfs() to remove the "dma_buf" directory if creating the "bufinfo" file fails. No need to have an empty debugfs directory around. Signed-off-by:
-
Mathias Krause authored
The callback function dma_buf_describe() returns an int not void so the function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can also fail when acquiring the mutex gets interrupted so always returning 0 in dma_buf_show() is wrong, too. Fix both issues by avoiding the indirection via dma_buf_show() and call dma_buf_describe() directly. Rename it to dma_buf_debug_show() to get it in line with the other functions. This type mismatch was caught by the PaX RAP plugin. Signed-off-by:
-
Chris Wilson authored
The drm_dp_aux is associated with the intel_dp encoder and not the connector. Since the encoder is destroyed before the connector, attempting to free the drm_dp_aux from inside the connector cleanup causes a use-after-free. This was applied to the patch that CI was happy with, but in the confusion of so many series trying to make CI happy, the unready patch was plucked. Fixes: c191eca1 ("drm/i915: Move intel_connector->unregister to connector->early_unregister") Signed-off-by:
-
- 19 Jun, 2016 2 commits
-
-
Chris Wilson authored
Currently the backlight is being unregistered in the unload phase (after the display and its objects are unregistered). Move the backlight unregistration into the analogous phase by performing it from the connector unregistration, just prior to its deletion. Signed-off-by:
-
Chris Wilson authored
We now have a connector->func that serves the same purpose as our own intel_connector->unregister vfunc allowing us to unwrap ourselves and use drm_connector_register() (and friends) as the central function. Signed-off-by:
-
- 18 Jun, 2016 1 commit
-
-
Chris Wilson authored
0-day kbuilder found [ 1.360244] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1.360972] IP: [<c14db9ad>] mutex_lock_nested+0x11f/0x2c3 [ 1.361512] *pde = 00000000 [ 1.361827] Oops: 0002 [#1] [ 1.362123] Modules linked in: [ 1.362451] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-rc2-00564-ge28cd4d0 #1 [ 1.363202] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 1.364105] task: c03d0000 ti: d28da000 task.ti: d28da000 [ 1.364636] EIP: 0060:[<c14db9ad>] EFLAGS: 00210096 CPU: 0 [ 1.365215] EIP is at mutex_lock_nested+0x11f/0x2c3 [ 1.365703] EAX: 00000000 EBX: d39e8ae8 ECX: d39e8b14 EDX: c1361cf9 [ 1.366351] ESI: c03d0000 EDI: d28dbed0 EBP: d28dbeec ESP: d28dbec0 [ 1.367010] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 1.367534] CR0: 80050033 CR2: 00000000 CR3: 019a9000 CR4: 00000690 [ 1.368152] Stack: [ 1.368356] d39e8b14 d39e8b24 c1361cf9 00200246 d39e8b14 00000000 11111111 d28dbed0 [ 1.369235] d39e8800 d39e8ae8 00000000 d28dbf08 c1361cf9 d28dbf0c c10b25be d39e8800 [ 1.370087] 00000000 00000000 d28dbf1c c135e37d fffffff4 ffffffff 00000000 d28dbf28 [ 1.371012] Call Trace: [ 1.371272] [<c1361cf9>] ? drm_connector_register_all+0x1a/0x92 [ 1.371847] [<c1361cf9>] drm_connector_register_all+0x1a/0x92 [ 1.372421] [<c10b25be>] ? kstrdup+0x25/0x3a [ 1.372863] [<c135e37d>] drm_dev_register+0x59/0x99 [ 1.373358] [<c195ea3e>] vgem_init+0x34/0x49 [ 1.373770] [<c195ea0a>] ? mipi_dsi_bus_init+0xf/0xf [ 1.374257] [<c100048f>] do_one_initcall+0x7c/0xfd [ 1.374754] [<c104b409>] ? parse_args+0x1fd/0x314 [ 1.375259] [<c1939c10>] ? kernel_init_freeable+0xd0/0x179 [ 1.375837] [<c1939c2c>] kernel_init_freeable+0xec/0x179 [ 1.376371] [<c14d66ea>] kernel_init+0x8/0xcb [ 1.376806] [<c14debce>] ret_from_kernel_thread+0xe/0x30 [ 1.377322] [<c14d66e2>] ? rest_init+0x10e/0x10e [ 1.377754] Code: 89 fa e8 71 c5 b7 ff 8b 4e 04 89 fa 89 d8 e8 8e c6 b7 ff 8d 43 2c 89 45 d4 8b 43 30 8d 4b 2c 89 45 e8 89 7b 30 89 4d e4 8b 55 dc <89> 38 8d 43 3c 89 75 ec e8 c9 dd b7 ff eb 0c 31 c0 87 03 48 +75 [ 1.380442] EIP: [<c14db9ad>] mutex_lock_nested+0x11f/0x2c3 SS:ESP 0068:d28dbec0 [ 1.381174] CR2: 0000000000000000 when loading the non-modesetting vGEM module. To prevent use of the uninitialised dev->mode_config from drm_dev_register() we move the drm_connector_register_all() under a DRIVER_MODESET guard. Longer term, we probably want to initialise the embedded dev->mode_config automatically from drm_dev_init() for all DRIVER_MODESET drivers. v2: Also protect drm_dev_unregister. Fixes: e28cd4d0 ("drm: Automatically register/unregister all connectors") Signed-off-by:
-
- 17 Jun, 2016 9 commits
-
-
Ville Syrjälä authored
drm_plane_helper_check_update() needs to account for the plane rotation for correct clipping/scaling calculations. Do so. There was an earlier attempt [1] to add this into intel_check_primary_plane() but I requested that it'd be put into the helper instead. An updated patch never materialized AFAICS, so I went ahead and cooked one up myself. v2: Deal with new drm_plane_helper_check_update() callers [1] https://patchwork.freedesktop.org/patch/65177/ Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: CK Hu <ck.hu@mediatek.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
-
Chris Wilson authored
As the drm_connector is now safe for multiple calls to register/unregister, automatically perform a registration on all known connectors drm drv_register (and unregister from drm_drv_unregister). Drivers can still call drm_connector_register() and drm_connector_unregister() individually, or defer as required. Signed-off-by:
-
Chris Wilson authored
When trying to split up the initialisation phase and the registration phase, one immediate problem encountered is trying to use our own i2c devices before registration with userspace (to read EDID during device discovery). drm_dp_aux in particular only offers an interface for setting up the device *after* we have exposed the connector via sysfs. In order to break the chicken-and-egg problem, export drm_dp_aux_init() to minimally prepare the i2c device for internal use before drm_connector_register(). Signed-off-by:
-
Chris Wilson authored
Rather than have both drm_dp_aux lock within its transfer, and i2c to lock around the transfer, use the same lock by filling in the locking callbacks that i2c wants to use. We require our own hw_mutex as we bypass i2c_transfer for drm_dp_dpcd_access(). Signed-off-by:
-
Daniel Vetter authored
Atomic drivers are supposed to do hw/sw state reset with the drm_mode_config_reset() call right above it. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Chris Wilson authored
As we now can call drm_connector_unregister() multiple times, provide a failsafe unregister for a connector when cleaning it up. v2: Add a WARN to catch any connectors that are still visible to userspace when we come to destoy them. Signed-off-by:
-
Chris Wilson authored
Protect against drivers that may try to register the connector more than once, or who try to unregister it multiple times. Signed-off-by:
-
Chris Wilson authored
If a driver wants to more precisely control its initialisation and in particular, defer registering its interfaces with userspace until after everything is setup, it also needs to defer registering the connectors. As some devices need more work during registration, add a callback so that drivers can do additional work if required for a connector. Correspondingly, we also require an unregister callback. Signed-off-by:
-
Chris Wilson authored
In order to allow drivers to pack their privates and drm_device into one struct (e.g. for subclassing), export the initialisation routines for struct drm_device. v2: Missed return ret. That error path had only one job to do! v3: Cross-referencing drm_dev_init/drm_dev_alloc in kerneldoc, fix missed error code for goto err_minors. Signed-off-by:
-
- 16 Jun, 2016 7 commits
-
-
Arnd Bergmann authored
The rockchip drm driver started using drm_gem_cma_vm_ops, but that might not be part of the kernel, causing the link to fail: drivers/gpu/built-in.o:(.data+0xb234): undefined reference to `drm_gem_cma_vm_ops' This adds a Kconfig 'select' statement to enable it like the other user do. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 80f67cd8 ("drm/rockchip: Use cma gem vm ops") Signed-off-by:
-
Daniel Vetter authored
Like with drm_master_open protect it with a check for primary_client to make it clear that this can't happen on render/control nodes. Reviewed-by:
-
Daniel Vetter authored
And pull out the primary_client check to make it really obvious that this can't happen on control/render nodes. Bonus that we can avoid the master lock in this case. v2: Don't leak locks on error path (and simplify control flow while at it), reported by Julia. Cc: Julia Lawall <julia.lawall@lip6.fr> Reviewed-by:
-
Daniel Vetter authored
For modern drivers pretty much the only thing drm_master does is handling authentication for the primary/legacy drm_minor node. Instead of having it all over drm files, move it all together into drm_auth.c. This patch just does code-motion, follow up patches will also extract the master logic from file open&release paths. Reviewed-by: Chris Wilson Mchris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Master-based auth only exists for the legacy/primary drm_minor, hence there can only be one per device. The goal here is to untangle the epic dereference games of minor->master and master->minor which is just massively confusing. Reviewed-by:
-
Daniel Vetter authored
A few things: - Rename the cleanup function from drm_master_release to drm_legacy_lock_release. It doesn't relase any master stuff, but just the legacy hw lock. - Hide it in drm_lock.c, which allows us to make a few more functions static in there. To avoid forward decl we need to shuffle the code a bit though. - Push the check for ->master into the function itself. - Only call this for !DRIVER_MODESET. End result: Another place that takes struct_mutex gone for good for modern drivers. v2: Remove leftover comment. Reviewed-by:
-
Daniel Vetter authored
GEM stopped using those a while ago, and no one should ever need to use them again to debug legacy horror show drivers. Nuke it all. Aside: It would kinda be nice if we'd have some generic debugfs dumps for at least kms ... Acked-by:
-
- 15 Jun, 2016 1 commit
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
- best_encoder cleanup from Boris. - drm_simple_display_pipe helpers from Noralf. Looks really neat imo, and there's 2-3 in-flight drivers which look like they could/should use it. Anyway, with this we have now helpers and everything in place to write drivers for simple hw with fewer complexity in the driver than what fbdev would need. That was the last complaint I've heard from embedded folks after we made atomic happen. Mission accomplished! - nonblocking commit helpers for atomic, plus a bunch of driver patches for that. - Prep patch from Laurent for cleaned up pixel format functions. - More of Gustavo's cleanup for drm vblank functions. - and a few oddball things in between Plus the merge of docs-next to prep the docbook->sphinx conversion as discussed. Jon cc'ed as fyi. * tag 'topic/drm-misc-2016-06-15' of git://anongit.freedesktop.org/drm-intel: (108 commits) drm/atomic-helpers: Clear up cleanup_done a bit drm/atomic-helpers: Stall on the right commit drm/vmwgfx: use *_32_bits() macros drm/virtio: Don't reinvent a flipping wheel drm/i915: Fix missing unlock on error in i915_ppgtt_info() drm/gma500: use drm_crtc_vblank_{on,off}() drm/radeon: use crtc directly in drm_crtc_vblank_put() drm/amdgpu: use crtc directly in drm_crtc_vblank_put() drm/radeon: use drm_crtc_vblank_{on,off}() drm/amdgpu: use drm_crtc_vblank_{on,off}() drm: make drm_vblank_{get,put}() static drm: remove legacy drm_arm_vblank_event() drm: remove legacy drm_send_vblank_event() drm/nouveau: replace legacy vblank helpers drm/prime: fix error path deadlock fail drm/dsi: Add uevent callback drm: fb: cma: fix memory leak drm: i915: Rely on the default ->best_encoder() behavior where appropriate drm: Add helper for simple display pipeline drm/bridge: dw-hdmi: Use drm_atomic_helper_best_encoder() ...
-
