[Bug 83319] New: [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730

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

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

  Priority: medium
Bug ID: 83319
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) -
RV730
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: Dieter at nuetzel-hh.de
  Hardware: x86 (IA32)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 105518
  --> https://bugs.freedesktop.org/attachment.cgi?id=105518=edit
dmesg-3.16.1-7.g90bc0f1-desktop-gsraytrace.log

GL_RENDERER   = Gallium 0.4 on AMD RV730
GL_VERSION= 3.0 Mesa 10.4.0-devel (git-5598458)
GL_VENDOR = X.Org

GShader thing?

mesa-demos/glsl> ./vsraytrace 
ATTENTION: default value of option vblank_mode overridden by environment.
GL_RENDERER = Gallium 0.4 on AMD RV730
47.590482 FPS (238 frames in 5.001000 seconds)
62.325210 FPS (312 frames in 5.006000 seconds)
65.407555 FPS (329 frames in 5.03 seconds)

mesa-demos/glsl> ./fsraytrace 
ATTENTION: default value of option vblank_mode overridden by environment.
GL_RENDERER = Gallium 0.4 on AMD RV730
503.00 FPS (2515 frames in 5.00 seconds)
626.80 FPS (3134 frames in 5.00 seconds)
577.60 FPS (2888 frames in 5.00 seconds)

mesa-demos/glsl> ./gsraytrace 
ATTENTION: default value of option vblank_mode overridden by environment.
GL_RENDERER = Gallium 0.4 on AMD RV730

ESC = exit demo
left mouse + drag   = rotate camera

0.044960 FPS (1 frames in 22.242000 seconds)
0.047201 FPS (1 frames in 21.186000 seconds)

ESC / CNTRL+C (several/hundred times)

=> 2 times switching between blank (black) full screen (console) and desktop
(KDE 4.13.3) before the system comes back

NO, no LLVM this time... (Michel?)

Maybe related: bug 76394

-- 
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/20140831/b0a6fd64/attachment-0001.html>

[Bug 83611] Kernel NULL pointer dereference when using tlp on a laptop with AMD video card.

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

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

--- Comment #3 from yshuiv7 at gmail.com ---
Maybe we could acquire the pm mutex while setting up crtcs in
radeon_modeset_init?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 76789] [radeonsi] si_descriptors.c requires -std=gnu99 or -fms-extensions

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

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

Jonathan Gray  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Gray  ---
This appears to have been fixed a while ago, though I note the fix is not
currently on the 10.2 branch.

commit 74388dd24bc7fdb9e62ec18096163f5426e03fbf
Author: Adam Jackson 
Date:   Tue Apr 22 12:46:08 2014 -0400

radeonsi: Don't use anonymous struct trick in atom tracking

I'm somewhat impressed that current gccs will let you do this, but
sufficiently old ones (including 4.4.7 in RHEL6) won't.

Reviewed-by: Marek Olk 
Signed-off-by: Adam Jackson 

 src/gallium/drivers/radeonsi/si_descriptors.c | 6 +++---
 src/gallium/drivers/radeonsi/si_hw_context.c  | 2 +-
 src/gallium/drivers/radeonsi/si_pipe.c| 6 +++---
 src/gallium/drivers/radeonsi/si_pipe.h| 2 +-
 src/gallium/drivers/radeonsi/si_state.c   | 2 +-
 src/gallium/drivers/radeonsi/si_state_draw.c  | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)

-- 
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/20140831/a59aed4c/attachment.html>

[Bug 83611] Kernel NULL pointer dereference when using tlp on a laptop with AMD video card.

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

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

--- Comment #2 from yshuiv7 at gmail.com ---
Created attachment 148941
  --> https://bugzilla.kernel.org/attachment.cgi?id=148941=edit
tlp udev rule file

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83611] Kernel NULL pointer dereference when using tlp on a laptop with AMD video card.

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

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

--- Comment #1 from yshuiv7 at gmail.com ---
I think there is probably a race condition here. When tlp is automatically
started via udev with the rule file attached (40-tlp.rules), this bug occurs.
But when I remove the rule file, and start tlp after the system is fully
booted, everything is fine.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 79696] 10.2.x GPU stall & Xorg crash while using Geeqie

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

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

--- Comment #20 from Clemens Fruhwirth  ---
I would appreciate an update to this bug as I am stuck on 10.1.4.

-- 
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/20140831/55f36e96/attachment.html>

[Bug 83611] New: Kernel NULL pointer dereference when using tlp on a laptop with AMD video card.

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

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

Bug ID: 83611
   Summary: Kernel NULL pointer dereference when using tlp on a
laptop with AMD video card.
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16.1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: yshuiv7 at gmail.com
Regression: No

relevant dmesg:

ACPI: \_SB_.PCI0.LPCB.EC0_.ECRD: 1 arguments were passed to a non-method ACPI
object (RegionField) (20140424/nsarguments-230)
ACPI: \_SB_.PCI0.LPCB.EC0_.ECRD: 1 arguments were passed to a non-method ACPI
object (RegionField) (20140424/nsarguments-230)
input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14
ATOM BIOS: Lenovo/Compal
[drm] GPU not posted. posting now...
radeon :05:00.0: VRAM: 2048M 0x - 0x7FFF (2048M
used)
radeon :05:00.0: GTT: 1024M 0x8000 - 0xBFFF
[drm] Detected VRAM RAM=2048M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 4049972 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 2048M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading VERDE Microcode
[drm] radeon/VERDE_mc2.bin: 31500 bytes
[drm] Internal thermal controller without fan control
[drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0
[drm] radeon: dpm initialized
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0
[drm] PCIE gen 2 link speeds already enabled
[drm] PCIE GART of 1024M enabled (table at 0x00276000).
radeon :05:00.0: WB enabled
radeon :05:00.0: fence driver on ring 0 use gpu addr 0x8c00 and
cpu addr 0x88024d04fc00
radeon :05:00.0: fence driver on ring 1 use gpu addr 0x8c04 and
cpu addr 0x88024d04fc04
radeon :05:00.0: fence driver on ring 2 use gpu addr 0x8c08 and
cpu addr 0x88024d04fc08
radeon :05:00.0: fence driver on ring 3 use gpu addr 0x8c0c and
cpu addr 0x88024d04fc0c
radeon :05:00.0: fence driver on ring 4 use gpu addr 0x8c10 and
cpu addr 0x88024d04fc10
radeon :05:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and
cpu addr 0xc900121b5a18
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
radeon :05:00.0: irq 68 for MSI/MSI-X
radeon :05:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
32]: wlp4s0: soliciting a DHCP lease
BUG: unable to handle kernel NULL pointer dereference at 0080
IP: [] dce6_bandwidth_update+0x4b/0x110 [radeon]
PGD 252511067 PUD 24ee99067 PMD 0 
Oops:  [#1] PREEMPT SMP 
Modules linked in: ses enclosure ecb btusb uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_core v4l2_common uas bluetooth videodev
thinkpad_acpi nvram media usb_storage 6lowpan_iphc crc16 intel_rapl joydev
mousedev x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul
glue_helper ablk_helper cryptd arc4 iTCO_wdt iwlmvm mac80211
iTCO_vendor_support i915(+) radeon(+) mac_hid microcode serio_raw psmouse evdev
pcspkr ttm iwlwifi dw_dmac dw_dmac_core drm_kms_helper thermal battery cfg80211
gpio_lynxpoint drm ideapad_laptop r8169 rtsx_pci_ms memstick sparse_keymap
rfkill mii fan 8250_dw video mei_me mei ac i2c_hid spi_pxa2xx_platform
i2c_designware_platform intel_gtt i2c_i801 i2c_algo_bit i2c_designware_core
 i2c_core button shpchp lpc_ich snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer snd
soundcore processor coretemp hwmon acpi_call(O) btrfs xor hid_generic usbhid
hid raid6_pq sd_mod crc_t10dif crct10dif_common rtsx_pci_sdmmc atkbd libps2
ahci libahci crc32c_intel libata scsi_mod ehci_pci ehci_hcd xhci_hcd usbcore
rtsx_pci usb_common i8042 serio sdhci_acpi sdhci led_class mmc_core
CPU: 0 PID: 407 Comm: tlp Tainted: G   O  3.16.1-1-ARCH #1
Hardware name: LENOVO 20347/Lenovo Y40-70, BIOS 99CN24WW(V1.07) 07/28/2014
task: 88024d1028c0 ti: 88024ecb8000 task.ti: 88024ecb8000
RIP: 0010:[]  []
dce6_bandwidth_update+0x4b/0x110 [radeon]
RSP: 0018:88024ecbbdf0  EFLAGS: 00010246
RAX: 88024ef68498 RBX: 88024ef68000 RCX: 88024ef684c8
RDX:  RSI: 04b0 RDI: 88024ef68000
RBP: 88024ecbbe20 R08: 88024d2699e6 R09: 04b0
R10: 0005 R11: ea00026a1500 R12: 88024ef68000
R13:  R14: 88024ef69738 R15: 88024ef69048
FS:  

[Bug 76490] Hang during boot when DPM is on (R9 270X)

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

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

--- Comment #23 from dex+fdobugzilla at dragonslave.de ---
I did some checks using the old profile based aproach for PM and switched
between the states.

Following are the data from /sys/kernel/debug/dri/0/radeon_pm_info when
switching via echo X  >  /sys/class/drm/card0/device/power_profile 

Default:
=
default engine clock: 108 kHz
current engine clock: 149990 kHz
default memory clock: 140 kHz
current memory clock: 149990 kHz
voltage: 1206 mV
PCIE lanes: 8

Low:
=
default engine clock: 108 kHz
current engine clock: 20 kHz
default memory clock: 140 kHz
current memory clock: 149990 kHz
voltage: 875 mV
PCIE lanes: 8

Mid:
=
default engine clock: 108 kHz
current engine clock: 20 kHz
default memory clock: 140 kHz
current memory clock: 149990 kHz
voltage: 875 mV
PCIE lanes: 8

High:
=
default engine clock: 108 kHz
current engine clock: 108 kHz
default memory clock: 140 kHz
current memory clock: 130 kHz
voltage: 1206 mV
PCIE lanes: 8

The last state (high) results in immediate freeze.

-- 
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/20140831/aa825747/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #57 from Maciej  ---
Well, after a day the bug is back, so xserver update didn't help.
@Cl?ment Gu?rin - I have this bug on default Chrome, turning on HW just makes
it more frequent.

-- 
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/20140831/5c1b6782/attachment.html>

[PATCH] drm/vmwgfx: select FB when DRM_VMWGFX is selected

[Randy Dunlap]

On 08/31/14 16:07, Max Filippov wrote:
> Otherwise, if FB is not selected build fails at linking step:
>   vmwgfx_fb.c:(.text+0x4098b): undefined reference to `register_framebuffer'
>   vmwgfx_fb.c:(.text+0x409c0): undefined reference to `framebuffer_release'
>   vmwgfx_fb.c:(.text+0x409f4): undefined reference to `unregister_framebuffer'
>   vmwgfx_fb.c:(.text+0x40a0e): undefined reference to `framebuffer_release'
> 
> Patch ae6445ac7475ff05 drm/vmwgfx: depends on FB
> added dependency on FB that was subsequently removed in patch
> 04381b987292256d drm: Move plane helpers into drm_kms_helper.ko
> 
> Signed-off-by: Max Filippov 
> ---
>  drivers/gpu/drm/vmwgfx/Kconfig |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
> index 67720f7..4fba548 100644
> --- a/drivers/gpu/drm/vmwgfx/Kconfig
> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_VMWGFX
>   tristate "DRM driver for VMware Virtual GPU"
>   depends on DRM && PCI
> + select FB
>   select FB_DEFERRED_IO
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
> 

My experience with these "select FB_*" things is that this symbol (DRM_VMWGFX)
should still depend on FB.  Has something changed recently to negate that?


-- 
~Randy

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #19 from Chernovsky Oleg  ---
So I'm starting to implement fan speed control, at least partially. Since I
haven't found any related docs, this work is basically reverse-engineering.

Here's my mmiotrace for BONAIRE R7 260X on 3.17-rc2 so far

MARK 560.042950
R 4 580.364585 2 0xf0808010 0x3028 0x0 0 // read GRBM STATUS
R 4 580.364590 2 0xf080d034 0x76ceed57 0x0 0// read SDMA0_STATUS_REG
R 4 580.364593 2 0xf080d834 0x46cee557 0x0 0// read
R_00D834_DMA_STATUS_REG
R 4 580.364629 2 0xf0808010 0x3028 0x0 0  // read GRBM STATUS
R 4 580.364632 2 0xf080d034 0x76ceed57 0x0 0// read SDMA0_STATUS_REG
R 4 580.364634 2 0xf080d834 0x46cee557 0x0 0// read
R_00D834_DMA_STATUS_REG
W 4 580.364639 2 0xf0800200 0x8004 0x0 0// write to SMC_IND_INDEX_0
a 0x8004
R 4 580.364641 2 0xf0800204 0x100 0x0 0// read from SMC_IND_DATA_0
W 4 580.364643 2 0xf0800200 0x8370 0x0 0// write to SMC_IND_INDEX_0 
R 4 580.364645 2 0xf0800204 0x23730 0x0 0// read from SMC_IND_DATA_0
W 4 580.364646 2 0xf0800250 0x5c 0x0 0// write to SMC_MESSAGE_0 (!)
R 4 580.364649 2 0xf0800254 0x0 0x0 0// wait for SMC_RESP
R 4 580.364652 2 0xf0800254 0x0 0x0 0// ...
R 4 580.364655 2 0xf0800254 0x0 0x0 0// ...
R 4 580.364659 2 0xf0800254 0x1 0x0 0// got it!
R 4 580.364661 2 0xf0800254 0x1 0x0 0
W 4 580.364662 2 0xf0800200 0xc0300068 0x0 0// write to SMC_IND_INDEX_0
R 4 580.364665 2 0xf0800204 0x40252f87 0x0 0// read from SMC_IND_DATA_0
W 4 580.364666 2 0xf0800200 0xc0300064 0x0 0// write to SMC_IND_INDEX_0
R 4 580.364668 2 0xf0800204 0x181431b 0x0 0// read from SMC_IND_DATA_0
W 4 580.364670 2 0xf0800200 0xc0300064 0x0 0// write to SMC_IND_INDEX_0
W 4 580.364671 2 0xf0800204 0x1814351 0x0 0// read from SMC_IND_DATA_0
- this is the speed!
W 4 580.364672 2 0xf0800200 0xc030006c 0x0 0// write to SMC_IND_INDEX_0
R 4 580.364674 2 0xf0800204 0x50cb0c00 0x0 0// read from SMC_IND_DATA_0
W 4 580.364676 2 0xf0800200 0xc030006c 0x0 0// write to SMC_IND_INDEX_0
W 4 580.364677 2 0xf0800204 0x50cb0c00 0x0 0// read from SMC_IND_DATA_0
W 4 580.364678 2 0xf0800200 0xc030006c 0x0 0// write to SMC_IND_INDEX_0
R 4 580.364681 2 0xf0800204 0x50cb0c00 0x0 0// read from SMC_IND_DATA_0
W 4 580.364682 2 0xf0800200 0xc030006c 0x0 0// write to SMC_IND_INDEX_0
W 4 580.364683 2 0xf0800204 0x50cb0c00 0x0 0// read from SMC_IND_DATA_0

I've almost clearly understand the register keys here but I don't understand
some values that are written and read in the process.

-- 
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/20140831/c1ffa782/attachment.html>

[PATCH v4 0/2] ASoC: tda998x: add a codec to the HDMI transmitter

[Jean-Francois Moine]

The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link
from 2 different sources, I2S and S/PDIF.

This patch set adds a generic HDMI CODEC module which is used by
the TDA998x driver to update the audio constraints from the display
characteristics (EDID) and by the audio subsystem to connect the chosen
audio source to the HDMI link.

v4:
- remove all the TDA998x specific stuff from the CODEC
- move the EDID scan from the CODEC to the TDA998x
- move the CODEC to sound/soc (Mark Brown)
- update the audio_sample_rate from the EDID (Andrew Jackson)
v3: fix bad rate (Andrew Jackson)
v2: check double stream start (Mark Brown)

Jean-Francois Moine (2):
  ASoC:codecs: Add a generic HDMI audio CODEC
  drm/i2c:tda998x: Use the HDMI2  audio CODEC

 Documentation/devicetree/bindings/sound/hdmi2.txt |  32 
 drivers/gpu/drm/i2c/Kconfig   |   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c | 142 ++-
 include/sound/hdmi2.h |  24 +++
 sound/soc/codecs/Kconfig  |   3 +
 sound/soc/codecs/Makefile |   2 +
 sound/soc/codecs/hdmi2.c  | 204 ++
 7 files changed, 400 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/hdmi2.txt
 create mode 100644 include/sound/hdmi2.h
 create mode 100644 sound/soc/codecs/hdmi2.c

-- 
2.1.0

[PATCH v4 2/2] drm/i2c:tda998x: Use the HDMI2 audio CODEC

[Jean-Francois Moine]

This patch adds an audio CODEC function to the NXP TDA998x transmitter.

Signed-off-by: Jean-Francois Moine 
---
 drivers/gpu/drm/i2c/Kconfig   |   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c | 142 +++---
 2 files changed, 135 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 4d341db..fa79cd3 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -22,6 +22,7 @@ config DRM_I2C_SIL164
 config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+   select SND_SOC_HDMI2
help
  Support for NXP Semiconductors TDA998X HDMI encoders.

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d476279..5f86b4d 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -27,6 +27,9 @@
 #include 
 #include 

+#include 
+#include 
+
 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)

 struct tda998x_priv {
@@ -44,9 +47,13 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+   struct hdmi2_codec audio;
 };

 #define to_tda998x_priv(x)  ((struct tda998x_priv 
*)to_encoder_slave(x)->slave_priv)
+#define audio_priv(x) \
+   container_of(audio, struct tda998x_priv, audio)

 /* The TDA9988 series of devices use a paged register scheme.. to simplify
  * things we encode the page # in upper bits of the register #.  To read/
@@ -639,27 +646,42 @@ static void
 tda998x_configure_audio(struct tda998x_priv *priv,
struct drm_display_mode *mode, struct tda998x_encoder_params *p)
 {
-   uint8_t buf[6], clksel_aip, clksel_fs, cts_n, adiv;
+   uint8_t buf[6], clksel_aip, clksel_fs, cts_n, adiv, aclk;
uint32_t n;

/* Enable audio ports */
reg_write(priv, REG_ENA_AP, p->audio_cfg);
-   reg_write(priv, REG_ENA_ACLK, p->audio_clk_cfg);

/* Set audio input source */
-   switch (p->audio_format) {
-   case AFMT_SPDIF:
+   switch (priv->audio.source) {
+   case HDMI2_SPDIF:
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
clksel_aip = AIP_CLKSEL_AIP_SPDIF;
clksel_fs = AIP_CLKSEL_FS_FS64SPDIF;
cts_n = CTS_N_M(3) | CTS_N_K(3);
+   aclk = 0;   /* no clock */
break;

-   case AFMT_I2S:
+   case HDMI2_I2S:
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
cts_n = CTS_N_M(3) | CTS_N_K(3);
+   /* with I2S input, the CTS_N predivider depends on
+* the sample width */
+   switch (priv->audio.sample_format) {
+   case SNDRV_PCM_FORMAT_S16_LE:
+   cts_n = CTS_N_M(3) | CTS_N_K(1);
+   break;
+   case SNDRV_PCM_FORMAT_S24_LE:
+   cts_n = CTS_N_M(3) | CTS_N_K(2);
+   break;
+   default:
+   case SNDRV_PCM_FORMAT_S32_LE:
+   cts_n = CTS_N_M(3) | CTS_N_K(3);
+   break;
+   }
+   aclk = 1;   /* clock enable */
break;

default:
@@ -671,6 +693,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT |
AIP_CNTRL_0_ACR_MAN);   /* auto CTS */
reg_write(priv, REG_CTS_N, cts_n);
+   reg_write(priv, REG_ENA_ACLK, aclk);

/*
 * Audio input somehow depends on HDMI line rate which is
@@ -684,7 +707,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
adiv++; /* AUDIO_DIV_SERCLK_16 */

/* S/PDIF asks for a larger divider */
-   if (p->audio_format == AFMT_SPDIF)
+   if (priv->audio.source == HDMI2_SPDIF)
adiv++; /* AUDIO_DIV_SERCLK_16 or _32 */

reg_write(priv, REG_AUDIO_DIV, adiv);
@@ -693,7 +716,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 * This is the approximate value of N, which happens to be
 * the recommended values for non-coherent clocks.
 */
-   n = 128 * p->audio_sample_rate / 1000;
+   n = 128 * priv->audio.sample_rate / 1000;

/* Write the CTS and N values */
buf[0] = 0x44;
@@ -727,6 +750,30 @@ tda998x_configure_audio(struct tda998x_priv *priv,
tda998x_write_aif(priv, p);
 }

+/* hdmi2 codec interface */
+void tda998x_audio_start(struct hdmi2_codec *audio,
+int full)
+{
+   struct tda998x_priv *priv = audio_priv(audio);
+   struct tda998x_encoder_params *p = >params;
+
+   if 

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

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

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

--- Comment #25 from Damian Nowak  ---
Max, you need to downgrade llvm too. Just install llvm from the same date as
your mesa.

-- 
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/20140831/fef1a5f5/attachment.html>

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

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

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

--- Comment #24 from Maximilian B?hm  ---
@Damian Nowak: I would gladly use Mesa 10.1.4 but with this version I don't get
any OpenGL.

Installed:
ati-dri-10.1.4-1
lib32-mesa-10.1.4-1
lib32-mesa-libgl-10.1.4-1
mesa-10.1.4-1
mesa-demos-8.1.0-2
mesa-libgl-10.1.4-1
(all from 06-08 via Arch Rollback Machine, the last day with 10.1.4*.)
+ recent X-Server 1.16 etc.

I see this bug report as the same as the linked above "Random radeonsi
crashes". The crashes are in many shapes, in the last time my screen just
freezes but the mouse pointer still moves... Can't jump into a virtual console
nor kill X. I think I will install Catalyst again, it's really sad. Catalyst
doesn't even support Firefox' OMTC GPU accelerated scrolling so all scrolling
is stuttering on my 2560x1440 monitor (if I set it to FHD the stuttering is
acceptable but of course I want full resolution...).

-- 
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/20140831/abda0c27/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #122 from langkamp at tomblog.de ---
(In reply to comment #119)
> I was browsing while compiling and once again it crashed:
> [57534.191174] Watchdog[29216]: segfault at 0 ip 7f402637ae58 sp
> 7f40131e1810 error 6 in chrome[7f40228fa000+590d000]
> [57544.227442] Watchdog[10690]: segfault at 0 ip 7f1ffab93e58 sp
> 7f1fe79fa810 error 6 in chrome[7f1ff7113000+590d000]
> 
> Does it happen with other browsers than chrome/chromium? Do someone use
> firefox?

Yes, me. We just spoke at github. Never had x crashes or lockups.

-- 
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/20140831/80961130/attachment.html>

[Bug 80618] [r600g] XCOM Ennemy Unknown crash (RV770)

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

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

--- Comment #2 from Jan K?mmel  ---
Does XCOM still crash when you use the memory corruption workaround from
https://github.com/knecht/xcom-hacks
?
See also:
http://steamcommunity.com/app/200510/discussions/0/522730700169435716/

-- 
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/20140831/cc3edbee/attachment.html>

[PATCH v4 1/2] ASoC:codecs: Add a generic HDMI audio CODEC

[Jean-Francois Moine]

This patch adds a generic audio CODEC function to HDMI transmitters.

The CODEC is implemented as a library in a kernel module.

It handles both I2S and S/PDIF input, maintaining the audio format
and rates constraints according to the HDMI device parameters (EDID).

Audio source input switch is offered to the HDMI driver on start/stop
of audio streaming.

Signed-off-by: Jean-Francois Moine 
---
 Documentation/devicetree/bindings/sound/hdmi2.txt |  32 
 include/sound/hdmi2.h |  24 +++
 sound/soc/codecs/Kconfig  |   3 +
 sound/soc/codecs/Makefile |   2 +
 sound/soc/codecs/hdmi2.c  | 204 ++
 5 files changed, 265 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/hdmi2.txt
 create mode 100644 include/sound/hdmi2.h
 create mode 100644 sound/soc/codecs/hdmi2.c

diff --git a/Documentation/devicetree/bindings/sound/hdmi2.txt 
b/Documentation/devicetree/bindings/sound/hdmi2.txt
new file mode 100644
index 000..5776370
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/hdmi2.txt
@@ -0,0 +1,32 @@
+Device-Tree bindings for the generic HDMI2 CODEC
+
+The HDMI2 CODEC describes how the audio controller is connected to the
+HDMI transmitter.
+These definitions are included in the HDMI transmiter description.
+
+Required properties:
+
+  - audio-ports: must contain one or two HDMI transmitter dependant
+   values identifying the audio sources.
+   The source type is given by the corresponding entry in
+   the audio-port-names property.
+
+  - audio-port-names: must contain entries matching the entries in
+   the audio-ports property.
+   Each value may be "i2s" or "spdif", giving the type of
+   the associated audio port.
+
+  - #sound-dai-cells: must be set to <1> for use with the simple-card.
+   The DAI 0 is the I2S input and the DAI 1 is the S/PDIF input.
+
+Example:
+
+   hdmi: hdmi-encoder {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
+   ...
+
+   audio-ports = <0x03>, <0x04>;
+   audio-port-names = "i2s", "spdif";
+   #sound-dai-cells = <1>;
+   };
diff --git a/include/sound/hdmi2.h b/include/sound/hdmi2.h
new file mode 100644
index 000..59e4148
--- /dev/null
+++ b/include/sound/hdmi2.h
@@ -0,0 +1,24 @@
+#ifndef SND_HDMI2_H
+#define SND_HDMI2_H
+/* hdmi2 codec data */
+struct hdmi2_codec {
+   u8 ports[2];
+   u16 source; /* audio DAI = index to ports[] */
+#define HDMI2_I2S 0
+#define HDMI2_SPDIF 1
+
+   unsigned sample_rate;   /* current streaming values */
+   int sample_format;
+
+   u64 formats;/* HDMI (EDID) values */
+   unsigned max_channels;
+   struct snd_pcm_hw_constraint_list rate_constraints;
+
+   void (*start)(struct hdmi2_codec *audio, int full);
+   void (*stop)(struct hdmi2_codec *audio);
+};
+
+/* hdmi device -> hdmi2 codec */
+int hdmi2_codec_register(struct device *dev);
+void hdmi2_codec_unregister(struct device *dev);
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 8ab1547..1b8d81e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -424,6 +424,9 @@ config SND_SOC_ES8328_SPI
tristate
select SND_SOC_ES8328

+config SND_SOC_HDMI2
+   tristate
+
 config SND_SOC_ISABELLE
 tristate

diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index afba944..f59b1e6 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -53,6 +53,7 @@ snd-soc-dmic-objs := dmic.o
 snd-soc-es8328-objs := es8328.o
 snd-soc-es8328-i2c-objs := es8328-i2c.o
 snd-soc-es8328-spi-objs := es8328-spi.o
+snd-soc-hdmi2-objs := hdmi2.o
 snd-soc-isabelle-objs := isabelle.o
 snd-soc-jz4740-codec-objs := jz4740.o
 snd-soc-l3-objs := l3.o
@@ -228,6 +229,7 @@ obj-$(CONFIG_SND_SOC_DMIC)  += snd-soc-dmic.o
 obj-$(CONFIG_SND_SOC_ES8328)   += snd-soc-es8328.o
 obj-$(CONFIG_SND_SOC_ES8328_I2C)+= snd-soc-es8328-i2c.o
 obj-$(CONFIG_SND_SOC_ES8328_SPI)+= snd-soc-es8328-spi.o
+obj-$(CONFIG_SND_SOC_HDMI2)+= snd-soc-hdmi2.o
 obj-$(CONFIG_SND_SOC_ISABELLE) += snd-soc-isabelle.o
 obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o
 obj-$(CONFIG_SND_SOC_L3)   += snd-soc-l3.o
diff --git a/sound/soc/codecs/hdmi2.c b/sound/soc/codecs/hdmi2.c
new file mode 100644
index 000..8ba8ba6
--- /dev/null
+++ b/sound/soc/codecs/hdmi2.c
@@ -0,0 +1,204 @@
+/*
+ * ALSA SoC generic HDMI CODEC
+ *
+ * Copyright (C) 2014 Jean-Francois Moine
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HDMI2_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | \
+  

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #56 from Cl?ment Gu?rin  ---
I had this bug because I forced hw acceleration ON in Chromium (about:flags).
Now that everything is set as default it's stable as rock. No crash in two
days, before that it was more like 5-6 crashes a day.

Arch Linux with latest mesa-git/llvm-svn, Linux 3.16. HD 7950

-- 
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/20140831/49c09a7d/attachment.html>

PCI Radeon RV100 detection hang on sparc64

[Meelis Roos]

>  The instrumented dmesg had a couple of my local test changes and was
>  bad now that I had ROM. Reverted them exept my readb changes (instead
>  of direct dereferences of iomapped space) and redid
>  logging to be more precise.
> 
> > [drm] radeon kernel modesetting enabled.
> > PCI: Enabling device: (:02:02.0), cmd 82
> > [drm] initializing kernel modesetting (RV100 0x1002:0x5159
> > 0x1002:0x0908).
> > [drm] register mmio base: 0x1000
> > [drm] register mmio size: 32768
> > [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
> 
> 
>  This was still the unchanged kernel hanging.
> 
>  Below is a new debug log to pinpoint the hang. It seems to hang in
>  r100_gfx_get_rptr but not on first try.
> >>>
> >>>
> >>> It's most likely hanging in readl() in r100_mm_rreg() then.
> >>
> >> Yes, it is doing direct readl() there. But what does this hang mean?
> >
> > I'm not sure if the read can hang because of the GPU, or if indicates a more
> > fundamental PCI issue. Dave?
[...]
> Just a short question regarding the test setup.
> Is the video card a Sun XVR-100 or is it a vanilla ATI RV100 ?
> (If it is a vanilla RV100 there might be some kind of initialization issue
> as the video ROM is not executed during boot?)

It,s SUNW,XVR-100 with F-code ROM.

-- 
Meelis Roos (mroos at linux.ee)

[REVERT] drm/radeon: consolidate vga and dvi get_modes functions (v2)

[Benjamin Herrenschmidt]

On Sat, 2014-08-30 at 23:38 +0100, Tony Vroon wrote:
> On 30/08/14 22:56, Benjamin Herrenschmidt wrote:
> > This is weird. The above means it crashed very early, such as in
> > prom_init. I fail to see how the above commit can possibly relate
> > to that in any way...
> 
> I was dubious as well, but this git bisection process is held up as the
> one and only truth in kernel troubleshooting and I followed it to the
> letter.
> 
> > Have you verified that reverting it actually helps ?
> 
> I just tried it on a clean tree and indeed, it did not help as you expected.
> 
> So, Alex, sorry to waste your time.
> 
> Ben, other ideas?

I'll have to experiment on my own G5's next week

Cheers,
Ben.

[REVERT] drm/radeon: consolidate vga and dvi get_modes functions (v2)

[Benjamin Herrenschmidt]

On Sat, 2014-08-30 at 18:37 +0100, Tony Vroon wrote:
> Please consider reverting commit 3e22920fbd0005927bc41f71daeb056a0f4def82 by 
> title of:
> drm/radeon: consolidate vga and dvi get_modes functions (v2)
> 
> I have bisected this as the culprit for my PowerMac 7,3 crashing back into 
> OpenFirmware 
> very early at boot with an invalid memory access. The diagnostic data printed 
> is:
> %SSR0: 000.00c0
> %SSR1: 100.0083030

This is weird. The above means it crashed very early, such as in
prom_init. I fail to see how the above commit can possibly relate
to that in any way...

Have you verified that reverting it actually helps ?

Cheers,
Ben.

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #55 from Aaron B  ---
1.16* Whoops, not talking the kernel.

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

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #54 from Aaron B  ---
I'm on 3.16 and have been for a while, it definitely is still in there.

-- 
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/20140831/c866bb81/attachment.html>

[Bug 78061] KWin rendering broken on SUMO2 with enabled glamor

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

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

russianneuromancer at ya.ru changed:

   What|Removed |Added

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

--- Comment #5 from russianneuromancer at ya.ru ---
Not reproducible with X.Org Server 1.16.

-- 
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/20140831/68a28fea/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #239 from Kajzer  ---
@Shawn Starr, 

I can confirm 100% that there are no freezes anymore with auto->high and
balanced->performance.
I can tell that for sure because I was able to reproduce freeze every time.
With this there were no freezes, not once.

As for booting I didn't try your suggestions because I rarely reboot and since
I'm on these changes (no freezes) it doesn't crash on boot either.
Before those changes it used to crash on boot.
I guess one is related to other, but on that I'm not sure, really not in the
mood to reboot hundreds of times to see if its gonna hang.
If it does I might try with additional boot kernel radeon options.

btw theres no need to complicate the commands, I do it like this :

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

echo performance > /sys/class/drm/card0/device/power_dpm_state

-- 
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/20140831/fbd4eeb2/attachment.html>

[REVERT] drm/radeon: consolidate vga and dvi get_modes functions (v2)

[Tony Vroon]

On 30/08/14 22:56, Benjamin Herrenschmidt wrote:
> This is weird. The above means it crashed very early, such as in
> prom_init. I fail to see how the above commit can possibly relate
> to that in any way...

I was dubious as well, but this git bisection process is held up as the
one and only truth in kernel troubleshooting and I followed it to the
letter.

> Have you verified that reverting it actually helps ?

I just tried it on a clean tree and indeed, it did not help as you expected.

So, Alex, sorry to waste your time.

Ben, other ideas?

Regards,
-- 
Tony Vroon
Server systems manager
London Internet Exchange Ltd, Trinity Court, Trinity Street,
Peterborough, PE1 1DA
Registered in England number 3137929
E-Mail: tony at linx.net

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: