[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #58 from Aaron B --- I would also like to add, if this happens three times in quick succession (Have chrome running with an OpenGL game starting/Level loading in a game) it'll sometimes have 3 quick fail and recovers. If it does happen 3 times in a row, X dies and it throws up a few "Couldn't schedule IB" with possibly a previous "Still active IB in BO." or two to the kernel log. This is pretty rare, but about one out of every 5 crashes when I'm starting a game and Chromium/Mesa fail to start the OpenGL app will fail in such a manner, although it has also happened with just Chromium, but that is much more rare. -- 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/951fd848/attachment.html>
[Bug 83319] [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
https://bugs.freedesktop.org/show_bug.cgi?id=83319 --- Comment #1 from Dieter N?tzel --- Created attachment 105519 --> https://bugs.freedesktop.org/attachment.cgi?id=105519&action=edit Xorg.0.log-3.16.1-7.g90bc0f1-desktop -- 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/861014aa/attachment.html>
[Bug 83319] New: [r600g] GPU lockup in gsraytrace (Mesa-demo-8.2.0) - RV730
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&action=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.
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
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.
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&action=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.
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
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.
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: 7f869e36c700(000
[Bug 76490] Hang during boot when DPM is on (R9 270X)
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.
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
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
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
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
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 = &priv->params; + + if (!pri
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
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
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
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)
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
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.
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
> 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)
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)
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.
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.
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
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
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>