no hdmi sound on hd5450

2013-08-18 Thread stompdagg...@yahoo.com 
>2013/8/18 StompDagger1 at yahoo.com :

>> 2013/8/18 StompDagger1 at yahoo.com :
>>>> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
>>>> setting bits in a register" which you've commited fixes my issue?
>>
>>>Yes, I believe so! Sorry, I forgot to ping you about that.
>>
>> thats ok, I've applied the patch it doesn't seems to work, I'll verify later
>> today when I'll get home.
>>
>> also, does screen flickering is part of this bug?
>
>Please create a bug report, and stop using HTML in your e-mail all the time.
>
>Provide output of "avivotool regs hdmi" in your bug report.

bug 68244 opened.

I'm trying to figure out how to disable HTML in mails in yahoo, still no luck, 
sorry.
-- next part ------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130818/e28e939f/attachment.html>

[PATCH] drm: Eliminate dev->vmalist

2013-08-18 Thread Daniel Vetter 
On Fri, Aug 16, 2013 at 12:24:37PM +0100, Chris Wilson wrote:
> The primary purpose of this list is for pretty printing the maps through
> debugfs/vma - per process information can be found in /proc/*/map et al.
> However, the list manipulation eats processor cycles resulting in a near
> indefinite (I got bored) stall for a leaky i-g-t/gem_concurrent_blit.
> 
> There is one true user of the vmalist though. drm_vm_shm_close() uses
> the list to count the number of drm_local_map references. For this, we
> switch to using a counter inside drm_local_map.
> 
> This patch kills drm_vm_open_locked and drm_vm_close_locked, and
> redirects the one user outside of the core (exoynos) to use the now
> semantically equivalent drm_gem_vm_open.
> 
> Signed-off-by: Chris Wilson 
> Cc: Dave Airlie 
> Cc: Rob Clark 
> Cc: Inki Dae 

Ok, I've accidentally read through the exynos mmap code and now I'm
desparately trying to get a bunch of forks out of my eyes again.

So just one question: Why is this stuff not using the gem mmap offset
stuff, but still tries to reinvent the useless parts of that wheel (like
drm_vm_open/close)?

/rant

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_bufs.c  |  1 +
>  drivers/gpu/drm/drm_drv.c   |  8 -
>  drivers/gpu/drm/drm_gem.c   | 16 +++--
>  drivers/gpu/drm/drm_info.c  | 38 -
>  drivers/gpu/drm/drm_stub.c  |  1 -
>  drivers/gpu/drm/drm_vm.c| 58 
> +++--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  9 +
>  include/drm/drmP.h  |  7 ++--
>  8 files changed, 20 insertions(+), 118 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index bef4abf..b0aa2eb 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -152,6 +152,7 @@ static int drm_addmap_core(struct drm_device * dev, 
> resource_size_t offset,
>   map->size = size;
>   map->flags = flags;
>   map->type = type;
> + map->count = 0;
>  
>   /* Only allow shared memory to be removable since we only keep enough
>* book keeping information about shared memory to allow for removal
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 799..7ec9959 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -182,8 +182,6 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>   */
>  int drm_lastclose(struct drm_device * dev)
>  {
> - struct drm_vma_entry *vma, *vma_temp;
> -
>   DRM_DEBUG("\n");
>  
>   if (dev->driver->lastclose)
> @@ -203,12 +201,6 @@ int drm_lastclose(struct drm_device * dev)
>   dev->sg = NULL;
>   }
>  
> - /* Clear vma list (only built for debugging) */
> - list_for_each_entry_safe(vma, vma_temp, >vmalist, head) {
> - list_del(>head);
> - kfree(vma);
> - }
> -
>   if (drm_core_check_feature(dev, DRIVER_HAVE_DMA) &&
>   !drm_core_check_feature(dev, DRIVER_MODESET))
>   drm_dma_takedown(dev);
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 9ab038c..84a5834 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -573,22 +573,16 @@ void drm_gem_vm_open(struct vm_area_struct *vma)
>   struct drm_gem_object *obj = vma->vm_private_data;
>  
>   drm_gem_object_reference(obj);
> -
> - mutex_lock(>dev->struct_mutex);
> - drm_vm_open_locked(obj->dev, vma);
> - mutex_unlock(>dev->struct_mutex);
> + drm_vma_open(obj->dev, vma);
>  }
>  EXPORT_SYMBOL(drm_gem_vm_open);
>  
>  void drm_gem_vm_close(struct vm_area_struct *vma)
>  {
>   struct drm_gem_object *obj = vma->vm_private_data;
> - struct drm_device *dev = obj->dev;
>  
> - mutex_lock(>struct_mutex);
> - drm_vm_close_locked(obj->dev, vma);
> - drm_gem_object_unreference(obj);
> - mutex_unlock(>struct_mutex);
> + drm_vma_close(obj->dev, vma);
> + drm_gem_object_unreference_unlocked(obj);
>  }
>  EXPORT_SYMBOL(drm_gem_vm_close);
>  
> @@ -639,9 +633,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned 
> long obj_size,
>* (which should happen whether the vma was created by this call, or
>* by a vm_open due to mremap or partial unmap or whatever).
>*/
> - drm_gem_object_reference(obj);
> -
> - drm_vm_open_locked(dev, vma);
> + drm_gem_vm_open(vma);
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_gem_mmap_obj);
> diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
> index d4b20ce..6ea817c 100644
> --- a/drivers/gpu/drm/drm_info.c
> +++ b/drivers/gpu/drm/drm_info.c
> @@ -228,49 +228,11 @@ int drm_vma_info(struct seq_file *m, void *data)
>  {
>   struct drm_info_node *node = (struct drm_info_node *) m->private;
>   struct drm_device *dev = node->minor->dev;
> - struct drm_vma_entry *pt;
> - struct vm_area_struct *vma;
> -#if

[PATCH] gma500: Fix SDVO turning off randomly

2013-08-18 Thread Daniel Vetter 
On Fri, Aug 16, 2013 at 02:23:35AM +0200, Patrik Jakobsson wrote:
> On Sun, Aug 11, 2013 at 12:00 PM, Daniel Vetter  wrote:
> > On Sat, Aug 10, 2013 at 10:12 PM, Patrik Jakobsson
> >  wrote:
> > If you take this opportunity to share a bit of code between gma500 and
> > i915 (the sdvo #defines header and maybe the sdvo i2c read/write and
> > cmd helpers) I'd be interested in such a patch. We probably need an
> > struct intel_sdvo_chip to abstract away a few things.
> > -Daniel
> 
> I'll take a look at it. Does i915 also have GMBUS and GPIOs spread out
> on different
> devices like the minnow? GPIOs seem to be accessed through LPC.

Hm, we always have the intel gmbus controller, but at different offsets.
In any case the abstraction provided by i2c_adapter should be more than
enough I hope. In drm/i915 we always use the bit-banging i2c encoder, but
such quirks are all handled within the i2c_adapter we pass to the
low-level sdvo i/o functions.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

I915 DRI_PRIME Bug

2013-08-18 Thread Daniel Vetter 
On Sat, Aug 17, 2013 at 9:46 PM, Tobias Klausmann
 wrote:
> Hello there,
> while testing my "Optimus" Notebook i saw a stack trace in my logs, maybe
> someone is interested!
> I can easily reproduce this any time. It happens when offloading a GL app,
> here Unigine Heaven 3.0 to the nvidia card. To be more exactly: When
> starting Unigine the window stays black. To get something useful i have to
> minimize and maximize the window. Exactly when maximizing the window the
> trace happens.
>
> Hope this helps anyway!

Fixed with

commit 4db9434c65e2bc838c3e24f4ae55ae517b45c3e3
Author: Daniel Vetter 
Date:   Thu Aug 8 09:10:37 2013 +0200

drm/i915: unpin backing storage in dmabuf_unmap

which is queued for -next.

Thanks, Daniel
>
> [ cut here ]
> WARNING: CPU: 7 PID: 718 at drivers/gpu/drm/i915/i915_gem.c:3967
> i915_gem_free_object+0x124/0x150 [i915]()
> Modules linked in: af_packet bnep fuse snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec ath3k btusb bluetooth
> uvcvideo snd_hwdep videobuf2_core videodev videobuf2_vmalloc
> videobuf2_memops snd_pcm snd_seq snd_timer arc4 ath9k snd_seq_device
> mac80211 ath9k_common ath9k_hw ath snd iTCO_wdt sdhci_pci sdhci mmc_core
> sr_mod sg tg3 ptp pps_core iTCO_vendor_support cfg80211 lpc_ich i2c_i801
> pcspkr joydev acer_wmi sparse_keymap rfkill cdrom soundcore snd_page_alloc
> mperf battery ac autofs4 i915 xhci_hcd processor scsi_dh_alua scsi_dh_hp_sw
> scsi_dh_emc scsi_dh_rdac scsi_dh nouveau ttm drm_kms_helper drm i2c_algo_bit
> mxm_wmi video thermal_sys wmi button
> CPU: 7 PID: 718 Comm: Xorg Not tainted 3.11.0-rc5-desktop+ #27
> Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V1.13 10/09/2012
>   0009 81568703 
>  81047f81 88021cf1ab00 88024f1d 88025e421930
>  88021c7bcd40 8802540f2da0 a0210a44 88021cf1ab00
> Call Trace:
>  [] ? dump_stack+0x50/0x80
>  [] ? warn_slowpath_common+0x81/0xb0
>  [] ? i915_gem_free_object+0x124/0x150 [i915]
>  [] ? i915_gem_dmabuf_release+0x80/0x90 [i915]
>  [] ? dma_buf_release+0x23/0x80
>  [] ? __fput+0xcd/0x230
>  [] ? task_work_run+0x97/0xd0
>  [] ? do_notify_resume+0x79/0xa0
>  [] ? int_signal+0x12/0x17
> ---[ end trace 99a0c147e69ddcd1 ]---
>
> Thanks,
> Tobias Klausmann
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



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

[Bug 68244] New: screen flickering and no sound with radeon.audio=1 when using hdmi on HD5450

2013-08-18 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68244

  Priority: medium
Bug ID: 68244
  Assignee: dri-devel at lists.freedesktop.org
   Summary: screen flickering and no sound with radeon.audio=1
when using hdmi on HD5450
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: stompdagger1 at yahoo.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 84210
  --> https://bugs.freedesktop.org/attachment.cgi?id=84210=edit
output of  avivotool regs hdmi

Hello,

I'm running gentoo with kernel 3.10.7 in a multiseat (hd5450, hd3650 and intel
hd3000) config in which I use the hd5450 gpu for xbmc with uvd and hdmi
enabled.

for some reason I don't have sound and the screen flickers from time to time.
dmesg and Xorg logs doesn't signal anything special.

I've tried to patch the kernel with Rafal Milecki's "[FIX][PATCH] drm/radeon:
fix WREG32_OR macro setting bits in a register" fix but it still didn't worked.

-- 
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/20130818/a7b4cd03/attachment-0001.html>

[PATCH -resend] drm: DRM should depend on HAS_DMA

2013-08-18 Thread Geert Uytterhoeven 
If NO_DMA=y:

drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_gem_unmap_dma_buf':
drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `drm_gem_map_dma_buf':
drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg'

Signed-off-by: Geert Uytterhoeven 
---
 drivers/gpu/drm/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index a7c54c8..626bc0c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -6,7 +6,7 @@
 #
 menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
-   depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU
+   depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
select HDMI
select I2C
select I2C_ALGOBIT
-- 
1.7.9.5

[Bug 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed!

2013-08-18 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64582

Christian K?nig  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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/20130818/d5926525/attachment.html>

no hdmi sound on hd5450

2013-08-18 Thread Rafał Miłecki 
2013/8/18 StompDagger1 at yahoo.com :
> 2013/8/18 StompDagger1 at yahoo.com :
>>> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
>>> setting bits in a register" which you've commited fixes my issue?
>
>>Yes, I believe so! Sorry, I forgot to ping you about that.
>
> thats ok, I've applied the patch it doesn't seems to work, I'll verify later
> today when I'll get home.
>
> also, does screen flickering is part of this bug?

Please create a bug report, and stop using HTML in your e-mail all the time.

Provide output of "avivotool regs hdmi" in your bug report.

-- 
Rafa?

no hdmi sound on hd5450

2013-08-18 Thread Rafał Miłecki 
2013/8/18 StompDagger1 at yahoo.com :
> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
> setting bits in a register" which you've commited fixes my issue?

Yes, I believe so! Sorry, I forgot to ping you about that.

-- 
Rafa?

[Bug 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed!

2013-08-18 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64582

Laurent carlier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

-- 
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/20130818/9109856d/attachment.html>

[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

2013-08-18 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68235

--- Comment #1 from Alexandre Demers  ---
Created attachment 84186
  --> https://bugs.freedesktop.org/attachment.cgi?id=84186=edit
errors when freeze happens

Errors logged from my two last try at booting and logging with kernel
3.11.0-rc5 when dpm=1 with RADEON_va=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/20130818/f2702106/attachment.html>

[Bug 68235] New: Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

2013-08-18 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68235

  Priority: medium
Bug ID: 68235
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Display freezes after login with kernel 3.11.0-rc5 on
Cayman with dpm=1
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: alexandre.f.demers at gmail.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

I was testing kernel 3.11.0-rc5 and ended up with my display freezing after
login (2 tests: one this morning, one tonight). It always freezes when dpm=1,
but it doesn't if disabled.

The result on my screen looks like screenshot posted in bug 66963
(https://bugs.freedesktop.org/attachment.cgi?id=83470)

So I connected through ssh and I got some error in dmesg just after display
froze. I'll be attaching my errors.log file in a moment. You'll see 

VM is also enabled. I could try without it.

Also, it doesn't freezes with commit 69e0b57, I've been using and testing it
regularly for the last week and half. So I could bisect if we don't have enough
info.

-- 
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/20130818/4e859138/attachment.html>

no hdmi sound on hd5450

2013-08-18 Thread stompdagg...@yahoo.com 
2013/8/18 StompDagger1 at yahoo.com :
>> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro
>> setting bits in a register" which you've commited fixes my issue?

>Yes, I believe so! Sorry, I forgot to ping you about that.

thatsok, I've applied the patch it doesn't seems to work, I'll verify later 
today when I'll get home.

also, does screen flickering is part of this bug?
-- next part --
An HTML attachment was scrubbed...
URL:

Re: no hdmi sound on hd5450

2013-08-18 Thread stompdagg...@yahoo.com 


2013/8/13 stompdagg...@yahoo.com stompdagg...@yahoo.com:
 following the inclusion of UVD support for and a post I've seen written by
 on of the devs mentioning that the hdmi sound will likely to be activated by
 default in 3.12, I've decided to switch my cards and use the hd5450 as the
 media center card and connect it to my hdtv.

 I've enabled the sound via the relevant kernel param, I see in dmesg that it
 is enabled and when I try to play directly to the hdmi, I see that mplayer
 is playing but there is no sound coming out.

 what can be the issue?

We've a regression in radeon (in audio support), I'll try to fix it
tomorrow or the day after. That's the first thing to try.

wow, thanks for the
 quick replay, I'll patiently wait for the fix.

have a great week.

Rafal,

does the following patch: [FIX][PATCH] drm/radeon: fix WREG32_OR macro setting 
bits in a register which you've commited fixes my issue?

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

Re: no hdmi sound on hd5450

2013-08-18 Thread Rafał Miłecki 
2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
 does the following patch: [FIX][PATCH] drm/radeon: fix WREG32_OR macro
 setting bits in a register which you've commited fixes my issue?

Yes, I believe so! Sorry, I forgot to ping you about that.

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

Re: no hdmi sound on hd5450

2013-08-18 Thread stompdagg...@yahoo.com 
2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
 does the following patch: [FIX][PATCH] drm/radeon: fix WREG32_OR macro
 setting bits in a register which you've commited fixes my issue?

Yes, I believe so! Sorry, I forgot to ping you about that.

thatsok, I've applied the patch it doesn't seems to work, I'll verify later 
today when I'll get home.

also, does screen flickering is part of this bug?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: no hdmi sound on hd5450

2013-08-18 Thread Rafał Miłecki 
2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
 2013/8/18 stompdagg...@yahoo.com stompdagg...@yahoo.com:
 does the following patch: [FIX][PATCH] drm/radeon: fix WREG32_OR macro
 setting bits in a register which you've commited fixes my issue?

Yes, I believe so! Sorry, I forgot to ping you about that.

 thats ok, I've applied the patch it doesn't seems to work, I'll verify later
 today when I'll get home.

 also, does screen flickering is part of this bug?

Please create a bug report, and stop using HTML in your e-mail all the time.

Provide output of avivotool regs hdmi in your bug report.

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

[Bug 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map-l_init_called' failed!

2013-08-18 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64582

Laurent carlier lordhea...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

-- 
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 -resend] drm: DRM should depend on HAS_DMA

2013-08-18 Thread Geert Uytterhoeven 
If NO_DMA=y:

drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_gem_unmap_dma_buf':
drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `drm_gem_map_dma_buf':
drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg'

Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
 drivers/gpu/drm/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index a7c54c8..626bc0c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -6,7 +6,7 @@
 #
 menuconfig DRM
tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)
-   depends on (AGP || AGP=n)  !EMULATED_CMPXCHG  MMU
+   depends on (AGP || AGP=n)  !EMULATED_CMPXCHG  MMU  HAS_DMA
select HDMI
select I2C
select I2C_ALGOBIT
-- 
1.7.9.5

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

[Bug 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map-l_init_called' failed!

2013-08-18 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64582

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

I915 DRI_PRIME Bug

2013-08-18 Thread Tobias Klausmann 

Hello there,
while testing my Optimus Notebook i saw a stack trace in my logs, 
maybe someone is interested!
I can easily reproduce this any time. It happens when offloading a GL 
app, here Unigine Heaven 3.0 to the nvidia card. To be more exactly: 
When starting Unigine the window stays black. To get something useful i 
have to minimize and maximize the window. Exactly when maximizing the 
window the trace happens.


Hope this helps anyway!

[ cut here ]
WARNING: CPU: 7 PID: 718 at drivers/gpu/drm/i915/i915_gem.c:3967 
i915_gem_free_object+0x124/0x150 [i915]()
Modules linked in: af_packet bnep fuse snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_intel snd_hda_codec ath3k btusb bluetooth 
uvcvideo snd_hwdep videobuf2_core videodev videobuf2_vmalloc 
videobuf2_memops snd_pcm snd_seq snd_timer arc4 ath9k snd_seq_device 
mac80211 ath9k_common ath9k_hw ath snd iTCO_wdt sdhci_pci sdhci mmc_core 
sr_mod sg tg3 ptp pps_core iTCO_vendor_support cfg80211 lpc_ich i2c_i801 
pcspkr joydev acer_wmi sparse_keymap rfkill cdrom soundcore 
snd_page_alloc mperf battery ac autofs4 i915 xhci_hcd processor 
scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac scsi_dh nouveau ttm 
drm_kms_helper drm i2c_algo_bit mxm_wmi video thermal_sys wmi button

CPU: 7 PID: 718 Comm: Xorg Not tainted 3.11.0-rc5-desktop+ #27
Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V1.13 10/09/2012
  0009 81568703 
 81047f81 88021cf1ab00 88024f1d 88025e421930
 88021c7bcd40 8802540f2da0 a0210a44 88021cf1ab00
Call Trace:
 [81568703] ? dump_stack+0x50/0x80
 [81047f81] ? warn_slowpath_common+0x81/0xb0
 [a0210a44] ? i915_gem_free_object+0x124/0x150 [i915]
 [a02574d0] ? i915_gem_dmabuf_release+0x80/0x90 [i915]
 [813761c3] ? dma_buf_release+0x23/0x80
 [8113e4dd] ? __fput+0xcd/0x230
 [81063167] ? task_work_run+0x97/0xd0
 [81002ab9] ? do_notify_resume+0x79/0xa0
 [8156f92a] ? int_signal+0x12/0x17
---[ end trace 99a0c147e69ddcd1 ]---

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

Re: nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

2013-08-18 Thread Pali Rohár 
On Thursday 15 August 2013 18:21:51 Martin Peres wrote:
 On 15/08/2013 03:24, Pali Rohár wrote:
  On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
  On 14/08/2013 05:02, Pali Rohár wrote:
  On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
  On 13/08/2013 09:53, Pali Rohár wrote:
  On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
  
  wrote:
  On 13/08/2013 09:23, Pali Rohár wrote:
  On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
 ...
  
  You can check the temperature by running nvidia-settings.
  If you can't see the temperature in it, then nvidia
  doesn't support it on your card and
  I'm not sure we should :s
  
  Thanks for the vbios you sent me in private. For the
  others, the reason why he doesn't have temperature
  anymore is because his vbios lacks sensor calibration
  values.
  
  In nvidia-settings tab GPU 0 - (GeForce 6600 GT) --
  Thermal Settings is:
  
  Thermal Sensor Information:
  ID: 0
  Target: GPU
  Provider: GPU Internal
  Temperature: 70 C (now)
  
  I looked in Windows program SpeedFan. It found Nvidia PCI
  card and reported GPU Temp about 68-70 C. So it looks
  like both nvidia driver and windows SpeedFan program
  reading same values.
  
  Great, I'll cook you a patch in a bit and you'll see what
  the temperature is like. It won't be perfectly accurate
  but there is some kind of default for nvidia cards of this
  generation.
  
  Ok, send me patch and I can try it if it will work and
  report similar values as windows or nvidia driver.
  
  Sorry for the late answer.
  
  Please test this patch. Be aware that temperature with nouveau
  will be higher than with the blob.
  I only want to see if nouveau reports a temperature.
  
  The only way to be sure if the values are good-enough would be
  to use the blob and run:
  nvapeek 0x15b0
  Please send me the result along with the temperature reported
  by nvidia at the time of the peek.
  
  Martin
  
  PS: This patch has only be compile-tested, I don't have access
  to an nv4x right now.
  
  Hello,
  
  now after patch nouveau report temperature:
  
  $ sensors
  ...
  nouveau-pci-0500
  Adapter: PCI adapter
  temp1:+63.0°C  (high = +95.0°C, hyst =  +3.0°C)
  
  (crit = +145.0°C, hyst =  +2.0°C)
  (emerg = +135.0°C, hyst =  +5.0°C)
 
 Ok, that was expected ;)
 
  ...
  
  I found that nvidia binary driver has command line utility
  nvidia-smi which report same temperature as X utility nvidia-
  settings. So I will use nvidia-smi (if it is OK).
  
  And after reboot nvidia report another temperature value:
  
  $ nvidia-smi -q -d TEMPERATURE
  ...
  GPU :05:00.0
  
   Temperature
   
   Gpu : 70 C
  
  Immediately I called nvapeek command:
  
  $ nvapeek 0x15b0
  15b0: 108e
  
  So value reported by nouveau is lower than value reported by
  nvidia binary driver.
 
 As you didn't run nvapeek 15b0 when running nouveau it is hard to tell
 if it is due to
 calibration values or because the temperature was lower.
 

I run it and it always reported value 00ff (also when temperature changed).

 Could you please read the temperature + peek 15b0 when running nouveau?
 
 Anyway, it is weird because I cannot find 70°C with 0x8e as an input
 temperature and with
 the current default values :o
 

My idea is that register does not contains temperature. Both nouveau and 
nvidia driver when show different temperature it does not show different output 
from nvapeek 0x15b0.

Now I started computer with nouveau driver. Temperature is incresing, but 
nvapeek 0x15b0 is still same.

So do you really needs other tests with nvapeek 0x15b0? Is that register 
correct?

  I wait some some and started nvidia-smi and nvapeek again, here
  are results:
  
  $ nvidia-smi -q -d TEMPERATURE
  ...
  GPU :05:00.0
  
   Temperature
   
   Gpu : 67 C
  
  $ nvapeek 0x15b0
  15b0: 108e
  
  So it looks like that nvapeek returning always same value and
  does not depends on temperature... It is OK?
 
 Well, it looks like the temperature reading is very noisy!
 Could you please get the temperature + peek when the card is as hot as
 possible?
 
 There is a very effective solution to get a GPU hot, use a hair drier.
 If you could get your
 GPU to at 110°C (or less, if you feel like it is too much), that could
 help me check the formula
 and default values.
 
 PS: I attached a new version of the patch that should improve the
 temperature accuracy for
 nv43s. Could you test it and send me your kernel log?

-- 
Pali Rohár
pali.ro...@gmail.com



signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

2013-08-18 Thread Pali Rohár 
On Thursday 15 August 2013 18:23:06 Martin Peres wrote:
 On 15/08/2013 13:46, Pali Rohár wrote:
  On Tuesday 13 August 2013 11:28:01 Pali Rohár wrote:
  Hello,
  
  in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
  introduced error which cause that on my Nvidia 6600GT card
  reclocking not working anymore. There is missing assigment of
  return value from pll_calc to ret.
  
  After this patch reclocking on my card working fine again.
  Above broken commit was introduced in kernel 3.7, so consider
  backporting this patch to older kernels too.
  
  Signed-off-by: Pali Rohár pali.ro...@gmail.com
  
  diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
  b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
  100644
  --- a/drivers/gpu/drm/nouveau/nv40_pm.c
  +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
  @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
  reg, struct nvbios_pll *pll, if (clk  pll-vco1.max_freq)
  
 pll-vco2.max_freq = 0;
  
  -  pclk-pll_calc(pclk, pll, clk, coef);
  +  ret = pclk-pll_calc(pclk, pll, clk, coef);
  
 if (ret == 0)
 
 return -ERANGE;
  
  Martin, can you look at another problem with my graphics card?
 
 As I told you before, I'm away from my computers, so I cannot test the
 patch. However,
 this one seems quite obvious and should be pushed. Thanks.

Yes, look at that diff of that problematic commit and you will see that ret 
here is missing. It is possible to push this patch to 3.11?

-- 
Pali Rohár
pali.ro...@gmail.com



signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

2013-08-18 Thread Martin Peres 

On 16/08/2013 03:16, Pali Rohár wrote:

On Thursday 15 August 2013 18:23:06 Martin Peres wrote:

On 15/08/2013 13:46, Pali Rohár wrote:

On Tuesday 13 August 2013 11:28:01 Pali Rohár wrote:

Hello,

in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
introduced error which cause that on my Nvidia 6600GT card
reclocking not working anymore. There is missing assigment of
return value from pll_calc to ret.

After this patch reclocking on my card working fine again.
Above broken commit was introduced in kernel 3.7, so consider
backporting this patch to older kernels too.

Signed-off-by: Pali Rohár pali.ro...@gmail.com

diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
reg, struct nvbios_pll *pll, if (clk  pll-vco1.max_freq)

pll-vco2.max_freq = 0;

-   pclk-pll_calc(pclk, pll, clk, coef);
+   ret = pclk-pll_calc(pclk, pll, clk, coef);

if (ret == 0)

return -ERANGE;

Martin, can you look at another problem with my graphics card?

As I told you before, I'm away from my computers, so I cannot test the
patch. However,
this one seems quite obvious and should be pushed. Thanks.

Yes, look at that diff of that problematic commit and you will see that ret
here is missing. It is possible to push this patch to 3.11?
Please make a proper patch (generated by git format-patch or git 
send-email) and

Ben will push it.

You add my Signed-off-by: Martin Peres martin.pe...@labri.fr

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

[PATCH] nouveau: fix reclocking on nv40

2013-08-18 Thread Pali Rohár 
In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced
error which cause that reclocking on nv40 not working anymore.
There is missing assigment of return value from pll_calc to ret.

Signed-off-by: Pali Rohár pali.ro...@gmail.com
Signed-off-by: Martin Peres martin.pe...@labri.fr
---
 drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c 
b/drivers/gpu/drm/nouveau/nv40_pm.c
index 3af5bcd..625f80d 100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct 
nvbios_pll *pll,
if (clk  pll-vco1.max_freq)
pll-vco2.max_freq = 0;
 
-   pclk-pll_calc(pclk, pll, clk, coef);
+   ret = pclk-pll_calc(pclk, pll, clk, coef);
if (ret == 0)
return -ERANGE;
 
-- 
1.7.10.4

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

Re: Moving a bug upstream per downstream request, emailing the maintainers

2013-08-18 Thread John Hupp 

On 8/16/2013 3:43 AM, Chris Wilson wrote:

On Thu, Aug 15, 2013 at 03:28:53PM -0400, John Hupp wrote:

[1.] One line summary of the problem:
Flash 11.2 content displays in shades of green and purple only, and
in a horizontally compressed space

[2.] Full description of the problem/report:
The full downstream bug report is at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455 , but
my description from there:

In my testing with the Intel driver using its default acceleration:
- Flash 11.2 works on Quantal with the 3.5 kernel
- Flash 11.2 works on Raring with the 3.5.0-17 kernel (though it
boots to a low-res desktop with a frozen pointer)
- Flash 11.2 works on Raring also with the 3.6.11-030611 or
3.7.10-030710 mainline kernels
- Flash 11.8 works on Raring with the 3.8 kernel (in Chrome)
- Flash 11.2 fails on Raring with the 3.8 kernel
- Flash 11.2 fails on Raring with the latest mainline kernel,
3.11.0-031100rc5
- Flash 11.2 fails on Saucy alpha 2 with its default kernel

It's a flash bug. They ignore the format of the Window that they
PutImage to. (Worse, they create an image of the right depth or else X
would reject the PutImage with a BadMatch and then render incorrect
pixel data into it.)
-Chris



OK, thanks for identifying the problem.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2

2013-08-18 Thread Greg KH 
On Fri, Aug 16, 2013 at 05:47:39PM -0400, Tom Stellard wrote:
 From: Tom Stellard thomas.stell...@amd.com
 
 Also add a new RADEON_INFO query to check that CP DMA packets are
 supported on the compute ring.
 
 v2:
   - Don't bump kms version, so this patch can be backported to stable
 kernels.

Why is this for a stable kernel?  What reported problem does it fix?

thanks,

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

Re: [PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2

2013-08-18 Thread Greg KH 
On Fri, Aug 16, 2013 at 05:31:39PM -0700, Tom Stellard wrote:
 On Fri, Aug 16, 2013 at 03:34:09PM -0700, Greg KH wrote:
  On Fri, Aug 16, 2013 at 05:47:39PM -0400, Tom Stellard wrote:
   From: Tom Stellard thomas.stell...@amd.com
   
   Also add a new RADEON_INFO query to check that CP DMA packets are
   supported on the compute ring.
   
   v2:
 - Don't bump kms version, so this patch can be backported to stable
   kernels.
  
  Why is this for a stable kernel?  What reported problem does it fix?
  
 
 CP DMA has been supported since the 3.8 kernel, but due to an oversight
 we forgot to teach the CS checker that the CP DMA packet was legal for
 the compute ring on Southern Islands GPUs.
 
 This patch fixes a bug where the radeon driver will incorrectly reject a legal
 CP DMA packet from user space.  I would like to have the patch
 backported to stable so that we don't have to require Mesa users to use a
 bleeding edge kernel in order to take advantage of this feature which
 is already present in the stable kernels (3.8 and newer).

Then please put that in the changelog section of the patch, otherwise
people (like me), will ask these types of things :)

thanks,

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

Re: I915 DRI_PRIME Bug

2013-08-18 Thread Daniel Vetter 
On Sat, Aug 17, 2013 at 9:46 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
 Hello there,
 while testing my Optimus Notebook i saw a stack trace in my logs, maybe
 someone is interested!
 I can easily reproduce this any time. It happens when offloading a GL app,
 here Unigine Heaven 3.0 to the nvidia card. To be more exactly: When
 starting Unigine the window stays black. To get something useful i have to
 minimize and maximize the window. Exactly when maximizing the window the
 trace happens.

 Hope this helps anyway!

Fixed with

commit 4db9434c65e2bc838c3e24f4ae55ae517b45c3e3
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Thu Aug 8 09:10:37 2013 +0200

drm/i915: unpin backing storage in dmabuf_unmap

which is queued for -next.

Thanks, Daniel

 [ cut here ]
 WARNING: CPU: 7 PID: 718 at drivers/gpu/drm/i915/i915_gem.c:3967
 i915_gem_free_object+0x124/0x150 [i915]()
 Modules linked in: af_packet bnep fuse snd_hda_codec_hdmi
 snd_hda_codec_realtek snd_hda_intel snd_hda_codec ath3k btusb bluetooth
 uvcvideo snd_hwdep videobuf2_core videodev videobuf2_vmalloc
 videobuf2_memops snd_pcm snd_seq snd_timer arc4 ath9k snd_seq_device
 mac80211 ath9k_common ath9k_hw ath snd iTCO_wdt sdhci_pci sdhci mmc_core
 sr_mod sg tg3 ptp pps_core iTCO_vendor_support cfg80211 lpc_ich i2c_i801
 pcspkr joydev acer_wmi sparse_keymap rfkill cdrom soundcore snd_page_alloc
 mperf battery ac autofs4 i915 xhci_hcd processor scsi_dh_alua scsi_dh_hp_sw
 scsi_dh_emc scsi_dh_rdac scsi_dh nouveau ttm drm_kms_helper drm i2c_algo_bit
 mxm_wmi video thermal_sys wmi button
 CPU: 7 PID: 718 Comm: Xorg Not tainted 3.11.0-rc5-desktop+ #27
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V1.13 10/09/2012
   0009 81568703 
  81047f81 88021cf1ab00 88024f1d 88025e421930
  88021c7bcd40 8802540f2da0 a0210a44 88021cf1ab00
 Call Trace:
  [81568703] ? dump_stack+0x50/0x80
  [81047f81] ? warn_slowpath_common+0x81/0xb0
  [a0210a44] ? i915_gem_free_object+0x124/0x150 [i915]
  [a02574d0] ? i915_gem_dmabuf_release+0x80/0x90 [i915]
  [813761c3] ? dma_buf_release+0x23/0x80
  [8113e4dd] ? __fput+0xcd/0x230
  [81063167] ? task_work_run+0x97/0xd0
  [81002ab9] ? do_notify_resume+0x79/0xa0
  [8156f92a] ? int_signal+0x12/0x17
 ---[ end trace 99a0c147e69ddcd1 ]---

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



-- 
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] gma500: Fix SDVO turning off randomly

2013-08-18 Thread Daniel Vetter 
On Fri, Aug 16, 2013 at 02:23:35AM +0200, Patrik Jakobsson wrote:
 On Sun, Aug 11, 2013 at 12:00 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Sat, Aug 10, 2013 at 10:12 PM, Patrik Jakobsson
  patrik.r.jakobs...@gmail.com wrote:
  If you take this opportunity to share a bit of code between gma500 and
  i915 (the sdvo #defines header and maybe the sdvo i2c read/write and
  cmd helpers) I'd be interested in such a patch. We probably need an
  struct intel_sdvo_chip to abstract away a few things.
  -Daniel
 
 I'll take a look at it. Does i915 also have GMBUS and GPIOs spread out
 on different
 devices like the minnow? GPIOs seem to be accessed through LPC.

Hm, we always have the intel gmbus controller, but at different offsets.
In any case the abstraction provided by i2c_adapter should be more than
enough I hope. In drm/i915 we always use the bit-banging i2c encoder, but
such quirks are all handled within the i2c_adapter we pass to the
low-level sdvo i/o functions.
-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 68244] New: screen flickering and no sound with radeon.audio=1 when using hdmi on HD5450

2013-08-18 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68244

  Priority: medium
Bug ID: 68244
  Assignee: dri-devel@lists.freedesktop.org
   Summary: screen flickering and no sound with radeon.audio=1
when using hdmi on HD5450
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: stompdagg...@yahoo.com
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 84210
  -- https://bugs.freedesktop.org/attachment.cgi?id=84210action=edit
output of  avivotool regs hdmi

Hello,

I'm running gentoo with kernel 3.10.7 in a multiseat (hd5450, hd3650 and intel
hd3000) config in which I use the hd5450 gpu for xbmc with uvd and hdmi
enabled.

for some reason I don't have sound and the screen flickers from time to time.
dmesg and Xorg logs doesn't signal anything special.

I've tried to patch the kernel with Rafal Milecki's [FIX][PATCH] drm/radeon:
fix WREG32_OR macro setting bits in a register fix but it still didn't worked.

-- 
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: Eliminate dev-vmalist

2013-08-18 Thread Daniel Vetter 
On Fri, Aug 16, 2013 at 12:24:37PM +0100, Chris Wilson wrote:
 The primary purpose of this list is for pretty printing the maps through
 debugfs/vma - per process information can be found in /proc/*/map et al.
 However, the list manipulation eats processor cycles resulting in a near
 indefinite (I got bored) stall for a leaky i-g-t/gem_concurrent_blit.
 
 There is one true user of the vmalist though. drm_vm_shm_close() uses
 the list to count the number of drm_local_map references. For this, we
 switch to using a counter inside drm_local_map.
 
 This patch kills drm_vm_open_locked and drm_vm_close_locked, and
 redirects the one user outside of the core (exoynos) to use the now
 semantically equivalent drm_gem_vm_open.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Dave Airlie airl...@redhat.com
 Cc: Rob Clark robdcl...@gmail.com
 Cc: Inki Dae inki@samsung.com

Ok, I've accidentally read through the exynos mmap code and now I'm
desparately trying to get a bunch of forks out of my eyes again.

So just one question: Why is this stuff not using the gem mmap offset
stuff, but still tries to reinvent the useless parts of that wheel (like
drm_vm_open/close)?

/rant

Cheers, Daniel

 ---
  drivers/gpu/drm/drm_bufs.c  |  1 +
  drivers/gpu/drm/drm_drv.c   |  8 -
  drivers/gpu/drm/drm_gem.c   | 16 +++--
  drivers/gpu/drm/drm_info.c  | 38 -
  drivers/gpu/drm/drm_stub.c  |  1 -
  drivers/gpu/drm/drm_vm.c| 58 
 +++--
  drivers/gpu/drm/exynos/exynos_drm_gem.c |  9 +
  include/drm/drmP.h  |  7 ++--
  8 files changed, 20 insertions(+), 118 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
 index bef4abf..b0aa2eb 100644
 --- a/drivers/gpu/drm/drm_bufs.c
 +++ b/drivers/gpu/drm/drm_bufs.c
 @@ -152,6 +152,7 @@ static int drm_addmap_core(struct drm_device * dev, 
 resource_size_t offset,
   map-size = size;
   map-flags = flags;
   map-type = type;
 + map-count = 0;
  
   /* Only allow shared memory to be removable since we only keep enough
* book keeping information about shared memory to allow for removal
 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index 799..7ec9959 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -182,8 +182,6 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
   */
  int drm_lastclose(struct drm_device * dev)
  {
 - struct drm_vma_entry *vma, *vma_temp;
 -
   DRM_DEBUG(\n);
  
   if (dev-driver-lastclose)
 @@ -203,12 +201,6 @@ int drm_lastclose(struct drm_device * dev)
   dev-sg = NULL;
   }
  
 - /* Clear vma list (only built for debugging) */
 - list_for_each_entry_safe(vma, vma_temp, dev-vmalist, head) {
 - list_del(vma-head);
 - kfree(vma);
 - }
 -
   if (drm_core_check_feature(dev, DRIVER_HAVE_DMA) 
   !drm_core_check_feature(dev, DRIVER_MODESET))
   drm_dma_takedown(dev);
 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index 9ab038c..84a5834 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -573,22 +573,16 @@ void drm_gem_vm_open(struct vm_area_struct *vma)
   struct drm_gem_object *obj = vma-vm_private_data;
  
   drm_gem_object_reference(obj);
 -
 - mutex_lock(obj-dev-struct_mutex);
 - drm_vm_open_locked(obj-dev, vma);
 - mutex_unlock(obj-dev-struct_mutex);
 + drm_vma_open(obj-dev, vma);
  }
  EXPORT_SYMBOL(drm_gem_vm_open);
  
  void drm_gem_vm_close(struct vm_area_struct *vma)
  {
   struct drm_gem_object *obj = vma-vm_private_data;
 - struct drm_device *dev = obj-dev;
  
 - mutex_lock(dev-struct_mutex);
 - drm_vm_close_locked(obj-dev, vma);
 - drm_gem_object_unreference(obj);
 - mutex_unlock(dev-struct_mutex);
 + drm_vma_close(obj-dev, vma);
 + drm_gem_object_unreference_unlocked(obj);
  }
  EXPORT_SYMBOL(drm_gem_vm_close);
  
 @@ -639,9 +633,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned 
 long obj_size,
* (which should happen whether the vma was created by this call, or
* by a vm_open due to mremap or partial unmap or whatever).
*/
 - drm_gem_object_reference(obj);
 -
 - drm_vm_open_locked(dev, vma);
 + drm_gem_vm_open(vma);
   return 0;
  }
  EXPORT_SYMBOL(drm_gem_mmap_obj);
 diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
 index d4b20ce..6ea817c 100644
 --- a/drivers/gpu/drm/drm_info.c
 +++ b/drivers/gpu/drm/drm_info.c
 @@ -228,49 +228,11 @@ int drm_vma_info(struct seq_file *m, void *data)
  {
   struct drm_info_node *node = (struct drm_info_node *) m-private;
   struct drm_device *dev = node-minor-dev;
 - struct drm_vma_entry *pt;
 - struct vm_area_struct *vma;
 -#if defined(__i386__)
 - unsigned int pgprot;

Re: [PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration

2013-08-18 Thread Dave Airlie 
On Thu, Aug 15, 2013 at 5:43 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
 From: Russell King rmk+ker...@arm.linux.org.uk

 This patch adds tda998x specific parameters to allow it to be configured
 for different boards using it. Also, this implements rudimentary audio
 support for S/PDIF attached controllers.

 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 Tested-by: Darren Etheridge detheri...@ti.com
 ---

I've merged the series,

this one generates a warning though:
  CC [M]  drivers/gpu/drm/i2c/tda998x_drv.o
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i2c/tda998x_drv.c:
In function ‘tda998x_encoder_mode_set’:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i2c/tda998x_drv.c:637:11:
warning: ‘clksel_fs’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i2c/tda998x_drv.c:573:30:
note: ‘clksel_fs’ was declared here
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i2c/tda998x_drv.c:637:11:
warning: ‘clksel_aip’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i2c/tda998x_drv.c:573:18:
note: ‘clksel_aip’ was declared here

It doesn't seem like a real problem, since the function is unlikely to
be called any way to make that case happen.

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

Re: [PATCHv3 1/4] drm/exynos: add device tree support for rotator

2013-08-18 Thread Inki Dae 
2013년 8월 19일 월요일에 Kukjin Kimkgene@samsung.com님이 작성:
 On 08/13/13 14:12, Chanho Park wrote:

 The exynos4 platform is only dt-based since 3.10, we should convert
driver data
 and ids to dt-based parsing methods. The rotator driver has a limit
table to get
 size limit of input picture. Each SoCs has slightly different limit value
 compared with any others.
 For example, exynos4210's max_size of RGB888 is 16k x 16k. But, others
have
 8k x 8k. Another example the exynos5250 should have multiple of 2 pixel
size
 for its X/Y axis. Thus, we should keep different tables for each of them.
 This patch also includes desciptions of each nodes for the rotator and
specifies
 a example how to bind it.

 Signed-off-by: Chanho Parkchanho61.p...@samsung.com
 Cc: Inki Daeinki@samsung.com

 Inki, do you OK on this? If so, let me take this whole series into the
samsung tree.

Signed-off-by: Inki Dae inki@samsung.com

Thanks,
Inki Dae


 Thanks,
 Kukjin

 Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
 ---
   .../devicetree/bindings/gpu/samsung-rotator.txt|   27 +
   drivers/gpu/drm/exynos/exynos_drm_rotator.c|  108
+++-
   2 files changed, 107 insertions(+), 28 deletions(-)
   create mode 100644
Documentation/devicetree/bindings/gpu/samsung-rotator.txt

 diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
 new file mode 100644
 index 000..82cd1ed
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
 @@ -0,0 +1,27 @@
 +* Samsung Image Rotator
 +
 +Required properties:
 +  - compatible : value should be one of the following:
 +   (a) samsung,exynos4210-rotator for Rotator IP in Exynos4210
 +   (b) samsung,exynos4212-rotator for Rotator IP in
Exynos4212/4412
 +   (c) samsung,exynos5250-rotator for Rotator IP in Exynos5250
 +
 +  - reg : Physical base address of the IP registers and length of memory
 + mapped region.
 +
 +  - interrupts : Interrupt specifier for rotator interrupt, according
to format
 +specific to interrupt parent.
 +
 +  - clocks : Clock specifier for rotator clock, according to generic
clock
 +bindings. (See
Documentation/devicetree/bindings/clock/exynos*.txt)
 +
 +  - clock-names : Names of clocks. For exynos rotator, it should be
rotator.
 +
 +Example:
 +   rotator@1281 {
 +   compatible = samsung,exynos4210-rotator;
 +   reg =0x1281 0x1000;
 +   interrupts =0 83 0;
 +   clocks =clock 278;
 +   clock-names = rotator;
 +   };
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
 index 427640a..0485aea5 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
 @@ -632,21 +632,98 @@ static int rotator_ippdrv_start(struct device
*dev, enum drm_exynos_ipp_cmd cmd)
 return 0;
   }

 +static struct rot_limit_table rot_limit_tbl_4210 = {
 +   .ycbcr420_2p = {
 +   .min_w = 32,
 +   .min_h = 32,
 +   .max_w = SZ_64K,
 +   .max_h = SZ_64K,
 +   .align = 3,
 +   },
 +   .rgb888 = {
 +   .min_w = 8,
 +   .min_h = 8,
 +   .max_w = SZ_16K,
 +   .max_h = SZ_16K,
 +   .align = 2,
 +   },
 +};
 +
 +static struct rot_limit_table rot_limit_tbl_4x12 = {
 +   .ycbcr420_2p = {
 +   .min_w = 32,
 +   .min_h = 32,
 +   .max_w = SZ_32K,
 +   .max_h = SZ_32K,
 +   .align = 3,
 +   },
 +   .rgb888 = {
 +   .min_w = 8,
 +   .min_h = 8,
 +   .max_w = SZ_8K,
 +   .max_h = SZ_8K,
 +   .align = 2,
 +   },
 +};
 +
 +static struct rot_limit_table rot_limit_tbl_5250 = {
 +   .ycbcr420_2p = {
 +   .min_w = 32,
 +   .min_h = 32,
 +   .max_w = SZ_32K,
 +   .max_h = SZ_32K,
 +   .align = 3,
 +   },
 +   .rgb888 = {
 +   .min_w = 8,
 +   .min_h = 8,
 +   .max_w = SZ_8K,
 +   .max_h = SZ_8K,
 +   .align = 1,
 +   },
 +};
 +
 +static const struct of_device_id exynos_rotator_match[] = {
 +   {
 +   .compatible = samsung,exynos4210-rotator,
 +   .data =rot_limit_tbl_4210,
 +   },
 +   {
 +   .compatible = samsung,exynos4212-rotator,
 +   .data =rot_limit_tbl_4x12,
 +   },
 +   {
 +   .compatible = samsung,exynos5250-rotator,
 +   .data =rot_limit_tbl_5250,
 +   },
 +   {},
 +};
 +
   static int rotator_probe(struct platform_device *pdev)
   {
 struct device *dev =pdev-dev;
 struct rot_context *rot;
 struct exynos_drm_ippdrv *ippdrv;
 +

[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

2013-08-18 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

queryv...@gmail.com changed:

   What|Removed |Added

 CC||queryv...@gmail.com

--- Comment #33 from queryv...@gmail.com ---
I'm also experiencing this issue with my 6870. I decided to attach a second
monitor yesterday and immediately noticed that my card went from idling at
around 45°C to a steady 55°C.

'watch cat /sys/kernel/debug/dri/0/radeon_pm_info' shows that I'm stuck at
power level 2, even when running a game like Xonotic. I get the same 'bash:
echo: write error: Invalid argument' error if I try to force a performance
level as well.

Using 3.11-rc5 + the drm-next-3.12-wip branch.

-- 
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 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem

2013-08-18 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60674

Dave systemdki...@yopmail.com changed:

   What|Removed |Added

 CC||systemdki...@yopmail.com

--- Comment #12 from Dave systemdki...@yopmail.com ---
We encountered such visual issues on a different, older GPU:

RV350 (Shivah) on AGP bus
xorg-xserver 1.14.2-2
xf86-video-ati 1.7.2.0-1
qt4 4.8.5-1
kernel 3.10.6-2
32-bit Arch Linux, up-to-date

Similar screenshots and reports,
https://bbs.archlinux.org/viewtopic.php?id=167248

For us, switching the xorg.conf AccelMethod from EXA to glamor caused the mess.
No problems occur under EXA.

GTK+ and XUL apps suffer far more than Qt. KDE desktop and apps render OK. We
get a random dead blank screen on likely hardware register or interrupt issues,
but only in glamor mode. Boxes run stable EXA indefinitely.

-- 
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 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

2013-08-18 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #34 from queryv...@gmail.com ---
Created attachment 107241
  -- https://bugzilla.kernel.org/attachment.cgi?id=107241action=edit
full dmesg (HD6870)

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