[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

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

https://bugzilla.kernel.org/show_bug.cgi?id=48941


Igor Murzov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




--- Comment #8 from Igor Murzov   2012-11-05 23:36:42 ---
Fixed.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 1/1] drm: exynos: fix for mapping contigous dma buffers

[Inki Dae]

2012. 11. 3. ?? 9:21 Rahul Sharma  ??:

> This patch fixes the problem of mapping contigous dma buffers. Currently page
> struct is calculated from the buf->dma_addr which is not the physical address.
> It is replaced by buf->pages which points to the page struct of the first page
> of contigous memory chunk. This gives the correct page frame number for
> mapping.
> 
> Signed-off-by: Rahul Sharma 
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index c557ac7..50d73f1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -120,8 +120,12 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object 
> *obj,
>}
> 
>pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
> -} else
> -pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
> +} else {
> +if (!buf->pages)
> +return -EINTR;
> +
> +pfn = page_to_pfn(buf->pages[0]) + page_offset;
> +}

Is there any reason you are sending patches respectively? It's better to 
combine them.

Thanks,
Inki Dae

> 
>return vm_insert_mixed(vma, f_vaddr, pfn);
> }
> -- 
> 1.7.0.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

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

https://bugzilla.kernel.org/show_bug.cgi?id=48941


Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org




--- Comment #7 from Florian Mickler   2012-11-05 
23:15:22 ---
A patch referencing this bug report has been merged in Linux v3.7-rc3:

commit 614499b4d844dcceae5ae2f1e53a2963789a8933
Author: Alex Deucher 
Date:   Wed Oct 17 17:20:24 2012 -0400

drm/radeon: give each backlight a unique id

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"

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

https://bugs.freedesktop.org/show_bug.cgi?id=56788

Emil Velikov  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |nouveau at 
lists.freedesktop.o
   |.org|rg
  Component|Drivers/DRI/Radeon  |Drivers/DRI/nouveau

--- Comment #2 from Emil Velikov  ---
Correcting component

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/7015d7ee/attachment.html>

[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"

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

https://bugs.freedesktop.org/show_bug.cgi?id=56788

--- Comment #1 from Emil Velikov  ---
Created attachment 69590
  --> https://bugs.freedesktop.org/attachment.cgi?id=69590=edit
Wine backtrace

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/39e5eb6a/attachment.html>

[Bug 56788] New: [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"

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

https://bugs.freedesktop.org/show_bug.cgi?id=56788

  Priority: medium
Bug ID: 56788
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [nv96] Dota2 (wine) consistently crashes with
"WARNING: out of code space, evicting all shaders"
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: emil.l.velikov at gmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/DRI/Radeon
   Product: Mesa

Created attachment 69589
  --> https://bugs.freedesktop.org/attachment.cgi?id=69589=edit
Untrimmed stdout & stderr

As of approx 1 Nov 2012, Dota2 crashes while playing/spectating a game

Initially I was suspecting the recent vbo work by Marek, although I'm leaning
towards memory bug/buggy shader in one of the Dota2 3 updates - 29,30 and 1 Nov

Cannot downgrade to verify, although backtrace does point that the crash occurs
after the above message is printed to stderr

Brief list of the other messages printed to strout & strerr

WARNING: value %35 not uniquely defined
...
WARNING: value %277 not uniquely defined
WARNING: value %17 not uniquely defined
context mis-match in pipe_sampler_view_release()
WARNING: value %28 not uniquely defined
...
WARNING: value %17 not uniquely defined
WARNING: out of code space, evicting all shaders.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/15747cc0/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #17 from Alexandre Demers  ---
I'm about to test patches. But before, as promised, here are the values
retrieved read and written to the registers. By the way, I have only a single
monitor.
tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]); -> 272696081 (0001 
0100 0001  0011 0001 0001)
tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; -> 289473297 (0001 0001 0100
0001  0011 0001 0001)

So, it is set as you explained me earlier. I'll be back soon with some news
from the patches.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/b3edd9fd/attachment.html>

[Bug 53130] 99c65ba breaks rendering (flickery, eventual fail)

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

https://bugs.freedesktop.org/show_bug.cgi?id=53130

--- Comment #3 from Darren Salt  ---
I've rebuilt mesa with this re-enabled and I saw a lot of rendering glitches. I
suspect that DISCARD_RANGE being re-enabled is the problem, although I've also
built and installed an updated xf86-video-ati (cdf522f?20bfc65).

My current mesa build has 1eedebc reverted; I'll re-check with that undone
later.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/48a9a737/attachment.html>

[bisected] drm i915 hangs on heavy io load

[Lekensteyn]

On Sunday 04 November 2012 16:08:47 Dave Airlie wrote:
> On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining  
> wrote:

> > On Di, 30 Okt 2012, Dave Airlie wrote:
> >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
> >> final to 3.7-rc1 or maybe -rc2.
> > 
> > Sorry for my ignorance ... I did on master branch
> > 
> > $ git checkout v3.7-rc1
> > ...
> > $ git bisect start drivers/gpu/drm/i915
> > $ git bisect bad
> > $ git bisect good v3.6
> > Bisecting: 121 revisions left to test after this (roughly 7 steps)
> > [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new
> > set_mode code flow $
> > 
> > after that I am back somewhere around
> > 
> > 3.6.0-rc2
> > 
> > ???
> > 
> > Am I doing something wrong? I thought I am bisecting between 3.6 and
> > 3.7.-rc2? How can I go back to 3.6.0-rc2?
> 
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.

As I mentioned on https://bugs.freedesktop.org/show_bug.cgi?id=55984, I also 
hit this bug. The first time was on branch drm-intel-next-2012-09-20 on Daniel 
Vetters drm-intel git.

I guess it has something to do with low memory. To reproduce the bug on my 
laptop with 8GB RAM and a i5-460M, I did:

1. Boot (I use KDE)
3. Start glxspheres (from http://virtualgl.org/, but glxgears might work too, 
not tested)
2. Copy a 1.2 GiB Linux source tree to /dev/shm and /tmp (both tmpfs), 5 
times. This uses 6GiB of RAM. I used this bash script:
#!/bin/bash
for i in /tmp/hang-l1 /tmp/hang-l2 /tmp/hang-l3 \
/dev/shm/hang-l1 /dev/shm/hang-l2; do
cp -ra ~/Linux-src/linux "$i" &
done; wait
3. When the copy is almost done, watch the machine become sluggish and 
eventually print the "[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer 
elapsed... GPU hung" message to the kernel log. Until the machine is rebooted, 
all OpenGL applications will fail to load.

On kernels where it was working fine, there is no lag when the copy is almost 
finished.

504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 is the first bad commit
commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
Author: Chris Wilson 
Date:   Thu Aug 23 13:12:52 2012 +0100

drm/i915: Use cpu relocations if the object is in the GTT but not mappable

This prevents the case of unbinding the object in order to process the
relocations through the GTT and then rebinding it only to then proceed
to use cpu relocations as the object is now in the CPU write domain. By
choosing to use cpu relocations up front, we can therefore avoid the
rebind penalty.

Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 

:04 04 090ed3d52b4f3210b988877f747b6ff86e123385 
1d48be89ded4777a543b693db833de64877059c4 M  drivers

Regards,
Peter

[PATCH] drm: exynos: fix for mapping of dma buffers

[Rahul Sharma]

This patch fixes the problem of mapping contigous and non contigous dma buffers.

Currently page struct is calculated from the buf->dma_addr which is not the
physical address. It is replaced by buf->pages which points to the page struct
of the first page of contigous memory chunk. This gives the correct page frame
number for mapping.

Non-contigous dma buffers are described using SG table and SG lists. Each
valid SG List is pointing to a single page or group of pages which are
physically contigous. Current implementation just maps the first page of each
SG List and leave the other pages unmapped, leading to a crash. Given solution
finds the page struct for the faulting page through parsing SG table and map it.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   28 +---
 1 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8cb6824..50d73f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -95,15 +95,37 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object 
*obj,
 {
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
+   struct scatterlist *sgl;
unsigned long pfn;
+   int i;

if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
+   if (!buf->sgt)
+   return -EINTR;
+
+   sgl = buf->sgt->sgl;
+   for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
+   if (!sgl) {
+   DRM_ERROR("invalid SG table\n");
+   return -EINTR;
+   }
+   if (page_offset < (sgl->length >> PAGE_SHIFT))
+   break;
+   page_offset -=  (sgl->length >> PAGE_SHIFT);
+   }
+
+   if (i >= buf->sgt->nents) {
+   DRM_ERROR("invalid page offset\n");
+   return -EINVAL;
+   }
+
+   pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
+   } else {
if (!buf->pages)
return -EINTR;

-   pfn = page_to_pfn(buf->pages[page_offset++]);
-   } else
-   pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
+   pfn = page_to_pfn(buf->pages[0]) + page_offset;
+   }

return vm_insert_mixed(vma, f_vaddr, pfn);
 }
-- 
1.7.0.4

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

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

https://bugs.freedesktop.org/show_bug.cgi?id=56081

--- Comment #10 from Tony Thomas  ---
Of note: with most kernel combo and 8.0 mesa branch (also tried on Arch Linux),
failures and corruption DO NOT prevent VT-switching as the 9.0 branch does.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/a08cad9d/attachment.html>

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

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

https://bugs.freedesktop.org/show_bug.cgi?id=56081

Tony Thomas  changed:

   What|Removed |Added

  Attachment #68713|0   |1
is obsolete||

--- Comment #9 from Tony Thomas  ---
Created attachment 69580
  --> https://bugs.freedesktop.org/attachment.cgi?id=69580=edit
Debian Sid w/3.6.8-pf xorg.0.log (fail)

Xorg.0.log from above failure (Debian Sid, 3.6.8-pf kernel)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/3a4df1cb/attachment-0001.html>

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

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

https://bugs.freedesktop.org/show_bug.cgi?id=56081

Tony Thomas  changed:

   What|Removed |Added

  Attachment #68684|0   |1
is obsolete||
  Attachment #68717|0   |1
is obsolete||

--- Comment #8 from Tony Thomas  ---
Created attachment 69579
  --> https://bugs.freedesktop.org/attachment.cgi?id=69579=edit
Debian Sid w/3.6.8-pf dmesg (drm.debug=6)

Switched system to Debian Sid, clean install. Sid is tracking 8.0.5-1 mesa
http://packages.debian.org/search?keywords=mesa=names=unstable=all

Screen corruption still, using Sid 3.2.0-4 stock kernel, and 3.6.8-pf kernel
from here: http://kernel.night-leshiy.ru/

Attaching drm.debug=6 dmesg from Debian 3.6.8-pf kernel

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/23436beb/attachment.html>

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

Alex Deucher wrote:
> On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss  wrote:
>> Alex Deucher wrote:
>>>
>>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss  wrote:

 For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
 and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
 and then turn TV on and -

 xrandr --output DVI-0 --auto

 to bring up the the TV and get a clone of monitor.

 This still works with drm-core-next but not with drm-fixes (todays or
 from a
 few days ago).

 With df I now loose the monitor with signal out of range when doing
 above,
 the TV output is OK. To get the monitor back I need to turn off TV, then
 off/auto the monitor.

 xrandr --output DVI-0 --off
 xrandr --output DVI-1 --off
 xrandr --output DVI-1 --auto

 The output from xrandr while the monitor is showing signal out of range
 looks normal.

 If I boot with the TV on it works OK.
>>>
>>>
>>> Can you bisect?
>>
>>
>> 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
>> commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
>> Author: Alex Deucher 
>> Date:   Fri Oct 5 10:22:02 2012 -0400
>>
>>  drm/radeon: allocate PPLLs from low to high
>>
>>  The order shouldn't matter, but there have been problems
>>  reported on certain older asics.  This behaves more
>>  like the original code before the PPLL allocation
>>  rework.
>>
>>  Signed-off-by: Alex Deucher 
>>  Cc:  Markus Trippelsdorf 
>>
>>
>
> That's bizarre.  That patch reverts the behavior back to the 3.6 and
> earlier kernel behavior.  I guess it's some issue with the ordering of
> the modesetting programming sequence.  I've attached a couple of
> things to try.
>
> The first patch is a simple fix.  It just reverts back to the previous
> pll allocation order for discrete cards like yours:
> 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch
>
> The second set of patches implements a more complex fix which may help
> regardless of the order in which plls are allocated:
> 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
> 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
> 0003-drm-radeon-disable-the-pll-before-a-modeset.patch
>
> Can you see if the second set helps?  If not, please try the first patch.

The second set doesn't fix it.

The first patch does.

nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

[Antonio Ospite]

On Mon, 5 Nov 2012 08:40:38 +
Dave Airlie  wrote:

> On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite  
> wrote:
> > On Mon, 29 Oct 2012 23:16:24 +0100
> > Antonio Ospite  wrote:
> >
> >> Hi,
> >>
> >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> >> my video adapter is the one integrated on the MSI M3N78-VM motherboard
> >> (hence x86_64):
> >>
> > [...]
> >> [ 1943.858601] BUG: unable to handle kernel paging request at 
> >> fff8
> >> [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 
> >> [nouveau]
> >> [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0
> >> [ 1943.858803] Oops:  [#1] SMP
> > [..]
> >> [ 1943.860018] Call Trace:
> >> [ 1943.860019]  [] ? kmem_cache_alloc_trace+0xbf/0xcf
> >> [ 1943.860019]  [] ? should_resched+0x5/0x23
> >> [ 1943.860019]  [] ? nv50_fb_vram_new+0xc5/0x1f2 
> >> [nouveau]
> >
> > Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits
> > a7dbf00 and 5cad16a which seem to be related to the problem I was
> > having; would you mind elaborating a bit about what you think was
> > causing the crash on my side? Maybe the chipset used on this motherboard
> > doesn't support some feature? And how did you figured out from the logs?
> >
> 
> 5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix
> 
> The chipset hasn't got Z compression support, and the oops once decoded 
> pointed
> out the new code was trying to allocate Z tags from a NULL memory block. The 
> old
> code use to allocate an empty memory block instead of NULL, and it got
> lost in the
> rewrite, Ben just fixed it to allow empty memory blocks again.
> 
> Dave.
> 

Thanks a lot for the explanation.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

merging printk and WARN

[David Sterba]

On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote:
> It looks like these patches were not a good idea, because in each case the
> printk provides an error level, and WARN then provides another one.

I think this is not a problem within btrfs at the place where this has
changed.

david

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #16 from Alex Deucher  ---
Created attachment 69573
  --> https://bugs.freedesktop.org/attachment.cgi?id=69573=edit
possible fix

Actually, I think I found the problem.  Missing index in mc_resume().

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/ce8d9998/attachment.html>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #15 from Alex Deucher  ---
(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Found what is wrong with the help of a few printk and by comparing to the
> > > code being replaced. All the logic is good (going through crtc, disabling
> > > them, waiting for vblank) BUT setting "tmp |=
> > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> > > 
> > > If I do as in the previous code by setting tmp = 0 and then continuing 
> > > with:
> > > radeon_wait_for_vblank(rdev, i);
> > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> > > everything works fine as before.
> > > 
> > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> > > From what I read with printk, it is far from a 0 or a 1. Is this normal?
> > 
> > That's the most important bit in the entire sequence.  It's a bit field in a
> > register (bit 24 to be exact).  That bit is the bit that actually disables
> > the requests from the display controller in the memory controller.  The
> > whole point of this code is to disable all clients of the memory controller
> > (mc_stop()) so that we can change the location of vram within the GPU's
> > address space.  Once we've moved vram, we can re-enable the clients
> > (mc_resume()) so that they point to the new vram location.
> 
> Thank you, you confirmed what I had assumed. I had already understood that
> it was the most important part in the sequence since it is associated to a
> "write" instruction. I don't have the (decimal/binary) values with me right
> now, but I'll be able to give you what was read from the register and from
> the result returned from the bitwise OR assignment we are pushing in the
> register. I'll confirm which bit(s) are changing. I'm sure the assignment
> was setting one (or more) bit in the register to "1". Is bit 24 the only one
> expected to change in the register? Should it be put to "1" or "0"?
> 

Setting bit 24 to 1 disables memory requests from the display controller. 
Setting bit 24 to 0, enables memory requests from the display controller.

> Another question: why were we setting "0" in the register before? By doing
> so, we were setting the whole register to "0" (the whole 32 bits), right? If
> I remember correctly, from what I saw yesterday with the help of printk, it
> seems we are setting at least one bit to "1" in this register, which would
> be the opposite of what was being done before and therefore of what was
> working correctly with my video card. I'm just trying to understand why we
> were doing something in the first place that was working correctly and that
> was introduce to fix this problem in the first place, both at boot time for
> grub (set gfxpayload=keep) and when suspending/resuming, and we are now
> doing the opposite, thus breaking the code for some setups. Is it possible
> that the bit/register logic is not the same for all Radeon GPUs? After all,
> we already introduced a different path for DCE6.

Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc is
disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled (bit 0
= 0) bit 24 is irrelevant.  There are separate bits to enable the crtc and
disable memory requests since there are cases (like this one) where we want to
keep the crtc timing running so that the monitor stays synced, but disable
reads from memory so we can reconfigure the memory controller.  If we disable
the crtc entirely, the monitor would lose sync and you would get additional
flicker during boot up.  Ideally, eventually we'd like to just hand over
control from the firmware without touching the display hardware so the user
gets a flicker free boot experience.

DCE4 and 5 have the same logic and bit layout for these registers.  The logic
is different on DCE6 chips.  On DCE6, the the memory controller request bit is
now tied in with the crtc blanking bit.  When the crtc is blanked, memory
requests are also disabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/f62d09d7/attachment.html>

[PATCH 4/4] drm/ttm: Optimize reservation slightly

[Thomas Hellstrom]

On 11/05/2012 03:01 PM, Maarten Lankhorst wrote:
> Hey,
>
> Op 05-11-12 14:31, Thomas Hellstrom schreef:
>> Reservation locking currently always takes place under the LRU spinlock.
>> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
>> atomic_read followed by atomic_write since nobody else will ever reserve
>> without the lru spinlock held.
>> At least on Intel this should remove a locked bus cycle on successful
>> reserve.
>>
>> Signed-off-by: Thomas Hellstrom 
>>
> Is that really a good thing to submit when I am busy killing lru lock around 
> reserve? :-)
>

If your patch series makes it into the same kernel, let's kill this 
patch. Otherwise it may live
at least for a kernel release. It's not a big thing to rebase against, 
and I won't complain if your
patch adds another atomic read-modify-write op here. :)

/Thomas

[PATCH 4/4] drm/ttm: Optimize reservation slightly

[Maarten Lankhorst]

Hey,

Op 05-11-12 14:31, Thomas Hellstrom schreef:
> Reservation locking currently always takes place under the LRU spinlock.
> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
> atomic_read followed by atomic_write since nobody else will ever reserve
> without the lru spinlock held.
> At least on Intel this should remove a locked bus cycle on successful
> reserve.
>
> Signed-off-by: Thomas Hellstrom 
>
Is that really a good thing to submit when I am busy killing lru lock around 
reserve? :-)

-   while (unlikely(atomic_cmpxchg(>reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_xchg(>reserved, 1) != 0)) {

Works without lru lock too!

In fact mutexes are done in a similar way[1], except with some more magic, and 
unlocked state is 1, not 0.
However I do think that to get that right (saves a irq disable in unlock path, 
and less wakeups in contended
case), I should really just post the mutex extension patches for reservations 
and ride the flames. It's
getting too close to real mutexes so I really want it to be a mutex in that 
case. So lets convert it.. Soon! :-)

~Maarten

[1] See linux/include/asm-generic/mutex-xchg.h and 
linux/include/asm-generic/mutex-dec.h for how
archs generally implement mutex fastpaths.

[PATCH 4/4] drm/ttm: Optimize reservation slightly

[Thomas Hellstrom]

Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo->glob;
int ret;

-   while (unlikely(atomic_cmpxchg(>reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_read(>reserved) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}

+   atomic_set(>reserved, 1);
if (use_sequence) {
/**
 * Wake up waiters that may need to recheck for deadlock,
-- 
1.7.4.4

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v2

[Thomas Hellstrom]

The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.

v2: Don't touch include/linux/kref.h

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_object.c |   30 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8 
 include/drm/ttm/ttm_object.h |4 
 3 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
  */

 struct ttm_object_device {
-   rwlock_t object_lock;
+   spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
-   write_lock(>object_lock);
+   spin_lock(>object_lock);
kref_init(>refcount);
ret = drm_ht_just_insert_please(>object_hash,
>hash,
(unsigned long)base, 31, 0, 0);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);
if (unlikely(ret != 0))
goto out_err0;

@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;

+   spin_lock(>object_lock);
(void)drm_ht_remove_item(>object_hash, >hash);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);
if (base->refcount_release) {
ttm_object_file_unref(>tfile);
base->refcount_release();
}
-   write_lock(>object_lock);
 }

 void ttm_base_object_unref(struct ttm_base_object **p_base)
 {
struct ttm_base_object *base = *p_base;
-   struct ttm_object_device *tdev = base->tfile->tdev;

*p_base = NULL;

-   /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
-   write_lock(>object_lock);
kref_put(>refcount, ttm_release_base);
-   write_unlock(>object_lock);
 }
 EXPORT_SYMBOL(ttm_base_object_unref);

@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;

-   read_lock(>object_lock);
+   rcu_read_lock();
ret = drm_ht_find_item(>object_hash, key, );

if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
-   kref_get(>refcount);
+   ret = kref_get_unless_zero(>refcount);
}
-   read_unlock(>object_lock);
+   rcu_read_unlock();

if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
return NULL;

tdev->mem_glob = mem_glob;
-   rwlock_init(>object_lock);
+   spin_lock_init(>object_lock);
atomic_set(>object_count, 0);
ret = drm_ht_create(>object_hash, hash_order);

@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)

*p_tdev = NULL;

-   write_lock(>object_lock);
+   spin_lock(>object_lock);
drm_ht_remove(>object_hash);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);

kfree(tdev);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;

-   kfree(ctx);
+   ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
 }
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
-   kfree(user_srf);
+   ttm_base_object_kfree(user_srf, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
 }

@@ -1575,7 +1575,7 @@ static void vmw_user_dmabuf_destroy(struct 
ttm_buffer_object *bo)
 {
struct vmw_user_dma_buffer *vmw_user_bo = vmw_user_dma_buffer(bo);

[PATCH 2/4] kref: Implement kref_get_unless_zero v2

[Thomas Hellstrom]

This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.

v2: Formatting fixes.

Signed-off-by: Thomas Hellstrom 
---
 include/linux/kref.h |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..bae91d0 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
 }
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+ *
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+   return !atomic_add_unless(>refcount, 1, 0);
+}
 #endif /* _KREF_H_ */
-- 
1.7.4.4

[PATCH 1/4] drm: Make hashtab rcu-safe

[Thomas Hellstrom]

TTM base objects will be the first consumer.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/drm_hashtab.c |   18 +++---
 1 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned 
long key)
hashed_key = hash_long(key, ht->order);
DRM_DEBUG("Key is 0x%08lx, Hashed key is 0x%08x\n", key, hashed_key);
h_list = >table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG("count %d, key: 0x%08lx\n", count++, entry->key);
-   }
 }

 static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct 
drm_open_hash *ht,

hashed_key = hash_long(key, ht->order);
h_list = >table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return list;
if (entry->key > key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
hashed_key = hash_long(key, ht->order);
h_list = >table[hashed_key];
parent = NULL;
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return -EINVAL;
if (entry->key > key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
parent = list;
}
if (parent) {
-   hlist_add_after(parent, >head);
+   hlist_add_after_rcu(parent, >head);
} else {
-   hlist_add_head(>head, h_list);
+   hlist_add_head_rcu(>head, h_list);
}
return 0;
 }
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)

list = drm_ht_find_key(ht, key);
if (list) {
-   hlist_del_init(list);
+   hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)

 int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
 {
-   hlist_del_init(>head);
+   hlist_del_init_rcu(>head);
return 0;
 }
 EXPORT_SYMBOL(drm_ht_remove_item);
-- 
1.7.4.4

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops v2

[Thomas Hellstrom]

A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down.

v2: Formatting fixes.

In-Reply-To: 

>From Thomas Hellstrom  # This line is ignored.
From: Thomas Hellstrom 
Subject: 
In-Reply-To: 

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #14 from Alexandre Demers  ---
(In reply to comment #12)
> (In reply to comment #11)
> > Found what is wrong with the help of a few printk and by comparing to the
> > code being replaced. All the logic is good (going through crtc, disabling
> > them, waiting for vblank) BUT setting "tmp |=
> > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> > 
> > If I do as in the previous code by setting tmp = 0 and then continuing with:
> > radeon_wait_for_vblank(rdev, i);
> > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> > everything works fine as before.
> > 
> > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> > From what I read with printk, it is far from a 0 or a 1. Is this normal?
> 
> That's the most important bit in the entire sequence.  It's a bit field in a
> register (bit 24 to be exact).  That bit is the bit that actually disables
> the requests from the display controller in the memory controller.  The
> whole point of this code is to disable all clients of the memory controller
> (mc_stop()) so that we can change the location of vram within the GPU's
> address space.  Once we've moved vram, we can re-enable the clients
> (mc_resume()) so that they point to the new vram location.

Thank you, you confirmed what I had assumed. I had already understood that it
was the most important part in the sequence since it is associated to a "write"
instruction. I don't have the (decimal/binary) values with me right now, but
I'll be able to give you what was read from the register and from the result
returned from the bitwise OR assignment we are pushing in the register. I'll
confirm which bit(s) are changing. I'm sure the assignment was setting one (or
more) bit in the register to "1". Is bit 24 the only one expected to change in
the register? Should it be put to "1" or "0"?

Another question: why were we setting "0" in the register before? By doing so,
we were setting the whole register to "0" (the whole 32 bits), right? If I
remember correctly, from what I saw yesterday with the help of printk, it seems
we are setting at least one bit to "1" in this register, which would be the
opposite of what was being done before and therefore of what was working
correctly with my video card. I'm just trying to understand why we were doing
something in the first place that was working correctly and that was introduce
to fix this problem in the first place, both at boot time for grub (set
gfxpayload=keep) and when suspending/resuming, and we are now doing the
opposite, thus breaking the code for some setups. Is it possible that the
bit/register logic is not the same for all Radeon GPUs? After all, we already
introduced a different path for DCE6.

I'll also try your patch when I'll get home tonight.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/c151856a/attachment.html>

[PATCH] drm/exynos: add userptr feature for g2d module

[Inki Dae]

This patch adds userptr feautre for G2D module.

The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.

To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_cmd and fill
struct drm_exynos_g2d_userptr with user space address
and size for it and then should set a pointer to
drm_exynos_g2d_userptr object to data variable of struct
drm_exynos_g2d_cmd. The last bit of offset variable is used
to check if the cmdlist's buffer type is userptr or not.
If userptr, the g2d driver gets user space address and size
and then gets pages through get_user_pages().
(another case is counted as gem handle)

Below is sample codes:

static void set_cmd(struct drm_exynos_g2d_cmd *cmd,
unsigned long offset, unsigned long data)
{
cmd->offset = offset;
cmd->data = data;
}

static int solid_fill_test(int x, int y, unsigned long userptr)
{
struct drm_exynos_g2d_cmd cmd_gem[5];
struct drm_exynos_g2d_userptr g2d_userptr;
unsigned int gem_nr = 0;
...

g2d_userptr.userptr = userptr;
g2d_userptr.size = x * y * 4;

set_cmd(_gem[gem_nr++], DST_BASE_ADDR_REG |
G2D_BUF_USERPTR,
(unsigned long)_userptr);
...
}

int main(int argc, char **argv)
{
unsigned long addr;
...

addr = malloc(x * y * 4);
...

solid_fill_test(x, y, addr);
...
}

And next, the pages are mapped with iommu table and the device
address is set to cmdlist so that G2D's dma can access it.
As you may know, the pages from get_user_pages() are pinned.
In other words, they CAN NOT be migrated and also swapped out.
So the dma access would be safe.

But the use of userptr feature has performance overhead so
this patch also has memory pool to the userptr feature.
Please, assume that user sends cmdlist filled with userptr
and size every time to g2d driver, and the get_user_pages
funcion will be called every time.

The memory pool has maximum 64MB size and the userptr that
user had ever sent, is holded in the memory pool.
This meaning is that if the userptr from user is same as one
in the memory pool, device address to the userptr in the memory
pool is set to cmdlist.

And last, the pages from get_user_pages() will be freed once
user calls free() and the dma access is completed. Actually,
get_user_pages() takes 2 reference counts if the user process
has never accessed user region allocated by malloc(). Then, if
the user calls free(), the page reference count becomes 1 and
becomes 0 with put_page() call. And the reverse holds as well.
This means how the pages backed are used by dma and freed.

This patch is based on "drm/exynos: add iommu support for g2d",
https://patchwork.kernel.org/patch/1629481/

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |3 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  342 --
 drivers/gpu/drm/exynos/exynos_drm_gem.c |  123 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.h |   45 
 include/uapi/drm/exynos_drm.h   |   13 +-
 5 files changed, 499 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a9db025..a4702a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -231,8 +231,7 @@ struct exynos_drm_g2d_private {
struct device   *dev;
struct list_headinuse_cmdlist;
struct list_headevent_list;
-   struct list_headgem_list;
-   unsigned intgem_nr;
+   struct list_headuserptr_list;
 };

 struct drm_exynos_file_private {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index bac2399..a9002ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -97,11 +97,19 @@

 #define MAX_BUF_ADDR_NR6

+/* maximum buffer pool size of userptr is 64MB as default */
+#define MAX_POOL   (64 * 1024 * 1024)
+
+enum {
+   BUF_TYPE_GEM = 1,
+   BUF_TYPE_USERPTR,
+};
+
 /* cmdlist data structure */
 struct g2d_cmdlist {
-   u32 head;
-   u32 data[G2D_CMDLIST_DATA_NUM];
-   u32 last;   /* last data offset */
+   u32 head;
+   unsigned long   data[G2D_CMDLIST_DATA_NUM];
+   u32 last;   /* last data offset */
 };

 struct drm_exynos_pending_g2d_event {
@@ -109,11 +117,26 @@ struct drm_exynos_pending_g2d_event {
struct drm_exynos_g2d_event event;
 };

+struct g2d_cmdlist_userptr {
+   struct list_headlist;
+   dma_addr_t  dma_addr;
+   unsigned long   userptr;
+   unsigned long   

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

[Thomas Hellstrom]

On 11/05/2012 02:31 PM, Thomas Hellstrom wrote:
> The mostly used lookup+get put+potential_destroy path of TTM objects
> is converted to use RCU locks. This will substantially decrease the amount
> of locked bus cycles during normal operation.
> Since we use kfree_rcu to free the objects, no rcu synchronization is needed
> at module unload time.
>
> Signed-off-by: Thomas Hellstrom 
> ---
>   drivers/gpu/drm/ttm/ttm_object.c |   30 
> +++---
>   drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8 
>   include/drm/ttm/ttm_object.h |4 
>   include/linux/kref.h |2 +-
>   4 files changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_object.c 
> b/drivers/gpu/drm/ttm/ttm_object.c
> index c785787..9d7f674 100644
> --- a/drivers/gpu/drm/ttm/ttm_object.c
> +++ b/drivers/gpu/drm/ttm/ttm_object.c
> @@ -80,7 +80,7 @@ struct ttm_object_file {
>*/
>   
>   struct ttm_object_device {
> - rwlock_t object_lock;
> + spinlock_t object_lock;
>   struct drm_open_hash object_hash;
>   atomic_t object_count;
>   struct ttm_mem_global *mem_glob;
> @@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
>   base->refcount_release = refcount_release;
>   base->ref_obj_release = ref_obj_release;
>   base->object_type = object_type;
> - write_lock(>object_lock);
> + spin_lock(>object_lock);
>   kref_init(>refcount);
>   ret = drm_ht_just_insert_please(>object_hash,
>   >hash,
>   (unsigned long)base, 31, 0, 0);
> - write_unlock(>object_lock);
> + spin_unlock(>object_lock);
>   if (unlikely(ret != 0))
>   goto out_err0;
>   
> @@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
>   container_of(kref, struct ttm_base_object, refcount);
>   struct ttm_object_device *tdev = base->tfile->tdev;
>   
> + spin_lock(>object_lock);
>   (void)drm_ht_remove_item(>object_hash, >hash);
> - write_unlock(>object_lock);
> + spin_unlock(>object_lock);
>   if (base->refcount_release) {
>   ttm_object_file_unref(>tfile);
>   base->refcount_release();
>   }
> - write_lock(>object_lock);
>   }
>   
>   void ttm_base_object_unref(struct ttm_base_object **p_base)
>   {
>   struct ttm_base_object *base = *p_base;
> - struct ttm_object_device *tdev = base->tfile->tdev;
>   
>   *p_base = NULL;
>   
> - /*
> -  * Need to take the lock here to avoid racing with
> -  * users trying to look up the object.
> -  */
> -
> - write_lock(>object_lock);
>   kref_put(>refcount, ttm_release_base);
> - write_unlock(>object_lock);
>   }
>   EXPORT_SYMBOL(ttm_base_object_unref);
>   
> @@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
> ttm_object_file *tfile,
>   struct drm_hash_item *hash;
>   int ret;
>   
> - read_lock(>object_lock);
> + rcu_read_lock();
>   ret = drm_ht_find_item(>object_hash, key, );
>   
>   if (likely(ret == 0)) {
>   base = drm_hash_entry(hash, struct ttm_base_object, hash);
> - kref_get(>refcount);
> + ret = kref_get_unless_zero(>refcount);
>   }
> - read_unlock(>object_lock);
> + rcu_read_unlock();
>   
>   if (unlikely(ret != 0))
>   return NULL;
> @@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
> ttm_mem_global
>   return NULL;
>   
>   tdev->mem_glob = mem_glob;
> - rwlock_init(>object_lock);
> + spin_lock_init(>object_lock);
>   atomic_set(>object_count, 0);
>   ret = drm_ht_create(>object_hash, hash_order);
>   
> @@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device 
> **p_tdev)
>   
>   *p_tdev = NULL;
>   
> - write_lock(>object_lock);
> + spin_lock(>object_lock);
>   drm_ht_remove(>object_hash);
> - write_unlock(>object_lock);
> + spin_unlock(>object_lock);
>   
>   kfree(tdev);
>   }
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index da3c6b5..ae675c6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource 
> *res)
>   container_of(res, struct vmw_user_context, res);
>   struct vmw_private *dev_priv = res->dev_priv;
>   
> - kfree(ctx);
> + ttm_base_object_kfree(ctx, base);
>   ttm_mem_global_free(vmw_mem_glob(dev_priv),
>   vmw_user_context_size);
>   }
> @@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
> *res)
>   kfree(srf->offsets);
>   kfree(srf->sizes);
>   kfree(srf->snooper.image);
> - kfree(user_srf);
> + ttm_base_object_kfree(user_srf, 

[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled

[Rahul Sharma]

This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.

This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

This patch is having dependency on  linux-samsung-soc patchset named
"add dt based support for iommu for hdmi"

Signed-off-by: Rahul Sharma 
Signed-off-by: Prathyush K 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   35 ++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d1a1d71..ee110c9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 

 #include 

@@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client 
*hdmiphy)
 }

 #ifdef CONFIG_OF
+
+static int drm_hdmi_dt_init_iommu(struct device *dev)
+{
+   struct platform_device *pds;
+   struct device_node *dn, *dns;
+   const __be32 *parp;
+
+   dn = dev->of_node;
+   parp = of_get_property(dn, "sysmmu", NULL);
+   if (parp == NULL) {
+   dev_err(dev, "failed to find sysmmu property\n");
+   return -EINVAL;
+   }
+   dns = of_find_node_by_phandle(be32_to_cpup(parp));
+   if (dns == NULL) {
+   dev_err(dev, "failed to find sysmmu node\n");
+   return -EINVAL;
+   }
+   pds = of_find_device_by_node(dns);
+   if (pds == NULL) {
+   dev_err(dev, "failed to find sysmmu platform device\n");
+   return -EINVAL;
+   }
+
+   platform_set_sysmmu(>dev, dev);
+   return 0;
+}
+
 static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
 {
@@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
goto err_data;
}

+   if (drm_hdmi_dt_init_iommu(dev)){
+   DRM_ERROR("no sysmmu property found\n");
+   goto err_data;
+   }
+
pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, );

return pd;
-- 
1.7.0.4

[PATCH 4/4] drm/ttm: Optimize reservation slightly

[Thomas Hellstrom]

Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo->glob;
int ret;

-   while (unlikely(atomic_cmpxchg(>reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_read(>reserved) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}

+   atomic_set(>reserved, 1);
if (use_sequence) {
/**
 * Wake up waiters that may need to recheck for deadlock,
-- 
1.7.4.4

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

[Thomas Hellstrom]

The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_object.c |   30 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8 
 include/drm/ttm/ttm_object.h |4 
 include/linux/kref.h |2 +-
 4 files changed, 20 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
  */

 struct ttm_object_device {
-   rwlock_t object_lock;
+   spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
-   write_lock(>object_lock);
+   spin_lock(>object_lock);
kref_init(>refcount);
ret = drm_ht_just_insert_please(>object_hash,
>hash,
(unsigned long)base, 31, 0, 0);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);
if (unlikely(ret != 0))
goto out_err0;

@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;

+   spin_lock(>object_lock);
(void)drm_ht_remove_item(>object_hash, >hash);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);
if (base->refcount_release) {
ttm_object_file_unref(>tfile);
base->refcount_release();
}
-   write_lock(>object_lock);
 }

 void ttm_base_object_unref(struct ttm_base_object **p_base)
 {
struct ttm_base_object *base = *p_base;
-   struct ttm_object_device *tdev = base->tfile->tdev;

*p_base = NULL;

-   /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
-   write_lock(>object_lock);
kref_put(>refcount, ttm_release_base);
-   write_unlock(>object_lock);
 }
 EXPORT_SYMBOL(ttm_base_object_unref);

@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;

-   read_lock(>object_lock);
+   rcu_read_lock();
ret = drm_ht_find_item(>object_hash, key, );

if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
-   kref_get(>refcount);
+   ret = kref_get_unless_zero(>refcount);
}
-   read_unlock(>object_lock);
+   rcu_read_unlock();

if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
return NULL;

tdev->mem_glob = mem_glob;
-   rwlock_init(>object_lock);
+   spin_lock_init(>object_lock);
atomic_set(>object_count, 0);
ret = drm_ht_create(>object_hash, hash_order);

@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)

*p_tdev = NULL;

-   write_lock(>object_lock);
+   spin_lock(>object_lock);
drm_ht_remove(>object_hash);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);

kfree(tdev);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;

-   kfree(ctx);
+   ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
 }
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
-   kfree(user_srf);
+   ttm_base_object_kfree(user_srf, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
 }

@@ -1575,7 +1575,7 @@ static void vmw_user_dmabuf_destroy(struct 
ttm_buffer_object *bo)
 {
struct vmw_user_dma_buffer *vmw_user_bo = 

[PATCH 2/4] kref: Implement kref_get_unless_zero

[Thomas Hellstrom]

This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.

Signed-off-by: Thomas Hellstrom 
---
 include/linux/kref.h |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..fd16042 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
 }
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+   return !atomic_add_unless(>refcount, 1, 0);
+}
 #endif /* _KREF_H_ */
-- 
1.7.4.4

[PATCH 1/4] drm: Make hashtab rcu-safe

[Thomas Hellstrom]

TTM base objects will be the first consumer.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/drm_hashtab.c |   18 +++---
 1 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned 
long key)
hashed_key = hash_long(key, ht->order);
DRM_DEBUG("Key is 0x%08lx, Hashed key is 0x%08x\n", key, hashed_key);
h_list = >table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG("count %d, key: 0x%08lx\n", count++, entry->key);
-   }
 }

 static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct 
drm_open_hash *ht,

hashed_key = hash_long(key, ht->order);
h_list = >table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return list;
if (entry->key > key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
hashed_key = hash_long(key, ht->order);
h_list = >table[hashed_key];
parent = NULL;
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return -EINVAL;
if (entry->key > key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
parent = list;
}
if (parent) {
-   hlist_add_after(parent, >head);
+   hlist_add_after_rcu(parent, >head);
} else {
-   hlist_add_head(>head, h_list);
+   hlist_add_head_rcu(>head, h_list);
}
return 0;
 }
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)

list = drm_ht_find_key(ht, key);
if (list) {
-   hlist_del_init(list);
+   hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)

 int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
 {
-   hlist_del_init(>head);
+   hlist_del_init_rcu(>head);
return 0;
 }
 EXPORT_SYMBOL(drm_ht_remove_item);
-- 
1.7.4.4

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops

[Thomas Hellstrom]

A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down.

In-Reply-To: 

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #13 from Alex Deucher  ---
Created attachment 69564
  --> https://bugs.freedesktop.org/attachment.cgi?id=69564=edit
possible fix

Slightly adjusted wait for vblank function.  Maybe this will help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/42dbed96/attachment.html>

[Bug 17511] Display no longer works with KMS enabled

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

https://bugzilla.kernel.org/show_bug.cgi?id=17511


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INSUFFICIENT_DATA




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 16065] linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor.

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

https://bugzilla.kernel.org/show_bug.cgi?id=16065


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

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

https://bugzilla.kernel.org/show_bug.cgi?id=16193


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

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

https://bugzilla.kernel.org/show_bug.cgi?id=16193


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk




--- Comment #2 from Alan   2012-11-05 14:16:22 ---
Closing as obsolete. If this is still seen on modern kernels (3.2+) please
update/reopen

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

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

https://bugzilla.kernel.org/show_bug.cgi?id=49981


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 AssignedTo|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #12 from Alex Deucher  ---
(In reply to comment #11)
> Found what is wrong with the help of a few printk and by comparing to the
> code being replaced. All the logic is good (going through crtc, disabling
> them, waiting for vblank) BUT setting "tmp |=
> EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> 
> If I do as in the previous code by setting tmp = 0 and then continuing with:
> radeon_wait_for_vblank(rdev, i);
> WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> everything works fine as before.
> 
> What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> From what I read with printk, it is far from a 0 or a 1. Is this normal?

That's the most important bit in the entire sequence.  It's a bit field in a
register (bit 24 to be exact).  That bit is the bit that actually disables the
requests from the display controller in the memory controller.  The whole point
of this code is to disable all clients of the memory controller (mc_stop()) so
that we can change the location of vram within the GPU's address space.  Once
we've moved vram, we can re-enable the clients (mc_resume()) so that they point
to the new vram location.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/f777c29e/attachment.html>

[PATCH v4] drm/exynos: add iommu support for exynos drm framework

[Inki Dae]

Changelog v4:
- fix condition to drm_iommu_detach_device funtion.

Changelog v3:
- add dma_parms->max_segment_size setting of drm_device->dev.
- use devm_kzalloc instead of kzalloc.

Changelog v2:
- fix iommu attach condition.
  . check archdata.dma_ops of drm device instead of
subdrv device's one.
- code clean to exynos_drm_iommu.c file.
  . remove '#ifdef CONFIG_ARM_DMA_USE_IOMMU' from exynos_drm_iommu.c
and add it to driver/gpu/drm/exynos/Kconfig.

Changelog v1:
This patch adds iommu support for exynos drm framework with dma mapping
api. In this patch, we used dma mapping api to allocate physical memory
and maps it with iommu table and removed some existing codes and added
new some codes for iommu support.

GEM allocation requires one device object to use dma mapping api so
this patch uses one iommu mapping for all sub drivers. In other words,
all sub drivers have same iommu mapping.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig |6 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_drm_buf.c|   88 +
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |   87 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   23 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   11 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c |   52 +++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c|  210 ++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h|1 +
 drivers/gpu/drm/exynos/exynos_drm_iommu.c  |  150 
 drivers/gpu/drm/exynos/exynos_drm_iommu.h  |   85 +++
 11 files changed, 409 insertions(+), 305 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 59a26e5..4ea8cdc 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -10,6 +10,12 @@ config DRM_EXYNOS
  Choose this option if you have a Samsung SoC EXYNOS chipset.
  If M is selected the module will be called exynosdrm.

+config DRM_EXYNOS_IOMMU
+   bool "EXYNOS DRM IOMMU Support"
+   depends on DRM_EXYNOS && EXYNOS_IOMMU && ARM_DMA_USE_IOMMU
+   help
+ Choose this option if you want to use IOMMU feature for DRM.
+
 config DRM_EXYNOS_DMABUF
bool "EXYNOS DRM DMABUF"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index eb651ca..26813b8 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,6 +8,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o 
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o

+exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 118c117..48c5896 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -33,71 +33,58 @@
 static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
-   dma_addr_t start_addr;
+   int ret = 0;
unsigned int npages, i = 0;
struct scatterlist *sgl;
-   int ret = 0;
+   enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;

DRM_DEBUG_KMS("%s\n", __FILE__);

-   if (IS_NONCONTIG_BUFFER(flags)) {
-   DRM_DEBUG_KMS("not support allocation type.\n");
-   return -EINVAL;
-   }
-
if (buf->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
return 0;
}

-   if (buf->size >= SZ_1M) {
-   npages = buf->size >> SECTION_SHIFT;
-   buf->page_size = SECTION_SIZE;
-   } else if (buf->size >= SZ_64K) {
-   npages = buf->size >> 16;
-   buf->page_size = SZ_64K;
-   } else {
-   npages = buf->size >> PAGE_SHIFT;
-   buf->page_size = PAGE_SIZE;
+   init_dma_attrs(>dma_attrs);
+
+   if (flags & EXYNOS_BO_NONCONTIG)
+   attr = DMA_ATTR_WRITE_COMBINE;
+
+   dma_set_attr(attr, >dma_attrs);
+
+   buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+   >dma_addr, GFP_KERNEL, >dma_attrs);
+   if (!buf->kvaddr) {
+   DRM_ERROR("failed to allocate buffer.\n");
+   return -ENOMEM;
}

buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!buf->sgt) {
DRM_ERROR("failed to allocate sg table.\n");
-   return -ENOMEM;
+   

[PATCH] drm/radeon: fix typo in evergreen_mc_resume()

[alexdeuc...@gmail.com]

From: Alex Deucher 

Add missing index that may have led us to enabling
more crtcs than necessary.

May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 14313ad..af31f82 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1372,7 +1372,7 @@ void evergreen_mc_resume(struct radeon_device *rdev, 
struct evergreen_mc_save *s
WREG32(BIF_FB_EN, FB_READ_EN | FB_WRITE_EN);

for (i = 0; i < rdev->num_crtc; i++) {
-   if (save->crtc_enabled) {
+   if (save->crtc_enabled[i]) {
if (ASIC_IS_DCE6(rdev)) {
tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + 
crtc_offsets[i]);
tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
-- 
1.7.7.5

Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Alex Deucher]

On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss  wrote:
> Alex Deucher wrote:
>>
>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss  wrote:
>>>
>>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
>>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
>>> and then turn TV on and -
>>>
>>> xrandr --output DVI-0 --auto
>>>
>>> to bring up the the TV and get a clone of monitor.
>>>
>>> This still works with drm-core-next but not with drm-fixes (todays or
>>> from a
>>> few days ago).
>>>
>>> With df I now loose the monitor with signal out of range when doing
>>> above,
>>> the TV output is OK. To get the monitor back I need to turn off TV, then
>>> off/auto the monitor.
>>>
>>> xrandr --output DVI-0 --off
>>> xrandr --output DVI-1 --off
>>> xrandr --output DVI-1 --auto
>>>
>>> The output from xrandr while the monitor is showing signal out of range
>>> looks normal.
>>>
>>> If I boot with the TV on it works OK.
>>
>>
>> Can you bisect?
>
>
> 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
> commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
> Author: Alex Deucher 
> Date:   Fri Oct 5 10:22:02 2012 -0400
>
> drm/radeon: allocate PPLLs from low to high
>
> The order shouldn't matter, but there have been problems
> reported on certain older asics.  This behaves more
> like the original code before the PPLL allocation
> rework.
>
> Signed-off-by: Alex Deucher 
> Cc:  Markus Trippelsdorf 
>
>

That's bizarre.  That patch reverts the behavior back to the 3.6 and
earlier kernel behavior.  I guess it's some issue with the ordering of
the modesetting programming sequence.  I've attached a couple of
things to try.

The first patch is a simple fix.  It just reverts back to the previous
pll allocation order for discrete cards like yours:
0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch

The second set of patches implements a more complex fix which may help
regardless of the order in which plls are allocated:
0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
0003-drm-radeon-disable-the-pll-before-a-modeset.patch

Can you see if the second set helps?  If not, please try the first patch.

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch
Type: text/x-patch
Size: 3153 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
Type: text/x-patch
Size: 3600 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0001.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
Type: text/x-patch
Size: 3166 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0002.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0003-drm-radeon-disable-the-pll-before-a-modeset.patch
Type: text/x-patch
Size: 910 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0003.bin>

[PATCH v7 8/8] drm_modes: add of_videomode helpers

[Thierry Reding]

On Wed, Oct 31, 2012 at 10:28:08AM +0100, Steffen Trumtrar wrote:
[...]
> +/**
> + * of_get_drm_display_mode - get a drm_display_mode from devicetree
> + * @np: device_node with the timing specification
> + * @dmode: will be set to the return value
> + * @index: index into the list of display timings in devicetree
> + * 
> + * DESCRIPTION:

I don't think this is necessary.

> + * This function is expensive and should only be used, if only one mode is 
> to be
> + * read from DT. To get multiple modes start with of_get_display_timing_list 
> ond

You probably meant "and" at the end of this line. Also I'm not even sure
that we should be exposing this function, but rather provide a helper
which automatically adds the parsed modes to a DRM connector object.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/41cb8434/attachment.pgp>

drm i915 hangs on heavy io load

[Norbert Preining]

On So, 04 Nov 2012, Dave Airlie wrote:
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.

Ok, thanks, didn't know that. Have started the bisect game now,
coming back in about 1 year ;-)

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
--- Douglas Adams, The Meaning of Liff

nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

[Antonio Ospite]

On Mon, 29 Oct 2012 23:16:24 +0100
Antonio Ospite  wrote:

> Hi,
> 
> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> my video adapter is the one integrated on the MSI M3N78-VM motherboard
> (hence x86_64):
> 
[...]
> [ 1943.858601] BUG: unable to handle kernel paging request at fff8
> [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 [nouveau]
> [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 
> [ 1943.858803] Oops:  [#1] SMP 
[..]
> [ 1943.860018] Call Trace:
> [ 1943.860019]  [] ? kmem_cache_alloc_trace+0xbf/0xcf
> [ 1943.860019]  [] ? should_resched+0x5/0x23
> [ 1943.860019]  [] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau]

Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits
a7dbf00 and 5cad16a which seem to be related to the problem I was
having; would you mind elaborating a bit about what you think was
causing the crash on my side? Maybe the chipset used on this motherboard
doesn't support some feature? And how did you figured out from the logs?

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

[Dave Airlie]

On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite  
wrote:
> On Mon, 29 Oct 2012 23:16:24 +0100
> Antonio Ospite  wrote:
>
>> Hi,
>>
>> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
>> my video adapter is the one integrated on the MSI M3N78-VM motherboard
>> (hence x86_64):
>>
> [...]
>> [ 1943.858601] BUG: unable to handle kernel paging request at 
>> fff8
>> [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 [nouveau]
>> [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0
>> [ 1943.858803] Oops:  [#1] SMP
> [..]
>> [ 1943.860018] Call Trace:
>> [ 1943.860019]  [] ? kmem_cache_alloc_trace+0xbf/0xcf
>> [ 1943.860019]  [] ? should_resched+0x5/0x23
>> [ 1943.860019]  [] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau]
>
> Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits
> a7dbf00 and 5cad16a which seem to be related to the problem I was
> having; would you mind elaborating a bit about what you think was
> causing the crash on my side? Maybe the chipset used on this motherboard
> doesn't support some feature? And how did you figured out from the logs?
>

5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix

The chipset hasn't got Z compression support, and the oops once decoded pointed
out the new code was trying to allocate Z tags from a NULL memory block. The old
code use to allocate an empty memory block instead of NULL, and it got
lost in the
rewrite, Ben just fixed it to allow empty memory blocks again.

Dave.

[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

[Rob Clark]

On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
>>> But even then, choosing the manager is not easy, as whoever chooses the
>>> >>manager needs to observe all the possible displays used at the same
>>> >>time...
>> >
>> >Right. I was wondering if omapfb/omapdrm could understand the 'all
>> >possible displays information' better compared to a panel's probe.
>> >
>> >Even omapdrm/omafb can't be perfect because we could insert a panel
>> >driver module at any time, and omapfb/omapdrm may miss that out.
> True, omapdrm/fb may have a better idea. It's still unclear though.
> Currently we have quite strict order in the sequence the modules need to
> be loaded, which is quite bad and causes issues. We should make things
> more dynamic, so that the initialization of the drivers could happen
> more freely.
>
> But that creates more problems: when booting up, omapfb starts. But
> omapfb can't know if all the panel drivers have already been loaded.
> omapfb may see that DVI is the default display, but what should it do if
> DVI doesn't have a driver yet? It could wait, but perhaps the driver for
> DVI will never even be loaded.

The encoder which is connected to the crtc (manager) is picked by 
combination of encoder->possible_crtcs bitmask and 
connector->best_encoder().  We could keep things limited so that the 
association of crtc to encoder (manager to output, roughly) never 
changes, but this isn't really the right thing to do.  It is better that 
the dssdev not rely on knowing the manager it is attached to at probe 
time, but instead grab resources more dynamically.

Also, at the moment we don't really have any notification to userspace 
about new encoders/connectors showing up (or conversely, being 
removed).  Only about existing connectors being plugged/unplugged.  The 
closest analogy is perhaps the USB display devices, but even there it is 
only the entire drm device that is plugged/unplugged.  And TBH I don't 
really see the point in supporting panel drivers being dynamically 
loaded.  It isn't like someone is dynamically soldering on a new display 
connector to some board that is running.  I think omapfb or omapdrm 
probe should trigger registering the compiled-in panel drivers, so that 
it can be sure that the dssdev's pop up before it goes and creates drm 
connector objects.  Currently we have to hack around this in omapdrm 
with late_initcall() to ensure the panel drivers are probed first, but 
that is an ugly hack that I'd like to get rid of.

BR,
-R

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

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

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #11 from Alexandre Demers  ---
Found what is wrong with the help of a few printk and by comparing to the code
being replaced. All the logic is good (going through crtc, disabling them,
waiting for vblank) BUT setting "tmp |=
EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.

If I do as in the previous code by setting tmp = 0 and then continuing with:
radeon_wait_for_vblank(rdev, i);
WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
everything works fine as before.

What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? From
what I read with printk, it is far from a 0 or a 1. Is this normal?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/ab1a6c11/attachment-0001.html>

Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

[Antonio Ospite]

On Mon, 29 Oct 2012 23:16:24 +0100
Antonio Ospite osp...@studenti.unina.it wrote:

 Hi,
 
 I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
 my video adapter is the one integrated on the MSI M3N78-VM motherboard
 (hence x86_64):
 
[...]
 [ 1943.858601] BUG: unable to handle kernel paging request at fff8
 [ 1943.858669] IP: [a031a67a] nouveau_mm_head+0x30/0x127 [nouveau]
 [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 
 [ 1943.858803] Oops:  [#1] SMP 
[..]
 [ 1943.860018] Call Trace:
 [ 1943.860019]  [810fa13d] ? kmem_cache_alloc_trace+0xbf/0xcf
 [ 1943.860019]  [81060f13] ? should_resched+0x5/0x23
 [ 1943.860019]  [a032a10a] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau]

Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits
a7dbf00 and 5cad16a which seem to be related to the problem I was
having; would you mind elaborating a bit about what you think was
causing the crash on my side? Maybe the chipset used on this motherboard
doesn't support some feature? And how did you figured out from the logs?

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

[Dave Airlie]

On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite osp...@studenti.unina.it wrote:
 On Mon, 29 Oct 2012 23:16:24 +0100
 Antonio Ospite osp...@studenti.unina.it wrote:

 Hi,

 I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
 my video adapter is the one integrated on the MSI M3N78-VM motherboard
 (hence x86_64):

 [...]
 [ 1943.858601] BUG: unable to handle kernel paging request at 
 fff8
 [ 1943.858669] IP: [a031a67a] nouveau_mm_head+0x30/0x127 [nouveau]
 [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0
 [ 1943.858803] Oops:  [#1] SMP
 [..]
 [ 1943.860018] Call Trace:
 [ 1943.860019]  [810fa13d] ? kmem_cache_alloc_trace+0xbf/0xcf
 [ 1943.860019]  [81060f13] ? should_resched+0x5/0x23
 [ 1943.860019]  [a032a10a] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau]

 Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits
 a7dbf00 and 5cad16a which seem to be related to the problem I was
 having; would you mind elaborating a bit about what you think was
 causing the crash on my side? Maybe the chipset used on this motherboard
 doesn't support some feature? And how did you figured out from the logs?


5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix

The chipset hasn't got Z compression support, and the oops once decoded pointed
out the new code was trying to allocate Z tags from a NULL memory block. The old
code use to allocate an empty memory block instead of NULL, and it got
lost in the
rewrite, Ben just fixed it to allow empty memory blocks again.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops

[Thomas Hellstrom]

A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down.

In-Reply-To: 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] kref: Implement kref_get_unless_zero

[Thomas Hellstrom]

This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 include/linux/kref.h |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..fd16042 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
 }
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+   return !atomic_add_unless(kref-refcount, 1, 0);
+}
 #endif /* _KREF_H_ */
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

[Thomas Hellstrom]

The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ttm/ttm_object.c |   30 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8 
 include/drm/ttm/ttm_object.h |4 
 include/linux/kref.h |2 +-
 4 files changed, 20 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
  */
 
 struct ttm_object_device {
-   rwlock_t object_lock;
+   spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base-refcount_release = refcount_release;
base-ref_obj_release = ref_obj_release;
base-object_type = object_type;
-   write_lock(tdev-object_lock);
+   spin_lock(tdev-object_lock);
kref_init(base-refcount);
ret = drm_ht_just_insert_please(tdev-object_hash,
base-hash,
(unsigned long)base, 31, 0, 0);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (unlikely(ret != 0))
goto out_err0;
 
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base-tfile-tdev;
 
+   spin_lock(tdev-object_lock);
(void)drm_ht_remove_item(tdev-object_hash, base-hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (base-refcount_release) {
ttm_object_file_unref(base-tfile);
base-refcount_release(base);
}
-   write_lock(tdev-object_lock);
 }
 
 void ttm_base_object_unref(struct ttm_base_object **p_base)
 {
struct ttm_base_object *base = *p_base;
-   struct ttm_object_device *tdev = base-tfile-tdev;
 
*p_base = NULL;
 
-   /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
-   write_lock(tdev-object_lock);
kref_put(base-refcount, ttm_release_base);
-   write_unlock(tdev-object_lock);
 }
 EXPORT_SYMBOL(ttm_base_object_unref);
 
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
 
-   read_lock(tdev-object_lock);
+   rcu_read_lock();
ret = drm_ht_find_item(tdev-object_hash, key, hash);
 
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
-   kref_get(base-refcount);
+   ret = kref_get_unless_zero(base-refcount);
}
-   read_unlock(tdev-object_lock);
+   rcu_read_unlock();
 
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
return NULL;
 
tdev-mem_glob = mem_glob;
-   rwlock_init(tdev-object_lock);
+   spin_lock_init(tdev-object_lock);
atomic_set(tdev-object_count, 0);
ret = drm_ht_create(tdev-object_hash, hash_order);
 
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)
 
*p_tdev = NULL;
 
-   write_lock(tdev-object_lock);
+   spin_lock(tdev-object_lock);
drm_ht_remove(tdev-object_hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
 
kfree(tdev);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res-dev_priv;
 
-   kfree(ctx);
+   ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
 }
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
*res)
kfree(srf-offsets);
kfree(srf-sizes);
kfree(srf-snooper.image);
-   kfree(user_srf);
+   ttm_base_object_kfree(user_srf, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
 }
 

[PATCH 4/4] drm/ttm: Optimize reservation slightly

[Thomas Hellstrom]

Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo-glob;
int ret;
 
-   while (unlikely(atomic_cmpxchg(bo-reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_read(bo-reserved) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}
 
+   atomic_set(bo-reserved, 1);
if (use_sequence) {
/**
 * Wake up waiters that may need to recheck for deadlock,
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups

[Thomas Hellstrom]

On 11/05/2012 02:31 PM, Thomas Hellstrom wrote:

The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
  drivers/gpu/drm/ttm/ttm_object.c |   30 +++---
  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8 
  include/drm/ttm/ttm_object.h |4 
  include/linux/kref.h |2 +-
  4 files changed, 20 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
   */
  
  struct ttm_object_device {

-   rwlock_t object_lock;
+   spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base-refcount_release = refcount_release;
base-ref_obj_release = ref_obj_release;
base-object_type = object_type;
-   write_lock(tdev-object_lock);
+   spin_lock(tdev-object_lock);
kref_init(base-refcount);
ret = drm_ht_just_insert_please(tdev-object_hash,
base-hash,
(unsigned long)base, 31, 0, 0);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (unlikely(ret != 0))
goto out_err0;
  
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)

container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base-tfile-tdev;
  
+	spin_lock(tdev-object_lock);

(void)drm_ht_remove_item(tdev-object_hash, base-hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (base-refcount_release) {
ttm_object_file_unref(base-tfile);
base-refcount_release(base);
}
-   write_lock(tdev-object_lock);
  }
  
  void ttm_base_object_unref(struct ttm_base_object **p_base)

  {
struct ttm_base_object *base = *p_base;
-   struct ttm_object_device *tdev = base-tfile-tdev;
  
  	*p_base = NULL;
  
-	/*

-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
-   write_lock(tdev-object_lock);
kref_put(base-refcount, ttm_release_base);
-   write_unlock(tdev-object_lock);
  }
  EXPORT_SYMBOL(ttm_base_object_unref);
  
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct ttm_object_file *tfile,

struct drm_hash_item *hash;
int ret;
  
-	read_lock(tdev-object_lock);

+   rcu_read_lock();
ret = drm_ht_find_item(tdev-object_hash, key, hash);
  
  	if (likely(ret == 0)) {

base = drm_hash_entry(hash, struct ttm_base_object, hash);
-   kref_get(base-refcount);
+   ret = kref_get_unless_zero(base-refcount);
}
-   read_unlock(tdev-object_lock);
+   rcu_read_unlock();
  
  	if (unlikely(ret != 0))

return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
return NULL;
  
  	tdev-mem_glob = mem_glob;

-   rwlock_init(tdev-object_lock);
+   spin_lock_init(tdev-object_lock);
atomic_set(tdev-object_count, 0);
ret = drm_ht_create(tdev-object_hash, hash_order);
  
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device **p_tdev)
  
  	*p_tdev = NULL;
  
-	write_lock(tdev-object_lock);

+   spin_lock(tdev-object_lock);
drm_ht_remove(tdev-object_hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
  
  	kfree(tdev);

  }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res-dev_priv;
  
-	kfree(ctx);

+   ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
  }
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
*res)
kfree(srf-offsets);
kfree(srf-sizes);
kfree(srf-snooper.image);
-   kfree(user_srf);
+   ttm_base_object_kfree(user_srf, base);

[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops v2

[Thomas Hellstrom]

A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down.

v2: Formatting fixes.

In-Reply-To: 

From Thomas Hellstrom thellst...@vmware.com # This line is ignored.
From: Thomas Hellstrom thellst...@vmware.com
Subject: 
In-Reply-To: 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm: Make hashtab rcu-safe

[Thomas Hellstrom]

TTM base objects will be the first consumer.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/drm_hashtab.c |   18 +++---
 1 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned 
long key)
hashed_key = hash_long(key, ht-order);
DRM_DEBUG(Key is 0x%08lx, Hashed key is 0x%08x\n, key, hashed_key);
h_list = ht-table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG(count %d, key: 0x%08lx\n, count++, entry-key);
-   }
 }
 
 static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct 
drm_open_hash *ht,
 
hashed_key = hash_long(key, ht-order);
h_list = ht-table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry-key == key)
return list;
if (entry-key  key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
hashed_key = hash_long(key, ht-order);
h_list = ht-table[hashed_key];
parent = NULL;
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry-key == key)
return -EINVAL;
if (entry-key  key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
parent = list;
}
if (parent) {
-   hlist_add_after(parent, item-head);
+   hlist_add_after_rcu(parent, item-head);
} else {
-   hlist_add_head(item-head, h_list);
+   hlist_add_head_rcu(item-head, h_list);
}
return 0;
 }
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)
 
list = drm_ht_find_key(ht, key);
if (list) {
-   hlist_del_init(list);
+   hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)
 
 int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
 {
-   hlist_del_init(item-head);
+   hlist_del_init_rcu(item-head);
return 0;
 }
 EXPORT_SYMBOL(drm_ht_remove_item);
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] kref: Implement kref_get_unless_zero v2

[Thomas Hellstrom]

This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.

v2: Formatting fixes.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 include/linux/kref.h |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..bae91d0 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
 }
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+ *
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+   return !atomic_add_unless(kref-refcount, 1, 0);
+}
 #endif /* _KREF_H_ */
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v2

[Thomas Hellstrom]

The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.

v2: Don't touch include/linux/kref.h

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ttm/ttm_object.c |   30 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8 
 include/drm/ttm/ttm_object.h |4 
 3 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
  */
 
 struct ttm_object_device {
-   rwlock_t object_lock;
+   spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base-refcount_release = refcount_release;
base-ref_obj_release = ref_obj_release;
base-object_type = object_type;
-   write_lock(tdev-object_lock);
+   spin_lock(tdev-object_lock);
kref_init(base-refcount);
ret = drm_ht_just_insert_please(tdev-object_hash,
base-hash,
(unsigned long)base, 31, 0, 0);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (unlikely(ret != 0))
goto out_err0;
 
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base-tfile-tdev;
 
+   spin_lock(tdev-object_lock);
(void)drm_ht_remove_item(tdev-object_hash, base-hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (base-refcount_release) {
ttm_object_file_unref(base-tfile);
base-refcount_release(base);
}
-   write_lock(tdev-object_lock);
 }
 
 void ttm_base_object_unref(struct ttm_base_object **p_base)
 {
struct ttm_base_object *base = *p_base;
-   struct ttm_object_device *tdev = base-tfile-tdev;
 
*p_base = NULL;
 
-   /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
-   write_lock(tdev-object_lock);
kref_put(base-refcount, ttm_release_base);
-   write_unlock(tdev-object_lock);
 }
 EXPORT_SYMBOL(ttm_base_object_unref);
 
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
 
-   read_lock(tdev-object_lock);
+   rcu_read_lock();
ret = drm_ht_find_item(tdev-object_hash, key, hash);
 
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
-   kref_get(base-refcount);
+   ret = kref_get_unless_zero(base-refcount);
}
-   read_unlock(tdev-object_lock);
+   rcu_read_unlock();
 
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
return NULL;
 
tdev-mem_glob = mem_glob;
-   rwlock_init(tdev-object_lock);
+   spin_lock_init(tdev-object_lock);
atomic_set(tdev-object_count, 0);
ret = drm_ht_create(tdev-object_hash, hash_order);
 
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)
 
*p_tdev = NULL;
 
-   write_lock(tdev-object_lock);
+   spin_lock(tdev-object_lock);
drm_ht_remove(tdev-object_hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
 
kfree(tdev);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res-dev_priv;
 
-   kfree(ctx);
+   ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
 }
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
*res)
kfree(srf-offsets);
kfree(srf-sizes);
kfree(srf-snooper.image);
-   kfree(user_srf);
+   ttm_base_object_kfree(user_srf, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
 }
 
@@ -1575,7 

Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly

[Maarten Lankhorst]

Hey,

Op 05-11-12 14:31, Thomas Hellstrom schreef:
 Reservation locking currently always takes place under the LRU spinlock.
 Hence, strictly there is no need for an atomic_cmpxchg call; we can use
 atomic_read followed by atomic_write since nobody else will ever reserve
 without the lru spinlock held.
 At least on Intel this should remove a locked bus cycle on successful
 reserve.

 Signed-off-by: Thomas Hellstrom thellst...@vmware.com

Is that really a good thing to submit when I am busy killing lru lock around 
reserve? :-)

-   while (unlikely(atomic_cmpxchg(bo-reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_xchg(bo-reserved, 1) != 0)) {

Works without lru lock too!

In fact mutexes are done in a similar way[1], except with some more magic, and 
unlocked state is 1, not 0.
However I do think that to get that right (saves a irq disable in unlock path, 
and less wakeups in contended
case), I should really just post the mutex extension patches for reservations 
and ride the flames. It's
getting too close to real mutexes so I really want it to be a mutex in that 
case. So lets convert it.. Soon! :-)

~Maarten

[1] See linux/include/asm-generic/mutex-xchg.h and 
linux/include/asm-generic/mutex-dec.h for how
archs generally implement mutex fastpaths.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #12 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #11)
 Found what is wrong with the help of a few printk and by comparing to the
 code being replaced. All the logic is good (going through crtc, disabling
 them, waiting for vblank) BUT setting tmp |=
 EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.
 
 If I do as in the previous code by setting tmp = 0 and then continuing with:
 radeon_wait_for_vblank(rdev, i);
 WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
 everything works fine as before.
 
 What is expected from tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
 From what I read with printk, it is far from a 0 or a 1. Is this normal?

That's the most important bit in the entire sequence.  It's a bit field in a
register (bit 24 to be exact).  That bit is the bit that actually disables the
requests from the display controller in the memory controller.  The whole point
of this code is to disable all clients of the memory controller (mc_stop()) so
that we can change the location of vram within the GPU's address space.  Once
we've moved vram, we can re-enable the clients (mc_resume()) so that they point
to the new vram location.

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

[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled

[Rahul Sharma]

This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.

This patch is based on exynos-drm-next-iommu branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

This patch is having dependency on  linux-samsung-soc patchset named
add dt based support for iommu for hdmi

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Prathyush K prathyus...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   35 ++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d1a1d71..ee110c9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,9 @@
 #include linux/regulator/consumer.h
 #include linux/io.h
 #include linux/of_gpio.h
+#include linux/of_platform.h
 #include plat/gpio-cfg.h
+#include mach/sysmmu.h
 
 #include drm/exynos_drm.h
 
@@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client 
*hdmiphy)
 }
 
 #ifdef CONFIG_OF
+
+static int drm_hdmi_dt_init_iommu(struct device *dev)
+{
+   struct platform_device *pds;
+   struct device_node *dn, *dns;
+   const __be32 *parp;
+
+   dn = dev-of_node;
+   parp = of_get_property(dn, sysmmu, NULL);
+   if (parp == NULL) {
+   dev_err(dev, failed to find sysmmu property\n);
+   return -EINVAL;
+   }
+   dns = of_find_node_by_phandle(be32_to_cpup(parp));
+   if (dns == NULL) {
+   dev_err(dev, failed to find sysmmu node\n);
+   return -EINVAL;
+   }
+   pds = of_find_device_by_node(dns);
+   if (pds == NULL) {
+   dev_err(dev, failed to find sysmmu platform device\n);
+   return -EINVAL;
+   }
+
+   platform_set_sysmmu(pds-dev, dev);
+   return 0;
+}
+
 static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
 {
@@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
goto err_data;
}
 
+   if (drm_hdmi_dt_init_iommu(dev)){
+   DRM_ERROR(no sysmmu property found\n);
+   goto err_data;
+   }
+
pd-hpd_gpio = of_get_named_gpio_flags(np, hpd-gpio, 0, flags);
 
return pd;
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly

[Thomas Hellstrom]

On 11/05/2012 03:01 PM, Maarten Lankhorst wrote:

Hey,

Op 05-11-12 14:31, Thomas Hellstrom schreef:

Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com


Is that really a good thing to submit when I am busy killing lru lock around 
reserve? :-)



If your patch series makes it into the same kernel, let's kill this 
patch. Otherwise it may live
at least for a kernel release. It's not a big thing to rebase against, 
and I won't complain if your

patch adds another atomic read-modify-write op here. :)

/Thomas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=49981


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 AssignedTo|drivers_video-other@kernel- |drivers_video-dri@kernel-bu
   |bugs.osdl.org   |gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=16193


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk




--- Comment #2 from Alan a...@lxorguk.ukuu.org.uk  2012-11-05 14:16:22 ---
Closing as obsolete. If this is still seen on modern kernels (3.2+) please
update/reopen

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=16193


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 16065] linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=16065


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: exynos: fix for mapping contigous dma buffers

[Inki Dae]

2012. 11. 3. 오후 9:21 Rahul Sharma rahul.sha...@samsung.com 작성:

 This patch fixes the problem of mapping contigous dma buffers. Currently page
 struct is calculated from the buf-dma_addr which is not the physical address.
 It is replaced by buf-pages which points to the page struct of the first page
 of contigous memory chunk. This gives the correct page frame number for
 mapping.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
 b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 index c557ac7..50d73f1 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 @@ -120,8 +120,12 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object 
 *obj,
}
 
pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
 -} else
 -pfn = (buf-dma_addr  PAGE_SHIFT) + page_offset;
 +} else {
 +if (!buf-pages)
 +return -EINTR;
 +
 +pfn = page_to_pfn(buf-pages[0]) + page_offset;
 +}

Is there any reason you are sending patches respectively? It's better to 
combine them.

Thanks,
Inki Dae

 
return vm_insert_mixed(vma, f_vaddr, pfn);
 }
 -- 
 1.7.0.4
 
 ___
 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

[Bug 17511] Display no longer works with KMS enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=17511


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INSUFFICIENT_DATA




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #13 from Alex Deucher ag...@yahoo.com ---
Created attachment 69564
  -- https://bugs.freedesktop.org/attachment.cgi?id=69564action=edit
possible fix

Slightly adjusted wait for vblank function.  Maybe this will help?

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #14 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #12)
 (In reply to comment #11)
  Found what is wrong with the help of a few printk and by comparing to the
  code being replaced. All the logic is good (going through crtc, disabling
  them, waiting for vblank) BUT setting tmp |=
  EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.
  
  If I do as in the previous code by setting tmp = 0 and then continuing with:
  radeon_wait_for_vblank(rdev, i);
  WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
  everything works fine as before.
  
  What is expected from tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
  From what I read with printk, it is far from a 0 or a 1. Is this normal?
 
 That's the most important bit in the entire sequence.  It's a bit field in a
 register (bit 24 to be exact).  That bit is the bit that actually disables
 the requests from the display controller in the memory controller.  The
 whole point of this code is to disable all clients of the memory controller
 (mc_stop()) so that we can change the location of vram within the GPU's
 address space.  Once we've moved vram, we can re-enable the clients
 (mc_resume()) so that they point to the new vram location.

Thank you, you confirmed what I had assumed. I had already understood that it
was the most important part in the sequence since it is associated to a write
instruction. I don't have the (decimal/binary) values with me right now, but
I'll be able to give you what was read from the register and from the result
returned from the bitwise OR assignment we are pushing in the register. I'll
confirm which bit(s) are changing. I'm sure the assignment was setting one (or
more) bit in the register to 1. Is bit 24 the only one expected to change in
the register? Should it be put to 1 or 0?

Another question: why were we setting 0 in the register before? By doing so,
we were setting the whole register to 0 (the whole 32 bits), right? If I
remember correctly, from what I saw yesterday with the help of printk, it seems
we are setting at least one bit to 1 in this register, which would be the
opposite of what was being done before and therefore of what was working
correctly with my video card. I'm just trying to understand why we were doing
something in the first place that was working correctly and that was introduce
to fix this problem in the first place, both at boot time for grub (set
gfxpayload=keep) and when suspending/resuming, and we are now doing the
opposite, thus breaking the code for some setups. Is it possible that the
bit/register logic is not the same for all Radeon GPUs? After all, we already
introduced a different path for DCE6.

I'll also try your patch when I'll get home tonight.

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

[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled

[Rahul Sharma]

This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.

This patch is based on exynos-drm-next-iommu branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

This patch is having dependency on  linux-samsung-soc patchset posted at
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/13556

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Prathyush K prathyus...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   35 ++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d1a1d71..a04452c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,9 @@
 #include linux/regulator/consumer.h
 #include linux/io.h
 #include linux/of_gpio.h
+#include linux/of_platform.h
 #include plat/gpio-cfg.h
+#include mach/sysmmu.h
 
 #include drm/exynos_drm.h
 
@@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client 
*hdmiphy)
 }
 
 #ifdef CONFIG_OF
+
+static int drm_hdmi_dt_init_iommu(struct device *dev)
+{
+   struct platform_device *pds;
+   struct device_node *dn, *dns;
+   const __be32 *parp;
+
+   dn = dev-of_node;
+   parp = of_get_property(dn, sysmmu, NULL);
+   if (parp == NULL) {
+   dev_err(dev, failed to find sysmmu property\n);
+   return -EINVAL;
+   }
+   dns = of_find_node_by_phandle(be32_to_cpup(parp));
+   if (dns == NULL) {
+   dev_err(dev, failed to find sysmmu node\n);
+   return -EINVAL;
+   }
+   pds = of_find_device_by_node(dns);
+   if (pds == NULL) {
+   dev_err(dev, failed to find sysmmu platform device\n);
+   return -EINVAL;
+   }
+
+   platform_set_sysmmu(pds-dev, dev);
+   return 0;
+}
+
 static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
 {
@@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
goto err_data;
}
 
+   if (drm_hdmi_dt_init_iommu(dev)) {
+   DRM_ERROR(no sysmmu property found\n);
+   goto err_data;
+   }
+
pd-hpd_gpio = of_get_named_gpio_flags(np, hpd-gpio, 0, flags);
 
return pd;
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: exynos: fix for mapping of dma buffers

[Rahul Sharma]

This patch fixes the problem of mapping contigous and non contigous dma buffers.

Currently page struct is calculated from the buf-dma_addr which is not the
physical address. It is replaced by buf-pages which points to the page struct
of the first page of contigous memory chunk. This gives the correct page frame
number for mapping.

Non-contigous dma buffers are described using SG table and SG lists. Each
valid SG List is pointing to a single page or group of pages which are
physically contigous. Current implementation just maps the first page of each
SG List and leave the other pages unmapped, leading to a crash. Given solution
finds the page struct for the faulting page through parsing SG table and map it.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   28 +---
 1 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8cb6824..50d73f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -95,15 +95,37 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object 
*obj,
 {
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buf = exynos_gem_obj-buffer;
+   struct scatterlist *sgl;
unsigned long pfn;
+   int i;
 
if (exynos_gem_obj-flags  EXYNOS_BO_NONCONTIG) {
+   if (!buf-sgt)
+   return -EINTR;
+
+   sgl = buf-sgt-sgl;
+   for_each_sg(buf-sgt-sgl, sgl, buf-sgt-nents, i) {
+   if (!sgl) {
+   DRM_ERROR(invalid SG table\n);
+   return -EINTR;
+   }
+   if (page_offset  (sgl-length  PAGE_SHIFT))
+   break;
+   page_offset -=  (sgl-length  PAGE_SHIFT);
+   }
+
+   if (i = buf-sgt-nents) {
+   DRM_ERROR(invalid page offset\n);
+   return -EINVAL;
+   }
+
+   pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
+   } else {
if (!buf-pages)
return -EINTR;
 
-   pfn = page_to_pfn(buf-pages[page_offset++]);
-   } else
-   pfn = (buf-dma_addr  PAGE_SHIFT) + page_offset;
+   pfn = page_to_pfn(buf-pages[0]) + page_offset;
+   }
 
return vm_insert_mixed(vma, f_vaddr, pfn);
 }
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Alex Deucher]

On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss andy...@ukfsn.org wrote:
 Alex Deucher wrote:

 On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote:

 For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
 and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
 and then turn TV on and -

 xrandr --output DVI-0 --auto

 to bring up the the TV and get a clone of monitor.

 This still works with drm-core-next but not with drm-fixes (todays or
 from a
 few days ago).

 With df I now loose the monitor with signal out of range when doing
 above,
 the TV output is OK. To get the monitor back I need to turn off TV, then
 off/auto the monitor.

 xrandr --output DVI-0 --off
 xrandr --output DVI-1 --off
 xrandr --output DVI-1 --auto

 The output from xrandr while the monitor is showing signal out of range
 looks normal.

 If I boot with the TV on it works OK.


 Can you bisect?


 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
 commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
 Author: Alex Deucher alexander.deuc...@amd.com
 Date:   Fri Oct 5 10:22:02 2012 -0400

 drm/radeon: allocate PPLLs from low to high

 The order shouldn't matter, but there have been problems
 reported on certain older asics.  This behaves more
 like the original code before the PPLL allocation
 rework.

 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc:  Markus Trippelsdorf mar...@trippelsdorf.de



That's bizarre.  That patch reverts the behavior back to the 3.6 and
earlier kernel behavior.  I guess it's some issue with the ordering of
the modesetting programming sequence.  I've attached a couple of
things to try.

The first patch is a simple fix.  It just reverts back to the previous
pll allocation order for discrete cards like yours:
0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch

The second set of patches implements a more complex fix which may help
regardless of the order in which plls are allocated:
0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
0003-drm-radeon-disable-the-pll-before-a-modeset.patch

Can you see if the second set helps?  If not, please try the first patch.

Alex
From b6cd7967513fe86c0822db4b41745da2140914b7 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Mon, 5 Nov 2012 10:16:12 -0500
Subject: [PATCH] drm/radeon/dce3: switch back to old pll allocation order for
 discrete

The order shouldn't matter, but this seems to cause regressions for
certain specific cases.  This should fix it for now.  We probably
need to investigate a proper fix in the next development cycle.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: Andy Furniss andy...@ukfsn.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |   54 ++-
 1 files changed, 31 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 2e566e1..3bce029 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1696,35 +1696,43 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 			return ATOM_PPLL2;
 		DRM_ERROR(unable to allocate a PPLL\n);
 		return ATOM_PPLL_INVALID;
-	} else {
-		if (ASIC_IS_AVIVO(rdev)) {
-			/* in DP mode, the DP ref clock can come from either PPLL
-			 * depending on the asic:
-			 * DCE3: PPLL1 or PPLL2
-			 */
-			if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc-encoder))) {
-/* use the same PPLL for all DP monitors */
-pll = radeon_get_shared_dp_ppll(crtc);
-if (pll != ATOM_PPLL_INVALID)
-	return pll;
-			} else {
-/* use the same PPLL for all monitors with the same clock */
-pll = radeon_get_shared_nondp_ppll(crtc);
-if (pll != ATOM_PPLL_INVALID)
-	return pll;
-			}
-			/* all other cases */
-			pll_in_use = radeon_get_pll_use_mask(crtc);
+	} else if (ASIC_IS_AVIVO(rdev)) {
+		/* in DP mode, the DP ref clock can come from either PPLL
+		 * depending on the asic:
+		 * DCE3: PPLL1 or PPLL2
+		 */
+		if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc-encoder))) {
+			/* use the same PPLL for all DP monitors */
+			pll = radeon_get_shared_dp_ppll(crtc);
+			if (pll != ATOM_PPLL_INVALID)
+return pll;
+		} else {
+			/* use the same PPLL for all monitors with the same clock */
+			pll = radeon_get_shared_nondp_ppll(crtc);
+			if (pll != ATOM_PPLL_INVALID)
+return pll;
+		}
+		/* all other cases */
+		pll_in_use = radeon_get_pll_use_mask(crtc);
+		/* the order shouldn't matter here, but we probably
+		 * need this until we have atomic modeset
+		 */
+		if (rdev-flags  RADEON_IS_IGP) {
 			if (!(pll_in_use  (1  ATOM_PPLL1)))
 return ATOM_PPLL1;
 			if (!(pll_in_use  (1  ATOM_PPLL2)))
 return ATOM_PPLL2;
-			DRM_ERROR(unable to allocate a PPLL\n);
-			return ATOM_PPLL_INVALID;
 		} else {
-			/* on pre-R5xx 

Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8

[Antonio Ospite]

On Mon, 5 Nov 2012 08:40:38 +
Dave Airlie airl...@gmail.com wrote:

 On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite osp...@studenti.unina.it 
 wrote:
  On Mon, 29 Oct 2012 23:16:24 +0100
  Antonio Ospite osp...@studenti.unina.it wrote:
 
  Hi,
 
  I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
  my video adapter is the one integrated on the MSI M3N78-VM motherboard
  (hence x86_64):
 
  [...]
  [ 1943.858601] BUG: unable to handle kernel paging request at 
  fff8
  [ 1943.858669] IP: [a031a67a] nouveau_mm_head+0x30/0x127 
  [nouveau]
  [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0
  [ 1943.858803] Oops:  [#1] SMP
  [..]
  [ 1943.860018] Call Trace:
  [ 1943.860019]  [810fa13d] ? kmem_cache_alloc_trace+0xbf/0xcf
  [ 1943.860019]  [81060f13] ? should_resched+0x5/0x23
  [ 1943.860019]  [a032a10a] ? nv50_fb_vram_new+0xc5/0x1f2 
  [nouveau]
 
  Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits
  a7dbf00 and 5cad16a which seem to be related to the problem I was
  having; would you mind elaborating a bit about what you think was
  causing the crash on my side? Maybe the chipset used on this motherboard
  doesn't support some feature? And how did you figured out from the logs?
 
 
 5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix
 
 The chipset hasn't got Z compression support, and the oops once decoded 
 pointed
 out the new code was trying to allocate Z tags from a NULL memory block. The 
 old
 code use to allocate an empty memory block instead of NULL, and it got
 lost in the
 rewrite, Ben just fixed it to allow empty memory blocks again.
 
 Dave.
 

Thanks a lot for the explanation.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #15 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #14)
 (In reply to comment #12)
  (In reply to comment #11)
   Found what is wrong with the help of a few printk and by comparing to the
   code being replaced. All the logic is good (going through crtc, disabling
   them, waiting for vblank) BUT setting tmp |=
   EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.
   
   If I do as in the previous code by setting tmp = 0 and then continuing 
   with:
   radeon_wait_for_vblank(rdev, i);
   WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
   everything works fine as before.
   
   What is expected from tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
   From what I read with printk, it is far from a 0 or a 1. Is this normal?
  
  That's the most important bit in the entire sequence.  It's a bit field in a
  register (bit 24 to be exact).  That bit is the bit that actually disables
  the requests from the display controller in the memory controller.  The
  whole point of this code is to disable all clients of the memory controller
  (mc_stop()) so that we can change the location of vram within the GPU's
  address space.  Once we've moved vram, we can re-enable the clients
  (mc_resume()) so that they point to the new vram location.
 
 Thank you, you confirmed what I had assumed. I had already understood that
 it was the most important part in the sequence since it is associated to a
 write instruction. I don't have the (decimal/binary) values with me right
 now, but I'll be able to give you what was read from the register and from
 the result returned from the bitwise OR assignment we are pushing in the
 register. I'll confirm which bit(s) are changing. I'm sure the assignment
 was setting one (or more) bit in the register to 1. Is bit 24 the only one
 expected to change in the register? Should it be put to 1 or 0?
 

Setting bit 24 to 1 disables memory requests from the display controller. 
Setting bit 24 to 0, enables memory requests from the display controller.

 Another question: why were we setting 0 in the register before? By doing
 so, we were setting the whole register to 0 (the whole 32 bits), right? If
 I remember correctly, from what I saw yesterday with the help of printk, it
 seems we are setting at least one bit to 1 in this register, which would
 be the opposite of what was being done before and therefore of what was
 working correctly with my video card. I'm just trying to understand why we
 were doing something in the first place that was working correctly and that
 was introduce to fix this problem in the first place, both at boot time for
 grub (set gfxpayload=keep) and when suspending/resuming, and we are now
 doing the opposite, thus breaking the code for some setups. Is it possible
 that the bit/register logic is not the same for all Radeon GPUs? After all,
 we already introduced a different path for DCE6.

Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc is
disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled (bit 0
= 0) bit 24 is irrelevant.  There are separate bits to enable the crtc and
disable memory requests since there are cases (like this one) where we want to
keep the crtc timing running so that the monitor stays synced, but disable
reads from memory so we can reconfigure the memory controller.  If we disable
the crtc entirely, the monitor would lose sync and you would get additional
flicker during boot up.  Ideally, eventually we'd like to just hand over
control from the firmware without touching the display hardware so the user
gets a flicker free boot experience.

DCE4 and 5 have the same logic and bit layout for these registers.  The logic
is different on DCE6 chips.  On DCE6, the the memory controller request bit is
now tied in with the crtc blanking bit.  When the crtc is blanked, memory
requests are also disabled.

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #16 from Alex Deucher ag...@yahoo.com ---
Created attachment 69573
  -- https://bugs.freedesktop.org/attachment.cgi?id=69573action=edit
possible fix

Actually, I think I found the problem.  Missing index in mc_resume().

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

[PATCH] drm/radeon: fix typo in evergreen_mc_resume()

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Add missing index that may have led us to enabling
more crtcs than necessary.

May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 14313ad..af31f82 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1372,7 +1372,7 @@ void evergreen_mc_resume(struct radeon_device *rdev, 
struct evergreen_mc_save *s
WREG32(BIF_FB_EN, FB_READ_EN | FB_WRITE_EN);
 
for (i = 0; i  rdev-num_crtc; i++) {
-   if (save-crtc_enabled) {
+   if (save-crtc_enabled[i]) {
if (ASIC_IS_DCE6(rdev)) {
tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + 
crtc_offsets[i]);
tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes

[Andy Furniss]

Alex Deucher wrote:

On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss andy...@ukfsn.org wrote:

Alex Deucher wrote:


On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss andy...@ukfsn.org wrote:


For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
and then turn TV on and -

xrandr --output DVI-0 --auto

to bring up the the TV and get a clone of monitor.

This still works with drm-core-next but not with drm-fixes (todays or
from a
few days ago).

With df I now loose the monitor with signal out of range when doing
above,
the TV output is OK. To get the monitor back I need to turn off TV, then
off/auto the monitor.

xrandr --output DVI-0 --off
xrandr --output DVI-1 --off
xrandr --output DVI-1 --auto

The output from xrandr while the monitor is showing signal out of range
looks normal.

If I boot with the TV on it works OK.



Can you bisect?



29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Fri Oct 5 10:22:02 2012 -0400

 drm/radeon: allocate PPLLs from low to high

 The order shouldn't matter, but there have been problems
 reported on certain older asics.  This behaves more
 like the original code before the PPLL allocation
 rework.

 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 Cc:  Markus Trippelsdorf mar...@trippelsdorf.de




That's bizarre.  That patch reverts the behavior back to the 3.6 and
earlier kernel behavior.  I guess it's some issue with the ordering of
the modesetting programming sequence.  I've attached a couple of
things to try.

The first patch is a simple fix.  It just reverts back to the previous
pll allocation order for discrete cards like yours:
0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch

The second set of patches implements a more complex fix which may help
regardless of the order in which plls are allocated:
0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
0003-drm-radeon-disable-the-pll-before-a-modeset.patch

Can you see if the second set helps?  If not, please try the first patch.


The second set doesn't fix it.

The first patch does.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56081

Tony Thomas autonym...@gmail.com changed:

   What|Removed |Added

  Attachment #68684|0   |1
is obsolete||
  Attachment #68717|0   |1
is obsolete||

--- Comment #8 from Tony Thomas autonym...@gmail.com ---
Created attachment 69579
  -- https://bugs.freedesktop.org/attachment.cgi?id=69579action=edit
Debian Sid w/3.6.8-pf dmesg (drm.debug=6)

Switched system to Debian Sid, clean install. Sid is tracking 8.0.5-1 mesa
http://packages.debian.org/search?keywords=mesasearchon=namessuite=unstablesection=all

Screen corruption still, using Sid 3.2.0-4 stock kernel, and 3.6.8-pf kernel
from here: http://kernel.night-leshiy.ru/

Attaching drm.debug=6 dmesg from Debian 3.6.8-pf kernel

-- 
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 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56081

--- Comment #10 from Tony Thomas autonym...@gmail.com ---
Of note: with most kernel combo and 8.0 mesa branch (also tried on Arch Linux),
failures and corruption DO NOT prevent VT-switching as the 9.0 branch does.

-- 
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 53130] 99c65ba breaks rendering (flickery, eventual fail)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=53130

--- Comment #3 from Darren Salt bugs...@moreofthesa.me.uk ---
I've rebuilt mesa with this re-enabled and I saw a lot of rendering glitches. I
suspect that DISCARD_RANGE being re-enabled is the problem, although I've also
built and installed an updated xf86-video-ati (cdf522f→20bfc65).

My current mesa build has 1eedebc reverted; I'll re-check with that undone
later.

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #17 from Alexandre Demers alexandre.f.dem...@gmail.com ---
I'm about to test patches. But before, as promised, here are the values
retrieved read and written to the registers. By the way, I have only a single
monitor.
tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]); - 272696081 (0001 
0100 0001  0011 0001 0001)
tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; - 289473297 (0001 0001 0100
0001  0011 0001 0001)

So, it is set as you explained me earlier. I'll be back soon with some news
from the patches.

-- 
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 56788] New: [nv96] Dota2 (wine) consistently crashes with WARNING: out of code space, evicting all shaders

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56788

  Priority: medium
Bug ID: 56788
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [nv96] Dota2 (wine) consistently crashes with
WARNING: out of code space, evicting all shaders
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: emil.l.veli...@gmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/DRI/Radeon
   Product: Mesa

Created attachment 69589
  -- https://bugs.freedesktop.org/attachment.cgi?id=69589action=edit
Untrimmed stdout  stderr

As of approx 1 Nov 2012, Dota2 crashes while playing/spectating a game

Initially I was suspecting the recent vbo work by Marek, although I'm leaning
towards memory bug/buggy shader in one of the Dota2 3 updates - 29,30 and 1 Nov

Cannot downgrade to verify, although backtrace does point that the crash occurs
after the above message is printed to stderr

Brief list of the other messages printed to strout  strerr

WARNING: value %35 not uniquely defined
...
WARNING: value %277 not uniquely defined
WARNING: value %17 not uniquely defined
context mis-match in pipe_sampler_view_release()
WARNING: value %28 not uniquely defined
...
WARNING: value %17 not uniquely defined
WARNING: out of code space, evicting all shaders.

-- 
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 56788] [nv96] Dota2 (wine) consistently crashes with WARNING: out of code space, evicting all shaders

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56788

--- Comment #1 from Emil Velikov emil.l.veli...@gmail.com ---
Created attachment 69590
  -- https://bugs.freedesktop.org/attachment.cgi?id=69590action=edit
Wine backtrace

-- 
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 56788] [nv96] Dota2 (wine) consistently crashes with WARNING: out of code space, evicting all shaders

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56788

Emil Velikov emil.l.veli...@gmail.com changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
   |.org|rg
  Component|Drivers/DRI/Radeon  |Drivers/DRI/nouveau

--- Comment #2 from Emil Velikov emil.l.veli...@gmail.com ---
Correcting component

-- 
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 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=48941


Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 CC||flor...@mickler.org




--- Comment #7 from Florian Mickler flor...@mickler.org  2012-11-05 23:15:22 
---
A patch referencing this bug report has been merged in Linux v3.7-rc3:

commit 614499b4d844dcceae5ae2f1e53a2963789a8933
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Wed Oct 17 17:20:24 2012 -0400

drm/radeon: give each backlight a unique id

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=48941


Igor Murzov e-m...@date.by changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




--- Comment #8 from Igor Murzov e-m...@date.by  2012-11-05 23:36:42 ---
Fixed.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #18 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #16)
 Created attachment 69573 [details] [review]
 possible fix
 
 Actually, I think I found the problem.  Missing index in mc_resume().

This seems to fix my resume problem I was experiencing where the display would
come up, but then it would crash. However, it doesn't solve the boot/grub2 bug.

So, this patch should be kept (but not for the current bug).

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #19 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #15)
 (In reply to comment #14)
  (In reply to comment #12)
   (In reply to comment #11)
Found what is wrong with the help of a few printk and by comparing to 
the
code being replaced. All the logic is good (going through crtc, 
disabling
them, waiting for vblank) BUT setting tmp |=
EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; is wrong.

If I do as in the previous code by setting tmp = 0 and then continuing 
with:
radeon_wait_for_vblank(rdev, i);
WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
everything works fine as before.

What is expected from tmp |= 
EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;?
From what I read with printk, it is far from a 0 or a 1. Is this normal?
   
   That's the most important bit in the entire sequence.  It's a bit field 
   in a
   register (bit 24 to be exact).  That bit is the bit that actually disables
   the requests from the display controller in the memory controller.  The
   whole point of this code is to disable all clients of the memory 
   controller
   (mc_stop()) so that we can change the location of vram within the GPU's
   address space.  Once we've moved vram, we can re-enable the clients
   (mc_resume()) so that they point to the new vram location.
  
  Thank you, you confirmed what I had assumed. I had already understood that
  it was the most important part in the sequence since it is associated to a
  write instruction. I don't have the (decimal/binary) values with me right
  now, but I'll be able to give you what was read from the register and from
  the result returned from the bitwise OR assignment we are pushing in the
  register. I'll confirm which bit(s) are changing. I'm sure the assignment
  was setting one (or more) bit in the register to 1. Is bit 24 the only one
  expected to change in the register? Should it be put to 1 or 0?
  
 
 Setting bit 24 to 1 disables memory requests from the display controller. 
 Setting bit 24 to 0, enables memory requests from the display controller.
 
  Another question: why were we setting 0 in the register before? By doing
  so, we were setting the whole register to 0 (the whole 32 bits), right? If
  I remember correctly, from what I saw yesterday with the help of printk, it
  seems we are setting at least one bit to 1 in this register, which would
  be the opposite of what was being done before and therefore of what was
  working correctly with my video card. I'm just trying to understand why we
  were doing something in the first place that was working correctly and that
  was introduce to fix this problem in the first place, both at boot time for
  grub (set gfxpayload=keep) and when suspending/resuming, and we are now
  doing the opposite, thus breaking the code for some setups. Is it possible
  that the bit/register logic is not the same for all Radeon GPUs? After all,
  we already introduced a different path for DCE6.
 
 Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc
 is disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled
 (bit 0 = 0) bit 24 is irrelevant.  There are separate bits to enable the
 crtc and disable memory requests since there are cases (like this one) where
 we want to keep the crtc timing running so that the monitor stays synced,
 but disable reads from memory so we can reconfigure the memory controller. 
 If we disable the crtc entirely, the monitor would lose sync and you would
 get additional flicker during boot up.  Ideally, eventually we'd like to
 just hand over control from the firmware without touching the display
 hardware so the user gets a flicker free boot experience.
 
 DCE4 and 5 have the same logic and bit layout for these registers.  The
 logic is different on DCE6 chips.  On DCE6, the the memory controller
 request bit is now tied in with the crtc blanking bit.  When the crtc is
 blanked, memory requests are also disabled.

If I followed you correctly, setting bit 24 to 1 disables memory but keeps
the CRTC state as it is (hopefully in sync with the monitor). However, what I
see when grub2 kicks in with the gfxpayload=keep is an unsynced monitor.
Sometimes the display will be black, other times it will only appear in the
first couple of vertical lines, in others it will be vertically synced but
shifted to the right at half or at two third of the screen. In other words,
this really seems to be a sync problem. Should I try to combine patch 69113 and
patch 69370 with the others?

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

[ANNOUNCE] libdrm 2.4.40

[Marek Olšák]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

libdrm 2.4.40 has been released.

The reason is we need to use the radeon stencil mipmap allocator for combined
depth-stencil buffers in Mesa.


Alex Deucher (1):
  radeon: add some new SI pci ids

Andreas Boll (1):
  radeon: fix unused-function warning

Chris Wilson (3):
  intel: Fix properly test for HAS_LLC
  intel: Correct the word decoding for gen2 3DSTATE_LOAD_STATE_IMMEDIATE_1
  intel: Silence a trivial compiler warning

Daniel Stone (1):
  configure.ac: Allow forcible disabling of Cairo support

Daniel Vetter (1):
  intel: properly test for HAS_LLC

Dave Airlie (1):
  fix make distcheck

Jakob Bornecrantz (1):
  vmwgfx: No longer experimental

Jesse Barnes (2):
  intel: add support for ValleyView
  libdrm: man page infrastructure and a few sample man pages

Kristian Høgsberg (1):
  intel: Mark bo's exported to prime as not reusable

Marcin Slusarz (1):
  libkms: link against libdrm

Marek Olšák (5):
  radeon: don't take the stencil-specific codepath for buffers without
stencil
  radeon: don't force stencil tile split to 0
  radeon: fix stencil miptree allocation of combined ZS buffers on EG and
SI
  radeon: fix tile_split of 128-bit surface formats with 8x MSAA
  configure.ac: bump version to 2.4.40 for release

Michel Dänzer (3):
  radeon: Fix layout of linear aligned mipmaps on SI.
  radeon: Memory footprint of SI mipmap base level is padded to powers of
two.
  radeon: Sampling pitch for non-mipmaps seems padded to slice alignment
on SI.

Rob Clark (2):
  update gitignore
  initialize width/height fields in drmModeCrtc

Vincent Penquerc'h (1):
  omap: release lock also on error paths

git tag: libdrm-2.4.40

http://dri.freedesktop.org/libdrm/libdrm-2.4.40.tar.bz2
MD5:  626a3dc44a40ef37565b61732b688567  libdrm-2.4.40.tar.bz2
SHA1: 0f77aa49922e17102caa75de86c8e79bbf23b4a1  libdrm-2.4.40.tar.bz2
SHA256: 48c14e4600ea0fde522292893eb4055d2f6d86a69d093d379c827deaccffaa1f
 libdrm-2.4.40.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.40.tar.gz
MD5:  d6c7eae620f0c0252377f0bf6a02ce54  libdrm-2.4.40.tar.gz
SHA1: fa16e9704514e3368a5b207ba250a7d7626b627b  libdrm-2.4.40.tar.gz
SHA256: 9f2ea4c1e5656c28e9237e9a67c58282b86b8e964aac5734774a2cd30ee17381
 libdrm-2.4.40.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJQmGD3AAoJEP3RXVrO8PKxg4cH/RDZUrVYqm4nDfnuVUFHLcju
SgPv3HEScFMvYeyrwNIGJKFca6ZkUQdS19YtS9x88WeRjsC811BNjQoNyvZd1D+V
6mKZwATR0IZ4bRmTTU58zgqFqboIdzrzXi/Cv0U3Qx7pbDdCUrHUAvcyjvLG5/Y6
SU9VmrQe1p/tlr3beQbJALhSFJpXJMS57BXz0M/58MlmeKplXjoPLVd/teOZGXB2
s4kxj1r4WBKcdnD9vnjoRrcrRV5ghdliqnmZf+xM2edBRIoreGQ/ZPzc9tXT8ywF
3BsBvyDxRwZFtUlDTocUrdTAeCpGQPhDe2pbxcMUKnA98ZUfmk+mHR7WL2HpE84=
=eban
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: exynos: fix for mapping of dma buffers

[Inki Dae]

Applied.

Thanks,
Inki Dae


2012/11/6 Rahul Sharma rahul.sha...@samsung.com

 This patch fixes the problem of mapping contigous and non contigous dma
 buffers.

 Currently page struct is calculated from the buf-dma_addr which is not the
 physical address. It is replaced by buf-pages which points to the page
 struct
 of the first page of contigous memory chunk. This gives the correct page
 frame
 number for mapping.

 Non-contigous dma buffers are described using SG table and SG lists. Each
 valid SG List is pointing to a single page or group of pages which are
 physically contigous. Current implementation just maps the first page of
 each
 SG List and leave the other pages unmapped, leading to a crash. Given
 solution
 finds the page struct for the faulting page through parsing SG table and
 map it.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_gem.c |   28
 +---
  1 files changed, 25 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 index 8cb6824..50d73f1 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
 @@ -95,15 +95,37 @@ static int exynos_drm_gem_map_buf(struct
 drm_gem_object *obj,
  {
 struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
 struct exynos_drm_gem_buf *buf = exynos_gem_obj-buffer;
 +   struct scatterlist *sgl;
 unsigned long pfn;
 +   int i;

 if (exynos_gem_obj-flags  EXYNOS_BO_NONCONTIG) {
 +   if (!buf-sgt)
 +   return -EINTR;
 +
 +   sgl = buf-sgt-sgl;
 +   for_each_sg(buf-sgt-sgl, sgl, buf-sgt-nents, i) {
 +   if (!sgl) {
 +   DRM_ERROR(invalid SG table\n);
 +   return -EINTR;
 +   }
 +   if (page_offset  (sgl-length  PAGE_SHIFT))
 +   break;
 +   page_offset -=  (sgl-length  PAGE_SHIFT);
 +   }
 +
 +   if (i = buf-sgt-nents) {
 +   DRM_ERROR(invalid page offset\n);
 +   return -EINVAL;
 +   }
 +
 +   pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
 +   } else {
 if (!buf-pages)
 return -EINTR;

 -   pfn = page_to_pfn(buf-pages[page_offset++]);
 -   } else
 -   pfn = (buf-dma_addr  PAGE_SHIFT) + page_offset;
 +   pfn = page_to_pfn(buf-pages[0]) + page_offset;
 +   }

 return vm_insert_mixed(vma, f_vaddr, pfn);
  }
 --
 1.7.0.4

 ___
 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

[drm-intel:drm-intel-next-queued 255/259] drivers/gpu/drm/i915/i915_gem_gtt.c:366:36: sparse: dereference of noderef expression

[Fengguang Wu]

Hi Ben,

FYI, there are new sparse warnings show up in

tree:   git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head:   afef67fbc09aec8508c88aac1931661a36e91958
commit: a1e0e54668f41badfaf5e49cae9fc10b79635b25 [255/259] drm/i915: Stop using 
AGP layer for GEN6+

+ drivers/gpu/drm/i915/i915_gem_gtt.c:366:36: sparse: dereference of noderef 
expression

vim +366 drivers/gpu/drm/i915/i915_gem_gtt.c

a1e0e546 Ben Widawsky 2012-11-04  350  {
a1e0e546 Ben Widawsky 2012-11-04  351   struct drm_device *dev = obj-base.dev;
a1e0e546 Ben Widawsky 2012-11-04  352   struct drm_i915_private *dev_priv = 
dev-dev_private;
a1e0e546 Ben Widawsky 2012-11-04  353   struct sg_table *st = obj-pages;
a1e0e546 Ben Widawsky 2012-11-04  354   struct scatterlist *sg = st-sgl;
a1e0e546 Ben Widawsky 2012-11-04  355   const int first_entry = 
obj-gtt_space-start  PAGE_SHIFT;
a1e0e546 Ben Widawsky 2012-11-04  356   const int max_entries = 
dev_priv-mm.gtt-gtt_total_entries - first_entry;
a1e0e546 Ben Widawsky 2012-11-04  357   gtt_pte_t __iomem *gtt_entries = 
dev_priv-mm.gtt-gtt + first_entry;
a1e0e546 Ben Widawsky 2012-11-04  358   int unused, i = 0;
a1e0e546 Ben Widawsky 2012-11-04  359   unsigned int len, m = 0;
a1e0e546 Ben Widawsky 2012-11-04  360   dma_addr_t addr;
a1e0e546 Ben Widawsky 2012-11-04  361  
a1e0e546 Ben Widawsky 2012-11-04  362   for_each_sg(st-sgl, sg, st-nents, 
unused) {
a1e0e546 Ben Widawsky 2012-11-04  363   len = sg_dma_len(sg)  
PAGE_SHIFT;
a1e0e546 Ben Widawsky 2012-11-04  364   for (m = 0; m  len; m++) {
a1e0e546 Ben Widawsky 2012-11-04  365   addr = 
sg_dma_address(sg) + (m  PAGE_SHIFT);
a1e0e546 Ben Widawsky 2012-11-04 @366   gtt_entries[i] = 
pte_encode(dev, addr, level);
a1e0e546 Ben Widawsky 2012-11-04  367   i++;
a1e0e546 Ben Widawsky 2012-11-04  368   }
a1e0e546 Ben Widawsky 2012-11-04  369   }
a1e0e546 Ben Widawsky 2012-11-04  370  
a1e0e546 Ben Widawsky 2012-11-04  371   BUG_ON(i  max_entries);
a1e0e546 Ben Widawsky 2012-11-04  372   BUG_ON(i != obj-base.size / PAGE_SIZE);
a1e0e546 Ben Widawsky 2012-11-04  373  
a1e0e546 Ben Widawsky 2012-11-04  374   /* XXX: This serves as a posting read 
to make sure that the PTE has

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: merging printk and WARN

[David Sterba]

On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote:
 It looks like these patches were not a good idea, because in each case the
 printk provides an error level, and WARN then provides another one.

I think this is not a problem within btrfs at the place where this has
changed.

david
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[bisected] drm i915 hangs on heavy io load

[Lekensteyn]

On Sunday 04 November 2012 16:08:47 Dave Airlie wrote:
 On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining prein...@logic.at wrote:

  On Di, 30 Okt 2012, Dave Airlie wrote:
  I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
  final to 3.7-rc1 or maybe -rc2.
  
  Sorry for my ignorance ... I did on master branch
  
  $ git checkout v3.7-rc1
  ...
  $ git bisect start drivers/gpu/drm/i915
  $ git bisect bad
  $ git bisect good v3.6
  Bisecting: 121 revisions left to test after this (roughly 7 steps)
  [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new
  set_mode code flow $
  
  after that I am back somewhere around
  
  3.6.0-rc2
  
  ???
  
  Am I doing something wrong? I thought I am bisecting between 3.6 and
  3.7.-rc2? How can I go back to 3.6.0-rc2?
 
 Yeah thats fine, bisecting works by going to where commits were
 originally committed, so drm-intel-next was 3.6.0-rc2 at some point
 was only merged into Linus later.

As I mentioned on https://bugs.freedesktop.org/show_bug.cgi?id=55984, I also 
hit this bug. The first time was on branch drm-intel-next-2012-09-20 on Daniel 
Vetters drm-intel git.

I guess it has something to do with low memory. To reproduce the bug on my 
laptop with 8GB RAM and a i5-460M, I did:

1. Boot (I use KDE)
3. Start glxspheres (from http://virtualgl.org/, but glxgears might work too, 
not tested)
2. Copy a 1.2 GiB Linux source tree to /dev/shm and /tmp (both tmpfs), 5 
times. This uses 6GiB of RAM. I used this bash script:
#!/bin/bash
for i in /tmp/hang-l1 /tmp/hang-l2 /tmp/hang-l3 \
/dev/shm/hang-l1 /dev/shm/hang-l2; do
cp -ra ~/Linux-src/linux $i 
done; wait
3. When the copy is almost done, watch the machine become sluggish and 
eventually print the [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer 
elapsed... GPU hung message to the kernel log. Until the machine is rebooted, 
all OpenGL applications will fail to load.

On kernels where it was working fine, there is no lag when the copy is almost 
finished.

504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 is the first bad commit
commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Thu Aug 23 13:12:52 2012 +0100

drm/i915: Use cpu relocations if the object is in the GTT but not mappable

This prevents the case of unbinding the object in order to process the
relocations through the GTT and then rebinding it only to then proceed
to use cpu relocations as the object is now in the CPU write domain. By
choosing to use cpu relocations up front, we can therefore avoid the
rebind penalty.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

:04 04 090ed3d52b4f3210b988877f747b6ff86e123385 
1d48be89ded4777a543b693db833de64877059c4 M  drivers

Regards,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

[Rob Clark]

On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:

But even then, choosing the manager is not easy, as whoever chooses the
manager needs to observe all the possible displays used at the same
time...


Right. I was wondering if omapfb/omapdrm could understand the 'all
possible displays information' better compared to a panel's probe.

Even omapdrm/omafb can't be perfect because we could insert a panel
driver module at any time, and omapfb/omapdrm may miss that out.

True, omapdrm/fb may have a better idea. It's still unclear though.
Currently we have quite strict order in the sequence the modules need to
be loaded, which is quite bad and causes issues. We should make things
more dynamic, so that the initialization of the drivers could happen
more freely.

But that creates more problems: when booting up, omapfb starts. But
omapfb can't know if all the panel drivers have already been loaded.
omapfb may see that DVI is the default display, but what should it do if
DVI doesn't have a driver yet? It could wait, but perhaps the driver for
DVI will never even be loaded.


The encoder which is connected to the crtc (manager) is picked by 
combination of encoder-possible_crtcs bitmask and 
connector-best_encoder().  We could keep things limited so that the 
association of crtc to encoder (manager to output, roughly) never 
changes, but this isn't really the right thing to do.  It is better that 
the dssdev not rely on knowing the manager it is attached to at probe 
time, but instead grab resources more dynamically.


Also, at the moment we don't really have any notification to userspace 
about new encoders/connectors showing up (or conversely, being 
removed).  Only about existing connectors being plugged/unplugged.  The 
closest analogy is perhaps the USB display devices, but even there it is 
only the entire drm device that is plugged/unplugged.  And TBH I don't 
really see the point in supporting panel drivers being dynamically 
loaded.  It isn't like someone is dynamically soldering on a new display 
connector to some board that is running.  I think omapfb or omapdrm 
probe should trigger registering the compiled-in panel drivers, so that 
it can be sure that the dssdev's pop up before it goes and creates drm 
connector objects.  Currently we have to hack around this in omapdrm 
with late_initcall() to ensure the panel drivers are probed first, but 
that is an ugly hack that I'd like to get rid of.


BR,
-R



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: fix typo in evergreen_mc_resume()

[Michel Dänzer]

On Mon, 2012-11-05 at 11:34 -0500, alexdeuc...@gmail.com wrote: 
 From: Alex Deucher alexander.deuc...@amd.com
 
 Add missing index that may have led us to enabling
 more crtcs than necessary.
 
 May also fix:
 https://bugs.freedesktop.org/show_bug.cgi?id=56139
 
 Signed-off-by: Alex Deucher alexander.deuc...@amd.com

Reviewed-by: Michel Dänzer michel.daen...@amd.com


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel