[Bug 41569] [r600 KMS] Asus A53T A4-3400

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[InKi Dae]

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

[bugzilla-dae...@freedesktop.org]

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

[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 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

[bugzilla-dae...@freedesktop.org]

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

[bugzilla-dae...@freedesktop.org]

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

[Ben Skeggs]

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

[Joel Sass]

From: Joel Sass 

Signed-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

[Jerome Glisse]

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

[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.
>
> 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.

[Dave Airlie]

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

[InKi Dae]

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

[Daniel Vetter]

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

[Konrad Rzeszutek Wilk]

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

[Konrad Rzeszutek Wilk]

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()

[Martin Peres]

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()

[Dan Carpenter]

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)

[bugzilla-dae...@freedesktop.org]

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()

[Martin Peres]

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

[Daniel Vetter]

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

[InKi Dae]

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()

[Martin Peres]

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.

[Dave Airlie]

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

[bugzilla-daemon]

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

[Konrad Rzeszutek Wilk]

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

[bugzilla-daemon]

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

[Konrad Rzeszutek Wilk]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[InKi Dae]

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