[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Daniel Vetter 
On Mon, May 6, 2013 at 9:56 PM, Dave Airlie  wrote:
> On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter  wrote:
>> On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
>>> >>
>>> >> However if we don't set a dma mask on the usb device, the mapping
>>> >> ends up using swiotlb on machines that have it enabled, which
>>> >> is less than desireable.
>>> >>
>>> >> Signed-off-by: Dave Airlie 
>>> >
>>> > Fyi for everyone else who was not on irc when Dave discussed this:
>>> > This really shouldn't be required and I think the real issue is that
>>> > udl creates a dma_buf attachement (which is needed for device dma
>>> > only), but only really wants to do cpu access through vmap/kmap. So
>>> > not attached the device should be good enough. Cc'ing a few more lists
>>> > for better fyi ;-)
>>>
>>> Though I've looked at this a bit more, and since I want to be able to expose
>>> shared objects as proper GEM objects from the import side I really
>>> need that list of pages.
>>
>> Hm, what does "proper GEM object" mean in the context of udl?
>
> One that appears the same as a GEM object created by userspace. i.e. mmap 
> works.

Oh, we have an mmap interface in the dma_buf thing for that, and iirc
Rob Clark even bothered to implement the gem->dma_buf mmap forwarding
somewhere. And iirc android's ion-on-dma_buf stuff is even using the
mmap interface stuff.

Now for prime "let's just ship this, dammit" prevailed for now. But I
still think that hiding the backing storage a bit better (with the
eventual goal of supporting eviction with Maarten's fence/ww_mutex
madness) feels like a worthy long-term goal.

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64201

--- Comment #12 from Erdem U. Altinyurt  ---
(In reply to comment #11)
> If you're experiencing GPU lockups w/ OpenCL, I'd recommend making sure that
> you mesa includes:
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=4539f8e20af286d1f521eb016c89c6d9af0b801c
> 
> This fixed a lot of common CL-based lockups on my Radeon 6850.

Nope, I am using mesa-trunk that  includes this patch also, but it looks
doesn't help much...

-- 
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/20130506/e823b185/attachment.html>

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64201

--- Comment #11 from Aaron Watry  ---
If you're experiencing GPU lockups w/ OpenCL, I'd recommend making sure that
you mesa includes:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4539f8e20af286d1f521eb016c89c6d9af0b801c

This fixed a lot of common CL-based lockups on my Radeon 6850.

-- 
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/20130506/dcc6b347/attachment.html>

[PATCH] radeon: Allow disabling UVD

2013-05-06 Thread Parag Warudkar 
Apparently UVD doesn't yet work everywhere - so allow it to be
disabled. Shaves off some reboot and suspend/resume time on machines
where it doesn't work. Might be useful for problematic chips in the
future as well.

Patch attached as well as inline below.

Signed-off-by: Parag Warudkar 

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1442ce7..f131d8f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -79,6 +79,7 @@
  * Modules parameters.
  */
 extern int radeon_no_wb;
+extern int radeon_no_uvd;
 extern int radeon_modeset;
 extern int radeon_dynclks;
 extern int radeon_r4xx_atom;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index d33f484..7e5b171 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -147,6 +147,7 @@ static inline void radeon_unregister_atpx_handler(void) {}
 #endif

 int radeon_no_wb;
+int radeon_no_uvd;
 int radeon_modeset = 1;
 int radeon_dynclks = -1;
 int radeon_r4xx_atom = 0;
@@ -168,6 +169,9 @@ int radeon_fastfb = 0;
 MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
 module_param_named(no_wb, radeon_no_wb, int, 0444);

+MODULE_PARM_DESC(no_uvd, "Disable UVD");
+module_param_named(no_uvd, radeon_no_uvd, int, 0444);
+
 MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
 module_param_named(modeset, radeon_modeset, int, 0400);

diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index b369d42..4320973 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -329,6 +329,7 @@ typedef struct drm_radeon_kcmd_buffer {
 } drm_radeon_kcmd_buffer_t;

 extern int radeon_no_wb;
+extern int radeon_no_uvd;
 extern struct drm_ioctl_desc radeon_ioctls[];
 extern int radeon_max_ioctl;

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 906e5c0..93a7dbb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -58,7 +58,8 @@ int radeon_uvd_init(struct radeon_device *rdev)
  unsigned long bo_size;
  const char *fw_name;
  int i, r;
-
+ if (radeon_no_uvd)
+ return -EINVAL;
  INIT_DELAYED_WORK(>uvd.idle_work, radeon_uvd_idle_work_handler);

  pdev = platform_device_register_simple("radeon_uvd", 0, NULL, 0);
-- next part --
A non-text attachment was scrubbed...
Name: radeon-option-no-uvd.patch
Type: application/octet-stream
Size: 2154 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/41cada71/attachment-0001.obj>

[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

2013-05-06 Thread Jerome Glisse 
On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski  wrote:
> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski  
> wrote:
>> Signed-off-by: Andy Lutomirski 
>> ---
>>
>> This needs careful review.  I don't really know what this code does, nor
>> do I have the hardware.  (I don't understand AGP and the associated
>> caching implications.)
>
> This patch is wrong (I didn't update the matching mtrr_del), and I'm
> reworking this whole series.  But I may need some help on this one:
> why is the mtrr handle of a map (whatever a map is) exported to
> userspace via the ADD_MAP and GET_MAP ioctls?  What (if anything) is
> userspace supposed to do with it?  Do I need to return a valid MTRR
> register number?  Is there any userspace code at all that sets
> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
> and needs the MTRR, for which the drm driver doesn't already add the
> MTRR?
>
> --Andy

>From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
cover it with a write combine MTRR. The whole ioctl is use by some ddx
or maybe even directly the XServer to do this mtrr mess in userspace.

Sorry for the bad news, but that's what i remember on that front
thought i would need to read all the code again.

Cheers,
Jerome

[Bug 62466] r600g hyperz lockups with KSP 0.19

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=62466

--- Comment #9 from lct at mail.ru ---
Hi, Gerome! 

Do I understand correctly, this patch is only for R600g AND its only for kernel
(not mesa or DDI) ?

Thanks for the fix! Unfortunately I have currently no access to the machine. 

When I have it, I will test the case on the sourcecode of kernel that I had -
vanilla & crashing(1), 
as well as with your patch(2), 

and then if that happens in more actual kernel 3.8. (ubuntu raring)(3)
and finally the kernel current with patch (4)

I will test both performance with PTS Urban Terror profile, as well as
stability exactly in the case I had and report back the results.


That said I am pretty sure it works out, as others already confirm that, but
still 
- I would like you to send me your paypal account data -
for beers (green tea, coffee etc) money.. I know that you are employed by
RedHat, its only a personal way to thank you for patching.

Thank you!

-- 
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/20130506/a9be7dff/attachment.html>

[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Rob Clark 
On Mon, May 6, 2013 at 4:44 PM, Daniel Vetter  wrote:
> On Mon, May 6, 2013 at 9:56 PM, Dave Airlie  wrote:
>> On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter  wrote:
>>> On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
 >>
 >> However if we don't set a dma mask on the usb device, the mapping
 >> ends up using swiotlb on machines that have it enabled, which
 >> is less than desireable.
 >>
 >> Signed-off-by: Dave Airlie 
 >
 > Fyi for everyone else who was not on irc when Dave discussed this:
 > This really shouldn't be required and I think the real issue is that
 > udl creates a dma_buf attachement (which is needed for device dma
 > only), but only really wants to do cpu access through vmap/kmap. So
 > not attached the device should be good enough. Cc'ing a few more lists
 > for better fyi ;-)

 Though I've looked at this a bit more, and since I want to be able to 
 expose
 shared objects as proper GEM objects from the import side I really
 need that list of pages.
>>>
>>> Hm, what does "proper GEM object" mean in the context of udl?
>>
>> One that appears the same as a GEM object created by userspace. i.e. mmap 
>> works.
>
> Oh, we have an mmap interface in the dma_buf thing for that, and iirc
> Rob Clark even bothered to implement the gem->dma_buf mmap forwarding
> somewhere. And iirc android's ion-on-dma_buf stuff is even using the
> mmap interface stuff.

fwiw, what I did was dma_buf -> gem mmap fwding, ie. implement mmap
for the dmabuf object by fwd'ing it to my normal gem mmap code.  Might
be the opposite of what you are looking for here.  Although I suppose
the reverse could work to, I hadn't really thought about it yet.

BR,
-R

> Now for prime "let's just ship this, dammit" prevailed for now. But I
> still think that hiding the backing storage a bit better (with the
> eventual goal of supporting eviction with Maarten's fence/ww_mutex
> madness) feels like a worthy long-term goal.
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Daniel Vetter 
On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
> >>
> >> However if we don't set a dma mask on the usb device, the mapping
> >> ends up using swiotlb on machines that have it enabled, which
> >> is less than desireable.
> >>
> >> Signed-off-by: Dave Airlie 
> >
> > Fyi for everyone else who was not on irc when Dave discussed this:
> > This really shouldn't be required and I think the real issue is that
> > udl creates a dma_buf attachement (which is needed for device dma
> > only), but only really wants to do cpu access through vmap/kmap. So
> > not attached the device should be good enough. Cc'ing a few more lists
> > for better fyi ;-)
> 
> Though I've looked at this a bit more, and since I want to be able to expose
> shared objects as proper GEM objects from the import side I really
> need that list of pages.

Hm, what does "proper GEM object" mean in the context of udl?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.

2013-05-06 Thread Daniel Vetter 
On Mon, May 06, 2013 at 02:52:08PM +0200, dl9pf at gmx.de wrote:
> From: Jan-Simon M?ller 
> 
> 20130509: v2: (re-)add inline upon request.
> 
> Description:
> intel_gmbus_is_forced_bit is no extern as its body is right below.
> Likewise for intel_gmbus_is_port_valid.
> 
> This fixes a compilation issue with clang. An initial version of this patch
> was developed by PaX Team .
> This is respin of this patch.
> 
> Signed-off-by: Jan-Simon M?ller 
> CC: pageexec at freemail.hu
> CC: daniel.vetter at ffwll.ch
> CC: airlied at linux.ie
> CC: intel-gfx at lists.freedesktop.org
> CC: dri-devel at lists.freedesktop.org
> CC: linux-kernel at vger.kernel.org

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

2013-05-06 Thread Andy Lutomirski 
On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse  wrote:
> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski  
> wrote:
>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski  
>> wrote:
>>> Signed-off-by: Andy Lutomirski 
>>> ---
>>>
>>> This needs careful review.  I don't really know what this code does, nor
>>> do I have the hardware.  (I don't understand AGP and the associated
>>> caching implications.)
>>
>> This patch is wrong (I didn't update the matching mtrr_del), and I'm
>> reworking this whole series.  But I may need some help on this one:
>> why is the mtrr handle of a map (whatever a map is) exported to
>> userspace via the ADD_MAP and GET_MAP ioctls?  What (if anything) is
>> userspace supposed to do with it?  Do I need to return a valid MTRR
>> register number?  Is there any userspace code at all that sets
>> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
>> and needs the MTRR, for which the drm driver doesn't already add the
>> MTRR?
>>
>> --Andy
>
> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
> cover it with a write combine MTRR. The whole ioctl is use by some ddx
> or maybe even directly the XServer to do this mtrr mess in userspace.

Egads!  So we have a _DRM_WRITE_COMBINING flag, which will continue to
work fine, but almost nothing uses it.

I'm amazed this stuff works in the current code, though.  Apparently
the memory type (WC or UC) of a drm mapping is determined by the mtrr
the driver set, but if one part of the BAR is textures or the
framebuffer and another part is an outgoing command ring, won't one of
them end up with the wrong memory type?

I'd really hate to have to track fake mtrrs in the drm core to emulate
real mtrrs.

>
> Sorry for the bad news, but that's what i remember on that front
> thought i would need to read all the code again.

On the bright side, in the entire 2005 monolithic xorg tarball, the
only thing that looks at the mtrr exported to userspace appears to be
dritests.

--Andy

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #4 from Tom Stellard  ---
I just pushed the Mesa patch that updates the GPU mappings to account for the
new processors in LLVM.  Can you re-test with the latest code from the git
repository?

-- 
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/20130506/017db789/attachment.html>

DMA mapping API abuse in exynos-drm

2013-05-06 Thread Inki Dae 
SoC, it seems like that it just ignores the attribute
without iommu: in case of no iommu, dma_alloc_attr() always maps pages
allocated from highmem with kernel space. So I think we make sure that
exynos drm driver sets the attribute only with iommu to avoid such
confusing. For this, will post it soon.

Thanks,
Inki Dae

Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/9f3fa9e5/attachment-0001.html>

[PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.

2013-05-06 Thread dl...@gmx.de 
From: Jan-Simon M?ller 

20130509: v2: (re-)add inline upon request.

Description:
intel_gmbus_is_forced_bit is no extern as its body is right below.
Likewise for intel_gmbus_is_port_valid.

This fixes a compilation issue with clang. An initial version of this patch
was developed by PaX Team .
This is respin of this patch.

Signed-off-by: Jan-Simon M?ller 
CC: pageexec at freemail.hu
CC: daniel.vetter at ffwll.ch
CC: airlied at linux.ie
CC: intel-gfx at lists.freedesktop.org
CC: dri-devel at lists.freedesktop.org
CC: linux-kernel at vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3ac71db..b41c49d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1806,7 +1806,7 @@ void i915_teardown_sysfs(struct drm_device *dev_priv);
 /* intel_i2c.c */
 extern int intel_setup_gmbus(struct drm_device *dev);
 extern void intel_teardown_gmbus(struct drm_device *dev);
-extern inline bool intel_gmbus_is_port_valid(unsigned port)
+static inline bool intel_gmbus_is_port_valid(unsigned port)
 {
return (port >= GMBUS_PORT_SSC && port <= GMBUS_PORT_DPD);
 }
@@ -1815,7 +1815,7 @@ extern struct i2c_adapter *intel_gmbus_get_adapter(
struct drm_i915_private *dev_priv, unsigned port);
 extern void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed);
 extern void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit);
-extern inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
+static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
 {
return container_of(adapter, struct intel_gmbus, adapter)->force_bit;
 }
-- 
1.8.1.4

[Bug 62669] HyperZ freeze when playing PrBoom-Plus demo with lots of monsters

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=62669

Jerome Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jerome Glisse  ---
Closing pushed to master and going to push to 9.1

-- 
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/20130506/df2e4845/attachment.html>

[Bug 62466] r600g hyperz lockups with KSP 0.19

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=62466

Jerome Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jerome Glisse  ---
Closing pushed to master and going to push to 9.1

-- 
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/20130506/d97b2b9e/attachment.html>

[Bug 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=59592

Jerome Glisse  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jerome Glisse  ---
Closing pushed to master and going to push to 9.1

-- 
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/20130506/ea1b1307/attachment-0001.html>

[Bug 60848] [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=60848

Jerome Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jerome Glisse  ---
Closing pushed to master and going to push to 9.1

-- 
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/20130506/02e85038/attachment.html>

[Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.

2013-05-06 Thread Jan-Simon Möller 
Ok, so let me resend a version with "static inline" .

Best,
JS


On Saturday 04 May 2013 10:55:50 PaX Team wrote:
> On 3 May 2013 at 15:03, Jani Nikula wrote:
> > >> This fixes a compilation issue with clang. An initial version of this
> > >> patch
> > >> was developed by PaX Team .
> > >> This is respin of this patch.
> > >> 
> > >> Signed-off-by: Jan-Simon M?ller 
> > >> CC: pageexec at freemail.hu
> > >> CC: daniel.vetter at ffwll.ch
> > >> CC: airlied at linux.ie
> > >> CC: intel-gfx at lists.freedesktop.org
> > >> CC: dri-devel at lists.freedesktop.org
> > >> CC: linux-kernel at vger.kernel.org
> > > 
> > > Picked up for -fixes, thanks for the patch.
> > 
> > Please drop it.
> > 
> > The patch removes the inline keyword, creating dozens of copies of the
> 
> > functions, and consequently loads of warnings:
> in my original patch they were both static inline, not sure where the
> inline got lost...
-- 

Dipl.-Ing.
Jan-Simon M?ller

jansimon.moeller at gmx.de

[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

2013-05-06 Thread Andy Lutomirski 
On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski  wrote:
> Signed-off-by: Andy Lutomirski 
> ---
>
> This needs careful review.  I don't really know what this code does, nor
> do I have the hardware.  (I don't understand AGP and the associated
> caching implications.)

This patch is wrong (I didn't update the matching mtrr_del), and I'm
reworking this whole series.  But I may need some help on this one:
why is the mtrr handle of a map (whatever a map is) exported to
userspace via the ADD_MAP and GET_MAP ioctls?  What (if anything) is
userspace supposed to do with it?  Do I need to return a valid MTRR
register number?  Is there any userspace code at all that sets
_DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
and needs the MTRR, for which the drm driver doesn't already add the
MTRR?

--Andy

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=63732

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[PATCH 3/4] drm/mgag200: Convert counter delays to jiffies

2013-05-06 Thread Christopher Harvey 
Signed-off-by: Christopher Harvey 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6f3b9db..6dbf6de 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -46,29 +46,26 @@ static void mga_crtc_load_lut(struct drm_crtc *crtc)

 static inline void mga_wait_vsync(struct mga_device *mdev)
 {
-   unsigned int count = 0;
+   unsigned long timeout = jiffies + HZ/10;
unsigned int status = 0;

do {
status = RREG32(MGAREG_Status);
-   count++;
-   } while ((status & 0x08) && (count < 25));
-   count = 0;
+   } while ((status & 0x08) && time_before(jiffies, timeout));
+   timeout = jiffies + HZ/10;
status = 0;
do {
status = RREG32(MGAREG_Status);
-   count++;
-   } while (!(status & 0x08) && (count < 25));
+   } while (!(status & 0x08) && time_before(jiffies, timeout));
 }

 static inline void mga_wait_busy(struct mga_device *mdev)
 {
-   unsigned int count = 0;
+   unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
status = RREG8(MGAREG_Status + 2);
-   count++;
-   } while ((status & 0x01) && (count < 50));
+   } while ((status & 0x01) && time_before(jiffies, timeout));
 }

 /*
-- 
1.8.1.5

[PATCH v2 3/4] drm/mgag200: Convert counter delays to jiffies

2013-05-06 Thread Christopher Harvey 
Signed-off-by: Christopher Harvey 
Acked-by: Julia Lemire 
Tested-by: Julia Lemire 
Acked-by: Mathieu Larouche 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6f3b9db..6dbf6de 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -46,29 +46,26 @@ static void mga_crtc_load_lut(struct drm_crtc *crtc)

 static inline void mga_wait_vsync(struct mga_device *mdev)
 {
-   unsigned int count = 0;
+   unsigned long timeout = jiffies + HZ/10;
unsigned int status = 0;

do {
status = RREG32(MGAREG_Status);
-   count++;
-   } while ((status & 0x08) && (count < 25));
-   count = 0;
+   } while ((status & 0x08) && time_before(jiffies, timeout));
+   timeout = jiffies + HZ/10;
status = 0;
do {
status = RREG32(MGAREG_Status);
-   count++;
-   } while (!(status & 0x08) && (count < 25));
+   } while (!(status & 0x08) && time_before(jiffies, timeout));
 }

 static inline void mga_wait_busy(struct mga_device *mdev)
 {
-   unsigned int count = 0;
+   unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
status = RREG8(MGAREG_Status + 2);
-   count++;
-   } while ((status & 0x01) && (count < 50));
+   } while ((status & 0x01) && time_before(jiffies, timeout));
 }

 /*
-- 
1.8.1.5

[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Dave Airlie 
>>
>> However if we don't set a dma mask on the usb device, the mapping
>> ends up using swiotlb on machines that have it enabled, which
>> is less than desireable.
>>
>> Signed-off-by: Dave Airlie 
>
> Fyi for everyone else who was not on irc when Dave discussed this:
> This really shouldn't be required and I think the real issue is that
> udl creates a dma_buf attachement (which is needed for device dma
> only), but only really wants to do cpu access through vmap/kmap. So
> not attached the device should be good enough. Cc'ing a few more lists
> for better fyi ;-)

Though I've looked at this a bit more, and since I want to be able to expose
shared objects as proper GEM objects from the import side I really
need that list of pages.

So it looks like this won't really fly.

Dave.

[PATCHv5 0/2] Speed Cap fixes for ppc64

2013-05-06 Thread Jerome Glisse 
n Mon, May 6, 2013 at 10:32 AM, Alex Deucher  wrote:
> On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
>  wrote:
>> On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:
>>
>>> This patch series does:
>>>   1. max_bus_speed is used to set the device to gen2 speeds
>>>   2. on power there's no longer a conflict between the pseries call and 
>>> other
>>> architectures, because the overwrite is done via a ppc_md hook
>>>   3. radeon is using bus->max_bus_speed instead of 
>>> drm_pcie_get_speed_cap_mask
>>> for gen2 capability detection
>>>
>>> The first patch consists of some architecture changes, such as adding a 
>>> hook on
>>> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a
>>> function, while all other architectures get a NULL pointer. So that whenever
>>> pci_create_root_bus is called, we'll get max_bus_speed properly setup from
>>> OpenFirmware.
>>>
>>> The second patch consists of simple radeon changes not to call
>>> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines,
>>> the max_bus_speed property will be properly set already.
>>
>> So I'm ok with the approach now and I might even put the powerpc patch
>> in for 3.10 since arguably we are fixing a nasty bug (uninitialized
>> max_bus_speed).
>>
>> David, what's your feeling about the radeon change ? It would be nice if
>> that could go in soon for various distro targets :-) On the other hand
>> I'm not going to be pushy if you are not comfortable with it.
>
> FWIW, the radeon change looks fine to me.
>
> Alex

As said previously, looks fine to me too.

Cheers,
Jerome

[PATCHv5 0/2] Speed Cap fixes for ppc64

2013-05-06 Thread Alex Deucher 
On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
 wrote:
> On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:
>
>> This patch series does:
>>   1. max_bus_speed is used to set the device to gen2 speeds
>>   2. on power there's no longer a conflict between the pseries call and other
>> architectures, because the overwrite is done via a ppc_md hook
>>   3. radeon is using bus->max_bus_speed instead of 
>> drm_pcie_get_speed_cap_mask
>> for gen2 capability detection
>>
>> The first patch consists of some architecture changes, such as adding a hook 
>> on
>> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a
>> function, while all other architectures get a NULL pointer. So that whenever
>> pci_create_root_bus is called, we'll get max_bus_speed properly setup from
>> OpenFirmware.
>>
>> The second patch consists of simple radeon changes not to call
>> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines,
>> the max_bus_speed property will be properly set already.
>
> So I'm ok with the approach now and I might even put the powerpc patch
> in for 3.10 since arguably we are fixing a nasty bug (uninitialized
> max_bus_speed).
>
> David, what's your feeling about the radeon change ? It would be nice if
> that could go in soon for various distro targets :-) On the other hand
> I'm not going to be pushy if you are not comfortable with it.

FWIW, the radeon change looks fine to me.

Alex

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #3 from Michel D?nzer  ---
Could be either, but you generally need matching Git snapshots anyway.

-- 
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/20130506/930493f6/attachment.html>

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=63732

--- Comment #6 from Honza Tvrznik  ---
Hello,

upgrade mesa library/ati-dri to version 9.1.2 solve this problem. Request can
be closed. Thanks!

-- 
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/20130506/9b169ca1/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64257

Mike Lothian  changed:

   What|Removed |Added

 CC||mike at fireburn.co.uk

--- Comment #2 from Mike Lothian  ---
Is it mesa or llvm that needs bisecting or both?

-- 
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/20130506/b4f17172/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #1 from Alex Deucher  ---
Any chance you could bisect?  It might be a duplicate of bug 64193.

-- 
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/20130506/8d7dacf3/attachment.html>

[Bug 64257] New: RS880 issues with r600-llvm-compiler

2013-05-06 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64257

  Priority: medium
Bug ID: 64257
  Assignee: dri-devel at lists.freedesktop.org
   Summary: RS880 issues with r600-llvm-compiler
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: mike at fireburn.co.uk
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Hi

Kwin starts with a black screen if I use r600-llvm-compiler on my RS880

When I switched off the llvm parts and just ran glxgears using
r600-llvm-compiler the gears looked like they were layered wrongly and slightly
darker

I'm not sure when this regression appeared - I'm guessing within the last two
weeks - I mostly ssh into the box

I'm always running the latest llvm, clang, libdrm and mesa

I didn't see anything strange in my dmesg or .xsession-errors  or from the
glxgears text output

Could this be due to RS880 being singled out in llvm as a separate processor
variant?

ie r600g/llvm: Update radeon family mappings for LLVM backend or [PATCH 1/2]
R600: Add some new processor variants

-- 
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/20130506/800425b6/attachment.html>

nouveau GF108 kernel crash in optimus mode when enabling external display output

2013-05-06 Thread Pasi Kärkkäinen 
Hello,

Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 5400M] 
(rev a1)

$ uname -a
Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I boot up the system with only laptop internal LVDS active on intel gpu, and 
when in X session,
I enable the second display on nouveau gpu connected to the dock DP2/DVI 
connector.
At this point the kernel crashes immediately. 

Screenshots of the kernel crash/stacktrace here:
http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg
http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg

hand-written bits from the kernel crash:

Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 
2349H2G/2349H2G
RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 
[nouveau]
RSP: 0018:8803298357c8 EFLAGS: 00010206
..
Process Xorg (pid: 1208,..)
..
Call Trace:
.. nouveau_vm_map_sg+0xc2/0x130 [nouveau]
.. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau]
.. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau]
.. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau]
.. nouveau_bo_move+0xa5/0x400 [nouveau]
.. ttm_bo_handle_move_mem+0x245/0x610 [ttm]

More info from the screenshots above.. 


dmesg drm bits before the crash:

[0.137586] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.137590] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=none,locks=none
[0.137591] vgaarb: loaded
[0.137591] vgaarb: bridge control possible :01:00.0
[0.137592] vgaarb: no bridge control possible :00:02.0
[0.529802] fb0: VESA VGA frame buffer device
[0.877212] ata1.00: supports DRM functions and may not be fully accessible
[0.878010] ata1.00: supports DRM functions and may not be fully accessible
[1.969486] [drm] Initialized drm 1.1.0 20060810
[1.990584] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG_.VID_ 
handle
[1.990610] nouveau :01:00.0: enabling device (0004 -> 0007)
[1.990874] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0c1780a1
[1.990877] nouveau  [  DEVICE][:01:00.0] Chipset: GF108 (NVC1)
[1.990878] nouveau  [  DEVICE][:01:00.0] Family : NVC0
[1.992485] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[2.002182] nouveau  [   VBIOS][:01:00.0] ... signature not found
[2.002184] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[2.002243] nouveau  [   VBIOS][:01:00.0] ... signature not found
[2.002245] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[2.189928] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[2.189935] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[2.190143] nouveau  [   VBIOS][:01:00.0] BIT signature found
[2.190149] nouveau  [   VBIOS][:01:00.0] version 70.08.b7.02.02
[2.190467] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
[2.190470] nouveau  [   VBIOS][:01:00.0] running init tables
[2.278184] nouveau  [ PFB][:01:00.0] RAM type: DDR3
[2.278189] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
[2.278192] nouveau  [ PFB][:01:00.0]ZCOMP: 0 tags
[2.311802] nouveau  [ DRM] VRAM: 512 MiB
[2.311805] nouveau  [ DRM] GART: 512 MiB
[2.311810] nouveau  [ DRM] BIT BIOS found
[2.311814] nouveau  [ DRM] Bios version 70.08.b7.02
[2.311831] nouveau  [ DRM] TMDS table version 2.0
[2.311832] nouveau  [ DRM] DCB version 4.0
[2.311833] nouveau  [ DRM] DCB outp 00: 01800323 00010034
[2.311834] nouveau  [ DRM] DCB outp 01: 02811300 
[2.311835] nouveau  [ DRM] DCB outp 02: 028223a6 0f220010
[2.311836] nouveau  [ DRM] DCB outp 03: 02822362 00020010
[2.311837] nouveau  [ DRM] DCB outp 04: 048333b6 0f220010
[2.311838] nouveau  [ DRM] DCB outp 05: 04833372 00020010
[2.311839] nouveau  [ DRM] DCB outp 06: 088443c6 0f220010
[2.311840] nouveau  [ DRM] DCB outp 07: 08844382 00020010
[2.311841] nouveau  [ DRM] DCB conn 00: 0040
[2.311842] nouveau  [ DRM] DCB conn 01: 0100
[2.311843] nouveau  [ DRM] DCB conn 02: 00110246
[2.311844] nouveau  [ DRM] DCB conn 03: 00220346
[2.311845] nouveau  [ DRM] DCB conn 04: 01400446
[2.312502] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[2.312503] [drm] No driver support for vblank timestamp query.
[2.312575] nouveau  [ DRM] ACPI backlight interface available, not 
registering our own
[2.312612] nouveau W[ DRM] voltage table 0x50 unknown
[2.312769] nouveau  [ DRM] 2 available performance level(s)
[2.312771] nouveau  [ DRM] 1: core 270MHz shader 540MHz memory 405MHz
[

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=63732

--- Comment #6 from Honza Tvrznik flate...@atlas.cz ---
Hello,

upgrade mesa library/ati-dri to version 9.1.2 solve this problem. Request can
be closed. Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mgag200 code cleanup patches

2013-05-06 Thread Paul Menzel 
Dear Christopher,


Am Montag, den 29.04.2013, 14:37 -0400 schrieb Christopher Harvey:
 I submitted these a while ago, but I think they got lost in the
 mailing list. Just wanted to make sure they get a shot at the merge
 window.

as you resend the patches you could have easily amended the commit
message to address my comments.

Thanks again for your patches and let’s hope that they get in with the
next merge window.


Thanks,

Paul

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

[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=63732

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv5 0/2] Speed Cap fixes for ppc64

2013-05-06 Thread Alex Deucher 
On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:

 This patch series does:
   1. max_bus_speed is used to set the device to gen2 speeds
   2. on power there's no longer a conflict between the pseries call and other
 architectures, because the overwrite is done via a ppc_md hook
   3. radeon is using bus-max_bus_speed instead of 
 drm_pcie_get_speed_cap_mask
 for gen2 capability detection

 The first patch consists of some architecture changes, such as adding a hook 
 on
 powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a
 function, while all other architectures get a NULL pointer. So that whenever
 pci_create_root_bus is called, we'll get max_bus_speed properly setup from
 OpenFirmware.

 The second patch consists of simple radeon changes not to call
 drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines,
 the max_bus_speed property will be properly set already.

 So I'm ok with the approach now and I might even put the powerpc patch
 in for 3.10 since arguably we are fixing a nasty bug (uninitialized
 max_bus_speed).

 David, what's your feeling about the radeon change ? It would be nice if
 that could go in soon for various distro targets :-) On the other hand
 I'm not going to be pushy if you are not comfortable with it.

FWIW, the radeon change looks fine to me.

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

Re: [PATCHv5 0/2] Speed Cap fixes for ppc64

2013-05-06 Thread Jerome Glisse 
n Mon, May 6, 2013 at 10:32 AM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
 b...@kernel.crashing.org wrote:
 On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:

 This patch series does:
   1. max_bus_speed is used to set the device to gen2 speeds
   2. on power there's no longer a conflict between the pseries call and 
 other
 architectures, because the overwrite is done via a ppc_md hook
   3. radeon is using bus-max_bus_speed instead of 
 drm_pcie_get_speed_cap_mask
 for gen2 capability detection

 The first patch consists of some architecture changes, such as adding a 
 hook on
 powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a
 function, while all other architectures get a NULL pointer. So that whenever
 pci_create_root_bus is called, we'll get max_bus_speed properly setup from
 OpenFirmware.

 The second patch consists of simple radeon changes not to call
 drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines,
 the max_bus_speed property will be properly set already.

 So I'm ok with the approach now and I might even put the powerpc patch
 in for 3.10 since arguably we are fixing a nasty bug (uninitialized
 max_bus_speed).

 David, what's your feeling about the radeon change ? It would be nice if
 that could go in soon for various distro targets :-) On the other hand
 I'm not going to be pushy if you are not comfortable with it.

 FWIW, the radeon change looks fine to me.

 Alex

As said previously, looks fine to me too.

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

[Bug 60848] [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=60848

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jerome Glisse gli...@freedesktop.org ---
Closing pushed to master and going to push to 9.1

-- 
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 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=59592

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jerome Glisse gli...@freedesktop.org ---
Closing pushed to master and going to push to 9.1

-- 
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 62466] r600g hyperz lockups with KSP 0.19

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=62466

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jerome Glisse gli...@freedesktop.org ---
Closing pushed to master and going to push to 9.1

-- 
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 62669] HyperZ freeze when playing PrBoom-Plus demo with lots of monsters

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=62669

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jerome Glisse gli...@freedesktop.org ---
Closing pushed to master and going to push to 9.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.

2013-05-06 Thread Daniel Vetter 
On Mon, May 06, 2013 at 02:52:08PM +0200, dl...@gmx.de wrote:
 From: Jan-Simon Möller dl...@gmx.de
 
 20130509: v2: (re-)add inline upon request.
 
 Description:
 intel_gmbus_is_forced_bit is no extern as its body is right below.
 Likewise for intel_gmbus_is_port_valid.
 
 This fixes a compilation issue with clang. An initial version of this patch
 was developed by PaX Team pageexec at freemail.hu.
 This is respin of this patch.
 
 Signed-off-by: Jan-Simon Möller dl...@gmx.de
 CC: pagee...@freemail.hu
 CC: daniel.vet...@ffwll.ch
 CC: airl...@linux.ie
 CC: intel-...@lists.freedesktop.org
 CC: dri-devel@lists.freedesktop.org
 CC: linux-ker...@vger.kernel.org

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #4 from Tom Stellard tstel...@gmail.com ---
I just pushed the Mesa patch that updates the GPU mappings to account for the
new processors in LLVM.  Can you re-test with the latest code from the git
repository?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Daniel Vetter 
On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
 
  However if we don't set a dma mask on the usb device, the mapping
  ends up using swiotlb on machines that have it enabled, which
  is less than desireable.
 
  Signed-off-by: Dave Airlie airl...@redhat.com
 
  Fyi for everyone else who was not on irc when DaveI discussed this:
  This really shouldn't be required and I think the real issue is that
  udl creates a dma_buf attachement (which is needed for device dma
  only), but only really wants to do cpu access through vmap/kmap. So
  not attached the device should be good enough. Cc'ing a few more lists
  for better fyi ;-)
 
 Though I've looked at this a bit more, and since I want to be able to expose
 shared objects as proper GEM objects from the import side I really
 need that list of pages.

Hm, what does proper GEM object mean in the context of udl?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62466] r600g hyperz lockups with KSP 0.19

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=62466

--- Comment #9 from l...@mail.ru ---
Hi, Gerome! 

Do I understand correctly, this patch is only for R600g AND its only for kernel
(not mesa or DDI) ?

Thanks for the fix! Unfortunately I have currently no access to the machine. 

When I have it, I will test the case on the sourcecode of kernel that I had -
vanilla  crashing(1), 
as well as with your patch(2), 

and then if that happens in more actual kernel 3.8. (ubuntu raring)(3)
and finally the kernel current with patch (4)

I will test both performance with PTS Urban Terror profile, as well as
stability exactly in the case I had and report back the results.


That said I am pretty sure it works out, as others already confirm that, but
still 
- I would like you to send me your paypal account data -
for beers (green tea, coffee etc) money.. I know that you are employed by
RedHat, its only a personal way to thank you for patching.

Thank you!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Dave Airlie 
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
 
  However if we don't set a dma mask on the usb device, the mapping
  ends up using swiotlb on machines that have it enabled, which
  is less than desireable.
 
  Signed-off-by: Dave Airlie airl...@redhat.com
 
  Fyi for everyone else who was not on irc when DaveI discussed this:
  This really shouldn't be required and I think the real issue is that
  udl creates a dma_buf attachement (which is needed for device dma
  only), but only really wants to do cpu access through vmap/kmap. So
  not attached the device should be good enough. Cc'ing a few more lists
  for better fyi ;-)

 Though I've looked at this a bit more, and since I want to be able to expose
 shared objects as proper GEM objects from the import side I really
 need that list of pages.

 Hm, what does proper GEM object mean in the context of udl?

One that appears the same as a GEM object created by userspace. i.e. mmap works.

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

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64201

--- Comment #11 from Aaron Watry awa...@gmail.com ---
If you're experiencing GPU lockups w/ OpenCL, I'd recommend making sure that
you mesa includes:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4539f8e20af286d1f521eb016c89c6d9af0b801c

This fixed a lot of common CL-based lockups on my Radeon 6850.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Daniel Vetter 
On Mon, May 6, 2013 at 9:56 PM, Dave Airlie airl...@gmail.com wrote:
 On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
 
  However if we don't set a dma mask on the usb device, the mapping
  ends up using swiotlb on machines that have it enabled, which
  is less than desireable.
 
  Signed-off-by: Dave Airlie airl...@redhat.com
 
  Fyi for everyone else who was not on irc when DaveI discussed this:
  This really shouldn't be required and I think the real issue is that
  udl creates a dma_buf attachement (which is needed for device dma
  only), but only really wants to do cpu access through vmap/kmap. So
  not attached the device should be good enough. Cc'ing a few more lists
  for better fyi ;-)

 Though I've looked at this a bit more, and since I want to be able to expose
 shared objects as proper GEM objects from the import side I really
 need that list of pages.

 Hm, what does proper GEM object mean in the context of udl?

 One that appears the same as a GEM object created by userspace. i.e. mmap 
 works.

Oh, we have an mmap interface in the dma_buf thing for that, and iirc
Rob Clark even bothered to implement the gem-dma_buf mmap forwarding
somewhere. And iirc android's ion-on-dma_buf stuff is even using the
mmap interface stuff.

Now for prime let's just ship this, dammit prevailed for now. But I
still think that hiding the backing storage a bit better (with the
eventual goal of supporting eviction with Maarten's fence/ww_mutex
madness) feels like a worthy long-term goal.

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

2013-05-06 Thread Dave Airlie 
 One that appears the same as a GEM object created by userspace. i.e. mmap 
 works.

 Oh, we have an mmap interface in the dma_buf thing for that, and iirc
 Rob Clark even bothered to implement the gem-dma_buf mmap forwarding
 somewhere. And iirc android's ion-on-dma_buf stuff is even using the
 mmap interface stuff.

 fwiw, what I did was dma_buf - gem mmap fwding, ie. implement mmap
 for the dmabuf object by fwd'ing it to my normal gem mmap code.  Might
 be the opposite of what you are looking for here.  Although I suppose
 the reverse could work to, I hadn't really thought about it yet.


Yeah thats the opposite, I want to implement my GEM mmap ioctls using
dma-buf mmaps :)

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

Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

2013-05-06 Thread Jerome Glisse 
On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski l...@amacapital.net wrote:
 On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski l...@amacapital.net wrote:
 Signed-off-by: Andy Lutomirski l...@amacapital.net
 ---

 This needs careful review.  I don't really know what this code does, nor
 do I have the hardware.  (I don't understand AGP and the associated
 caching implications.)

 This patch is wrong (I didn't update the matching mtrr_del), and I'm
 reworking this whole series.  But I may need some help on this one:
 why is the mtrr handle of a map (whatever a map is) exported to
 userspace via the ADD_MAP and GET_MAP ioctls?  What (if anything) is
 userspace supposed to do with it?  Do I need to return a valid MTRR
 register number?  Is there any userspace code at all that sets
 _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
 and needs the MTRR, for which the drm driver doesn't already add the
 MTRR?

 --Andy

From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
cover it with a write combine MTRR. The whole ioctl is use by some ddx
or maybe even directly the XServer to do this mtrr mess in userspace.

Sorry for the bad news, but that's what i remember on that front
thought i would need to read all the code again.

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

[Bug 51787] performance regression with llvm shader compiler in ut2004

2013-05-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=51787

--- Comment #6 from almos aaalmo...@gmail.com ---
Now I took a new look at the issue with GALLIUM_HUD=fps, and there is
definitely a serious problem with cpufreq. I have a few scripts to switch
cpufreq governor between performance and ondemand (Phenom II x4), and to switch
between high and low gpu power profiles (HD6850). When ondemand is selected, it
seriously limits performance, and causes noticeable variance in fps. Some
examples:

Psychonauts, main menu (Raz standing on top of the giant brain)
ondemand/low 20 fps
ondemand/high 40-50 fps
performance/low 29 fps
performance/high 104 fps

SW:KoToR, the main character standing alone on Dantuine, looking at the Ebon
Hawk
ondemand/low 20-30 fps
ondemand/high 20-30 fps
performance/low 55-60 fps
performance/high 68 fps

The difference between ondemand and performance makes a huge difference in
native games as well. Quake Wars, Team Fortress 2, and UT2004 are all
borderline playable with ondemand, but run perfectly with performance. It's not
just a drop in fps, but a very noticeable laggyness, that kills the games.

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

linux-next: manual merge of the drm-intel tree with Linus' tree

2013-05-06 Thread Stephen Rothwell 
Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 (drm/i915:
Make data/link N value power of two) from Linus' tree and commit
e3b95f1eb5b9 (drm/i915: Apply OCD to data/link m/n register #defines)
from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

Daniel, I assume all this stuff being added to the drm-intel tree is
going upstream very soon?
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_reg.h
index 83f9c26,a470103..000
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@@ -2648,18 -2768,19 +2768,19 @@@
   * which is after the LUTs, so we want the bytes for our color format.
   * For our current usage, this is always 3, one byte for R, G and B.
   */
- #define _PIPEA_GMCH_DATA_M0x70050
- #define _PIPEB_GMCH_DATA_M0x71050
+ #define _PIPEA_DATA_M_G4X 0x70050
+ #define _PIPEB_DATA_M_G4X 0x71050
  
  /* Transfer unit size for display port - 1, default is 0x3f (for TU size 64) 
*/
 -#define   PIPE_GMCH_DATA_M_TU_SIZE_MASK   (0x3f  25)
 -#define   PIPE_GMCH_DATA_M_TU_SIZE_SHIFT  25
 +#define  TU_SIZE(x) (((x)-1)  25) /* default size 64 */
 +#define  TU_SIZE_MASK   (0x3f  25)
+ #define  TU_SIZE_SHIFT25
  
 -#define   PIPE_GMCH_DATA_M_MASK   (0xff)
 +#define  DATA_LINK_M_N_MASK   (0xff)
 +#define  DATA_LINK_N_MAX  (0x80)
  
- #define _PIPEA_GMCH_DATA_N0x70054
- #define _PIPEB_GMCH_DATA_N0x71054
+ #define _PIPEA_DATA_N_G4X 0x70054
+ #define _PIPEB_DATA_N_G4X 0x71054
 -#define   PIPE_GMCH_DATA_N_MASK   (0xff)
  
  /*
   * Computing Link M and N values for the Display Port link
@@@ -2672,16 -2793,18 +2793,16 @@@
   * Attributes and VB-ID.
   */
  
- #define _PIPEA_DP_LINK_M  0x70060
- #define _PIPEB_DP_LINK_M  0x71060
+ #define _PIPEA_LINK_M_G4X 0x70060
+ #define _PIPEB_LINK_M_G4X 0x71060
 -#define   PIPEA_DP_LINK_M_MASK(0xff)
  
- #define _PIPEA_DP_LINK_N  0x70064
- #define _PIPEB_DP_LINK_N  0x71064
+ #define _PIPEA_LINK_N_G4X 0x70064
+ #define _PIPEB_LINK_N_G4X 0x71064
 -#define   PIPEA_DP_LINK_N_MASK(0xff)
  
- #define PIPE_GMCH_DATA_M(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_M, 
_PIPEB_GMCH_DATA_M)
- #define PIPE_GMCH_DATA_N(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_N, 
_PIPEB_GMCH_DATA_N)
- #define PIPE_DP_LINK_M(pipe) _PIPE(pipe, _PIPEA_DP_LINK_M, _PIPEB_DP_LINK_M)
- #define PIPE_DP_LINK_N(pipe) _PIPE(pipe, _PIPEA_DP_LINK_N, _PIPEB_DP_LINK_N)
+ #define PIPE_DATA_M_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_M_G4X, 
_PIPEB_DATA_M_G4X)
+ #define PIPE_DATA_N_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_N_G4X, 
_PIPEB_DATA_N_G4X)
+ #define PIPE_LINK_M_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_M_G4X, 
_PIPEB_LINK_M_G4X)
+ #define PIPE_LINK_N_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_N_G4X, 
_PIPEB_LINK_N_G4X)
  
  /* Display  cursor control */
  


pgpDXJrNF_Fz2.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

2013-05-06 Thread Dave Airlie 

 From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
 cover it with a write combine MTRR. The whole ioctl is use by some ddx
 or maybe even directly the XServer to do this mtrr mess in userspace.

 Egads!  So we have a _DRM_WRITE_COMBINING flag, which will continue to
 work fine, but almost nothing uses it.

 I'm amazed this stuff works in the current code, though.  Apparently
 the memory type (WC or UC) of a drm mapping is determined by the mtrr
 the driver set, but if one part of the BAR is textures or the
 framebuffer and another part is an outgoing command ring, won't one of
 them end up with the wrong memory type?

Nobody sane puts the command ring in VRAM.

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