dri-devel March 2011

dri-devel@lists.freedesktop.org

88 participants
477 discussions

[Bug 31412] radeon memory leak
by bugzilla-daemon＠bugzilla.kernel.org 18 Mar '11

18 Mar '11

https://bugzilla.kernel.org/show_bug.cgi?id=31412 --- Comment #2 from Kevin <kjslag(a)gmail.com> 2011-03-18 20:47:01 --- It's not a regression. I also experienced the problem with 2.6.37 and 2.6.36. I haven't tested any other kernel versions; I got my laptop in December. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[Bug 31412] radeon memory leak
by bugzilla-daemon＠bugzilla.kernel.org 18 Mar '11

18 Mar '11

https://bugzilla.kernel.org/show_bug.cgi?id=31412 Andrew Morton <akpm(a)linux-foundation.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |akpm(a)linux-foundation.org --- Comment #1 from Andrew Morton <akpm(a)linux-foundation.org> 2011-03-18 20:31:35 --- It's a little unclear - is this a regression? If so, is it a 2.6.37 -> 2.6.38 regression? Thanks. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[Bug 31412] radeon memory leak
by bugzilla-daemon＠bugzilla.kernel.org 18 Mar '11

18 Mar '11

https://bugzilla.kernel.org/show_bug.cgi?id=31412 Andrew Morton <akpm(a)linux-foundation.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |Video(DRI - non Intel) AssignedTo|akpm(a)linux-foundation.org |drivers_video-dri@kernel-bu | |gs.osdl.org Product|Memory Management |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[PATCH] drm: Fix use-after-free in drm_gem_vm_close()
by Chris Wilson 17 Mar '11

17 Mar '11

As we may release the last reference, we need to store the device in a local variable in order to unlock afterwards. [ 60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f [ 60.140973] IP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] *pdpt = 0000000024a54001 *pde = 0000000000000000 [ 60.141014] Oops: 0002 [#1] PREEMPT SMP [ 60.141014] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now [ 60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev [ 60.141014] [ 60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1 EXOPC EXOPG06411/EXOPG06411 [ 60.141014] EIP: 0060:[<c1536d11>] EFLAGS: 00010046 CPU: 0 [ 60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] EAX: 00000100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580 [ 60.141014] ESI: db162558 EDI: 00000246 EBP: e480be50 ESP: e480be44 [ 60.141014] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0 task.ti=e480a000) [ 60.141014] Stack: [ 60.141014] e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b db162558 [ 60.141014] db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc 000155fe [ 60.141014] f760241c f5a2f838 f5a2f8c8 00000000 e480bea4 c1037c24 00000000 f5a2f838 [ 60.141014] Call Trace: [ 60.141014] [<c1536dd0>] ? mutex_unlock+0x8/0xa [ 60.141014] [<c125ab1b>] ? drm_gem_vm_close+0x39/0x3d [ 60.141014] [<c10ba071>] ? remove_vma+0x2d/0x58 [ 60.141014] [<c10bb0bc>] ? exit_mmap+0x126/0x13f [ 60.141014] [<c1037c24>] ? mmput+0x37/0x9a [ 60.141014] [<c10d450d>] ? exec_mmap+0x178/0x19c [ 60.141014] [<c1537f85>] ? _raw_spin_unlock+0x1d/0x36 [ 60.141014] [<c10d4eb0>] ? flush_old_exec+0x42/0x75 [ 60.141014] [<c1104442>] ? load_elf_binary+0x32a/0x922 [ 60.141014] [<c10d3f76>] ? search_binary_handler+0x200/0x2ea [ 60.141014] [<c10d3ecf>] ? search_binary_handler+0x159/0x2ea [ 60.141014] [<c1104118>] ? load_elf_binary+0x0/0x922 [ 60.141014] [<c10d56b2>] ? do_execve+0x1ff/0x2e6 [ 60.141014] [<c100970e>] ? sys_execve+0x2d/0x55 [ 60.141014] [<c1002a5a>] ? ptregs_execve+0x12/0x18 [ 60.141014] [<c10029dc>] ? sysenter_do_call+0x12/0x3c [ 60.141014] [<c1530000>] ? init_centaur+0x9c/0x1ba [ 60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff 9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 <f0> 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef [ 60.141014] EIP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44 [ 60.141014] CR2: 000000006b6b6b9f Reported-by: Rusty Lynch <rusty.lynch(a)intel.com> Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: stable(a)kernel.org --- drivers/gpu/drm/drm_gem.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 57ce27c..74e4ff5 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -499,11 +499,12 @@ EXPORT_SYMBOL(drm_gem_vm_open); void drm_gem_vm_close(struct vm_area_struct *vma) { struct drm_gem_object *obj = vma->vm_private_data; + struct drm_device *dev = obj->dev; - mutex_lock(&obj->dev->struct_mutex); + mutex_lock(&dev->struct_mutex); drm_vm_close_locked(vma); drm_gem_object_unreference(obj); - mutex_unlock(&obj->dev->struct_mutex); + mutex_unlock(&dev->struct_mutex); } EXPORT_SYMBOL(drm_gem_vm_close); -- 1.7.2.3

1 0

Oops at i915_gem_retire_requests_ring
by Herton Ronaldo Krzesinski 17 Mar '11

17 Mar '11

(please CC me if replying) Hi, recently I saw a report about an oops in 2.6.38-rc7 in i915, attached at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/733780 Unfortunately the oops is cut (without call trace): [126167.230394] BUG: unable to handle kernel paging request at 00100104 [126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000 [126167.231314] Oops: 0002 [#1] SMP [126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now [126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci [126167.232018] [126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway MC7833U / [126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0 [126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915] [126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100 [126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0 [126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000) [126167.232018] Stack: [126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85 [126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040 [126167.232018] f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214 [126167.232018] Call Trace: But we already can see some things. After downloading the debug symbols for kernel above [1] and extracting the files (dpkg-deb -x), setting up the source files, in gdb we can get this: (gdb) l *(i915_gem_retire_requests_ring+0xd4) 0x17e74 is in i915_gem_retire_requests_ring (/build/buildd/linux-2.6.38/include/linux/list.h:88). warning: Source file is more recent than executable. 83 * This is only for internal list manipulation where we know 84 * the prev/next entries already! 85 */ 86 static inline void __list_del(struct list_head * prev, struct list_head * next) 87 { 88 next->prev = prev; 89 prev->next = next; 90 } 91 92 /** So the oops is in a list_del call. And looking at the EDX and dereferenced value, it's LIST_POISON1 + 4, as p &((struct list_head *)0)->prev == 0x4 So indeed the oops is happening on __list_del at next->prev = prev, called from i915_gem_retire_requests_ring, probably from the i915_gem_request_remove_from_client call, going back in the code for example: (gdb) l *(i915_gem_retire_requests_ring+0xc6) 0x17e66 is in i915_gem_retire_requests_ring (/build/buildd/linux-2.6.38/drivers/gpu/drm/i915/i915_gem.c:1748). warning: Source file is more recent than executable. 1743 static inline void 1744 i915_gem_request_remove_from_client(struct drm_i915_gem_request *request) 1745 { 1746 struct drm_i915_file_private *file_priv = request->file_priv; 1747 1748 if (!file_priv) 1749 return; 1750 1751 spin_lock(&file_priv->mm.lock); 1752 list_del(&request->client_list); But without the call trace no way to know for certain. Anyway the oops with LIST_POISON1 means we are trying to delete from the list an already deleted item. As I can see in the code (I'm not used to that code, so may be there is something I don't see), it seems we indeed have the possibility to remove an request->client_list twice, which would cause the above, we do list_del(&request->client_list) on both i915_gem_request_remove_from_client and i915_gem_release I don't know if it's the most correct fix, but perhaps the simple fix is needed in the code. It's against latest Linus tree. We may have an already removed client_list, or we didn't add any item to client_list (file_priv NULL in i915_add_request) Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski(a)canonical.com> --- diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 36e66cc..6077c0d 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1749,8 +1749,10 @@ i915_gem_request_remove_from_client(struct drm_i915_gem_request *request) return; spin_lock(&file_priv->mm.lock); - list_del(&request->client_list); - request->file_priv = NULL; + if (request->file_priv) { + list_del(&request->client_list); + request->file_priv = NULL; + } spin_unlock(&file_priv->mm.lock); } @@ -4043,8 +4045,10 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file) request = list_first_entry(&file_priv->mm.request_list, struct drm_i915_gem_request, client_list); - list_del(&request->client_list); - request->file_priv = NULL; + if (request->file_priv) { + list_del(&request->client_list); + request->file_priv = NULL; + } } spin_unlock(&file_priv->mm.lock); } [1] http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-2.6.38-6-generic-pae-… -- []'s Herton

2 3

[PATCH] drm: radeon: *_cs_packet_parse_vline() cleanup
by Paul Bolle 16 Mar '11

16 Mar '11

Simplify the way the return value is set a number of times (mostly on error). Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- Should a patch like this go through the trivial tree? Documentation/SubmittingPatches wasn't entirely clear on that. drivers/gpu/drm/radeon/evergreen_cs.c | 24 ++++++++---------------- drivers/gpu/drm/radeon/r100.c | 16 ++++++---------- drivers/gpu/drm/radeon/r600_cs.c | 25 +++++++++---------------- 3 files changed, 23 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index 345a75a..d091e70 100644 --- a/drivers/gpu/drm/radeon/evergreen_cs.c +++ b/drivers/gpu/drm/radeon/evergreen_cs.c @@ -292,33 +292,28 @@ static int evergreen_cs_packet_parse_vline(struct radeon_cs_parser *p) if (wait_reg_mem.type != PACKET_TYPE3 || wait_reg_mem.opcode != PACKET3_WAIT_REG_MEM) { DRM_ERROR("vline wait missing WAIT_REG_MEM segment\n"); - r = -EINVAL; - return r; + return -EINVAL; } wait_reg_mem_info = radeon_get_ib_value(p, wait_reg_mem.idx + 1); /* bit 4 is reg (0) or mem (1) */ if (wait_reg_mem_info & 0x10) { DRM_ERROR("vline WAIT_REG_MEM waiting on MEM rather than REG\n"); - r = -EINVAL; - return r; + return -EINVAL; } /* waiting for value to be equal */ if ((wait_reg_mem_info & 0x7) != 0x3) { DRM_ERROR("vline WAIT_REG_MEM function not equal\n"); - r = -EINVAL; - return r; + return -EINVAL; } if ((radeon_get_ib_value(p, wait_reg_mem.idx + 2) << 2) != EVERGREEN_VLINE_STATUS) { DRM_ERROR("vline WAIT_REG_MEM bad reg\n"); - r = -EINVAL; - return r; + return -EINVAL; } if (radeon_get_ib_value(p, wait_reg_mem.idx + 5) != EVERGREEN_VLINE_STAT) { DRM_ERROR("vline WAIT_REG_MEM bad bit mask\n"); - r = -EINVAL; - return r; + return -EINVAL; } /* jump over the NOP */ @@ -336,8 +331,7 @@ static int evergreen_cs_packet_parse_vline(struct radeon_cs_parser *p) obj = drm_mode_object_find(p->rdev->ddev, crtc_id, DRM_MODE_OBJECT_CRTC); if (!obj) { DRM_ERROR("cannot find crtc %d\n", crtc_id); - r = -EINVAL; - goto out; + return -EINVAL; } crtc = obj_to_crtc(obj); radeon_crtc = to_radeon_crtc(crtc); @@ -362,12 +356,10 @@ static int evergreen_cs_packet_parse_vline(struct radeon_cs_parser *p) break; default: DRM_ERROR("unknown crtc reloc\n"); - r = -EINVAL; - goto out; + return -EINVAL; } } -out: - return r; + return 0; } static int evergreen_packet0_check(struct radeon_cs_parser *p, diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index e372f9e..fcc23e4 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -1205,14 +1205,12 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p) if (waitreloc.reg != RADEON_WAIT_UNTIL || waitreloc.count != 0) { DRM_ERROR("vline wait had illegal wait until segment\n"); - r = -EINVAL; - return r; + return -EINVAL; } if (radeon_get_ib_value(p, waitreloc.idx + 1) != RADEON_WAIT_CRTC_VLINE) { DRM_ERROR("vline wait had illegal wait until\n"); - r = -EINVAL; - return r; + return -EINVAL; } /* jump over the NOP */ @@ -1230,8 +1228,7 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p) obj = drm_mode_object_find(p->rdev->ddev, crtc_id, DRM_MODE_OBJECT_CRTC); if (!obj) { DRM_ERROR("cannot find crtc %d\n", crtc_id); - r = -EINVAL; - goto out; + return -EINVAL; } crtc = obj_to_crtc(obj); radeon_crtc = to_radeon_crtc(crtc); @@ -1253,14 +1250,13 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p) break; default: DRM_ERROR("unknown crtc reloc\n"); - r = -EINVAL; - goto out; + return -EINVAL; } ib[h_idx] = header; ib[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1; } -out: - return r; + + return 0; } /** diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index 153095f..5bfed09 100644 --- a/drivers/gpu/drm/radeon/r600_cs.c +++ b/drivers/gpu/drm/radeon/r600_cs.c @@ -687,33 +687,28 @@ static int r600_cs_packet_parse_vline(struct radeon_cs_parser *p) if (wait_reg_mem.type != PACKET_TYPE3 || wait_reg_mem.opcode != PACKET3_WAIT_REG_MEM) { DRM_ERROR("vline wait missing WAIT_REG_MEM segment\n"); - r = -EINVAL; - return r; + return -EINVAL; } wait_reg_mem_info = radeon_get_ib_value(p, wait_reg_mem.idx + 1); /* bit 4 is reg (0) or mem (1) */ if (wait_reg_mem_info & 0x10) { DRM_ERROR("vline WAIT_REG_MEM waiting on MEM rather than REG\n"); - r = -EINVAL; - return r; + return -EINVAL; } /* waiting for value to be equal */ if ((wait_reg_mem_info & 0x7) != 0x3) { DRM_ERROR("vline WAIT_REG_MEM function not equal\n"); - r = -EINVAL; - return r; + return -EINVAL; } if ((radeon_get_ib_value(p, wait_reg_mem.idx + 2) << 2) != AVIVO_D1MODE_VLINE_STATUS) { DRM_ERROR("vline WAIT_REG_MEM bad reg\n"); - r = -EINVAL; - return r; + return -EINVAL; } if (radeon_get_ib_value(p, wait_reg_mem.idx + 5) != AVIVO_D1MODE_VLINE_STAT) { DRM_ERROR("vline WAIT_REG_MEM bad bit mask\n"); - r = -EINVAL; - return r; + return -EINVAL; } /* jump over the NOP */ @@ -732,8 +727,7 @@ static int r600_cs_packet_parse_vline(struct radeon_cs_parser *p) obj = drm_mode_object_find(p->rdev->ddev, crtc_id, DRM_MODE_OBJECT_CRTC); if (!obj) { DRM_ERROR("cannot find crtc %d\n", crtc_id); - r = -EINVAL; - goto out; + return -EINVAL; } crtc = obj_to_crtc(obj); radeon_crtc = to_radeon_crtc(crtc); @@ -756,14 +750,13 @@ static int r600_cs_packet_parse_vline(struct radeon_cs_parser *p) break; default: DRM_ERROR("unknown crtc reloc\n"); - r = -EINVAL; - goto out; + return -EINVAL; } ib[h_idx] = header; ib[h_idx + 4] = AVIVO_D2MODE_VLINE_STATUS >> 2; } -out: - return r; + + return 0; } static int r600_packet0_check(struct radeon_cs_parser *p, -- 1.7.4.1

1 0

Re: i915/kms regression after 2.6.38-rc8
by Melchior FRANZ 16 Mar '11

16 Mar '11

* Chris Wilson -- Wednesday 16 March 2011: > There's only one patch directly related to i915, so you could begin there. I'll try later. Was just too obvious for now. :-} > Useful information to include is a dmesg (particularly one with > drm.debug=0xe kernel parameters) and lspci OK, thanks for that info. Attached. > (though google says you have a gm45). I didn't look it up before, I just trusted the kernel with its "i915". But you are probably right, this Acer TravelMate 5735Z-452G32Mnss is supposed to have an "Intel Graphics Media Accelerator 4500MHD". m.

1 0

Just for fun (a pleasant diversion from coding)
by Garry Hurley 16 Mar '11

16 Mar '11

On LinkedIn, I belong to the "Linux Users" and "Linux Experts" lists. We were having a discussion on "Linux Users" as to why corporations aren't moving to Linux desktops. Someone suggested a name like "Doors" or "Skylights" for a Linux distro to point out how 'similar Linux was to Windows'. I countered that perhaps we should market Linux as the "Low-e OS" because Linux is a "more energy-efficient, greener approach to computing than traditional Windows." Well, we could change that to KDE or Gnome and get away without paying Microsoft - especially since they cannot trademark the word "Windows" (although they did try). Okay, just a thought that might have amused you for a second. I'll let you folks get back to work now. Lots of ground to cover in making Linux worthy for most desktop computers.

1 0

Re: i915/kms regression after 2.6.38-rc8
by Jiri Slaby 16 Mar '11

16 Mar '11

Ccing some relevant people (you should have done this). On 03/16/2011 06:30 PM, Melchior FRANZ wrote: > On my i915 using Acer TravelMate 5735z I could run kernel 2.6.38-rc8 > with KMS. On 2.6.38 I get a black screen instead. In case anyone > cares, just tell me what information you need. (bisect result on > request, but I assume the experts know which patch caused it.) -- js

1 0

[PATCH] radeon: merge list_del()/list_add_tail() to list_move_tail()
by Nicolas Kaiser 16 Mar '11

16 Mar '11

Merge list_del() + list_add_tail() to list_move_tail(). Signed-off-by: Nicolas Kaiser <nikai(a)nikai.net> --- drivers/gpu/drm/radeon/radeon_fence.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 171b0b2..9e59868 100644 --- a/drivers/gpu/drm/radeon/radeon_fence.c +++ b/drivers/gpu/drm/radeon/radeon_fence.c @@ -60,8 +60,7 @@ int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence *fence) trace_radeon_fence_emit(rdev->ddev, fence->seq); fence->emited = true; - list_del(&fence->list); - list_add_tail(&fence->list, &rdev->fence_drv.emited); + list_move_tail(&fence->list, &rdev->fence_drv.emited); write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags); return 0; } @@ -121,8 +120,7 @@ static bool radeon_fence_poll_locked(struct radeon_device *rdev) i = n; do { n = i->prev; - list_del(i); - list_add_tail(i, &rdev->fence_drv.signaled); + list_move_tail(i, &rdev->fence_drv.signaled); fence = list_entry(i, struct radeon_fence, list); fence->signaled = true; i = n; -- 1.7.3.4

1 0

← Newer
1
...
28
29
30
31
32
33
34
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2011