[PATCH] drm/radeon: Disable writeback by default on ppc
On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote: > On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote: > > On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote: > > > >> Weird. I wonder if there is an issue with cache snoops on PPC. We > >> currently use the gart in cached mode (GPU snoops CPU cache) with > >> cached pages. I wonder if we need to use uncached pages on PPC. > > > > There is no such issue and no known bugs with DMA writes on those > > PCIe host bridges (and they do get hammered pretty bad here). > > > > This needs further investigation by the lab/hw guys to find out what's > > actually happening on the bus and the host bridge. > > > > Thadeu, Kleber: Jerome suggested writing a test case in userspace that > > continuously writes to a spare scratch register (thus triggering the > > corresponding writeback DMA) and checks the memory location to compare > > the writeback value (using a debugfs file for example, or mmap). > > > > I can look into that. Any news ? Ben. > > Thanks, > > Kleber > > > Can you guys do something like that ? Then we need the analyzer on > > and/or the lab guys to look at the fabric trace & PHB trace. > > > > Ben. > > > > > >
[Bug 70391] "atombios stuck executing D1FC" when switching back from tty to X
https://bugs.freedesktop.org/show_bug.cgi?id=70391 Jose P. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose P. --- It's been fixed (I'm using oibaf's PPA + 3.13-rc0. I don't know the patch that fixed it) Closing :) -- 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/20131125/c87caf7b/attachment.html>
[Bug 69365] vgaswitcheroo crashes when passing "OFF" to the "switch" file
https://bugs.freedesktop.org/show_bug.cgi?id=69365 Jose P. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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/20131125/38ae0912/attachment.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 Alexandre Demers changed: What|Removed |Added Summary|GPU lockups with kernel |GPU lockups with kernel |3.11.0 / 3.12-rc1 (with bug |3.11.0 / 3.12-rc1 when |68235's patches applied)|dpm=1 on r600g (Cayman) |when dpm=1 on r600g | |(Cayman)| -- 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/20131125/fb713528/attachment.html>
[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=71859 --- Comment #9 from Alexandre Demers --- May be related to bug 68224 -- 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/20131125/61b36a45/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #29 from Alexandre Demers --- may be related to bug 71859 -- 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/20131125/8f58fcf8/attachment.html>
[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian H?gsberg wrote: > I don't know what else you'd propose? Pass an X visual in the ioctl? > An EGL config? This is our name space, we can add stuff as we need > (as Keith is doing here). include/uapi/drm/drm_fourcc.h is the > canonical source for these values and we should add > DRM_FORMAT_SARGB there to make sure we don't clash. Well that's kinda the problem. If you don't expect the kernel to clash with whatever mesa is using internally then we should add it to the kernel, first. That's kinda what Dave's recent rant has all been about. The other issue was that originally the idea behind fourcc was to have one formate namespace shared between drm, v4l and whomever else cares. If people are happy to drop that idea on the floor I won't shed a single tear. In the end I'll expect that someone will make a funny collision between all the different projects anyway, so meh. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Patch
On Fri, Nov 22, 2013 at 06:36:48PM +0100, Levente Kurusa wrote: > 2013-11-22 17:35, Arthur Schwalbenberg: > > > > From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001 > > From: Arthur Schwalbenberg > > Date: Thu, 21 Nov 2013 19:42:44 -0500 > > Subject: [PATCH] Staging: Fixed compilar warnings and coding style > > issues in i915_debugfs.c > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > This is a patch fixing both a compilar warning: > > ?val? may be used uninitialized in this function > > and various coding style issues which include line length > > warnings and a few errors as defined by 'checkpatch.pl' tool > > > > Signed-off-by: Arthur Schwalbenberg > > Hi, > > When you break 80+ lines into two lines, you should also > indent the newly created line so that it shows that it is a part of something. > I as well don't think it is worth splitting lines that are 84 characters long > into > two lines, that just doesn't make sense. > > Also, your patch seems (atleast to me) a 'bit' whitespace damaged. Also, please don't smash different changes into the same patch. Especially pure whitespace changes _must_ be separate from actual code changes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 71777] R600 stuck while compiling shader for Unigine Heaven 3.0
https://bugs.freedesktop.org/show_bug.cgi?id=71777 Marc Dietrich changed: What|Removed |Added Attachment #89455|0 |1 is obsolete|| --- Comment #2 from Marc Dietrich --- Created attachment 89739 --> https://bugs.freedesktop.org/attachment.cgi?id=89739&action=edit failing shader in Unigine Heaven 3.0 -- 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/20131125/cdb4a116/attachment.html>
[Bug 71983] New: libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 Priority: medium Bug ID: 71983 Assignee: dri-devel at lists.freedesktop.org Summary: libdrm 2.4.49 makes gpu crash (HD7770) Severity: normal Classification: Unclassified OS: All Reporter: arek.rusi at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 89740 --> https://bugs.freedesktop.org/attachment.cgi?id=89740&action=edit kernel log when i run some ogl apps (unigine-*;some 3d games; even google-chrome) I've gzipped log because it has ~ 14MB. main part are bazillion lines like that: <3>[ 414.876442] radeon :01:00.0: GPU fault detected: 146 0x0fe32004 <3>[ 414.876446] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x21FF <3>[ 414.876448] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03020004 <4>[ 414.876450] VM fault (0x04, vmid 1) at page 8703, write from CB (32) <3>[ 414.876455] radeon :01:00.0: GPU fault detected: 146 0x0fc32004 <3>[ 414.876457] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x <3>[ 414.876458] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x <4>[ 414.876460] VM fault (0x00, vmid 0) at page 0, read from unknown (0) Usually my PC doesn't respone but sometimes like for unigine-sanctuary i can see graphics corruption for a while. When i downgrade libdrm everything works like before. -- 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/20131125/d679870b/attachment.html>
[Bug 41375] VDPAU not working on RS880
https://bugs.freedesktop.org/show_bug.cgi?id=41375 Christian K?nig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Christian K?nig --- I just tested in on an RS880 and it works fine. Any objections on closing this bug? -- 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/20131125/fdda147b/attachment.html>
[Bug 41375] VDPAU not working on RS880
https://bugs.freedesktop.org/show_bug.cgi?id=41375 --- Comment #7 from Mike Lothian --- I'll test it when I get home tonight. I take it its software vdpau. Is it only mpeg2 that's implemented? On 25 Nov 2013 12:49, wrote: > Christian K?nig changed bug > 41375<https://bugs.freedesktop.org/show_bug.cgi?id=41375> > What Removed Added Status NEW RESOLVED Resolution --- WORKSFORME > > *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=41375#c6> on > bug 41375 <https://bugs.freedesktop.org/show_bug.cgi?id=41375> from > Christian K?nig * > > I just tested in on an RS880 and it works fine. > > Any objections on closing this bug? > > -- > You are receiving this mail because: > >- You are the assignee for the bug. > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- 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/20131125/6c9455da/attachment.html>
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 Arek Ru?niak changed: What|Removed |Added Attachment #89740|0 |1 is obsolete|| --- Comment #1 from Arek Ru?niak --- Created attachment 89745 --> https://bugs.freedesktop.org/attachment.cgi?id=89745&action=edit kernel log when i run some ogl apps (unigine-*;some 3d games; even google-chrome) my software/hardware: archlinux x86/x86_64 LIBDRM 2.4.49 / 2.4.48 linux 3.13rc1 / 3.12.1 mesa 10.1 git-e6a0eca LLVM 3.5 r195632 glamor - latest from git repo xf86-video-ati - latest form git repo xorg-server 1.14.4 GPU HD7770 GHz Ed. Chipset: "VERDE" (ChipID = 0x683d) I am wild and woolly today, sorry for that. -- 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/20131125/9e103ee9/attachment-0001.html>
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 --- Comment #2 from Maarten Lankhorst --- Can you bisect? -- 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/20131125/da523dd2/attachment.html>
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 Maarten Lankhorst changed: What|Removed |Added Status|NEW |NEEDINFO -- 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/20131125/d6636f9e/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #6 from Christian K?nig --- I can't reproduce the problem. Can you try this with mesa master branch? Thanks in advance. -- 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/20131125/f0bd93e2/attachment.html>
[i915] BUG: Bad page state in process Xorg
oh, hmm.. are you importing buffers from i915? It looks like this part: - if (obj->base.import_attach) { - drm_free_large(obj->pages); - obj->pages = NULL; - return; - } should not have been removed from udl_gem_put_pages().. BR, -R On Mon, Nov 25, 2013 at 8:17 AM, wrote: > Hi, > > It turns out that this seems to be a bug in udl DRM driver. > > I bisected the problem to this patch: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=5dc9e1e87229cb786a5bb58ddd0d60fee6eb4641 > > With kind regards > Thomas > > Am 22.11.2013 17:18 schrieb Daniel Vetter : >> >> On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer wrote: >> >> Am 22.11.2013 um 11:55 schrieb Daniel Vetter : >> >> >> >> On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie wrote: >> Hi, >> >>> >> >>> cc'ing mailing list, >> >>> >> >>> Daniel any ideas? >> >> >> >> Nope, not really :( And no ideas how to triage this further - if it >> >> takes 9 days to hit it eventually we'll have a real hard time. Or does >> >> this happen even after just a short X run? >> > >> > Seems to happen every time while stopping the x server. Also after a short >> > run time. >> > >> > The current fedora 3.11 kernel doesn't show this bug. I'm using fedora 19, >> > with a self compiled kernel. >> > >> > I did turn on config-debug-pagealloc but this didn't show any wrongness. >> >> In that case I think the bisect is the fastest way to insight - atm >> I'm really at loss what could be wrong here. >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 --- Comment #3 from Marek Ol??k --- Could you bisect? -- 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/20131125/c8405ca7/attachment.html>
[PATCH 3.2 74/87] drm: Prevent overwriting from userspace underallocating core ioctl structs
3.2.53-rc1 review patch. If anyone has any objections, please let me know. -- From: Chris Wilson commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream. Apply the protections from commit 1b2f1489633888d4a06028315dc19d65768a1c05 Author: Dave Airlie Date: Sat Aug 14 20:20:34 2010 +1000 drm: block userspace under allocating buffer and having drivers overwrite it (v2) to the core ioctl structs as well, for we found one instance where there is a 32-/64-bit size mismatch and were guilty of writing beyond the end of the user's buffer. Signed-off-by: Chris Wilson Cc: Dave Airlie Reviewed-by: Ville Syrj?l? Cc: dri-devel at lists.freedesktop.org Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings --- drivers/gpu/drm/drm_drv.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -408,9 +408,16 @@ long drm_ioctl(struct file *filp, asize = drv_size; } else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) { + u32 drv_size; + ioctl = &drm_ioctls[nr]; - cmd = ioctl->cmd; + + drv_size = _IOC_SIZE(ioctl->cmd); usize = asize = _IOC_SIZE(cmd); + if (drv_size > asize) + asize = drv_size; + + cmd = ioctl->cmd; } else goto err_i1;
[PATCH 3.2 75/87] drm: Pad drm_mode_get_connector to 64-bit boundary
3.2.53-rc1 review patch. If anyone has any objections, please let me know. -- From: Chris Wilson commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream. Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting the 4 bytes beyond the end of its structure with a 32-bit userspace running on a 64-bit kernel. This is due to the padding gcc inserts as the drm_mode_get_connector struct includes a u64 and its size is not a natural multiple of u64s. 64-bit kernel: sizeof(drm_mode_get_connector)=80, alignof=8 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 32-bit userspace: sizeof(drm_mode_get_connector)=76, alignof=4 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 Fortuituously we can insert explicit padding to the tail of our structures without breaking ABI. Reported-by: Pavel Roskin Signed-off-by: Chris Wilson Cc: Dave Airlie Cc: dri-devel at lists.freedesktop.org Signed-off-by: Dave Airlie [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings --- include/uapi/drm/drm_mode.h | 2 ++ 1 file changed, 2 insertions(+) --- a/include/drm/drm_mode.h +++ b/include/drm/drm_mode.h @@ -184,6 +184,8 @@ struct drm_mode_get_connector { __u32 connection; __u32 mm_width, mm_height; /**< HxW in millimeters */ __u32 subpixel; + + __u32 pad; }; #define DRM_MODE_PROP_PENDING (1<<0)
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 --- Comment #4 from Arek Ru?niak --- yep:) if i good understand word "bisect" here it is: http://cgit.freedesktop.org/mesa/drm/commit/?id=ce8af454259279c14c44bcd32c429640ca5e1691 btw i try turn off tiling but without succes, gpu still crashes. Before this commit it works ok. -- 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/20131125/1491adf0/attachment-0001.html>
[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Mon, Nov 25, 2013 at 09:57:23AM +0100, Daniel Vetter wrote: > On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian H?gsberg wrote: > > I don't know what else you'd propose? Pass an X visual in the ioctl? > > An EGL config? This is our name space, we can add stuff as we need > > (as Keith is doing here). include/uapi/drm/drm_fourcc.h is the > > canonical source for these values and we should add > > DRM_FORMAT_SARGB there to make sure we don't clash. > > Well that's kinda the problem. If you don't expect the kernel to clash > with whatever mesa is using internally then we should add it to the > kernel, first. That's kinda what Dave's recent rant has all been about. > > The other issue was that originally the idea behind fourcc was to have one > formate namespace shared between drm, v4l and whomever else cares. If > people are happy to drop that idea on the floor I won't shed a single > tear. I broke that idea alredy when I cooked up the current drm fourccs. I didn't cross check them with any other fourcc source, so I'm 100% sure most of them don't match anything else. -- Ville Syrj?l? Intel OTC
[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau
https://bugs.freedesktop.org/show_bug.cgi?id=50618 Christian K?nig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Christian K?nig --- Since DPM is available for a while now I think we can close this bug. Any objections? -- 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/20131125/efc193ed/attachment.html>
[PATCH 2/2] drm/radeon: add radeon_vm_bo_update trace point
From: Christian K?nig Also rename the function to better reflect what it is doing. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h | 8 drivers/gpu/drm/radeon/radeon_cs.c| 4 ++-- drivers/gpu/drm/radeon/radeon_gart.c | 14 -- drivers/gpu/drm/radeon/radeon_trace.h | 18 ++ 4 files changed, 32 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index ecf2a39..b1f990d 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -2710,10 +2710,10 @@ void radeon_vm_fence(struct radeon_device *rdev, struct radeon_vm *vm, struct radeon_fence *fence); uint64_t radeon_vm_map_gart(struct radeon_device *rdev, uint64_t addr); -int radeon_vm_bo_update_pte(struct radeon_device *rdev, - struct radeon_vm *vm, - struct radeon_bo *bo, - struct ttm_mem_reg *mem); +int radeon_vm_bo_update(struct radeon_device *rdev, + struct radeon_vm *vm, + struct radeon_bo *bo, + struct ttm_mem_reg *mem); void radeon_vm_bo_invalidate(struct radeon_device *rdev, struct radeon_bo *bo); struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm, diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index f41594b..0b36616 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -360,13 +360,13 @@ static int radeon_bo_vm_update_pte(struct radeon_cs_parser *parser, struct radeon_bo *bo; int r; - r = radeon_vm_bo_update_pte(rdev, vm, rdev->ring_tmp_bo.bo, &rdev->ring_tmp_bo.bo->tbo.mem); + r = radeon_vm_bo_update(rdev, vm, rdev->ring_tmp_bo.bo, &rdev->ring_tmp_bo.bo->tbo.mem); if (r) { return r; } list_for_each_entry(lobj, &parser->validated, tv.head) { bo = lobj->bo; - r = radeon_vm_bo_update_pte(parser->rdev, vm, bo, &bo->tbo.mem); + r = radeon_vm_bo_update(parser->rdev, vm, bo, &bo->tbo.mem); if (r) { return r; } diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index aa8f778..96e4400 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -1118,7 +1118,7 @@ static void radeon_vm_update_ptes(struct radeon_device *rdev, } /** - * radeon_vm_bo_update_pte - map a bo into the vm page table + * radeon_vm_bo_update - map a bo into the vm page table * * @rdev: radeon_device pointer * @vm: requested vm @@ -1130,10 +1130,10 @@ static void radeon_vm_update_ptes(struct radeon_device *rdev, * * Object have to be reserved & global and local mutex must be locked! */ -int radeon_vm_bo_update_pte(struct radeon_device *rdev, - struct radeon_vm *vm, - struct radeon_bo *bo, - struct ttm_mem_reg *mem) +int radeon_vm_bo_update(struct radeon_device *rdev, + struct radeon_vm *vm, + struct radeon_bo *bo, + struct ttm_mem_reg *mem) { struct radeon_ib ib; struct radeon_bo_va *bo_va; @@ -1178,6 +1178,8 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev, bo_va->valid = false; } + trace_radeon_vm_bo_update(bo_va); + nptes = radeon_bo_ngpu_pages(bo); /* assume two extra pdes in case the mapping overlaps the borders */ @@ -1259,7 +1261,7 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev, mutex_lock(&rdev->vm_manager.lock); mutex_lock(&bo_va->vm->mutex); if (bo_va->soffset) { - r = radeon_vm_bo_update_pte(rdev, bo_va->vm, bo_va->bo, NULL); + r = radeon_vm_bo_update(rdev, bo_va->vm, bo_va->bo, NULL); } mutex_unlock(&rdev->vm_manager.lock); list_del(&bo_va->vm_list); diff --git a/drivers/gpu/drm/radeon/radeon_trace.h b/drivers/gpu/drm/radeon/radeon_trace.h index 8c13aec..ba74718 100644 --- a/drivers/gpu/drm/radeon/radeon_trace.h +++ b/drivers/gpu/drm/radeon/radeon_trace.h @@ -62,6 +62,24 @@ TRACE_EVENT(radeon_vm_grab_id, TP_printk("vmid=%u, ring=%u", __entry->vmid, __entry->ring) ); +TRACE_EVENT(radeon_vm_bo_update, + TP_PROTO(struct radeon_bo_va *bo_va), + TP_ARGS(bo_va), + TP_STRUCT__entry( +__field(u64, soffset) +__field(u64, eoffset) +__field(u32, flags) +), + + TP_fast_assign( + __entry->soffset = bo_va->soffset; + __entry->eoffset = bo_va->eoffset; +
[PATCH 1/2] drm/radeon: add VMID allocation trace point
From: Christian K?nig Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_gart.c | 2 ++ drivers/gpu/drm/radeon/radeon_trace.h | 15 +++ 2 files changed, 17 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c index 3044e50..aa8f778 100644 --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -29,6 +29,7 @@ #include #include "radeon.h" #include "radeon_reg.h" +#include "radeon_trace.h" /* * GART @@ -737,6 +738,7 @@ struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev, for (i = 0; i < 2; ++i) { if (choices[i]) { vm->id = choices[i]; + trace_radeon_vm_grab_id(vm->id, ring); return rdev->vm_manager.active[choices[i]]; } } diff --git a/drivers/gpu/drm/radeon/radeon_trace.h b/drivers/gpu/drm/radeon/radeon_trace.h index 9f0e181..8c13aec 100644 --- a/drivers/gpu/drm/radeon/radeon_trace.h +++ b/drivers/gpu/drm/radeon/radeon_trace.h @@ -47,6 +47,21 @@ TRACE_EVENT(radeon_cs, __entry->fences) ); +TRACE_EVENT(radeon_vm_grab_id, + TP_PROTO(unsigned vmid, int ring), + TP_ARGS(vmid, ring), + TP_STRUCT__entry( +__field(u32, vmid) +__field(u32, ring) +), + + TP_fast_assign( + __entry->vmid = vmid; + __entry->ring = ring; + ), + TP_printk("vmid=%u, ring=%u", __entry->vmid, __entry->ring) +); + TRACE_EVENT(radeon_vm_set_page, TP_PROTO(uint64_t pe, uint64_t addr, unsigned count, uint32_t incr, uint32_t flags), -- 1.8.1.2
[Bug 71812] VDPAU: MPEG-4 ASP Garbling/Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=71812 Christian K?nig changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Christian K?nig --- That's a known problem, but so far we didn't had any bugreport for it. Thanks for filling one in. -- 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/20131125/5fa8290b/attachment.html>
[RFCv4 00/14] Atomic/nuclear modeset/pageflip
Previous Revision: http://lists.freedesktop.org/archives/dri-devel/2013-November/049363.html Changes since previous: + convert new properties over to DRM_MODE_PROP_EXTENDED_TYPE, so we aren't consuming one new bit per property type (as suggested by, I think, Ville) + Fixed usage of ww_ctx, split things out into 'struct drm_modeset_lock' to make things easier when we start making locking even more fine grained (ie. per-plane locks, etc) + Handle connector_ids changes better. In legacy setcrtc path, we implicitly update other CRTCs that are having their connector stolen, whereas in atomic ioctl there is no implicit connector stealing (ie. this is an error if user does not also remove the connector from it's current CRTC. - Description from original RFC (with updated links): This patchset is the merging of Ville's atomic modeset ioctl, and the drm_{crtc,plane}_state stuff from my original nuclear pageflip RFC. It is currently working on msm with an updated version of Ville's glplane test app (removing cursor properties and atomic event): https://github.com/robclark/glplane the libdrm bits can be found here: https://github.com/robclark/libdrm/commits/atomic The msm part is on top of msm-next, the complete branch can be found: http://cgit.freedesktop.org/~robclark/linux/log/?h=global-thermonuclear-war-9 Compared to my earlier nuclear pageflip RFC, there is now a set of drm_atomic helpers which do most of the non-hw-specific work for the different drivers. Unlike the crtc helpers, it is intended that the atomic helpers can be used piecemeal by the drivers, either using all or overriding parts as needed. A naive driver, with no special constraints or hw support for atomic updates may simply add the following to their driver struct: .atomic_begin = drm_atomic_helper_begin, .atomic_set_event = drm_atomic_helper_set_event, .atomic_check = drm_atomic_helper_check, .atomic_commit= drm_atomic_helper_commit, .atomic_end = drm_atomic_helper_end, .atomic_helpers = &drm_atomic_helper_funcs, In addition, if you're plane/crtc doesn't already have it's own custom properties, then add to your plane/crtc_funcs: .set_property = drm_atomic_helper_{plane,crtc}_set_property, A driver which can have (for example) conflicting modes across multiple crtcs (for example, bandwidth limitations or clock/pll configuration restrictions), can wrap drm_atomic_helper_check() with their own driver specific .atomic_check() function. A driver which can support true atomic updates can wrap drm_atomic_helper_commit(). A driver with custom properties should override the appropriate get_state(), check_state(), and commit_state() functions in .atomic_helpers if it uses the drm-atomic-helpers. Otherwise it is free to use &drm_atomic_helper_funcs as-is. Rob Clark (11): drm: add atomic fxns drm: convert crtc to ww_mutex drm: add object property type drm: add signed-range property type drm: helpers to find mode objects drm: split propvals out and blob property support drm: convert plane to properties/state drm: convert crtc to properties/state drm: push locking down into restore_fbdev_mode drm/msm: add atomic support HACK: drm: allow FB's in drm_mode_object_find Ville Syrj?l? (3): drm: Allow drm_mode_object_find() to look up an object of any type drm: Refactor object property check code drm: Atomic modeset ioctl drivers/gpu/drm/Makefile|3 +- drivers/gpu/drm/ast/ast_drv.c |6 + drivers/gpu/drm/ast/ast_drv.h |1 + drivers/gpu/drm/ast/ast_mode.c |1 + drivers/gpu/drm/cirrus/cirrus_drv.c |6 + drivers/gpu/drm/cirrus/cirrus_drv.h |1 + drivers/gpu/drm/cirrus/cirrus_mode.c|1 + drivers/gpu/drm/drm_atomic_helper.c | 696 drivers/gpu/drm/drm_crtc.c | 1630 +++ drivers/gpu/drm/drm_drv.c |1 + drivers/gpu/drm/drm_fb_cma_helper.c |9 +- drivers/gpu/drm/drm_fb_helper.c | 28 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 15 +- drivers/gpu/drm/exynos/exynos_drm_drv.c |7 + drivers/gpu/drm/exynos/exynos_drm_encoder.c |6 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +- drivers/gpu/drm/gma500/cdv_intel_crt.c |4 +- drivers/gpu/drm/gma500/cdv_intel_display.c |1 + drivers/gpu/drm/gma500/cdv_intel_dp.c |7 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c |7 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 10 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 12 +- drivers/gpu/drm/gma500/psb_drv.c| 11 +- drivers/gpu/drm/gma500/psb_drv.h|1 + drivers/gpu/drm/gma500/psb_intel_display.c |1 + drivers/gpu/drm/gma500/psb
[RFCv4 02/14] drm: convert crtc to ww_mutex
For atomic, it will be quite convenient to not have to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock so that the atomic state won't eventually have to keep separate lists of locked planes/crtcs/etc. The state keeps track of which locks it has aquired, and for the benefit of NONBLOCK operations, supports transfering "locked" resources to driver worker/thread to complete the asynchronous state change. --- drivers/gpu/drm/drm_atomic_helper.c | 140 ++- drivers/gpu/drm/drm_crtc.c | 105 +++--- drivers/gpu/drm/i915/intel_display.c | 16 ++-- drivers/gpu/drm/omapdrm/omap_crtc.c | 10 +-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +- include/drm/drmP.h | 5 -- include/drm/drm_atomic_helper.h | 17 + include/drm/drm_crtc.h | 75 +-- include/uapi/drm/drm_mode.h | 3 + 9 files changed, 340 insertions(+), 39 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 46c67b8..8b37cf1 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -49,9 +49,14 @@ void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags) state = ptr; ptr = &state[1]; + ww_acquire_init(&state->ww_ctx, &crtc_ww_class); + INIT_LIST_HEAD(&state->locked); + + mutex_init(&state->mutex); kref_init(&state->refcount); state->dev = dev; state->flags = flags; + return state; } EXPORT_SYMBOL(drm_atomic_helper_begin); @@ -91,6 +96,103 @@ int drm_atomic_helper_check(struct drm_device *dev, void *state) } EXPORT_SYMBOL(drm_atomic_helper_check); +/* Note that we drop and re-acquire the locks w/ ww_mutex directly, + * since we keep the crtc in our list with in_atomic == true. + */ + +static void drop_locks(struct drm_atomic_helper_state *a, + struct ww_acquire_ctx *ww_ctx) +{ + struct drm_modeset_lock *lock; + + mutex_lock(&a->mutex); + list_for_each_entry(lock, &a->locked, head) + ww_mutex_unlock(&lock->mutex); + mutex_unlock(&a->mutex); + + ww_acquire_fini(ww_ctx); +} + +static void grab_locks(struct drm_atomic_helper_state *a, + struct ww_acquire_ctx *ww_ctx) +{ + struct drm_modeset_lock *lock, *slow_locked, *contended; + int ret; + + lock = slow_locked = contended = NULL; + + + ww_acquire_init(ww_ctx, &crtc_ww_class); + + /* +* We need to do proper rain^Hww dance.. another context +* could sneak in a grab the lock in order to check +* crtc->in_atomic, and we get -EDEADLK. But the winner +* will realize the mistake when it sees crtc->in_atomic +* already set, and then drop lock and return -EBUSY. +* So we just need to keep dancing until we win. +*/ +retry: + ret = 0; + list_for_each_entry(lock, &a->locked, head) { + if (lock == slow_locked) { + slow_locked = NULL; + continue; + } + contended = lock; + ret = ww_mutex_lock(&lock->mutex, ww_ctx); + if (ret) + goto fail; + } + +fail: + if (ret == -EDEADLK) { + /* we lost out in a seqno race, backoff, lock and retry.. */ + + list_for_each_entry(lock, &a->locked, head) { + if (lock == contended) + break; + ww_mutex_unlock(&lock->mutex); + } + + if (slow_locked) + ww_mutex_unlock(&slow_locked->mutex); + + ww_mutex_lock_slow(&contended->mutex, ww_ctx); + slow_locked = contended; + goto retry; + } + WARN_ON(ret); /* if we get EALREADY then something is fubar */ +} + +static void commit_locks(struct drm_atomic_helper_state *a, + struct ww_acquire_ctx *ww_ctx) +{ + /* and properly release them (clear in_atomic, remove from list): */ + mutex_lock(&a->mutex); + while (!list_empty(&a->locked)) { + struct drm_modeset_lock *lock; + + lock = list_first_entry(&a->locked, + struct drm_modeset_lock, head); + + drm_modeset_unlock(lock); + } + mutex_unlock(&a->mutex); + ww_acquire_fini(ww_ctx); + a->committed = true; +} + +static int atomic_commit(struct drm_atomic_helper_state *a, + struct ww_acquire_ctx *ww_ctx) +{ + int ret = 0; + + commit_locks(a, ww_ctx); + + return ret; +} + /** * drm_atomic_
[RFCv4 03/14] drm: add object property type
An object property is an id (idr) for a drm mode object. This will allow a property to be used set/get a framebuffer, CRTC, etc. --- drivers/gpu/drm/drm_crtc.c | 60 +++-- include/drm/drm_crtc.h | 27 include/uapi/drm/drm_mode.h | 14 +++ 3 files changed, 88 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index c8a4d2f..8013204 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -2913,6 +2913,8 @@ struct drm_property *drm_property_create(struct drm_device *dev, int flags, if (!property) return NULL; + property->dev = dev; + if (num_values) { property->values = kzalloc(sizeof(uint64_t)*num_values, GFP_KERNEL); if (!property->values) @@ -2933,6 +2935,9 @@ struct drm_property *drm_property_create(struct drm_device *dev, int flags, } list_add_tail(&property->head, &dev->mode_config.property_list); + + BUG_ON(!drm_property_type_valid(property)); + return property; fail: kfree(property->values); @@ -3016,19 +3021,38 @@ struct drm_property *drm_property_create_range(struct drm_device *dev, int flags } EXPORT_SYMBOL(drm_property_create_range); +struct drm_property *drm_property_create_object(struct drm_device *dev, +int flags, const char *name, uint32_t type) +{ + struct drm_property *property; + + flags |= DRM_MODE_PROP_OBJECT; + + property = drm_property_create(dev, flags, name, 1); + if (!property) + return NULL; + + property->values[0] = type; + + return property; +} +EXPORT_SYMBOL(drm_property_create_object); + int drm_property_add_enum(struct drm_property *property, int index, uint64_t value, const char *name) { struct drm_property_enum *prop_enum; - if (!(property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK))) + if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) || + drm_property_type_is(property, DRM_MODE_PROP_BITMASK))) return -EINVAL; /* * Bitmask enum properties have the additional constraint of values * from 0 to 63 */ - if ((property->flags & DRM_MODE_PROP_BITMASK) && (value > 63)) + if (drm_property_type_is(property, DRM_MODE_PROP_BITMASK) && + (value > 63)) return -EINVAL; if (!list_empty(&property->enum_blob_list)) { @@ -3153,10 +3177,11 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev, } property = obj_to_property(obj); - if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) { + if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) || + drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) { list_for_each_entry(prop_enum, &property->enum_blob_list, head) enum_count++; - } else if (property->flags & DRM_MODE_PROP_BLOB) { + } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) { list_for_each_entry(prop_blob, &property->enum_blob_list, head) blob_count++; } @@ -3178,7 +3203,8 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev, } out_resp->count_values = value_count; - if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) { + if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) || + drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) { if ((out_resp->count_enum_blobs >= enum_count) && enum_count) { copied = 0; enum_ptr = (struct drm_mode_property_enum __user *)(unsigned long)out_resp->enum_blob_ptr; @@ -3200,7 +3226,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev, out_resp->count_enum_blobs = enum_count; } - if (property->flags & DRM_MODE_PROP_BLOB) { + if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) { if ((out_resp->count_enum_blobs >= blob_count) && blob_count) { copied = 0; blob_id_ptr = (uint32_t __user *)(unsigned long)out_resp->enum_blob_ptr; @@ -3331,19 +3357,25 @@ static bool drm_property_change_is_valid(struct drm_property *property, { if (property->flags & DRM_MODE_PROP_IMMUTABLE) return false; - if (property->flags & DRM_MODE_PROP_RANGE) { + + if (drm_property_type_is(property, DRM_MODE_PROP_RANGE)) { if (value < property->values[0] || value > property->values[1]) return false; return true; - } else if (property->flags & DRM_MODE_PROP_BITMASK) { + } else if (drm_property_type_is(property, DRM_MODE_P
[RFCv4 01/14] drm: add atomic fxns
The 'atomic' mechanism allows for multiple properties to be updated, checked, and commited atomically. This will be the basis of atomic- modeset and nuclear-pageflip. The basic flow is: state = dev->atomic_begin(); for (... one or more ...) obj->set_property(obj, state, prop, value); if (dev->atomic_check(state)) dev->atomic_commit(state); dev->atomic_end(state); The split of check and commit steps is to allow for ioctls with a test-only flag (which would skip the commit step). --- drivers/gpu/drm/Makefile| 3 +- drivers/gpu/drm/ast/ast_drv.c | 6 ++ drivers/gpu/drm/ast/ast_drv.h | 1 + drivers/gpu/drm/cirrus/cirrus_drv.c | 6 ++ drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + drivers/gpu/drm/drm_atomic_helper.c | 135 ++ drivers/gpu/drm/drm_crtc.c | 141 +--- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 ++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_crt.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_dp.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 4 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 4 +- drivers/gpu/drm/gma500/psb_drv.c| 7 ++ drivers/gpu/drm/gma500/psb_drv.h| 1 + drivers/gpu/drm/gma500/psb_intel_drv.h | 4 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 4 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 8 ++ drivers/gpu/drm/i915/intel_crt.c| 4 +- drivers/gpu/drm/i915/intel_dp.c | 4 +- drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 4 +- drivers/gpu/drm/i915/intel_lvds.c | 4 +- drivers/gpu/drm/i915/intel_sdvo.c | 4 +- drivers/gpu/drm/i915/intel_tv.c | 5 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 7 ++ drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/msm/mdp4/mdp4_crtc.c| 4 +- drivers/gpu/drm/msm/mdp4/mdp4_plane.c | 4 +- drivers/gpu/drm/msm/msm_drv.c | 6 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/nouveau/dispnv04/overlay.c | 4 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 ++ drivers/gpu/drm/nouveau/nouveau_drm.h | 1 + drivers/gpu/drm/omapdrm/omap_crtc.c | 7 +- drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++ drivers/gpu/drm/omapdrm/omap_drv.h | 5 +- drivers/gpu/drm/omapdrm/omap_plane.c| 4 +- drivers/gpu/drm/qxl/qxl_display.c | 4 +- drivers/gpu/drm/qxl/qxl_drv.c | 9 ++ drivers/gpu/drm/radeon/radeon_connectors.c | 9 +- drivers/gpu/drm/radeon/radeon_drv.c | 9 ++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 7 ++ drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c| 7 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 + drivers/gpu/drm/tilcdc/tilcdc_slave.c | 3 +- drivers/gpu/drm/udl/udl_connector.c | 6 +- drivers/gpu/drm/udl/udl_drv.c | 8 ++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 ++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 +- include/drm/drmP.h | 77 +++ include/drm/drm_atomic_helper.h | 100 include/drm/drm_crtc.h | 14 +-- 61 files changed, 619 insertions(+), 103 deletions(-) create mode 100644 drivers/gpu/drm/drm_atomic_helper.c create mode 100644 include/drm/drm_atomic_helper.h diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index cc08b84..4a2e320 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -13,7 +13,8 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \ drm_crtc.o drm_modes.o drm_edid.o \ drm_info.o drm_debugfs.o drm_encoder_slave.o \ drm_trace_points.o drm_global.o drm_prime.o \ - drm_rect.o drm_vma_manager.o drm_flip_work.o + drm_rect.o drm_vma_manager.o drm_flip_work.o \ + drm_atomic_helper.o drm-$(CONFIG_COMPAT) += drm_ioc32.o drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 5137f15..90ba5f1 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -216,6 +216,12 @@ static struct drm_driver driver = { .dumb_map_offset = ast_dumb_mma
[RFCv4 04/14] drm: add signed-range property type
Like range, but values are signed. --- drivers/gpu/drm/drm_crtc.c | 29 + include/drm/drm_crtc.h | 12 include/uapi/drm/drm_mode.h | 1 + 3 files changed, 38 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 8013204..e438e24 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -3002,14 +3002,12 @@ struct drm_property *drm_property_create_bitmask(struct drm_device *dev, } EXPORT_SYMBOL(drm_property_create_bitmask); -struct drm_property *drm_property_create_range(struct drm_device *dev, int flags, -const char *name, +static struct drm_property *property_create_range(struct drm_device *dev, +int flags, const char *name, uint64_t min, uint64_t max) { struct drm_property *property; - flags |= DRM_MODE_PROP_RANGE; - property = drm_property_create(dev, flags, name, 2); if (!property) return NULL; @@ -3019,8 +3017,25 @@ struct drm_property *drm_property_create_range(struct drm_device *dev, int flags return property; } + +struct drm_property *drm_property_create_range(struct drm_device *dev, int flags, +const char *name, +uint64_t min, uint64_t max) +{ + return property_create_range(dev, DRM_MODE_PROP_RANGE | flags, + name, min, max); +} EXPORT_SYMBOL(drm_property_create_range); +struct drm_property *drm_property_create_signed_range(struct drm_device *dev, +int flags, const char *name, +int64_t min, int64_t max) +{ + return property_create_range(dev, DRM_MODE_PROP_SIGNED_RANGE | flags, + name, I642U64(min), I642U64(max)); +} +EXPORT_SYMBOL(drm_property_create_signed_range); + struct drm_property *drm_property_create_object(struct drm_device *dev, int flags, const char *name, uint32_t type) { @@ -3362,6 +3377,12 @@ static bool drm_property_change_is_valid(struct drm_property *property, if (value < property->values[0] || value > property->values[1]) return false; return true; + } else if (drm_property_type_is(property, DRM_MODE_PROP_SIGNED_RANGE)) { + int64_t svalue = U642I64(value); + if (svalue < U642I64(property->values[0]) || + svalue > U642I64(property->values[1])) + return false; + return true; } else if (drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) { int i; uint64_t valid_mask = 0; diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c05d5ba..17790a0 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -65,6 +65,15 @@ struct drm_object_properties { uint64_t values[DRM_OBJECT_MAX_PROPERTY]; }; +static inline int64_t U642I64(uint64_t val) +{ + return (int64_t)*((int64_t *)&val); +} +static inline uint64_t I642U64(int64_t val) +{ + return (uint64_t)*((uint64_t *)&val); +} + /* * Note on terminology: here, for brevity and convenience, we refer to connector * control chips as 'CRTCs'. They can control any type of connector, VGA, LVDS, @@ -1123,6 +1132,9 @@ struct drm_property *drm_property_create_bitmask(struct drm_device *dev, struct drm_property *drm_property_create_range(struct drm_device *dev, int flags, const char *name, uint64_t min, uint64_t max); +struct drm_property *drm_property_create_signed_range(struct drm_device *dev, +int flags, const char *name, +int64_t min, int64_t max); struct drm_property *drm_property_create_object(struct drm_device *dev, int flags, const char *name, uint32_t type); extern void drm_property_destroy(struct drm_device *dev, struct drm_property *property); diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 516425d..6421edc 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -264,6 +264,7 @@ struct drm_mode_get_connector { #define DRM_MODE_PROP_EXTENDED_TYPE0xffc0 #define DRM_MODE_PROP_TYPE(n) ((n) << 6) #define DRM_MODE_PROP_OBJECT DRM_MODE_PROP_TYPE(1) +#define DRM_MODE_PROP_SIGNED_RANGE DRM_MODE_PROP_TYPE(2) struct drm_mode_property_enum { __u64 value; -- 1.8.4.2
[RFCv4 05/14] drm: helpers to find mode objects
Add a few more useful helpers to find mode objects. --- drivers/gpu/drm/drm_crtc.c | 97 ++ include/drm/drm_crtc.h | 33 2 files changed, 63 insertions(+), 67 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e438e24..622d001 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1633,7 +1633,6 @@ int drm_mode_getcrtc(struct drm_device *dev, { struct drm_mode_crtc *crtc_resp = data; struct drm_crtc *crtc; - struct drm_mode_object *obj; int ret = 0; if (!drm_core_check_feature(dev, DRIVER_MODESET)) @@ -1641,13 +1640,11 @@ int drm_mode_getcrtc(struct drm_device *dev, drm_modeset_lock_all(dev); - obj = drm_mode_object_find(dev, crtc_resp->crtc_id, - DRM_MODE_OBJECT_CRTC); - if (!obj) { + crtc = drm_crtc_find(dev, crtc_resp->crtc_id); + if (!crtc) { ret = -ENOENT; goto out; } - crtc = obj_to_crtc(obj); crtc_resp->x = crtc->x; crtc_resp->y = crtc->y; @@ -1701,7 +1698,6 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, struct drm_file *file_priv) { struct drm_mode_get_connector *out_resp = data; - struct drm_mode_object *obj; struct drm_connector *connector; struct drm_display_mode *mode; int mode_count = 0; @@ -1725,13 +1721,11 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, mutex_lock(&dev->mode_config.mutex); - obj = drm_mode_object_find(dev, out_resp->connector_id, - DRM_MODE_OBJECT_CONNECTOR); - if (!obj) { + connector = drm_connector_find(dev, out_resp->connector_id); + if (!connector) { ret = -ENOENT; goto out; } - connector = obj_to_connector(obj); props_count = connector->properties.count; @@ -1833,7 +1827,6 @@ int drm_mode_getencoder(struct drm_device *dev, void *data, struct drm_file *file_priv) { struct drm_mode_get_encoder *enc_resp = data; - struct drm_mode_object *obj; struct drm_encoder *encoder; int ret = 0; @@ -1841,13 +1834,11 @@ int drm_mode_getencoder(struct drm_device *dev, void *data, return -EINVAL; drm_modeset_lock_all(dev); - obj = drm_mode_object_find(dev, enc_resp->encoder_id, - DRM_MODE_OBJECT_ENCODER); - if (!obj) { + encoder = drm_encoder_find(dev, enc_resp->encoder_id); + if (!encoder) { ret = -ENOENT; goto out; } - encoder = obj_to_encoder(obj); if (encoder->crtc) enc_resp->crtc_id = encoder->crtc->base.id; @@ -1922,7 +1913,6 @@ int drm_mode_getplane(struct drm_device *dev, void *data, struct drm_file *file_priv) { struct drm_mode_get_plane *plane_resp = data; - struct drm_mode_object *obj; struct drm_plane *plane; uint32_t __user *format_ptr; int ret = 0; @@ -1931,13 +1921,11 @@ int drm_mode_getplane(struct drm_device *dev, void *data, return -EINVAL; drm_modeset_lock_all(dev); - obj = drm_mode_object_find(dev, plane_resp->plane_id, - DRM_MODE_OBJECT_PLANE); - if (!obj) { + plane = drm_plane_find(dev, plane_resp->plane_id); + if (!plane) { ret = -ENOENT; goto out; } - plane = obj_to_plane(obj); if (plane->crtc) plane_resp->crtc_id = plane->crtc->base.id; @@ -1987,7 +1975,6 @@ int drm_mode_setplane(struct drm_device *dev, void *data, struct drm_file *file_priv) { struct drm_mode_set_plane *plane_req = data; - struct drm_mode_object *obj; struct drm_plane *plane; struct drm_crtc *crtc; struct drm_framebuffer *fb = NULL, *old_fb = NULL; @@ -2002,14 +1989,12 @@ int drm_mode_setplane(struct drm_device *dev, void *data, * First, find the plane, crtc, and fb objects. If not available, * we don't bother to call the driver. */ - obj = drm_mode_object_find(dev, plane_req->plane_id, - DRM_MODE_OBJECT_PLANE); - if (!obj) { + plane = drm_plane_find(dev, plane_req->plane_id); + if (!plane) { DRM_DEBUG_KMS("Unknown plane ID %d\n", plane_req->plane_id); return -ENOENT; } - plane = obj_to_plane(obj); /* No fb means shut it down */ if (!plane_req->fb_id) { @@ -2022,15 +2007,13 @@ int drm_mode_setplane(struct drm_device *dev, void *data, goto out; } - obj = drm_mode_object_find(dev, plane_req->crtc_i
[RFCv4 06/14] drm: split propvals out and blob property support
Split property values out into a different struct, so we can later move property values into state structs. This will allow the property values to stay in sync w/ the state updates which are either discarded or atomically committed. And since we are touching all the same code, add support for mutable blob properties, which will also be needed for atomic modeset. --- drivers/gpu/drm/drm_crtc.c | 79 + drivers/gpu/drm/drm_fb_helper.c | 3 +- drivers/gpu/drm/gma500/cdv_intel_dp.c | 3 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 6 ++- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 8 +-- drivers/gpu/drm/gma500/psb_intel_lvds.c | 6 ++- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 19 +-- drivers/gpu/drm/i2c/ch7006_drv.c| 4 +- drivers/gpu/drm/i915/intel_display.c| 3 +- drivers/gpu/drm/i915/intel_dp.c | 3 +- drivers/gpu/drm/i915/intel_hdmi.c | 3 +- drivers/gpu/drm/i915/intel_sdvo.c | 19 +-- drivers/gpu/drm/i915/intel_tv.c | 6 ++- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 3 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +- drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 3 +- drivers/gpu/drm/rcar-du/rcar_du_vgacon.c| 3 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 4 +- include/drm/drm_crtc.h | 11 +++- 21 files changed, 142 insertions(+), 57 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 622d001..68eeb2a 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -173,6 +173,14 @@ void drm_warn_on_modeset_not_all_locked(struct drm_device *dev) } EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked); +static int drm_mode_set_obj_prop(struct drm_mode_object *obj, + void *state, struct drm_property *property, + uint64_t value, void *blob_data); +static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, + int length, void *data); +static void drm_property_destroy_blob(struct drm_device *dev, + struct drm_property_blob *blob); + /* Avoid boilerplate. I'm tired of typing. */ #define DRM_ENUM_NAME_FN(fnname, list) \ const char *fnname(int val) \ @@ -727,6 +735,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, goto out; crtc->base.properties = &crtc->properties; + crtc->base.propvals = &crtc->propvals; list_add_tail(&crtc->head, &dev->mode_config.crtc_list); dev->mode_config.num_crtc++; @@ -818,6 +827,7 @@ int drm_connector_init(struct drm_device *dev, goto out; connector->base.properties = &connector->properties; + connector->base.propvals = &connector->propvals; connector->dev = dev; connector->funcs = funcs; connector->connector_type = connector_type; @@ -991,6 +1001,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane *plane, goto out; plane->base.properties = &plane->properties; + plane->base.propvals = &plane->propvals; plane->dev = dev; plane->funcs = funcs; plane->format_types = kmalloc(sizeof(uint32_t) * format_count, @@ -1791,7 +1802,7 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, goto out; } - if (put_user(connector->properties.values[i], + if (put_user(connector->propvals.values[i], prop_values + copied)) { ret = -EFAULT; goto out; @@ -3102,19 +3113,33 @@ void drm_object_attach_property(struct drm_mode_object *obj, } obj->properties->ids[count] = property->base.id; - obj->properties->values[count] = init_val; + obj->propvals->values[count] = init_val; obj->properties->count++; } EXPORT_SYMBOL(drm_object_attach_property); int drm_object_property_set_value(struct drm_mode_object *obj, - struct drm_property *property, uint64_t val) + struct drm_object_property_values *propvals, + struct drm_property *property, uint64_t val, + void *blob_data) { int i; for (i = 0; i < obj->properties->count; i++) { if (obj->properties->ids[i] == property->base.id) { - obj->properties->values[i] = val; + struct drm_device *dev = property->dev; + if (property->flags & DRM_MODE_PROP_BLOB) { + struct drm_property_blob *blob, *o
[RFCv4 07/14] drm: Allow drm_mode_object_find() to look up an object of any type
From: Ville Syrj?l? To avoid having to pass object types from userspace for atomic mode setting ioctl, allow drm_mode_object_find() to look up an object of any type. This will only work as long as the all object types share the ID space. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 3 ++- include/drm/drm_crtc.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 68eeb2a..5142599 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -445,7 +445,8 @@ struct drm_mode_object *drm_mode_object_find(struct drm_device *dev, mutex_lock(&dev->mode_config.idr_mutex); obj = idr_find(&dev->mode_config.crtc_idr, id); - if (!obj || (obj->type != type) || (obj->id != id)) + if (!obj || (type != DRM_MODE_OBJECT_ANY && obj->type != type) || + (obj->id != id)) obj = NULL; mutex_unlock(&dev->mode_config.idr_mutex); diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index ff1ecb5..40eec19 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -52,6 +52,7 @@ struct drm_object_property_values; #define DRM_MODE_OBJECT_BLOB 0x #define DRM_MODE_OBJECT_PLANE 0x #define DRM_MODE_OBJECT_BRIDGE 0xbdbdbdbd +#define DRM_MODE_OBJECT_ANY 0 struct drm_mode_object { uint32_t id; -- 1.8.4.2
[RFCv4 08/14] drm: Refactor object property check code
From: Ville Syrj?l? Refactor the code to check whether an object has a specific property to a new function. v1: original v2: rebase on atomic -- Rob Clark v3: EINVAL->ENOENT Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 5142599..8180499 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -3506,6 +3506,19 @@ static int drm_mode_set_obj_prop(struct drm_mode_object *obj, return -EINVAL; } +static bool object_has_prop(const struct drm_mode_object *obj, u32 prop_id) +{ + int i; + + if (!obj->properties) + return false; + + for (i = 0; i < obj->properties->count; i++) + if (obj->properties->ids[i] == prop_id) + return true; + return false; +} + /* call with mode_config mutex held */ static int drm_mode_set_obj_prop_id(struct drm_device *dev, void *state, uint32_t obj_id, uint32_t obj_type, @@ -3513,20 +3526,10 @@ static int drm_mode_set_obj_prop_id(struct drm_device *dev, void *state, { struct drm_mode_object *arg_obj; struct drm_property *property; - int i; arg_obj = drm_mode_object_find(dev, obj_id, obj_type); - if (!arg_obj) + if (!(arg_obj && object_has_prop(arg_obj, prop_id))) return -ENOENT; - if (!arg_obj->properties) - return -EINVAL; - - for (i = 0; i < arg_obj->properties->count; i++) - if (arg_obj->properties->ids[i] == prop_id) - break; - - if (i == arg_obj->properties->count) - return -EINVAL; property = drm_property_find(dev, prop_id); if (!property) -- 1.8.4.2
[RFCv4 09/14] drm: convert plane to properties/state
Break the mutable state of a plane out into a separate structure and use atomic properties mechanism to set plane attributes. This makes it easier to have some helpers for plane->set_property() and for checking for invalid params. The idea is that individual drivers can wrap the state struct in their own struct which adds driver specific parameters, for easy build-up of state across multiple set_property() calls and for easy atomic commit or roll- back. The same should be done for CRTC, encoder, and connector, but this patch only includes the first part (plane). --- drivers/gpu/drm/drm_atomic_helper.c | 156 ++- drivers/gpu/drm/drm_crtc.c | 397 +++- drivers/gpu/drm/drm_fb_helper.c | 17 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +- drivers/gpu/drm/i915/intel_sprite.c | 21 +- drivers/gpu/drm/msm/mdp4/mdp4_crtc.c| 2 +- drivers/gpu/drm/msm/mdp4/mdp4_plane.c | 19 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 8 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/omapdrm/omap_plane.c| 33 ++- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 8 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +- drivers/gpu/drm/shmobile/shmob_drm_plane.c | 6 +- drivers/gpu/drm/tegra/dc.c | 16 +- include/drm/drm_atomic_helper.h | 39 ++- include/drm/drm_crtc.h | 88 +- 19 files changed, 654 insertions(+), 189 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 8b37cf1..14e0571 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -39,10 +39,12 @@ void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags) { struct drm_atomic_helper_state *state; + int nplanes = dev->mode_config.num_plane; int sz; void *ptr; sz = sizeof(*state); + sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes; ptr = kzalloc(sz, GFP_KERNEL); @@ -57,6 +59,12 @@ void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags) state->dev = dev; state->flags = flags; + state->planes = ptr; + ptr = &state->planes[nplanes]; + + state->pstates = ptr; + ptr = &state->pstates[nplanes]; + return state; } EXPORT_SYMBOL(drm_atomic_helper_begin); @@ -92,7 +100,19 @@ EXPORT_SYMBOL(drm_atomic_helper_set_event); */ int drm_atomic_helper_check(struct drm_device *dev, void *state) { - return 0; /* for now */ + struct drm_atomic_helper_state *a = state; + int nplanes = dev->mode_config.num_plane; + int i, ret = 0; + + for (i = 0; i < nplanes; i++) { + if (a->planes[i]) { + ret = drm_atomic_check_plane_state(a->planes[i], a->pstates[i]); + if (ret) + break; + } + } + + return ret; } EXPORT_SYMBOL(drm_atomic_helper_check); @@ -168,6 +188,18 @@ fail: static void commit_locks(struct drm_atomic_helper_state *a, struct ww_acquire_ctx *ww_ctx) { + struct drm_device *dev = a->dev; + int nplanes = dev->mode_config.num_plane; + int i; + + for (i = 0; i < nplanes; i++) { + struct drm_plane *plane = a->planes[i]; + if (plane) { + plane->state->state = NULL; + drm_atomic_helper_destroy_plane_state(plane, a->pstates[i]); + } + } + /* and properly release them (clear in_atomic, remove from list): */ mutex_lock(&a->mutex); while (!list_empty(&a->locked)) { @@ -186,7 +218,17 @@ static void commit_locks(struct drm_atomic_helper_state *a, static int atomic_commit(struct drm_atomic_helper_state *a, struct ww_acquire_ctx *ww_ctx) { - int ret = 0; + int nplanes = a->dev->mode_config.num_plane; + int i, ret = 0; + + for (i = 0; i < nplanes; i++) { + struct drm_plane *plane = a->planes[i]; + if (plane) { + ret = drm_atomic_commit_plane_state(plane, a->pstates[i]); + if (ret) + break; + } + } commit_locks(a, ww_ctx); @@ -263,7 +305,117 @@ void _drm_atomic_helper_state_free(struct kref *kref) } EXPORT_SYMBOL(_drm_atomic_helper_state_free); +int drm_atomic_helper_plane_set_property(struct drm_plane *plane, void *state, + struct drm_property *property, uint64_t val, void *blob_data) +{ + struct drm_plane_state *pstate = drm_atomic_get_plane_state(plane, state); + if (IS_ERR(pstate)) +
[RFCv4 10/14] drm: convert crtc to properties/state
Break the mutable state of a crtc out into a separate structure and use atomic properties mechanism to set crtc attributes. This makes it easier to have some helpers for crtc->set_property() and for checking for invalid params. The idea is that individual drivers can wrap the state struct in their own struct which adds driver specific parameters, for easy build-up of state across multiple set_property() calls and for easy atomic commit or roll- back. --- drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c| 277 - drivers/gpu/drm/drm_crtc.c | 622 ++--- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 1 + drivers/gpu/drm/gma500/psb_intel_display.c | 1 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/mgag200/mgag200_mode.c | 1 + drivers/gpu/drm/msm/mdp4/mdp4_crtc.c | 6 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c| 1 + drivers/gpu/drm/nouveau/nv50_display.c | 1 + drivers/gpu/drm/omapdrm/omap_crtc.c| 12 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/qxl/qxl_display.c | 2 + drivers/gpu/drm/radeon/radeon_display.c| 2 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 + drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 1 + drivers/gpu/drm/udl/udl_modeset.c | 2 + drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 1 + drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 + include/drm/drm_atomic_helper.h| 39 ++ include/drm/drm_crtc.h | 82 +++- 24 files changed, 818 insertions(+), 250 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 7fc9f72..13f6943 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -619,6 +619,7 @@ static const struct drm_crtc_funcs ast_crtc_funcs = { .cursor_move = ast_cursor_move, .reset = ast_crtc_reset, .set_config = drm_crtc_helper_set_config, + .set_property = drm_atomic_helper_crtc_set_property, .gamma_set = ast_crtc_gamma_set, .destroy = ast_crtc_destroy, }; diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c b/drivers/gpu/drm/cirrus/cirrus_mode.c index adabc3d..9e0b713 100644 --- a/drivers/gpu/drm/cirrus/cirrus_mode.c +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c @@ -363,6 +363,7 @@ static void cirrus_crtc_destroy(struct drm_crtc *crtc) static const struct drm_crtc_funcs cirrus_crtc_funcs = { .gamma_set = cirrus_crtc_gamma_set, .set_config = drm_crtc_helper_set_config, + .set_property = drm_atomic_helper_crtc_set_property, .destroy = cirrus_crtc_destroy, }; diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 14e0571..9b60536 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -40,11 +40,13 @@ void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags) { struct drm_atomic_helper_state *state; int nplanes = dev->mode_config.num_plane; + int ncrtcs = dev->mode_config.num_crtc; int sz; void *ptr; sz = sizeof(*state); sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes; + sz += (sizeof(state->crtcs) + sizeof(state->cstates)) * ncrtcs; ptr = kzalloc(sz, GFP_KERNEL); @@ -65,6 +67,12 @@ void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags) state->pstates = ptr; ptr = &state->pstates[nplanes]; + state->crtcs = ptr; + ptr = &state->crtcs[ncrtcs]; + + state->cstates = ptr; + ptr = &state->cstates[ncrtcs]; + return state; } EXPORT_SYMBOL(drm_atomic_helper_begin); @@ -83,7 +91,18 @@ int drm_atomic_helper_set_event(struct drm_device *dev, void *state, struct drm_mode_object *obj, struct drm_pending_vblank_event *event) { - return -EINVAL; /* for now */ + switch (obj->type) { + case DRM_MODE_OBJECT_CRTC: { + struct drm_crtc_state *cstate = + drm_atomic_get_crtc_state(obj_to_crtc(obj), state); + if (IS_ERR(cstate)) + return PTR_ERR(cstate); + cstate->event = event; + return 0; + } + default: + return -EINVAL; + } } EXPORT_SYMBOL(drm_atomic_helper_set_event); @@ -102,6 +121,7 @@ int drm_atomic_helper_check(struct drm_device *dev, void *state) { struct drm_atomic_helper_state *a = state; int nplanes = dev->mode_config.num_plane; + int ncrtcs = dev->mode_config.num_crtc; int i, ret = 0; for (i = 0; i < nplanes; i++) { @@ -112,6 +132,14 @@ int drm_atomic_helper_check(struct drm_device *dev, voi
[RFCv4 11/14] drm: push locking down into restore_fbdev_mode
All the call-sites save one need locking. By pushing it down and adding a lockless flag, we can use the new spiffy atomic ww_mutex crtc locking and simplify all the call-sites. --- drivers/gpu/drm/drm_fb_cma_helper.c | 9 ++--- drivers/gpu/drm/drm_fb_helper.c | 12 +++- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +--- drivers/gpu/drm/gma500/psb_drv.c | 4 +--- drivers/gpu/drm/i915/intel_fbdev.c| 6 +- drivers/gpu/drm/msm/msm_drv.c | 7 ++- drivers/gpu/drm/omapdrm/omap_drv.c| 4 +--- drivers/gpu/drm/tegra/fb.c| 7 ++- include/drm/drm_fb_helper.h | 3 ++- 9 files changed, 19 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 61b5a47..df3ad41 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -429,13 +429,8 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_fini); */ void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma) { - if (fbdev_cma) { - struct drm_device *dev = fbdev_cma->fb_helper.dev; - - drm_modeset_lock_all(dev); - drm_fb_helper_restore_fbdev_mode(&fbdev_cma->fb_helper); - drm_modeset_unlock_all(dev); - } + if (fbdev_cma) + drm_fb_helper_restore_fbdev_mode(&fbdev_cma->fb_helper, false); } EXPORT_SYMBOL_GPL(drm_fbdev_cma_restore_mode); diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5773468..294fe5e 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -276,12 +276,15 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave); /** * drm_fb_helper_restore_fbdev_mode - restore fbdev configuration * @fb_helper: fbcon to restore + * @lockless: true in drm_fb_helper_force_kernel_mode() path, to avoid + * blocking in panic case, everywhere else should use false * * This should be called from driver's drm ->lastclose callback * when implementing an fbcon on top of kms using this helper. This ensures that * the user isn't greeted with a black screen when e.g. X dies. */ -bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper) +bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper, + bool lockless) { struct drm_device *dev = fb_helper->dev; struct drm_plane *plane; @@ -289,9 +292,8 @@ bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper) void *state; int i; - drm_warn_on_modeset_not_all_locked(dev); - - state = dev->driver->atomic_begin(dev, 0); + state = dev->driver->atomic_begin(dev, lockless ? + DRM_MODE_ATOMIC_NOLOCK : 0); if (IS_ERR(state)) { DRM_ERROR("failed to restore fbdev mode\n"); return true; @@ -343,7 +345,7 @@ static bool drm_fb_helper_force_kernel_mode(void) if (helper->dev->switch_power_state == DRM_SWITCH_POWER_OFF) continue; - ret = drm_fb_helper_restore_fbdev_mode(helper); + ret = drm_fb_helper_restore_fbdev_mode(helper, true); if (ret) error = true; } diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index e7c2f2d..8032021 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -354,7 +354,5 @@ void exynos_drm_fbdev_restore_mode(struct drm_device *dev) if (!private || !private->fb_helper) return; - drm_modeset_lock_all(dev); - drm_fb_helper_restore_fbdev_mode(private->fb_helper); - drm_modeset_unlock_all(dev); + drm_fb_helper_restore_fbdev_mode(private->fb_helper, false); } diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index 34c3116..a6545fe 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -153,11 +153,9 @@ static void psb_lastclose(struct drm_device *dev) struct drm_psb_private *dev_priv = dev->dev_private; struct psb_fbdev *fbdev = dev_priv->fbdev; - drm_modeset_lock_all(dev); - ret = drm_fb_helper_restore_fbdev_mode(&fbdev->psb_fb_helper); + ret = drm_fb_helper_restore_fbdev_mode(&fbdev->psb_fb_helper, false); if (ret) DRM_DEBUG("failed to restore crtc mode\n"); - drm_modeset_unlock_all(dev); return; } diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 895fcb4..4f7046d 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -313,11 +313,7 @@ void intel_fbdev_restore_mode(struct drm_device *dev) if (INTEL_INFO(dev)->num_pipes == 0) return; - drm_modeset_lock_all(dev); - - ret = drm_fb_helper_restore_fb
[RFCv4 12/14] drm: Atomic modeset ioctl
From: Ville Syrj?l? The atomic modeset ioctl cna be used to push any number of new values for object properties. The driver can then check the full device configuration as single unit, and try to apply the changes atomically. The ioctl simply takes a list of object IDs and property IDs and their values. For setting values to blob properties, the property value indicates the length of the data, and the actual data is passed via another blob pointer. The caller can demand non-blocking operation from the ioctl, and if the driver can't satisfy that requirement an error will be returned. The caller can also request to receive asynchronous completion events after the operation has reached the hardware. An event is sent for each object specified by the caller, whether or not the actual state of that object changed. Each event also carries a framebuffer ID, which indicates to user space that the specified object is no longer accessing that framebuffer. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 156 drivers/gpu/drm/drm_drv.c | 1 + include/drm/drmP.h | 6 ++ include/drm/drm_crtc.h | 2 + include/uapi/drm/drm.h | 12 include/uapi/drm/drm_mode.h | 20 ++ 6 files changed, 197 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 008b5bb..8158250 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -4581,3 +4581,159 @@ void drm_mode_config_cleanup(struct drm_device *dev) idr_destroy(&dev->mode_config.crtc_idr); } EXPORT_SYMBOL(drm_mode_config_cleanup); + +int drm_mode_atomic_ioctl(struct drm_device *dev, + void *data, struct drm_file *file_priv) +{ + struct drm_mode_atomic *arg = data; + uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned long)(arg->objs_ptr); + uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned long)(arg->count_props_ptr); + uint32_t __user *props_ptr = (uint32_t __user *)(unsigned long)(arg->props_ptr); + uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned long)(arg->prop_values_ptr); + uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned long)(arg->blob_values_ptr); + unsigned int copied_objs, copied_props, copied_blobs; + void *state; + int ret = 0; + unsigned int i, j; + + if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) + return -EINVAL; + + /* can't test and expect an event at the same time. */ + if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) && + (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) + return -EINVAL; + +retry: + copied_objs = 0; + copied_props = 0; + copied_blobs = 0; + + state = dev->driver->atomic_begin(dev, arg->flags); + if (IS_ERR(state)) { + ret = PTR_ERR(state); + goto out; + } + + for (i = 0; i < arg->count_objs; i++) { + uint32_t obj_id, count_props; + struct drm_mode_object *obj; + + if (get_user(obj_id, objs_ptr + copied_objs)) { + ret = -EFAULT; + goto out; + } + + obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY); + if (!obj || !obj->properties) { + ret = -ENOENT; + goto out; + } + + if ((obj->type == DRM_MODE_OBJECT_CRTC) && + (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) { + struct drm_pending_vblank_event *e = + create_vblank_event(dev, file_priv, arg->user_data); + if (!e) { + ret = -ENOMEM; + goto out; + } + ret = dev->driver->atomic_set_event(dev, state, obj, e); + if (ret) { + destroy_vblank_event(dev, file_priv, e); + goto out; + } + } + + if (get_user(count_props, count_props_ptr + copied_objs)) { + ret = -EFAULT; + goto out; + } + + copied_objs++; + + for (j = 0; j < count_props; j++) { + uint32_t prop_id; + uint64_t prop_value; + struct drm_property *prop; + void *blob_data = NULL; + + if (get_user(prop_id, props_ptr + copied_props)) { + ret = -EFAULT; + goto out; + } + + if (!object_has_prop(obj, prop_id)) { + ret = -EINVAL; + goto out; +
[RFCv4 13/14] drm/msm: add atomic support
TODO: probably can split this up into prep patch which splits the msm_queue_fence_cb out of gem.. --- drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/mdp4/mdp4_crtc.c | 57 ++ drivers/gpu/drm/msm/mdp4/mdp4_kms.c | 6 ++ drivers/gpu/drm/msm/mdp4/mdp4_kms.h | 1 + drivers/gpu/drm/msm/msm_atomic.c | 149 +++ drivers/gpu/drm/msm/msm_drv.c| 22 +- drivers/gpu/drm/msm/msm_drv.h| 8 ++ drivers/gpu/drm/msm/msm_gem.c| 24 +- drivers/gpu/drm/msm/msm_gem.h| 13 +++ 9 files changed, 228 insertions(+), 53 deletions(-) create mode 100644 drivers/gpu/drm/msm/msm_atomic.c diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index e5fa12b..f7648d1 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -18,6 +18,7 @@ msm-y := \ mdp4/mdp4_irq.o \ mdp4/mdp4_kms.o \ mdp4/mdp4_plane.o \ + msm_atomic.o \ msm_drv.o \ msm_fb.o \ msm_gem.o \ diff --git a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c index 650c147..4f6bce3 100644 --- a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c +++ b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c @@ -51,7 +51,6 @@ struct mdp4_crtc { /* if there is a pending flip, these will be non-null: */ struct drm_pending_vblank_event *event; - struct msm_fence_cb pageflip_cb; #define PENDING_CURSOR 0x1 #define PENDING_FLIP 0x2 @@ -120,12 +119,16 @@ static void complete_flip(struct drm_crtc *crtc, struct drm_file *file) spin_unlock_irqrestore(&dev->event_lock, flags); } -static void crtc_flush(struct drm_crtc *crtc) +void mdp4_crtc_flush(struct drm_crtc *crtc) { + struct msm_drm_private *priv = crtc->dev->dev_private; struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc); struct mdp4_kms *mdp4_kms = get_kms(crtc); uint32_t i, flush = 0; + if (priv->pending_crtcs & (1 << crtc->id)) + return; + for (i = 0; i < ARRAY_SIZE(mdp4_crtc->planes); i++) { struct drm_plane *plane = mdp4_crtc->planes[i]; if (plane) { @@ -148,23 +151,6 @@ static void request_pending(struct drm_crtc *crtc, uint32_t pending) mdp4_irq_register(get_kms(crtc), &mdp4_crtc->vblank); } -static void pageflip_cb(struct msm_fence_cb *cb) -{ - struct mdp4_crtc *mdp4_crtc = - container_of(cb, struct mdp4_crtc, pageflip_cb); - struct drm_crtc *crtc = &mdp4_crtc->base; - struct drm_framebuffer *fb = crtc->fb; - - if (!fb) - return; - - mdp4_plane_set_scanout(mdp4_crtc->plane, fb); - crtc_flush(crtc); - - /* enable vblank to complete flip: */ - request_pending(crtc, PENDING_FLIP); -} - static void unref_fb_worker(struct drm_flip_work *work, void *val) { struct mdp4_crtc *mdp4_crtc = @@ -374,7 +360,7 @@ static void mdp4_crtc_prepare(struct drm_crtc *crtc) static void mdp4_crtc_commit(struct drm_crtc *crtc) { mdp4_crtc_dpms(crtc, DRM_MODE_DPMS_ON); - crtc_flush(crtc); + mdp4_crtc_flush(crtc); /* drop the ref to mdp clk's that we got in prepare: */ mdp4_disable(get_kms(crtc)); } @@ -405,23 +391,27 @@ static int mdp4_crtc_page_flip(struct drm_crtc *crtc, { struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc); struct drm_device *dev = crtc->dev; - struct drm_gem_object *obj; unsigned long flags; + spin_lock_irqsave(&dev->event_lock, flags); if (mdp4_crtc->event) { + spin_unlock_irqrestore(&dev->event_lock, flags); dev_err(dev->dev, "already pending flip!\n"); return -EBUSY; } - obj = msm_framebuffer_bo(new_fb, 0); - - spin_lock_irqsave(&dev->event_lock, flags); mdp4_crtc->event = event; spin_unlock_irqrestore(&dev->event_lock, flags); update_fb(crtc, true, new_fb); - return msm_gem_queue_inactive_cb(obj, &mdp4_crtc->pageflip_cb); + mdp4_plane_set_scanout(mdp4_crtc->plane, crtc->fb); + mdp4_crtc_flush(crtc); + + /* enable vblank to complete flip: */ + request_pending(crtc, PENDING_FLIP); + + return 0; } static int mdp4_crtc_set_property(struct drm_crtc *crtc, void *state, @@ -585,8 +575,13 @@ static void mdp4_crtc_vblank_irq(struct mdp4_irq *irq, uint32_t irqstatus) pending = atomic_xchg(&mdp4_crtc->pending, 0); if (pending & PENDING_FLIP) { - complete_flip(crtc, NULL); - drm_flip_work_commit(&mdp4_crtc->unref_fb_work, priv->wq); + if (priv->pending_crtcs & (1 << crtc->id)) { + /* our update hasn't been flushed yet: */ + request_pending(crtc, PENDING_FLIP); + } else { + complete_flip(crtc, NULL); + drm_flip_work_commit(&mdp4_crtc->unref_fb_work,
[RFCv4 14/14] HACK: drm: allow FB's in drm_mode_object_find
Ugg.. we do actually want to permit FB's in atomic case, since FB will be looked up like any other object property value. Currently we do the FB refcnt'ing dance in atomic->commit(), and would rather not have to special case FB's or collect an FB ref when we look up the property. Not sure if it is better to rework the atomic FB refcnt'ing or loosen this restriction? --- drivers/gpu/drm/drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 8158250..e57b7eb 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -441,7 +441,7 @@ struct drm_mode_object *drm_mode_object_find(struct drm_device *dev, /* Framebuffers are reference counted and need their own lookup * function.*/ - WARN_ON(type == DRM_MODE_OBJECT_FB); +// WARN_ON(type == DRM_MODE_OBJECT_FB); mutex_lock(&dev->mode_config.idr_mutex); obj = idr_find(&dev->mode_config.crtc_idr, id); -- 1.8.4.2
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 --- Comment #5 from Dave Witbrodt --- Same problem here on HD 7850 (PITCAIRN 0x1002:0x6819 0x1787:0x2320). Yesterday I was upgrading my X server to test 1.15 RC2, which requires some libraries not available on Debian yet. All was well when I began: libdrm : 2.4.48 mesa : 10.1.0-devel (commit 53f89a43 of Nov. 17) xorg-server: 1.14.99.3 radeon DDX : 7.2.99 (commit d571d6af of Nov. 13) glamor : 0.5.1 (commit 890a7738 of Nov. 6) linux : 3.12.1 (+ some DRM from 3.13rc1) I had some build failures last time I tried to update the X server, and I saw bigger than usual changes coming for 1.15, so I thought I should invest some time into trying to get things working. After getting the dependencies satisfied and having succesfully built 1.14.99.902 (with the drivers rebuilt against it) everything was fine. In fact, I saw a very noticeable performance boost. On a roll, I decided to update Mesa and libdrm, ending up with this set of packages: libdrm : 2.4.49 mesa : 10.1.0-devel (commit f56f875b of Nov. 21) xorg-server: 1.14.99.902 radeon DDX : 7.2.99 (commit d571d6af of Nov. 13) glamor : 0.5.1 (commit 71e7168d of Nov. 13) linux : 3.12.1 (+ some DRM from 3.13rc1) That's when it all stopped working. Even downgrading the X stack and Mesa (in any combination) to the previous working versions still causes failures. The symptoms are that everything seems to be fine (kernel boots, X starts, you can use the desktop, etc.) until you touch OpenGL. Any attempt to try a game like 'torcs' (or even 'prboom-plus', which is much less GL intensive) causes X to freeze. It is sometimes possible to switch to a VT, but the screen goes black in a few moments so there is nothing to see; if the system does not reboot on its own, it is possible to use sysrq keys to shut it down somewhat sanely. When changing everything back (except libdrm) to previous working versions _also_ was not working, I began to suspect libdrm. After downgrading to libdrm 2.4.48, everything was working again flawlessly; even upgrading Mesa and the X stack continued to work perfectly, so I can once again enjoy the 1.15 performance improvements! It took so many hours to identify libdrm 2.4.49 as the culprit -- I was assuming that xorg-server, mesa, or glamor were at fault -- that I ran out of time last night. I only have to work 2 days this week, so I should be able to bisect it in 2 days (if no developer can reproduce it by then). -- 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/20131125/9909cbb2/attachment.html>
[Bug 71975] [regression][bisected] fast hdmi audio playback
https://bugs.freedesktop.org/show_bug.cgi?id=71975 Brian Paterni 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 -- 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/20131125/49467143/attachment.html>
[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Sat, Nov 23, 2013 at 2:10 AM, Ville Syrj?l? wrote: > On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote: >> Ville Syrj?l? writes: >> >> > What is this format anyway? -ENODOCS >> >> Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-) >> >> > If its just an srgb version of ARGB, then I wouldn't really want it >> > in drm_fourcc.h. I expect colorspacy stuff will be handled by various >> > crtc/plane properties in the kernel so we don't need to encode that >> > stuff into the fb format. >> >> It's not any different from splitting YUV codes from RGB codes; > > Not really. Saying something is YUV (or rather Y'CbCr) doesn't > actually tell you the color space. It just tells you whether the > information is encoded as R+G+B or Y+Cb+Cr. How you convert between > them is another matter. You need to know the gamma, color primaries, > chroma siting for sub-sampled YCbCr formats, etc. Yep. Fbdev has a separation of type (how pixel values are laid out in memory), fb_bitfield structs (how tuples are formed into pixels), and visual (how to interprete the tuples). The fb_bitfield structs do have RGB-centric names, but you could use them for e.g. Y, Cb, Cr, and alpha, giving a proper visual. Unfortunately the YCbCr visuals haven't made it into mainline. FOURCC unifies all of that in (not so) unique 32-bit IDs. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support
Hi Thierry, Thanks for the review. On 11/22/2013 06:41 PM, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 05:25:23PM +0100, Andrzej Hajda wrote: >> MIPI DSI bus allows to model DSI hosts >> and DSI devices using Linux bus. > This looks somewhat terse. Any chance you could be more verbose about > what exactly this does? You could mention for instance that it allows > DSI devices to be instantiated from device tree and manually. That a > Linux bus type is provided and device drivers can use that to bind to > DSI devices. OK. > >> Signed-off-by: Andrzej Hajda >> Signed-off-by: Kyungmin Park >> --- >> Hi, >> >> This is my implementation of mipi dsi bus. >> The first time it was posted as a part of CDF infrastructure [1], >> but if it can be merged independently I will be glad. >> >> I have not addressed yet Bert's comments, but I think it should >> be easy, once we have agreement how to implement it. >> >> There are also working drivers which uses this bus: >> - Exynos DSI master, >> - s6e8aa0 panel. >> I will post them later. >> >> [1] http://www.mail-archive.com/dri-devel at >> lists.freedesktop.org/msg45252.html >> >> Changes: >> v2: >> - set_power callback removed (its role is passed to RUNTIME_PM), >> - changed transfer ops parameters to struct, >> - changed source location, >> - minor fixes >> >> Regards >> Andrzej >> >> --- >> drivers/gpu/drm/Kconfig| 4 + >> drivers/gpu/drm/Makefile | 2 + >> drivers/gpu/drm/drm_mipi_dsi.c | 344 >> + >> include/drm/drm_mipi_dsi.h | 154 ++ >> 4 files changed, 504 insertions(+) >> create mode 100644 drivers/gpu/drm/drm_mipi_dsi.c >> create mode 100644 include/drm/drm_mipi_dsi.h > This seems to be missing a device tree binding document. That could > probably be rather small since there's not a lot there right now. I > volunteer to draft that document if you don't have the time to do > that. > >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index f864275..58a603d 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -20,6 +20,10 @@ menuconfig DRM >>details. You should also select and configure AGP >>(/dev/agpgart) support if it is available for your platform. >> >> +config DRM_MIPI_DSI >> +tristate >> +default y > Shouldn't this remain off by default? And only be selected by drivers > that actually need it. I think that DSI host drivers could select this > symbol and DSI peripheral drivers can depend on it. That way you'll > automatically be able to only select peripheral drivers if there's at > least one DSI host driver enabled. Yes, of course. I just forgot to set it back properly after last tests. > >> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c > [...] >> +/* >> + * MIPI DSI Bus >> + * >> + * Copyright (C) 2012, Samsung Electronics, Co., Ltd. > Perhaps this should now be "2012-2013"? Yes, thanks. > >> + * Andrzej Hajda >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include > Can these please be ordered alphabetically? OK > >> +/* >> - >> + * Bus operations >> + */ > Nitpick: I'm not a huge fan of these separators. They have a tendency to > get in the way when people add new functions and then all of a sudden > they no longer fit into that category... > >> +int mipi_dsi_init(struct mipi_dsi_device *dev) >> +{ > [...] >> +} >> +EXPORT_SYMBOL_GPL(mipi_dsi_init); >> + >> +int mipi_dsi_set_stream(struct mipi_dsi_device *dev, bool on) >> +{ > [...] >> +} >> +EXPORT_SYMBOL_GPL(mipi_dsi_set_stream); > These are missing documentation. It's not clear at all what they are > supposed to do. > >> +int mipi_dsi_dcs_write(struct mipi_dsi_device *dev, int channel, const u8 >> *data, > unsigned int for channel, please. And const void * for data so that the > same type is used consistently. > >> +static struct device_attribute mipi_dsi_dev_attrs[] = { > static const? > > I also believe these now need to be done using attribute groups. Look at > commit d06262e58546 (driver-core: platform: convert bus code to use > dev_groups) for an example of how to do that. >> +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = { >> +.runtime_suspend = pm_generic_runtime_suspend, >> +.runtime_resume = pm_generic_runtime_resume, >> +.suspend = pm_generic_suspend, >> +.resume = pm_generic_resume, >> +.freeze = pm_generic_freeze, >> +.thaw = pm_generic_thaw, >> +.poweroff = pm_generic_poweroff, >> +.restore = pm_generic_restore, >> +}; >> + >> +static struct bus_type mipi_dsi_bus_type =
[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use
On Fri, Nov 22, 2013 at 05:35:54AM -0800, Keith Packard wrote: > If the application sends us a file descriptor pointing at a prime > buffer that we've already got, we have to re-use the same bo_gem > structure or chaos will result. > > Track the set of all known prime objects and look to see if the kernel > has returned one of those for a new file descriptor. > > Signed-off-by: Keith Packard > --- > > This one took a while to find -- multiple bo_gem structs pointing at > the same gem handle would either cause the object to be destroyed > before we were done using it, or we'd end up sending the same > gem_handle for multiple buffers. > > This looks a lot like the named object handling stuff, as one would > expect. Yeah, it unfortunately took a few rounds of kernel fixes and other haggling to get the semantics right on this one. The kernel atm promises to userspace (minus one big in a racy corner case no one should care about, still need to fix that one) that it'll return the same gem handle if userspace already has one for the underlying object. We need that to make sure userspace doesn't submit the same bo in execbuf multiple times and then upsets the kernel - we'll reject such batches as userspace bugs. I guess I should have reviewed userspace when doing the relevant kernel fixes, shame on me. Two questions below. > > intel/intel_bufmgr_gem.c | 22 +- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c > index df6fcec..2897bb2 100644 > --- a/intel/intel_bufmgr_gem.c > +++ b/intel/intel_bufmgr_gem.c > @@ -112,6 +112,7 @@ typedef struct _drm_intel_bufmgr_gem { > > drmMMListHead named; > drmMMListHead vma_cache; > +drmMMListHead prime; > int vma_count, vma_open, vma_max; > > uint64_t gtt_size; > @@ -2451,8 +2452,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr > *bufmgr, int prime_fd, int s > uint32_t handle; > drm_intel_bo_gem *bo_gem; > struct drm_i915_gem_get_tiling get_tiling; > + drmMMListHead *list; > > ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle); > + > + /* > + * See if the kernel has already returned this buffer to us. Just as > + * for named buffers, we must not create two bo's pointing at the same > + * kernel object > + */ > + for (list = bufmgr_gem->prime.next; > + list != &bufmgr_gem->prime; > + list = list->next) { > + bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list); > + if (bo_gem->gem_handle == handle) { > + drm_intel_gem_bo_reference(&bo_gem->bo); > + return &bo_gem->bo; > + } > + } > + > if (ret) { > fprintf(stderr,"ret is %d %d\n", ret, errno); > return NULL; > @@ -2487,8 +2505,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr > *bufmgr, int prime_fd, int s > bo_gem->has_error = false; > bo_gem->reusable = false; > > - DRMINITLISTHEAD(&bo_gem->name_list); > DRMINITLISTHEAD(&bo_gem->vma_list); > + DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime); Won't this result in us having fun when a buffer is both imported from a prime buffer and then also used with legacy flink? Or is this something the X server won't support? The second one is about exporting: With flink names we also add the name to the lookup list in drm_intel_gem_bo_flink. I think we should do the same for exported prime buffers just as a precaution - the kernel will return the (existing) gem name also for a prime buffer that has been exported by yourself. I guess that would imply insane userspace, but better safe than sorry. Cheers, Daniel > > VG_CLEAR(get_tiling); > get_tiling.handle = bo_gem->gem_handle; > @@ -3301,5 +3319,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size) > DRMINITLISTHEAD(&bufmgr_gem->vma_cache); > bufmgr_gem->vma_max = -1; /* unlimited by default */ > > + DRMINITLISTHEAD(&bufmgr_gem->prime); > + > return &bufmgr_gem->bufmgr; > } > -- > 1.8.4.3 > > ___ > mesa-dev mailing list > mesa-dev at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 65761] New: HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 Bug ID: 65761 Summary: HD 7970M Hybrid - hangs and errors and rmmod causes crash Product: Drivers Version: 2.5 Kernel Version: 3.13-rc1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: haagch.christoph at googlemail.com Regression: No Created attachment 115961 --> https://bugzilla.kernel.org/attachment.cgi?id=115961&action=edit dmesg with multiple issues 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] muxless, so there's no display outputs on the radeon gpu. With 3.13 and dpm and runtime power management enabled by default this should be getting usable. I did not start X this time. (when starting X on the intel gpu quickly after booting (presumably before radeon is initialized) the display output hangs, which is yet another problem). Dmesg seems to contain several issues. 1. While booting it already produces these before even "dpm initialized" is logged: [ 20.120137] WARNING: CPU: 0 PID: 53 at drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2e/0x30 [drm]() [ 20.120138] Memory manager not clean during takedown. 2. These are just periodically displayed in the tty: [ 79.179928] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35). [ 79.181378] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35). [ 79.182790] [drm:radeon_resume_kms] *ERROR* ib ring test failed (-35). 3. After some time in a tty, I did "rmmod radeon" and got some other issues ending with [ 192.663059] Fixing recursive fault but reboot is needed! and then, after a little while a lot of other errors happen, but they are not captured here in the dmesg. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 Mike Lothian changed: What|Removed |Added CC||mike at fireburn.co.uk --- Comment #1 from Mike Lothian --- I believe this is related to https://bugs.freedesktop.org/show_bug.cgi?id=71930 I think the memory Warnings have been fixed by either: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=c58f009e01c918717379c206a63baa66f56a77f9 or https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=0bc254257bfd9b25f64a68b719ee70a303b6d051 As a workaround you can boot with radeon.runpm=0 but that'll leave your discreet card powered up -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #2 from Mike Lothian --- I think the same issue has been reported upstream too https://bugzilla.kernel.org/show_bug.cgi?id=65761 -- 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/20131125/177cf222/attachment.html>
[Bug 65771] New: Oops after starting nouveau with NVAA / NV50 (Nvidia 8200)
https://bugzilla.kernel.org/show_bug.cgi?id=65771 Bug ID: 65771 Summary: Oops after starting nouveau with NVAA / NV50 (Nvidia 8200) Product: Drivers Version: 2.5 Kernel Version: 3.13-rc1 Hardware: i386 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: dirk.neukirchen at student.hu-berlin.de Regression: Yes Created attachment 115981 --> https://bugzilla.kernel.org/attachment.cgi?id=115981&action=edit 3.13-rc1 debug kernel log recv. via netconsole Desktop didn't come up after updating Kernel from 3.12.0 to 3.13-rc1. Screen remains black. A netconsole log showed the messages possibly responsable for the Oops: [ 11.132842] nouveau E[ CLK][:02:00.0] 17 freq unknown [ 11.132901] nouveau E[ CLK][:02:00.0] init failed, -22 [ 11.132966] nouveau E[ DRM] failed to create 0x8080, -22 [ 11.133734] nouveau: probe of :02:00.0 failed with error -22 System: - Linux Mint 15 with vanilla kernel 3.13-rc1 - dual screen -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65771] Oops after starting nouveau with NVAA / NV50 (Nvidia 8200)
https://bugzilla.kernel.org/show_bug.cgi?id=65771 --- Comment #1 from dirk.neukirchen at student.hu-berlin.de --- Created attachment 115991 --> https://bugzilla.kernel.org/attachment.cgi?id=115991&action=edit acpidump output; just in case -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65771] Oops after starting nouveau with NVAA / NV50 (Nvidia 8200)
https://bugzilla.kernel.org/show_bug.cgi?id=65771 --- Comment #2 from dirk.neukirchen at student.hu-berlin.de --- Created attachment 116001 --> https://bugzilla.kernel.org/attachment.cgi?id=116001&action=edit dmesg of successfull boot of 3.12.1 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #36 from Alex Deucher --- (In reply to comment #35) > To be noted: I was using a balanced power state this time, not a performance > power state. To be investigated. On most cards there are only performance states. Selecting balanced also selects performance. You are probably using the same state in both cases. -- 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/20131125/c0c6530f/attachment.html>
[Bug 69728] Radeon Redwood (5670) GPU Lockup
https://bugs.freedesktop.org/show_bug.cgi?id=69728 --- Comment #9 from Alex Deucher --- (In reply to comment #8) > Sorry to bump.. but this bug have became very frustating. Now watching > videos with flash cant be done without a lockup ocurring aproximately 20% of > times (with rendering relying on GPU, software decoding). With fglrx it's OK. Are you using adobe's flash player? Do you still get lockups using something other than adobe's flash player? It's known to be buggy. -- 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/20131125/004df712/attachment.html>
[Bug 71975] [regression][bisected] fast hdmi audio playback
https://bugs.freedesktop.org/show_bug.cgi?id=71975 --- Comment #1 from Alex Deucher --- Created attachment 89768 --> https://bugs.freedesktop.org/attachment.cgi?id=89768&action=edit possible fix Does this fix it? -- 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/20131125/9e90909c/attachment-0001.html>
[Bug 69728] Radeon Redwood (5670) GPU Lockup
https://bugs.freedesktop.org/show_bug.cgi?id=69728 --- Comment #10 from pablow.1422 at gmail.com --- Actually, using adobe flash 11.2 wich is the latest usable version with firefox didn't bring a lockup, only adobe version 11.9 (PPAPI) with google chrome did. Still, all the issues I had described in previous post still happens, like: Wine Games (counter strike 1.6 wich I belive is OpenGL 2.0), O AD, Xonotic causing a total system hang, after trying to reset the GPU several times (as I could see from the logs). To add, normal desktop usage (without counting the adobe flash issues) like libreoffice gpu acceleration, vdpau video player, Kwin composited, etc it's in good shape. I've also tried set env var R600_DEBUG=nohyperz; R600_DEBUG=nodma; R600_DEBUG=nosb; R600_LLVM=0 with no luck. -- 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/20131125/7ecd95c2/attachment.html>
[Bug 41375] VDPAU not working on RS880
https://bugs.freedesktop.org/show_bug.cgi?id=41375 --- Comment #8 from Alex Deucher --- (In reply to comment #7) > I'll test it when I get home tonight. I take it its software vdpau. Is it > only mpeg2 that's implemented? It's shader based decode for mpeg2. -- 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/20131125/9f9c0676/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #3 from Alex Deucher --- Does manually turning off the dGPU using switcheroo still work with radeon.runpm=0? If not, can you bisect? runpm and switcheroo use the same apci mechanism to turn off the dGPU. -- 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/20131125/79d89200/attachment.html>
[Bug 71975] [regression][bisected] fast hdmi audio playback
https://bugs.freedesktop.org/show_bug.cgi?id=71975 --- Comment #2 from Brian Paterni --- (In reply to comment #1) > Created attachment 89768 [details] [review] > possible fix > > Does this fix it? That does, audio is fine now. Thank you very much Alex! :) -- 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/20131125/f2840eb9/attachment.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #37 from Alexandre Demers --- (In reply to comment #36) > (In reply to comment #35) > > To be noted: I was using a balanced power state this time, not a performance > > power state. To be investigated. > > On most cards there are only performance states. Selecting balanced also > selects performance. You are probably using the same state in both cases. This is also what it seems. However, it may be completly unrelated, but I only had hangs when using the balanced setting. -- 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/20131125/eccdfa16/attachment.html>
[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI
On a MacBookAir2,1, booting to Linux with EFI though having no efifb built-in Xorg refuses to start with "no devices detected" because for the only VGA device available (NVidia Geforce 9400M) the sysfs attribute boot_vga is zero (instead of expected 1). When CONFIG_FB_EFI is selected, efifb does provide its own vga_default_device() to report the PCI device matching global screen_info as determined during efifb setup. Otherwise there is just a dummy or VGA_ARB's vga_default_device() that does not provide the right information. On the other hand, boot_vga_show() falls back to poking PCI resources to flag a PCI device as boot_vga if vga_default_device() returned no PCI device (NULL). To complement this PCI resource poking, this patch copies the validation code used to determine which PCI device to report as default VGA device by efifb into boot_vga_show(). Signed-off-by: Bruno Pr?mont --- Would it make sense to kill the corresponding code from efifb as it covers only a single case? The other EFI capable system I have (AMD Ilano based, Gigabyte mainboard does report boot_vga=1, possibly through the resources poking and there Xorg starts properly without efifb built in. Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does not help by itself, patching that one instead of PCI's boot_vga attribute directly would still not cover the case when neither of them is enabled. drivers/pci/pci-sysfs.c | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 7128cfd..91cac71 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include "pci.h" @@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct device_attribute *attr, char *buf) if (vga_dev) return sprintf(buf, "%u\n", (pdev == vga_dev)); + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) { + resource_size_t start, end; + int i; + + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) { + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM)) + continue; + + start = pci_resource_start(pdev, i); + end = pci_resource_end(pdev, i); + + if (!start || !end) + continue; + + if (screen_info.lfb_base >= start && + (screen_info.lfb_base + screen_info.lfb_size) < end) + return sprintf(buf, "1\n"); + } + } + return sprintf(buf, "%u\n", !!(pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW));
[Bug 65811] New: AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 Bug ID: 65811 Summary: AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering Product: Drivers Version: 2.5 Kernel Version: 3.13-rc1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: jack at cyphernaut.org Regression: No rc1 appears to have solved my issues of X not starting or crashing when starting, which I ran into when using the DRM patches on 3.12. However I've run into another issue: When I start my laptop, if I do not immediately offload rendering to the discrete Radeon card (xrandr --setprovideroffloadsink radeon Intel) the state in vgaswitcheroo will change to 'DynOff', and xrandr --listproviders will no longer report the radeon as a potentially offload source Conversely, if I *do* --setprovideroffloadsink to the radeon within a few seconds after X starts, the state in vgaswitcheroo changes to DynPwr and never actually turns off (laptop behaves as if runpm was not enabled at all). -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI
On Mon, Nov 25, 2013 at 12:54 PM, Bruno Pr?mont wrote: > On a MacBookAir2,1, booting to Linux with EFI though having > no efifb built-in Xorg refuses to start with "no devices detected" > because for the only VGA device available (NVidia Geforce 9400M) > the sysfs attribute boot_vga is zero (instead of expected 1). > > When CONFIG_FB_EFI is selected, efifb does provide its own > vga_default_device() to report the PCI device matching global > screen_info as determined during efifb setup. > > Otherwise there is just a dummy or VGA_ARB's vga_default_device() > that does not provide the right information. Wouldn't it be cleaner to fix vga_default_device() so it returns the correct thing even when CONFIG_FB_EFI=n? > On the other hand, boot_vga_show() falls back to poking PCI > resources to flag a PCI device as boot_vga if vga_default_device() > returned no PCI device (NULL). > > To complement this PCI resource poking, this patch copies the > validation code used to determine which PCI device to report as > default VGA device by efifb into boot_vga_show(). If we do have to use logic like this, I'd like it better if it were factored into a single function called both here and from efifb_setup(). > Signed-off-by: Bruno Pr?mont > --- > Would it make sense to kill the corresponding code from efifb > as it covers only a single case? > > The other EFI capable system I have (AMD Ilano based, Gigabyte > mainboard does report boot_vga=1, possibly through the resources > poking and there Xorg starts properly without efifb built in. > > Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does > not help by itself, patching that one instead of PCI's boot_vga > attribute directly would still not cover the case when neither > of them is enabled. > > > drivers/pci/pci-sysfs.c | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c > index 7128cfd..91cac71 100644 > --- a/drivers/pci/pci-sysfs.c > +++ b/drivers/pci/pci-sysfs.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > #include > #include "pci.h" > > @@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct > device_attribute *attr, char *buf) > if (vga_dev) > return sprintf(buf, "%u\n", (pdev == vga_dev)); > > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) { > + resource_size_t start, end; > + int i; > + > + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) { > + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM)) > + continue; > + > + start = pci_resource_start(pdev, i); > + end = pci_resource_end(pdev, i); > + > + if (!start || !end) > + continue; > + > + if (screen_info.lfb_base >= start && > + (screen_info.lfb_base + screen_info.lfb_size) > < end) > + return sprintf(buf, "1\n"); > + } > + } > + > return sprintf(buf, "%u\n", > !!(pdev->resource[PCI_ROM_RESOURCE].flags & >IORESOURCE_ROM_SHADOW));
[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 --- Comment #1 from Jack --- Only kernel option I have set is `radeon.runpm=1`, not sure if this is needed in 3.13 or if it even matters that I have it. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 --- Comment #2 from Jack --- 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] Linux localhost 3.13.0-1-00085-g7e3528c-dirty #1 SMP PREEMPT Sun Nov 24 17:38:54 CST 2013 x86_64 GNU/Linux xf86-video-ati-git 3103.d571d6a-1 xf86-video-intel-git 7529.b14228f-1 -- You are receiving this mail because: You are watching the assignee of the bug.
[Mesa-dev] [PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated image miptrees
Keith Packard writes: > Just copying code from the dri2 path to set up the fast color clear state. > > This also removes a couple of bogus intel_region_reference calls. These two are: Reviewed-by: Eric Anholt -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/ea340f31/attachment.pgp>
[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI
On Mon, 25 November 2013 Bjorn Helgaas wrote: > On Mon, Nov 25, 2013 at 12:54 PM, Bruno Pr?mont wrote: > > On a MacBookAir2,1, booting to Linux with EFI though having > > no efifb built-in Xorg refuses to start with "no devices detected" > > because for the only VGA device available (NVidia Geforce 9400M) > > the sysfs attribute boot_vga is zero (instead of expected 1). > > > > When CONFIG_FB_EFI is selected, efifb does provide its own > > vga_default_device() to report the PCI device matching global > > screen_info as determined during efifb setup. > > > > Otherwise there is just a dummy or VGA_ARB's vga_default_device() > > that does not provide the right information. > > Wouldn't it be cleaner to fix vga_default_device() so it returns the > correct thing even when CONFIG_FB_EFI=n? I would rather completely drop the vga_default_device() from efifb (CONFIG_FB_EFI) and just keep vga_default_device() for vga-arbitration/vga-switcheroo. The fact that there are currently *two* instances of that function doesn't make life easy for determining who is providing it and when. drivers/gpu/vga/vgaarb.c:135 drivers/video/efifb.c:88 include/linux/vgaarb.h:190 (dummy) > > On the other hand, boot_vga_show() falls back to poking PCI > > resources to flag a PCI device as boot_vga if vga_default_device() > > returned no PCI device (NULL). > > > > To complement this PCI resource poking, this patch copies the > > validation code used to determine which PCI device to report as > > default VGA device by efifb into boot_vga_show(). > > If we do have to use logic like this, I'd like it better if it were > factored into a single function called both here and from > efifb_setup(). As of above, I would preferably drop that part of code from efifb_setup() and have the logic called only in one place and each time the same way. Otherwise efifb versus x86_sysfb+simplefb or directly going to native driver (nvoueau/radeon/...) behave differently without reason. Bruno > > Signed-off-by: Bruno Pr?mont > > --- > > Would it make sense to kill the corresponding code from efifb > > as it covers only a single case? > > > > The other EFI capable system I have (AMD Ilano based, Gigabyte > > mainboard does report boot_vga=1, possibly through the resources > > poking and there Xorg starts properly without efifb built in. > > > > Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does > > not help by itself, patching that one instead of PCI's boot_vga > > attribute directly would still not cover the case when neither > > of them is enabled. > > > > > > drivers/pci/pci-sysfs.c | 21 + > > 1 file changed, 21 insertions(+) > > > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c > > index 7128cfd..91cac71 100644 > > --- a/drivers/pci/pci-sysfs.c > > +++ b/drivers/pci/pci-sysfs.c > > @@ -28,6 +28,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include "pci.h" > > > > @@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct > > device_attribute *attr, char *buf) > > if (vga_dev) > > return sprintf(buf, "%u\n", (pdev == vga_dev)); > > > > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) { > > + resource_size_t start, end; > > + int i; > > + > > + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) { > > + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM)) > > + continue; > > + > > + start = pci_resource_start(pdev, i); > > + end = pci_resource_end(pdev, i); > > + > > + if (!start || !end) > > + continue; > > + > > + if (screen_info.lfb_base >= start && > > + (screen_info.lfb_base + > > screen_info.lfb_size) < end) > > + return sprintf(buf, "1\n"); > > + } > > + } > > + > > return sprintf(buf, "%u\n", > > !!(pdev->resource[PCI_ROM_RESOURCE].flags & > >IORESOURCE_ROM_SHADOW));
[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use
Daniel Vetter writes: > Yeah, it unfortunately took a few rounds of kernel fixes and other > haggling to get the semantics right on this one. The kernel atm promises > to userspace (minus one big in a racy corner case no one should care > about, still need to fix that one) that it'll return the same gem handle > if userspace already has one for the underlying object. That's definitely something we want it to do -- returning different handles to the same object would result in madness. We just need to deal with the userspace consequences. > We need that to make sure userspace doesn't submit the same bo in execbuf > multiple times and then upsets the kernel - we'll reject such batches as > userspace bugs. Oh, I'm well aware of that; you can imagine the adventures I had trying to debug this... >> -DRMINITLISTHEAD(&bo_gem->name_list); >> DRMINITLISTHEAD(&bo_gem->vma_list); >> +DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime); > > Won't this result in us having fun when a buffer is both imported from a > prime buffer and then also used with legacy flink? Or is this something > the X server won't support? Well, the whole point of prime-based FD buffer passing is to *not* use flink, of course. However, you could use both DRI2 and DRI3 on the same pixmap (presumably through different APIs). Ok, I just tried to create a completely separate prime list for this, and I think that's wrong. If the question is whether the kernel might return the same object from two calls, then we'd best actually keep a single list and look things up for both APIs there. *and*, I think we need to do the flink->gem handle conversion and then look in the list again to see if that gem handle was already returned from another flink or prime fd. > The second one is about exporting: With flink names we also add the name > to the lookup list in drm_intel_gem_bo_flink. I think we should do the > same for exported prime buffers just as a precaution - the kernel will > return the (existing) gem name also for a prime buffer that has been > exported by yourself. I guess that would imply insane userspace, but > better safe than sorry. yeah, that would seem like crazy user-space behaviour, but user space often seems insane. Thanks for your review; replacement patch to follow shortly. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/8da762d1/attachment.pgp>
[PATCH] intel: Track known prime buffers for re-use
If the application sends us a file descriptor pointing at a prime buffer that we've already got, we have to re-use the same bo_gem structure or chaos will result. Track the set of all known prime objects and look to see if the kernel has returned one of those for a new file descriptor. Also checks for prime buffers in the flink case. Signed-off-by: Keith Packard --- intel/intel_bufmgr_gem.c | 50 +--- 1 file changed, 43 insertions(+), 7 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index df6fcec..2b7fe07 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -149,6 +149,8 @@ struct _drm_intel_bo_gem { /** * Kenel-assigned global name for this object + * + * List contains both flink named and prime fd'd objects */ unsigned int global_name; drmMMListHead name_list; @@ -862,10 +864,6 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr, } } - bo_gem = calloc(1, sizeof(*bo_gem)); - if (!bo_gem) - return NULL; - VG_CLEAR(open_arg); open_arg.name = handle; ret = drmIoctl(bufmgr_gem->fd, @@ -874,9 +872,26 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr, if (ret != 0) { DBG("Couldn't reference %s handle 0x%08x: %s\n", name, handle, strerror(errno)); - free(bo_gem); return NULL; } +/* Now see if someone has used a prime handle to get this + * object from the kernel before by looking through the list + * again for a matching gem_handle + */ + for (list = bufmgr_gem->named.next; +list != &bufmgr_gem->named; +list = list->next) { + bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list); + if (bo_gem->gem_handle == open_arg.handle) { + drm_intel_gem_bo_reference(&bo_gem->bo); + return &bo_gem->bo; + } + } + + bo_gem = calloc(1, sizeof(*bo_gem)); + if (!bo_gem) + return NULL; + bo_gem->bo.size = open_arg.size; bo_gem->bo.offset = 0; bo_gem->bo.virtual = NULL; @@ -2451,8 +2466,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr *bufmgr, int prime_fd, int s uint32_t handle; drm_intel_bo_gem *bo_gem; struct drm_i915_gem_get_tiling get_tiling; + drmMMListHead *list; ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle); + + /* +* See if the kernel has already returned this buffer to us. Just as +* for named buffers, we must not create two bo's pointing at the same +* kernel object +*/ + for (list = bufmgr_gem->named.next; +list != &bufmgr_gem->named; +list = list->next) { + bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list); + if (bo_gem->gem_handle == handle) { + drm_intel_gem_bo_reference(&bo_gem->bo); + return &bo_gem->bo; + } + } + if (ret) { fprintf(stderr,"ret is %d %d\n", ret, errno); return NULL; @@ -2487,8 +2519,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr *bufmgr, int prime_fd, int s bo_gem->has_error = false; bo_gem->reusable = false; - DRMINITLISTHEAD(&bo_gem->name_list); DRMINITLISTHEAD(&bo_gem->vma_list); + DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named); VG_CLEAR(get_tiling); get_tiling.handle = bo_gem->gem_handle; @@ -2513,6 +2545,9 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int *prime_fd) drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr; drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo; +if (DRMLISTEMPTY(&bo_gem->name_list)) +DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named); + if (drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle, DRM_CLOEXEC, prime_fd) != 0) return -errno; @@ -2542,7 +2577,8 @@ drm_intel_gem_bo_flink(drm_intel_bo *bo, uint32_t * name) bo_gem->global_name = flink.name; bo_gem->reusable = false; - DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named); +if (DRMLISTEMPTY(&bo_gem->name_list)) +DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named); } *name = bo_gem->global_name; -- 1.8.4.4
[PATCH] dri3: Support GLX_INTEL_swap_event
Keith Packard writes: > The easy part is turning on the extension, now that the X server has a patch > to send the events. > > The only trick was making sure the Present extension reliably provided the > right 'sbc' count back in the event, and that's done by making sure the sbc > count is always the same as the sequence number that we send in the > PresentPixmap requests, and that's done by using the same variable for both > roles. I'd prefer to see sbc stay with its current name, since that's its name in the specs we're trying to implement (GLX_OML_sync_control, GLX_INTEL_swap_event). If you drop the rename from the patch, Reviewed-by: Eric Anholt I think our handling of SBC for glXWaitForSbcOML() is wrong. From the OML_sync_control spec: The SBC value is incremented by the graphics driver at the completion of each buffer swap (e.g., the pixel copy has been completed or the hardware register that swaps memory banks has been written). For pixel formats that do not contain a back buffer, the SBC will always be returned as 0. I read that as "SBC is incremented when the PresentComplete comes in" not "SBC is incremented when we generate the Present request". Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm assuming they're talking a hardware register for pageflipping that immediately starts scanning out the new stuff, not our fancy new automatically double buffered ones that you have to push hard on to get an immediate pageflip mode) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/f253d181/attachment.pgp>
[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
Keith Packard writes: > The __DRIimage createImageFromFds function takes a fourcc code, but there was > no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for > that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to > __DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to > __IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers. > > I'll refrain from comments on whether I think having two separate sets of > format defines in dri_interface.h is a good idea or not... > > Signed-off-by: Keith Packard Reviewed-by: Eric Anholt I'd love to see some debug information in whatever path it was that was silently failing, if we can. It's so easy to miss places to add format support. (I see gallium doesn't use sargb images currently, but might want this in the future, plus we're still missing an equivalent change for 2101010 though I don't know if anybody's made it really work anywhere on dri2 either) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/cee0c182/attachment.pgp>
[PATCH] dri3: Support GLX_INTEL_swap_event
Eric Anholt writes: > I'd prefer to see sbc stay with its current name, since that's its name > in the specs we're trying to implement (GLX_OML_sync_control, > GLX_INTEL_swap_event). If you drop the rename from the patch, > > Reviewed-by: Eric Anholt Sounds good. > I read that as "SBC is incremented when the PresentComplete comes in" > not "SBC is incremented when we generate the Present request". > Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm > assuming they're talking a hardware register for pageflipping that > immediately starts scanning out the new stuff, not our fancy new > automatically double buffered ones that you have to push hard on to get > an immediate pageflip mode) Oh, that's almost sensible. And nicely eliminates the silly sleep(1) loop. New patches coming shortly. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/f84f590a/attachment.pgp>
[PATCH] present: Send GLX_BufferSwapComplete events from present extension
Keith Packard writes: > This allows GL to support the GLX_INTEL_swap_event extension > > Signed-off-by: Keith Packard There's a minor behavior change that the event now gets sent to the drawable owner rather than the caller of DRI2SwapBuffers. I don't expect it to matter in practice (I expect that the swap-requesting client using this GLX extension is also the drawable-creating one), and either choice seems wrong compared to "send the event to everyone listening for the event on this drawable". That would be a separate change, anyway. Reviewed-by: Eric Anholt -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/a13a5579/attachment.pgp>
[PATCH] Enable probing of non-rb modes
With the current implementation of collecting edid modes, in case rb mode exists for a non rb mode of same resolution and vrefresh, the non-rb mode is never fed to display controller to be probed, as a result we lose on using the non-rb mode, if the display controller does not support rb mode but supports non-rb. For instance in case of 1680x1050 at 60Hz: with monitor whose EDID supports RB, if connected to display controller does not support 1680x1050 at 60Hz RB but it supports 1680x1050 at 60Hz, with the current implementation the non-rb mode 1680x1050 at 60Hz is not listed in connectors probed modes and hence on running xrandr is not listed. V2: Incorporate review comments by Adam Jackson remove suffix of 'rb' Shirish S (1): drm: edid: enable probing and listing of non rb modes drivers/gpu/drm/drm_edid.c | 40 ++-- 1 file changed, 18 insertions(+), 22 deletions(-) -- 1.7.9.5
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
This patch adds dt support to hdmiphy config settings as it is board specific and depends on the signal pattern of board. Signed-off-by: Shirish S --- .../devicetree/bindings/video/exynos_hdmi.txt | 31 drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++- 2 files changed, 104 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 323983b..6eeb333 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -13,6 +13,30 @@ Required properties: b) pin number within the gpio controller. c) optional flags and pull up/down. +- hdmiphy-configs: following information about the hdmiphy config settings. + a) "config: config" specifies the phy configuration settings, + where 'N' denotes the number of configuration, since every + pixel clock can have its unique configuration. + "pixel-clock" specifies the pixel clock + "conifig-de-emphasis-level" provides fine control of TMDS data +pre emphasis, below shown is example for + data de-emphasis register at address 0x145D0040. + hdmiphy at 38[16] for bits[3:0] permitted values are in + the range of 760 mVdiff to 1400 mVdiff at 20mVdiff + increments for every LSB + hdmiphy at 38[16] for bits[7:4] permitted values are in + the range of 0dB to -7.45dB at increments of -0.45dB + for every LSB. + "config-clock-level" provides fine control of TMDS data + amplitude for each channel, + for example if 0x145D005C is the address of clock level + register then, + hdmiphy at 38[23] for bits [1:0] permitted values are in + the range of 0 mVdiff & 60 mVdiff for each channel at + increments 20 mVdiff of amplitude levels for every LSB, + hdmiphy at 38[23] for bits [7:3] permitted values are in + the range of 790 and 1430 mV at 20mV increments for + every LSB. Example: hdmi { @@ -20,4 +44,11 @@ Example: reg = <0x1453 0x10>; interrupts = <0 95 0>; hpd-gpio = <&gpx3 7 1>; + hdmiphy-configs { + config0: config0 { + pixel-clock = <2520>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + } }; diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 32ce9a6..5f599e3 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -197,6 +197,9 @@ struct hdmi_context { struct hdmi_resources res; + struct hdmiphy_config *confs; + int nr_confs; + int hpd_gpio; enum hdmi_type type; @@ -256,7 +259,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[] = { }, }; -static const struct hdmiphy_config hdmiphy_v14_configs[] = { +static struct hdmiphy_config hdmiphy_v14_configs[] = { { .pixel_clock = 2520, .conf = { @@ -785,8 +788,8 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock) confs = hdmiphy_v13_configs; count = ARRAY_SIZE(hdmiphy_v13_configs); } else if (hdata->type == HDMI_TYPE14) { - confs = hdmiphy_v14_configs; - count = ARRAY_SIZE(hdmiphy_v14_configs); + confs = hdata->confs; + count = hdata->nr_confs; } else return -EINVAL; @@ -1415,7 +1418,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata) if (hdata->type == HDMI_TYPE13) hdmiphy_data = hdmiphy_v13_configs[i].conf; else - hdmiphy_data = hdmiphy_v14_configs[i].conf; + hdmiphy_data = hdata->confs[i].conf; memcpy(buffer, hdmiphy_data, 32); ret = i2c_master_send(hdata->hdmiphy_port, buffer, 32); @@ -1894,6 +1897,63 @@ fail: return -ENODEV; } +static int drm_hdmi_dt_parse_phy_conf(struct platform_device *pdev, + struct hdmi_context *hdata) +{ + struct device *dev = &pdev->dev; + struct device_node *dev_np = dev->of_node; + struct device_node *phy_conf, *cfg_np; + int i, pixel_clock = 0; + + /* Initialize with default config */ + hdata->confs
[PATCH] drm: edid: enable probing and listing of non rb modes
The current solution checks for the existing RB mode, if available in the edid block returns by adding it, but does not populate the connector with the modes of same resolution but which are non-rb modes. As a result the probing and listing of non-rb modes can't be made, in case the rb mode's pixel clock is not supported but non-rb mode is supported. This patch changes the drm_mode_std mode selection to collect all the supported modes and not just one mode. Signed-off-by: Shirish S --- drivers/gpu/drm/drm_edid.c | 40 ++-- 1 file changed, 18 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index fb7cf0e..765aa96 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1587,12 +1587,12 @@ bad_std_timing(u8 a, u8 b) * Take the standard timing params (in this case width, aspect, and refresh) * and convert them into a real mode using CVT/GTF/DMT. */ -static struct drm_display_mode * -drm_mode_std(struct drm_connector *connector, struct edid *edid, +unsigned int drm_mode_std(struct drm_connector *connector, struct edid *edid, struct std_timing *t, int revision) { struct drm_device *dev = connector->dev; struct drm_display_mode *m, *mode = NULL; + unsigned int modes = 0; int hsize, vsize; int vrefresh_rate; unsigned aspect_ratio = (t->vfreq_aspect & EDID_TIMING_ASPECT_MASK) @@ -1602,7 +1602,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, int timing_level = standard_timing_level(edid); if (bad_std_timing(t->hsize, t->vfreq_aspect)) - return NULL; + return modes; /* According to the EDID spec, the hdisplay = hsize * 8 + 248 */ hsize = t->hsize * 8 + 248; @@ -1638,7 +1638,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, list_for_each_entry(m, &connector->probed_modes, head) if (m->hdisplay == hsize && m->vdisplay == vsize && drm_mode_vrefresh(m) == vrefresh_rate) - return NULL; + return modes; /* HDTV hack, part 2 */ if (hsize == 1366 && vsize == 768 && vrefresh_rate == 60) { @@ -1647,19 +1647,21 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, mode->hdisplay = 1366; mode->hsync_start = mode->hsync_start - 1; mode->hsync_end = mode->hsync_end - 1; - return mode; + goto done; } /* check whether it can be found in default mode table */ if (drm_monitor_supports_rb(edid)) { mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, true); - if (mode) - return mode; + if (mode) { + drm_mode_probed_add(connector, mode); + modes++; + } } mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false); if (mode) - return mode; + goto done; /* okay, generate it */ switch (timing_level) { @@ -1676,7 +1678,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, */ mode = drm_gtf_mode(dev, hsize, vsize, vrefresh_rate, 0, 0); if (!mode) - return NULL; + return modes; if (drm_mode_hsync(mode) > drm_gtf2_hbreak(edid)) { drm_mode_destroy(dev, mode); mode = drm_gtf_mode_complex(dev, hsize, vsize, @@ -1692,7 +1694,11 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, false); break; } - return mode; + +done: + drm_mode_probed_add(connector, mode); + return modes++; + } /* @@ -2174,15 +2180,10 @@ do_standard_modes(struct detailed_timing *timing, void *c) int i; for (i = 0; i < 6; i++) { struct std_timing *std; - struct drm_display_mode *newmode; std = &data->data.timings[i]; - newmode = drm_mode_std(connector, edid, std, + closure->modes += drm_mode_std(connector, edid, std, edid->revision); - if (newmode) { - drm_mode_probed_add(connector, newmode); - closure->modes++; - } } } } @@ -2203,15 +2204,10 @@ add_standard_modes(struct drm_connector *connector, struct edid *edid) }; for (i = 0; i < EDID_STD_TIMINGS; i++) { - struct drm_display_mode *newmode; - newmode = drm_mo
[PATCH 0/4] Add dt support for exynos hdmiphy settings
For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values matter,we can move the same to dt, wherein we can have different dt files for every revision. This is an initial patchset towards achieving the same for exynos 5250 and can be later extended to future chipsets. V2: replaced moving of entire phy config structure with only required and justifiable conf registers. V3: Incorporated Mark Rutland's comments. V4: Rebased and included cros5250-common.dtsi. V5: removed nr-configs feild and also the constraint of having the exact number of configs in the dt file as in the driver, the programmer can add only the pixel clock that needs to be updated. V6: V7: removed nr-configs form the dtsi files. Shirish S (4): ARM: dts: smdk5250: Add hdmi phy settings ARM: dts: arndale: Add hdmi phy settings ARM: exynos: dts: cros5250: Add hdmi phy settings drm: exynos: hdmi: Add dt support for hdmiphy settings .../devicetree/bindings/video/exynos_hdmi.txt | 31 arch/arm/boot/dts/cros5250-common.dtsi | 74 +++ arch/arm/boot/dts/exynos5250-arndale.dts | 74 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++- 5 files changed, 326 insertions(+), 4 deletions(-) -- 1.7.9.5
[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings
This patch moves the hdmi phy setting to smdk5250 dts,as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 + 1 file changed, 74 insertions(+) diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts index 2538b32..96e2cad 100644 --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts @@ -220,6 +220,80 @@ hdmi { hpd-gpio = <&gpx3 7 0>; + hdmiphy-configs { + /* + * Eye diagram test passed for: + * Data de-emphasis: -0.7dB & Data Level: 880mV + * i.e., 0010 0110 = 0x26 + * and Clock level of 515mV and diff 1030mV + * i.e., 0x66 + */ + config0: config0 { + pixel-clock = <2520>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config1: config1 { + pixel-clock = <2700>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config2: config2 { + pixel-clock = <27027000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config3: config3 { + pixel-clock = <3600>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config4: config4 { + pixel-clock = <4000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config5: config5 { + pixel-clock = <6500>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config6: config6 { + pixel-clock = <74176000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config7: config7 { + pixel-clock = <7425>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config8: config8 { + pixel-clock = <8350>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config9: config9 { + pixel-clock = <10650>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config10: config10 { + pixel-clock = <10800>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config11: config11 { + pixel-clock = <14625>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config12: config12 { + pixel-clock = <14850>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + }; }; codec at 1100 { -- 1.7.9.5
[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/cros5250-common.dtsi | 74 1 file changed, 74 insertions(+) diff --git a/arch/arm/boot/dts/cros5250-common.dtsi b/arch/arm/boot/dts/cros5250-common.dtsi index dc259e8b..77408c6 100644 --- a/arch/arm/boot/dts/cros5250-common.dtsi +++ b/arch/arm/boot/dts/cros5250-common.dtsi @@ -301,6 +301,80 @@ hdmi { hpd-gpio = <&gpx3 7 0>; + hdmiphy-configs { + /* + * Eye diagram test passed for: + * Data de-emphasis: -0.7dB & Data Level: 880mV + * i.e., 0010 0110 = 0x26 + * and Clock level of 515mV and diff 1030mV + * i.e., 0x66 + */ + config0: config0 { + pixel-clock = <2520>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config1: config1 { + pixel-clock = <2700>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config2: config2 { + pixel-clock = <27027000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config3: config3 { + pixel-clock = <3600>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config4: config4 { + pixel-clock = <4000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config5: config5 { + pixel-clock = <6500>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config6: config6 { + pixel-clock = <74176000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config7: config7 { + pixel-clock = <7425>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config8: config8 { + pixel-clock = <8350>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config9: config9 { + pixel-clock = <10650>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config10: config10 { + pixel-clock = <10800>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config11: config11 { + pixel-clock = <14625>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config12: config12 { + pixel-clock = <14850>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + }; }; gpio-keys { -- 1.7.9.5
[PATCH] drm: edid: enable probing and listing of non rb modes
The current solution checks for the existing RB mode, if available in the edid block returns by adding it, but does not populate the connector with the modes of same resolution but which are non-rb modes. As a result the probing and listing of non-rb modes can't be made, in case the rb mode's pixel clock is not supported but non-rb mode is supported. This patch changes the drm_mode_std mode selection to collect all the supported modes and not just one mode. Signed-off-by: Shirish S --- drivers/gpu/drm/drm_edid.c | 40 ++-- 1 file changed, 18 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index fb7cf0e..765aa96 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1587,12 +1587,12 @@ bad_std_timing(u8 a, u8 b) * Take the standard timing params (in this case width, aspect, and refresh) * and convert them into a real mode using CVT/GTF/DMT. */ -static struct drm_display_mode * -drm_mode_std(struct drm_connector *connector, struct edid *edid, +unsigned int drm_mode_std(struct drm_connector *connector, struct edid *edid, struct std_timing *t, int revision) { struct drm_device *dev = connector->dev; struct drm_display_mode *m, *mode = NULL; + unsigned int modes = 0; int hsize, vsize; int vrefresh_rate; unsigned aspect_ratio = (t->vfreq_aspect & EDID_TIMING_ASPECT_MASK) @@ -1602,7 +1602,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, int timing_level = standard_timing_level(edid); if (bad_std_timing(t->hsize, t->vfreq_aspect)) - return NULL; + return modes; /* According to the EDID spec, the hdisplay = hsize * 8 + 248 */ hsize = t->hsize * 8 + 248; @@ -1638,7 +1638,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, list_for_each_entry(m, &connector->probed_modes, head) if (m->hdisplay == hsize && m->vdisplay == vsize && drm_mode_vrefresh(m) == vrefresh_rate) - return NULL; + return modes; /* HDTV hack, part 2 */ if (hsize == 1366 && vsize == 768 && vrefresh_rate == 60) { @@ -1647,19 +1647,21 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, mode->hdisplay = 1366; mode->hsync_start = mode->hsync_start - 1; mode->hsync_end = mode->hsync_end - 1; - return mode; + goto done; } /* check whether it can be found in default mode table */ if (drm_monitor_supports_rb(edid)) { mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, true); - if (mode) - return mode; + if (mode) { + drm_mode_probed_add(connector, mode); + modes++; + } } mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false); if (mode) - return mode; + goto done; /* okay, generate it */ switch (timing_level) { @@ -1676,7 +1678,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, */ mode = drm_gtf_mode(dev, hsize, vsize, vrefresh_rate, 0, 0); if (!mode) - return NULL; + return modes; if (drm_mode_hsync(mode) > drm_gtf2_hbreak(edid)) { drm_mode_destroy(dev, mode); mode = drm_gtf_mode_complex(dev, hsize, vsize, @@ -1692,7 +1694,11 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, false); break; } - return mode; + +done: + drm_mode_probed_add(connector, mode); + return modes++; + } /* @@ -2174,15 +2180,10 @@ do_standard_modes(struct detailed_timing *timing, void *c) int i; for (i = 0; i < 6; i++) { struct std_timing *std; - struct drm_display_mode *newmode; std = &data->data.timings[i]; - newmode = drm_mode_std(connector, edid, std, + closure->modes += drm_mode_std(connector, edid, std, edid->revision); - if (newmode) { - drm_mode_probed_add(connector, newmode); - closure->modes++; - } } } } @@ -2203,15 +2204,10 @@ add_standard_modes(struct drm_connector *connector, struct edid *edid) }; for (i = 0; i < EDID_STD_TIMINGS; i++) { - struct drm_display_mode *newmode; - newmode = drm_mo
[PATCH 3.5 13/78] drm: Prevent overwriting from userspace underallocating core ioctl structs
3.5.7.26 -stable review patch. If anyone has any objections, please let me know. -- From: Chris Wilson commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream. Apply the protections from commit 1b2f1489633888d4a06028315dc19d65768a1c05 Author: Dave Airlie Date: Sat Aug 14 20:20:34 2010 +1000 drm: block userspace under allocating buffer and having drivers overwrite it (v2) to the core ioctl structs as well, for we found one instance where there is a 32-/64-bit size mismatch and were guilty of writing beyond the end of the user's buffer. Signed-off-by: Chris Wilson Cc: Dave Airlie Reviewed-by: Ville Syrj?l? Cc: dri-devel at lists.freedesktop.org Signed-off-by: Dave Airlie [ luis: backported to 3.5: adjusted context ] Signed-off-by: Luis Henriques --- drivers/gpu/drm/drm_drv.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 8a9d079..df54da9 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -422,9 +422,16 @@ long drm_ioctl(struct file *filp, asize = drv_size; } else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) { + u32 drv_size; + ioctl = &drm_ioctls[nr]; - cmd = ioctl->cmd; + + drv_size = _IOC_SIZE(ioctl->cmd); usize = asize = _IOC_SIZE(cmd); + if (drv_size > asize) + asize = drv_size; + + cmd = ioctl->cmd; } else goto err_i1; -- 1.8.3.2
[PATCH 3.5 14/78] drm: Pad drm_mode_get_connector to 64-bit boundary
3.5.7.26 -stable review patch. If anyone has any objections, please let me know. -- From: Chris Wilson commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream. Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting the 4 bytes beyond the end of its structure with a 32-bit userspace running on a 64-bit kernel. This is due to the padding gcc inserts as the drm_mode_get_connector struct includes a u64 and its size is not a natural multiple of u64s. 64-bit kernel: sizeof(drm_mode_get_connector)=80, alignof=8 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 32-bit userspace: sizeof(drm_mode_get_connector)=76, alignof=4 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 Fortuituously we can insert explicit padding to the tail of our structures without breaking ABI. Reported-by: Pavel Roskin Signed-off-by: Chris Wilson Cc: Dave Airlie Cc: dri-devel at lists.freedesktop.org Signed-off-by: Dave Airlie [ luis: backported to 3.5: - file rename: include/uapi/drm/drm_mode.h -> include/drm/drm_mode.h ] Signed-off-by: Luis Henriques --- include/drm/drm_mode.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h index 3d6301b..f604a1a 100644 --- a/include/drm/drm_mode.h +++ b/include/drm/drm_mode.h @@ -223,6 +223,8 @@ struct drm_mode_get_connector { __u32 connection; __u32 mm_width, mm_height; /**< HxW in millimeters */ __u32 subpixel; + + __u32 pad; }; #define DRM_MODE_PROP_PENDING (1<<0) -- 1.8.3.2
kernel BUG at drivers/gpu/drm/drm_crtc.c:3112!
it bisect good 7e3528c3660a2e8602abc7858b0994d611f74bc3 # 19:49 60+ 0 slab.h: remove duplicate kmalloc declaration and fix kernel-doc warnings git bisect good a05e9dfb656cd9184443f2e807c9c53c13a3815d # 20:03 60+ 0 Add linux-next specific files for 20131125 --yliu -- next part -- [0.00] Linux version 3.12.0-00831-g4bd863f (kbuild at roam) (gcc version 4.8.1 (Debian 4.8.1-8) ) #71 SMP PREEMPT Sat Nov 23 00:19:39 CST 2013 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable [0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] debug: ignoring loglevel setting. [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011 [0.00] Hypervisor detected: KVM [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x100 [0.00] Scan for SMP in [mem 0x-0x03ff] [0.00] Scan for SMP in [mem 0x0009fc00-0x0009] [0.00] Scan for SMP in [mem 0x000f-0x000f] [0.00] found SMP MP-table at [mem 0x000fdac0-0x000fdacf] mapped at [c00fdac0] [0.00] mpc: fdad0-fdbec [0.00] initial memory mapped: [mem 0x-0x02df] [0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] init_memory_mapping: [mem 0x0e40-0x0e5f] [0.00] [mem 0x0e40-0x0e5f] page 2M [0.00] init_memory_mapping: [mem 0x0c00-0x0e3f] [0.00] [mem 0x0c00-0x0e3f] page 2M [0.00] init_memory_mapping: [mem 0x0010-0x0bff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x0bff] page 2M [0.00] init_memory_mapping: [mem 0x0e60-0x0fffdfff] [0.00] [mem 0x0e60-0x0fdf] page 2M [0.00] [mem 0x0fe0-0x0fffdfff] page 4k [0.00] BRK [0x0281, 0x02810fff] PGTABLE [0.00] cma: CMA: reserved 16 MiB at 0d40 [0.00] log_buf_len: 8388608 [0.00] early log buf free: 128628(98%) [0.00] RAMDISK: [mem 0x0e73f000-0x0ffe] [0.00] ACPI: RSDP 000fd930 00014 (v00 BOCHS ) [0.00] ACPI: RSDT 0fffe450 00034 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.00] ACPI: FACP 0f80 00074 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.00] ACPI: DSDT 0fffe490 011A9 (v01 BXPC BXDSDT 0001 INTL 20100528) [0.00] ACPI: FACS 0f40 00040 [0.00] ACPI: SSDT 07a0 00796 (v01 BOCHS BXPCSSDT 0001 BXPC 0001) [0.00] ACPI: APIC 0680 00080 (v01 BOCHS BXPCAPIC 0001 BXPC 0001) [0.00] ACPI: HPET 0640 00038 (v01 BOCHS BXPCHPET 0001 BXPC 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] mapped APIC to b000 (fee0) [0.00] 0MB HIGHMEM available. [0.00] 255MB LOWMEM available. [0.00] mapped low ram: 0 - 0fffe000 [0.00] low ram: 0 - 0fffe000 [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [0.00] kvm-clock: cpu 0, msr 0:fffd001, boot clock [0.00] BRK [0x02811000, 0x02811fff] PGTABLE [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] Normal [mem 0x0100-0x0fffdfff] [0.00] HighMem empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009efff] [0.00] node 0: [mem 0x0010-0x0fffdfff] [0.00] On node 0 totalpages: 65436 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3998 pages, LIFO batch:0 [0.00] Normal zone: 480 pages used for memmap [0.00] Normal zone: 61438 pages, LIFO batch:15 [0.00] Using APIC driver default [0.00] ACPI: PM-Timer IO Port: 0xb008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] mapped APIC to b000 (fee0) [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [0.00]
[PATCH 1/2] drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
On Fri, Nov 22, 2013 at 09:52:00PM -0800, Guenter Roeck wrote: > Simplify the code and fix race condition seen because > attribute files were created after hwmon device registration. > > Signed-off-by: Guenter Roeck > --- > Compile tested only; unfortunately I don't have the the necessary hardware. > Update: Tested working on actual hardware. Guenter
[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-arndale.dts | 74 ++ 1 file changed, 74 insertions(+) diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts index cee55fa..48b00f7 100644 --- a/arch/arm/boot/dts/exynos5250-arndale.dts +++ b/arch/arm/boot/dts/exynos5250-arndale.dts @@ -475,6 +475,80 @@ vdd_osc-supply = <&ldo10_reg>; vdd_pll-supply = <&ldo8_reg>; vdd-supply = <&ldo8_reg>; + hdmiphy-configs { + /* + * Eye diagram test passed for: + * Data de-emphasis: -0.7dB & Data Level: 880mV + * i.e., 0010 0110 = 0x26 + * and Clock level of 515mV and diff 1030mV + * i.e., 0x66 + */ + config0: config0 { + pixel-clock = <2520>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config1: config1 { + pixel-clock = <2700>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config2: config2 { + pixel-clock = <27027000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config3: config3 { + pixel-clock = <3600>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config4: config4 { + pixel-clock = <4000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config5: config5 { + pixel-clock = <6500>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config6: config6 { + pixel-clock = <74176000>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config7: config7 { + pixel-clock = <7425>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config8: config8 { + pixel-clock = <8350>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config9: config9 { + pixel-clock = <10650>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config10: config10 { + pixel-clock = <10800>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config11: config11 { + pixel-clock = <14625>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + config12: config12 { + pixel-clock = <14850>; + config-de-emphasis-level = /bits/ 8 <0x26>; + config-clock-level = /bits/ 8 < 0x66>; + }; + }; }; regulators { -- 1.7.9.5
[PATCH] drm/radeon: Disable writeback by default on ppc
On 11/24/2013 09:15 PM, Benjamin Herrenschmidt wrote: > On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote: >> On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote: >>> On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote: >>> Weird. I wonder if there is an issue with cache snoops on PPC. We currently use the gart in cached mode (GPU snoops CPU cache) with cached pages. I wonder if we need to use uncached pages on PPC. >>> There is no such issue and no known bugs with DMA writes on those >>> PCIe host bridges (and they do get hammered pretty bad here). >>> >>> This needs further investigation by the lab/hw guys to find out what's >>> actually happening on the bus and the host bridge. >>> >>> Thadeu, Kleber: Jerome suggested writing a test case in userspace that >>> continuously writes to a spare scratch register (thus triggering the >>> corresponding writeback DMA) and checks the memory location to compare >>> the writeback value (using a debugfs file for example, or mmap). >>> >> I can look into that. > Any news ? Only now I've got the bandwidth to actually take a look at this. I will start to write some code and let you guys know of the results. Thanks, Kleber > > Ben. > >> Thanks, >> >> Kleber >> >>> Can you guys do something like that ? Then we need the analyzer on >>> and/or the lab guys to look at the fabric trace & PHB trace. >>> >>> Ben. >>> >>> >> > -- Kleber Sacilotto de Souza IBM Linux Technology Center
[PATCH] present: Send GLX_BufferSwapComplete events from present extension
Eric Anholt writes: > There's a minor behavior change that the event now gets sent to the > drawable owner rather than the caller of DRI2SwapBuffers. Yeah, probably not ideal, especially when the GLX drawable is created using the window XID (as is the case for some older GLX clients). I don't have the original client at the time the event is generated, but I think I can go back and stick it in; will require tracking when the client exits, of course. > I don't expect it to matter in practice (I expect that the > swap-requesting client using this GLX extension is also the > drawable-creating one), and either choice seems wrong compared to "send > the event to everyone listening for the event on this drawable". That > would be a separate change, anyway. I think the original behaviour, sending the event to the client who sent the PresentPixmap request is the only sane plan, and only a bit more complicated than sending it to the drawable owner. I'll cook up an alternate patch and send that along; we can then compare the two approaches at least. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/64285d3b/attachment-0001.pgp>
[PATCH 0/4] Clean up dri3 SBC handling, enable GLX_INTEL_swap_event
I've split the GLX_INTEL_swap_event enabling patch into four bits -- the first three just fix the existing code to track SBC values correctly and to fix wait_for_sbc. The fourth is the trivial patch to actually turn on the new extension; all of the hard work for that is actually dealt with in the X server. [PATCH 1/4] dri3: Clean up struct dri3_drawable Trivial struct member cleanup -- a couple of unused fields, and one oddly placed field. [PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just This switches all of the internal SBC tracking to use 64-bit values. I use uint64_t because I don't trust compilers with signed integer comparisons that may wrap any more. [PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of This one makes wait_for_sbc actually wait for the completion of the specified swap, rather than the queuing of that value. Makes *far* more sense this way. [PATCH 4/4] dri3: Enable GLX_INTEL_swap_event The trivial patch that just adds the extension to the list. -keith
[PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of requested SBC
Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC had been completed, which means to wait until the PresentCompleteNotify event for that SBC had been received. This replaces the simple sleep(1) loop (which was bogus) with a loop that just checks to see if we've seen the specified SBC value come back in a PresentCompleteNotify event yet. The change is a bit larger than that as I've broken out a piece of common code to wait for and process a single Present event for the target drawable. Signed-off-by: Keith Packard --- src/glx/dri3_glx.c | 55 ++ 1 file changed, 39 insertions(+), 16 deletions(-) diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c index c0915f2..da3f08b 100644 --- a/src/glx/dri3_glx.c +++ b/src/glx/dri3_glx.c @@ -397,14 +397,33 @@ dri3_handle_present_event(struct dri3_drawable *priv, xcb_present_generic_event_ free(ge); } +static bool +dri3_wait_for_event(__GLXDRIdrawable *pdraw) +{ + xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy); + struct dri3_drawable *priv = (struct dri3_drawable *) pdraw; + xcb_generic_event_t *ev; + xcb_present_generic_event_t *ge; + + ev = xcb_wait_for_special_event(c, priv->special_event); + if (!ev) + return false; + ge = (void *) ev; + dri3_handle_present_event(priv, ge); + return true; +} + +/** dri3_wait_for_msc + * + * Get the X server to send an event when the target msc/divisor/remainder is + * reached. + */ static int dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc) { xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy); struct dri3_drawable *priv = (struct dri3_drawable *) pdraw; - xcb_generic_event_t *ev; - xcb_present_generic_event_t *ge; uint32_t msc_serial; /* Ask for the an event for the target MSC */ @@ -421,11 +440,8 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, /* Wait for the event */ if (priv->special_event) { while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) { - ev = xcb_wait_for_special_event(c, priv->special_event); - if (!ev) -break; - ge = (void *) ev; - dri3_handle_present_event(priv, ge); + if (!dri3_wait_for_event(pdraw)) +return 0; } } @@ -436,6 +452,11 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, return 1; } +/** dri3_drawable_get_msc + * + * Return the current UST/MSC/SBC triplet by asking the server + * for an event + */ static int dri3_drawable_get_msc(struct glx_screen *psc, __GLXDRIdrawable *pdraw, int64_t *ust, int64_t *msc, int64_t *sbc) @@ -445,12 +466,9 @@ dri3_drawable_get_msc(struct glx_screen *psc, __GLXDRIdrawable *pdraw, /** dri3_wait_for_sbc * - * Wait for the swap buffer count to increase. The only way this - * can happen is if some other thread is doing swap buffers as - * we no longer share swap buffer counts with other processes. - * - * I'm not sure this is actually useful as such, and so this - * implementation is a kludge that just polls once a second + * Wait for the completed swap buffer count to reach the specified + * target. Presumably the application knows that this will be reached with + * outstanding complete events, or we're going to be here awhile. */ static int dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust, @@ -458,10 +476,15 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust, { struct dri3_drawable *priv = (struct dri3_drawable *) pdraw; - while (priv->send_sbc < target_sbc) { - sleep(1); + while (priv->recv_sbc < target_sbc) { + if (!dri3_wait_for_event(pdraw)) + return 0; } - return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc); + + *ust = priv->ust; + *msc = priv->msc; + *sbc = priv->recv_sbc; + return 1; } /** -- 1.8.4.4
[PATCH 1/4] dri3: Clean up struct dri3_drawable
Move the depth field up with width and height. Remove unused previous_time and frames fields. Signed-off-by: Keith Packard --- src/glx/dri3_priv.h | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h index 05f66cf..34c67a6 100644 --- a/src/glx/dri3_priv.h +++ b/src/glx/dri3_priv.h @@ -177,7 +177,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type) struct dri3_drawable { __GLXDRIdrawable base; __DRIdrawable *driDrawable; - int width, height; + int width, height, depth; int swap_interval; uint8_t have_back; uint8_t have_fake_front; @@ -193,13 +193,9 @@ struct dri3_drawable { /* For WaitMSC */ uint32_t present_msc_request_serial; uint32_t present_msc_event_serial; - - uint64_t previous_time; - unsigned frames; struct dri3_buffer *buffers[DRI3_NUM_BUFFERS]; int cur_back; - int depth; uint32_t *stamp; -- 1.8.4.4
[PATCH 4/4] dri3: Enable GLX_INTEL_swap_event
Now that we're tracking SBC values correctly, and the X server has the ability to send the GLX swap events from a PresentPixmap request, enable this extension. Signed-off-by: Keith Packard --- src/glx/dri3_glx.c | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c index da3f08b..aa5dd21 100644 --- a/src/glx/dri3_glx.c +++ b/src/glx/dri3_glx.c @@ -1525,23 +1525,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct glx_display * priv, __glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control"); __glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control"); __glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read"); - - /* -* GLX_INTEL_swap_event is broken on the server side, where it's -* currently unconditionally enabled. This completely breaks -* systems running on drivers which don't support that extension. -* There's no way to test for its presence on this side, so instead -* of disabling it unconditionally, just disable it for drivers -* which are known to not support it, or for DDX drivers supporting -* only an older (pre-ScheduleSwap) version of DRI2. -* -* This is a hack which is required until: -* http://lists.x.org/archives/xorg-devel/2013-February/035449.html -* is merged and updated xserver makes it's way into distros: -*/ -// if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) { -// __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event"); -// } + __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event"); mask = psc->image_driver->getAPIMask(psc->driScreen); -- 1.8.4.4
[PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just 32-bits
Tracking the full 64-bit SBC values makes it clearer how those values are being used, and simplifies the wait_msc code. The only trick is in re-constructing the full 64-bit value from Present's 32-bit serial number that we use to pass the SBC value from request to event. Signed-off-by: Keith Packard --- src/glx/dri3_glx.c | 34 +- src/glx/dri3_priv.h | 16 +--- 2 files changed, 30 insertions(+), 20 deletions(-) diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c index 669f0bb..c0915f2 100644 --- a/src/glx/dri3_glx.c +++ b/src/glx/dri3_glx.c @@ -364,10 +364,17 @@ dri3_handle_present_event(struct dri3_drawable *priv, xcb_present_generic_event_ case XCB_PRESENT_COMPLETE_NOTIFY: { xcb_present_complete_notify_event_t *ce = (void *) ge; - if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) - priv->present_event_serial = ce->serial; - else - priv->present_msc_event_serial = ce->serial; + /* Compute the processed SBC number from the received 32-bit serial number merged + * with the upper 32-bits of the sent 64-bit serial number while checking for + * wrap + */ + if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) { + priv->recv_sbc = (priv->send_sbc & 0xLL) | ce->serial; + if (priv->recv_sbc > priv->send_sbc) +priv->recv_sbc -= 0x1; + } else { + priv->recv_msc_serial = ce->serial; + } priv->ust = ce->ust; priv->msc = ce->msc; break; @@ -398,12 +405,13 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, struct dri3_drawable *priv = (struct dri3_drawable *) pdraw; xcb_generic_event_t *ev; xcb_present_generic_event_t *ge; + uint32_t msc_serial; /* Ask for the an event for the target MSC */ - ++priv->present_msc_request_serial; + msc_serial = ++priv->send_msc_serial; xcb_present_notify_msc(c, priv->base.xDrawable, - priv->present_msc_request_serial, + msc_serial, target_msc, divisor, remainder); @@ -412,7 +420,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, /* Wait for the event */ if (priv->special_event) { - while (priv->present_msc_request_serial != priv->present_msc_event_serial) { + while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) { ev = xcb_wait_for_special_event(c, priv->special_event); if (!ev) break; @@ -423,7 +431,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, *ust = priv->ust; *msc = priv->msc; - *sbc = priv->sbc; + *sbc = priv->recv_sbc; return 1; } @@ -450,7 +458,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust, { struct dri3_drawable *priv = (struct dri3_drawable *) pdraw; - while (priv->sbc < target_sbc) { + while (priv->send_sbc < target_sbc) { sleep(1); } return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc); @@ -1282,15 +1290,15 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, /* Compute when we want the frame shown by taking the last known successful * MSC and adding in a swap interval for each outstanding swap request */ - ++priv->present_request_serial; + ++priv->send_sbc; if (target_msc == 0) - target_msc = priv->msc + priv->swap_interval * (priv->present_request_serial - priv->present_event_serial); + target_msc = priv->msc + priv->swap_interval * (priv->send_sbc - priv->recv_sbc); priv->buffers[buf_id]->busy = 1; xcb_present_pixmap(c, priv->base.xDrawable, priv->buffers[buf_id]->pixmap, - priv->present_request_serial, + (uint32_t) priv->send_sbc, 0,/* valid */ 0,/* update */ 0,/* x_off */ @@ -1302,7 +1310,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor, target_msc, divisor, remainder, 0, NULL); - ret = ++priv->sbc; + ret = (int64_t) priv->send_sbc; /* If there's a fake front, then copy the source back buffer * to the fake front to keep it up to date. This needs diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h index 34c67a6..f1fec3c 100644 --- a/src/glx/dri3_priv.h +++ b/src/glx/dri3_priv.h @@ -183,16 +183,18 @@ struct dri3_drawable { uint8_t have_fake_front; uint8_t is_pixmap; - uint32_t present_request_serial; - uint32_