3.12 nvidia switcheroo regression
Hi Marcin et al,
When booting my Macbook Pro into 3.12 and powering off the Nvidia GPU, we
see nouveau try to dequeue an item which isn't present, leading to a
page-not-present fault. 3.11 works just nice.
It looks like I should add some debug, as there aren't event
enqueuing/dequeueing debug flags, or as you suggest?
http://quora.org/2013/dmesg.txt
http://quora.org/2013/config (same as the Ubuntu mainline config)
# echo OFF >/sys/kernel/debug/vgaswitcheroo/switch
hda-intel :01:00.1: Disabling via VGA-switcheroo
hda-intel :01:00.1: Cannot lock devices!
VGA switcheroo: switched nouveau off
nouveau [ DRM] suspending display...
general protection fault: [#1] SMP
Modules linked in: dm_crypt(F) parport_pc(F) snd_hda_codec_hdmi(F) ppdev(F)
lib80211_crypt_tkip(F) rfcomm(F) bnep(F) joydev(F) x86_pkg_temp_thermal(F)
intel_powerclamp(F) coretemp(F) nfsd(F) applesmc(F) kvm_intel(F)
input_polldev(F) auth_rpcgss(F) nfs_acl(F) kvm(F) crc32_pclmul(F) nfs(F)
aesni_intel(F) aes_x86_64(F) lockd(F) glue_helper(F) binfmt_misc(F) lrw(F)
gf128mul(F) ablk_helper(F) cryptd(F) wl(POF) sunrpc(F) btusb(F) fscache(F)
ax88179_178a(F) usbnet(F) snd_seq_midi(F) mii(F) uvcvideo(F)
snd_seq_midi_event(F) snd_hda_codec_cirrus(F) bluetooth(F) bcm5974(F)
videobuf2_vmalloc(F) videobuf2_memops(F) videobuf2_core(F) snd_rawmidi(F)
videodev(F) snd_hda_intel(F) snd_hda_codec(F) snd_seq(F) lib80211(F)
snd_hwdep(F) snd_seq_device(F) cfg80211(F) lpc_ich(F) snd_pcm(F) mei_me(F)
mei(F) snd_page_alloc(F) snd_timer(F) snd(F) soundcore(F) nls_iso8859_1(F)
apple_gmux(F) mac_hid(F) apple_bl(F) lp(F) parport(F) btrfs(F) xor(F)
raid6_pq(F) libcrc32c(F) hid_generic(F) hid_apple(F) usbhid(F) hid(F)
microcode(F) ahci(F) libahci(F) nouveau(F) i915(F) mxm_wmi(F) wmi(F)
i2c_algo_bit(F) ttm(F) drm_kms_helper(F) drm(F) video(F)
CPU: 2 PID: 2738 Comm: bash Tainted: PF O 3.12.2-ninja+ #3
Hardware name: Apple Inc. MacBookPro10,1/Mac-C3EC7CD22292981F, BIOS
MBP101.88Z.00EE.B02.1208081132 08/08/2012
task: 880262bb5d00 ti: 88008624e000 task.ti: 88008624e000
RIP: 0010:[] []
nouveau_event_put_locked+0x31/0x60 [nouveau]
RSP: 0018:88008624fd48 EFLAGS: 00010097
RAX: dead00200200 RBX: 88025e8bad88 RCX: 0010
RDX: dead00100100 RSI: 0011 RDI: 88025ef36400
RBP: 88008624fd50 R08: 0217 R09: 052d
R10: R11: 88008624f98e R12: 0011
R13: 0217 R14: 88025e8bad88 R15: 88025e522bf0
FS: 7f08445c1740() GS:88026f28() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f7d5452d000 CR3: 889d5000 CR4: 001407e0
Stack:
88025ef36400 88008624fd80 a0159be5 88025e8ba800
88025e9e7240 88025e522800 88025e8a2b40 88008624fdb8
a01c54be 0003 880263819000 88025e522800
Call Trace:
[] nouveau_event_put+0x35/0x50 [nouveau]
[] nouveau_display_fini+0x8e/0xc0 [nouveau]
[] nouveau_display_suspend+0x1d/0xe0 [nouveau]
[] nouveau_do_suspend+0x23d/0x2d0 [nouveau]
[] nouveau_pmops_suspend+0x46/0xc0 [nouveau]
[] nouveau_switcheroo_set_state+0x64/0xc0 [nouveau]
[] vga_switchoff.part.2+0x18/0x40
[] vga_switcheroo_debugfs_write+0x303/0x3c0
[] ? __sb_start_write+0x49/0x100
[] ? security_file_permission+0x23/0xa0
[] vfs_write+0xbd/0x1e0
[] SyS_write+0x49/0xa0
[] system_call_fastpath+0x16/0x1b
Code: 63 c6 55 48 8d 04 40 48 89 e5 53 48 89 d3 48 8d 54 c7 30 83 6a 08 01
75 0b 48 8b 47 18 48 85 c0 74 02 ff d0 48 8b 43 08 48 8b 13 <48> 89 42 08
48 89 10 48 b8 00 01 10 00 00 00 ad de 48 89 03 48
RIP [] nouveau_event_put_locked+0x31/0x60 [nouveau]
RSP
(gdb) list *(nouveau_event_put_locked+0x31)
0xbb1 is in nouveau_event_put_locked (include/linux/list.h:88).
83 * This is only for internal list manipulation where we know
84 * the prev/next entries already!
85 */
86 static inline void __list_del(struct list_head * prev, struct list_head
* next)
87 {
88 next->prev = prev;
89 prev->next = next;
90 }
Thanks,
Daniel
--
Daniel J Blueman
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/efb34700/attachment-0001.html>
drm-radeon-fix-typo-in-fetching-mpll-params.patch et.al isn't in 'drm-fixes' and 3.13-rc2
Only a reminder. Thanks, Dieter PS Hope all of you had have a nice first Sunday of Advent!
[drm/radeon] Nothing for stable is in 3.12.2, at least.
Cheers, Dieter
[GIT PULL FOR v3.14] Renesas R-Car DU patches
Hi Dave, The following changes since commit a3483353ca4e6dbeef2ed62ebed01af109b5b27a: drm: check for !kdev in drm_unplug_minor() (2013-11-15 20:49:02 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git drm/next/du for you to fetch changes up to 29ee6469e6138115420236a71c6b89bf8af1788a: drm/rcar-du: Add support for the r8a7791 DU (2013-12-02 01:27:29 +0100) Laurent Pinchart (5): drm/rcar-du: Don't cast crtc to rcrtc twice in the same function drm/rcar-du: Update plane pitch in .mode_set_base() operation drm/rcar-du: Split features and quirks drm/rcar-du: Add LVDS_LANES quirk drm/rcar-du: Add support for the r8a7791 DU Wei Yongjun (1): drm/rcar-du: fix return value check in rcar_du_lvdsenc_get_resources() drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 3 +-- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 24 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 14 -- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 28 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 21 +++-- 6 files changed, 60 insertions(+), 34 deletions(-) -- Regards, Laurent Pinchart
[PATCH] drm: shmob_drm: Check clk_prepare_enable() return value
The clk_prepare_enable() call can fail. Check it's return value. We
can't propagate it all the way to the user as the KMS operations in
which the clock is enabled return a void.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index 562f9a4..0428076 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -37,14 +37,21 @@
* Clock management
*/
-static void shmob_drm_clk_on(struct shmob_drm_device *sdev)
+static int shmob_drm_clk_on(struct shmob_drm_device *sdev)
{
- if (sdev->clock)
- clk_prepare_enable(sdev->clock);
+ int ret;
+
+ if (sdev->clock) {
+ ret = clk_prepare_enable(sdev->clock);
+ if (ret < 0)
+ return ret;
+ }
#if 0
if (sdev->meram_dev && sdev->meram_dev->pdev)
pm_runtime_get_sync(&sdev->meram_dev->pdev->dev);
#endif
+
+ return 0;
}
static void shmob_drm_clk_off(struct shmob_drm_device *sdev)
@@ -161,6 +168,7 @@ static void shmob_drm_crtc_start(struct shmob_drm_crtc
*scrtc)
struct drm_device *dev = sdev->ddev;
struct drm_plane *plane;
u32 value;
+ int ret;
if (scrtc->started)
return;
@@ -170,7 +178,9 @@ static void shmob_drm_crtc_start(struct shmob_drm_crtc
*scrtc)
return;
/* Enable clocks before accessing the hardware. */
- shmob_drm_clk_on(sdev);
+ ret = shmob_drm_clk_on(sdev);
+ if (ret < 0)
+ return;
/* Reset and enable the LCDC. */
lcdc_write(sdev, LDCNT2R, lcdc_read(sdev, LDCNT2R) | LDCNT2R_BR);
--
1.8.3.2
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit a1216444283e
("drm/i915: use the correct force_wake function at the PC8 code") from
the drm-intel-fixes tree and commit c8d9a5905e45 ("drm/i915: Add power
well arguments to force wake routines") from the drm-intel tree.
I fixed it up (I just used the drm-intel-fixes version) and can carry the
fix as necessary (no action is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/eff4e8cc/attachment.pgp>
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
On Mon, 2 Dec 2013 12:04:37 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/intel_display.c between commit a1216444283e
> ("drm/i915: use the correct force_wake function at the PC8 code") from
> the drm-intel-fixes tree and commit c8d9a5905e45 ("drm/i915: Add power
> well arguments to force wake routines") from the drm-intel tree.
>
> I fixed it up (I just used the drm-intel-fixes version) and can carry the
> fix as necessary (no action is required).
Actually, I ended up doing the below.
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 080f6fd4e839,0332d7ca892d..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -6402,7 -6583,7 +6583,7 @@@ static void hsw_restore_lcpll(struct dr
/* Make sure we're not on PC8 state before disabling PC8, otherwise
* we'll hang the machine! */
- gen6_gt_force_wake_get(dev_priv);
- dev_priv->uncore.funcs.force_wake_get(dev_priv, FORCEWAKE_ALL);
++ gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
if (val & LCPLL_POWER_DOWN_ALLOW) {
val &= ~LCPLL_POWER_DOWN_ALLOW;
@@@ -6436,7 -6617,7 +6617,7 @@@
DRM_ERROR("Switching back to LCPLL failed\n");
}
- gen6_gt_force_wake_put(dev_priv);
- dev_priv->uncore.funcs.force_wake_put(dev_priv, FORCEWAKE_ALL);
++ gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
}
void hsw_enable_pc8_work(struct work_struct *__work)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/bb4fd72c/attachment.pgp>
[Bug 69775] [r600g] RV730 AGP UVD hang (GPU lockup) with mplayer on dual DVI display with 3.12-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=69775 Alexandre Demers changed: What|Removed |Added Status|CLOSED |RESOLVED Resolution|WORKSFORME |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/1331cc66/attachment.html>
[Bug 71796] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup - Radeon HD6950
https://bugs.freedesktop.org/show_bug.cgi?id=71796 --- Comment #8 from Alexandre Demers --- You may have a look at bug 69775. It was reported as fixed by this patch: [PATCH] drm/radeon: fix typo in fetching mpll params http://lists.freedesktop.org/archives/dri-devel/2013-November/049425.html The patch has not been merged yet, but should be soon. -- 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/20131202/19eeb864/attachment.html>
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 Michel D?nzer changed: What|Removed |Added Assignee|xorg-team at lists.x.org |dri-devel at lists.freedesktop ||.org QA Contact|xorg-team at lists.x.org | Product|xorg|DRI Component|Server/General |DRM/Radeon --- Comment #1 from Michel D?nzer --- (In reply to comment #1) > When I zap xorg-server 1.15.0 RC3 with alt-ctrl-backspace > my monitor switches off and I can't switch to another virtual console. Can you still log in via ssh at that point? Please attach the Xorg.0.log file and the output of dmesg. Preferably from after the problem occurred, or if that's not possible, from before. -- 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/20131202/012ede86/attachment-0001.html>
[Bug 70687] vgaswitcheroo issues on Linux 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=70687 --- Comment #5 from Teofilis.Martisius at gmail.com --- (In reply to comment #4) > I can confirm that I have a similar issue on 3.12.0. I have Asus K73TA > laptop with AMD APU A6-3400M and a discrete card Radeon 6550M. > > VGA Switcheroo device was created successfully with 3.11, but disappeared on > 3.12.0. Error from dmesg: > ... I think the issue went away in Kernel 3.12.2. Vgaswitcheroo in /sys/kernel/debug does get created successfully and there are no "cut here" error traces in dmesg. Teo -- 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/20131202/46d54503/attachment.html>
[PATCH] drm/radeon: Fix a typo in Cayman and Evergreen registers
According to documentation, 0x8A60 should be PA_SU_LINE_STIPPLE_VALUE. Signed-off-by: Alexandre Demers --- drivers/gpu/drm/radeon/reg_srcs/cayman| 2 +- drivers/gpu/drm/radeon/reg_srcs/evergreen | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman b/drivers/gpu/drm/radeon/reg_srcs/cayman index a072fa8..ca8896d 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/cayman +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman @@ -21,7 +21,7 @@ cayman 0x9400 0x89AC VGT_COMPUTE_THREAD_GOURP_SIZE 0x89B0 VGT_HS_OFFCHIP_PARAM 0x8A14 PA_CL_ENHANCE -0x8A60 PA_SC_LINE_STIPPLE_VALUE +0x8A60 PA_SU_LINE_STIPPLE_VALUE 0x8B10 PA_SC_LINE_STIPPLE_STATE 0x8BF0 PA_SC_ENHANCE 0x8D8C SQ_DYN_GPR_CNTL_PS_FLUSH_REQ diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen b/drivers/gpu/drm/radeon/reg_srcs/evergreen index b912a37..2513cb2 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen @@ -22,7 +22,7 @@ evergreen 0x9400 0x89A4 VGT_COMPUTE_START_Z 0x89AC VGT_COMPUTE_THREAD_GOURP_SIZE 0x8A14 PA_CL_ENHANCE -0x8A60 PA_SC_LINE_STIPPLE_VALUE +0x8A60 PA_SU_LINE_STIPPLE_VALUE 0x8B10 PA_SC_LINE_STIPPLE_STATE 0x8BF0 PA_SC_ENHANCE 0x8D8C SQ_DYN_GPR_CNTL_PS_FLUSH_REQ -- 1.8.4.2
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle wrote: > On Sun, 2013-12-01 at 10:58 +0100, Daniel Vetter wrote: >> Should be fixed with >> >> commit 7c063c725987406d743cc7de7625ff224fab75de >> Author: Jesse Barnes >> Date: Tue Nov 26 09:13:41 2013 -0800 >> >> drm/i915: take mode config lock around crtc disable at suspend >> >> which is currently in drm-intel-fixes. I'll forward it early next week. > > Thanks! > > The WARNING is now gone during suspend and resume (having tested that > thoroughly - ie, twice). But I still see it at boot. Is there a related > fix for that WARNING during boot? Hm, I've never seen it during boot. Can you please boot with drm.debug=0xe and attach the dmesg with the WARN? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/radeon: Cayman - add missing registers
Added some missing registers listed in documentation. Signed-off-by: Alexandre Demers --- drivers/gpu/drm/radeon/reg_srcs/cayman | 78 +- 1 file changed, 67 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman b/drivers/gpu/drm/radeon/reg_srcs/cayman index ca8896d..596cd62 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/cayman +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman @@ -559,50 +559,106 @@ cayman 0x9400 0x00028C34 PA_SC_AA_SAMPLE_LOCS_PIXEL_X1_Y1_3 0x00028C38 PA_SC_AA_MASK_X0_Y0_X1_Y0 0x00028C3C PA_SC_AA_MASK_X0_Y1_X1_Y1 +0x00028C70 CB_COLOR0_INFO +0x00028C74 CB_COLOR0_ATTRIB 0x00028C78 CB_COLOR0_DIM -0x00028CB4 CB_COLOR1_DIM -0x00028CF0 CB_COLOR2_DIM -0x00028D2C CB_COLOR3_DIM -0x00028D68 CB_COLOR4_DIM -0x00028DA4 CB_COLOR5_DIM -0x00028DE0 CB_COLOR6_DIM -0x00028E1C CB_COLOR7_DIM -0x00028E58 CB_COLOR8_DIM -0x00028E74 CB_COLOR9_DIM -0x00028E90 CB_COLOR10_DIM -0x00028EAC CB_COLOR11_DIM +0x00028C7C CB_COLOR0_CMASK +0x00028C80 CB_COLOR0_CMAKS_SLICE +0x00028C84 CB_COLOR0_FMASK +0x00028C88 CB_COLOR0_FMASK_SLICE 0x00028C8C CB_COLOR0_CLEAR_WORD0 0x00028C90 CB_COLOR0_CLEAR_WORD1 0x00028C94 CB_COLOR0_CLEAR_WORD2 0x00028C98 CB_COLOR0_CLEAR_WORD3 +0x00028CAC CB_COLOR1_INFO +0x00028CB0 CB_COLOR1_ATTRIB +0x00028CB4 CB_COLOR1_DIM +0x00028CB8 CB_COLOR1_CMASK +0x00028CBC CB_COLOR1_CMAKS_SLICE +0x00028CC0 CB_COLOR1_FMASK +0x00028CC4 CB_COLOR1_FMASK_SLICE 0x00028CC8 CB_COLOR1_CLEAR_WORD0 0x00028CCC CB_COLOR1_CLEAR_WORD1 0x00028CD0 CB_COLOR1_CLEAR_WORD2 0x00028CD4 CB_COLOR1_CLEAR_WORD3 +0x00028CE8 CB_COLOR2_INFO +0x00028CEC CB_COLOR2_ATTRIB +0x00028CF0 CB_COLOR2_DIM +0x00028CF4 CB_COLOR2_CMASK +0x00028CF8 CB_COLOR2_CMAKS_SLICE +0x00028CFC CB_COLOR2_FMASK +0x00028D00 CB_COLOR2_FMASK_SLICE 0x00028D04 CB_COLOR2_CLEAR_WORD0 0x00028D08 CB_COLOR2_CLEAR_WORD1 0x00028D0C CB_COLOR2_CLEAR_WORD2 0x00028D10 CB_COLOR2_CLEAR_WORD3 +0x00028D24 CB_COLOR3_INFO +0x00028D28 CB_COLOR3_ATTRIB +0x00028D2C CB_COLOR3_DIM +0x00028D30 CB_COLOR3_CMASK +0x00028D34 CB_COLOR3_CMAKS_SLICE +0x00028D38 CB_COLOR3_FMASK +0x00028D3C CB_COLOR3_FMASK_SLICE 0x00028D40 CB_COLOR3_CLEAR_WORD0 0x00028D44 CB_COLOR3_CLEAR_WORD1 0x00028D48 CB_COLOR3_CLEAR_WORD2 0x00028D4C CB_COLOR3_CLEAR_WORD3 +0x00028D60 CB_COLOR4_INFO +0x00028D64 CB_COLOR4_ATTRIB +0x00028D68 CB_COLOR4_DIM +0x00028D6C CB_COLOR4_CMASK +0x00028D70 CB_COLOR4_CMAKS_SLICE +0x00028D74 CB_COLOR4_FMASK +0x00028D78 CB_COLOR4_FMASK_SLICE 0x00028D7C CB_COLOR4_CLEAR_WORD0 0x00028D80 CB_COLOR4_CLEAR_WORD1 0x00028D84 CB_COLOR4_CLEAR_WORD2 0x00028D88 CB_COLOR4_CLEAR_WORD3 +0x00028D9C CB_COLOR5_INFO +0x00028DA0 CB_COLOR5_ATTRIB +0x00028DA4 CB_COLOR5_DIM +0x00028DA8 CB_COLOR5_CMASK +0x00028DAC CB_COLOR5_CMAKS_SLICE +0x00028DB0 CB_COLOR5_FMASK +0x00028DB4 CB_COLOR5_FMASK_SLICE 0x00028DB8 CB_COLOR5_CLEAR_WORD0 0x00028DBC CB_COLOR5_CLEAR_WORD1 0x00028DC0 CB_COLOR5_CLEAR_WORD2 0x00028DC4 CB_COLOR5_CLEAR_WORD3 +0x00028DD8 CB_COLOR6_INFO +0x00028DDC CB_COLOR6_ATTRIB +0x00028DE0 CB_COLOR6_DIM +0x00028DE4 CB_COLOR6_CMASK +0x00028DE8 CB_COLOR6_CMAKS_SLICE +0x00028DEC CB_COLOR6_FMASK +0x00028DF0 CB_COLOR6_FMASK_SLICE 0x00028DF4 CB_COLOR6_CLEAR_WORD0 0x00028DF8 CB_COLOR6_CLEAR_WORD1 0x00028DFC CB_COLOR6_CLEAR_WORD2 0x00028E00 CB_COLOR6_CLEAR_WORD3 +0x00028E14 CB_COLOR7_INFO +0x00028E18 CB_COLOR7_ATTRIB +0x00028E1C CB_COLOR7_DIM +0x00028E20 CB_COLOR7_CMASK +0x00028E24 CB_COLOR7_CMAKS_SLICE +0x00028E28 CB_COLOR7_FMASK +0x00028E2C CB_COLOR7_FMASK_SLICE 0x00028E30 CB_COLOR7_CLEAR_WORD0 0x00028E34 CB_COLOR7_CLEAR_WORD1 0x00028E38 CB_COLOR7_CLEAR_WORD2 0x00028E3C CB_COLOR7_CLEAR_WORD3 +0x00028E50 CB_COLOR8_INFO +0x00028E54 CB_COLOR8_ATTRIB +0x00028E58 CB_COLOR8_DIM +0x00028E6C CB_COLOR9_INFO +0x00028E70 CB_COLOR9_ATTRIB +0x00028E74 CB_COLOR9_DIM +0x00028E88 CB_COLOR10_INFO +0x00028E8C CB_COLOR10_ATTRIB +0x00028E90 CB_COLOR10_DIM +0x00028EA4 CB_COLOR11_INFO +0x00028EA8 CB_COLOR11_ATTRIB +0x00028EAC CB_COLOR11_DIM 0x00028F80 SQ_ALU_CONST_BUFFER_SIZE_HS_0 0x00028F84 SQ_ALU_CONST_BUFFER_SIZE_HS_1 0x00028F88 SQ_ALU_CONST_BUFFER_SIZE_HS_2 -- 1.8.4.2
[PULL] drm-intel-fixes
Hi Dave, Just flushing out my pile of bugfixes, most of them for regressions/cc: stable. Nothing really serious going on. For outstanding issues we still have the S4 fun due to the hsw S4 duct-tape pending (seems like I need to switch into angry maintainer mode on that one). And there's the mode merging revert to make my g33 work again still pending for drm core. For that one I don't have any more clue (and it looks like no one else has a good idea either). And apparently the locking WARN fix in here also needs to be replicated for boot, still confirming that one though. Cheers, Daniel The following changes since commit f727b490efd0941a8d720fd07012dcb7f0740f77: drm/i915: Fix gen3 self-refresh watermarks (2013-11-20 15:52:52 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-12-02 for you to fetch changes up to 993fc6ebaf4af6fdfde08cc8649c386e483a5908: drm/i915: Pin pages whilst allocating for dma-buf vmap() (2013-11-29 15:51:20 +0100) Chris Wilson (3): drm/i915: Prefer setting PTE cache age to 3 drm/i915: Pin relocations for the duration of constructing the execbuffer drm/i915: Pin pages whilst allocating for dma-buf vmap() Jani Nikula (1): drm/i915/ddi: set sink to power down mode on dp disable Jesse Barnes (2): drm/i915: take mode config lock around crtc disable at suspend drm/i915: use crtc_htotal in watermark calculations to match fastboot v2 Paulo Zanoni (1): drm/i915: use the correct force_wake function at the PC8 code Ville Syrj?l? (5): drm/i915: Check VBT for eDP ports on VLV drm/i915: Simplify DP vs. eDP detection drm/i915: Fix pipe CSC post offset calculation drm/i915: Make the DERRMR SRM target global GTT drm/i915: MI_PREDICATE_RESULT_2 is HSW only drivers/gpu/drm/i915/i915_drv.c| 2 + drivers/gpu/drm/i915/i915_gem.c| 7 ++-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 60 -- drivers/gpu/drm/i915/i915_gem_gtt.c| 6 ++- drivers/gpu/drm/i915/i915_reg.h| 1 + drivers/gpu/drm/i915/intel_ddi.c | 5 ++- drivers/gpu/drm/i915/intel_display.c | 14 +++ drivers/gpu/drm/i915/intel_dp.c| 34 +++-- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_pm.c| 15 11 files changed, 82 insertions(+), 77 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 --- Comment #2 from octoploid --- Created attachment 90084 --> https://bugs.freedesktop.org/attachment.cgi?id=90084&action=edit Xorg log -- 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/20131202/14877ad1/attachment.html>
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 --- Comment #3 from octoploid --- Created attachment 90085 --> https://bugs.freedesktop.org/attachment.cgi?id=90085&action=edit kernel log -- 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/20131202/f2afee66/attachment-0001.html>
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 --- Comment #4 from octoploid --- (In reply to comment #1) > (In reply to comment #1) > > When I zap xorg-server 1.15.0 RC3 with alt-ctrl-backspace > > my monitor switches off and I can't switch to another virtual console. > > Can you still log in via ssh at that point? Yes. SysRq still works, too. -- 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/20131202/1177f07f/attachment.html>
[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
From: Ville Syrj?l? Some lower level things get angry if we don't have modeset locks during intel_modeset_setup_hw_state(). Actually the resume and lid_notify codepaths alreday hold the locks, but the init codepath doesn't, so fix that. Signed-off-by: Ville Syrj?l? --- Totally untested, but looks correct to me. drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 080f6fd..114db51 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11046,7 +11046,9 @@ void intel_modeset_gem_init(struct drm_device *dev) intel_setup_overlay(dev); + drm_modeset_lock_all(dev); intel_modeset_setup_hw_state(dev, false); + drm_modeset_unlock_all(dev); } void intel_modeset_cleanup(struct drm_device *dev) -- 1.8.3.2
[PATCH v3 28/32] drm/exynos: Implement drm_connector in hdmi directly
On Fri, Nov 29, 2013 at 04:58:46PM +0100, Tomasz Figa wrote: > On Tuesday 29 of October 2013 12:13:14 Sean Paul wrote: [...] > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > > b/drivers/gpu/drm/exynos/exynos_hdmi.c [...] > > @@ -811,11 +816,60 @@ static int hdmi_check_mode(struct exynos_drm_display > > *display, > > > > ret = mixer_check_mode(mode); > > if (ret) > > - return ret; > > + return MODE_BAD; > > Is there a need to define custom return values, instead of returning 0 or > a standard error code depending on whether the mode is correct? That's not a custom return value. It's one of the values in the drm_mode_status enumeration (include/drm/drm_crtc.h). They are used to transport more meaning than one of the standard error codes. In this case one could argue that MODE_BAD doesn't transport very much meaning, though, and I think it would be more useful to modify mixer_check_mode() to return a specific MODE_* value rather than one of the standard error codes. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/7d729207/attachment.pgp>
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Mon, 2013-12-02 at 08:33 +0100, Daniel Vetter wrote: > On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle wrote: > > The WARNING is now gone during suspend and resume (having tested that > > thoroughly - ie, twice). But I still see it at boot. Is there a related > > fix for that WARNING during boot? > > Hm, I've never seen it during boot. Can you please boot with > drm.debug=0xe and attach the dmesg with the WARN? Sure. This generated quite a bit of debug messages so I only copied the WARNING and the drm (related) messages immediately preceding it. Please feel free to prod again if that's insufficient. [...] <6>[2.727041] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 <7>[2.729161] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus panel <7>[2.729166] [drm:intel_lvds_init], using mode from VBT: <7>[2.729170] [drm:drm_mode_debug_printmodeline], <5>[2.729175] Modeline 0:"1024x768" 0 54160 1024 1048 1184 1344 768 771 777 806 0x8 0xa <7>[2.729464] [drm:intel_lvds_init], detected single-link lvds configuration <7>[2.729575] [drm:intel_panel_get_backlight], get backlight PWM = 13875 <7>[2.729579] [drm:intel_panel_get_max_backlight], max backlight PWM = 13875 <7>[2.729732] [drm:i915_gem_setup_global_gtt], clearing unused GTT space: [0, 000] <7>[2.733459] [drm:i915_gem_object_create_stolen], creating stolen object: size=2 <7>[2.733466] [drm:i915_pages_create_for_stolen], offset=0x0, size=131072 <7>[2.733514] [drm:i915_gem_context_init], Disabling HW Contexts; old hardware <6>[2.733649] [drm] initialized overlay support <7>[2.733654] [drm:intel_modeset_readout_hw_state], [CRTC:3] hw state readout: disabled <7>[2.733664] [drm:intel_modeset_readout_hw_state], [CRTC:4] hw state readout: enabled <7>[2.733670] [drm:intel_modeset_readout_hw_state], [ENCODER:6:LVDS-6] hw state readout: enabled, pipe B <7>[2.733674] [drm:intel_modeset_readout_hw_state], [ENCODER:10:DAC-10] hw state readout: disabled, pipe A <7>[2.733679] [drm:intel_modeset_readout_hw_state], [ENCODER:12:TV-12] hw state readout: disabled, pipe A <7>[2.733683] [drm:intel_modeset_readout_hw_state], [CONNECTOR:5:LVDS-1] hw state readout: enabled <7>[2.733687] [drm:intel_modeset_readout_hw_state], [CONNECTOR:9:VGA-1] hw state readout: disabled <7>[2.733690] [drm:intel_modeset_readout_hw_state], [CONNECTOR:11:SVIDEO-1] hw state readout: disabled <7>[2.733696] [drm:intel_dump_pipe_config], [CRTC:3][setup_hw_state] config for pipe A <7>[2.733699] [drm:intel_dump_pipe_config], cpu_transcoder: A <7>[2.733702] [drm:intel_dump_pipe_config], pipe bpp: 0, dithering: 0 <7>[2.733705] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 <7>[2.733708] [drm:intel_dump_pipe_config], dp: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 <7>[2.733712] [drm:intel_dump_pipe_config], requested mode: <7>[2.733714] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 <7>[2.733719] [drm:intel_dump_pipe_config], adjusted mode: <7>[2.733721] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 <7>[2.733726] [drm:intel_dump_crtc_timings], crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0 <7>[2.733730] [drm:intel_dump_pipe_config], port clock: 0 <7>[2.733732] [drm:intel_dump_pipe_config], pipe src size: 0x0 <7>[2.733735] [drm:intel_dump_pipe_config], gmch pfit: control: 0x, ratios: 0x, lvds border: 0x <7>[2.733738] [drm:intel_dump_pipe_config], pch pfit: pos: 0x, size: 0x, disabled <7>[2.733741] [drm:intel_dump_pipe_config], ips: 0 <7>[2.733743] [drm:intel_dump_pipe_config], double wide: 0 <7>[2.733747] [drm:intel_sanitize_crtc], [CRTC:4] wrong plane connection detected! <4>[2.733750] [ cut here ] <4>[2.733815] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector+0x42/0x50 [i915]() <5>[2.733818] Modules linked in: i915(F+) ata_generic(F) pata_acpi(F) i2c_algo_bit(F) drm_kms_helper(F) yenta_socket(F+) drm(F) tg3(F) ptp(F) pps_core(F) i2c_core(F) video(F) sunrpc(F) <5>[2.733836] CPU: 0 PID: 173 Comm: systemd-udevd Tainted: GF 3.13.0-0.rc2.1.local1.fc18.i686 #1 <5>[2.733839] Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <5>[2.733842] f54979f4 c09b66d2 f5497a24 c0449b14 c0b541a4 <5>[2.733850] 00ad f82d3524 26dc f828c6a2 f828c6a2 f5561e00 00061200 <5>[2.733856] f56a4000 f5497a34 c0449b52 0009 f5497a40 f828c6a2 f563d000 <5>[2.733863] Call Trace: <5>[2.733875] [] dump_stack+0x41/0x52 <5>[2.733882] [] warn_slowpath_common+0x84/0xa0 <5>[2.733919] [] ? intel_get_pipe_from_connector+0x42/0x50 [i915
[PATCH v3 28/32] drm/exynos: Implement drm_connector in hdmi directly
On Monday 02 of December 2013 10:46:37 Thierry Reding wrote: > On Fri, Nov 29, 2013 at 04:58:46PM +0100, Tomasz Figa wrote: > > On Tuesday 29 of October 2013 12:13:14 Sean Paul wrote: > [...] > > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > > > b/drivers/gpu/drm/exynos/exynos_hdmi.c > [...] > > > @@ -811,11 +816,60 @@ static int hdmi_check_mode(struct > > > exynos_drm_display *display, > > > > > > ret = mixer_check_mode(mode); > > > if (ret) > > > - return ret; > > > + return MODE_BAD; > > > > Is there a need to define custom return values, instead of returning 0 or > > a standard error code depending on whether the mode is correct? > > That's not a custom return value. It's one of the values in the > drm_mode_status enumeration (include/drm/drm_crtc.h). They are used to > transport more meaning than one of the standard error codes. OK. Strange thing is that LXR doesn't index them. > In this > case one could argue that MODE_BAD doesn't transport very much meaning, > though, and I think it would be more useful to modify mixer_check_mode() > to return a specific MODE_* value rather than one of the standard error > codes. Right. Best regards, Tomasz
[Bug 71864] [RS690] GPU Lockup CP Stall and Resulting Kernel Oops (Kernel 3.2.0)
https://bugs.freedesktop.org/show_bug.cgi?id=71864 --- Comment #18 from reimth at gmail.com --- (In reply to comment #17) > I would suggest trying newer versions of the userspace gfx stack (mesa, > xf86-video-ati). GPU resets are usually caused by bad command combinations > sent by the userspace drivers. Status with following kernel and userspace stack versions: Kernel: 3.8.0 Mesa: 9.1.7 xf86-video-ati: compiled for 1.13.3, module version = 7.1.0 The system is more stable again. We had only one kernel freeze and this was preceeded by a failed GPU reset. One root cause of the previously increased instability seems to be that the second X server runs wine-1.4. Wine requires also the 32-bit i386 userspace drivers, which had to be manually upgraded to the above mentioned latest versions. Is the wine required combined use of 32-bit (i386) and 64-bit (amd64) userspace drivers on an AMD platform supposed to be valid and stable approach? -- 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/20131202/ed3982bc/attachment-0001.html>
[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
On Mon, 2013-12-02 at 11:08 +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> Some lower level things get angry if we don't have modeset locks
> during intel_modeset_setup_hw_state(). Actually the resume and
> lid_notify codepaths alreday hold the locks, but the init codepath
> doesn't, so fix that.
>
> Signed-off-by: Ville Syrj?l?
> ---
> Totally untested, but looks correct to me.
I assume I need to test this, on top of 7c063c725987 ("drm/i915: take
mode config lock around crtc disable at suspend"), to see if this makes
the WARNING that I currently see at boot go away?
Paul Bolle
> drivers/gpu/drm/i915/intel_display.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 080f6fd..114db51 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11046,7 +11046,9 @@ void intel_modeset_gem_init(struct drm_device *dev)
>
> intel_setup_overlay(dev);
>
> + drm_modeset_lock_all(dev);
> intel_modeset_setup_hw_state(dev, false);
> + drm_modeset_unlock_all(dev);
> }
>
> void intel_modeset_cleanup(struct drm_device *dev)
[Bug 71138] flashlight bug in L4D2
https://bugs.freedesktop.org/show_bug.cgi?id=71138
--- Comment #5 from Benjamin Bellec ---
I'm experiencing the same issue, with the same hardware.
I tried different graphics settings. The corruption exists only when the
"shader detail" ("D?tails de l'image" in french) is set to "low" or "mid". When
set on "high" or "very high", there is no problem. All other settings doesn't
change anything.
Note that when the character is in the sunlight, then the flashlight have less
incidence (less blinking textures).
Here is a video showing the bug (199.6 MiB):
http://ubuntuone.com/12CfgEkAOwaBvgXKQILIxR
I have also a Radeon HD 5870 (AMD CYPRESS), and there is no such problem with
this card (same software config).
---
System information:
Radeon HD 4850 (RV770)
Fedora 19 x86-64
Linux 3.11.9-200.fc19.x86_64
libdrm 2.4.49-1.i686
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.1.0-devel
(git-5455c81)
OpenGL core profile shading language version string: 1.40
--
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/20131202/56847ad4/attachment.html>
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 --- Comment #5 from Michel D?nzer --- Looks like the X server may not shut down cleanly. Is there something interesting in its stderr output? You may find it in the display manager log file(s). (In reply to comment #4) > > Can you still log in via ssh at that point? > > Yes. What happens if you try starting X again or switching VTs using chvt from ssh? -- 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/20131202/bc7a6d1d/attachment.html>
[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support
bject, and in that case the drm_bridge_funcs.mode_set()
> > would be the equivalent of this.
> I think mode setting is common for most DSI-hosts, at least
> for all having video mode.
I agree, but I don't think we need to make it an integral part of the
DSI peripheral or DSI host structures. Most of the drivers for a DSI
host or DSI peripheral will have some subsystem specific way to deal
with that anyway, so I don't think we're doing us a favour by adding an
extra layer here.
> >>>> +#define mipi_dsi_dcs_write_seq(dev, channel, seq...) \
> >>>> +({\
> >>>> +const u8 d[] = { seq };\
> >>>> +BUILD_BUG_ON_MSG(ARRAY_SIZE(d) > 64, "DCS sequence too long for
> >>>> stack");\
> >>>> +mipi_dsi_dcs_write(dev, channel, d, ARRAY_SIZE(d));\
> >>>> +})
> >>>> +
> >>>> +#define mipi_dsi_dcs_write_static_seq(dev, channel, seq...) \
> >>>> +({\
> >>>> +static const u8 d[] = { seq };\
> >>>> +mipi_dsi_dcs_write(dev, channel, d, ARRAY_SIZE(d));\
> >>>> +})
> >>> Can we drop these please? I'd rather have drivers construct buffers
> >>> explicitly than use these.
> >> I like those two. It removes lots of boiler-plate code. Please compare
> >> implementations
> >> of s6e8aa panel drivers without it [1] and with it [2], look for
> >> calls to dsi_dcs_write.
> >>
> >> [1]
> >> http://lists.freedesktop.org/archives/dri-devel/2013-January/034212.html
> >> [2] https://linuxtv.org/patch/20215/
> > Actually I much prefer the first version that doesn't use the macros.
> > It's much more explicit and therefore obvious what's happening. I can
> > understand that these might be convenient for some use-cases, but I
> > don't think that warrants them being part of the core. You can always
> > add them in specific drivers if you really want to. Once more people
> > start using this infrastructure and these macros start to appear as a
> > common pattern we can still move them into the core header to avoid the
> > duplication.
> Hmm,
> grep -rP '--include=*.h' '\.\.\.\)'
> shows lots of similar macros :)
The large majority of those are wrappers around printk(), so they have a
completely different purpose.
> Anyway I can move it to driver :)
I agree that it can be useful to have shortcuts to common operations,
and I'm open to move these back into core headers if indeed they prove
to be the best way to do that.
> > Anyway, it seems like there are still a few things that need discussion,
> > so in an attempt to push this forward perhaps a good idea would be to
> > drop all the contentious parts and focus on getting the basic infra-
> > structure to work. The crucial parts will be to have a standard way of
> > instantiating devices from device tree. As far as I can tell, the only
> > disagreement we have on that matter is whether or not to name the
> > devices according to their bus number. I hope I've been able to convince
> > you above.
> >
> > Do you think it would be possible to remove the .set_stream() and
> > .transfer() operations (and related defines) for now? I'm not asking for
> > you to drop them, just to move them to a separate patch so that the
> > basic infrastructure patch can be merged early and we can get started to
> > port drivers to use this as soon as possible.
> I would like to have DSI bus and working DSI host and panel, so
> I would like to replace set_stream at least with set_mode.
>
> I hope to send next iteration at the beginning of the next week.
Okay, I think I could live with those if they are modified as discussed
so far. But I really think we should get rid of the struct videomode in
struct mipi_dsi_device and encode the virtual channels in device names.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/c7d919f6/attachment.pgp>
[PATCH] drm/radeon: Cayman - add missing registers
The registers aren't listed because they are not safe and they need to be checked by the CS checker. NAK. Marek On Mon, Dec 2, 2013 at 8:34 AM, Alexandre Demers wrote: > Added some missing registers listed in documentation. > > Signed-off-by: Alexandre Demers > --- > drivers/gpu/drm/radeon/reg_srcs/cayman | 78 > +- > 1 file changed, 67 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman > b/drivers/gpu/drm/radeon/reg_srcs/cayman > index ca8896d..596cd62 100644 > --- a/drivers/gpu/drm/radeon/reg_srcs/cayman > +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman > @@ -559,50 +559,106 @@ cayman 0x9400 > 0x00028C34 PA_SC_AA_SAMPLE_LOCS_PIXEL_X1_Y1_3 > 0x00028C38 PA_SC_AA_MASK_X0_Y0_X1_Y0 > 0x00028C3C PA_SC_AA_MASK_X0_Y1_X1_Y1 > +0x00028C70 CB_COLOR0_INFO > +0x00028C74 CB_COLOR0_ATTRIB > 0x00028C78 CB_COLOR0_DIM > -0x00028CB4 CB_COLOR1_DIM > -0x00028CF0 CB_COLOR2_DIM > -0x00028D2C CB_COLOR3_DIM > -0x00028D68 CB_COLOR4_DIM > -0x00028DA4 CB_COLOR5_DIM > -0x00028DE0 CB_COLOR6_DIM > -0x00028E1C CB_COLOR7_DIM > -0x00028E58 CB_COLOR8_DIM > -0x00028E74 CB_COLOR9_DIM > -0x00028E90 CB_COLOR10_DIM > -0x00028EAC CB_COLOR11_DIM > +0x00028C7C CB_COLOR0_CMASK > +0x00028C80 CB_COLOR0_CMAKS_SLICE > +0x00028C84 CB_COLOR0_FMASK > +0x00028C88 CB_COLOR0_FMASK_SLICE > 0x00028C8C CB_COLOR0_CLEAR_WORD0 > 0x00028C90 CB_COLOR0_CLEAR_WORD1 > 0x00028C94 CB_COLOR0_CLEAR_WORD2 > 0x00028C98 CB_COLOR0_CLEAR_WORD3 > +0x00028CAC CB_COLOR1_INFO > +0x00028CB0 CB_COLOR1_ATTRIB > +0x00028CB4 CB_COLOR1_DIM > +0x00028CB8 CB_COLOR1_CMASK > +0x00028CBC CB_COLOR1_CMAKS_SLICE > +0x00028CC0 CB_COLOR1_FMASK > +0x00028CC4 CB_COLOR1_FMASK_SLICE > 0x00028CC8 CB_COLOR1_CLEAR_WORD0 > 0x00028CCC CB_COLOR1_CLEAR_WORD1 > 0x00028CD0 CB_COLOR1_CLEAR_WORD2 > 0x00028CD4 CB_COLOR1_CLEAR_WORD3 > +0x00028CE8 CB_COLOR2_INFO > +0x00028CEC CB_COLOR2_ATTRIB > +0x00028CF0 CB_COLOR2_DIM > +0x00028CF4 CB_COLOR2_CMASK > +0x00028CF8 CB_COLOR2_CMAKS_SLICE > +0x00028CFC CB_COLOR2_FMASK > +0x00028D00 CB_COLOR2_FMASK_SLICE > 0x00028D04 CB_COLOR2_CLEAR_WORD0 > 0x00028D08 CB_COLOR2_CLEAR_WORD1 > 0x00028D0C CB_COLOR2_CLEAR_WORD2 > 0x00028D10 CB_COLOR2_CLEAR_WORD3 > +0x00028D24 CB_COLOR3_INFO > +0x00028D28 CB_COLOR3_ATTRIB > +0x00028D2C CB_COLOR3_DIM > +0x00028D30 CB_COLOR3_CMASK > +0x00028D34 CB_COLOR3_CMAKS_SLICE > +0x00028D38 CB_COLOR3_FMASK > +0x00028D3C CB_COLOR3_FMASK_SLICE > 0x00028D40 CB_COLOR3_CLEAR_WORD0 > 0x00028D44 CB_COLOR3_CLEAR_WORD1 > 0x00028D48 CB_COLOR3_CLEAR_WORD2 > 0x00028D4C CB_COLOR3_CLEAR_WORD3 > +0x00028D60 CB_COLOR4_INFO > +0x00028D64 CB_COLOR4_ATTRIB > +0x00028D68 CB_COLOR4_DIM > +0x00028D6C CB_COLOR4_CMASK > +0x00028D70 CB_COLOR4_CMAKS_SLICE > +0x00028D74 CB_COLOR4_FMASK > +0x00028D78 CB_COLOR4_FMASK_SLICE > 0x00028D7C CB_COLOR4_CLEAR_WORD0 > 0x00028D80 CB_COLOR4_CLEAR_WORD1 > 0x00028D84 CB_COLOR4_CLEAR_WORD2 > 0x00028D88 CB_COLOR4_CLEAR_WORD3 > +0x00028D9C CB_COLOR5_INFO > +0x00028DA0 CB_COLOR5_ATTRIB > +0x00028DA4 CB_COLOR5_DIM > +0x00028DA8 CB_COLOR5_CMASK > +0x00028DAC CB_COLOR5_CMAKS_SLICE > +0x00028DB0 CB_COLOR5_FMASK > +0x00028DB4 CB_COLOR5_FMASK_SLICE > 0x00028DB8 CB_COLOR5_CLEAR_WORD0 > 0x00028DBC CB_COLOR5_CLEAR_WORD1 > 0x00028DC0 CB_COLOR5_CLEAR_WORD2 > 0x00028DC4 CB_COLOR5_CLEAR_WORD3 > +0x00028DD8 CB_COLOR6_INFO > +0x00028DDC CB_COLOR6_ATTRIB > +0x00028DE0 CB_COLOR6_DIM > +0x00028DE4 CB_COLOR6_CMASK > +0x00028DE8 CB_COLOR6_CMAKS_SLICE > +0x00028DEC CB_COLOR6_FMASK > +0x00028DF0 CB_COLOR6_FMASK_SLICE > 0x00028DF4 CB_COLOR6_CLEAR_WORD0 > 0x00028DF8 CB_COLOR6_CLEAR_WORD1 > 0x00028DFC CB_COLOR6_CLEAR_WORD2 > 0x00028E00 CB_COLOR6_CLEAR_WORD3 > +0x00028E14 CB_COLOR7_INFO > +0x00028E18 CB_COLOR7_ATTRIB > +0x00028E1C CB_COLOR7_DIM > +0x00028E20 CB_COLOR7_CMASK > +0x00028E24 CB_COLOR7_CMAKS_SLICE > +0x00028E28 CB_COLOR7_FMASK > +0x00028E2C CB_COLOR7_FMASK_SLICE > 0x00028E30 CB_COLOR7_CLEAR_WORD0 > 0x00028E34 CB_COLOR7_CLEAR_WORD1 > 0x00028E38 CB_COLOR7_CLEAR_WORD2 > 0x00028E3C CB_COLOR7_CLEAR_WORD3 > +0x00028E50 CB_COLOR8_INFO > +0x00028E54 CB_COLOR8_ATTRIB > +0x00028E58 CB_COLOR8_DIM > +0x00028E6C CB_COLOR9_INFO > +0x00028E70 CB_COLOR9_ATTRIB > +0x00028E74 CB_COLOR9_DIM > +0x00028E88 CB_COLOR10_INFO > +0x00028E8C CB_COLOR10_ATTRIB > +0x00028E90 CB_COLOR10_DIM > +0x00028EA4 CB_COLOR11_INFO > +0x00028EA8 CB_COLOR11_ATTRIB > +0x00028EAC CB_COLOR11_DIM > 0x00028F80 SQ_ALU_CONST_BUFFER_SIZE_HS_0 > 0x00028F84 SQ_ALU_CONST_BUFFER_SIZE_HS_1 > 0x00028F88 SQ_ALU_CONST_BUFFER_SIZE_HS_2 > -- > 1.8.4.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
On Mon, Dec 02, 2013 at 11:00:29AM +0100, Paul Bolle wrote:
> On Mon, 2013-12-02 at 11:08 +0200, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l?
> >
> > Some lower level things get angry if we don't have modeset locks
> > during intel_modeset_setup_hw_state(). Actually the resume and
> > lid_notify codepaths alreday hold the locks, but the init codepath
> > doesn't, so fix that.
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > Totally untested, but looks correct to me.
>
> I assume I need to test this, on top of 7c063c725987 ("drm/i915: take
> mode config lock around crtc disable at suspend"), to see if this makes
> the WARNING that I currently see at boot go away?
Yeah that would be nice.
> Paul Bolle
>
> > drivers/gpu/drm/i915/intel_display.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 080f6fd..114db51 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11046,7 +11046,9 @@ void intel_modeset_gem_init(struct drm_device *dev)
> >
> > intel_setup_overlay(dev);
> >
> > + drm_modeset_lock_all(dev);
> > intel_modeset_setup_hw_state(dev, false);
> > + drm_modeset_unlock_all(dev);
> > }
> >
> > void intel_modeset_cleanup(struct drm_device *dev)
--
Ville Syrj?l?
Intel OTC
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 --- Comment #6 from octoploid --- (In reply to comment #5) > Looks like the X server may not shut down cleanly. Is there something > interesting in its stderr output? You may find it in the display manager log > file(s). I redirected the output of startx to a log file, but there's nothing interesting in there AFAICS. > (In reply to comment #4) > > > Can you still log in via ssh at that point? > > > > Yes. > > What happens if you try starting X again or switching VTs using chvt from > ssh? Sorry, I just assumed that ssh would work because the machine still responds to SysRq input. I cannot test this ATM. -- 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/20131202/ceb65da0/attachment.html>
[PATCH 2/2] drm/i915: Return a drm_mode_status enum in the mode_valid vfuncs
On Thu, Nov 28, 2013 at 04:49:52PM +0100, Daniel Vetter wrote: > On Thu, Nov 28, 2013 at 03:29:18PM +, Damien Lespiau wrote: > > We had some mode_valid() vfuncs returning an int, others the enum. Let's > > use the latter everywhere. > > > > Signed-off-by: Damien Lespiau > > Yeah, makes sense. Queued for -next, thanks for the patch. > > -Daniel > > --- > > drivers/gpu/drm/i915/intel_crt.c | 5 +++-- > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > drivers/gpu/drm/i915/intel_dsi.c | 5 +++-- > > drivers/gpu/drm/i915/intel_dvo.c | 5 +++-- > > drivers/gpu/drm/i915/intel_hdmi.c | 5 +++-- > > drivers/gpu/drm/i915/intel_lvds.c | 5 +++-- > > drivers/gpu/drm/i915/intel_sdvo.c | 5 +++-- > > 7 files changed, 19 insertions(+), 13 deletions(-) Shouldn't you be updating all other drivers as well? GCC doesn't seem to complain about it, but it's still an inconsistency. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/e299ada6/attachment.pgp>
[GIT PULL] exynos-drm-fixes
Hi Dave, This pull request includes two fixup patches pended for long time. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 1b28c3e628315ac0d9ef2d3fac0403f05ae692db: drm/qxl: fix memory leak in release list handling (2013-11-29 08:36:15 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes for you to fetch changes up to 0cbc330e12835fcbac44e33d5632d805b16635f2: drm/exynos: release unhandled page flip events at postclose. (2013-12-02 22:49:20 +0900) Inki Dae (1): drm/exynos: release unhandled page flip events at postclose. Sachin Kamat (1): drm/exynos: Fix trivial typo in exynos_drm_fimd.c drivers/gpu/drm/exynos/exynos_drm_drv.c | 35 +++--- drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- 2 files changed, 23 insertions(+), 14 deletions(-)
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle wrote: > On Mon, 2013-12-02 at 08:33 +0100, Daniel Vetter wrote: >> On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle wrote: >> > The WARNING is now gone during suspend and resume (having tested that >> > thoroughly - ie, twice). But I still see it at boot. Is there a related >> > fix for that WARNING during boot? >> >> Hm, I've never seen it during boot. Can you please boot with >> drm.debug=0xe and attach the dmesg with the WARN? > > Sure. > > This generated quite a bit of debug messages so I only copied the > WARNING and the drm (related) messages immediately preceding it. Please > feel free to prod again if that's insufficient. Yeah, the beginning of the drm message would are wanted since I need to know what exactly your hardware claims to support ;-) But the backtrace confirms my first hunch for now ... Just want to confirm before sending out a patch with commit message. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 72228] New: Painkiller: Hell and Damnation segfaults intermittently on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=72228 Priority: medium Bug ID: 72228 Assignee: dri-devel at lists.freedesktop.org Summary: Painkiller: Hell and Damnation segfaults intermittently on radeonsi Severity: normal Classification: Unclassified OS: Linux (All) Reporter: xamaniqinqu at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 90108 --> https://bugs.freedesktop.org/attachment.cgi?id=90108&action=edit Log file of crashed Painkiller: Hell and Damnation run Overview: The game "Painkiller: Hell and Damnation" randomly crashes (segfaults) in-game, probably due to a LLVM-related bug. Steps to reproduce: 1) Install the Painkiller: Hell and Damnation Linux client (resource: http://store.steampowered.com/app/214870/) 2) Start the game, enter a level 3) Play until it crashes Actual results: A random crash 2-3 minutes into playtime. Expected results: No crash. Build date and platform: Build date of all components: 12/02/2013 Linux kernel version: 3.12.1-gentoo x86_64 Mesa: git (c4cf487315f1f5375534f1677177983fa496d577) LLVM: 3.5-svn (bc134cb1f18e6870ccebbf03e40b7de11f274644) Additional information: The error log, including a backtrace, is attached. It strongly suggests the problem is related to LLVM. There is no demo client available for Painkiller: Hell and Damnation, I will attempt to reproduce this bug in other programs (like Xonotic). -- 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/20131202/caab981d/attachment.html>
[Bug 72228] Painkiller: Hell and Damnation segfaults intermittently on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=72228 Remco Zoet changed: What|Removed |Added Version|unspecified |git -- 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/20131202/d9939aef/attachment-0001.html>
[PATCH] of: Add MIPI DSI bus device tree bindings
Document the device tree bindings for the MIPI DSI bus. The MIPI Display
Serial Interface specifies a serial bus and a protocol for communication
between a host and up to four peripherals.
Signed-off-by: Thierry Reding
---
.../devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
diff --git a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
new file mode 100644
index ..f58ca4485a2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
@@ -0,0 +1,54 @@
+MIPI DSI (Display Serial Interface) busses
+==
+
+The MIPI Display Serial Interface specifies a serial bus and a protocol for
+communication between a host and up to four peripherals. This document will
+define the syntax used to represent a DSI bus in a device tree.
+
+This document describes DSI bus-specific properties only or defines existing
+standard properties in the context of the DSI bus.
+
+Each DSI host provides a DSI bus. The DSI host controller's node contains a
+set of properties that characterize the bus. Child nodes describe individual
+peripherals on that bus.
+
+DSI host
+
+
+In addition to the standard properties and those defined by the parent bus of
+a DSI host, the following properties apply to a node representing a DSI host.
+
+Required properties:
+- #address-cells: The number of cells required to represent an address on the
+ bus. DSI peripherals are addressed using a 2-bit virtual channel number, so
+ a maximum of 4 devices can be addressed on a single bus. Hence the value of
+ this property should be 1.
+- #size-cells: Should be 0.
+
+DSI peripheral
+--
+
+Peripherals are represented as child nodes of the DSI host's node. Properties
+described here apply to all DSI peripherals, but individual bindings may want
+to define additional, device-specific properties.
+
+Required properties:
+- reg: The virtual channel number of a DSI peripheral. Must be in the range
+ from 0 to 3.
+
+Example
+---
+
+ dsi-host {
+ ...
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ peripheral at 0 {
+ compatible = "...";
+ reg = <0>;
+ };
+
+ ...
+ };
--
1.8.4.2
[Bug 72087] Black levels incorrect during video playback at first
https://bugs.freedesktop.org/show_bug.cgi?id=72087 --- Comment #2 from Andy Furniss --- (In reply to comment #1) > Video can be found at http://youtu.be/lTUtw0onSCw and the issue is observed > around 9-10 second mark. That looks like some auto level thing like C.A.T.S - is that turned on on the Panny for that input? Unlike Windows I don't think OSS Radeon will do anything other than full range RGB over HDMI - I would investigate the "dark" issue as perhaps setting XBMC not to scale to full range may be confusing something that's trying to automagically tweak things for you - Denon or TV - I don't know, but it's normal for 16 - 235 luma to have samples that are below/above which usually get corrected by the stretch to full range. PS How did you add dither to xrandr? -- 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/20131202/1dfe8ca4/attachment.html>
[Bug 72087] Black levels incorrect during video playback at first
https://bugs.freedesktop.org/show_bug.cgi?id=72087 --- Comment #3 from pyrodex --- Thanks for the feedback Andy. The Denon and the Panasonic are both in "Extended (0-255)" and it seems in the upcoming XBMC release you can adjust the levels. By default XBMC was set to 0-255 and I noticed the VERY dark scenes and settings so they suggesting changing XBMC to 16-235. Before I know about the XBMC setting I changed the Denon to 16-235 and it fixed the darkness issue. I have these same two machines with IDENTICAL hardware, etc. but the second unit which is upstairs in my Bedroom is attached to an LG 32" LCD TV and has the same issue. The ONLY common point between the two setups is a Griffin HDMI detective to prevent issues I've seen in the past when I shut off the TVs(and AVR) and leave the units running. The only thing I've changed in this equation was the leap to Linux from Windows with the OSS drivers for radeon. FYI I used "xrandr --output HDMI-0 --set dither On" in my startup script after X started. Any recommendations is welcome. -- 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/20131202/8a7aa9e0/attachment.html>
[Bug 72228] Painkiller: Hell and Damnation segfaults intermittently on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=72228 --- Comment #1 from Tom Stellard --- Can you rebuild LLVM with debuging symbols: --enable-debug and repost the backtrace? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/8dc1f21a/attachment.html>
[Bug 71864] [RS690] GPU Lockup CP Stall and Resulting Kernel Oops (Kernel 3.2.0)
https://bugs.freedesktop.org/show_bug.cgi?id=71864 --- Comment #19 from Alex Deucher --- (In reply to comment #18) > > Is the wine required combined use of 32-bit (i386) and 64-bit (amd64) > userspace drivers on an AMD platform supposed to be valid and stable > approach? Yes, that should work fine. -- 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/20131202/adbc97be/attachment.html>
[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
On Mon, 2013-12-02 at 14:12 +0200, Ville Syrj?l? wrote:
> On Mon, Dec 02, 2013 at 11:00:29AM +0100, Paul Bolle wrote:
> > I assume I need to test this, on top of 7c063c725987 ("drm/i915: take
> > mode config lock around crtc disable at suspend"), to see if this makes
> > the WARNING that I currently see at boot go away?
>
> Yeah that would be nice.
A grand total of one boot suggests that this patch really makes the
v3.13+ WARNING go away at boot too. Should I test more thoroughly?
Paul Bolle
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Mon, 2013-12-02 at 15:23 +0100, Daniel Vetter wrote: > On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle wrote: > > This generated quite a bit of debug messages so I only copied the > > WARNING and the drm (related) messages immediately preceding it. Please > > feel free to prod again if that's insufficient. > > Yeah, the beginning of the drm message would are wanted since I need > to know what exactly your hardware claims to support ;-) > > But the backtrace confirms my first hunch for now ... Just want to > confirm before sending out a patch with commit message. It seems Ville's patch ( https://lkml.org/lkml/2013/12/2/77 ) does the trick. Do you still need the additional info? Paul Bolle
[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=64801 --- Comment #12 from Alex Deucher --- (In reply to comment #11) > Created attachment 90044 [details] > dmesg output > > I too am seeing this. Particularly in games Euro Truck Simulator 2 and X3 > franchise. Graphical corruption is obvious. dmesg output attached. You are seeing an out of system memory condition. The driver is not able to allocate enough memory to process the GPU's command buffer so the rendering gets dropped which is why you are seeing corruption. -- 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/20131202/f9d7f466/attachment-0001.html>
[Bug 69775] [r600g] RV730 AGP UVD hang (GPU lockup) with mplayer on dual DVI display with 3.12-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=69775 --- Comment #4 from Alex Deucher --- (In reply to comment #3) > Retested with > > Kernel 3.13-rc1 + drm-radeon-fix-typo-in-fetching-mpll-params.patch That patch only affects SI and CI parts so something else must have fixed it. -- 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/20131202/99e64058/attachment.html>
[Bug 66201] AMD atombios stuck
https://bugzilla.kernel.org/show_bug.cgi?id=66201 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- The bug title should be changed. The atombios messages are just a side effect of the driver trying to access a GPU that has been powered down via vgaswitcheroo. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 66201] AMD atombios stuck
https://bugzilla.kernel.org/show_bug.cgi?id=66201 --- Comment #2 from RussianNeuroMancer --- So 3.13 trying to power down/up dGPU even if radeon.runpm=1 is not set? runpm is enabled by default? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 72195] Sea in Crusader Kings II rendered in green colour with grey dots
https://bugs.freedesktop.org/show_bug.cgi?id=72195 Alex Deucher changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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/20131202/3386f48e/attachment.html>
[Bug 66201] AMD atombios stuck
https://bugzilla.kernel.org/show_bug.cgi?id=66201 --- Comment #3 from Alex Deucher --- (In reply to RussianNeuroMancer from comment #2) > So 3.13 trying to power down/up dGPU even if radeon.runpm=1 is not set? > runpm is enabled by default? runpm is enabled by default in 3.13. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=64801 --- Comment #13 from aaannz at gmail.com --- Ok, so is this bug in a game itself? I never experienced something like this on Windows (except of crashed, which may indeed be Windows way to handle this) even on more demanding games like Arma 3. I have 1024MB VRAM and I just tried ETS2 with GALLIUM_HUD and it reported maximal requested VRAM to be 700MB. At the beginning (requested VRAM was about 400MB) I even got some graphics corruption but that it was all ok. Note that other visually demanding games like Serious Sam 3, Killing Floor, HL2, CS:S does not exhibit this behaviour under linux, at least I didn't noticed graphical corruption and/or blinking textures so I didn't check dmesg in these cases. -- 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/20131202/8a4d8493/attachment.html>
[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=64801 --- Comment #14 from Alex Deucher --- It's not really a bug per se, the system is just out of memory. Note that this is system memory that you've run out of (not vram). The radeon kernel driver allocates system memory (kmalloc) for some structures that are used for processing the command buffers from the 3D driver. When the kernel driver is not able to allocate that memory, it just skips the GPU command buffer since it can't process it. That's why you see the corruption; certain GPU commands never happened. You'd probably need to track down further what processes are using large amounts of memory to see why you are out. -- 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/20131202/2f13aa4b/attachment.html>
[Bug 69775] [r600g] RV730 AGP UVD hang (GPU lockup) with mplayer on dual DVI display with 3.12-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=69775 --- Comment #5 from Dieter N?tzel --- (In reply to comment #4) > (In reply to comment #3) > > Retested with > > > > Kernel 3.13-rc1 + drm-radeon-fix-typo-in-fetching-mpll-params.patch > > That patch only affects SI and CI parts so something else must have fixed it. I didn't said that that patch fixed it ;-) Maybe Christian's 2 fixes which didn't made it into 3.12-final and 3.12.2, currently. drm/radeon: activate UVD clocks before sending the destroy msg http://cgit.freedesktop.org/~agd5f/linux/patch/?id=c154a76311293f9671439286834aa325b7ef59fe drm/radeon: fix UVD destroy IB size http://cgit.freedesktop.org/~agd5f/linux/patch/?id=727ddc84a1373bf06b2fa261f44e38fb0faf5340 -Dieter -- 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/20131202/0177a3b7/attachment-0001.html>
[PATCH] drm/radeon: Fix a typo in Cayman and Evergreen registers
Applied. thanks! On Mon, Dec 2, 2013 at 2:33 AM, Alexandre Demers wrote: > According to documentation, 0x8A60 should be PA_SU_LINE_STIPPLE_VALUE. > > Signed-off-by: Alexandre Demers > --- > drivers/gpu/drm/radeon/reg_srcs/cayman| 2 +- > drivers/gpu/drm/radeon/reg_srcs/evergreen | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman > b/drivers/gpu/drm/radeon/reg_srcs/cayman > index a072fa8..ca8896d 100644 > --- a/drivers/gpu/drm/radeon/reg_srcs/cayman > +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman > @@ -21,7 +21,7 @@ cayman 0x9400 > 0x89AC VGT_COMPUTE_THREAD_GOURP_SIZE > 0x89B0 VGT_HS_OFFCHIP_PARAM > 0x8A14 PA_CL_ENHANCE > -0x8A60 PA_SC_LINE_STIPPLE_VALUE > +0x8A60 PA_SU_LINE_STIPPLE_VALUE > 0x8B10 PA_SC_LINE_STIPPLE_STATE > 0x8BF0 PA_SC_ENHANCE > 0x8D8C SQ_DYN_GPR_CNTL_PS_FLUSH_REQ > diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen > b/drivers/gpu/drm/radeon/reg_srcs/evergreen > index b912a37..2513cb2 100644 > --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen > +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen > @@ -22,7 +22,7 @@ evergreen 0x9400 > 0x89A4 VGT_COMPUTE_START_Z > 0x89AC VGT_COMPUTE_THREAD_GOURP_SIZE > 0x8A14 PA_CL_ENHANCE > -0x8A60 PA_SC_LINE_STIPPLE_VALUE > +0x8A60 PA_SU_LINE_STIPPLE_VALUE > 0x8B10 PA_SC_LINE_STIPPLE_STATE > 0x8BF0 PA_SC_ENHANCE > 0x8D8C SQ_DYN_GPR_CNTL_PS_FLUSH_REQ > -- > 1.8.4.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] of: Add MIPI DSI bus device tree bindings
Hi Thierry,
On Monday 02 of December 2013 16:37:11 Thierry Reding wrote:
> Document the device tree bindings for the MIPI DSI bus. The MIPI Display
> Serial Interface specifies a serial bus and a protocol for communication
> between a host and up to four peripherals.
>
> Signed-off-by: Thierry Reding
> ---
> .../devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 54
> ++
> 1 file changed, 54 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
>
> diff --git a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
> b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
> new file mode 100644
> index ..f58ca4485a2f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
> @@ -0,0 +1,54 @@
> +MIPI DSI (Display Serial Interface) busses
> +==
> +
> +The MIPI Display Serial Interface specifies a serial bus and a protocol for
> +communication between a host and up to four peripherals. This document will
> +define the syntax used to represent a DSI bus in a device tree.
> +
> +This document describes DSI bus-specific properties only or defines existing
> +standard properties in the context of the DSI bus.
> +
> +Each DSI host provides a DSI bus. The DSI host controller's node contains a
> +set of properties that characterize the bus. Child nodes describe individual
> +peripherals on that bus.
> +
> +DSI host
> +
> +
> +In addition to the standard properties and those defined by the parent bus of
> +a DSI host, the following properties apply to a node representing a DSI host.
> +
> +Required properties:
> +- #address-cells: The number of cells required to represent an address on the
> + bus. DSI peripherals are addressed using a 2-bit virtual channel number, so
> + a maximum of 4 devices can be addressed on a single bus. Hence the value of
> + this property should be 1.
> +- #size-cells: Should be 0.
> +
> +DSI peripheral
> +--
> +
> +Peripherals are represented as child nodes of the DSI host's node. Properties
> +described here apply to all DSI peripherals, but individual bindings may want
> +to define additional, device-specific properties.
> +
> +Required properties:
> +- reg: The virtual channel number of a DSI peripheral. Must be in the range
> + from 0 to 3.
> +
> +Example
> +---
> +
> + dsi-host {
> + ...
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + peripheral at 0 {
> + compatible = "...";
> + reg = <0>;
> + };
> +
> + ...
> + };
>
In general, this looks good to me as a starter, so we could have support
for DSI bus merged. IMHO we should consider adding some generic bus
properties in future, though.
Anyway, have my
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
[Bug 66201] AMD atombios stuck
https://bugzilla.kernel.org/show_bug.cgi?id=66201 RussianNeuroMancer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from RussianNeuroMancer --- Thanks for answer. From others reports related to runpm I assume it has to be enabled manually, but mistake. I tried to disabled runpm and now Linux 3.13 seems like boot fine, like previous releases. So this issue probably duplicate of this one: https://bugs.freedesktop.org/show_bug.cgi?id=62882 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/3] drm: Add LCD display clock polarity flags
On Mon, Dec 2, 2013 at 3:01 PM, Russell King - ARM Linux wrote: > On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote: >> Add DRM flags for the LCD display clock polarity so the pixelclk-active DT >> property can be properly handled by drivers using the DRM API. > > I still say that not even this should be part of the DRM mode API to > userspace. The hint that you're changing the user API is that you're > modifying a header file below a 'uapi' directory. > > The settings of double scan, sync polarity etc are all part of the > display mode specification (check CEA-861 documents). Things like > pixel clock polarity are not part of the mode specification, they're > a property of the display itself and are independent of the mode. > > Therefore, they should not be part of struct drm_mode_modeinfo. Note that we could make them part of drm_display_mode (but drm_crtc_convert_to_umode() should filter them out when copying from drm_mode_modeinfo.. I agree this information should not be coming from userspace). Seems like the sort of thing that the bridge or encoder could set on the adjusted_mode. BR, -R > ___ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[PATCH] of: Add MIPI DSI bus device tree bindings
On Mon, Dec 02, 2013 at 08:57:20PM +0100, Tomasz Figa wrote:
> On Monday 02 of December 2013 16:37:11 Thierry Reding wrote:
[...]
> > +Example
> > +---
> > +
> > + dsi-host {
> > + ...
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + peripheral at 0 {
> > + compatible = "...";
> > + reg = <0>;
> > + };
> > +
> > + ...
> > + };
> >
>
> In general, this looks good to me as a starter, so we could have support
> for DSI bus merged. IMHO we should consider adding some generic bus
> properties in future, though.
To be honest this looked somewhat minimal to me too at first, and then I
tried to come up with any other properties but couldn't think of any. Of
course anything that we add later on has the potential to break ABI
compatibility.
A few of the things I had in mind that might be added as properties were
the number of lanes or the video format. But those will already be
implied by the compatible value and therefore don't really belong in the
DT.
But if anyone can think of other properties that would be useful for DSI
host or peripherals, by all means, let me know.
> Anyway, have my
>
> Reviewed-by: Tomasz Figa
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/3b4cb924/attachment.pgp>
[PATCH] drm/radeon: fix VGT_GS_INSTANCE_CNT register
Applied. thanks! On Sat, Nov 30, 2013 at 6:07 AM, Dave Airlie wrote: > this register was incorrect for evergreen and cayman. > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/radeon/radeon_drv.h | 3 ++- > drivers/gpu/drm/radeon/reg_srcs/cayman| 2 +- > drivers/gpu/drm/radeon/reg_srcs/evergreen | 2 +- > 3 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_drv.h > b/drivers/gpu/drm/radeon/radeon_drv.h > index b369d42..e1082be 100644 > --- a/drivers/gpu/drm/radeon/radeon_drv.h > +++ b/drivers/gpu/drm/radeon/radeon_drv.h > @@ -108,9 +108,10 @@ > * 1.31- Add support for num Z pipes from GET_PARAM > * 1.32- fixes for rv740 setup > * 1.33- Add r6xx/r7xx const buffer support > + * 1.34- fix evergreen/cayman GS register > */ > #define DRIVER_MAJOR 1 > -#define DRIVER_MINOR 33 > +#define DRIVER_MINOR 34 > #define DRIVER_PATCHLEVEL 0 > > /* The rest of the file is DEPRECATED! */ > diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman > b/drivers/gpu/drm/radeon/reg_srcs/cayman > index a072fa8..af7a941 100644 > --- a/drivers/gpu/drm/radeon/reg_srcs/cayman > +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman > @@ -532,7 +532,7 @@ cayman 0x9400 > 0x00028B84 PA_SU_POLY_OFFSET_FRONT_OFFSET > 0x00028B88 PA_SU_POLY_OFFSET_BACK_SCALE > 0x00028B8C PA_SU_POLY_OFFSET_BACK_OFFSET > -0x00028B74 VGT_GS_INSTANCE_CNT > +0x00028B90 VGT_GS_INSTANCE_CNT > 0x00028BD4 PA_SC_CENTROID_PRIORITY_0 > 0x00028BD8 PA_SC_CENTROID_PRIORITY_1 > 0x00028BDC PA_SC_LINE_CNTL > diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen > b/drivers/gpu/drm/radeon/reg_srcs/evergreen > index b912a37..e19ef0e 100644 > --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen > +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen > @@ -545,7 +545,7 @@ evergreen 0x9400 > 0x00028B84 PA_SU_POLY_OFFSET_FRONT_OFFSET > 0x00028B88 PA_SU_POLY_OFFSET_BACK_SCALE > 0x00028B8C PA_SU_POLY_OFFSET_BACK_OFFSET > -0x00028B74 VGT_GS_INSTANCE_CNT > +0x00028B90 VGT_GS_INSTANCE_CNT > 0x00028C00 PA_SC_LINE_CNTL > 0x00028C08 PA_SU_VTX_CNTL > 0x00028C0C PA_CL_GB_VERT_CLIP_ADJ > -- > 1.8.4.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68799] [APITRACE] Hyper-Z lockup with Falcon BMS 4.32u6 on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=68799 Marek Ol??k changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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/20131202/9423be18/attachment.html>
[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #78 from Alex Deucher --- (In reply to comment #77) > Hello Mr. Deucher, hello d4ddi0; sorry for not responding, unfortunately I > can only test it on this weekend, sorry for polluting maillist with my ego > status. As I mentioned in a previous comment, this patch won't affect your system. RS600 chips don't support sideport memory and they use a different code path in the driver to configure the memory controller. Please use bug 35998. -- 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/20131202/1c948a8e/attachment.html>
[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 Alex Deucher changed: What|Removed |Added Attachment #89886|0 |1 is obsolete|| --- Comment #79 from Alex Deucher --- Created attachment 90125 --> https://bugs.freedesktop.org/attachment.cgi?id=90125&action=edit possible fix Please try this updated patch. thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131202/a63c8273/attachment-0001.html>
[PATCH] drm/radeon: Fix sideport problems on certain RS690 boards
Some RS690 boards with 64MB of sideport memory show up as
having 128MB sideport + 256MB of UMA. In this case,
just skip the sideport memory and use UMA. This fixes
rendering corruption and should improve performance.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=35457
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/rs690.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
index 1c56062..e7dab06 100644
--- a/drivers/gpu/drm/radeon/rs690.c
+++ b/drivers/gpu/drm/radeon/rs690.c
@@ -162,6 +162,16 @@ static void rs690_mc_init(struct radeon_device *rdev)
base = RREG32_MC(R_000100_MCCFG_FB_LOCATION);
base = G_000100_MC_FB_START(base) << 16;
rdev->mc.igp_sideport_enabled = radeon_atombios_sideport_present(rdev);
+ /* Some boards seem to be configured for 128MB of sideport memory,
+* but really only have 64MB. Just skip the sideport and use
+* UMA memory.
+*/
+ if (rdev->mc.igp_sideport_enabled &&
+ (rdev->mc.real_vram_size == (384 * 1024 * 1024))) {
+ base += 128 * 1024 * 1024;
+ rdev->mc.real_vram_size -= 128 * 1024 * 1024;
+ rdev->mc.mc_vram_size = rdev->mc.real_vram_size;
+ }
/* Use K8 direct mapping for fast fb access. */
rdev->fastfb_working = false;
--
1.8.3.1
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
ge+0xef/0x110 [radeon]
Dec 02 01:01:05 Xander kernel:[]
radeon_cs_ioctl+0x8f0/0x9f0 [radeon]
Dec 02 01:01:05 Xander kernel:[]
drm_ioctl+0x502/0x640
Dec 02 01:01:05 Xander kernel:[]
radeon_drm_ioctl+0x49/0x80 [radeon]
Dec 02 01:01:05 Xander kernel:[]
do_vfs_ioctl+0x300/0x520
Dec 02 01:01:05 Xander kernel:[] SyS_ioctl+0x81/0xa0
Dec 02 01:01:05 Xander kernel:[]
system_call_fastpath+0x1a/0x1f
Dec 02 01:01:05 Xander kernel:
-> #0 (reservation_ww_class_mutex){+.+.+.}:
Dec 02 01:01:05 Xander kernel:[]
__lock_acquire+0x195a/0x1b20
Dec 02 01:01:05 Xander kernel:[]
lock_acquire+0x72/0xa0
Dec 02 01:01:05 Xander kernel:[]
mutex_lock_interruptible_nested+0x58/0x550
Dec 02 01:01:05 Xander kernel:[]
ttm_bo_wait_unreserved+0x39/0x70 [ttm]
Dec 02 01:01:05 Xander kernel:[]
ttm_bo_vm_fault+0x389/0x470 [ttm]
Dec 02 01:01:05 Xander kernel:[]
radeon_ttm_fault+0x47/0x60 [radeon]
Dec 02 01:01:05 Xander kernel:[]
__do_fault+0x6c/0x4c0
Dec 02 01:01:05 Xander kernel:[]
handle_mm_fault+0x2e6/0xc90
Dec 02 01:01:05 Xander kernel:[]
__do_page_fault+0x165/0x560
Dec 02 01:01:05 Xander kernel:[]
do_page_fault+0x9/0x10
Dec 02 01:01:05 Xander kernel:[] page_fault+0x28/0x30
Dec 02 01:01:05 Xander kernel:
other info that might help us debug this:
Dec 02 01:01:05 Xander kernel: Chain exists of:
reservation_ww_class_mutex -->
&rdev->pm.mclk_lock --> &bo->wu_mutex
Dec 02 01:01:05 Xander kernel: Possible unsafe locking scenario:
Dec 02 01:01:05 Xander kernel:CPU0CPU1
Dec 02 01:01:05 Xander kernel:
Dec 02 01:01:05 Xander kernel: lock(&bo->wu_mutex);
Dec 02 01:01:05 Xander kernel:
lock(&rdev->pm.mclk_lock);
Dec 02 01:01:05 Xander kernel:
lock(&bo->wu_mutex);
Dec 02 01:01:05 Xander kernel: lock(reservation_ww_class_mutex);
Dec 02 01:01:05 Xander kernel:
*** DEADLOCK ***
Dec 02 01:01:05 Xander kernel: 2 locks held by chromium/3786:
Dec 02 01:01:05 Xander kernel: #0: (&rdev->pm.mclk_lock){++}, at:
[] radeon_ttm_fault+0x36/0x60 [radeon]
Dec 02 01:01:05 Xander kernel: #1: (&bo->wu_mutex){+.+...}, at:
[] ttm_bo_wait_unreserved+0x1d/0x70 [ttm]
Dec 02 01:01:05 Xander kernel:
stack backtrace:
Dec 02 01:01:05 Xander kernel: CPU: 1 PID: 3786 Comm: chromium Tainted: G
C 3.13.0-rc2-VANILLA-dirty #170
Dec 02 01:01:05 Xander kernel: Hardware name: Gigabyte Technology Co., Ltd.
GA-990FXA-UD3/GA-990FXA-UD3, BIOS F10a 01/24/2013
Dec 02 01:01:05 Xander kernel: 8241ade0 8803e9a03a18
81824a57 8241af90
Dec 02 01:01:05 Xander kernel: 8803e9a03a58 8181f529
8803e9a03ab0 8803e5d7c6d8
Dec 02 01:01:05 Xander kernel: 0001 8803e5d7c6b0
8803e5d7c080 8803e5d7c6d8
Dec 02 01:01:05 Xander kernel: Call Trace:
Dec 02 01:01:05 Xander kernel: [] dump_stack+0x45/0x56
Dec 02 01:01:05 Xander kernel: []
print_circular_bug+0x1f9/0x208
Dec 02 01:01:05 Xander kernel: []
__lock_acquire+0x195a/0x1b20
Dec 02 01:01:05 Xander kernel: [] lock_acquire+0x72/0xa0
Dec 02 01:01:05 Xander kernel: [] ?
ttm_bo_wait_unreserved+0x39/0x70 [ttm]
Dec 02 01:01:05 Xander kernel: []
mutex_lock_interruptible_nested+0x58/0x550
Dec 02 01:01:05 Xander kernel: [] ?
ttm_bo_wait_unreserved+0x39/0x70 [ttm]
Dec 02 01:01:05 Xander kernel: [] ?
ttm_bo_wait_unreserved+0x39/0x70 [ttm]
Dec 02 01:01:05 Xander kernel: [] ?
ttm_bo_vm_fault+0x381/0x470 [ttm]
Dec 02 01:01:05 Xander kernel: []
ttm_bo_wait_unreserved+0x39/0x70 [ttm]
Dec 02 01:01:05 Xander kernel: []
ttm_bo_vm_fault+0x389/0x470 [ttm]
Dec 02 01:01:05 Xander kernel: [] ?
radeon_ttm_fault+0x36/0x60 [radeon]
Dec 02 01:01:05 Xander kernel: [] radeon_ttm_fault+0x47/0x60
[radeon]
Dec 02 01:01:05 Xander kernel: [] __do_fault+0x6c/0x4c0
Dec 02 01:01:05 Xander kernel: []
handle_mm_fault+0x2e6/0xc90
Dec 02 01:01:05 Xander kernel: []
__do_page_fault+0x165/0x560
Dec 02 01:01:05 Xander kernel: [] ? fsnotify+0x83/0x340
Dec 02 01:01:05 Xander kernel: [] ? sysret_check+0x22/0x5d
Dec 02 01:01:05 Xander kernel: [] ?
trace_hardirqs_off_thunk+0x3a/0x3c
Dec 02 01:01:05 Xander kernel: [] do_page_fault+0x9/0x10
Dec 02 01:01:05 Xander kernel: [] page_fault+0x28/0x30
--
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/20131202/3320565a/attachment.html>
[PATCH] drm/radeon: Cayman - add missing registers
OK, I see. Thanks for the info. Alexandre Demers On Mon 02 Dec 2013 06:45:04 AM EST, Marek Ol??k wrote: > The registers aren't listed because they are not safe and they need to > be checked by the CS checker. > > NAK. > > Marek > > On Mon, Dec 2, 2013 at 8:34 AM, Alexandre Demers > wrote: >> Added some missing registers listed in documentation. >> >> Signed-off-by: Alexandre Demers >> --- >> drivers/gpu/drm/radeon/reg_srcs/cayman | 78 >> +- >> 1 file changed, 67 insertions(+), 11 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman >> b/drivers/gpu/drm/radeon/reg_srcs/cayman >> index ca8896d..596cd62 100644 >> --- a/drivers/gpu/drm/radeon/reg_srcs/cayman >> +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman >> @@ -559,50 +559,106 @@ cayman 0x9400 >> 0x00028C34 PA_SC_AA_SAMPLE_LOCS_PIXEL_X1_Y1_3 >> 0x00028C38 PA_SC_AA_MASK_X0_Y0_X1_Y0 >> 0x00028C3C PA_SC_AA_MASK_X0_Y1_X1_Y1 >> +0x00028C70 CB_COLOR0_INFO >> +0x00028C74 CB_COLOR0_ATTRIB >> 0x00028C78 CB_COLOR0_DIM >> -0x00028CB4 CB_COLOR1_DIM >> -0x00028CF0 CB_COLOR2_DIM >> -0x00028D2C CB_COLOR3_DIM >> -0x00028D68 CB_COLOR4_DIM >> -0x00028DA4 CB_COLOR5_DIM >> -0x00028DE0 CB_COLOR6_DIM >> -0x00028E1C CB_COLOR7_DIM >> -0x00028E58 CB_COLOR8_DIM >> -0x00028E74 CB_COLOR9_DIM >> -0x00028E90 CB_COLOR10_DIM >> -0x00028EAC CB_COLOR11_DIM >> +0x00028C7C CB_COLOR0_CMASK >> +0x00028C80 CB_COLOR0_CMAKS_SLICE >> +0x00028C84 CB_COLOR0_FMASK >> +0x00028C88 CB_COLOR0_FMASK_SLICE >> 0x00028C8C CB_COLOR0_CLEAR_WORD0 >> 0x00028C90 CB_COLOR0_CLEAR_WORD1 >> 0x00028C94 CB_COLOR0_CLEAR_WORD2 >> 0x00028C98 CB_COLOR0_CLEAR_WORD3 >> +0x00028CAC CB_COLOR1_INFO >> +0x00028CB0 CB_COLOR1_ATTRIB >> +0x00028CB4 CB_COLOR1_DIM >> +0x00028CB8 CB_COLOR1_CMASK >> +0x00028CBC CB_COLOR1_CMAKS_SLICE >> +0x00028CC0 CB_COLOR1_FMASK >> +0x00028CC4 CB_COLOR1_FMASK_SLICE >> 0x00028CC8 CB_COLOR1_CLEAR_WORD0 >> 0x00028CCC CB_COLOR1_CLEAR_WORD1 >> 0x00028CD0 CB_COLOR1_CLEAR_WORD2 >> 0x00028CD4 CB_COLOR1_CLEAR_WORD3 >> +0x00028CE8 CB_COLOR2_INFO >> +0x00028CEC CB_COLOR2_ATTRIB >> +0x00028CF0 CB_COLOR2_DIM >> +0x00028CF4 CB_COLOR2_CMASK >> +0x00028CF8 CB_COLOR2_CMAKS_SLICE >> +0x00028CFC CB_COLOR2_FMASK >> +0x00028D00 CB_COLOR2_FMASK_SLICE >> 0x00028D04 CB_COLOR2_CLEAR_WORD0 >> 0x00028D08 CB_COLOR2_CLEAR_WORD1 >> 0x00028D0C CB_COLOR2_CLEAR_WORD2 >> 0x00028D10 CB_COLOR2_CLEAR_WORD3 >> +0x00028D24 CB_COLOR3_INFO >> +0x00028D28 CB_COLOR3_ATTRIB >> +0x00028D2C CB_COLOR3_DIM >> +0x00028D30 CB_COLOR3_CMASK >> +0x00028D34 CB_COLOR3_CMAKS_SLICE >> +0x00028D38 CB_COLOR3_FMASK >> +0x00028D3C CB_COLOR3_FMASK_SLICE >> 0x00028D40 CB_COLOR3_CLEAR_WORD0 >> 0x00028D44 CB_COLOR3_CLEAR_WORD1 >> 0x00028D48 CB_COLOR3_CLEAR_WORD2 >> 0x00028D4C CB_COLOR3_CLEAR_WORD3 >> +0x00028D60 CB_COLOR4_INFO >> +0x00028D64 CB_COLOR4_ATTRIB >> +0x00028D68 CB_COLOR4_DIM >> +0x00028D6C CB_COLOR4_CMASK >> +0x00028D70 CB_COLOR4_CMAKS_SLICE >> +0x00028D74 CB_COLOR4_FMASK >> +0x00028D78 CB_COLOR4_FMASK_SLICE >> 0x00028D7C CB_COLOR4_CLEAR_WORD0 >> 0x00028D80 CB_COLOR4_CLEAR_WORD1 >> 0x00028D84 CB_COLOR4_CLEAR_WORD2 >> 0x00028D88 CB_COLOR4_CLEAR_WORD3 >> +0x00028D9C CB_COLOR5_INFO >> +0x00028DA0 CB_COLOR5_ATTRIB >> +0x00028DA4 CB_COLOR5_DIM >> +0x00028DA8 CB_COLOR5_CMASK >> +0x00028DAC CB_COLOR5_CMAKS_SLICE >> +0x00028DB0 CB_COLOR5_FMASK >> +0x00028DB4 CB_COLOR5_FMASK_SLICE >> 0x00028DB8 CB_COLOR5_CLEAR_WORD0 >> 0x00028DBC CB_COLOR5_CLEAR_WORD1 >> 0x00028DC0 CB_COLOR5_CLEAR_WORD2 >> 0x00028DC4 CB_COLOR5_CLEAR_WORD3 >> +0x00028DD8 CB_COLOR6_INFO >> +0x00028DDC CB_COLOR6_ATTRIB >> +0x00028DE0 CB_COLOR6_DIM >> +0x00028DE4 CB_COLOR6_CMASK >> +0x00028DE8 CB_COLOR6_CMAKS_SLICE >> +0x00028DEC CB_COLOR6_FMASK >> +0x00028DF0 CB_COLOR6_FMASK_SLICE >> 0x00028DF4 CB_COLOR6_CLEAR_WORD0 >> 0x00028DF8 CB_COLOR6_CLEAR_WORD1 >> 0x00028DFC CB_COLOR6_CLEAR_WORD2 >> 0x00028E00 CB_COLOR6_CLEAR_WORD3 >> +0x00028E14 CB_COLOR7_INFO >> +0x00028E18 CB_COLOR7_ATTRIB >> +0x00028E1C CB_COLOR7_DIM >> +0x00028E20 CB_COLOR7_CMASK >> +0x00028E24 CB_COLOR7_CMAKS_SLICE >> +0x00028E28 CB_COLOR7_FMASK >> +0x00028E2C CB_COLOR7_FMASK_SLICE >> 0x00028E30 CB_COLOR7_CLEAR_WORD0 >> 0x00028E34 CB_COLOR7_CLEAR_WORD1 >> 0x00028E38 CB_COLOR7_CLEAR_WORD2 >> 0x00028E3C CB_COLOR7_CLEAR_WORD3 >> +0x00028E50 CB_COLOR8_INFO >> +0x00028E54 CB_COLOR8_ATTRIB >> +0x00028E58 CB_COLOR8_DIM >> +0x00028E6C CB_COLOR9_INFO >> +0x00028E70 CB_COLOR9_ATTRIB >> +0x00028E74 CB_COLOR9_DIM >> +0x00028E88 CB_COLOR10_INFO >> +0x00028E8C CB_COLOR10_ATTRIB >> +0x00028E90 CB_COLOR10_DIM >> +0x00028EA4 CB_COLOR11_INFO >> +0x00028EA8 CB_COLOR11_ATTRIB >> +0x00028EAC CB_COLOR11_DIM >> 0x00028F80 SQ_ALU_CONST_BUFFER_SIZE_HS_0 >> 0x00028F84 SQ_ALU_CONST_BUFFER_SIZE_HS_1 >> 0x00028F88 SQ_ALU_CONST_BUFFER_SIZE_HS_2 >> -- >> 1.8.4.2 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-dev
[PATCH v3 13/32] drm/exynos: hdmi: remove the i2c drivers and use devtree
On Fri, Nov 29, 2013 at 2:24 AM, Thierry Reding
wrote:
> On Thu, Nov 28, 2013 at 02:30:24PM +0100, Tomasz Figa wrote:
>> On Monday 11 of November 2013 09:44:27 Thierry Reding wrote:
>> > On Sun, Nov 10, 2013 at 09:46:02PM +0100, Tomasz Figa wrote:
>> > [...]
>> > > On Tuesday 29 of October 2013 12:12:59 Sean Paul wrote:
>> > [...]
>> > > [snip]
>> > > > @@ -1957,21 +1943,30 @@ static int hdmi_probe(struct platform_device
>> > > > *pdev)
>> > > > }
>> > > >
>> > > > /* DDC i2c driver */
>> > > > - if (i2c_add_driver(&ddc_driver)) {
>> > > > - DRM_ERROR("failed to register ddc i2c driver\n");
>> > > > - return -ENOENT;
>> > > > + ddc_node = of_find_node_by_name(NULL, "hdmiddc");
>> > >
>> > > This is wrong. You shall not reference a device tree node by its name,
>> > > except some very specific well-defined cases, such as cpus or memory
>> > > nodes.
>> > >
>> > > A solution closest to yours, but correct, would be to use the same match
>> > > table as in the I2C driver you are removing and call
>> > > of_find_matching_node().
>> >
>> > Isn't the correct solution to use a phandle? That might need the binding
>> > to change in a backwards incompatible way.
>>
>> Yes, phandle is an even better option as it can point you precisely to the
>> node you are interested in, but this will be incompatible, meaning that
>> you would have to support both variants anyway.
>
> Oh come on. If a phandle is the right way to do it, then we should just
> do it. Will it really be so difficult to carry code for both variants?
> If nothing else it will at least set a good example and reduce the risk
> of people doing the same mistakes over and over again.
>
> Adding the right binding also gives you a way to start deprecating the
> wrong one and eventually remove it. The longer you wait, the more people
> will start to use the existing, broken binding and removing it will only
> become more difficult over time.
>
>> > Then again, if something as
>> > simple as specifying a DDC I2C bus causes the binding to change in a
>> > backwards incompatible way then it can't have been a very good binding
>> > in the first place, right? +1 for unstable DT bindings...
>>
>> Well, some of already existing bindings should have been definitely marked
>> unstable, as they haven't been thought and reviewed well enough, if at all
>> (especially reviewed, as we only started seriously reviewing DT bindings
>> not so long ago).
>>
>> Honestly, I'm not quite sure about this binding in particular, especially
>> how much it would be a problem if we broke compatibility. I mean, how much
>> tied to old DTBs are existing boards using this binding. The affected
>> boards are:
>> - exynos5250-snow,
>> - exynos5250-arndale,
>> - exynos5250-smdk5250,
>> - exynos5420-smdk5420.
>> The last three are most likely to be used only with DTB appended, so
>> I don't think that anyone would complain. However I'm not sure about the
>> first one, which is supposed to be a Chromebook if I'm not mistaken.
>
> Well, if it's a Chromebook it likely doesn't ship with a completely
> mainline kernel. That frees it from the stability requirements, doesn't
> it?
Correct, there are absolutely no stability requirements between
mainline and the chromium.org kernel.
-Olof
[PATCH] drm: Don't reference objects in the flink name idr
There's no reason to keep a reference to objects in the name idr. Each
handle to an object has a reference to the object and just before we
destroy the last handle we take the object out of the name idr. Thus,
if an object is in the name idr, there's at least one reference to the
object.
Or to put it another way, the name idr reference will never keep the
object alive. It just looks like it, which is confusing.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/drm_gem.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4761ade..3ff39bb 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -175,11 +175,6 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj,
struct drm_file *filp)
mutex_unlock(&filp->prime.lock);
}
-static void drm_gem_object_ref_bug(struct kref *list_kref)
-{
- BUG();
-}
-
/**
* Called after the last handle to the object has been closed
*
@@ -195,13 +190,6 @@ static void drm_gem_object_handle_free(struct
drm_gem_object *obj)
if (obj->name) {
idr_remove(&dev->object_name_idr, obj->name);
obj->name = 0;
- /*
-* The object name held a reference to this object, drop
-* that now.
- *
- * This cannot be the last reference, since the handle holds one
too.
-*/
- kref_put(&obj->refcount, drm_gem_object_ref_bug);
}
}
@@ -602,9 +590,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
goto err;
obj->name = ret;
-
- /* Allocate a reference for the name table. */
- drm_gem_object_reference(obj);
}
args->name = (uint64_t) obj->name;
--
1.8.3.1
[PATCH 2/3] imx-drm: ipuv3-crtc: Make DISP_CLK polarity configurable
This patch makes the LCD display clock polarity configurable via DT so in case board needs different DISP_CLK clock polarity, it can use the 'pixelclk-active' DT prop to do such adjustment. Signed-off-by: Marek Vasut Cc: Dave Airlie Cc: Greg Kroah-Hartman Cc: Philipp Zabel Cc: Sascha Hauer Cc: Shawn Guo --- drivers/staging/imx-drm/ipuv3-crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c index ce6ba98..1d8223e 100644 --- a/drivers/staging/imx-drm/ipuv3-crtc.c +++ b/drivers/staging/imx-drm/ipuv3-crtc.c @@ -157,7 +157,7 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc, sig_cfg.Vsync_pol = 1; sig_cfg.enable_pol = 1; - sig_cfg.clk_pol = 1; + sig_cfg.clk_pol = !!(mode->flags & DRM_MODE_FLAG_PIXELCLK_NPOL); sig_cfg.width = mode->hdisplay; sig_cfg.height = mode->vdisplay; sig_cfg.pixel_fmt = out_pixel_fmt; -- 1.8.4.2
[PATCH 1/3] drm: Add LCD display clock polarity flags
Add DRM flags for the LCD display clock polarity so the pixelclk-active DT property can be properly handled by drivers using the DRM API. Signed-off-by: Marek Vasut Cc: Dave Airlie Cc: Greg Kroah-Hartman Cc: Philipp Zabel Cc: Sascha Hauer Cc: Shawn Guo --- drivers/gpu/drm/drm_modes.c | 5 + include/uapi/drm/drm_mode.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 85071a1..d1f3bfc 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -537,6 +537,11 @@ int drm_display_mode_from_videomode(const struct videomode *vm, dmode->flags |= DRM_MODE_FLAG_DBLSCAN; if (vm->flags & DISPLAY_FLAGS_DOUBLECLK) dmode->flags |= DRM_MODE_FLAG_DBLCLK; + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) + dmode->flags |= DRM_MODE_FLAG_PIXELCLK_PPOL; + else if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) + dmode->flags |= DRM_MODE_FLAG_PIXELCLK_NPOL; + drm_mode_set_name(dmode); return 0; diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index f104c26..a6169ca 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -73,6 +73,9 @@ #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14) #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14) +/* CRTC LCD clock polarity flags. */ +#define DRM_MODE_FLAG_PIXELCLK_PPOL(1<<19) +#define DRM_MODE_FLAG_PIXELCLK_NPOL(1<<20) /* DPMS flags */ /* bit compatible with the xorg definitions. */ -- 1.8.4.2
[PATCH 3/3] ARM: dts: imx53: Switch DISP_CLK polarity on M53EVK
Change the DISP_CLK line polarity on M53EVK to work correctly after the following commit: commit f0ac9bebf19001f38afbb93e2dc719a15dfb75e5 Author: Fabio Estevam Date: Tue Oct 29 19:42:22 2013 -0200 imx-drm: ipuv3-crtc: Invert IPU DI0 clock polarity Signed-off-by: Marek Vasut Cc: Dave Airlie Cc: Greg Kroah-Hartman Cc: Philipp Zabel Cc: Sascha Hauer Cc: Shawn Guo --- arch/arm/boot/dts/imx53-m53evk.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts index 84a2cdc..97ec9c7 100644 --- a/arch/arm/boot/dts/imx53-m53evk.dts +++ b/arch/arm/boot/dts/imx53-m53evk.dts @@ -41,6 +41,7 @@ vfront-porch = <9>; vsync-len = <3>; vsync-active = <1>; + pixelclk-active = <1>; }; }; }; -- 1.8.4.2
[PATCH 1/3] drm: Add LCD display clock polarity flags
On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote: > Add DRM flags for the LCD display clock polarity so the pixelclk-active DT > property can be properly handled by drivers using the DRM API. I still say that not even this should be part of the DRM mode API to userspace. The hint that you're changing the user API is that you're modifying a header file below a 'uapi' directory. The settings of double scan, sync polarity etc are all part of the display mode specification (check CEA-861 documents). Things like pixel clock polarity are not part of the mode specification, they're a property of the display itself and are independent of the mode. Therefore, they should not be part of struct drm_mode_modeinfo.
