[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 Alex Deucher changed: What|Removed |Added Attachment #55401|application/octet-stream|text/plain mime type|| Attachment #55401|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43858] DVI of ATI RADEON 9200 AGP don't work
https://bugs.freedesktop.org/show_bug.cgi?id=43858 --- Comment #4 from Alex Deucher 2012-01-10 13:53:35 PST --- According to your xorg log, you are trying to drive two 1920x1080 monitors. That is a lot of bandwidth for an r2xx GPU to drive. Try only attaching one monitor. I suspect the memory controller cannot keep up with the requests for two large monitors and the 3D engine, and when you get underflow, you get the blinking. Does it work ok with only one monitor (xrandr --output VGA-0 --off)? How about a different mode? Try 1024x768 or 1280x800, etc. You can also try a different modeline for 1920x1080. try: Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 +hsync -vsync for example. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43858] DVI of ATI RADEON 9200 AGP don't work
https://bugs.freedesktop.org/show_bug.cgi?id=43858 Alex Deucher changed: What|Removed |Added Attachment #54464|text/x-log |text/plain mime type|| Attachment #54464|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #12 from lonefox at kapsi.fi 2012-01-10 13:38:34 PST --- Created attachment 55401 --> https://bugs.freedesktop.org/attachment.cgi?id=55401 Xorg log I don't think Xorg log is relevant here, but since you asked one, I'm attaching it anyway. This is from working system. The bug happens when the console switches from text mode to graphics mode during boot, so I cannot startx or even log in except with ssh. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #11 from lonefox at kapsi.fi 2012-01-10 13:32:37 PST --- Created attachment 55400 --> https://bugs.freedesktop.org/attachment.cgi?id=55400 dmesg/system log I deleted the buggy kernels already, but here is the system log from a boot with one. It should have full dmesg output in it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #10 from Alex Deucher 2012-01-10 12:51:52 PST --- (In reply to comment #9) > These patches may fix some systems, but they also cause a similar problem on > my > HP ProBook 6465b (A6-3410MX processor with built-in GPU). There is also > someone > else with the same issue on different ProBook model: > http://forums.gentoo.org/viewtopic-t-908460.html > Reverting the patch from comment #6 fixes it at least for me. Please attach your xorg log and dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 lonefox at kapsi.fi changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #9 from lonefox at kapsi.fi 2012-01-10 12:45:58 PST --- These patches may fix some systems, but they also cause a similar problem on my HP ProBook 6465b (A6-3410MX processor with built-in GPU). There is also someone else with the same issue on different ProBook model: http://forums.gentoo.org/viewtopic-t-908460.html Reverting the patch from comment #6 fixes it at least for me. Either way, it is bad for Zathras. :-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
2012/1/10 InKi Dae : > 2012/1/10 Semwal, Sumit : >> On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote: >>> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote: 2012/1/10 Rob Clark : at least with no IOMMU, the memory information(containing physical memory address) would be copied to vb2_xx_buf object if drm gem exported its own buffer and vb2 wants to use that buffer at this time, sg table is used to share that buffer. and the problem I pointed out is that this buffer(also physical memory region) could be released by vb2 framework(as you know, vb2_xx_buf object and the memory region for buf->dma_addr pointing) but the Exporter(drm gem) couldn't know that so some problems would be induced once drm gem tries to release or access that buffer. and I have tried to resolve this issue adding get_shared_cnt() callback to dma-buf.h but I'm not sure that this is good way. maybe there would be better way. >> Hi Inki, >> As also mentioned in the documentation patch, importer (the user of >> the buffer) - in this case for current RFC patches on >> v4l2-as-a-user[1] vb2 framework - shouldn't release the backing memory >> of the buffer directly - it should only use the dma-buf callbacks in >> the right sequence to let the exporter know that it is done using this >> buffer, so the exporter can release it if allowed and needed. > > thank you for your comments.:) and below are some tables about dmabuf > operations with ideal use and these tables indicate reference count of > when buffer is created, shared and released. so if there are any > problems, please let me know. P.S. these are just simple cases so > there would be others. > > > in case of using only drm gem and dmabuf, > > operations ? ? ? ? ? ? ? ? ? ? ? gem refcount ? ?file f_count ? buf refcount > > 1. gem create ? ? ? ? ? ? ? ? ? A:1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? A:0 > 2. export(handle A -> fd) ? ?A:2 ? ? ? ? ? ? ? ?A:1 ? ? ? ? ? ? ?A:0 > 3. import(fd -> handle B) ? ?A:2, B:1 ? ? ? ? A:2 ? ? ? ? ? ? ?A:1 > 4. file close(A) ? ? ? ? ? ? ? ? ?A:2, B:1 ? ? ? ? A:1 ? ? ? ? ? ? ?A:1 > 5. gem close(A) ? ? ? ? ? ? ? ?A:1, B:1 ? ? ? ? A:1 ? ? ? ? ? ? ?A:1 > 6. gem close(B) ? ? ? ? ? ? ? ?A:1, B:0 ? ? ? ? A:1 ? ? ? ? ? ? ?A:0 > 7. file close(A) ? ? ? ? ? ? ? ? ?A:0 ? ? ? ? ? ? ? ?A:0 > --- > 3. handle B shares the buf of handle A. > 6. release handle B but its buf. > 7. release gem handle A and dmabuf of file A and also physical memory region. > > > and in case of using drm gem, vb2 and dmabuf, > > operations ? ? ? ? ? ? ? ? ?gem, vb2 refcount ? ?file f_count ? buf refcount > > 1. gem create ? ? ? ? ? ? ? ? ? A:1 ? ? ? ? ? ? ? ? A:0 > ? (GEM side) > 2. export(handle A -> fd) ? ?A:2 ? ? ? ? ? ? ? ? A:1 ? ? ? ? ? ? ?A:0 > ? (GEM side) > 3. import(fd -> handle B) ? ?A:2, B:1 ? ? ? ? ?A:2 ? ? ? ? ? ? ?A:1 > ? (VB2 side) > 4. file close(A) ? ? ? ? ? ? ? ? ?A:2, B:1 ? ? ? ? ?A:1 ? ? ? ? ? ? ?A:1 > ? (VB2 side) > 5. vb2 close(B) ? ? ? ? ? ? ? ? A:2, B:0 ? ? ? ? ?A:1 ? ? ? ? ? ? ?A:0 > ? (VB2 side) > 6. gem close(A) ? ? ? ? ? ? ? ?A:1 ? ? ? ? ? ? ? ?A:1 ? ? ? ? ? ? ?A:0 > ? (GEM side) > 7. file close(A) ? ? ? ? ? ? ? ? ?A:0 ? ? ? ? ? ? ? ?A:0 > ? (GEM side) > > 3. vb2 handle B is shared with the buf of gem handle A. > 5. release vb2 handle B and decrease refcount of the buf pointed by it. > 7. release gem handle A and dmabuf of file A and also physical memory region. > Ah, sorry, it seems that file close shouldn't be called because file->f_count of the file would be dropped by Importer and if f_count is 0 then the file would be released by fput() so I'm not sure but again: in case of using only drm gem and dmabuf, operations gem refcount file f_count buf refcount -- 1. gem create(A) A:1 A:0 2. export(handle A -> fd)A:2 A:1 A:0 3. import(fd -> handle B)A:2, B:1 A:2 A:1 4. gem close(B)A:2, B:release A:1 A:0 5. gem close(A)A:1, A:1 A:0 6. gem close(A)A:release A:release A:release - and in case of using drm gem, vb2 and dmabuf, operations gem, vb2 refcountfile f_count buf refcount 1. gem create
[Bug 44647] New: [wine regression] Call of Duty 4: Intro videos renders garbage
https://bugs.freedesktop.org/show_bug.cgi?id=44647 Bug #: 44647 Summary: [wine regression] Call of Duty 4: Intro videos renders garbage Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se Created attachment 55392 --> https://bugs.freedesktop.org/attachment.cgi?id=55392 Screenshot of broken video Intro videos in the game Call of Duty 4 (running with Wine) no longer renders correctly, bisecting leads to this: e8139ebf583acf37150a8b341bcbef6b924a7792 is the first bad commit commit e8139ebf583acf37150a8b341bcbef6b924a7792 Author: Mathias Fr?hlich Date: Tue Jul 26 07:05:10 2011 +0200 r600g: Replace needless flush in texture upload. Replace pipe->flush() with pipe->texture_barrier() in the texture upload path for the staging texture. This should be enough to get data out of the gpu caches ready to be read for texture fetch. :04 04 b3f16d1a114f54d753ba7845b697888307f6246e faab26149053fdb2fb65d81bb2a777a77e130de2 Msrc Adding the flush back fixes the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
2012/1/10 Semwal, Sumit : > On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote: >> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote: >>> 2012/1/10 Rob Clark : >>> at least with no IOMMU, the memory information(containing physical >>> memory address) would be copied to vb2_xx_buf object if drm gem >>> exported its own buffer and vb2 wants to use that buffer at this time, >>> sg table is used to share that buffer. and the problem I pointed out >>> is that this buffer(also physical memory region) could be released by >>> vb2 framework(as you know, vb2_xx_buf object and the memory region for >>> buf->dma_addr pointing) but the Exporter(drm gem) couldn't know that >>> so some problems would be induced once drm gem tries to release or >>> access that buffer. and I have tried to resolve this issue adding >>> get_shared_cnt() callback to dma-buf.h but I'm not sure that this is >>> good way. maybe there would be better way. > Hi Inki, > As also mentioned in the documentation patch, importer (the user of > the buffer) - in this case for current RFC patches on > v4l2-as-a-user[1] vb2 framework - shouldn't release the backing memory > of the buffer directly - it should only use the dma-buf callbacks in > the right sequence to let the exporter know that it is done using this > buffer, so the exporter can release it if allowed and needed. thank you for your comments.:) and below are some tables about dmabuf operations with ideal use and these tables indicate reference count of when buffer is created, shared and released. so if there are any problems, please let me know. P.S. these are just simple cases so there would be others. in case of using only drm gem and dmabuf, operations gem refcountfile f_count buf refcount 1. gem create A:1 A:0 2. export(handle A -> fd)A:2A:1 A:0 3. import(fd -> handle B)A:2, B:1 A:2 A:1 4. file close(A) A:2, B:1 A:1 A:1 5. gem close(A)A:1, B:1 A:1 A:1 6. gem close(B)A:1, B:0 A:1 A:0 7. file close(A) A:0A:0 --- 3. handle B shares the buf of handle A. 6. release handle B but its buf. 7. release gem handle A and dmabuf of file A and also physical memory region. and in case of using drm gem, vb2 and dmabuf, operations gem, vb2 refcountfile f_count buf refcount 1. gem create A:1 A:0 (GEM side) 2. export(handle A -> fd)A:2 A:1 A:0 (GEM side) 3. import(fd -> handle B)A:2, B:1 A:2 A:1 (VB2 side) 4. file close(A) A:2, B:1 A:1 A:1 (VB2 side) 5. vb2 close(B) A:2, B:0 A:1 A:0 (VB2 side) 6. gem close(A)A:1A:1 A:0 (GEM side) 7. file close(A) A:0A:0 (GEM side) 3. vb2 handle B is shared with the buf of gem handle A. 5. release vb2 handle B and decrease refcount of the buf pointed by it. 7. release gem handle A and dmabuf of file A and also physical memory region. >> >> the exporter (in this case your driver's drm/gem bits) shouldn't >> release that mapping / sgtable until the importer (in this case v4l2) >> calls dma_buf_unmap fxn.. >> >> It would be an error if the importer did a dma_buf_put() without first >> calling dma_buf_unmap_attachment() (if currently mapped) and then >> dma_buf_detach() (if currently attached). ?Perhaps somewhere there >> should be some sanity checking debug code which could be enabled to do >> a WARN_ON() if the importer does the wrong thing. ?It shouldn't really >> be part of the API, I don't think, but it actually does seem like a >> good thing, esp. as new drivers start trying to use dmabuf, to have >> some debug options which could be enabled. >> >> It is entirely possible that something was missed on the vb2 patches, >> but the way it is intended to work is like this: >> https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-core.c#L92 >> >> where it does a detach() before the dma_buf_put(), and the vb2-contig >> backend checks here that it is also unmapped(): >> https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-dma-contig.c#L251 > > The proposed RFC for V4L2 adaptation at [1] does exactly the same >
[Bug 41265] KMS does not work on Radeon HD6700M
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #11 from Alex Deucher 2012-01-10 06:55:22 PST --- windows supports decoupled display and rendering. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41265] KMS does not work on Radeon HD6700M
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #10 from gyhor at gmx.de 2012-01-10 05:59:45 PST --- With the ati-driver in windows i can configure how the system uses the PMD. 1. as a gpu for the internal screen 2. as a graphic card for the external display I think, that the card can used in both modes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/nouveau: fix ttm move notify callback
On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote: > On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote: > > > Still having difficulty to reproduce can you reproduce with the attached > > > printk debuging patch and provide the log (only few printk preceding the > > > oops or segfault are interesting). > > > > http://darnok.org/vga/move_notify-v212.log > > > > Looks like nouveau doesn't like move notify being call on driver > shutdown or when somethings om nv50 is down. Ben i think you will > be better at finding a fix for that than me. I'm also not able to reproduce this issue on a NV98 (so, i'd expect every nv50+ chipset to behave the same) chipset with the current code in Dave's drm-core-next tree.. Am I missing something? Ben. > > Cheers, > Jerome
[PATCH] drm/i915: Add Clientron E830 to the ignore LVDS list
From: Joel SassSigned-off-by: Joel Sass Reviewed-by: Adam Jackson --- drivers/gpu/drm/i915/intel_lvds.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 77578b4..e44988e 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -708,6 +708,14 @@ static const struct dmi_system_id intel_no_lvds[] = { }, }, { +.callback = intel_no_lvds_dmi_callback, +.ident = "Clientron E830", +.matches = { +DMI_MATCH(DMI_SYS_VENDOR, "Clientron"), +DMI_MATCH(DMI_PRODUCT_NAME, "E830"), +}, +}, +{ .callback = intel_no_lvds_dmi_callback, .ident = "Asus EeeBox PC EB1007", .matches = { -- 1.7.0.4
[RFC] Future TTM DMA direction
On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote: > On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: > > Hi! > > > > When TTM was originally written, it was assumed that GPU apertures > > could address pages directly, and that the CPU could access those > > pages without explicit synchronization. The process of binding a > > page to a GPU translation table was a simple one-step operation, and > > we needed to worry about fragmentation in the GPU aperture only. > > > > Now that we "sort of" support DMA memory there are three things I > > think are missing: > > > > 1) We can't gracefully handle coherent DMA OOMs or coherent DMA > > (Including CMA) memory fragmentation leading to failed allocations. > > 2) We can't handle dynamic mapping of pages into and out of dma, and > > corresponding IOMMU space shortage or fragmentation, and CPU > > synchronization. > > 3) We have no straightforward way of moving pages between devices. > > > > I think a reasonable way to support this is to make binding to a > > non-fixed (system page based) TTM memory type a two-step binding > > process, so that a TTM placement consists of (DMA_TYPE, MEMORY_TYPE) > > instead of only (MEMORY_TYPE). > > > > In step 1) the bo is bound to a specific DMA type. These could be > > for example: > > (NONE, DYNAMIC, COHERENT, CMA), device dependent types could be > > allowed as well. > > In this step, we perform dma_sync_for_device, or allocate > > dma-specific pages maintaining LRU lists so that if we receive a DMA > > memory allocation OOM, we can unbind bo:s bound to the same DMA > > type. Standard graphics cards would then, for example, use the NONE > > DMA type when run on bare metal or COHERENT when run on Xen. A > > "COHERENT" OOM condition would then lead to eviction of another bo. > > (Note that DMA eviction might involve data copies and be costly, but > > still better than failing). > > Binding with the DYNAMIC memory type would mean that CPU accesses > > are disallowed, and that user-space CPU page mappings might need to > > be killed, with a corresponding sync_for_cpu if they are faulted in > > again (perhaps on a page-by-page basis). Any attempt to bo_kmap() a > > bo page bound to DYNAMIC DMA mapping should trigger a BUG. > > > > In step 2) The bo is bound to the GPU in the same way it's done > > today. Evicting from DMA will of course also trigger an evict from > > GPU, but an evict from GPU will not trigger a DMA evict. > > > > Making a bo "anonymous" and thus moveable between devices would then > > mean binding it to the "NONE" DMA type. > > > > Comments, suggestions? > > Well I think we need to solve outstanding issues in the dma_buf framework > first. Currently dma_buf isn't really up to par to handle coherency > between the cpu and devices and there's also not yet any way to handle dma > address space fragmentation/exhaustion. > > I fear that if you jump ahead with improving the ttm support alone we > might end up with something incompatible to the stuff dma_buf eventually > will grow, resulting in decent amounts of wasted efforts. > > Cc'ed a bunch of relevant lists to foster input from people. > > For a starter you seem to want much more low-level integration with the > dma api than existing users commonly need. E.g. if I understand things > correctly drivers just call dma_alloc_coherent and the platform/board code > then decides whether the device needs a contigious allocation from cma or > whether something else is good, too (e.g. vmalloc for the cpu + iommu). > Another thing is that I think doing lru eviction in case of dma address > space exhaustion (or fragmentation) needs at least awereness of what's > going on in the upper layers. iommus are commonly shared between devices > and I presume that two ttm drivers sitting behind the same iommu and > fighting over it's resources can lead to some hilarious outcomes. > > Cheers, Daniel I am with Daniel here, while i think the ttm API change you propose are good idea, i think most of the issue you are listing need to be addressed at lower level. If ttm keeps doing its own things for GPU in its own little area we gonna endup in a dma getto ;) dma space exhaustion is somethings that is highly platform specific, on x86 platform it's very unlikely to happen for AMD, Intel or NVidia GPU. While on the ARM platform it's more likely situation, at least on current generation. I believe that the dma api to allocate memory are just too limited for the kind of device and support we are having. The association to a device is too restrictive. I would rather see some new API to allocate DMA/IOMMU, something more flexible and more in line with the dma-buf work. I believe all dma allocation have a set of restriction. dma mask of the device, is there an iommu or not, iommu dma mask if any, iommu has a limited address space (note that recent x86 iommu don't have such limit). In the end it's not only the device dma mask that matter but also the
[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote: > On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote: >> 2012/1/10 Rob Clark : >> at least with no IOMMU, the memory information(containing physical >> memory address) would be copied to vb2_xx_buf object if drm gem >> exported its own buffer and vb2 wants to use that buffer at this time, >> sg table is used to share that buffer. and the problem I pointed out >> is that this buffer(also physical memory region) could be released by >> vb2 framework(as you know, vb2_xx_buf object and the memory region for >> buf->dma_addr pointing) but the Exporter(drm gem) couldn't know that >> so some problems would be induced once drm gem tries to release or >> access that buffer. and I have tried to resolve this issue adding >> get_shared_cnt() callback to dma-buf.h but I'm not sure that this is >> good way. maybe there would be better way. Hi Inki, As also mentioned in the documentation patch, importer (the user of the buffer) - in this case for current RFC patches on v4l2-as-a-user[1] vb2 framework - shouldn't release the backing memory of the buffer directly - it should only use the dma-buf callbacks in the right sequence to let the exporter know that it is done using this buffer, so the exporter can release it if allowed and needed. > > the exporter (in this case your driver's drm/gem bits) shouldn't > release that mapping / sgtable until the importer (in this case v4l2) > calls dma_buf_unmap fxn.. > > It would be an error if the importer did a dma_buf_put() without first > calling dma_buf_unmap_attachment() (if currently mapped) and then > dma_buf_detach() (if currently attached). ?Perhaps somewhere there > should be some sanity checking debug code which could be enabled to do > a WARN_ON() if the importer does the wrong thing. ?It shouldn't really > be part of the API, I don't think, but it actually does seem like a > good thing, esp. as new drivers start trying to use dmabuf, to have > some debug options which could be enabled. > > It is entirely possible that something was missed on the vb2 patches, > but the way it is intended to work is like this: > https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-core.c#L92 > > where it does a detach() before the dma_buf_put(), and the vb2-contig > backend checks here that it is also unmapped(): > https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-dma-contig.c#L251 The proposed RFC for V4L2 adaptation at [1] does exactly the same thing; detach() before dma_buf_put(), and check in vb2-contig backend for unmapped() as mentioned above. > > BR, > -R > BR, Sumit. [1]: V4l2 as a dma-buf user RFC: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966
[git pull] drm merge for 3.3-rc1.
Hi Linus, This is the main pull request for the drm for this merge window. It has two conflicts with your tree, I've fixed them up in a separate drm-linus-merged branch if you don't want to exercise your merging fingers. Highlights: drm core: add plane support and userspace interface to expose overlays for intel and soc hardwre. Lots of code removal through restructing by Daniel Vetter. EDID support for CEA modes. ttm: DMA aware page pool added, allows for use under Xen, and makes support for radeon VM easier. radeon: multi-ring support, semaphore support, better IB pool support, add VM support for Cayman and upcoming GPUs, evergreen HDMI audio support gma500: Initial GMA500 KMS driver moved from staging into drm proper. nouveau: HDMI audio support, lots of power management fixes, overscan connector property, initial nvd9 support, exynos: hdmi support, pm support, plane support. intel: better HDMI ELD support, plane support, GEN 7 streamout support. The Intel guys are also having process issues again, and then Intel pull request was very late and it looked like nobody was pulling stuff into a -next tree at all regularly. I'm sort of tempted to just drop anything more from them for this cycle, to give them time to sort themselves out for the next one. I think there is one missed IRQ fix from them I'd like to see, the rest I'm thinking can wait. Dave. The following changes since commit 6abff3c78051e40130a1c653f874fb12b9d40254: vmwgfx: Clip cliprects against screen boundaries in present and dirty (2011-12-19 14:06:05 +) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-core-next Akshay Joshi (1): gma500: Convert spaces to tabs in accel_2d.c. Alan Cox (31): gma500: Move the basic driver out of staging gma500: GEM and GEM glue gma500: introduce the GTT and MMU handling logic gma500: introduce the framebuffer support code gma500: Add device framework gma500: Add the glue to the various BIOS and firmware interfaces gma500: Add the i2c bus support gma500: Add the core DRM files and headers gma500: Add Poulsbo support gma500: Add Oaktrail support gma500: Add support for Cedarview gma500: Now connect up to the DRM build to finish the job drm/gma500: begin pruning dead bits of API gma500: Rename the ioctls to avoid clashing with the legacy drivers gma500: kill off NUM_PIPE define gma500: Move the API gma500: kill virtual mapping support gma500: do a pass over the FIXME tags gma500: kill bogus code gma500: Fix backlight crash gma500: frame buffer locking gma500: gtt based hardware scrolling console gma500: Be smarter about layout gma500: Fix oaktrail probing part 1 gma500: Oaktrail BIOS handling gma500: Final enables for Oaktrail gma500: Oaktrail fixes gma500/oaktrail: panel display quality fix gma500: Add the E6xx PCI identifier we are missing gma500: Fix Cedarview support (Correct version) gma500: remove no_fb bits Alex Deucher (9): drm/radeon/kms: add support for multiple fence queues v2 drm/radeon/kms: add some new ring params to better handle other ring types drm/radeon/kms: add cayman specific fence_ring_emit drm/radeon/kms: add support for per-ring fence interrupts drm/radeon/kms: add missing ring ready check in sync tests drm/radeon/kms: disable writeback on pre-R300 asics drm/radeon/kms: sync across multiple rings when doing bo moves v3 drm/radeon/kms: check if vm is supported in VA ioctl drm/radeon/kms: remove pointless CS flags priority struct Arjan van de Ven (1): drm: Make the per-driver file_operations struct const Ben Skeggs (88): drm/nv40/pm: parse fan pwm divisor from vbios tables drm/nv40/pm: implement first type of pwm fanspeed funcs drm/nv41/pm: implement a second type of fanspeed pwm drm/nouveau/pm: hook up fanspeed get/set if they're present drm/nouveau/vdec: implement stub modules for the known engines drm/nv50/pm: add support for pwm fan control drm/nv50/pm: mostly nailed down fan pwm frequency selection drm/nouveau/gpio: remove invert flag, use state[] everywhere drm/nouveau/pm: introduce generic handler for on-chip fan controller drm/nv50/pm: convert to new fanspeed pwm controller hooks drm/nv40/pm: convert to new pwm hooks, also fixing pwm type detection drm/nouveau/pm: remove defunct fanspeed_set/get from pm table drm/nv50/pm: s/unk05/vdec/ drm/nouveau/hdmi: build ELD from EDID, notify audio driver of its presence drm/nouveau/hdmi: add hdmi register accessors to handle hdmi block move drm/nouveau/hdmi: enable sending of avi/audio infoframes drm/nv50/crtc: disable flip overlay around scaling mode changes drm/nouveau: move master modesetting init to
[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
2012/1/10 Rob Clark : > On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote: >> note : in case of sharing a buffer between v4l2 and drm driver, the >> memory info would be copied vb2_xx_buf to xx_gem or xx_gem to >> vb2_xx_buf through sg table. in this case, only memory info is used to >> share, not some objects. > > which v4l2/vb2 patches are you looking at? ?The patches I was using, > vb2 holds a reference to the 'struct dma_buf *' internally, not just > keeping the sg_table > yes, not keeping the sg_table. I mean... see a example below please. static void vb2_dma_contig_map_dmabuf(void *mem_priv) { struct sg_table *sg; ... sg = dma_buf_map_attachment(buf->db_attach, dir); ... buf->dma_addr = sg_dma_address(sg->sgl); ... } at least with no IOMMU, the memory information(containing physical memory address) would be copied to vb2_xx_buf object if drm gem exported its own buffer and vb2 wants to use that buffer at this time, sg table is used to share that buffer. and the problem I pointed out is that this buffer(also physical memory region) could be released by vb2 framework(as you know, vb2_xx_buf object and the memory region for buf->dma_addr pointing) but the Exporter(drm gem) couldn't know that so some problems would be induced once drm gem tries to release or access that buffer. and I have tried to resolve this issue adding get_shared_cnt() callback to dma-buf.h but I'm not sure that this is good way. maybe there would be better way. Thanks. > BR, > -R
[RFC] Future TTM DMA direction
Hi Thomas, On Mon, Jan 09, 2012 at 12:01:28PM +0100, Thomas Hellstrom wrote: > Thanks for your input. I think this is mostly orthogonal to dma_buf, and > really a way to adapt TTM to be DMA-api aware. That's currently done > within the TTM backends. CMA was mearly included as an example that > might not be relevant. > > I haven't followed dma_buf that closely lately, but if it's growing > from being just > a way to share buffer objects between devices to something providing > also low-level > allocators with fragmentation prevention, there's definitely an overlap. > However, on the dma_buf meeting in Budapest there seemed to be > little or no interest > in robust buffer allocation / fragmentation prevention although I > remember bringing > it up to the point where I felt annoying :). Well, I've shot at you quite a bit too, and I still think it's too much for the first few iterations. But I also think we will need a cleverer dma subsystem sooner or later (even if it's just around dma_buf) so that's why I've dragged your rfc out of the drm corner ;-) Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[RFC] Future TTM DMA direction
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: > Hi! > > When TTM was originally written, it was assumed that GPU apertures > could address pages directly, and that the CPU could access those > pages without explicit synchronization. The process of binding a > page to a GPU translation table was a simple one-step operation, and > we needed to worry about fragmentation in the GPU aperture only. > > Now that we "sort of" support DMA memory there are three things I > think are missing: > > 1) We can't gracefully handle coherent DMA OOMs or coherent DMA > (Including CMA) memory fragmentation leading to failed allocations. However most allocations are done in PAGE_SIZE chunks. So there aren't any danger of contingous allocation failures. However, one way that the storage and network driver had solved this was by doing a dmapool code concept. Which is pretty much what TTM DMA is based on - that way we won't be hitting OOMs b/c we have allocated a pool at the start. Well, OK, we can still hit OOMs if we want more DMA buffers than the IOMMU can provide. We could eleviate part of the problem by making the unbind/binding process (and hence also the unpopulate/populate) happen more lazily to lower the exhaustion problem? > 2) We can't handle dynamic mapping of pages into and out of dma, and > corresponding IOMMU space shortage or fragmentation, and CPU > synchronization. This and 1) seem to point to the same thing - a closer relationship with the IOMMU/DMA code. I would think that this problem would not just be with graphics, but also with storage, userspace drivers, and network. Seems that some form of feedback mechanism from IOMMU API might be useful? > 3) We have no straightforward way of moving pages between devices. > > I think a reasonable way to support this is to make binding to a > non-fixed (system page based) TTM memory type a two-step binding > process, so that a TTM placement consists of (DMA_TYPE, MEMORY_TYPE) > instead of only (MEMORY_TYPE). > > In step 1) the bo is bound to a specific DMA type. These could be > for example: > (NONE, DYNAMIC, COHERENT, CMA), device dependent types could be > allowed as well. > In this step, we perform dma_sync_for_device, or allocate > dma-specific pages maintaining LRU lists so that if we receive a DMA > memory allocation OOM, we can unbind bo:s bound to the same DMA The DMA API is quite stringent in wanting the DMA page allocated to be associated with the BDF of the device. So the "same DMA type" would need to be "same DMA type on the same PCI device." > type. Standard graphics cards would then, for example, use the NONE > DMA type when run on bare metal or COHERENT when run on Xen. A > "COHERENT" OOM condition would then lead to eviction of another bo. > (Note that DMA eviction might involve data copies and be costly, but > still better than failing). OK, that sounds right - we do have those buffers and we could re-use them. Thought right now we throw away the 'tt_cached' ones instead of re-using them. > Binding with the DYNAMIC memory type would mean that CPU accesses > are disallowed, and that user-space CPU page mappings might need to > be killed, with a corresponding sync_for_cpu if they are faulted in > again (perhaps on a page-by-page basis). Any attempt to bo_kmap() a > bo page bound to DYNAMIC DMA mapping should trigger a BUG. > > In step 2) The bo is bound to the GPU in the same way it's done > today. Evicting from DMA will of course also trigger an evict from > GPU, but an evict from GPU will not trigger a DMA evict. > > Making a bo "anonymous" and thus moveable between devices would then > mean binding it to the "NONE" DMA type. Which would be copied to a different device when needed by another GPU? The "binding" process sounds like it would need the smarts to figure out whether it can just attach the DMA page to the other pool or if it needs to fetch a page from the other pool, copy the contents of the page, and retire the old one in a pool for re-use? And probably some other logic too. > > Comments, suggestions? > > /Thomas > > > > > >
[PATCH] drm/nouveau: fix ttm move notify callback
On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote: > On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote: > > On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote: > > > > Still having difficulty to reproduce can you reproduce with the attached > > > > printk debuging patch and provide the log (only few printk preceding the > > > > oops or segfault are interesting). > > > > > > http://darnok.org/vga/move_notify-v212.log > > > > > > > Looks like nouveau doesn't like move notify being call on driver > > shutdown or when somethings om nv50 is down. Ben i think you will > > be better at finding a fix for that than me. > I'm also not able to reproduce this issue on a NV98 (so, i'd expect > every nv50+ chipset to behave the same) chipset with the current code in > Dave's drm-core-next tree.. I was using 3.2 and then merged drm-core-next tree on top of that. > > Am I missing something? I am using a stock Fedora 16 with X Server 1.11.2. Machine has 8GB, and one DVI monitor and is an AMD box. The kernel was compiled using the default Fedora Core .config and for any new options I just hit enter. Don't have the experimental libGL code, so using: OpenGL version string: 2.1 Mesa 7.11.2 for the rendering. And the test setup is fairly easy - launch etracer, switch to a FB VC (Ctrl-Alt-F2), login, find the etracer pid and run perf --record --pid X and then switch back. Finish playing the game, exit it and then switch to the FB VC to turn it off, and it happens. Sometimes it happens when I just finished the game. I also can reproduce this with an AGP card (GeForce 4 Ti4200?) on an Intel Prescott box (2GB of memory) - also with stock Fedora 16. Thought the crash is different: http://darnok.org/vga/agp_nouveau_crash.jpg Hmm, I can hook up a serial console to that box to get a better output - but perhaps before I do that should is there a debug patch I should compile in?
[patch] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
Le 10/01/2012 06:39, Dan Carpenter a ?crit : > On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote: >> Le 04/01/2012 08:20, Dan Carpenter a ?crit : >>> calc_mclk() returns zero on success and negative on failure but clk is >>> a u32. >>> >>> Signed-off-by: Dan Carpenter >>> >>> diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c >>> b/drivers/gpu/drm/nouveau/nv50_pm.c >>> index 0393721..3508de9 100644 >>> --- a/drivers/gpu/drm/nouveau/nv50_pm.c >>> +++ b/drivers/gpu/drm/nouveau/nv50_pm.c >>> @@ -540,7 +540,7 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct >>> nouveau_pm_level *perflvl) >>> info->mclk_hwsq.len = 0; >>> if (perflvl->memory) { >>> clk = calc_mclk(dev, perflvl->memory,>mclk_hwsq); >>> - if (clk< 0) { >>> + if ((int)clk< 0) { >>> ret = clk; >>> goto error; >>> } >> Well spotted Dan! >> >> Sorry for the late answer, was busy reworking this file for safe reclocking. >> >> I have a slightly different fix for that. Please tell me if It suits >> you: >> https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commit/c1b80360ezd1aa7dd780ac383aae9437c66ef3b89 > That link redirects to > https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/master > and it doesn't show the patch. > > But I wasn't a huge fan of adding the cast very much either so I'm > sure your patch is good. > > regards, > dan carpenter Sorry, here is the patch attached.
[patch] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote: > Le 04/01/2012 08:20, Dan Carpenter a ?crit : > >calc_mclk() returns zero on success and negative on failure but clk is > >a u32. > > > >Signed-off-by: Dan Carpenter > > > >diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c > >b/drivers/gpu/drm/nouveau/nv50_pm.c > >index 0393721..3508de9 100644 > >--- a/drivers/gpu/drm/nouveau/nv50_pm.c > >+++ b/drivers/gpu/drm/nouveau/nv50_pm.c > >@@ -540,7 +540,7 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct > >nouveau_pm_level *perflvl) > > info->mclk_hwsq.len = 0; > > if (perflvl->memory) { > > clk = calc_mclk(dev, perflvl->memory,>mclk_hwsq); > >-if (clk< 0) { > >+if ((int)clk< 0) { > > ret = clk; > > goto error; > > } > Well spotted Dan! > > Sorry for the late answer, was busy reworking this file for safe reclocking. > > I have a slightly different fix for that. Please tell me if It suits > you: > https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commit/c1b80360ezd1aa7dd780ac383aae9437c66ef3b89 That link redirects to https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/master and it doesn't show the patch. But I wasn't a huge fan of adding the cast very much either so I'm sure your patch is good. regards, dan carpenter -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120110/e24aecef/attachment.pgp>
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #63 from Rafael ?vila de Esp?ndola 2012-01-09 17:11:34 PST --- Created attachment 55359 --> https://bugs.freedesktop.org/attachment.cgi?id=55359 dmesg from kernel 3.2 I just tried KMS with kernel 3.2 and I still get a black screen :-( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[patch] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
Le 04/01/2012 08:20, Dan Carpenter a ?crit : > calc_mclk() returns zero on success and negative on failure but clk is > a u32. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c > b/drivers/gpu/drm/nouveau/nv50_pm.c > index 0393721..3508de9 100644 > --- a/drivers/gpu/drm/nouveau/nv50_pm.c > +++ b/drivers/gpu/drm/nouveau/nv50_pm.c > @@ -540,7 +540,7 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct > nouveau_pm_level *perflvl) > info->mclk_hwsq.len = 0; > if (perflvl->memory) { > clk = calc_mclk(dev, perflvl->memory,>mclk_hwsq); > - if (clk< 0) { > + if ((int)clk< 0) { > ret = clk; > goto error; > } Well spotted Dan! Sorry for the late answer, was busy reworking this file for safe reclocking. I have a slightly different fix for that. Please tell me if It suits you: https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commit/c1b80360ezd1aa7dd780ac383aae9437c66ef3b89
Re: [RFC] Future TTM DMA direction
Hi Thomas, On Mon, Jan 09, 2012 at 12:01:28PM +0100, Thomas Hellstrom wrote: Thanks for your input. I think this is mostly orthogonal to dma_buf, and really a way to adapt TTM to be DMA-api aware. That's currently done within the TTM backends. CMA was mearly included as an example that might not be relevant. I haven't followed dma_buf that closely lately, but if it's growing from being just a way to share buffer objects between devices to something providing also low-level allocators with fragmentation prevention, there's definitely an overlap. However, on the dma_buf meeting in Budapest there seemed to be little or no interest in robust buffer allocation / fragmentation prevention although I remember bringing it up to the point where I felt annoying :). Well, I've shot at you quite a bit too, and I still think it's too much for the first few iterations. But I also think we will need a cleverer dma subsystem sooner or later (even if it's just around dma_buf) so that's why I've dragged your rfc out of the drm corner ;-) Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
2012/1/10 InKi Dae daei...@gmail.com: 2012/1/10 Semwal, Sumit sumit.sem...@ti.com: On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark r...@ti.com wrote: On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae daei...@gmail.com wrote: 2012/1/10 Rob Clark r...@ti.com: at least with no IOMMU, the memory information(containing physical memory address) would be copied to vb2_xx_buf object if drm gem exported its own buffer and vb2 wants to use that buffer at this time, sg table is used to share that buffer. and the problem I pointed out is that this buffer(also physical memory region) could be released by vb2 framework(as you know, vb2_xx_buf object and the memory region for buf-dma_addr pointing) but the Exporter(drm gem) couldn't know that so some problems would be induced once drm gem tries to release or access that buffer. and I have tried to resolve this issue adding get_shared_cnt() callback to dma-buf.h but I'm not sure that this is good way. maybe there would be better way. Hi Inki, As also mentioned in the documentation patch, importer (the user of the buffer) - in this case for current RFC patches on v4l2-as-a-user[1] vb2 framework - shouldn't release the backing memory of the buffer directly - it should only use the dma-buf callbacks in the right sequence to let the exporter know that it is done using this buffer, so the exporter can release it if allowed and needed. thank you for your comments.:) and below are some tables about dmabuf operations with ideal use and these tables indicate reference count of when buffer is created, shared and released. so if there are any problems, please let me know. P.S. these are just simple cases so there would be others. in case of using only drm gem and dmabuf, operations gem refcount file f_count buf refcount 1. gem create A:1 A:0 2. export(handle A - fd) A:2 A:1 A:0 3. import(fd - handle B) A:2, B:1 A:2 A:1 4. file close(A) A:2, B:1 A:1 A:1 5. gem close(A) A:1, B:1 A:1 A:1 6. gem close(B) A:1, B:0 A:1 A:0 7. file close(A) A:0 A:0 --- 3. handle B shares the buf of handle A. 6. release handle B but its buf. 7. release gem handle A and dmabuf of file A and also physical memory region. and in case of using drm gem, vb2 and dmabuf, operations gem, vb2 refcount file f_count buf refcount 1. gem create A:1 A:0 (GEM side) 2. export(handle A - fd) A:2 A:1 A:0 (GEM side) 3. import(fd - handle B) A:2, B:1 A:2 A:1 (VB2 side) 4. file close(A) A:2, B:1 A:1 A:1 (VB2 side) 5. vb2 close(B) A:2, B:0 A:1 A:0 (VB2 side) 6. gem close(A) A:1 A:1 A:0 (GEM side) 7. file close(A) A:0 A:0 (GEM side) 3. vb2 handle B is shared with the buf of gem handle A. 5. release vb2 handle B and decrease refcount of the buf pointed by it. 7. release gem handle A and dmabuf of file A and also physical memory region. Ah, sorry, it seems that file close shouldn't be called because file-f_count of the file would be dropped by Importer and if f_count is 0 then the file would be released by fput() so I'm not sure but again: in case of using only drm gem and dmabuf, operations gem refcount file f_count buf refcount -- 1. gem create(A) A:1 A:0 2. export(handle A - fd)A:2 A:1 A:0 3. import(fd - handle B)A:2, B:1 A:2 A:1 4. gem close(B)A:2, B:release A:1 A:0 5. gem close(A)A:1, A:1 A:0 6. gem close(A)A:release A:release A:release - and in case of using drm gem, vb2 and dmabuf, operations gem, vb2 refcountfile f_count buf refcount 1. gem create A:1 A:0
Re: [patch] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
Le 10/01/2012 06:39, Dan Carpenter a écrit : On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote: Le 04/01/2012 08:20, Dan Carpenter a écrit : calc_mclk() returns zero on success and negative on failure but clk is a u32. Signed-off-by: Dan Carpenterdan.carpen...@oracle.com diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c b/drivers/gpu/drm/nouveau/nv50_pm.c index 0393721..3508de9 100644 --- a/drivers/gpu/drm/nouveau/nv50_pm.c +++ b/drivers/gpu/drm/nouveau/nv50_pm.c @@ -540,7 +540,7 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct nouveau_pm_level *perflvl) info-mclk_hwsq.len = 0; if (perflvl-memory) { clk = calc_mclk(dev, perflvl-memory,info-mclk_hwsq); - if (clk 0) { + if ((int)clk 0) { ret = clk; goto error; } Well spotted Dan! Sorry for the late answer, was busy reworking this file for safe reclocking. I have a slightly different fix for that. Please tell me if It suits you: https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commit/c1b80360ezd1aa7dd780ac383aae9437c66ef3b89 That link redirects to https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/master and it doesn't show the patch. But I wasn't a huge fan of adding the cast very much either so I'm sure your patch is good. regards, dan carpenter Sorry, here is the patch attached. From c1b80360ed1aa7dd780ac383aae9437c66ef3b89 Mon Sep 17 00:00:00 2001 From: Dan Carpenter dan.carpen...@oracle.com Date: Wed, 4 Jan 2012 10:20:47 +0300 Subject: [PATCH 5/7] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre() calc_mclk() returns zero on success and negative on failure but clk is a u32. v2: Martin Peres: - clk should be an int, not a u32 Signed-off-by: Martin Peres martin.pe...@labri.fr Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- drivers/gpu/drm/nouveau/nv50_pm.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c b/drivers/gpu/drm/nouveau/nv50_pm.c index 983b432..4be2e20 100644 --- a/drivers/gpu/drm/nouveau/nv50_pm.c +++ b/drivers/gpu/drm/nouveau/nv50_pm.c @@ -659,11 +659,11 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct nouveau_pm_level *perflvl) struct nv50_pm_state *info; struct hwsq_ucode *hwsq; struct pll_lims pll; - int ret = -EINVAL; + int clk, ret = -EINVAL; int N, M, P1, P2; u32 mast = nv_rd32(dev, 0x00c040); u32 divs = read_div(dev); - u32 ctrl, clk, out; + u32 ctrl, out; if (dev_priv-chipset == 0xaa || dev_priv-chipset == 0xac) -- 1.7.8.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm merge for 3.3-rc1.
Hi Linus, This is the main pull request for the drm for this merge window. It has two conflicts with your tree, I've fixed them up in a separate drm-linus-merged branch if you don't want to exercise your merging fingers. Highlights: drm core: add plane support and userspace interface to expose overlays for intel and soc hardwre. Lots of code removal through restructing by Daniel Vetter. EDID support for CEA modes. ttm: DMA aware page pool added, allows for use under Xen, and makes support for radeon VM easier. radeon: multi-ring support, semaphore support, better IB pool support, add VM support for Cayman and upcoming GPUs, evergreen HDMI audio support gma500: Initial GMA500 KMS driver moved from staging into drm proper. nouveau: HDMI audio support, lots of power management fixes, overscan connector property, initial nvd9 support, exynos: hdmi support, pm support, plane support. intel: better HDMI ELD support, plane support, GEN 7 streamout support. The Intel guys are also having process issues again, and then Intel pull request was very late and it looked like nobody was pulling stuff into a -next tree at all regularly. I'm sort of tempted to just drop anything more from them for this cycle, to give them time to sort themselves out for the next one. I think there is one missed IRQ fix from them I'd like to see, the rest I'm thinking can wait. Dave. The following changes since commit 6abff3c78051e40130a1c653f874fb12b9d40254: vmwgfx: Clip cliprects against screen boundaries in present and dirty (2011-12-19 14:06:05 +) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-core-next Akshay Joshi (1): gma500: Convert spaces to tabs in accel_2d.c. Alan Cox (31): gma500: Move the basic driver out of staging gma500: GEM and GEM glue gma500: introduce the GTT and MMU handling logic gma500: introduce the framebuffer support code gma500: Add device framework gma500: Add the glue to the various BIOS and firmware interfaces gma500: Add the i2c bus support gma500: Add the core DRM files and headers gma500: Add Poulsbo support gma500: Add Oaktrail support gma500: Add support for Cedarview gma500: Now connect up to the DRM build to finish the job drm/gma500: begin pruning dead bits of API gma500: Rename the ioctls to avoid clashing with the legacy drivers gma500: kill off NUM_PIPE define gma500: Move the API gma500: kill virtual mapping support gma500: do a pass over the FIXME tags gma500: kill bogus code gma500: Fix backlight crash gma500: frame buffer locking gma500: gtt based hardware scrolling console gma500: Be smarter about layout gma500: Fix oaktrail probing part 1 gma500: Oaktrail BIOS handling gma500: Final enables for Oaktrail gma500: Oaktrail fixes gma500/oaktrail: panel display quality fix gma500: Add the E6xx PCI identifier we are missing gma500: Fix Cedarview support (Correct version) gma500: remove no_fb bits Alex Deucher (9): drm/radeon/kms: add support for multiple fence queues v2 drm/radeon/kms: add some new ring params to better handle other ring types drm/radeon/kms: add cayman specific fence_ring_emit drm/radeon/kms: add support for per-ring fence interrupts drm/radeon/kms: add missing ring ready check in sync tests drm/radeon/kms: disable writeback on pre-R300 asics drm/radeon/kms: sync across multiple rings when doing bo moves v3 drm/radeon/kms: check if vm is supported in VA ioctl drm/radeon/kms: remove pointless CS flags priority struct Arjan van de Ven (1): drm: Make the per-driver file_operations struct const Ben Skeggs (88): drm/nv40/pm: parse fan pwm divisor from vbios tables drm/nv40/pm: implement first type of pwm fanspeed funcs drm/nv41/pm: implement a second type of fanspeed pwm drm/nouveau/pm: hook up fanspeed get/set if they're present drm/nouveau/vdec: implement stub modules for the known engines drm/nv50/pm: add support for pwm fan control drm/nv50/pm: mostly nailed down fan pwm frequency selection drm/nouveau/gpio: remove invert flag, use state[] everywhere drm/nouveau/pm: introduce generic handler for on-chip fan controller drm/nv50/pm: convert to new fanspeed pwm controller hooks drm/nv40/pm: convert to new pwm hooks, also fixing pwm type detection drm/nouveau/pm: remove defunct fanspeed_set/get from pm table drm/nv50/pm: s/unk05/vdec/ drm/nouveau/hdmi: build ELD from EDID, notify audio driver of its presence drm/nouveau/hdmi: add hdmi register accessors to handle hdmi block move drm/nouveau/hdmi: enable sending of avi/audio infoframes drm/nv50/crtc: disable flip overlay around scaling mode changes drm/nouveau: move master modesetting init to
[Bug 41265] KMS does not work on Radeon HD6700M
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #10 from gy...@gmx.de 2012-01-10 05:59:45 PST --- With the ati-driver in windows i can configure how the system uses the PMD. 1. as a gpu for the internal screen 2. as a graphic card for the external display I think, that the card can used in both modes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: fix ttm move notify callback
On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote: On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote: On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote: Still having difficulty to reproduce can you reproduce with the attached printk debuging patch and provide the log (only few printk preceding the oops or segfault are interesting). http://darnok.org/vga/move_notify-v212.log Looks like nouveau doesn't like move notify being call on driver shutdown or when somethings om nv50 is down. Ben i think you will be better at finding a fix for that than me. I'm also not able to reproduce this issue on a NV98 (so, i'd expect every nv50+ chipset to behave the same) chipset with the current code in Dave's drm-core-next tree.. I was using 3.2 and then merged drm-core-next tree on top of that. Am I missing something? I am using a stock Fedora 16 with X Server 1.11.2. Machine has 8GB, and one DVI monitor and is an AMD box. The kernel was compiled using the default Fedora Core .config and for any new options I just hit enter. Don't have the experimental libGL code, so using: OpenGL version string: 2.1 Mesa 7.11.2 for the rendering. And the test setup is fairly easy - launch etracer, switch to a FB VC (Ctrl-Alt-F2), login, find the etracer pid and run perf --record --pid X and then switch back. Finish playing the game, exit it and then switch to the FB VC to turn it off, and it happens. Sometimes it happens when I just finished the game. I also can reproduce this with an AGP card (GeForce 4 Ti4200?) on an Intel Prescott box (2GB of memory) - also with stock Fedora 16. Thought the crash is different: http://darnok.org/vga/agp_nouveau_crash.jpg Hmm, I can hook up a serial console to that box to get a better output - but perhaps before I do that should is there a debug patch I should compile in? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41265] KMS does not work on Radeon HD6700M
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #11 from Alex Deucher ag...@yahoo.com 2012-01-10 06:55:22 PST --- windows supports decoupled display and rendering. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Future TTM DMA direction
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: Hi! When TTM was originally written, it was assumed that GPU apertures could address pages directly, and that the CPU could access those pages without explicit synchronization. The process of binding a page to a GPU translation table was a simple one-step operation, and we needed to worry about fragmentation in the GPU aperture only. Now that we sort of support DMA memory there are three things I think are missing: 1) We can't gracefully handle coherent DMA OOMs or coherent DMA (Including CMA) memory fragmentation leading to failed allocations. However most allocations are done in PAGE_SIZE chunks. So there aren't any danger of contingous allocation failures. However, one way that the storage and network driver had solved this was by doing a dmapool code concept. Which is pretty much what TTM DMA is based on - that way we won't be hitting OOMs b/c we have allocated a pool at the start. Well, OK, we can still hit OOMs if we want more DMA buffers than the IOMMU can provide. We could eleviate part of the problem by making the unbind/binding process (and hence also the unpopulate/populate) happen more lazily to lower the exhaustion problem? 2) We can't handle dynamic mapping of pages into and out of dma, and corresponding IOMMU space shortage or fragmentation, and CPU synchronization. This and 1) seem to point to the same thing - a closer relationship with the IOMMU/DMA code. I would think that this problem would not just be with graphics, but also with storage, userspace drivers, and network. Seems that some form of feedback mechanism from IOMMU API might be useful? 3) We have no straightforward way of moving pages between devices. I think a reasonable way to support this is to make binding to a non-fixed (system page based) TTM memory type a two-step binding process, so that a TTM placement consists of (DMA_TYPE, MEMORY_TYPE) instead of only (MEMORY_TYPE). In step 1) the bo is bound to a specific DMA type. These could be for example: (NONE, DYNAMIC, COHERENT, CMA), device dependent types could be allowed as well. In this step, we perform dma_sync_for_device, or allocate dma-specific pages maintaining LRU lists so that if we receive a DMA memory allocation OOM, we can unbind bo:s bound to the same DMA The DMA API is quite stringent in wanting the DMA page allocated to be associated with the BDF of the device. So the same DMA type would need to be same DMA type on the same PCI device. type. Standard graphics cards would then, for example, use the NONE DMA type when run on bare metal or COHERENT when run on Xen. A COHERENT OOM condition would then lead to eviction of another bo. (Note that DMA eviction might involve data copies and be costly, but still better than failing). OK, that sounds right - we do have those buffers and we could re-use them. Thought right now we throw away the 'tt_cached' ones instead of re-using them. Binding with the DYNAMIC memory type would mean that CPU accesses are disallowed, and that user-space CPU page mappings might need to be killed, with a corresponding sync_for_cpu if they are faulted in again (perhaps on a page-by-page basis). Any attempt to bo_kmap() a bo page bound to DYNAMIC DMA mapping should trigger a BUG. In step 2) The bo is bound to the GPU in the same way it's done today. Evicting from DMA will of course also trigger an evict from GPU, but an evict from GPU will not trigger a DMA evict. Making a bo anonymous and thus moveable between devices would then mean binding it to the NONE DMA type. Which would be copied to a different device when needed by another GPU? The binding process sounds like it would need the smarts to figure out whether it can just attach the DMA page to the other pool or if it needs to fetch a page from the other pool, copy the contents of the page, and retire the old one in a pool for re-use? And probably some other logic too. Comments, suggestions? /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 lone...@kapsi.fi changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #9 from lone...@kapsi.fi 2012-01-10 12:45:58 PST --- These patches may fix some systems, but they also cause a similar problem on my HP ProBook 6465b (A6-3410MX processor with built-in GPU). There is also someone else with the same issue on different ProBook model: http://forums.gentoo.org/viewtopic-t-908460.html Reverting the patch from comment #6 fixes it at least for me. Either way, it is bad for Zathras. :-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #10 from Alex Deucher ag...@yahoo.com 2012-01-10 12:51:52 PST --- (In reply to comment #9) These patches may fix some systems, but they also cause a similar problem on my HP ProBook 6465b (A6-3410MX processor with built-in GPU). There is also someone else with the same issue on different ProBook model: http://forums.gentoo.org/viewtopic-t-908460.html Reverting the patch from comment #6 fixes it at least for me. Please attach your xorg log and dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #11 from lone...@kapsi.fi 2012-01-10 13:32:37 PST --- Created attachment 55400 -- https://bugs.freedesktop.org/attachment.cgi?id=55400 dmesg/system log I deleted the buggy kernels already, but here is the system log from a boot with one. It should have full dmesg output in it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43858] DVI of ATI RADEON 9200 AGP don't work
https://bugs.freedesktop.org/show_bug.cgi?id=43858 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #54464|text/x-log |text/plain mime type|| Attachment #54464|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43858] DVI of ATI RADEON 9200 AGP don't work
https://bugs.freedesktop.org/show_bug.cgi?id=43858 --- Comment #4 from Alex Deucher ag...@yahoo.com 2012-01-10 13:53:35 PST --- According to your xorg log, you are trying to drive two 1920x1080 monitors. That is a lot of bandwidth for an r2xx GPU to drive. Try only attaching one monitor. I suspect the memory controller cannot keep up with the requests for two large monitors and the 3D engine, and when you get underflow, you get the blinking. Does it work ok with only one monitor (xrandr --output VGA-0 --off)? How about a different mode? Try 1024x768 or 1280x800, etc. You can also try a different modeline for 1920x1080. try: Modeline 1920x1080R 138.50 1920 1968 2000 2080 1080 1083 1088 +hsync -vsync for example. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41569] [r600 KMS] Asus A53T A4-3400
https://bugs.freedesktop.org/show_bug.cgi?id=41569 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #55401|application/octet-stream|text/plain mime type|| Attachment #55401|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37826] piglit: fbo/fbo-maxsize assertion failure
https://bugs.freedesktop.org/show_bug.cgi?id=37826 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sven Arvidsson s...@whiz.se 2012-01-10 16:15:47 PST --- This test is passing now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
2012/1/10 Rob Clark r...@ti.com: On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae daei...@gmail.com wrote: 2012/1/10 Rob Clark r...@ti.com: On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae daei...@gmail.com wrote: note : in case of sharing a buffer between v4l2 and drm driver, the memory info would be copied vb2_xx_buf to xx_gem or xx_gem to vb2_xx_buf through sg table. in this case, only memory info is used to share, not some objects. which v4l2/vb2 patches are you looking at? The patches I was using, vb2 holds a reference to the 'struct dma_buf *' internally, not just keeping the sg_table yes, not keeping the sg_table. I mean... see a example below please. static void vb2_dma_contig_map_dmabuf(void *mem_priv) { struct sg_table *sg; ... sg = dma_buf_map_attachment(buf-db_attach, dir); ... buf-dma_addr = sg_dma_address(sg-sgl); ... } at least with no IOMMU, the memory information(containing physical memory address) would be copied to vb2_xx_buf object if drm gem exported its own buffer and vb2 wants to use that buffer at this time, sg table is used to share that buffer. and the problem I pointed out is that this buffer(also physical memory region) could be released by vb2 framework(as you know, vb2_xx_buf object and the memory region for buf-dma_addr pointing) but the Exporter(drm gem) couldn't know that so some problems would be induced once drm gem tries to release or access that buffer. and I have tried to resolve this issue adding get_shared_cnt() callback to dma-buf.h but I'm not sure that this is good way. maybe there would be better way. the exporter (in this case your driver's drm/gem bits) shouldn't release that mapping / sgtable until the importer (in this case v4l2) calls dma_buf_unmap fxn.. It would be an error if the importer did a dma_buf_put() without first calling dma_buf_unmap_attachment() (if currently mapped) and then dma_buf_detach() (if currently attached). Perhaps somewhere there should be some sanity checking debug code which could be enabled to do a WARN_ON() if the importer does the wrong thing. It shouldn't really be part of the API, I don't think, but it actually does seem like a good thing, esp. as new drivers start trying to use dmabuf, to have some debug options which could be enabled. It is entirely possible that something was missed on the vb2 patches, but the way it is intended to work is like this: https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-core.c#L92 where it does a detach() before the dma_buf_put(), and the vb2-contig backend checks here that it is also unmapped(): https://github.com/robclark/kernel-omap4/blob/0961428143cd10269223e3d0f24bc3a66a96185f/drivers/media/video/videobuf2-dma-contig.c#L251 I think that we also used same concept as your. for this, you can refer to Dave's repository below and see the drm_prime_gem_destroy function. http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-prime-dmabufid=7cb374d6642e838e0e4836042e057e6d9139dcad but when it comes to releasing resources, I mistakely understood some parts of dmabuf concept so thank you for Rob and Sumit. that is very useful. BR, -R Thanks. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel