search for: hw_mutex

Here's some fixes for the less important DP AUX issues I mentioned a while back. Lyude Paul (2): drm/dp: Add ->pre/post_transfer() hooks for drm_dp_aux drm/nouveau: Grab an rpm reference before/after DP AUX transactions drivers/gpu/drm/drm_dp_helper.c | 5 ++ drivers/gpu/drm/nouveau/nouveau_connector.c | 36 ++++++++ drivers/gpu/drm/nouveau/nouveau_drm.c | 12 ++-

...I need to > take a separate lock at the patches for that. Locking when switching only the DDC lines is facilitated by the ddc_lock attribute of struct vgasr_priv. This is all local to vga_switcheroo.c and contained in patches 5 and 6. Locking when proxying the AUX channel is facilitated by the hw_mutex attribute of struct drm_dp_aux. nouveau has its own locking mechanism contained in drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad*.c. Thus, when proxying via nouveau, there are two locking mechanisms at work (drm_dp_aux hw_mutex as outer lock + pad as inner lock). This is nothing introduced by this pa...

...#include <drm/ttm/ttm_bo_driver.h> > #include <drm/ttm/ttm_placement.h> > @@ -78,9 +80,7 @@ struct vbox_private { > > int fb_mtrr; > > - struct { > - struct ttm_bo_device bdev; > - } ttm; > + struct drm_simple_ttm ttm; > > struct mutex hw_mutex; /* protects modeset and accel/vbva accesses */ > struct work_struct hotplug_work; > diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c b/drivers/gpu/drm/vboxvideo/vbox_ttm.c > index a1d64e1ea90c..115ec44636ab 100644 > --- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c > +++ b/drivers/gpu/...

...246.747541] #1: 000000002c55902b ((work_completion)(&dev- >power.work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.748338] #2: 000000002a39c817 (&mgr->lock){+.+.}, at: drm_dp_mst_topology_mgr_suspend+0x33/0x90 [drm_kms_helper] [ 246.749120] #3: 00000000b7d2f3c0 (&aux->hw_mutex){+.+.}, at: drm_dp_dpcd_access+0x64/0x110 [drm_kms_helper] [ 246.749928] 1 lock held by khungtaskd/65: [ 246.750715] #0: 00000000407da5ec (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185 [ 246.751535] 1 lock held by dmesg/1122: [ 246.752328] 2 locks held by zsh/1149: [ 246.753100]...

This is a follow-up to the v1 posted in April: http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html Patches 1 - 17 enable GPU switching on the pre-retina MacBook Pro. These were tested successfully by multiple people and solve two tickets in Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 https://bugs.freedesktop.org/show_bug.cgi?id=61115 Patches 18 - 22 are a

[cc += linux-pm] Hi Lyude, First of all, thanks a lot for looking into this. On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > In order to fix all of the spots that need to have runtime PM get/puts() > added, we need to ensure that it's possible for us to call > pm_runtime_get/put() in any context, regardless of how deep, since > almost all of the spots that are

...box_cursor_atomic_update(struct drm_plane *plane, > vbox_crtc->cursor_enabled = true; > > /* pinning is done in prepare/cleanup framebuffer */ > - src = vbox_bo_kmap(bo); > + src = drm_gem_ttm_kmap(gbo, true); > if (IS_ERR(src)) { > mutex_unlock(&vbox->hw_mutex); > DRM_WARN("Could not kmap cursor bo, skipping update\n"); > @@ -421,7 +423,7 @@ static void vbox_cursor_atomic_update(struct drm_plane *plane, > data_size = width * height * 4 + mask_size; > > copy_cursor_image(src, vbox->cursor_data, width, height, mask_...

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same