[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 pitamila at free.fr changed: What|Removed |Added Version|7.10|8.0 --- Comment #9 from pitamila at free.fr --- Hi, I updated my Debian Sid distro to mesa 8.0.4 unfortunately, Enemy Territory continue to have - texture blinking - error in drawing landscapes (I can see thru the walls) - many objects (all the screen when enterring limbo menu) appearing only a fraction of second then disappearing Tell me if I can do any testing or provide some more log to help diagnose the pb. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/68edf543/attachment.html>
[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 pitamila at free.fr changed: What|Removed |Added Attachment #50399|0 |1 is obsolete|| --- Comment #8 from pitamila at free.fr --- Created attachment 68363 --> https://bugs.freedesktop.org/attachment.cgi?id=68363=edit my glxinfo output with mesa 8.0.4 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/1adb211c/attachment.html>
[Bug 55819] Mouse cursor corruption when moving between monitors
https://bugs.freedesktop.org/show_bug.cgi?id=55819 Alex Deucher changed: What|Removed |Added Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QA Contact|xorg-team at lists.x.org | Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon --- Comment #5 from Alex Deucher --- What kernel are you using? Make sure it has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f60ec4c7df043df81e62891ac45383d012afe0da -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/7628903b/attachment.html>
[PATCH] drm/omap: fix allocation size for page addresses array
Signed-off-by: Rob Clark Signed-off-by: Vincent Penquerc'h --- drivers/staging/omapdrm/omap_gem.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index c828743..4c1472c 100644 --- a/drivers/staging/omapdrm/omap_gem.c +++ b/drivers/staging/omapdrm/omap_gem.c @@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) * DSS, GPU, etc. are not cache coherent: */ if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) { - addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; @@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) 0, PAGE_SIZE, DMA_BIDIRECTIONAL); } } else { - addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; -- 1.7.9.5
[PATCH] drm: avoid passing null pointer to memset
On Tue, 9 Oct 2012 14:50:46 -0300, Rodrigo Vivi wrote: > When cmd isn't IOC_IN | IOC_OUT a null "kdata" goes to "memset", which > dereferences it. > usize should be 0 in that case, since the ioctl is neither copying data in or out, for example I915_GEM_THROTTLE. To be on the safe side: if (IOC_IN | IOC_OUT) { /* blah */ } else usize = 0; -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] Fix calculation of memory needed for page handles
Hi, Wrong sizeof used, fixed in attached patch, and below. >From 7f430a4104bee5f75929580a66128b7b0e2859d9 Mon Sep 17 00:00:00 2001 From: Vincent Penquerc'h <vincent.penque...@collabora.co.uk> Date: Tue, 9 Oct 2012 17:18:33 +0100 Subject: [PATCH] drm/omap: fix allocation size for page addresses array Signed-off-by: Rob Clark --- drivers/staging/omapdrm/omap_gem.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index c828743..4c1472c 100644 --- a/drivers/staging/omapdrm/omap_gem.c +++ b/drivers/staging/omapdrm/omap_gem.c @@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) * DSS, GPU, etc. are not cache coherent: */ if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) { - addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; @@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) 0, PAGE_SIZE, DMA_BIDIRECTIONAL); } } else { - addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; -- 1.7.9.5 -- next part -- A non-text attachment was scrubbed... Name: 0001-omap_gem-fix-incorrect-allocation-size-for-page-addr.patch Type: text/x-patch Size: 1153 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/33ce3b0c/attachment.bin>
Update on the CEC API
Em Mon, 08 Oct 2012 19:45:14 +0200 Florian Fainelli escreveu: > On Monday 08 October 2012 17:49:00 Hans Verkuil wrote: > > On Mon October 8 2012 17:06:20 Florian Fainelli wrote: > > > Hi Hans, > > > > > > On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote: > > > > Hi all, > > > > > > > > During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) > > > > had a > > > > discussion on how to handle the CEC protocol that's part of the HDMI > > > standard. > > > > > > > > The decision was made to create a CEC bus with CEC clients, each > > > > represented > > > > by a /dev/cecX device. So this is independent of the V4L or DRM APIs. > > > > > > > > In addition interested subsystems (alsa for the Audio Return Channel, > > > > and > > > > possibly networking as well for ethernet over HDMI) can intercept/send > > > > CEC > > > > messages as well if needed. Particularly for the CEC additions made in > > > > HDMI 1.4a it is no longer possible to handle the CEC protocol > > > > completely in > > > > userspace, but part of the intelligence has to be moved to kernelspace. ... > > Also remote control messages might optionally be handled through an input > > driver. > > Ok, then maybe just stick to the standard CEC_UI_* key codes, and let people > having proprietary UI functions do the rest in user-space, or write their own > input driver. No. The RC core already provides standard ways for userspace to read/add/replace the scancode -> Linux keycode using the standard Kernel mechanisms for that. All it is needed is to use an userspace program for that (with already exists). So, there's absolutely no need for per-vendor kernelspace/userspace drivers. The RC core also allows sending remote controller keystrokes. The userspace API currently works only with IR raw codes. There are, however, discussions and some RFC patches proposing some changes there to also accept scancodes (and/or Linux keycodes) to be passed for the Remote Controller TX drivers. So, from remote controller standpoint, just one driver will be enough to handle HDMI CEC. Regards, Mauro
[PATCH] drm: avoid passing null pointer to memset
When cmd isn't IOC_IN | IOC_OUT a null "kdata" goes to "memset", which dereferences it. v2: simpler version just using usize = 0 instead of allocating useless memory Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/drm_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 1490e76..f72dce5 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -444,7 +444,8 @@ long drm_ioctl(struct file *filp, } if (asize > usize) memset(kdata + usize, 0, asize - usize); - } + } else + usize = 0; if (cmd & IOC_IN) { if (copy_from_user(kdata, (void __user *)arg, -- 1.7.11.4
[PATCH v5 1/3] drm: Add user-defined EDID quirks capability
On Fri, 28 Sep 2012, Ian Pilcher wrote: > Add the ability for users to define their own EDID quirks via a > module parameter or sysfs attribute. Hi Ian - IMHO this patch should be chopped up to smaller pieces. For example, change the edid_quirk_list format first (if you must), then add module parameter support, then add sysfs support, in separate patches. It'll be easier to review. Please see some other comments inline. BR, Jani. > > Signed-off-by: Ian Pilcher > --- > Documentation/EDID/edid_quirks.txt | 126 ++ > drivers/gpu/drm/drm_drv.c | 2 + > drivers/gpu/drm/drm_edid.c | 500 > - > drivers/gpu/drm/drm_stub.c | 6 + > drivers/gpu/drm/drm_sysfs.c| 19 ++ > include/drm/drmP.h | 10 + > include/drm/drm_edid.h | 13 +- > 7 files changed, 615 insertions(+), 61 deletions(-) > create mode 100644 Documentation/EDID/edid_quirks.txt > > diff --git a/Documentation/EDID/edid_quirks.txt > b/Documentation/EDID/edid_quirks.txt > new file mode 100644 > index 000..0c9c746 > --- /dev/null > +++ b/Documentation/EDID/edid_quirks.txt > @@ -0,0 +1,126 @@ > + EDID Quirks > + = > + Ian Pilcher > +August 11, 2012 > + > + > +"EDID blocks out in the wild have a variety of bugs" > +-- from drivers/gpu/drm/drm_edid.c > + > + > +Overview > + > + > +EDID quirks provide a mechanism for working around display hardware with > buggy > +EDID data. > + > +An individual EDID quirk maps a display type (identified by its EDID > +manufacturer ID and product code[1]) to a set of "quirk flags." The kernel > +includes a variety of built-in quirks. (They are stored in the > edid_quirk_list > +array in drivers/gpu/drm/drm_edid.c.) > + > +An example of a built-in EDID quirk is: > + > +ACR:0xad46:0x0001 > + > +The first field is the manufacturer ID (Acer, Inc.), the second field is the > +manufacturer's product code, and the third field contains the quirk flags for > +that display type. > + > +The quirk flags are defined in drivers/gpu/drm/drm_edid.c. Each flag has a > +symbolic name beginning with EDID_QUIRK_, along with a numerical value. Each > +flag should also have an associated comment which provides an idea of its > +effect. Note that the values in the source file are expressed as bit > shifts[2]: > + > +* 1 << 0: 0x0001 > +* 1 << 1: 0x0002 > +* 1 << 2: 0x0004 > +* etc. > + > + > +sysfs interface > +=== > + > +The current EDID quirk list can be read from /sys/class/drm/edid_quirks: > + > +# cat /sys/class/drm/edid_quirks > + ACR:0xad46:0x0001 > + API:0x7602:0x0001 > + ACR:0x0977:0x0020 > +0x9e6a:0x077e:0x0080 > +... > + > +("Nonconformant" manufacturer IDs are displayed as hexadecimal values.) > + > +The number of total "slots" in the list can be read from > +/sys/class/drm/edid_quirks_size. This total includes both occupied slots > (i.e. > +the current list) and any slots available for additional quirks. The number > of > +available slots can be calculated by subtracting the number of quirks in the > +current list from the total number of slots. > + > +If a slot is available, an additional quirk can be added to the list by > writing > +it to /sys/class/drm/edid_quirks: > + > +# echo FOO:0x:0x100 > /sys/class/drm/edid_quirks > + > +Manufacturer IDs can also be specified numerically. (This is the only way to > +specify a nonconformant ID.) This command is equivalent to the previous one: > + > +# echo 0x19ef:0x:0x100 > /sys/class/drm/edid_quirks > + > +Numeric values can also be specified in decimal or octal formats; a number > that > +begins with a 0 is assumed to be octal: > + > +# echo FOO:65535:0400 > /sys/class/drm/edid_quirks > + > +An existing quirk can be replaced by writing a new set of flags: > + > +# echo FOO:0x:0x200 > /sys/class/drm/edid_quirks > + > +A quirk can be deleted from the list by writing an empty flag set (0). This > +makes the slot occupied by that quirk available. > + > +# echo FOO:0x:0 > /sys/class/drm/edid_quirks > + > +Writing an "at symbol" (@) clears the entire quirk list: > + > +# echo @ > /sys/class/drm/edid_quirks > + > +Multiple changes to the list can be specified in a comma (or newline) > separated > +list. For example, the following command clears all of the existing quirks in > +the list and adds 3 new quirks: > + > +# echo @,FOO:0x:0x100,BAR:0x:0x001,BAZ:0x:0x002 > \ > +/sys/class/drm/edid_quirks > + > +Note however, that any error (an incorrectly formatted quirk or an attempt to > +add a quirk when no slot is available) will abort processing of any further > +changes, potentially making it difficult to determine exactly which change > +caused the error and what
[PATCH] drm: avoid passing null pointer to memset
When cmd isn't IOC_IN | IOC_OUT a null "kdata" goes to "memset", which dereferences it. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/drm_drv.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 1490e76..5945920 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -452,8 +452,16 @@ long drm_ioctl(struct file *filp, retcode = -EFAULT; goto err_i1; } - } else + } else { + if (!kdata) { + kdata = kmalloc(usize, GFP_KERNEL); + if (!kdata) { + retcode = -ENOMEM; + goto err_i1; + } + } memset(kdata, 0, usize); + } if (ioctl->flags & DRM_UNLOCKED) retcode = func(dev, kdata, file_priv); -- 1.7.11.4
[Bug 55809] omap_drm: fix locking bug on error path
https://bugs.freedesktop.org/show_bug.cgi?id=55809 Rob Clark changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |rob at ti.com |.org| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/718b92af/attachment.html>
[Bug 55809] New: omap_drm: fix locking bug on error path
https://bugs.freedesktop.org/show_bug.cgi?id=55809 Priority: medium Bug ID: 55809 Assignee: dri-devel at lists.freedesktop.org Summary: omap_drm: fix locking bug on error path Severity: normal Classification: Unclassified OS: Linux (All) Reporter: vincent at collabora.co.uk Hardware: ARM Status: NEW Version: XOrg CVS Component: libdrm Product: DRI Created attachment 68338 --> https://bugs.freedesktop.org/attachment.cgi?id=68338=edit Fix for locking bug on error paths omap_drm.c has a couple places where a lock is not released on an error path, but should be. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/3848a219/attachment.html>
[PATCH 00/11] page-flip cleanups and fixes
2012/10/9 Rob Clark : > From: Rob Clark > > Add a helper fxn to send vblank event after pageflip, plus a handful > of fixes for other issues that I noticed in the process. > patches 1, 5 and 6 are: Reviewed-by: Inki Dae
[PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2
On Die, 2012-10-09 at 13:31 +0200, Christian K?nig wrote: > We want to use VMs without the IB pool in the future. > > v2: also remove it from radeon_vm_finish. > > Signed-off-by: Christian K?nig Reviewed-by: Michel D?nzer -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[PATCH 3/3] drm/radeon: separate pt alloc from lru add
Make it possible to allocate a persistent page table. Signed-off-by: Christian K?nig Reviewed-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h |1 + drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_gart.c | 20 3 files changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 54cf9b5..8c42d54 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1851,6 +1851,7 @@ void radeon_vm_manager_fini(struct radeon_device *rdev); void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm); void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm); int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm); +void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm); struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev, struct radeon_vm *vm, int ring); void radeon_vm_fence(struct radeon_device *rdev, diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index d59eb59..023c67d 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -478,6 +478,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev, } out: + radeon_vm_add_to_lru(rdev, vm); mutex_unlock(>mutex); mutex_unlock(>vm_manager.lock); return r; diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index 80f0331..08e0ddc 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -617,9 +617,6 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm) } if (vm->page_directory != NULL) { - /* update lru */ - list_del_init(>list); - list_add_tail(>list, >vm_manager.lru_vm); return 0; } @@ -653,11 +650,26 @@ retry: return -ENOMEM; } - list_add_tail(>list, >vm_manager.lru_vm); return 0; } /** + * radeon_vm_add_to_lru - add VMs page table to LRU list + * + * @rdev: radeon_device pointer + * @vm: vm to add to LRU + * + * Add the allocated page table to the LRU list (cayman+). + * + * Global mutex must be locked! + */ +void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm) +{ + list_del_init(>list); + list_add_tail(>list, >vm_manager.lru_vm); +} + +/** * radeon_vm_grab_id - allocate the next free VMID * * @rdev: radeon_device pointer -- 1.7.9.5
[PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2
We want to use VMs without the IB pool in the future. v2: also remove it from radeon_vm_finish. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h |2 +- drivers/gpu/drm/radeon/radeon_gart.c | 34 +++--- drivers/gpu/drm/radeon/radeon_kms.c | 22 +- 3 files changed, 25 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index bc6b56b..54cf9b5 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1848,7 +1848,7 @@ extern void radeon_ttm_set_active_vram_size(struct radeon_device *rdev, u64 size */ int radeon_vm_manager_init(struct radeon_device *rdev); void radeon_vm_manager_fini(struct radeon_device *rdev); -int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm); +void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm); void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm); int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm); struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev, diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index b36b615..80f0331 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -602,7 +602,6 @@ int radeon_vm_evict(struct radeon_device *rdev, struct radeon_vm *vm) * @vm: vm to bind * * Allocate a page table for the requested vm (cayman+). - * Also starts to populate the page table. * Returns 0 for success, error for failure. * * Global and local mutex must be locked! @@ -655,8 +654,7 @@ retry: } list_add_tail(>list, >vm_manager.lru_vm); - return radeon_vm_bo_update_pte(rdev, vm, rdev->ring_tmp_bo.bo, - >ring_tmp_bo.bo->tbo.mem); + return 0; } /** @@ -1241,30 +1239,15 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev, * @rdev: radeon_device pointer * @vm: requested vm * - * Init @vm (cayman+). - * Map the IB pool and any other shared objects into the VM - * by default as it's used by all VMs. - * Returns 0 for success, error for failure. + * Init @vm fields (cayman+). */ -int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm) +void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm) { - struct radeon_bo_va *bo_va; - int r; - vm->id = 0; vm->fence = NULL; mutex_init(>mutex); INIT_LIST_HEAD(>list); INIT_LIST_HEAD(>va); - - /* map the ib pool buffer at 0 in virtual address space, set -* read only -*/ - bo_va = radeon_vm_bo_add(rdev, vm, rdev->ring_tmp_bo.bo); - r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET, - RADEON_VM_PAGE_READABLE | - RADEON_VM_PAGE_SNOOPED); - return r; } /** @@ -1286,17 +1269,6 @@ void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm) radeon_vm_free_pt(rdev, vm); mutex_unlock(>vm_manager.lock); - /* remove all bo at this point non are busy any more because unbind -* waited for the last vm fence to signal -*/ - r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false); - if (!r) { - bo_va = radeon_vm_bo_find(vm, rdev->ring_tmp_bo.bo); - list_del_init(_va->bo_list); - list_del_init(_va->vm_list); - radeon_bo_unreserve(rdev->ring_tmp_bo.bo); - kfree(bo_va); - } if (!list_empty(>va)) { dev_err(rdev->dev, "still active bo inside vm\n"); } diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index cb8e94d..c97d49b 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -420,6 +420,7 @@ int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv) /* new gpu have virtual address space support */ if (rdev->family >= CHIP_CAYMAN) { struct radeon_fpriv *fpriv; + struct radeon_bo_va *bo_va; int r; fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL); @@ -427,7 +428,15 @@ int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv) return -ENOMEM; } - r = radeon_vm_init(rdev, >vm); + radeon_vm_init(rdev, >vm); + + /* map the ib pool buffer read only into +* virtual address space */ + bo_va = radeon_vm_bo_add(rdev, >vm, +rdev->ring_tmp_bo.bo); + r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET, + RADEON_VM_PAGE_READABLE | + RADEON_VM_PAGE_SNOOPED);
[PATCH 1/3] drm/radeon: allocate page tables on demand v4
Based on Dmitries work, but splitting the code into page directory and page table handling makes it far more readable and (hopefully) more reliable. Allocations of page tables are made from the SA on demand, that should still work fine since all page tables are of the same size. Also using the fact that allocations from the SA are mostly continuously (except for end of buffer wraps and under very high memory pressure) to group updates send to the chipset specific code into larger chunks. v3: mostly a rewrite of Dmitries previous patch. v4: fix some typos and coding style Signed-off-by: Dmitry Cherkasov Signed-off-by: Christian K?nig Tested-by: Michel D?nzer Reviewed-by: Alex Deucher --- drivers/gpu/drm/radeon/ni.c |2 +- drivers/gpu/drm/radeon/radeon.h | 11 +- drivers/gpu/drm/radeon/radeon_gart.c | 322 ++ 3 files changed, 262 insertions(+), 73 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index 9a46f7d..48e2337 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -1576,7 +1576,7 @@ void cayman_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm) radeon_ring_write(ring, 0); radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (vm->id << 2), 0)); - radeon_ring_write(ring, vm->last_pfn); + radeon_ring_write(ring, rdev->vm_manager.max_pfn); radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2), 0)); radeon_ring_write(ring, vm->pd_gpu_addr >> 12); diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index b04c064..bc6b56b 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -663,9 +663,14 @@ struct radeon_vm { struct list_headlist; struct list_headva; unsignedid; - unsignedlast_pfn; - u64 pd_gpu_addr; - struct radeon_sa_bo *sa_bo; + + /* contains the page directory */ + struct radeon_sa_bo *page_directory; + uint64_tpd_gpu_addr; + + /* array of page tables, one for each page directory entry */ + struct radeon_sa_bo **page_tables; + struct mutexmutex; /* last fence for cs using this vm */ struct radeon_fence *fence; diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index 753b7ca..b36b615 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -423,6 +423,18 @@ void radeon_gart_fini(struct radeon_device *rdev) */ /** + * radeon_vm_num_pde - return the number of page directory entries + * + * @rdev: radeon_device pointer + * + * Calculate the number of page directory entries (cayman+). + */ +static unsigned radeon_vm_num_pdes(struct radeon_device *rdev) +{ + return rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE; +} + +/** * radeon_vm_directory_size - returns the size of the page directory in bytes * * @rdev: radeon_device pointer @@ -431,7 +443,7 @@ void radeon_gart_fini(struct radeon_device *rdev) */ static unsigned radeon_vm_directory_size(struct radeon_device *rdev) { - return (rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE) * 8; + return RADEON_GPU_PAGE_ALIGN(radeon_vm_num_pdes(rdev) * 8); } /** @@ -451,11 +463,11 @@ int radeon_vm_manager_init(struct radeon_device *rdev) if (!rdev->vm_manager.enabled) { /* allocate enough for 2 full VM pts */ - size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev)); - size += RADEON_GPU_PAGE_ALIGN(rdev->vm_manager.max_pfn * 8); + size = radeon_vm_directory_size(rdev); + size += rdev->vm_manager.max_pfn * 8; size *= 2; r = radeon_sa_bo_manager_init(rdev, >vm_manager.sa_manager, - size, + RADEON_GPU_PAGE_ALIGN(size), RADEON_GEM_DOMAIN_VRAM); if (r) { dev_err(rdev->dev, "failed to allocate vm bo (%dKB)\n", @@ -476,7 +488,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev) /* restore page table */ list_for_each_entry(vm, >vm_manager.lru_vm, list) { - if (vm->sa_bo == NULL) + if (vm->page_directory == NULL) continue; list_for_each_entry(bo_va, >va, vm_list) { @@ -500,16 +512,25 @@ static void radeon_vm_free_pt(struct radeon_device *rdev, struct radeon_vm *vm) { struct radeon_bo_va *bo_va; + int i; - if (!vm->sa_bo) + if (!vm->page_directory)
[RFC 1/4] time: export getnstime_raw_and_real for DRM
On Fri, 2012-10-05 at 12:14 -0400, Kristian H?gsberg wrote: > On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak wrote: > > Needed by the upcoming DRM raw monotonic timestamp support. > > I just had a quick look at driver/input/evdev.c, since evdev devices > did a similar change recently to allow evdev timestamp from the > monotonic clock. They're using a different time API: > > time_mono = ktime_get(); > time_real = ktime_sub(time_mono, ktime_get_monotonic_offset()); > > and > > event->time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ? > mono : real); > > I'm not really up-to-date on kernel time APIs, but I wonder if that > may be better? At least, I suspect we wouldn't need changes outside > drm if we use this API. Thanks, I will use this instead of getnstime_raw_and_real. The reason is as discussed on #intel-gfx that this provides a monotonic vs. raw monotonic time and that as you say it won't require a change in the time keeping code. --Imre > > Kristian > > > > Signed-off-by: Imre Deak > > --- > > kernel/time/timekeeping.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > > index d3b91e7..073d262 100644 > > --- a/kernel/time/timekeeping.c > > +++ b/kernel/time/timekeeping.c > > @@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts) > > } > > EXPORT_SYMBOL_GPL(ktime_get_ts); > > > > -#ifdef CONFIG_NTP_PPS > > +#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || > > defined(CONFIG_DRM_MODULE) > > > > /** > > * getnstime_raw_and_real - get day and raw monotonic time in timespec > > format > > -- > > 1.7.9.5 > >
[PATCH] drm/omap: fix allocation size for page addresses array
Signed-off-by: Rob Clark --- drivers/staging/omapdrm/omap_gem.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index c828743..4c1472c 100644 --- a/drivers/staging/omapdrm/omap_gem.c +++ b/drivers/staging/omapdrm/omap_gem.c @@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) * DSS, GPU, etc. are not cache coherent: */ if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) { - addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; @@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) 0, PAGE_SIZE, DMA_BIDIRECTIONAL); } } else { - addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; -- 1.7.9.5
[PATCH 11/11] drm/omap: page-flip fixes
On Tue, 2012-10-09 at 12:35 +0300, Imre Deak wrote: > On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote: > > From: Rob Clark > > > > Userspace might not request a vblank event. So it is not an error > > for 'event' to be NULL, and we shouldn't use it to determine if > > there is a pending flip already. > > > > Signed-off-by: Rob Clark > > --- > > drivers/staging/omapdrm/omap_crtc.c |6 ++ > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/staging/omapdrm/omap_crtc.c > > b/drivers/staging/omapdrm/omap_crtc.c > > index 74e019a..317b854 100644 > > --- a/drivers/staging/omapdrm/omap_crtc.c > > +++ b/drivers/staging/omapdrm/omap_crtc.c > > @@ -119,7 +119,6 @@ static void vblank_cb(void *arg) > > struct omap_crtc *omap_crtc = to_omap_crtc(crtc); > > unsigned long flags; > > > > - WARN_ON(!event); > > spin_lock_irqsave(>event_lock, flags); > > > > /* wakeup userspace */ > > @@ -127,6 +126,7 @@ static void vblank_cb(void *arg) > > drm_send_vblank_event(dev, -1, omap_crtc->event); > > > > omap_crtc->event = NULL; > > + omap_crtc->old_fb = NULL; > > Is old_fb used anywhere? If not we could just remove it. > > Otherwise nice work! On the series: > > Reviewed-by: Imre Deak > > > > > spin_unlock_irqrestore(>event_lock, flags); > > } > > @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg) > > struct drm_framebuffer *old_fb = omap_crtc->old_fb; > > struct drm_gem_object *bo; > > > > - omap_crtc->old_fb = NULL; > > - > > omap_crtc_mode_set_base(crtc, crtc->x, crtc->y, old_fb); > > > > /* really we'd like to setup the callback atomically w/ setting the > > @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc > > *crtc, > > > > DBG("%d -> %d", crtc->fb ? crtc->fb->base.id : -1, fb->base.id); > > > > - if (omap_crtc->event) { > > + if (omap_crtc->old_fb) { Ah, just noticed this adds the use for it :) So ignore my comment above. --Imre > > dev_err(dev->dev, "already a pending flip\n"); > > return -EINVAL; > > } >
[PATCH 11/11] drm/omap: page-flip fixes
On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote: > From: Rob Clark > > Userspace might not request a vblank event. So it is not an error > for 'event' to be NULL, and we shouldn't use it to determine if > there is a pending flip already. > > Signed-off-by: Rob Clark > --- > drivers/staging/omapdrm/omap_crtc.c |6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/omapdrm/omap_crtc.c > b/drivers/staging/omapdrm/omap_crtc.c > index 74e019a..317b854 100644 > --- a/drivers/staging/omapdrm/omap_crtc.c > +++ b/drivers/staging/omapdrm/omap_crtc.c > @@ -119,7 +119,6 @@ static void vblank_cb(void *arg) > struct omap_crtc *omap_crtc = to_omap_crtc(crtc); > unsigned long flags; > > - WARN_ON(!event); > spin_lock_irqsave(>event_lock, flags); > > /* wakeup userspace */ > @@ -127,6 +126,7 @@ static void vblank_cb(void *arg) > drm_send_vblank_event(dev, -1, omap_crtc->event); > > omap_crtc->event = NULL; > + omap_crtc->old_fb = NULL; Is old_fb used anywhere? If not we could just remove it. Otherwise nice work! On the series: Reviewed-by: Imre Deak > > spin_unlock_irqrestore(>event_lock, flags); > } > @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg) > struct drm_framebuffer *old_fb = omap_crtc->old_fb; > struct drm_gem_object *bo; > > - omap_crtc->old_fb = NULL; > - > omap_crtc_mode_set_base(crtc, crtc->x, crtc->y, old_fb); > > /* really we'd like to setup the callback atomically w/ setting the > @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc > *crtc, > > DBG("%d -> %d", crtc->fb ? crtc->fb->base.id : -1, fb->base.id); > > - if (omap_crtc->event) { > + if (omap_crtc->old_fb) { > dev_err(dev->dev, "already a pending flip\n"); > return -EINVAL; > }
[PATCH] drm: Add missing break in the command line mode parsing code
From: Damien LespiauAs we parse the string given on the command line one char at a time, it seems that we do want a break at every case. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_modes.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 28637c1..50bd5c1 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1054,6 +1054,7 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, was_digit = false; } else goto done; + break; case '0' ... '9': was_digit = true; break; -- 1.7.7.5
[PATCH] drm: Fix kdoc comment for drm_crtc_convert_umode
From: Mika KuoppalaSigned-off-by: Mika Kuoppala --- drivers/gpu/drm/drm_crtc.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index ef1b221..bb4c686 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1148,9 +1148,9 @@ static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out, } /** - * drm_crtc_convert_to_umode - convert a modeinfo into a drm_display_mode - * @out: drm_display_mode to return to the user - * @in: drm_mode_modeinfo to use + * drm_crtc_convert_umode - convert a modeinfo into a drm_display_mode + * @out: drm_display_mode to return to the caller + * @in: drm_mode_modeinfo from user * * LOCKING: * None. -- 1.7.9.5
[PATCH v2] Documentation: kernel-parameters.txt Add drm_kms_helper.poll
From: Mika KuoppalaPossibility to disable polling to find connected displays was introduced by commit [1]: commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9 Author: Chris Wilson Date: Fri Aug 20 09:13:36 2010 +0100 drm/kms: Add a module parameter to disable polling Add description for this parameter to kernel-parameters.txt [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9 Signed-off-by: Mika Kuoppala --- Documentation/kernel-parameters.txt | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f777fa9..0f0f071 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -741,6 +741,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted. if its name and a colon are prepended to the EDID name. + drm_kms_helper.poll= + Polling for connected display devices on older systems + without Hot Plug Detect (HPD) support, can be quite + expensive. Poll will happen periodically and can in + worst cases take several hundred milliseconds, + depending on the hardware. This will cause visible + stalls, for example in video playback. These stalls + might happen even when your video is on HDP output + but you have other non HDP outputs in your hw + configuration. If you experience stalls in display + output occurring every 10 seconds, disabling polling + might help. With polling disabled you need to manually + use xrandr to trigger detection. + Format: (1/Y/y=enable, 0/N/n=disable) + default: enabled + dscc4.setup=[NET] dyndbg[="val"] [KNL,DYNAMIC_DEBUG] -- 1.7.9.5
[PATCH] drm/omap: fix allocation size for page addresses array
On Tue, Oct 09, 2012 at 01:01:08PM -0500, Vincent Penquerc'h wrote: > Signed-off-by: Rob Clark > --- > drivers/staging/omapdrm/omap_gem.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Having a patch "From:" someone else is fine, but please get a signed-off-by from them as well. Care to resend? Also, take a look at Documentation/SubmittingPatches which shows how to put the "From:" line in the body of the changelog area so that the From: part shows up correctly when I commit it. thanks, greg k-h
[PATCH v5 0/3] Enhanced EDID quirk functionality
On 10/8/12 7:22 PM, Ian Pilcher wrote: > On 09/28/2012 02:03 AM, Ian Pilcher wrote: >> As promised, this patch series does only the following: >> >> * Add user-defined EDID quirks -- via sysfs or a module parameter >> * Add an EDID quirk flag to disable all HDMI functionality >>(InfoFrames) >> * Add a quirk to disable HDMI InfoFrames for the LG L246WP >> > > ACK? NACK? I'm on crack? > > (I'm starting to think that this is some sort of hazing ritual.) Sorry, I'm just not paying close attention to EDID stuff at the moment. The series as is is clearly better than what we've got. I still think there's something fundamentally amiss with a display that doesn't want to accept InfoFrames, but without having it in hand to mess with - and without wanting to play telephone to figure it out - I'm fine with this. Reviewed-by: Adam Jackson - ajax
[PATCH] drm/radeon/cayman: set VM max pfn at MC init
On 08.10.2012 18:25, alexdeucher at gmail.com wrote: > From: Alex Deucher > > No need to emit them at VM flush as we no longer use > variable sized page tables now that we support 2 level > page tables. This matches the behavior of SI (which > does not support variable sized page tables). > > Signed-off-by: Alex Deucher Yeah, wanted to do so also, but have somehow forgotten it. Reviewed-by: Christian K?nig > --- > drivers/gpu/drm/radeon/ni.c |8 +--- > 1 files changed, 1 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c > index cfb9276..cc0701a 100644 > --- a/drivers/gpu/drm/radeon/ni.c > +++ b/drivers/gpu/drm/radeon/ni.c > @@ -776,7 +776,7 @@ static int cayman_pcie_gart_enable(struct radeon_device > *rdev) >*/ > for (i = 1; i < 8; i++) { > WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (i << 2), 0); > - WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i << 2), 0); > + WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i << 2), > rdev->vm_manager.max_pfn); > WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (i << 2), > rdev->gart.table_addr >> 12); > } > @@ -1576,12 +1576,6 @@ void cayman_vm_flush(struct radeon_device *rdev, int > ridx, struct radeon_vm *vm) > if (vm == NULL) > return; > > - radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_START_ADDR + > (vm->id << 2), 0)); > - radeon_ring_write(ring, 0); > - > - radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + > (vm->id << 2), 0)); > - radeon_ring_write(ring, rdev->vm_manager.max_pfn); > - > radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + > (vm->id << 2), 0)); > radeon_ring_write(ring, vm->pd_gpu_addr >> 12); >
[PATCH] drm/radeon: check if pcie gen 2 is already enabled (v2)
From: Alex DeucherIf so, skip enabling it to save time. v2: coding style fixes Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/evergreen.c |7 ++- drivers/gpu/drm/radeon/r600.c |6 ++ 2 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index a1f49c5..14313ad 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -3431,9 +3431,14 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev) if (!(mask & DRM_PCIE_SPEED_50)) return; + speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL); + if (speed_cntl & LC_CURRENT_DATA_RATE) { + DRM_INFO("PCIE gen 2 link speeds already enabled\n"); + return; + } + DRM_INFO("enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0\n"); - speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL); if ((speed_cntl & LC_OTHER_SIDE_EVER_SENT_GEN2) || (speed_cntl & LC_OTHER_SIDE_SUPPORTS_GEN2)) { diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index 70c800f..cda280d 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -3703,6 +3703,12 @@ static void r600_pcie_gen2_enable(struct radeon_device *rdev) if (!(mask & DRM_PCIE_SPEED_50)) return; + speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL); + if (speed_cntl & LC_CURRENT_DATA_RATE) { + DRM_INFO("PCIE gen 2 link speeds already enabled\n"); + return; + } + DRM_INFO("enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0\n"); /* 55 nm r6xx asics */ -- 1.7.7.5
[PATCH v5 1/3] drm: Add user-defined EDID quirks capability
r, struct edid *edid) > > -{ > > +{ > > struct detailed_mode_closure closure = { > > connector, edid, 0, 0, 0 > > }; > > @@ -1615,15 +2004,12 @@ void drm_edid_to_eld(struct drm_connector > *connector, struct edid *edid) > > > > eld[0] = 2 << 3;/* ELD version: 2 */ > > > > - eld[16] = edid->mfg_id[0]; > > - eld[17] = edid->mfg_id[1]; > > - eld[18] = edid->prod_code[0]; > > - eld[19] = edid->prod_code[1]; > > + *(u32 *)([16]) = edid->display_id.u; > > > > if (cea[1] >= 3) > > for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) { > > dbl = db[0] & 0x1f; > > - > > + > > switch ((db[0] & 0xe0) >> 5) { > > case AUDIO_BLOCK: > > /* Audio Data Block, contains SADs */ > > diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c > > index 21bcd4a..b939d51 100644 > > --- a/drivers/gpu/drm/drm_stub.c > > +++ b/drivers/gpu/drm/drm_stub.c > > @@ -46,16 +46,22 @@ EXPORT_SYMBOL(drm_vblank_offdelay); > > unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */ > > EXPORT_SYMBOL(drm_timestamp_precision); > > > > +char *drm_edid_quirks = NULL; > > +EXPORT_SYMBOL(drm_edid_quirks); > > + > > MODULE_AUTHOR(CORE_AUTHOR); > > MODULE_DESCRIPTION(CORE_DESC); > > MODULE_LICENSE("GPL and additional rights"); > > MODULE_PARM_DESC(debug, "Enable debug output"); > > MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable > [msecs]"); > > MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps > [usecs]"); > > +MODULE_PARM_DESC(edid_quirks, "MFG:prod:flags[,MFG:prod:flags[...]]\n" > > + "(See Documentation/EDID/edid_quirks.txt)"); > > > > module_param_named(debug, drm_debug, int, 0600); > > module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600); > > module_param_named(timestamp_precision_usec, drm_timestamp_precision, > int, 0600); > > +module_param_named(edid_quirks, drm_edid_quirks, charp, 0400); > > > > struct idr drm_minors_idr; > > > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c > > index 45ac8d6..84dc365 100644 > > --- a/drivers/gpu/drm/drm_sysfs.c > > +++ b/drivers/gpu/drm/drm_sysfs.c > > @@ -84,6 +84,11 @@ static CLASS_ATTR_STRING(version, S_IRUGO, > > __stringify(CORE_PATCHLEVEL) " " > > CORE_DATE); > > > > +static CLASS_ATTR(edid_quirks_size, 0400, drm_edid_quirks_size_show, 0); > > + > > +static CLASS_ATTR(edid_quirks, 0600, drm_edid_quirks_show, > > + drm_edid_quirks_store); > > + > > /** > > * drm_sysfs_create - create a struct drm_sysfs_class structure > > * @owner: pointer to the module that is to "own" this struct > drm_sysfs_class > > @@ -113,10 +118,22 @@ struct class *drm_sysfs_create(struct module > *owner, char *name) > > if (err) > > goto err_out_class; > > > > + err = class_create_file(class, _attr_edid_quirks_size); > > + if (err) > > + goto err_out_version; > > + > > + err = class_create_file(class, _attr_edid_quirks); > > + if (err) > > + goto err_out_quirks_size; > > + > > class->devnode = drm_devnode; > > > > return class; > > > > +err_out_quirks_size: > > + class_remove_file(class, _attr_edid_quirks_size); > > +err_out_version: > > + class_remove_file(class, _attr_version.attr); > > err_out_class: > > class_destroy(class); > > err_out: > > @@ -132,6 +149,8 @@ void drm_sysfs_destroy(void) > > { > > if ((drm_class == NULL) || (IS_ERR(drm_class))) > > return; > > + class_remove_file(drm_class, _attr_edid_quirks); > > + class_remove_file(drm_class, _attr_edid_quirks_size); > > class_remove_file(drm_class, _attr_version.attr); > > class_destroy(drm_class); > > drm_class = NULL; > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > > index d6b67bb..c947f3e 100644 > > --- a/include/drm/drmP.h > > +++ b/include/drm/drmP.h > > @@ -1501,6 +1501,7 @@ extern unsigned int drm_debug; > > > > extern unsigned int drm_vblank_offdelay; > > extern unsigned int drm_timestamp_precision; > > +extern char *drm_edid_quirks; > > > > extern struct class *drm_class; > > extern struct proc_dir_entry *drm_proc_root; > > @@ -1612,6 +1613,15 @@ void drm_gem_vm_open(struct vm_area_struct *vma); > > void drm_gem_vm_close(struct vm_area_struct *vma); > > int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma); > > > > + /* EDID support (drm_edid.c) */ > > +void drm_edid_quirks_param_process(void); > > +ssize_t drm_edid_quirks_size_show(struct class *class, > > + struct class_attribute *attr, char *buf); > > +ssize_t drm_edid_quirks_show(struct class *class, struct > class_attribute *attr, > > + char *buf); > > +ssize_t drm_edid_quirks_store(struct class *class, struct > class_attribute *attr, > > + const char *buf, size_t count); > > + > > #include "drm_global.h" > > > > static inline void > > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h > > index 0cac551..713229b 100644 > > --- a/include/drm/drm_edid.h > > +++ b/include/drm/drm_edid.h > > @@ -202,11 +202,18 @@ struct detailed_timing { > > #define DRM_EDID_FEATURE_PM_SUSPEND (1 << 6) > > #define DRM_EDID_FEATURE_PM_STANDBY (1 << 7) > > > > +union edid_display_id { > > + struct { > > + __be16 mfg_id; > > + __le16 prod_code; > > + } __attribute__((packed)) s; > > + u32 u; > > +}; > > I think adding this union is counterproductive. The u32 version is > helpful in one comparison and one assignment, while making all the rest > just slightly more confusing. > > > + > > struct edid { > > u8 header[8]; > > /* Vendor & product info */ > > - u8 mfg_id[2]; > > - u8 prod_code[2]; > > + union edid_display_id display_id; > > u32 serial; /* FIXME: byte order */ > > u8 mfg_week; > > u8 mfg_year; > > @@ -242,8 +249,6 @@ struct edid { > > u8 checksum; > > } __attribute__((packed)); > > > > -#define EDID_PRODUCT_ID(e) ((e)->prod_code[0] | ((e)->prod_code[1] << > 8)) > > - > > struct drm_encoder; > > struct drm_connector; > > struct drm_display_mode; > > -- > > 1.7.11.4 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/7ec2da10/attachment-0001.html>
[PATCH 02/11] drm/i915: use drm_send_vblank_event() helper
On Mon, Oct 08, 2012 at 02:50:40PM -0500, Rob Clark wrote: > From: Rob Clark > > Signed-off-by: Rob Clark Maybe note in the commit message that after this change pageflip events will also fire the vblank_event_delivered tracepoint. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_display.c | 15 ++- > 1 file changed, 2 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index f5bcf6f..4716c83 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6158,8 +6158,6 @@ static void do_intel_finish_page_flip(struct drm_device > *dev, > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > struct intel_unpin_work *work; > struct drm_i915_gem_object *obj; > - struct drm_pending_vblank_event *e; > - struct timeval tvbl; > unsigned long flags; > > /* Ignore early vblank irqs */ > @@ -6175,17 +6173,8 @@ static void do_intel_finish_page_flip(struct > drm_device *dev, > > intel_crtc->unpin_work = NULL; > > - if (work->event) { > - e = work->event; > - e->event.sequence = drm_vblank_count_and_time(dev, > intel_crtc->pipe, ); > - > - e->event.tv_sec = tvbl.tv_sec; > - e->event.tv_usec = tvbl.tv_usec; > - > - list_add_tail(>base.link, > - >base.file_priv->event_list); > - wake_up_interruptible(>base.file_priv->event_wait); > - } > + if (work->event) > + drm_send_vblank_event(dev, intel_crtc->pipe, work->event); > > drm_vblank_put(dev, intel_crtc->pipe); > > -- > 1.7.9.5 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/2 v6] of: add generic videomode description
Hi Laurent, On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote: > Hi Steffen, > > On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote: > > On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote: > > > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote: > > > > Get videomode from devicetree in a format appropriate for the > > > > backend. drm_display_mode and fb_videomode are supported atm. > > > > Uses the display signal timings from of_display_timings > > > > > > > > Signed-off-by: Steffen Trumtrar > > > > --- > > > > > > > > drivers/of/Kconfig |5 + > > > > drivers/of/Makefile |1 + > > > > drivers/of/of_videomode.c| 212 +++ > > > > include/linux/of_videomode.h | 41 > > > > 4 files changed, 259 insertions(+) > > > > create mode 100644 drivers/of/of_videomode.c > > > > create mode 100644 include/linux/of_videomode.h > > [snip] > > > > > diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c > > > > new file mode 100644 > > > > index 000..76ac16e > > > > --- /dev/null > > > > +++ b/drivers/of/of_videomode.c > > [snip] > > > > > +int videomode_from_timing(struct display_timings *disp, struct > > > > videomode *vm, > > > > + int index) > > > > +{ > > > > + struct signal_timing *st = NULL; > > > > + > > > > + if (!vm) > > > > + return -EINVAL; > > > > + > > > > > > What about making vm a mandatory argument ? It looks to me like a caller > > > bug if vm is NULL. > > > > The caller must provide the struct videomode, yes. Wouldn't the kernel hang > > itself with a NULL pointer exception, if I just work with it ? > > The kernel would oops, clearly showing the caller that a non-null vm is > needed > :-) > Okay. No error checking it is then. > > > > + st = display_timings_get(disp, index); > > > > + > > > > > > You can remove the blank line. > > > > > > > + if (!st) { > > > > + pr_err("%s: no signal timings found\n", __func__); > > > > + return -EINVAL; > > > > + } > > > > + > > > > + vm->pixelclock = signal_timing_get_value(>pixelclock, 0); > > > > + vm->hactive = signal_timing_get_value(>hactive, 0); > > > > + vm->hfront_porch = signal_timing_get_value(>hfront_porch, > > > > 0); > > > > + vm->hback_porch = signal_timing_get_value(>hback_porch, 0); > > > > + vm->hsync_len = signal_timing_get_value(>hsync_len, 0); > > > > + > > > > + vm->vactive = signal_timing_get_value(>vactive, 0); > > > > + vm->vfront_porch = signal_timing_get_value(>vfront_porch, > > > > 0); > > > > + vm->vback_porch = signal_timing_get_value(>vback_porch, 0); > > > > + vm->vsync_len = signal_timing_get_value(>vsync_len, 0); > > > > + > > > > + vm->vah = st->vsync_pol_active_high; > > > > + vm->hah = st->hsync_pol_active_high; > > > > + vm->interlaced = st->interlaced; > > > > + vm->doublescan = st->doublescan; > > > > + > > > > + return 0; > > > > +} > > > > + > > > > +int of_get_videomode(struct device_node *np, struct videomode *vm, int > > > > index) > > > > > > I wonder how to avoid abuse of this functions. It's a useful helper for > > > drivers that need to get a video mode once only, but would result in lower > > > performances if a driver calls it for every mode. Drivers must call > > > of_get_display_timing_list instead in that case and case the display > > > timings. I'm wondering whether we should really expose of_get_videomode. > > > > The intent was to let the driver decide. That way all the other overhead may > > be skipped. > > My point is that driver writers might just call of_get_videomode() in a loop, > not knowing that it's expensive. I want to avoid that. We need to at least > add > kerneldoc to the function stating that this shouldn't be done. > You're right. That should be made clear in the code. > > > > +{ > > > > + struct display_timings *disp; > > > > + int ret = 0; > > > > > > No need to assign ret to 0 here. > > > > Ah, yes. Unneeded in this case. > > > > > > + > > > > + disp = of_get_display_timing_list(np); > > > > + > > > > > > You can remove the blank line. > > > > > > > + if (!disp) { > > > > + pr_err("%s: no timings specified\n", __func__); > > > > + return -EINVAL; > > > > + } > > > > + > > > > + if (index == OF_DEFAULT_TIMING) > > > > + index = disp->default_timing; > > > > + > > > > + ret = videomode_from_timing(disp, vm, index); > > > > + > > > > > > No need for a blank line. > > > > > > > + if (ret) > > > > + return ret; > > > > + > > > > + display_timings_release(disp); > > > > + > > > > + if (!vm) { > > > > + pr_err("%s: could not get videomode %d\n", __func__, > > > > index); > > > > + return -EINVAL; > > > > +
[PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: > Tapani P?lli writes: > >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) > > Couldn't this just be done with androgenizer without making a > maintenance mess in the upstream code? > We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/8197482c/attachment.pgp>
[PATCH] drm/radeon: check if pcie gen 2 is already enabled
2012/10/8 : > + if (speed_cntl & LC_CURRENT_DATA_RATE) { > + DRM_INFO("PCIE gen 2 link speeds already enabled\n"); > + return; > + } else > + DRM_INFO("enabling PCIE gen 2 link speeds, disable with > radeon.pcie_gen2=0\n"); > + See documentation/CodingStyle: > This does not apply if only one branch of a conditional statement is a single > statement; in the latter case use braces in both branches: Your else should use braces :) -- Rafa?
[PATCH] drm/radeon: check if pcie gen 2 is already enabled
On Tue, Oct 9, 2012 at 3:05 AM, Rafa? Mi?ecki wrote: > 2012/10/8 : >> + if (speed_cntl & LC_CURRENT_DATA_RATE) { >> + DRM_INFO("PCIE gen 2 link speeds already enabled\n"); >> + return; >> + } else >> + DRM_INFO("enabling PCIE gen 2 link speeds, disable with >> radeon.pcie_gen2=0\n"); >> + > > See documentation/CodingStyle: > >> This does not apply if only one branch of a conditional statement is a single >> statement; in the latter case use braces in both branches: > > Your else should use braces :) I'll fix that up. Alex
[PATCH] drm/radeon: check if pcie gen 2 is already enabled
On Tue, Oct 9, 2012 at 2:26 AM, Paul Menzel wrote: > Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeucher at gmail.com: >> From: Alex Deucher >> >> If so, skip enabling it. > > Does that fix any error/problem or is it just for speed reasons? It doesn't fix anything that I know of. Just speed. Alex > >> Signed-off-by: Alex Deucher >> --- >> drivers/gpu/drm/radeon/evergreen.c |8 ++-- >> drivers/gpu/drm/radeon/r600.c |7 ++- >> 2 files changed, 12 insertions(+), 3 deletions(-) > > [?] > > > Thanks, > > Paul
[PATCH] drm/radeon: check if pcie gen 2 is already enabled
Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeucher at gmail.com: > From: Alex Deucher > > If so, skip enabling it. Does that fix any error/problem or is it just for speed reasons? > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/radeon/evergreen.c |8 ++-- > drivers/gpu/drm/radeon/r600.c |7 ++- > 2 files changed, 12 insertions(+), 3 deletions(-) [?] Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/7ee68b1c/attachment.pgp>
[PATCH v3 3/3] Android.mk: use LOCAL_COPY_HEADERS to export headers.
On Mon, Oct 08, 2012 at 03:52:20PM +0300, Tapani P?lli wrote: > From: Haitao Huang > > Export necessary header files used by other components for Android, > such as libva intel-driver, gralloc, hwcomposer, etc. > > Signed-off-by: Haitao Huang > Signed-off-by: Chad Versace Reviewed-by: Oliver McFadden > --- > [chad: Fixed inconsistent indentation.] > Android.mk | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/Android.mk b/Android.mk > index 1029dc6..68db5df 100644 > --- a/Android.mk > +++ b/Android.mk > @@ -1,5 +1,5 @@ > # > -# Copyright ? 2011 Intel Corporation > +# Copyright ? 2011-2012 Intel Corporation > # > # Permission is hereby granted, free of charge, to any person obtaining a > # copy of this software and associated documentation files (the "Software"), > @@ -45,6 +45,16 @@ LOCAL_C_INCLUDES := \ > LOCAL_CFLAGS := \ > -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 > > +LOCAL_COPY_HEADERS :=\ > + xf86drm.h\ > + include/drm/drm_fourcc.h \ > + include/drm/drm.h\ > + include/drm/drm_mode.h \ > + include/drm/drm_sarea.h \ > + include/drm/i915_drm.h \ > + intel/intel_bufmgr.h \ > + > +LOCAL_COPY_HEADERS_TO := libdrm > include $(BUILD_SHARED_LIBRARY) > > include $(LOCAL_PATH)/intel/Android.mk > -- > 1.7.11.7 > -- Oliver McFadden.
[RFC 1/4] time: export getnstime_raw_and_real for DRM
On 08.10.12 13:35, Imre Deak wrote: > On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote: >> [...] >> >> But then Psychtoolbox checks each timestamp it gets from somewhere >> "outside" (OML_sync_control / INTEL_swap_events / ALSA audio timestamps, >> network receive timestamps, evdev, x11, ...) if it is in gettimeofday() >> aka CLOCK_REALTIME aka wall time or in CLOCK_MONOTONIC time and just >> remaps to whatever its reference clock is. >> >> There's no way around this than to have no fixed expectations, but to >> remap stuff on the fly, because different parts of the Linux universe >> have decided on different time bases, or even switched somewhere from >> one kernel version to the next in the last years, e.g., ALSA, which at >> some time switched from wall clock to CLOCK_MONOTONIC. Sometimes >> clock_gettime() wasn't available at all in older setups, so there only >> was gettimeofday(). Or toolkits like GStreamer use different timebases >> dependent on OS and sometimes even on plugins. >> >> I would expect that other timing sensitive apps have to have ways to >> handle this in similar ways. > > I think the question is, can we be sure? I don't think there is any > guarantee that random application X will not be confused by an > unconditional switch to monotonic timestamps. > >> Wrt. to the drm vblank/pageflip timestamps, the userspace extensions >> which expose these (INTEL_swap_events, OML_sync_control) don't allow >> apps to select which timebase to use, they define monotonic time as what >> is returned, so i don't know how a userspace app could actually ask the >> DRM for one or the other format? So i guess just switching to >> CLOCK_MONOTONIC shouldn't be that bad. > > An application could just use the kernel DRM interface directly. I admit > this is not very likely but this is what should determine the rules by > which we change the ABI. > Ok, that's a good point, agreed. -mario
[PATCH 00/11] page-flip cleanups and fixes
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote: > From: Rob Clark > > Add a helper fxn to send vblank event after pageflip, plus a handful > of fixes for other issues that I noticed in the process. FWIW, patches 1-5 and 7 (with a fix to 1st) are: Reviewed-by: Marcin Slusarz > > Other than OMAP, the changes are just compile tested, so would be > good to get a quick look from the maintainers of various drivers. > > Rob Clark (11): > drm: add drm_send_vblank_event() helper > drm/i915: use drm_send_vblank_event() helper > drm/nouveau: use drm_send_vblank_event() helper > drm/radeon: use drm_send_vblank_event() helper > drm/exynos: use drm_send_vblank_event() helper > drm/exynos: page flip fixes > drm/shmob: use drm_send_vblank_event() helper > drm/imx: use drm_send_vblank_event() helper > drm/imx: page flip fixes > drm/omap: use drm_send_vblank_event() helper > drm/omap: page-flip fixes > > drivers/gpu/drm/drm_irq.c | 65 > +++-- > drivers/gpu/drm/exynos/exynos_drm_crtc.c |1 - > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 + > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 10 + > drivers/gpu/drm/exynos/exynos_mixer.c |9 +--- > drivers/gpu/drm/i915/intel_display.c | 15 +-- > drivers/gpu/drm/nouveau/nouveau_display.c | 13 +- > drivers/gpu/drm/radeon/radeon_display.c | 13 ++ > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 19 ++--- > drivers/staging/imx-drm/ipuv3-crtc.c | 32 -- > drivers/staging/omapdrm/omap_crtc.c | 37 > include/drm/drmP.h|2 + > 12 files changed, 78 insertions(+), 148 deletions(-) > > --
[PATCH 01/11] drm: add drm_send_vblank_event() helper
On Mon, Oct 08, 2012 at 02:50:39PM -0500, Rob Clark wrote: > From: Rob Clark > > A helper that drivers can use to send vblank event after a pageflip. > If the driver doesn't support proper vblank irq based time/seqn then > just pass -1 for the pipe # to get do_gettimestamp() behavior (since > there are a lot of drivers that don't use drm_vblank_count_and_time()) > > Also an internal send_vblank_event() helper for the various other code > paths within drm_irq that also need to send vblank events. > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/drm_irq.c | 65 > + > include/drm/drmP.h|2 ++ > 2 files changed, 44 insertions(+), 23 deletions(-) > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index 076c4a8..7a00d94 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -802,6 +802,43 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, > int crtc, > } > EXPORT_SYMBOL(drm_vblank_count_and_time); > > +static void send_vblank_event(struct drm_pending_vblank_event *e, > + unsigned long seq, struct timeval *now) > +{ > + e->event.sequence = seq; > + e->event.tv_sec = now->tv_sec; > + e->event.tv_usec = now->tv_usec; > + > + list_add_tail(>base.link, > + >base.file_priv->event_list); > + wake_up_interruptible(>base.file_priv->event_wait); > + trace_drm_vblank_event_delivered(e->base.pid, e->pipe, > + e->event.sequence); > +} > + > +/** > + * drm_send_vblank_event - helper to send vblank event after pageflip > + * @dev: DRM device > + * @crtc: CRTC in question > + * @e: the event to send > + * > + * Updates sequence # and timestamp on event, and sends it to userspace. > + */ > +void drm_send_vblank_event(struct drm_device *dev, int crtc, > + struct drm_pending_vblank_event *e) > +{ > + struct timeval now; > + unsigned int seq; > + if (crtc >= 0) { > + seq = drm_vblank_count_and_time(dev, crtc, ); > + } else { > + seq = 0; > + do_gettimeofday(); > + } > + send_vblank_event(e, seq, ); > +} > +EXPORT_SYMBOL(drm_send_vblank_event); > + > /** > * drm_update_vblank_count - update the master vblank counter > * @dev: DRM device > @@ -955,15 +992,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc) > DRM_DEBUG("Sending premature vblank event on disable: \ > wanted %d, current %d\n", > e->event.sequence, seq); > - > - e->event.sequence = seq; > - e->event.tv_sec = now.tv_sec; > - e->event.tv_usec = now.tv_usec; > + list_del(>base.link); > drm_vblank_put(dev, e->pipe); > - list_move_tail(>base.link, >base.file_priv->event_list); > - wake_up_interruptible(>base.file_priv->event_wait); > - trace_drm_vblank_event_delivered(e->base.pid, e->pipe, > - e->event.sequence); > + send_vblank_event(e, seq, ); > } > > spin_unlock_irqrestore(>vbl_lock, irqflags); > @@ -1107,15 +1138,8 @@ static int drm_queue_vblank_event(struct drm_device > *dev, int pipe, > > e->event.sequence = vblwait->request.sequence; > if ((seq - vblwait->request.sequence) <= (1 << 23)) { > - e->event.sequence = seq; > - e->event.tv_sec = now.tv_sec; > - e->event.tv_usec = now.tv_usec; > drm_vblank_put(dev, pipe); > - list_add_tail(>base.link, >base.file_priv->event_list); > - wake_up_interruptible(>base.file_priv->event_wait); > - vblwait->reply.sequence = seq; D?j? vu http://lists.freedesktop.org/archives/dri-devel/2011-April/010693.html :) > - trace_drm_vblank_event_delivered(current->pid, pipe, > - vblwait->request.sequence); > + send_vblank_event(e, seq, ); > } else { > /* drm_handle_vblank_events will call drm_vblank_put */ > list_add_tail(>base.link, >vblank_event_list); > @@ -1256,14 +1280,9 @@ static void drm_handle_vblank_events(struct drm_device > *dev, int crtc) > DRM_DEBUG("vblank event on %d, current %d\n", > e->event.sequence, seq); > > - e->event.sequence = seq; > - e->event.tv_sec = now.tv_sec; > - e->event.tv_usec = now.tv_usec; > + list_del(>base.link); > drm_vblank_put(dev, e->pipe); > - list_move_tail(>base.link, >base.file_priv->event_list); > - wake_up_interruptible(>base.file_priv->event_wait); > - trace_drm_vblank_event_delivered(e->base.pid, e->pipe, > - e->event.sequence); > + send_vblank_event(e, seq, ); > } > >
[PATCH] drm/nv40/pm: silence GCC warnings
Building nv40_pm.o triggers these GCC warnings: drivers/gpu/drm/nouveau/nv40_pm.c: In function 'nv40_pm_clocks_pre': drivers/gpu/drm/nouveau/nv40_pm.c:164:41: warning: 'log2P' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:38: warning: 'M2' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:45: warning: 'M1' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:25: warning: 'N2' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:51: warning: 'N1' may be used uninitialized in this function [-Wmaybe-uninitialized] But these variables seem to be initialized when used there. If the preceding call of nv40_calc_pll() fails it will return a negative value and this code will never be run. And if that call succeeds it will return zero and all those five variables ought to be initialized when used there. Anyhow, it turns out that these warnings can be silenced by giving GCC slightly more detailed information a little earlier. See, get_pll_limits() returns an error-code integer (ie, negative on failure, zero on success). And a trivial tweak to nv40_calc_pll() that takes this into account makes these errors go away. Signed-off-by: Paul Bolle --- 0) I noticed these warnings while building recent releases (eg, v3.6-rc7, v3.6, and v3.6.1) on current Fedora 17, using Fedora's default config. But I found identical warnings in a build log for release v3.4-rc1. I didn't bother checking earlier releases. 1) Compile tested only (I do not have the hardware involved at hand). 2) This is not the only place where get_pll_limits()'s return value is checked. But this is apparently the only place where GCC needs to know that any non-zero return will be negative. drivers/gpu/drm/nouveau/nv40_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c index e66273a..3df30cb 100644 --- a/drivers/gpu/drm/nouveau/nv40_pm.c +++ b/drivers/gpu/drm/nouveau/nv40_pm.c @@ -114,7 +114,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct pll_lims *pll, int ret; ret = get_pll_limits(dev, reg, pll); - if (ret) + if (ret < 0) return ret; if (clk < pll->vco1.maxfreq) -- 1.7.11.4
Re: [PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: Tapani Pälli tapani.pa...@intel.com writes: Upstreaming old set of patches here to enable Android support in libdrm. Some little rebasing was required for the first one. Chad Versace (2): libdrm,intel: Factor source file lists into sources.mk libdrm,intel: Add Android makefiles (v2) Couldn't this just be done with androgenizer without making a maintenance mess in the upstream code? We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gma500: medfield: drop bogus NULL check in mdfld_dsi_output_init()
From: Wei Yongjun yongjun_...@trendmicro.com.cn Drop the NULL test for dev since it never be NULL. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c b/drivers/gpu/drm/gma500/mdfld_dsi_output.c index 32dba2a..b6f49d9 100644 --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c @@ -506,7 +506,7 @@ void mdfld_dsi_output_init(struct drm_device *dev, dev_dbg(dev-dev, init DSI output on pipe %d\n, pipe); - if (!dev || ((pipe != 0) (pipe != 2))) { + if ((pipe != 0) (pipe != 2)) { DRM_ERROR(Invalid parameter\n); return; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Update on the CEC API
Hi Hans, On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote: Hi all, During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) had a discussion on how to handle the CEC protocol that's part of the HDMI standard. The decision was made to create a CEC bus with CEC clients, each represented by a /dev/cecX device. So this is independent of the V4L or DRM APIs. In addition interested subsystems (alsa for the Audio Return Channel, and possibly networking as well for ethernet over HDMI) can intercept/send CEC messages as well if needed. Particularly for the CEC additions made in HDMI 1.4a it is no longer possible to handle the CEC protocol completely in userspace, but part of the intelligence has to be moved to kernelspace. What kind of intelligence are you talking about? I see nothing in HDMI 1.4a or earlier that requires doing stuff in kernelspace besides managing control to the hardware, but I might be missing something. In my opinion ARC is just a control mechanism, and can be dealt with in user- space, since you really want to just have hints about when ARC is enabled/disabled to take appropriate actions on the audio outputs or your system. I've started working on this API but I am still at the stage of playing around with it and thinking about the best way this functionality should be exposed. At least I managed to get the first CEC packets transferred today :-) It will probably be a few weeks before I post something, but in the meantime if you want to use CEC and have certain requirements that need to be met, please let me know. If only so that I can be certain I haven't forgotten anything. Here is my wish-list, if I may: - allow for a CEC adapter to be in detached / attached mode, particularly useful if the hardware doing CEC can process a basic set of messages to act a a global wake-up source for the system - allow for a CEC adapter to define several receive modes: unicast and promiscuous, which is useful for dumping the CEC bus messages - make the CEC adapter API asynchronous for the data path, so it is easy for a driver to report completion of a successfully transmitted/received CEC frame Thank you! -- Florian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gma500: medfield: drop bogus NULL check in mdfld_dsi_output_init()
On Mon, Oct 08, 2012 at 10:44:06PM +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Drop the NULL test for dev since it never be NULL. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c b/drivers/gpu/drm/gma500/mdfld_dsi_output.c index 32dba2a..b6f49d9 100644 --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c @@ -506,7 +506,7 @@ void mdfld_dsi_output_init(struct drm_device *dev, dev_dbg(dev-dev, init DSI output on pipe %d\n, pipe); - if (!dev || ((pipe != 0) (pipe != 2))) { + if ((pipe != 0) (pipe != 2)) { It would be nice to remove redundant parentheses while you're there. Otherwise Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com DRM_ERROR(Invalid parameter\n); return; } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Kirill A. Shutemov ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On 10/7/2012 11:01 PM, Tomi Valkeinen wrote: On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote: In general, I might be misunderstanding something, but don't we have to distinguish between 2 types of information about display timings: (1) is defined by the display controller requirements, is known to the display driver and doesn't need to be present in timings DT. We did have some of these parameters in board data previously, because we didn't have proper display controller drivers... (2) is board specific configuration, and is such it has to be present in DT. In that way, doesn't interlaced belong to type (1) and thus doesn't need to be present in DT? As I see it, this DT data is about the display (most commonly LCD panel), i.e. what video mode(s) the panel supports. If things were done my way, the panel's supported timings would be defined in the driver for the panel, and DT would be left to describe board specific data, but this approach has its benefits. Thus, if you connect an interlaced panel to your board, Do interlaced panels exist? I have never seen one. you need to tell the display controller that this panel requires interlace signal. Also, pixel clock source doesn't make sense in this context, as this doesn't describe the actual used configuration, but only what the panel supports. Of course, if this is about describing the hardware, the default-mode property doesn't really fit in... Tomi ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Update on the CEC API
On Monday 08 October 2012 17:49:00 Hans Verkuil wrote: On Mon October 8 2012 17:06:20 Florian Fainelli wrote: Hi Hans, On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote: Hi all, During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) had a discussion on how to handle the CEC protocol that's part of the HDMI standard. The decision was made to create a CEC bus with CEC clients, each represented by a /dev/cecX device. So this is independent of the V4L or DRM APIs. In addition interested subsystems (alsa for the Audio Return Channel, and possibly networking as well for ethernet over HDMI) can intercept/send CEC messages as well if needed. Particularly for the CEC additions made in HDMI 1.4a it is no longer possible to handle the CEC protocol completely in userspace, but part of the intelligence has to be moved to kernelspace. What kind of intelligence are you talking about? I see nothing in HDMI 1.4a or earlier that requires doing stuff in kernelspace besides managing control to the hardware, but I might be missing something. Most notably: handling the new hotplug message. That's something that kernel drivers need to know. Some ARC messages might be relevant for ALSA drivers as well, but I need to look into those more carefully. Also remote control messages might optionally be handled through an input driver. Ok, then maybe just stick to the standard CEC_UI_* key codes, and let people having proprietary UI functions do the rest in user-space, or write their own input driver. In my opinion ARC is just a control mechanism, and can be dealt with in user- space, since you really want to just have hints about when ARC is enabled/disabled to take appropriate actions on the audio outputs or your system. I've started working on this API but I am still at the stage of playing around with it and thinking about the best way this functionality should be exposed. At least I managed to get the first CEC packets transferred today :-) It will probably be a few weeks before I post something, but in the meantime if you want to use CEC and have certain requirements that need to be met, please let me know. If only so that I can be certain I haven't forgotten anything. Here is my wish-list, if I may: - allow for a CEC adapter to be in detached / attached mode, particularly useful if the hardware doing CEC can process a basic set of messages to act a a global wake-up source for the system I have hardware that can do that, so I want to look into supporting this. - allow for a CEC adapter to define several receive modes: unicast and promiscuous, which is useful for dumping the CEC bus messages I don't think I have hardware for that, but it shouldn't be difficult to add. Definitively not, just let a driver writer specify a flag to advertise this capability and have a getter/setter to specify the receive mode. - make the CEC adapter API asynchronous for the data path, so it is easy for a driver to report completion of a successfully transmitted/received CEC frame Already done. Great, thanks! -- Florian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled
Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeuc...@gmail.com: From: Alex Deucher alexander.deuc...@amd.com If so, skip enabling it. Does that fix any error/problem or is it just for speed reasons? Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/evergreen.c |8 ++-- drivers/gpu/drm/radeon/r600.c |7 ++- 2 files changed, 12 insertions(+), 3 deletions(-) […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled
2012/10/8 alexdeuc...@gmail.com: + if (speed_cntl LC_CURRENT_DATA_RATE) { + DRM_INFO(PCIE gen 2 link speeds already enabled\n); + return; + } else + DRM_INFO(enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0\n); + See documentation/CodingStyle: This does not apply if only one branch of a conditional statement is a single statement; in the latter case use braces in both branches: Your else should use braces :) -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2 v6] of: add generic videomode description
Hi Laurent, On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote: Hi Steffen, On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote: On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote: On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote: Get videomode from devicetree in a format appropriate for the backend. drm_display_mode and fb_videomode are supported atm. Uses the display signal timings from of_display_timings Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- drivers/of/Kconfig |5 + drivers/of/Makefile |1 + drivers/of/of_videomode.c| 212 +++ include/linux/of_videomode.h | 41 4 files changed, 259 insertions(+) create mode 100644 drivers/of/of_videomode.c create mode 100644 include/linux/of_videomode.h [snip] diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c new file mode 100644 index 000..76ac16e --- /dev/null +++ b/drivers/of/of_videomode.c [snip] +int videomode_from_timing(struct display_timings *disp, struct videomode *vm, + int index) +{ + struct signal_timing *st = NULL; + + if (!vm) + return -EINVAL; + What about making vm a mandatory argument ? It looks to me like a caller bug if vm is NULL. The caller must provide the struct videomode, yes. Wouldn't the kernel hang itself with a NULL pointer exception, if I just work with it ? The kernel would oops, clearly showing the caller that a non-null vm is needed :-) Okay. No error checking it is then. + st = display_timings_get(disp, index); + You can remove the blank line. + if (!st) { + pr_err(%s: no signal timings found\n, __func__); + return -EINVAL; + } + + vm-pixelclock = signal_timing_get_value(st-pixelclock, 0); + vm-hactive = signal_timing_get_value(st-hactive, 0); + vm-hfront_porch = signal_timing_get_value(st-hfront_porch, 0); + vm-hback_porch = signal_timing_get_value(st-hback_porch, 0); + vm-hsync_len = signal_timing_get_value(st-hsync_len, 0); + + vm-vactive = signal_timing_get_value(st-vactive, 0); + vm-vfront_porch = signal_timing_get_value(st-vfront_porch, 0); + vm-vback_porch = signal_timing_get_value(st-vback_porch, 0); + vm-vsync_len = signal_timing_get_value(st-vsync_len, 0); + + vm-vah = st-vsync_pol_active_high; + vm-hah = st-hsync_pol_active_high; + vm-interlaced = st-interlaced; + vm-doublescan = st-doublescan; + + return 0; +} + +int of_get_videomode(struct device_node *np, struct videomode *vm, int index) I wonder how to avoid abuse of this functions. It's a useful helper for drivers that need to get a video mode once only, but would result in lower performances if a driver calls it for every mode. Drivers must call of_get_display_timing_list instead in that case and case the display timings. I'm wondering whether we should really expose of_get_videomode. The intent was to let the driver decide. That way all the other overhead may be skipped. My point is that driver writers might just call of_get_videomode() in a loop, not knowing that it's expensive. I want to avoid that. We need to at least add kerneldoc to the function stating that this shouldn't be done. You're right. That should be made clear in the code. +{ + struct display_timings *disp; + int ret = 0; No need to assign ret to 0 here. Ah, yes. Unneeded in this case. + + disp = of_get_display_timing_list(np); + You can remove the blank line. + if (!disp) { + pr_err(%s: no timings specified\n, __func__); + return -EINVAL; + } + + if (index == OF_DEFAULT_TIMING) + index = disp-default_timing; + + ret = videomode_from_timing(disp, vm, index); + No need for a blank line. + if (ret) + return ret; + + display_timings_release(disp); + + if (!vm) { + pr_err(%s: could not get videomode %d\n, __func__, index); + return -EINVAL; + } This can't happen. If vm is NULL the videomode_from_timing call above will return -EINVAL, and this function will then return immediately without reaching this code block. Okay. + + return 0; +} +EXPORT_SYMBOL_GPL(of_get_videomode); -- Regards, Laurent Pinchart Regards, Steffen -- Pengutronix e.K. | |
[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM
https://bugzilla.kernel.org/show_bug.cgi?id=47481 Anisse Astier ani...@astier.eu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #9 from Anisse Astier ani...@astier.eu 2012-10-09 07:53:11 --- I was able to reproduce this bug on an AMD E2-1800 with kernel 3.6. I can confirm that backporting those two patches fixes the problem: 4a15903 drm/radeon/dce4+: don't use radeon_crtc for vblank callback 62444b7 drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2) It would be great if they could be imported to stable, if they are not demmed too invasive. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] drm/i915: use drm_send_vblank_event() helper
On Mon, Oct 08, 2012 at 02:50:40PM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Signed-off-by: Rob Clark r...@ti.com Maybe note in the commit message that after this change pageflip events will also fire the vblank_event_delivered tracepoint. Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 15 ++- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f5bcf6f..4716c83 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6158,8 +6158,6 @@ static void do_intel_finish_page_flip(struct drm_device *dev, struct intel_crtc *intel_crtc = to_intel_crtc(crtc); struct intel_unpin_work *work; struct drm_i915_gem_object *obj; - struct drm_pending_vblank_event *e; - struct timeval tvbl; unsigned long flags; /* Ignore early vblank irqs */ @@ -6175,17 +6173,8 @@ static void do_intel_finish_page_flip(struct drm_device *dev, intel_crtc-unpin_work = NULL; - if (work-event) { - e = work-event; - e-event.sequence = drm_vblank_count_and_time(dev, intel_crtc-pipe, tvbl); - - e-event.tv_sec = tvbl.tv_sec; - e-event.tv_usec = tvbl.tv_usec; - - list_add_tail(e-base.link, - e-base.file_priv-event_list); - wake_up_interruptible(e-base.file_priv-event_wait); - } + if (work-event) + drm_send_vblank_event(dev, intel_crtc-pipe, work-event); drm_vblank_put(dev, intel_crtc-pipe); -- 1.7.9.5 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/cayman: set VM max pfn at MC init
On 08.10.2012 18:25, alexdeuc...@gmail.com wrote: From: Alex Deucher alexander.deuc...@amd.com No need to emit them at VM flush as we no longer use variable sized page tables now that we support 2 level page tables. This matches the behavior of SI (which does not support variable sized page tables). Signed-off-by: Alex Deucher alexander.deuc...@amd.com Yeah, wanted to do so also, but have somehow forgotten it. Reviewed-by: Christian König christian.koe...@amd.com --- drivers/gpu/drm/radeon/ni.c |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index cfb9276..cc0701a 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -776,7 +776,7 @@ static int cayman_pcie_gart_enable(struct radeon_device *rdev) */ for (i = 1; i 8; i++) { WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (i 2), 0); - WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i 2), 0); + WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i 2), rdev-vm_manager.max_pfn); WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (i 2), rdev-gart.table_addr 12); } @@ -1576,12 +1576,6 @@ void cayman_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm) if (vm == NULL) return; - radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (vm-id 2), 0)); - radeon_ring_write(ring, 0); - - radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (vm-id 2), 0)); - radeon_ring_write(ring, rdev-vm_manager.max_pfn); - radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm-id 2), 0)); radeon_ring_write(ring, vm-pd_gpu_addr 12); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/11] drm/omap: page-flip fixes
On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Userspace might not request a vblank event. So it is not an error for 'event' to be NULL, and we shouldn't use it to determine if there is a pending flip already. Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_crtc.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/omapdrm/omap_crtc.c b/drivers/staging/omapdrm/omap_crtc.c index 74e019a..317b854 100644 --- a/drivers/staging/omapdrm/omap_crtc.c +++ b/drivers/staging/omapdrm/omap_crtc.c @@ -119,7 +119,6 @@ static void vblank_cb(void *arg) struct omap_crtc *omap_crtc = to_omap_crtc(crtc); unsigned long flags; - WARN_ON(!event); spin_lock_irqsave(dev-event_lock, flags); /* wakeup userspace */ @@ -127,6 +126,7 @@ static void vblank_cb(void *arg) drm_send_vblank_event(dev, -1, omap_crtc-event); omap_crtc-event = NULL; + omap_crtc-old_fb = NULL; Is old_fb used anywhere? If not we could just remove it. Otherwise nice work! On the series: Reviewed-by: Imre Deak imre.d...@intel.com spin_unlock_irqrestore(dev-event_lock, flags); } @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg) struct drm_framebuffer *old_fb = omap_crtc-old_fb; struct drm_gem_object *bo; - omap_crtc-old_fb = NULL; - omap_crtc_mode_set_base(crtc, crtc-x, crtc-y, old_fb); /* really we'd like to setup the callback atomically w/ setting the @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc, DBG(%d - %d, crtc-fb ? crtc-fb-base.id : -1, fb-base.id); - if (omap_crtc-event) { + if (omap_crtc-old_fb) { dev_err(dev-dev, already a pending flip\n); return -EINVAL; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/11] drm/omap: page-flip fixes
On Tue, 2012-10-09 at 12:35 +0300, Imre Deak wrote: On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote: From: Rob Clark r...@ti.com Userspace might not request a vblank event. So it is not an error for 'event' to be NULL, and we shouldn't use it to determine if there is a pending flip already. Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_crtc.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/omapdrm/omap_crtc.c b/drivers/staging/omapdrm/omap_crtc.c index 74e019a..317b854 100644 --- a/drivers/staging/omapdrm/omap_crtc.c +++ b/drivers/staging/omapdrm/omap_crtc.c @@ -119,7 +119,6 @@ static void vblank_cb(void *arg) struct omap_crtc *omap_crtc = to_omap_crtc(crtc); unsigned long flags; - WARN_ON(!event); spin_lock_irqsave(dev-event_lock, flags); /* wakeup userspace */ @@ -127,6 +126,7 @@ static void vblank_cb(void *arg) drm_send_vblank_event(dev, -1, omap_crtc-event); omap_crtc-event = NULL; + omap_crtc-old_fb = NULL; Is old_fb used anywhere? If not we could just remove it. Otherwise nice work! On the series: Reviewed-by: Imre Deak imre.d...@intel.com spin_unlock_irqrestore(dev-event_lock, flags); } @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg) struct drm_framebuffer *old_fb = omap_crtc-old_fb; struct drm_gem_object *bo; - omap_crtc-old_fb = NULL; - omap_crtc_mode_set_base(crtc, crtc-x, crtc-y, old_fb); /* really we'd like to setup the callback atomically w/ setting the @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc, DBG(%d - %d, crtc-fb ? crtc-fb-base.id : -1, fb-base.id); - if (omap_crtc-event) { + if (omap_crtc-old_fb) { Ah, just noticed this adds the use for it :) So ignore my comment above. --Imre dev_err(dev-dev, already a pending flip\n); return -EINVAL; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/4] time: export getnstime_raw_and_real for DRM
On Fri, 2012-10-05 at 12:14 -0400, Kristian Høgsberg wrote: On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak imre.d...@intel.com wrote: Needed by the upcoming DRM raw monotonic timestamp support. I just had a quick look at driver/input/evdev.c, since evdev devices did a similar change recently to allow evdev timestamp from the monotonic clock. They're using a different time API: time_mono = ktime_get(); time_real = ktime_sub(time_mono, ktime_get_monotonic_offset()); and event-time = ktime_to_timeval(client-clkid == CLOCK_MONOTONIC ? mono : real); I'm not really up-to-date on kernel time APIs, but I wonder if that may be better? At least, I suspect we wouldn't need changes outside drm if we use this API. Thanks, I will use this instead of getnstime_raw_and_real. The reason is as discussed on #intel-gfx that this provides a monotonic vs. raw monotonic time and that as you say it won't require a change in the time keeping code. --Imre Kristian Signed-off-by: Imre Deak imre.d...@intel.com --- kernel/time/timekeeping.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index d3b91e7..073d262 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts) } EXPORT_SYMBOL_GPL(ktime_get_ts); -#ifdef CONFIG_NTP_PPS +#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || defined(CONFIG_DRM_MODULE) /** * getnstime_raw_and_real - get day and raw monotonic time in timespec format -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] Documentation: kernel-parameters.txt Add drm_kms_helper.poll
From: Mika Kuoppala mika.kuopp...@intel.com Possibility to disable polling to find connected displays was introduced by commit [1]: commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Aug 20 09:13:36 2010 +0100 drm/kms: Add a module parameter to disable polling Add description for this parameter to kernel-parameters.txt [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9 Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com --- Documentation/kernel-parameters.txt | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f777fa9..0f0f071 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -741,6 +741,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted. if its name and a colon are prepended to the EDID name. + drm_kms_helper.poll= + Polling for connected display devices on older systems + without Hot Plug Detect (HPD) support, can be quite + expensive. Poll will happen periodically and can in + worst cases take several hundred milliseconds, + depending on the hardware. This will cause visible + stalls, for example in video playback. These stalls + might happen even when your video is on HDP output + but you have other non HDP outputs in your hw + configuration. If you experience stalls in display + output occurring every 10 seconds, disabling polling + might help. With polling disabled you need to manually + use xrandr to trigger detection. + Format: bool (1/Y/y=enable, 0/N/n=disable) + default: enabled + dscc4.setup=[NET] dyndbg[=val] [KNL,DYNAMIC_DEBUG] -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix kdoc comment for drm_crtc_convert_umode
From: Mika Kuoppala mika.kuopp...@intel.com Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com --- drivers/gpu/drm/drm_crtc.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index ef1b221..bb4c686 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1148,9 +1148,9 @@ static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out, } /** - * drm_crtc_convert_to_umode - convert a modeinfo into a drm_display_mode - * @out: drm_display_mode to return to the user - * @in: drm_mode_modeinfo to use + * drm_crtc_convert_umode - convert a modeinfo into a drm_display_mode + * @out: drm_display_mode to return to the caller + * @in: drm_mode_modeinfo from user * * LOCKING: * None. -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Add missing break in the command line mode parsing code
From: Damien Lespiau damien.lesp...@intel.com As we parse the string given on the command line one char at a time, it seems that we do want a break at every case. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/drm_modes.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 28637c1..50bd5c1 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1054,6 +1054,7 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, was_digit = false; } else goto done; + break; case '0' ... '9': was_digit = true; break; -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2
We want to use VMs without the IB pool in the future. v2: also remove it from radeon_vm_finish. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon.h |2 +- drivers/gpu/drm/radeon/radeon_gart.c | 34 +++--- drivers/gpu/drm/radeon/radeon_kms.c | 22 +- 3 files changed, 25 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index bc6b56b..54cf9b5 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1848,7 +1848,7 @@ extern void radeon_ttm_set_active_vram_size(struct radeon_device *rdev, u64 size */ int radeon_vm_manager_init(struct radeon_device *rdev); void radeon_vm_manager_fini(struct radeon_device *rdev); -int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm); +void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm); void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm); int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm); struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev, diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index b36b615..80f0331 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -602,7 +602,6 @@ int radeon_vm_evict(struct radeon_device *rdev, struct radeon_vm *vm) * @vm: vm to bind * * Allocate a page table for the requested vm (cayman+). - * Also starts to populate the page table. * Returns 0 for success, error for failure. * * Global and local mutex must be locked! @@ -655,8 +654,7 @@ retry: } list_add_tail(vm-list, rdev-vm_manager.lru_vm); - return radeon_vm_bo_update_pte(rdev, vm, rdev-ring_tmp_bo.bo, - rdev-ring_tmp_bo.bo-tbo.mem); + return 0; } /** @@ -1241,30 +1239,15 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev, * @rdev: radeon_device pointer * @vm: requested vm * - * Init @vm (cayman+). - * Map the IB pool and any other shared objects into the VM - * by default as it's used by all VMs. - * Returns 0 for success, error for failure. + * Init @vm fields (cayman+). */ -int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm) +void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm) { - struct radeon_bo_va *bo_va; - int r; - vm-id = 0; vm-fence = NULL; mutex_init(vm-mutex); INIT_LIST_HEAD(vm-list); INIT_LIST_HEAD(vm-va); - - /* map the ib pool buffer at 0 in virtual address space, set -* read only -*/ - bo_va = radeon_vm_bo_add(rdev, vm, rdev-ring_tmp_bo.bo); - r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET, - RADEON_VM_PAGE_READABLE | - RADEON_VM_PAGE_SNOOPED); - return r; } /** @@ -1286,17 +1269,6 @@ void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm) radeon_vm_free_pt(rdev, vm); mutex_unlock(rdev-vm_manager.lock); - /* remove all bo at this point non are busy any more because unbind -* waited for the last vm fence to signal -*/ - r = radeon_bo_reserve(rdev-ring_tmp_bo.bo, false); - if (!r) { - bo_va = radeon_vm_bo_find(vm, rdev-ring_tmp_bo.bo); - list_del_init(bo_va-bo_list); - list_del_init(bo_va-vm_list); - radeon_bo_unreserve(rdev-ring_tmp_bo.bo); - kfree(bo_va); - } if (!list_empty(vm-va)) { dev_err(rdev-dev, still active bo inside vm\n); } diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index cb8e94d..c97d49b 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -420,6 +420,7 @@ int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv) /* new gpu have virtual address space support */ if (rdev-family = CHIP_CAYMAN) { struct radeon_fpriv *fpriv; + struct radeon_bo_va *bo_va; int r; fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL); @@ -427,7 +428,15 @@ int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv) return -ENOMEM; } - r = radeon_vm_init(rdev, fpriv-vm); + radeon_vm_init(rdev, fpriv-vm); + + /* map the ib pool buffer read only into +* virtual address space */ + bo_va = radeon_vm_bo_add(rdev, fpriv-vm, +rdev-ring_tmp_bo.bo); + r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET, + RADEON_VM_PAGE_READABLE | +
[PATCH 1/3] drm/radeon: allocate page tables on demand v4
Based on Dmitries work, but splitting the code into page directory and page table handling makes it far more readable and (hopefully) more reliable. Allocations of page tables are made from the SA on demand, that should still work fine since all page tables are of the same size. Also using the fact that allocations from the SA are mostly continuously (except for end of buffer wraps and under very high memory pressure) to group updates send to the chipset specific code into larger chunks. v3: mostly a rewrite of Dmitries previous patch. v4: fix some typos and coding style Signed-off-by: Dmitry Cherkasov dmitrii.cherka...@amd.com Signed-off-by: Christian König deathsim...@vodafone.de Tested-by: Michel Dänzer michel.daen...@amd.com Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/ni.c |2 +- drivers/gpu/drm/radeon/radeon.h | 11 +- drivers/gpu/drm/radeon/radeon_gart.c | 322 ++ 3 files changed, 262 insertions(+), 73 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index 9a46f7d..48e2337 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -1576,7 +1576,7 @@ void cayman_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm) radeon_ring_write(ring, 0); radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (vm-id 2), 0)); - radeon_ring_write(ring, vm-last_pfn); + radeon_ring_write(ring, rdev-vm_manager.max_pfn); radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm-id 2), 0)); radeon_ring_write(ring, vm-pd_gpu_addr 12); diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index b04c064..bc6b56b 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -663,9 +663,14 @@ struct radeon_vm { struct list_headlist; struct list_headva; unsignedid; - unsignedlast_pfn; - u64 pd_gpu_addr; - struct radeon_sa_bo *sa_bo; + + /* contains the page directory */ + struct radeon_sa_bo *page_directory; + uint64_tpd_gpu_addr; + + /* array of page tables, one for each page directory entry */ + struct radeon_sa_bo **page_tables; + struct mutexmutex; /* last fence for cs using this vm */ struct radeon_fence *fence; diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index 753b7ca..b36b615 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -423,6 +423,18 @@ void radeon_gart_fini(struct radeon_device *rdev) */ /** + * radeon_vm_num_pde - return the number of page directory entries + * + * @rdev: radeon_device pointer + * + * Calculate the number of page directory entries (cayman+). + */ +static unsigned radeon_vm_num_pdes(struct radeon_device *rdev) +{ + return rdev-vm_manager.max_pfn RADEON_VM_BLOCK_SIZE; +} + +/** * radeon_vm_directory_size - returns the size of the page directory in bytes * * @rdev: radeon_device pointer @@ -431,7 +443,7 @@ void radeon_gart_fini(struct radeon_device *rdev) */ static unsigned radeon_vm_directory_size(struct radeon_device *rdev) { - return (rdev-vm_manager.max_pfn RADEON_VM_BLOCK_SIZE) * 8; + return RADEON_GPU_PAGE_ALIGN(radeon_vm_num_pdes(rdev) * 8); } /** @@ -451,11 +463,11 @@ int radeon_vm_manager_init(struct radeon_device *rdev) if (!rdev-vm_manager.enabled) { /* allocate enough for 2 full VM pts */ - size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev)); - size += RADEON_GPU_PAGE_ALIGN(rdev-vm_manager.max_pfn * 8); + size = radeon_vm_directory_size(rdev); + size += rdev-vm_manager.max_pfn * 8; size *= 2; r = radeon_sa_bo_manager_init(rdev, rdev-vm_manager.sa_manager, - size, + RADEON_GPU_PAGE_ALIGN(size), RADEON_GEM_DOMAIN_VRAM); if (r) { dev_err(rdev-dev, failed to allocate vm bo (%dKB)\n, @@ -476,7 +488,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev) /* restore page table */ list_for_each_entry(vm, rdev-vm_manager.lru_vm, list) { - if (vm-sa_bo == NULL) + if (vm-page_directory == NULL) continue; list_for_each_entry(bo_va, vm-va, vm_list) { @@ -500,16 +512,25 @@ static void radeon_vm_free_pt(struct radeon_device *rdev, struct radeon_vm *vm) { struct
[PATCH 3/3] drm/radeon: separate pt alloc from lru add
Make it possible to allocate a persistent page table. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/radeon.h |1 + drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_gart.c | 20 3 files changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 54cf9b5..8c42d54 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1851,6 +1851,7 @@ void radeon_vm_manager_fini(struct radeon_device *rdev); void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm); void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm); int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm); +void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm); struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev, struct radeon_vm *vm, int ring); void radeon_vm_fence(struct radeon_device *rdev, diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index d59eb59..023c67d 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -478,6 +478,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev, } out: + radeon_vm_add_to_lru(rdev, vm); mutex_unlock(vm-mutex); mutex_unlock(rdev-vm_manager.lock); return r; diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index 80f0331..08e0ddc 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -617,9 +617,6 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm) } if (vm-page_directory != NULL) { - /* update lru */ - list_del_init(vm-list); - list_add_tail(vm-list, rdev-vm_manager.lru_vm); return 0; } @@ -653,11 +650,26 @@ retry: return -ENOMEM; } - list_add_tail(vm-list, rdev-vm_manager.lru_vm); return 0; } /** + * radeon_vm_add_to_lru - add VMs page table to LRU list + * + * @rdev: radeon_device pointer + * @vm: vm to add to LRU + * + * Add the allocated page table to the LRU list (cayman+). + * + * Global mutex must be locked! + */ +void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm) +{ + list_del_init(vm-list); + list_add_tail(vm-list, rdev-vm_manager.lru_vm); +} + +/** * radeon_vm_grab_id - allocate the next free VMID * * @rdev: radeon_device pointer -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2
On Die, 2012-10-09 at 13:31 +0200, Christian König wrote: We want to use VMs without the IB pool in the future. v2: also remove it from radeon_vm_finish. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/3] drm: Add user-defined EDID quirks capability
On Fri, 28 Sep 2012, Ian Pilcher arequip...@gmail.com wrote: Add the ability for users to define their own EDID quirks via a module parameter or sysfs attribute. Hi Ian - IMHO this patch should be chopped up to smaller pieces. For example, change the edid_quirk_list format first (if you must), then add module parameter support, then add sysfs support, in separate patches. It'll be easier to review. Please see some other comments inline. BR, Jani. Signed-off-by: Ian Pilcher arequip...@gmail.com --- Documentation/EDID/edid_quirks.txt | 126 ++ drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 500 - drivers/gpu/drm/drm_stub.c | 6 + drivers/gpu/drm/drm_sysfs.c| 19 ++ include/drm/drmP.h | 10 + include/drm/drm_edid.h | 13 +- 7 files changed, 615 insertions(+), 61 deletions(-) create mode 100644 Documentation/EDID/edid_quirks.txt diff --git a/Documentation/EDID/edid_quirks.txt b/Documentation/EDID/edid_quirks.txt new file mode 100644 index 000..0c9c746 --- /dev/null +++ b/Documentation/EDID/edid_quirks.txt @@ -0,0 +1,126 @@ + EDID Quirks + = + Ian Pilcher arequip...@gmail.com +August 11, 2012 + + +EDID blocks out in the wild have a variety of bugs +-- from drivers/gpu/drm/drm_edid.c + + +Overview + + +EDID quirks provide a mechanism for working around display hardware with buggy +EDID data. + +An individual EDID quirk maps a display type (identified by its EDID +manufacturer ID and product code[1]) to a set of quirk flags. The kernel +includes a variety of built-in quirks. (They are stored in the edid_quirk_list +array in drivers/gpu/drm/drm_edid.c.) + +An example of a built-in EDID quirk is: + +ACR:0xad46:0x0001 + +The first field is the manufacturer ID (Acer, Inc.), the second field is the +manufacturer's product code, and the third field contains the quirk flags for +that display type. + +The quirk flags are defined in drivers/gpu/drm/drm_edid.c. Each flag has a +symbolic name beginning with EDID_QUIRK_, along with a numerical value. Each +flag should also have an associated comment which provides an idea of its +effect. Note that the values in the source file are expressed as bit shifts[2]: + +* 1 0: 0x0001 +* 1 1: 0x0002 +* 1 2: 0x0004 +* etc. + + +sysfs interface +=== + +The current EDID quirk list can be read from /sys/class/drm/edid_quirks: + +# cat /sys/class/drm/edid_quirks + ACR:0xad46:0x0001 + API:0x7602:0x0001 + ACR:0x0977:0x0020 +0x9e6a:0x077e:0x0080 +... + +(Nonconformant manufacturer IDs are displayed as hexadecimal values.) + +The number of total slots in the list can be read from +/sys/class/drm/edid_quirks_size. This total includes both occupied slots (i.e. +the current list) and any slots available for additional quirks. The number of +available slots can be calculated by subtracting the number of quirks in the +current list from the total number of slots. + +If a slot is available, an additional quirk can be added to the list by writing +it to /sys/class/drm/edid_quirks: + +# echo FOO:0x:0x100 /sys/class/drm/edid_quirks + +Manufacturer IDs can also be specified numerically. (This is the only way to +specify a nonconformant ID.) This command is equivalent to the previous one: + +# echo 0x19ef:0x:0x100 /sys/class/drm/edid_quirks + +Numeric values can also be specified in decimal or octal formats; a number that +begins with a 0 is assumed to be octal: + +# echo FOO:65535:0400 /sys/class/drm/edid_quirks + +An existing quirk can be replaced by writing a new set of flags: + +# echo FOO:0x:0x200 /sys/class/drm/edid_quirks + +A quirk can be deleted from the list by writing an empty flag set (0). This +makes the slot occupied by that quirk available. + +# echo FOO:0x:0 /sys/class/drm/edid_quirks + +Writing an at symbol (@) clears the entire quirk list: + +# echo @ /sys/class/drm/edid_quirks + +Multiple changes to the list can be specified in a comma (or newline) separated +list. For example, the following command clears all of the existing quirks in +the list and adds 3 new quirks: + +# echo @,FOO:0x:0x100,BAR:0x:0x001,BAZ:0x:0x002 \ +/sys/class/drm/edid_quirks + +Note however, that any error (an incorrectly formatted quirk or an attempt to +add a quirk when no slot is available) will abort processing of any further +changes, potentially making it difficult to determine exactly which change +caused the error and what changes were made. For this reason, making changes +one at a time is recommended, particularly
Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled
On Tue, Oct 9, 2012 at 2:26 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeuc...@gmail.com: From: Alex Deucher alexander.deuc...@amd.com If so, skip enabling it. Does that fix any error/problem or is it just for speed reasons? It doesn't fix anything that I know of. Just speed. Alex Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/evergreen.c |8 ++-- drivers/gpu/drm/radeon/r600.c |7 ++- 2 files changed, 12 insertions(+), 3 deletions(-) […] Thanks, Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled
On Tue, Oct 9, 2012 at 3:05 AM, Rafał Miłecki zaj...@gmail.com wrote: 2012/10/8 alexdeuc...@gmail.com: + if (speed_cntl LC_CURRENT_DATA_RATE) { + DRM_INFO(PCIE gen 2 link speeds already enabled\n); + return; + } else + DRM_INFO(enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0\n); + See documentation/CodingStyle: This does not apply if only one branch of a conditional statement is a single statement; in the latter case use braces in both branches: Your else should use braces :) I'll fix that up. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: check if pcie gen 2 is already enabled (v2)
From: Alex Deucher alexander.deuc...@amd.com If so, skip enabling it to save time. v2: coding style fixes Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/evergreen.c |7 ++- drivers/gpu/drm/radeon/r600.c |6 ++ 2 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index a1f49c5..14313ad 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -3431,9 +3431,14 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev) if (!(mask DRM_PCIE_SPEED_50)) return; + speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL); + if (speed_cntl LC_CURRENT_DATA_RATE) { + DRM_INFO(PCIE gen 2 link speeds already enabled\n); + return; + } + DRM_INFO(enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0\n); - speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL); if ((speed_cntl LC_OTHER_SIDE_EVER_SENT_GEN2) || (speed_cntl LC_OTHER_SIDE_SUPPORTS_GEN2)) { diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index 70c800f..cda280d 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -3703,6 +3703,12 @@ static void r600_pcie_gen2_enable(struct radeon_device *rdev) if (!(mask DRM_PCIE_SPEED_50)) return; + speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL); + if (speed_cntl LC_CURRENT_DATA_RATE) { + DRM_INFO(PCIE gen 2 link speeds already enabled\n); + return; + } + DRM_INFO(enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0\n); /* 55 nm r6xx asics */ -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55809] New: omap_drm: fix locking bug on error path
https://bugs.freedesktop.org/show_bug.cgi?id=55809 Priority: medium Bug ID: 55809 Assignee: dri-devel@lists.freedesktop.org Summary: omap_drm: fix locking bug on error path Severity: normal Classification: Unclassified OS: Linux (All) Reporter: vinc...@collabora.co.uk Hardware: ARM Status: NEW Version: XOrg CVS Component: libdrm Product: DRI Created attachment 68338 -- https://bugs.freedesktop.org/attachment.cgi?id=68338action=edit Fix for locking bug on error paths omap_drm.c has a couple places where a lock is not released on an error path, but should be. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55809] omap_drm: fix locking bug on error path
https://bugs.freedesktop.org/show_bug.cgi?id=55809 Rob Clark r...@ti.com changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |r...@ti.com |.org| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/3] Enhanced EDID quirk functionality
On 10/8/12 7:22 PM, Ian Pilcher wrote: On 09/28/2012 02:03 AM, Ian Pilcher wrote: As promised, this patch series does only the following: * Add user-defined EDID quirks -- via sysfs or a module parameter * Add an EDID quirk flag to disable all HDMI functionality (InfoFrames) * Add a quirk to disable HDMI InfoFrames for the LG L246WP ACK? NACK? I'm on crack? (I'm starting to think that this is some sort of hazing ritual.) Sorry, I'm just not paying close attention to EDID stuff at the moment. The series as is is clearly better than what we've got. I still think there's something fundamentally amiss with a display that doesn't want to accept InfoFrames, but without having it in hand to mess with - and without wanting to play telephone to figure it out - I'm fine with this. Reviewed-by: Adam Jackson a...@redhat.com - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: avoid passing null pointer to memset
When cmd isn't IOC_IN | IOC_OUT a null kdata goes to memset, which dereferences it. Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com --- drivers/gpu/drm/drm_drv.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 1490e76..5945920 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -452,8 +452,16 @@ long drm_ioctl(struct file *filp, retcode = -EFAULT; goto err_i1; } - } else + } else { + if (!kdata) { + kdata = kmalloc(usize, GFP_KERNEL); + if (!kdata) { + retcode = -ENOMEM; + goto err_i1; + } + } memset(kdata, 0, usize); + } if (ioctl-flags DRM_UNLOCKED) retcode = func(dev, kdata, file_priv); -- 1.7.11.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: fix allocation size for page addresses array
Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_gem.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index c828743..4c1472c 100644 --- a/drivers/staging/omapdrm/omap_gem.c +++ b/drivers/staging/omapdrm/omap_gem.c @@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) * DSS, GPU, etc. are not cache coherent: */ if (omap_obj-flags (OMAP_BO_WC|OMAP_BO_UNCACHED)) { - addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; @@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) 0, PAGE_SIZE, DMA_BIDIRECTIONAL); } } else { - addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid passing null pointer to memset
On Tue, 9 Oct 2012 14:50:46 -0300, Rodrigo Vivi rodrigo.v...@gmail.com wrote: When cmd isn't IOC_IN | IOC_OUT a null kdata goes to memset, which dereferences it. usize should be 0 in that case, since the ioctl is neither copying data in or out, for example I915_GEM_THROTTLE. To be on the safe side: if (IOC_IN | IOC_OUT) { /* blah */ } else usize = 0; -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: fix allocation size for page addresses array
Signed-off-by: Rob Clark r...@ti.com Signed-off-by: Vincent Penquerc'h vincent.penque...@collabora.co.uk --- drivers/staging/omapdrm/omap_gem.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index c828743..4c1472c 100644 --- a/drivers/staging/omapdrm/omap_gem.c +++ b/drivers/staging/omapdrm/omap_gem.c @@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) * DSS, GPU, etc. are not cache coherent: */ if (omap_obj-flags (OMAP_BO_WC|OMAP_BO_UNCACHED)) { - addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; @@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj) 0, PAGE_SIZE, DMA_BIDIRECTIONAL); } } else { - addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL); + addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL); if (!addrs) { ret = -ENOMEM; goto free_pages; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: avoid passing null pointer to memset
When cmd isn't IOC_IN | IOC_OUT a null kdata goes to memset, which dereferences it. v2: simpler version just using usize = 0 instead of allocating useless memory Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com --- drivers/gpu/drm/drm_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 1490e76..f72dce5 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -444,7 +444,8 @@ long drm_ioctl(struct file *filp, } if (asize usize) memset(kdata + usize, 0, asize - usize); - } + } else + usize = 0; if (cmd IOC_IN) { if (copy_from_user(kdata, (void __user *)arg, -- 1.7.11.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55819] Mouse cursor corruption when moving between monitors
https://bugs.freedesktop.org/show_bug.cgi?id=55819 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon --- Comment #5 from Alex Deucher ag...@yahoo.com --- What kernel are you using? Make sure it has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f60ec4c7df043df81e62891ac45383d012afe0da -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 pitam...@free.fr changed: What|Removed |Added Attachment #50399|0 |1 is obsolete|| --- Comment #8 from pitam...@free.fr --- Created attachment 68363 -- https://bugs.freedesktop.org/attachment.cgi?id=68363action=edit my glxinfo output with mesa 8.0.4 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 pitam...@free.fr changed: What|Removed |Added Version|7.10|8.0 --- Comment #9 from pitam...@free.fr --- Hi, I updated my Debian Sid distro to mesa 8.0.4 unfortunately, Enemy Territory continue to have - texture blinking - error in drawing landscapes (I can see thru the walls) - many objects (all the screen when enterring limbo menu) appearing only a fraction of second then disappearing Tell me if I can do any testing or provide some more log to help diagnose the pb. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/11] drm/omap: use drm_send_vblank_event() helper
On 08.10.12 21:50, Rob Clark wrote: From: Rob Clark r...@ti.com Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_crtc.c | 31 ++- 1 file changed, 6 insertions(+), 25 deletions(-) diff --git a/drivers/staging/omapdrm/omap_crtc.c b/drivers/staging/omapdrm/omap_crtc.c index 732f2ad..74e019a 100644 --- a/drivers/staging/omapdrm/omap_crtc.c +++ b/drivers/staging/omapdrm/omap_crtc.c @@ -114,40 +114,21 @@ static void omap_crtc_load_lut(struct drm_crtc *crtc) static void vblank_cb(void *arg) { - static uint32_t sequence = 0; struct drm_crtc *crtc = arg; struct drm_device *dev = crtc-dev; struct omap_crtc *omap_crtc = to_omap_crtc(crtc); - struct drm_pending_vblank_event *event = omap_crtc-event; unsigned long flags; - struct timeval now; WARN_ON(!event); + spin_lock_irqsave(dev-event_lock, flags); + + /* wakeup userspace */ + if (omap_crtc-event) + drm_send_vblank_event(dev, -1, omap_crtc-event); omap_crtc-event = NULL; - /* wakeup userspace */ - if (event) { - do_gettimeofday(now); - - spin_lock_irqsave(dev-event_lock, flags); - /* TODO: we can't yet use the vblank time accounting, -* because omapdss lower layer is the one that knows -* the irq # and registers the handler, which more or -* less defeats how drm_irq works.. for now just fake -* the sequence number and use gettimeofday.. -* - event-event.sequence = drm_vblank_count_and_time( - dev, omap_crtc-id, now); -*/ I think this TOO comment should be retained as a reminder that there is work to do. - event-event.sequence = sequence++; This is problematic. You lose the pseudo vblank counter implemented here, which is a violation of the spec, and from my own experience it causes extra pain and the need for awful workarounds in userspace clients. Nouveau-kms has the same problem for no good reason. But then, on second thought, the way it is implemented here in the original is even more wrong, returning zero might be better. -mario - event-event.tv_sec = now.tv_sec; - event-event.tv_usec = now.tv_usec; - list_add_tail(event-base.link, - event-base.file_priv-event_list); - wake_up_interruptible(event-base.file_priv-event_wait); - spin_unlock_irqrestore(dev-event_lock, flags); - } + spin_unlock_irqrestore(dev-event_lock, flags); } static void page_flip_cb(void *arg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel