[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 --- Comment #6 from Tom Stellard --- (In reply to sarnex from comment #5) > (In reply to Tom Stellard from comment #4) > > (In reply to sarnex from comment #0) > > > Hi guys. If I use LLVM git, I get these graphical glitches in Dota 2 > > > native. > > > > > > https://i.imgur.com/I4vyWFt.jpg > > > > > > The bug has been bisected to LLVM: > > > 51a3c27d6e0c66cc8d2d1da8e9205fec7b74ca5c > > > R600/SI: Define a schedule model and enable the generic machine scheduler > > > > > > > > > I'm using Mesa git, Kernel 3.18.5 and Linux Mint. > > > > > > Thanks alot, > > > > > > sarnex > > > > Can you run the game with the environment variable: > > R600_DEBUG=ps,vs,gs and post the output. > > Hi Tom, thanks for replying. > > The log is here, since it's too big to be an attachment. Skip to near the > end to see the in-game bugged time, the beginning is mostly the menu. > > Log: http://paste.ubuntu.com/10075950/ Thanks, would you also be able to get a dump using the last good commit. -- 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/20150209/ccd643d2/attachment.html>
[Bug 76223] [radeonsi] luxmark segfault
https://bugs.freedesktop.org/show_bug.cgi?id=76223 --- Comment #21 from Michel Dänzer --- (In reply to Vladimir Ysikov from comment #20) > I rebuild llvm-svn, mesa-git with debug symbols and get this: > > behem0th at ArchLinux ~ $ glxinfo > name of display: :0 > Error: couldn't find RGB GLX visual or fbconfig Looks like something went wrong when updating LLVM / Mesa. Please attach the corresponding Xorg.0.log file. -- 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/20150209/0169f904/attachment.html>
[Bug 76223] [radeonsi] luxmark segfault
https://bugs.freedesktop.org/show_bug.cgi?id=76223 --- Comment #22 from Vladimir Ysikov --- Created attachment 113266 --> https://bugs.freedesktop.org/attachment.cgi?id=113266&action=edit Xorg.0.log It happen after update llvm, not mesa. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150209/75d6e5ed/attachment-0001.html>
[Bug 89009] radeon: Failed to allocate a buffer
https://bugs.freedesktop.org/show_bug.cgi?id=89009 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Drivers/Gallium/r600 --- Comment #1 from Michel Dänzer --- Please attach the /var/log/Xorg.0.log file and the output of dmesg and glxinfo. -- 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/20150209/e06bf867/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 Bug ID: 89034 Summary: Firefox crashing xserver and some major rendering bugs Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: smoki00790 at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 113269 --> https://bugs.freedesktop.org/attachment.cgi?id=113269&action=edit valley_artifacts Well i put this as radeosi bug as i am not sure if happens elsewhere. It is LLVM bug actually which happens once subreg liveness is enabled, so svn 228228 is bisected as bad. I running current llvm with subreg liveness disabled, as this is major/grave one bug for me. Same issue was present in Tom's perf branches last month once subreg liveness is enabled too. Hardware is kabini (Athlon 5350), current Debian Sid 64bit, kernel 3.19.0, xserver git, mesa git, etc... Attached is screenshot from Unigine Valley for example, there are major rendering issues in many other GL apps. For Firefox crashing xserver not sure how to debug that (btw it crashed X immidiate at starting FF) , if i build llvm with debug and assertations screen/monitor somehow looks like it goes sleep mode (without any messages in logs) and only hard reset helps. If i build llvm without those it just crashing xserver, but there is not enough info in Xorg.0.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/20150209/6b66729e/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 smoki changed: What|Removed |Added Attachment #113269|text/plain |image/png mime type|| -- 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/20150209/ddf2b326/attachment.html>
[Bug 76223] [radeonsi] luxmark segfault
https://bugs.freedesktop.org/show_bug.cgi?id=76223 --- Comment #23 from Michel Dänzer --- > (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed > (libLLVM-3.5.so: cannot open shared object file: No such file or directory) Looks like the dynamic linker can't find libLLVM-3.5.so anymore. Did you run ldconfig after installing LLVM? -- 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/20150209/a10c4dae/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #1 from Michel Dänzer --- (In reply to smoki from comment #0) > Attached is screenshot from Unigine Valley for example, there are major > rendering issues in many other GL apps. Haven't seen such artifacts on Kaveri. Can you attach the stderr output of running Valley or another affected app with R600_DEBUG=vs,ps with and without the bisected commit? > For Firefox crashing xserver not sure how to debug that [...] Is there something about it in the Xorg stderr output? It should be captured in a gdm log file. -- 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/20150209/1272d1c7/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #2 from smoki --- Well i can but i need first to make a bottle of coffee because one llvm build takes 30 minutes on Kabini :D. but OK will do something... later... I don't have gdm.log as i don't use it, plain startx is used. I can only attach Xorg.0.log without debug build... but well, later... -- 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/20150209/e6b2fbd1/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #3 from Michel Dänzer --- (In reply to smoki from comment #2) > Well i can but i need first to make a bottle of coffee because one llvm > build takes 30 minutes on Kabini :D. It shouldn't take that long after switching between the bisected commit and the one before it (or just re-applying/reverting it on top of whatever later commit you may have built last). If you're not using ccache yet, that might help a little as well. > I don't have gdm.log as i don't use it, plain startx is used. Then something like startx [...] 2>stderr.txt should capture the stderr output in a file. -- 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/20150209/706647cc/attachment-0001.html>
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #29 from Arthur Marsh --- Created attachment 113270 --> https://bugs.freedesktop.org/attachment.cgi?id=113270&action=edit 20150209dmesg.txt didn't lock up on usual video but did on another with 3.19 kernel With the 3.19 kernel, I didn't get a lock-up with the usual test video but did eventually with another video. -- 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/20150209/aa276a83/attachment.html>
[Bug 88464] booting with radeon.test=1 with radeon3850hd and lockdep validation causes lock-up
https://bugs.freedesktop.org/show_bug.cgi?id=88464 --- Comment #7 from Arthur Marsh --- Created attachment 113271 --> https://bugs.freedesktop.org/attachment.cgi?id=113271&action=edit 2015020917dmesg.txt behaviour when booting with radeon.test=1 with 3.19 kernel and 3850hd I tried booting with the 3.19 kernel and radeon.test=1 and had to restart afterwards to restore video output. -- 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/20150209/b4dafb63/attachment.html>
[Bug 88464] booting with radeon.test=1 with radeon3850hd and lockdep validation causes lock-up
https://bugs.freedesktop.org/show_bug.cgi?id=88464 --- Comment #8 from Michel Dänzer --- Arthur, there's no need to keep posting the same information as long as the behaviour doesn't change. -- 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/20150209/a31f66d3/attachment.html>
[Bug 86720] [radeon] Europa Universalis 4 freezing during game start (10.3.3)
https://bugs.freedesktop.org/show_bug.cgi?id=86720 --- Comment #17 from Joti Papadopoulos --- I can confirm the patch fixes the issue here as well -- 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/20150209/755da4c3/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #4 from smoki --- Created attachment 113272 --> https://bugs.freedesktop.org/attachment.cgi?id=113272&action=edit xcrash Using wihout patched llvm to post this as i can't use proper llvm with browser to post this :D This is with debug llvm, but without asserts enabled likely there are assertation there holding something to not logging, but dunno anyway might be useful. -- 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/20150209/008d2873/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #5 from Michel Dänzer --- Please get a backtrace of the crash with gdb by attaching gdb to the Xorg process via ssh before starting Firefox. -- 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/20150209/f654632c/attachment.html>
[Bug 88364] Xorg hangs after videocard switching
https://bugs.freedesktop.org/show_bug.cgi?id=88364 --- Comment #7 from Liss --- Here is bisect output: 636e2582658742b94e7620becce58f939996c961 is the first bad commit commit 636e2582658742b94e7620becce58f939996c961 Author: Alex Deucher Date: Fri Jun 6 18:43:45 2014 -0400 drm/radeon/dpm: add support for SVI2 voltage for SI Some newer boards use SVI2 for voltage control rather than GPIO. Signed-off-by: Alex Deucher :04 04 53449e086e151c24e90607b713c9bd416c658b55 72d3d0491cabfd6921a038565d8eeaca34726d5f Mdrivers -- 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/20150209/b4a5c9b9/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #6 from smoki --- (In reply to Michel Dänzer from comment #3) > > Then something like > > startx [...] 2>stderr.txt > > should capture the stderr output in a file. Actually that one drop something, this is with debug+assertion enabled llvm when monitor just gooes to "sleep" after starting firefox... seems like usefull :) ? X: TargetRegisterInfo.cpp:189: virtual const llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getMatchingSuperRegClass(const llvm::TargetRegisterClass*, const llvm::TargetRegisterClass*, unsigned int) const: Assertion `A && B && "Missing register class"' failed. -- 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/20150209/fd13d2ab/attachment-0001.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #7 from Michel Dänzer --- Please get a gdb backtrace (bt full) for the assertion failure then. Bonus points for running Xorg with R600_DEBUG=vs,ps and grabbing its stderr output leading up to the assertion failure as well. -- 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/20150209/ae967aef/attachment.html>
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Driver/modesetting Assignee|dri-devel at lists.freedesktop |xorg-team at lists.x.org |.org| Product|Mesa|xorg QA Contact|dri-devel at lists.freedesktop |xorg-team at lists.x.org |.org| --- Comment #3 from Michel Dänzer --- Please attach the output of glxinfo from using the modesetting and radeon drivers. -- 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/20150209/52b54fe0/attachment.html>
[Bug 88968] Unit mouseover in World of Warcraft (wine, D3D) freezes up the entire system
https://bugs.freedesktop.org/show_bug.cgi?id=88968 --- Comment #3 from Michel Dänzer --- A web search for "git bisect howto" should get you started. -- 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/20150209/fac5ce83/attachment.html>
[Bug 89034] Firefox crashing xserver and some major rendering bugs
https://bugs.freedesktop.org/show_bug.cgi?id=89034 --- Comment #8 from smoki --- Well i think i can't do that, because i don't have another machine right now. -- 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/20150209/4ff7b82b/attachment.html>
[Bug 89009] radeon: Failed to allocate a buffer
https://bugs.freedesktop.org/show_bug.cgi?id=89009 --- Comment #2 from tsesmelistheodore at gmail.com --- Created attachment 113276 --> https://bugs.freedesktop.org/attachment.cgi?id=113276&action=edit dmesg output -- 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/20150209/90864e38/attachment.html>
[Bug 89009] radeon: Failed to allocate a buffer
https://bugs.freedesktop.org/show_bug.cgi?id=89009 --- Comment #3 from tsesmelistheodore at gmail.com --- Created attachment 113277 --> https://bugs.freedesktop.org/attachment.cgi?id=113277&action=edit glxinfo output -- 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/20150209/df0db857/attachment.html>
[Bug 89009] radeon: Failed to allocate a buffer
https://bugs.freedesktop.org/show_bug.cgi?id=89009 --- Comment #4 from tsesmelistheodore at gmail.com --- Created attachment 113278 --> https://bugs.freedesktop.org/attachment.cgi?id=113278&action=edit Xorg.0.log file -- 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/20150209/d5c41076/attachment.html>
[Bug 89009] radeon: Failed to allocate a buffer
https://bugs.freedesktop.org/show_bug.cgi?id=89009 --- Comment #5 from tsesmelistheodore at gmail.com --- I hope it helps. If you need something else please do not hesitate to contact me back. -- 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/20150209/451818f1/attachment-0001.html>
[GIT PULL] drm: sti: infoframe improvement
Hello Dave, Those patches improve audio info frame management, add pixel formats support and fix minor issues. The following changes since commit e4bf44b3b558742fb7c58b4d34e206c8942f07e6: drm/modes: Print the mode status in human readable form (2015-02-03 11:13:27 +1000) are available in the git repository at: http://git.linaro.org/people/benjamin.gaignard/kernel.git drm-sti-next-2015-02-04 for you to fetch changes up to cffe1e89dc9bf541a39d9287ced7c5addff07084: drm: sti: HDMI add audio infoframe (2015-02-05 16:21:19 +0100) Arnaud Pouliquen (1): drm: sti: HDMI add audio infoframe Benjamin Gaignard (1): drm: sti: add support of ABGR for gdp plane Fabien Dessenne (1): drm: sti: add support of XBGR for gdp plane Jassi Brar (1): drm: sti: fix check for clk_pix_main Vincent Abriou (1): drm: sti: fix static checker warning in sti_awg_utils drivers/gpu/drm/sti/sti_awg_utils.c | 2 - drivers/gpu/drm/sti/sti_gdp.c | 11 +++ drivers/gpu/drm/sti/sti_hdmi.c | 179 +++- drivers/gpu/drm/sti/sti_hqvdp.c | 2 +- 4 files changed, 149 insertions(+), 45 deletions(-) -- Benjamin Gaignard Graphic Working Group Linaro.org â Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine
https://bugs.freedesktop.org/show_bug.cgi?id=83800 darkbasic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from darkbasic --- Fixed in nine state tracker. Probably the crash still happens with old nine. -- 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/20150209/328e1db3/attachment.html>
[PATCH 1/4] drm/exynos: dsim: fix to control mipi phy register
On 07/02/15 12:53, Inki Dae wrote:
> This patch fixes the issue that the try to get a phy object is failed
> to enable mipi phy.
>
> System and power management unit registers should be controlled by
> syscon framework. So this patch removes existing phy framework based
> codes and adds syscon support instead. However, we should support
> legacy device tree binding so consider the legacy binding for compatibility.
>
> In addition, we need to remove below device node and relevant properties,
> mipi_phy: video-phy at 10020710 {
> compatible = "samsung,s5pv210-mipi-video-phy";
> reg = <0x10020710 8>;
> #phy-cells = <1>;
> };
>
> Now camera device node uses mipi_phy node relevant properties like below,
> camera {
> ...
> csis_0: csis at 1188 {
> ...
> phys = <&mipi_phy 0>;
> phy-names = "csis";
> ...
> };
> csis_1: csis at 1189 {
> ...
> phys = <&mipi_phy 2>;
> phy-names = "csis";
> ...
> };
> ...
> };
>
> With above, we will find below message while booting,
> can't request region for resource [mem 0x10020710-0x10020717]
I'm afraid this approach won't work because MIPI DSI Master and MIPI CSI
Slave devices share a control bit in the register and it seems impossible
to ensure proper locking with current regmap/syscon API.
I have submitted patches to fix this issue [1] and they should be already
available in linux-next and can be found on linux-samsung-soc ML:
[PATCH 1/2] phy: exynos-video-mipi: Fix regression by adding support for PMU
regmap
[PATCH 2/2] ARM: dts: Add syscon phandle to the video-phy node for Exynos4
The other issue with your approach is that we are moving the PMU details
to the MIPI DSIM driver and similar changes would need to be done in
the MIPI CSIS driver.
Instead I just added syscon support to the PHY layer, it's not perfect
but fixes the issue for both DSI and CSI and doesn't strip the PHY layer
which could potentially be useful.
--
Thanks,
Sylwester
[1] https://patchwork.ozlabs.org/patch/429948/
http://www.spinics.net/lists/linux-samsung-soc/msg41210.html
[PATCH 12/12] ARM: shmobile: koelsch: Add DU HDMI output support
On Sun, Feb 08, 2015 at 06:08:19PM +0200, Laurent Pinchart wrote:
> Hi Simon,
>
> On Friday 06 February 2015 09:58:43 Simon Horman wrote:
> > [CC Damian, Magnus]
> >
> > On Mon, Oct 27, 2014 at 02:12:56PM +0200, Laurent Pinchart wrote:
> > > On Monday 27 October 2014 09:38:29 Simon Horman wrote:
> > > > On Wed, Sep 24, 2014 at 11:04:32PM +0300, Laurent Pinchart wrote:
> > > >> Add DT nodes for the ADV7511 HDMI encoder and its HDMI output
> > > >> connector and configure the DISP pin group that drives the HDMI
> > > >> transmitter DE pin.
> > > >>
> > > >> Signed-off-by: Laurent Pinchart
> > > >>
> > > >
> > > > Acked-by: Simon Horman
> > > >
> > > > Please be careful of any conflicts that may arise if this patch
> > > > doesn't go through my renesas tree.
> > >
> > > I think it would be best if the patch went through your tree. There's no
> > > compile time or runtime dependency on the DU HDMI code, so as soon as the
> > > ADV7511 DT bindings get accepted I plan to ask you to merge this patch.
> >
> > Hi Laurent,
> >
> > I'd like to enquire about the status of this change as
> > Damian has asked me about it.
> >
> > It seems that I could pick this up for v3.21 as the bindings seem to be in
> > v3.19-rc1. But perhaps events have overtaken the discussion above which was
> > some months ago now.
>
> For Koelsch everything should be fine, you can pick the patch for v3.21.
>
> For Lager, there's an additional dependency on "drm: rcar-du: Don't fail
> probe
> in case of partial encoder init error" (to avoid regressions) and on "drm:
> rcar-du: Remove LVDS and HDMI encoders chaining restriction" (to make it work
> at all). Both are in Dave's drm-next branch and should land in v3.20-rc1. To
> avoid bisection breakages we would have to merge Dave's branch first.
Thanks, I have queued up the version of this patch which you posted
in December:
From: Laurent Pinchart
[PATCH] ARM: shmobile: koelsch: Add DU HDMI output support
Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector
and configure the DISP pin group that drives the HDMI transmitter DE
pin.
Signed-off-by: Laurent Pinchart
Acked-by: Simon Horman
Signed-off-by: Simon Horman
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 691e4c6..d2ea19f 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -258,6 +258,17 @@
system-clock-frequency = <11289600>;
};
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
};
&du {
@@ -266,6 +277,11 @@
status = "okay";
ports {
+ port at 0 {
+ endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
port at 1 {
lvds_connector: endpoint {
};
@@ -284,7 +300,7 @@
};
du_pins: du {
- renesas,groups = "du_rgb666", "du_sync", "du_clk_out_0";
+ renesas,groups = "du_rgb666", "du_sync", "du_disp",
"du_clk_out_0";
renesas,function = "du";
};
@@ -506,6 +522,38 @@
};
};
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+
eeprom at 50 {
compatible = "renesas,24c02";
reg = <0x50>;
--
2.1.4
[PATCH 1/4] drm/exynos: dsim: fix to control mipi phy register
On 2015ë
02ì 09ì¼ 19:57, Sylwester Nawrocki wrote:
> On 07/02/15 12:53, Inki Dae wrote:
>> This patch fixes the issue that the try to get a phy object is failed
>> to enable mipi phy.
>>
>> System and power management unit registers should be controlled by
>> syscon framework. So this patch removes existing phy framework based
>> codes and adds syscon support instead. However, we should support
>> legacy device tree binding so consider the legacy binding for compatibility.
>>
>> In addition, we need to remove below device node and relevant properties,
>> mipi_phy: video-phy at 10020710 {
>> compatible = "samsung,s5pv210-mipi-video-phy";
>> reg = <0x10020710 8>;
>> #phy-cells = <1>;
>> };
>>
>> Now camera device node uses mipi_phy node relevant properties like below,
>> camera {
>> ...
>> csis_0: csis at 1188 {
>> ...
>> phys = <&mipi_phy 0>;
>> phy-names = "csis";
>> ...
>> };
>> csis_1: csis at 1189 {
>> ...
>> phys = <&mipi_phy 2>;
>> phy-names = "csis";
>> ...
>> };
>> ...
>> };
>>
>> With above, we will find below message while booting,
>> can't request region for resource [mem 0x10020710-0x10020717]
>
> I'm afraid this approach won't work because MIPI DSI Master and MIPI CSI
> Slave devices share a control bit in the register and it seems impossible
> to ensure proper locking with current regmap/syscon API.
>
> I have submitted patches to fix this issue [1] and they should be already
> available in linux-next and can be found on linux-samsung-soc ML:
>
> [PATCH 1/2] phy: exynos-video-mipi: Fix regression by adding support for PMU
> regmap
> [PATCH 2/2] ARM: dts: Add syscon phandle to the video-phy node for Exynos4
>
> The other issue with your approach is that we are moving the PMU details
> to the MIPI DSIM driver and similar changes would need to be done in
> the MIPI CSIS driver.
>
> Instead I just added syscon support to the PHY layer, it's not perfect
> but fixes the issue for both DSI and CSI and doesn't strip the PHY layer
> which could potentially be useful.
Ah, Right. I didn't check your patch set. Your way is a better idea than
my one. With this, we don't need to change device drivers, MIPI DSI and CSI.
Then, what is the meaning that it's not perfect?
Thanks,
Inki Dae
>
[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine
https://bugs.freedesktop.org/show_bug.cgi?id=83800 darkbasic changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #16 from darkbasic --- Sorry guys, I forgot to enable nine in my previous test: it still hangs the whole system. -- 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/20150209/904453f7/attachment-0001.html>
[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine
https://bugs.freedesktop.org/show_bug.cgi?id=83800 --- Comment #17 from darkbasic --- By the way I already narrowed this issue down to the 3D engine with Christian Koenig, so no VM or DMA problem here. -- 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/20150209/d491a47e/attachment.html>
[PATCH 1/4] drm/exynos: dsim: fix to control mipi phy register
On 09/02/15 13:17, Inki Dae wrote: >> Instead I just added syscon support to the PHY layer, it's not perfect >> > but fixes the issue for both DSI and CSI and doesn't strip the PHY layer >> > which could potentially be useful. > > Ah, Right. I didn't check your patch set. Your way is a better idea than > my one. With this, we don't need to change device drivers, MIPI DSI and CSI. > > Then, what is the meaning that it's not perfect? What I didn't like is that there are at least 3 mutexes on the phy_power_on/ phy_power_off path (PHY core, PHY driver, regmap) and there is another level of indirection after introducing the regmap. I guess it's nothing serious though. And BTW the syscon could be converted to use spinlock rather than a mutex, since in our case behind the PMU syscon is always a memory mapped region. -- Regards, Sylwester
[patch] drm/nouveau/mmu: shift wrapping bug in gf100_vm_map()
Since "1" is an int, then it means we can't use the high bits of this
u64.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.c
index 294cda3..b10c90a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.c
@@ -106,7 +106,7 @@ static void
gf100_vm_map(struct nvkm_vma *vma, struct nvkm_gpuobj *pgt,
struct nvkm_mem *mem, u32 pte, u32 cnt, u64 phys, u64 delta)
{
- u64 next = 1 << (vma->node->type - 8);
+ u64 next = 1ULL << (vma->node->type - 8);
phys = gf100_vm_addr(vma, phys, mem->memtype, 0);
pte <<= 3;
[PATCH -v2 10/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
Hi,
I'm merging this patch series but I found two issues. One is already
pointed out.
On 2015ë
02ì 07ì¼ 04:37, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
> unprotect the windows before the commit and protects it after based on
> a plane mask tha store which plane will be updated.
>
> For that we create two new exynos_crtc callbacks: .win_protect() and
> .win_unprotect(). The only driver that implement those now is FIMD.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 34 +
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 49
> ---
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +++
> 4 files changed, 76 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 1c0d936..5e7c13e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -153,6 +153,38 @@ static void exynos_drm_crtc_disable(struct drm_crtc
> *crtc)
> }
> }
>
> +static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
> +{
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
> + int index = 0;
> +
> + list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
> + if (exynos_crtc->ops->win_protect &&
> + exynos_crtc->plane_mask & (0x01 << index))
> + exynos_crtc->ops->win_protect(exynos_crtc, index);
> +
> + index++;
> + }
> +}
> +
> +static void exynos_crtc_atomic_flush(struct drm_crtc *crtc)
> +{
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> + struct drm_plane *plane;
> + int index = 0;
> +
> + list_for_each_entry(plane, &crtc->dev->mode_config.plane_list, head) {
> + if (exynos_crtc->ops->win_unprotect &&
> + exynos_crtc->plane_mask & (0x01 << index))
> + exynos_crtc->ops->win_unprotect(exynos_crtc, index);
> +
> + index++;
> + }
> +
> + exynos_crtc->plane_mask = 0;
> +}
> +
> static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
> .dpms = exynos_drm_crtc_dpms,
> .prepare= exynos_drm_crtc_prepare,
> @@ -161,6 +193,8 @@ static struct drm_crtc_helper_funcs
> exynos_crtc_helper_funcs = {
> .mode_set = exynos_drm_crtc_mode_set,
> .mode_set_base = exynos_drm_crtc_mode_set_base,
> .disable= exynos_drm_crtc_disable,
> + .atomic_begin = exynos_crtc_atomic_begin,
> + .atomic_flush = exynos_crtc_atomic_flush,
> };
>
> static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index ab82772..f025a54 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -175,6 +175,8 @@ struct exynos_drm_display {
> * hardware overlay is updated.
> * @win_commit: apply hardware specific overlay data to registers.
> * @win_disable: disable hardware specific overlay.
> + * @win_protect: protect hardware specific window.
> + * @win_unprotect: unprotect hardware specific window.
> * @te_handler: trigger to transfer video image at the tearing effect
> * synchronization signal if there is a page flip request.
> */
> @@ -190,6 +192,8 @@ struct exynos_drm_crtc_ops {
> void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
> void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
> void (*win_disable)(struct exynos_drm_crtc *crtc, unsigned int zpos);
> + void (*win_protect)(struct exynos_drm_crtc *crtc, unsigned int zpos);
> + void (*win_unprotect)(struct exynos_drm_crtc *crtc, unsigned int zpos);
> void (*te_handler)(struct exynos_drm_crtc *crtc);
> };
>
> @@ -206,6 +210,7 @@ struct exynos_drm_crtc_ops {
> * we can refer to the crtc to current hardware interrupt occurred through
> * this pipe value.
> * @dpms: store the crtc dpms value
> + * @plane_mask: store planes to be updated on atomic modesetting
> * @event: vblank event that is currently queued for flip
> * @ops: pointer to callbacks for exynos drm specific functionality
> * @ctx: A pointer to the crtc's implementation specific context
> @@ -215,6 +220,7 @@ struct exynos_drm_crtc {
> enum exynos_drm_output_type type;
> unsigned intpipe;
> unsigned intdpms;
> + unsigned intplane_mask;
> wait_queue_head_t pending_flip_queue;
> struct drm_pending_vblank_event *event;
> struct exynos_drm_crtc_ops *ops;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/dr
[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 --- Comment #7 from sarnex --- (In reply to Tom Stellard from comment #6) > (In reply to sarnex from comment #5) > > (In reply to Tom Stellard from comment #4) > > > (In reply to sarnex from comment #0) > > > > Hi guys. If I use LLVM git, I get these graphical glitches in Dota 2 > > > > native. > > > > > > > > https://i.imgur.com/I4vyWFt.jpg > > > > > > > > The bug has been bisected to LLVM: > > > > 51a3c27d6e0c66cc8d2d1da8e9205fec7b74ca5c > > > > R600/SI: Define a schedule model and enable the generic machine > > > > scheduler > > > > > > > > > > > > I'm using Mesa git, Kernel 3.18.5 and Linux Mint. > > > > > > > > Thanks alot, > > > > > > > > sarnex > > > > > > Can you run the game with the environment variable: > > > R600_DEBUG=ps,vs,gs and post the output. > > > > Hi Tom, thanks for replying. > > > > The log is here, since it's too big to be an attachment. Skip to near the > > end to see the in-game bugged time, the beginning is mostly the menu. > > > > Log: http://paste.ubuntu.com/10075950/ > > Thanks, would you also be able to get a dump using the last good commit. Hi Tom, Here is the log from the commit directly before R600/SI: Define a schedule model and enable the generic machine scheduler, and it has no graphical issues Log: http://paste.ubuntu.com/10143733/ Thanks again, sarnex -- 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/20150209/f09a13ac/attachment-0001.html>
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #3 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 tuxoholic at hotmail.de changed: What|Removed |Added CC||tuxoholic at hotmail.de --- Comment #33 from tuxoholic at hotmail.de --- Hello Christian It took me a while to regather my bugzilla login info, so I'm not sure whether you pushed this fix into kernel-git already or still are awaiting feedback, anyway ... I'm quoting my testing results I wrote in the debian bugtracker (#770790): That small patch in attachment #163891 does indeed fix the screen flickering for me. I built three versions of radeon.ko against 3.16.7-ckt2 from debian/testing: 1) vanilla version: reproducible flickering, it's even easier to reproduce by quickly dragging a medium sized window around in circles 2) superseded version: (attachment #159331): no flickering, might contain a typo on line 1002, but I did not fix that one and it ran flawless for days 3) current version: (#attachment 163891): no flickering So to sum up: this small fix in #163891 is a blessing, I vote for pushing this if it hasn't happened already. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH -v2 10/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
Hi Inki, On 9 February 2015 at 14:53, Inki Dae wrote: > I'm merging this patch series but I found two issues. One is already > pointed out. Fantastic - thanks a lot for doing this! > On 2015ë 02ì 07ì¼ 04:37, Gustavo Padovan wrote: >> @@ -628,20 +638,6 @@ static void fimd_win_commit(struct exynos_drm_crtc >> *crtc, unsigned int win) >> return; >> } >> >> - /* >> - * SHADOWCON/PRTCON register is used for enabling timing. >> - * >> - * for example, once only width value of a register is set, >> - * if the dma is started then fimd hardware could malfunction so >> - * with protect window setting, the register fields with prefix '_F' >> - * wouldn't be updated at vsync also but updated once unprotect window >> - * is set. >> - */ >> - >> - /* protect windows */ >> - fimd_shadow_protect_win(ctx, win, true); > > You removed to protect shadow register updating at vsync so fimd > hardware could malfunction if setcrtc/page flip/setplane are requested > by userspace. Actually, when I run modetest repeatedly, I could see > overlay isn't rarely turned on. > > So how about calling win_protect/unprotect callbacks like below? If you > are ok, I can modify it and merge it. I think you are missing some details about atomic and the helpers. The helpers wrap _all_ legacy codepaths, e.g. SetCrtc, SetPlane, etc. All of these operations are intercepted by the code in drm_atomic_helper.c / drm_plane_helper.c code, and the legacy operations are turned into atomic operations. For the driver - there are no legacy operations. The atomic helpers guarantee that atomic_begin() will be called before the state is committed, and atomic_flush() will be called after the state is committed. Thus this change is completely safe. > This warning would mean a fb object leak and while I have a review, I > couldn't find why it causes the leak. I'm not really surprised; the fb refcounting in Exynos has long had quite a few issues. The refcounting is incredibly difficult to get right, and whilst atomic changes the order of operations a little, it also makes the semantics of fb/vblank refcounting much more consistent, so it should be much easier to fix than usual. > However, I'd like to merge this patch series this time and fix this > issue at RC for phase 3. Great, thankyou! Really very happy about this. :) Cheers, Daniel
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #34 from Alex Deucher --- Already upstream: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=72edd83cc9e5819ed1ee771519143d7594e059f0 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
https://bugzilla.kernel.org/show_bug.cgi?id=85421 --- Comment #27 from Hin-Tak Leung --- Created attachment 166191 --> https://bugzilla.kernel.org/attachment.cgi?id=166191&action=edit screen corruption just before suspend & GPU crash on resume See screenshot. I had been playing a few videos with mplayer -vo xv http://*.mp4 from the BBC web site, on and off; then I did some browsing and noticed a few firefox tabs are corrupted (as shown - only about 3 out of those are). I then checked and see some messages in dmesg: [14452.823499] radeon :00:01.0: GPU fault detected: 146 0x02050004 [14452.823512] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00015A90 [14452.823516] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0504 [14452.823521] VM fault (0x04, vmid 2) at page 88720, write from 'CB0' (0x43423000) (0) So I suspended anyway; and the GPU crashed on resume. I was able to switch to a vt to reboot safely (not always the case) - so if there is anything say, I can look while the GPU is still stuck, please left me know. Been on 10.4.3 since 29 Jan (just routine fedora upgrade) and never did have problem with 10.4.2 before that, so I guess 10.4.2/10.4.3 is at least as good as 10.2.9 + patch. kernel is 3.18.6-200.fc21.x86_64. oh! I rebooted from from 3.18.5-200.fc21 and libdrm-2.4.58-3.fc21.* -> 2.4.59-4.fc21.* So if the screen corruption or the lock-up a regression from 25 days of goodness under 10.4.2/10.4.3 (and perhaps even a month in you include 10.4.1), than either the kernel or libdrm might be it. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
https://bugzilla.kernel.org/show_bug.cgi?id=85421 --- Comment #28 from Hin-Tak Leung --- So a quick summary is that later 10.4.x (excluding 10.4.0, which locked up within first day) is about as stable as 10.2.9 + patch. None of 10.3.x tried was any good. I'll just continue with 10.4.x and upgrade as they are available, and hope not to report too often about further lock ups. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH -v2 10/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
2015-02-09 Daniel Stone : > Hi Inki, > > On 9 February 2015 at 14:53, Inki Dae wrote: > > I'm merging this patch series but I found two issues. One is already > > pointed out. > > Fantastic - thanks a lot for doing this! > > > On 2015ë 02ì 07ì¼ 04:37, Gustavo Padovan wrote: > >> @@ -628,20 +638,6 @@ static void fimd_win_commit(struct exynos_drm_crtc > >> *crtc, unsigned int win) > >> return; > >> } > >> > >> - /* > >> - * SHADOWCON/PRTCON register is used for enabling timing. > >> - * > >> - * for example, once only width value of a register is set, > >> - * if the dma is started then fimd hardware could malfunction so > >> - * with protect window setting, the register fields with prefix '_F' > >> - * wouldn't be updated at vsync also but updated once unprotect > >> window > >> - * is set. > >> - */ > >> - > >> - /* protect windows */ > >> - fimd_shadow_protect_win(ctx, win, true); > > > > You removed to protect shadow register updating at vsync so fimd > > hardware could malfunction if setcrtc/page flip/setplane are requested > > by userspace. Actually, when I run modetest repeatedly, I could see > > overlay isn't rarely turned on. > > > > So how about calling win_protect/unprotect callbacks like below? If you > > are ok, I can modify it and merge it. > > I think you are missing some details about atomic and the helpers. > > The helpers wrap _all_ legacy codepaths, e.g. SetCrtc, SetPlane, etc. > All of these operations are intercepted by the code in > drm_atomic_helper.c / drm_plane_helper.c code, and the legacy > operations are turned into atomic operations. For the driver - there > are no legacy operations. > > The atomic helpers guarantee that atomic_begin() will be called before > the state is committed, and atomic_flush() will be called after the > state is committed. Thus this change is completely safe. Exactly, when phase 3 is merged you won't see any of these issues. I have patches ready for most part of phase 3. Expect them soon in the mailing list. Gustavo
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #43 from José Suárez --- I would suggest updating to a llvm-3.6 enabled mesa (and even git llvm 3.7). I had suffered from this lockup bug but the game has been pretty stable lately. -- 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/20150209/2b00e3b9/attachment-0001.html>
[Bug 88877] Invisible Chrome windows on radeonsi with KWin compositing
https://bugs.freedesktop.org/show_bug.cgi?id=88877 darkbasic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from darkbasic --- I switched to the modesetting driver (xorg-server git) + page flipping patches: http://cgit.freedesktop.org/~kwg/xserver/commit/?h=pageflip&id=f60ed01813e8c479625c28ab530a0fa3d76c1196 http://cgit.freedesktop.org/~kwg/xserver/commit/?h=pageflip&id=885deeffc90548cc4a98def507522d422cc90a09 http://cgit.freedesktop.org/~kwg/xserver/commit/?h=pageflip&id=77c0d59d01fece39910ae593f7807e74ffe24583 http://cgit.freedesktop.org/~kwg/xserver/commit/?h=pageflip&id=25d5d2b1103be58bb2d549bf0e62d505377060f4 http://cgit.freedesktop.org/~kwg/xserver/commit/?h=pageflip&id=f3c10666df33650da1e772994b087825774671ee ~ # cat /usr/share/X11/xorg.conf.d/99-modesetting.conf Section "Device" Identifier "radeon" Driver "modesetting" EndSection ~ $ ./dri3info Connected to DRI3 on display ':0', using fd 4: matches /dev/dri/card1 Also in the meantime I moved to Plasma 5 git so I can't reproduce the original xf86-video-ati bug anymore, that's why I'm closing this issue. -- 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/20150209/d2857f7f/attachment.html>
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #4 from georg at schorsch-tech.de --- Hello Alex, this is my bisect result: git bisect bad 01ac8794a77192236a4b91c33adf4177ac5a21f0 is the first bad commit commit 01ac8794a77192236a4b91c33adf4177ac5a21f0 Author: Alex Deucher Date: Wed Dec 18 19:11:27 2013 -0500 drm/radeon: re-order firmware loading in preparation for dpm rework We need to reorder the driver init sequence to better accomodate dpm which needs to be loaded earlier in the init sequence. Move fw init up so that it's available for dpm init. Signed-off-by: Alex Deucher :04 04 eba931a20e6dbe63d4b24e7e0fce83a8ac24d327 4e0bc09de082e88d43615b492b3a9433f99148f5 Mdrivers I added my bisect log. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #5 from georg at schorsch-tech.de --- Created attachment 166201 --> https://bugzilla.kernel.org/attachment.cgi?id=166201&action=edit bisect log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #6 from georg at schorsch-tech.de --- I know this is a commit not on the RT Tree. I have done this bisecting with the evergreen card. 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 5770] [1002:68b8] As config i always used the 3.14.20-rt17 config for oldconfig source. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/5] drm/i915: Add tiled framebuffer modifiers
From: Tvrtko Ursulin To be used from the new addfb2 extension. v2: - Drop Intel-specific untiled modfier. - Move to drm_fourcc.h. - Document layouts a bit and denote them as platform-specific and not useable for cross-driver sharing. - Add Y-tiling for completeness. - Drop special docstring markers to avoid confusing kerneldoc. Signed-off-by: Tvrtko Ursulin Cc: Tvrtko Ursulin Signed-off-by: Daniel Vetter (v2) --- drivers/gpu/drm/i915/i915_drv.h | 1 + include/uapi/drm/drm_fourcc.h | 31 +++ 2 files changed, 32 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 217845951b7f..a027a983c82b 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -31,6 +31,7 @@ #define _I915_DRV_H_ #include +#include #include "i915_reg.h" #include "intel_bios.h" diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 622109677747..886814c6f9d2 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -164,4 +164,35 @@ * authoritative source for all of these. */ +/* Intel framebuffer modifiers */ + +/* + * Intel X-tiling layout + * + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb) + * in row-major layout. Within the tile bytes are laid out row-major, with + * a platform-dependent stride. On top of that the memory can apply + * platform-depending swizzling of some higher address bits into bit6. + * + * This format is highly platforms specific and not useful for cross-driver + * sharing. It exists since on a given platform it does uniquely identify the + * layout in a simple way for i915-specific userspace. + */ +#define I915_FORMAT_MOD_X_TILEDfourcc_mod_code(INTEL, 1) + +/* + * Intel Y-tiling layout + * + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb) + * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes) + * chunks column-major, with a platform-dependent height. On top of that the + * memory can apply platform-depending swizzling of some higher address bits + * into bit6. + * + * This format is highly platforms specific and not useful for cross-driver + * sharing. It exists since on a given platform it does uniquely identify the + * layout in a simple way for i915-specific userspace. + */ +#define I915_FORMAT_MOD_Y_TILEDfourcc_mod_code(INTEL, 1) + #endif /* DRM_FOURCC_H */ -- 2.1.4
[PATCH 2/5] drm/i915: Add fb format modifier support
Currently we don't support anything but X tiled. And for an easier
transition it makes a lot of sense to just keep requiring that X tiled
is properly fenced.
Which means we need to do absolutely nothing in old code to support fb
modifiers, yay!
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3fe95982be93..2d69cce03ab5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12707,7 +12707,20 @@ static int intel_framebuffer_init(struct drm_device
*dev,
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
- if (obj->tiling_mode == I915_TILING_Y) {
+ if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
+ /* Enforce that fb modifier and tiling mode match, but only for
+* X-tiled. */
+ if (!!(obj->tiling_mode == I915_TILING_X) !=
+ !!(mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED)) {
+ DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
+ return -EINVAL;
+ }
+ } else {
+ if (obj->tiling_mode == I915_TILING_X)
+ mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
+ }
+
+ if (mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED) {
DRM_DEBUG("hardware does not support tiling Y\n");
return -EINVAL;
}
@@ -12721,12 +12734,12 @@ static int intel_framebuffer_init(struct drm_device
*dev,
if (INTEL_INFO(dev)->gen >= 5 && !IS_VALLEYVIEW(dev)) {
pitch_limit = 32*1024;
} else if (INTEL_INFO(dev)->gen >= 4) {
- if (obj->tiling_mode)
+ if (mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED)
pitch_limit = 16*1024;
else
pitch_limit = 32*1024;
} else if (INTEL_INFO(dev)->gen >= 3) {
- if (obj->tiling_mode)
+ if (mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED)
pitch_limit = 8*1024;
else
pitch_limit = 16*1024;
@@ -12736,12 +12749,13 @@ static int intel_framebuffer_init(struct drm_device
*dev,
if (mode_cmd->pitches[0] > pitch_limit) {
DRM_DEBUG("%s pitch (%d) must be at less than %d\n",
- obj->tiling_mode ? "tiled" : "linear",
+ mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED ?
+ "tiled" : "linear",
mode_cmd->pitches[0], pitch_limit);
return -EINVAL;
}
- if (obj->tiling_mode != I915_TILING_NONE &&
+ if (mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED &&
mode_cmd->pitches[0] != obj->stride) {
DRM_DEBUG("pitch (%d) must match tiling stride (%d)\n",
mode_cmd->pitches[0], obj->stride);
--
2.1.4
[PATCH 0/5] i915 fb modifier support, respun
Hi all, So this is the very quickly spun together version for my take on fb modifiers. Aim is to reduce the churn a bit with: - Only validate fb modifiers and old tiling_mode behaviour in framebuffer_init to ensure they are consistent. Don't convert over all the code for old platforms. - Guarantee that X-tiling always implies that the underlying bo is fenced with X-tiling mode, too. Otherwise the implications into existing code (e.g. adjusting fbc) are a bit too much. - One draft patch to show how I think we should us fb modifiers: Directly switch on them like we do with obj->tiling_mode, no need to have remap/masking functions around. At least for now. This isn't complete since some of the shared code, specifically the fb_align stuff used by framebuffer_init and the fbdev emulation code still uses obj->tiling_mode. That needs to be converted into a function which takes u64 fb modifers (for shared code) and the old code retained in an i9xx_ variant (for the plane_config readout code for old platforms). Then we can add the skl+ stuff in another version, together with a if/else. And then framebuffer_init obvsiouly needs to be extended. Commments highly welcome. Cheers, Daniel Daniel Vetter (3): drm/i915: Add fb format modifier support drm/i915: Use fb format modifiers in skylake_update_primary_plane drm: Also check unused fields for addfb2 Tvrtko Ursulin (2): drm/i915: Add tiled framebuffer modifiers drm/i915: Announce support for framebuffer modifiers drivers/gpu/drm/drm_crtc.c | 17 + drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_display.c | 32 include/uapi/drm/drm_fourcc.h| 31 +++ 4 files changed, 73 insertions(+), 8 deletions(-) -- 2.1.4
[PATCH 3/5] drm/i915: Use fb format modifiers in skylake_update_primary_plane
Just a little demo really. We probably need to introduce skl specific
functions for a lot of the format validation stuff, or at least
helpers. Specifically I think intel_framebuffer_init and
intel_fb_align_height must be adjusted to have an i915_ and a skl_
variant. And only shared code should be converted to fb modifiers,
platform code (like the plane config readout can keep on using old
tiling_mode defines to avoid some churn).
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2d69cce03ab5..41b3ddc4068d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2773,11 +2773,11 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
* The stride is either expressed as a multiple of 64 bytes chunks for
* linear buffers or in number of tiles for tiled buffers.
*/
- switch (obj->tiling_mode) {
- case I915_TILING_NONE:
+ switch (fb->modifier[0]) {
+ case DRM_FORMAT_MOD_NONE:
stride = fb->pitches[0] >> 6;
break;
- case I915_TILING_X:
+ case I915_FORMAT_MOD_X_TILED:
plane_ctl |= PLANE_CTL_TILED_X;
stride = fb->pitches[0] >> 9;
break;
--
2.1.4
[PATCH 4/5] drm/i915: Announce support for framebuffer modifiers
From: Tvrtko Ursulin Let the DRM core know we can handle it. v2: Change to boolean true. (Daniel Vetter) Signed-off-by: Tvrtko Ursulin Signed-off-by: Daniel Vetter --- 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 41b3ddc4068d..e96d0c75f89c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13214,6 +13214,8 @@ void intel_modeset_init(struct drm_device *dev) dev->mode_config.preferred_depth = 24; dev->mode_config.prefer_shadow = 1; + dev->mode_config.allow_fb_modifiers = true; + dev->mode_config.funcs = &intel_mode_funcs; intel_init_quirks(dev); -- 2.1.4
[PATCH 5/5] drm: Also check unused fields for addfb2
Just the usual paranoia ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b15d720eda4c..a12d7e8a0ca0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3322,6 +3322,23 @@ static int framebuffer_check(const struct
drm_mode_fb_cmd2 *r)
}
}
+ for (; i < 4; i++) {
+ if (r->handles[i]) {
+ DRM_DEBUG_KMS("buffer object handle for unused plane
%d\n", i);
+ return -EINVAL;
+ }
+
+ if (r->pitches[i] || r->offsets[i]) {
+ DRM_DEBUG_KMS("buffer pitch/offset for unused plane",
i);
+ return -EINVAL;
+ }
+
+ if (r->modifier[i]) {
+ DRM_DEBUG_KMS("fb modifer for unused plane", i);
+ return -EINVAL;
+ }
+ }
+
return 0;
}
--
2.1.4
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #7 from georg at schorsch-tech.de --- Created attachment 166211 --> https://bugzilla.kernel.org/attachment.cgi?id=166211&action=edit the config used as the bisect ended -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89045] [HAWAII,REGRESSION] X crash on KDE session initialisation
0x7f4212b0bb45] > [ 464.858] (EE) 36: /usr/bin/X (0x7f4214df5000+0x4619e) [0x7f4214e3b19e] > [ 464.858] (EE) > [ 464.858] (EE) Segmentation fault at address 0x18 > [ 464.858] (EE) > Fatal server error: > [ 464.858] (EE) Caught signal 11 (Segmentation fault). Server aborting Nothing turns up in dmesg. This is a *regression* over my previous configuration (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/661c8bb220 libdrm: Git:master/libdrm-2.4.59 LLVM: SVN:trunk/r228127 (3.7 devel) X.Org: Git:master/6672606420 Linux: 3.19.0 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> > 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin libclc: Git:master/d73f33b736 DDX: Git:master/c9f8f642fd I guess you want a bisect run, right? If so, could you advise me, which part I should check first: LLVM or Mesa? Or maybe you have a culprit in mind right away? Let me know, what you need. -- 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/20150209/bf87617e/attachment-0001.html>
[Bug 89045] [HAWAII,REGRESSION] X crash on KDE session initialisation
https://bugs.freedesktop.org/show_bug.cgi?id=89045 --- Comment #1 from Chernovsky Oleg --- May it be related to https://bugs.freedesktop.org/show_bug.cgi?id=88556 ? If so, I think it's a LLVM regression since GLSL stuff is handled there -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150209/7cbd3bf7/attachment.html>
[Bug 89045] [HAWAII,REGRESSION] X crash on KDE session initialisation
https://bugs.freedesktop.org/show_bug.cgi?id=89045 --- Comment #2 from Kai --- (In reply to Chernovsky Oleg from comment #1) > May it be related to https://bugs.freedesktop.org/show_bug.cgi?id=88556 ? > > If so, I think it's a LLVM regression since GLSL stuff is handled there Possible but I doubt it: bug 88556 was reported on 2015-01-18. My last working build is from 2015-02-04 (with Mesa and LLVM versions from that day). And as I'm on KDE 4.x I'm not using Plasma shell 5. -- 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/20150209/08604829/attachment.html>
[PATCH v2] drm: atmel-hlcdc: Atomic mode-setting conversion
Hu Sylvain, On Mon, 9 Feb 2015 19:26:06 +0100 Sylvain Rochet wrote: > Hello Boris, > > On Fri, Feb 06, 2015 at 04:22:23PM +0100, Boris Brezillon wrote: > > Convert the HLCDC driver to atomic mode-setting. > > > > Signed-off-by: Boris Brezillon > > --- > > I am getting the following trace with this patch applied, which seems > pretty straightforward to fix. Yep, I thought DRM core was already checking the previous state before calling the disable/enable callbacks, but it doesn't. I'll add a field to store the previous state and check it before doing any operation. Thanks for pointing this out. Regards, Boris > > Apart from that, it works perfectly, you can add my: > > Tested-by: Sylvain Rochet > > > > [ cut here ] > WARNING: CPU: 0 PID: 9 at drivers/clk/clk.c:992 clk_disable+0x28/0x34() > Modules linked in: > CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 3.19.0-rc7-next-20150204+ #90 > Hardware name: Atmel SAMA5 (Device Tree) > Workqueue: events output_poll_execute > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (warn_slowpath_common+0x84/0xb0) > [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > [] (warn_slowpath_null) from [] (clk_disable+0x28/0x34) > [] (clk_disable) from [] > (atmel_hlcdc_crtc_disable+0xe8/0x114) > [] (atmel_hlcdc_crtc_disable) from [] > (__drm_helper_disable_unused_functions+0xa4/0xd8) > [] (__drm_helper_disable_unused_functions) from [] > (drm_helper_disable_unused_functions+0x14/0x20) > [] (drm_helper_disable_unused_functions) from [] > (drm_fbdev_cma_init+0x78/0xfc) > [] (drm_fbdev_cma_init) from [] > (atmel_hlcdc_fb_output_poll_changed+0x30/0x40) > [] (atmel_hlcdc_fb_output_poll_changed) from [] > (output_poll_execute+0x148/0x188) > [] (output_poll_execute) from [] > (process_one_work+0xfc/0x310) > [] (process_one_work) from [] (worker_thread+0x60/0x478) > [] (worker_thread) from [] (kthread+0xd4/0xec) > [] (kthread) from [] (ret_from_fork+0x14/0x34) > ---[ end trace 9500ebf8d7076b60 ]--- > [ cut here ] > WARNING: CPU: 0 PID: 9 at drivers/clk/clk.c:898 clk_unprepare+0x24/0x2c() > Modules linked in: > CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: GW > 3.19.0-rc7-next-20150204+ #90 > Hardware name: Atmel SAMA5 (Device Tree) > Workqueue: events output_poll_execute > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (warn_slowpath_common+0x84/0xb0) > [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > [] (warn_slowpath_null) from [] (clk_unprepare+0x24/0x2c) > [] (clk_unprepare) from [] > (atmel_hlcdc_crtc_disable+0xf0/0x114) > [] (atmel_hlcdc_crtc_disable) from [] > (__drm_helper_disable_unused_functions+0xa4/0xd8) > [] (__drm_helper_disable_unused_functions) from [] > (drm_helper_disable_unused_functions+0x14/0x20) > [] (drm_helper_disable_unused_functions) from [] > (drm_fbdev_cma_init+0x78/0xfc) > [] (drm_fbdev_cma_init) from [] > (atmel_hlcdc_fb_output_poll_changed+0x30/0x40) > [] (atmel_hlcdc_fb_output_poll_changed) from [] > (output_poll_execute+0x148/0x188) > [] (output_poll_execute) from [] > (process_one_work+0xfc/0x310) > [] (process_one_work) from [] (worker_thread+0x60/0x478) > [] (worker_thread) from [] (kthread+0xd4/0xec) > [] (kthread) from [] (ret_from_fork+0x14/0x34) > ---[ end trace 9500ebf8d7076b61 ]--- > > > Sylvain -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #8 from georg at schorsch-tech.de --- After the current bisect result did not satisfy me, i tried various other RT kernels prior the 3.13 result from the bisect with the evergreen card. Between 3.12.15-rt25 and 3.10.20-rt17 i have no rt tags in my tree. I know that both cards run with 3.18.5 (non rt). So i tried a manual search in the tree, i tried "non-rt" and "rt" versions out of my tree with the evergreen card. 3.12.37-rt51 : bad 3.12.15-rt25 : bad 3.10.20-rt17 : good 3.10.67-rt71 : good 3.11.0 : good 3.12.0 : good 3.12.15: bad 3.13.0 : good -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #9 from georg at schorsch-tech.de --- Now plug the PITCAIRN card into the pc again. I tried the saved kernels from avouve. There i discouvered, that the machine is not hanging itself, it is just the display which hangs. The display connected to the DVI-0 and DVI-1 port dont update anymore. I could ssh into the machine. Even the RT kernels did respond The results with the PITCAIRN card: 3.12.37-rt51 : No image 3.12.15-rt25 : No image 3.10.20-rt17 : No image 3.10.67-rt71 : No image 3.11.0 : No image 3.12.0 : No image 3.12.15: No image 3.13.0 : No image -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #10 from Alex Deucher --- Does disabling dpm help? Append radeon.dpm=0 to the kernel command line in grub. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 92891] Maschine hangs forever at loading the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=92891 --- Comment #11 from Alex Deucher --- Please attach your dmesg output and a copy of your vbios. To get a copy of your vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 93001] New: modprobe radeon dpm=0 and starting Xorg sometimes logs "general protection fault" and no output
https://bugzilla.kernel.org/show_bug.cgi?id=93001 Bug ID: 93001 Summary: modprobe radeon dpm=0 and starting Xorg sometimes logs "general protection fault" and no output Product: Drivers Version: 2.5 Kernel Version: 3.18.6 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: jackfritt at boh.de Regression: No I need to blacklist the radeon module in debian. Loading of radeon only works with modprobe radeon dpm=0 on the console, autoloading with kernel command line will crash kernel and needs powercycle. I have to power on my Monitor before kernel load, not module load! If i try to power on my Monitor after kernel load, I never get an output. Even when I try to load radeon module. I have the problems since 3.18, before this I used 3.12 kernels without these Problems. Can I give more info? lspci -s 01:00.0 -v 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Device e157 Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at f7cc (64-bit, non-prefetchable) [size=128K] I/O ports at d000 [size=256] Expansion ROM at f7ca [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon modprobe radeon dpm=0 syslog: Feb 9 19:49:28 vdr kernel: [ 72.811025] [drm] Initialized drm 1.1.0 20060810 Feb 9 19:49:29 vdr kernel: [ 72.985256] [drm] radeon kernel modesetting enabled. Feb 9 19:49:29 vdr kernel: [ 72.985685] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x174B:0xE157). Feb 9 19:49:29 vdr kernel: [ 72.985744] [drm] register mmio base: 0xF7CC Feb 9 19:49:29 vdr kernel: [ 72.985779] [drm] register mmio size: 131072 Feb 9 19:49:29 vdr kernel: [ 72.985842] ATOM BIOS: CEDAR Feb 9 19:49:29 vdr kernel: [ 72.985936] radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M used) Feb 9 19:49:29 vdr kernel: [ 72.985979] radeon :01:00.0: GTT: 1024M 0x2000 - 0x5FFF Feb 9 19:49:29 vdr kernel: [ 72.986019] [drm] Detected VRAM RAM=512M, BAR=256M Feb 9 19:49:29 vdr kernel: [ 72.986055] [drm] RAM width 64bits DDR Feb 9 19:49:29 vdr kernel: [ 72.986192] [TTM] Zone kernel: Available graphics memory: 4092590 kiB Feb 9 19:49:29 vdr kernel: [ 72.986238] [TTM] Zone dma32: Available graphics memory: 2097152 kiB Feb 9 19:49:29 vdr kernel: [ 72.986285] [TTM] Initializing pool allocator Feb 9 19:49:29 vdr kernel: [ 72.986323] [TTM] Initializing DMA pool allocator Feb 9 19:49:29 vdr kernel: [ 72.986374] [drm] radeon: 512M of VRAM memory ready Feb 9 19:49:29 vdr kernel: [ 72.986412] [drm] radeon: 1024M of GTT memory ready. Feb 9 19:49:29 vdr kernel: [ 72.986459] [drm] Loading CEDAR Microcode Feb 9 19:49:29 vdr kernel: [ 73.036364] [drm] Internal thermal controller with fan control Feb 9 19:49:29 vdr kernel: [ 73.036483] [drm] radeon: power management initialized Feb 9 19:49:29 vdr kernel: [ 73.078603] [drm] GART: num cpu pages 262144, num gpu pages 262144 Feb 9 19:49:29 vdr kernel: [ 73.080385] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 Feb 9 19:49:29 vdr kernel: [ 73.086702] [drm] PCIE GART of 1024M enabled (table at 0x0025E000). Feb 9 19:49:29 vdr kernel: [ 73.086871] radeon :01:00.0: WB enabled Feb 9 19:49:29 vdr kernel: [ 73.086915] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x8800c94e2c00 Feb 9 19:49:29 vdr kernel: [ 73.086979] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x8800c94e2c0c Feb 9 19:49:29 vdr kernel: [ 73.089987] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc90005b1c418 Feb 9 19:49:29 vdr kernel: [ 73.090135] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Feb 9 19:49:29 vdr kernel: [ 73.090188] [drm] Driver supports precise vblank timestamp query. Feb 9 19:49:29 vdr kernel: [ 73.090239] radeon :01:00.0: radeon: MSI limited to 32-bit Feb 9 19:49:29 vdr kernel: [ 73.090299] radeon :01:00.0: irq 33 for MSI/MSI-X Feb 9 19:49:29 vdr kernel: [ 73.090309] radeon :01:00.0: radeon: using MSI. Feb
[libdrm][PATCH 1/2] random: Use unsigned long for seed
This is more consistent with the rest, and avoids potential undefined
behavior (signed overflow) in drmRandom()
Signed-off-by: Jan Vesely
---
xf86drmRandom.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xf86drmRandom.c b/xf86drmRandom.c
index ecab9e2..a084b86 100644
--- a/xf86drmRandom.c
+++ b/xf86drmRandom.c
@@ -98,7 +98,7 @@ typedef struct RandomState {
unsigned long q; /* m div a */
unsigned long r; /* m mod a */
unsigned long check;
-long seed;
+unsigned long seed;
} RandomState;
#if RANDOM_MAIN
@@ -147,13 +147,13 @@ int drmRandomDestroy(void *state)
unsigned long drmRandom(void *state)
{
RandomState *s = (RandomState *)state;
-long hi;
-long lo;
+unsigned long hi;
+unsigned long lo;
hi = s->seed / s->q;
lo = s->seed % s->q;
s->seed = s->a * lo - s->r * hi;
-if (s->seed <= 0) s->seed += s->m;
+if ((s->a * lo) <= (s->r * hi)) s->seed += s->m;
return s->seed;
}
@@ -166,7 +166,7 @@ double drmRandomDouble(void *state)
}
#if RANDOM_MAIN
-static void check_period(long seed)
+static void check_period(unsigned long seed)
{
unsigned long count = 0;
unsigned long initial;
@@ -178,7 +178,7 @@ static void check_period(long seed)
while (initial != drmRandom(state)) {
if (!++count) break;
}
-printf("With seed of %10ld, period = %10lu (0x%08lx)\n",
+printf("With seed of %10lu, period = %10lu (0x%08lx)\n",
seed, count, count);
drmRandomDestroy(state);
}
@@ -195,7 +195,7 @@ int main(void)
}
printf("After 1 iterations: %lu (%lu expected): %s\n",
rand, state->check,
- rand - state->check ? "*INCORRECT*" : "CORRECT");
+ rand != state->check ? "*INCORRECT*" : "CORRECT");
drmRandomDestroy(state);
printf("Checking periods...\n");
--
2.1.0
[libdrm][PATCH 2/2] Fix gcc -Wextra warnings
Signed-off-by: Jan Vesely
---
tests/vbltest/vbltest.c | 3 ++-
xf86drm.c | 4 ++--
xf86drmMode.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index cdc1ef6..6e13c57 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -104,7 +104,8 @@ static void usage(char *name)
int main(int argc, char **argv)
{
- int i, c, fd, ret;
+ unsigned i;
+ int c, fd, ret;
char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos",
"omapdrm", "tilcdc", "msm", "tegra" };
drmVBlank vbl;
drmEventContext evctx;
diff --git a/xf86drm.c b/xf86drm.c
index 345325a..fb673b5 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -303,7 +303,7 @@ static int chown_check_return(const char *path, uid_t
owner, gid_t group)
* special file node with the major and minor numbers specified by \p dev and
* parent directory if necessary and was called by root.
*/
-static int drmOpenDevice(long dev, int minor, int type)
+static int drmOpenDevice(dev_t dev, int minor, int type)
{
stat_t st;
const char *dev_name;
@@ -2213,7 +2213,7 @@ int drmGetClient(int fd, int idx, int *auth, int *pid,
int *uid,
int drmGetStats(int fd, drmStatsT *stats)
{
drm_stats_t s;
-int i;
+unsignedi;
if (drmIoctl(fd, DRM_IOCTL_GET_STATS, &s))
return -errno;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 60ce369..e3e599b 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -854,7 +854,7 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
len = read(fd, buffer, sizeof buffer);
if (len == 0)
return 0;
- if (len < sizeof *e)
+ if (len < (int)sizeof *e)
return -1;
i = 0;
--
2.1.0
[Bug 89045] [HAWAII,REGRESSION] X crash on KDE session initialisation
https://bugs.freedesktop.org/show_bug.cgi?id=89045 --- Comment #3 from smoki --- Might be duplicate of bug 89034 and llvm svn228228 as a problem that came 2015-02-04 R600/SI: Enable subreg liveness by default -- 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/20150209/61d0beac/attachment.html>
[libdrm][PATCH 1/2] random: Use unsigned long for seed
On 02/09/2015 01:39 PM, Jan Vesely wrote:
> This is more consistent with the rest, and avoids potential undefined
> behavior (signed overflow) in drmRandom()
>
> Signed-off-by: Jan Vesely
> ---
> xf86drmRandom.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/xf86drmRandom.c b/xf86drmRandom.c
> index ecab9e2..a084b86 100644
> --- a/xf86drmRandom.c
> +++ b/xf86drmRandom.c
> @@ -98,7 +98,7 @@ typedef struct RandomState {
> unsigned long q; /* m div a */
> unsigned long r; /* m mod a */
> unsigned long check;
> -long seed;
> +unsigned long seed;
> } RandomState;
>
> #if RANDOM_MAIN
> @@ -147,13 +147,13 @@ int drmRandomDestroy(void *state)
> unsigned long drmRandom(void *state)
> {
> RandomState *s = (RandomState *)state;
> -long hi;
> -long lo;
> +unsigned long hi;
> +unsigned long lo;
>
> hi = s->seed / s->q;
> lo = s->seed % s->q;
> s->seed = s->a * lo - s->r * hi;
> -if (s->seed <= 0) s->seed += s->m;
> +if ((s->a * lo) <= (s->r * hi)) s->seed += s->m;
This seems like an unrelated change.
>
> return s->seed;
> }
> @@ -166,7 +166,7 @@ double drmRandomDouble(void *state)
> }
>
> #if RANDOM_MAIN
> -static void check_period(long seed)
> +static void check_period(unsigned long seed)
> {
> unsigned long count = 0;
> unsigned long initial;
> @@ -178,7 +178,7 @@ static void check_period(long seed)
> while (initial != drmRandom(state)) {
> if (!++count) break;
> }
> -printf("With seed of %10ld, period = %10lu (0x%08lx)\n",
> +printf("With seed of %10lu, period = %10lu (0x%08lx)\n",
> seed, count, count);
> drmRandomDestroy(state);
> }
> @@ -195,7 +195,7 @@ int main(void)
> }
> printf("After 1 iterations: %lu (%lu expected): %s\n",
> rand, state->check,
> -rand - state->check ? "*INCORRECT*" : "CORRECT");
> +rand != state->check ? "*INCORRECT*" : "CORRECT");
So does this.
> drmRandomDestroy(state);
>
> printf("Checking periods...\n");
>
[libdrm][PATCH 2/2] Fix gcc -Wextra warnings
This patch is
Reviewed-by: Ian Romanick
On 02/09/2015 01:39 PM, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
> tests/vbltest/vbltest.c | 3 ++-
> xf86drm.c | 4 ++--
> xf86drmMode.c | 2 +-
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
> index cdc1ef6..6e13c57 100644
> --- a/tests/vbltest/vbltest.c
> +++ b/tests/vbltest/vbltest.c
> @@ -104,7 +104,8 @@ static void usage(char *name)
>
> int main(int argc, char **argv)
> {
> - int i, c, fd, ret;
> + unsigned i;
> + int c, fd, ret;
> char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos",
> "omapdrm", "tilcdc", "msm", "tegra" };
> drmVBlank vbl;
> drmEventContext evctx;
> diff --git a/xf86drm.c b/xf86drm.c
> index 345325a..fb673b5 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -303,7 +303,7 @@ static int chown_check_return(const char *path, uid_t
> owner, gid_t group)
> * special file node with the major and minor numbers specified by \p dev and
> * parent directory if necessary and was called by root.
> */
> -static int drmOpenDevice(long dev, int minor, int type)
> +static int drmOpenDevice(dev_t dev, int minor, int type)
> {
> stat_t st;
> const char *dev_name;
> @@ -2213,7 +2213,7 @@ int drmGetClient(int fd, int idx, int *auth, int *pid,
> int *uid,
> int drmGetStats(int fd, drmStatsT *stats)
> {
> drm_stats_t s;
> -int i;
> +unsignedi;
>
> if (drmIoctl(fd, DRM_IOCTL_GET_STATS, &s))
> return -errno;
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 60ce369..e3e599b 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -854,7 +854,7 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
> len = read(fd, buffer, sizeof buffer);
> if (len == 0)
> return 0;
> - if (len < sizeof *e)
> + if (len < (int)sizeof *e)
> return -1;
>
> i = 0;
>
[libdrm][PATCH 1/2] random: Use unsigned long for seed
On Mon, 2015-02-09 at 15:11 -0800, Ian Romanick wrote:
> On 02/09/2015 01:39 PM, Jan Vesely wrote:
> > This is more consistent with the rest, and avoids potential undefined
> > behavior (signed overflow) in drmRandom()
> >
> > Signed-off-by: Jan Vesely
> > ---
> > xf86drmRandom.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/xf86drmRandom.c b/xf86drmRandom.c
> > index ecab9e2..a084b86 100644
> > --- a/xf86drmRandom.c
> > +++ b/xf86drmRandom.c
> > @@ -98,7 +98,7 @@ typedef struct RandomState {
> > unsigned long q; /* m div a */
> > unsigned long r; /* m mod a */
> > unsigned long check;
> > -long seed;
> > +unsigned long seed;
> > } RandomState;
> >
> > #if RANDOM_MAIN
> > @@ -147,13 +147,13 @@ int drmRandomDestroy(void *state)
> > unsigned long drmRandom(void *state)
> > {
> > RandomState *s = (RandomState *)state;
> > -long hi;
> > -long lo;
> > +unsigned long hi;
> > +unsigned long lo;
> >
> > hi = s->seed / s->q;
> > lo = s->seed % s->q;
> > s->seed = s->a * lo - s->r * hi;
> > -if (s->seed <= 0) s->seed += s->m;
> > +if ((s->a * lo) <= (s->r * hi)) s->seed += s->m;
>
> This seems like an unrelated change.
This change is necessary. since s->seed is unsigned now it cannot be <
0. also the result of s->seed op s->q is unsigned.
>
> >
> > return s->seed;
> > }
> > @@ -166,7 +166,7 @@ double drmRandomDouble(void *state)
> > }
> >
> > #if RANDOM_MAIN
> > -static void check_period(long seed)
> > +static void check_period(unsigned long seed)
> > {
> > unsigned long count = 0;
> > unsigned long initial;
> > @@ -178,7 +178,7 @@ static void check_period(long seed)
> > while (initial != drmRandom(state)) {
> > if (!++count) break;
> > }
> > -printf("With seed of %10ld, period = %10lu (0x%08lx)\n",
> > +printf("With seed of %10lu, period = %10lu (0x%08lx)\n",
> >seed, count, count);
> > drmRandomDestroy(state);
> > }
> > @@ -195,7 +195,7 @@ int main(void)
> > }
> > printf("After 1 iterations: %lu (%lu expected): %s\n",
> >rand, state->check,
> > - rand - state->check ? "*INCORRECT*" : "CORRECT");
> > + rand != state->check ? "*INCORRECT*" : "CORRECT");
>
> So does this.
I'll drop this one in v2, it shouldn't have been included
>
> > drmRandomDestroy(state);
> >
> > printf("Checking periods...\n");
> >
>
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150209/54aaa8b0/attachment-0001.sig>
[libdrm][PATCH v2 1/2] random: Use unsigned long for seed
v2: Remove unrelated change in main()
This is more consistent with the rest, and avoids potential undefined
behavior (signed overflow) ind drmRandom()
Signed-off-by: Jan Vesely
---
xf86drmRandom.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xf86drmRandom.c b/xf86drmRandom.c
index ecab9e2..94922ad 100644
--- a/xf86drmRandom.c
+++ b/xf86drmRandom.c
@@ -98,7 +98,7 @@ typedef struct RandomState {
unsigned long q; /* m div a */
unsigned long r; /* m mod a */
unsigned long check;
-long seed;
+unsigned long seed;
} RandomState;
#if RANDOM_MAIN
@@ -147,13 +147,13 @@ int drmRandomDestroy(void *state)
unsigned long drmRandom(void *state)
{
RandomState *s = (RandomState *)state;
-long hi;
-long lo;
+unsigned long hi;
+unsigned long lo;
hi = s->seed / s->q;
lo = s->seed % s->q;
s->seed = s->a * lo - s->r * hi;
-if (s->seed <= 0) s->seed += s->m;
+if ((s->a * lo) <= (s->r * hi)) s->seed += s->m;
return s->seed;
}
@@ -166,7 +166,7 @@ double drmRandomDouble(void *state)
}
#if RANDOM_MAIN
-static void check_period(long seed)
+static void check_period(unsigned long seed)
{
unsigned long count = 0;
unsigned long initial;
@@ -178,7 +178,7 @@ static void check_period(long seed)
while (initial != drmRandom(state)) {
if (!++count) break;
}
-printf("With seed of %10ld, period = %10lu (0x%08lx)\n",
+printf("With seed of %10lu, period = %10lu (0x%08lx)\n",
seed, count, count);
drmRandomDestroy(state);
}
--
2.1.0
[libdrm][PATCH 2/2] Fix gcc -Wextra warnings
On 9 February 2015 at 21:39, Jan Vesely wrote: > Signed-off-by: Jan Vesely Nice one Jan. I've sent similar fixes for drmOpenDevice and drmGetStats a few days ago. Considering you drop the last hunk that Ian spotted both patches are Reviewed-by: Emil Velikov The strange part is that the normal Linux build does not show even a single warning, despite the -Wextra and -Wsign-compare flags from configure.ac. Perhaps my gcc does not like libdrm for some reason :P -Emil
Is my Radeon HD 6970M dying? Hangs & init problems
On Mon, Feb 9, 2015 at 6:06 PM, RafaÅ MiÅecki wrote: > My notebook Samsung NP700G7A-S01PL was working stable for more than 2 years. > I was using 3.11, 3.17, 3.18, 3.19 (since rc1) and many more successfully. > First hang has happened on 2015-02-08 (23:30) with 3.19-rc5 I was > using for 3 weeks. > > So what I'm seeing are two possibly related problems: > > 1) Random hangs > I don't have to be doing anything unusual. A single display, no UVD, > just writing some code in kate. And then it randomly happens. My > screen goes all white or green vertical lines or blue vertical lines. > I can't use/access my machine, sound goes into a loop (last second). > Sometimes it happens after hours, sometimes 30 minutes, sometimes few > minutes. So far I got 5-7 hangs like this. > > 2) Init problems > Unfortunately rebooting does not always help. Even cold boot (removing > power & battery, keeping power button pressed for few seconds) isn't > helpful. > a) First I get UVD init errors: > *ERROR* UVD not responding, trying to reset the VCPU!!! > b) Then machine hangs after displaying "pitch is 7680" > I've tracked it to be somewhere near register_framebuffer > (see attached bad.txt) > > As long as I don't use radeon (booting with "nomodeset") it works stable. > > I tested my RAM with MemTest86 (one pass, took 1 hour), no errors, CPU > temperature didn't exceed 70 degrees. > > This evening as the last hope I installed fglrx. It hangs my machine > as well with following messages: > [ 36.472526] console [netcon0] enabled > [ 36.473106] netconsole: network logging started > [ 48.192215] fglrx_pci :01:00.0: irq 56 for MSI/MSI-X > [ 48.192726] <6>[fglrx] Firegl kernel thread PID: 1481 > [ 48.192833] <6>[fglrx] Firegl kernel thread PID: 1482 > [ 48.192954] <6>[fglrx] Firegl kernel thread PID: 1483 > [ 48.193077] <6>[fglrx] IRQ 56 Enabled > [ 48.240118] <6>[fglrx] Reserved FB block: Shared offset:0, size:100 > [ 48.240122] <6>[fglrx] Reserved FB block: Unshared offset:3fab4000, > size:4000 > [ 48.240124] <6>[fglrx] Reserved FB block: Unshared offset:3fab8000, > size:548000 > [ 48.240126] <6>[fglrx] Reserved FB block: Unshared offset:7fff3000, > size:d000 > However if I drop fglrx.ko and just use Xorg driver fglrx_drv.so it > works stable. > > Any ideas? Is GPU on my motherboard just dying? :| If it just started at some point in time regardless of the sw stack you are running, then I suspect I hw problem. If you can run an older known-good stack and it works fine, then it's probably a sw problem. If you disable the fglrx kernel module, you are basically running a display only driver (no accel, etc.). Alex
[libdrm][PATCH 2/2] Fix gcc -Wextra warnings
On Mon, 2015-02-09 at 23:32 +, Emil Velikov wrote: > On 9 February 2015 at 21:39, Jan Vesely wrote: > > Signed-off-by: Jan Vesely > Nice one Jan. I've sent similar fixes for drmOpenDevice and > drmGetStats a few days ago. > > Considering you drop the last hunk that Ian spotted both patches are > Reviewed-by: Emil Velikov Thanks, I sent v2 of that patch few minutes ago. I think your 4/6 and 5/6 overlap with this one. Should I go ahead or do you plan to push yours? > > The strange part is that the normal Linux build does not show even a > single warning, despite the -Wextra and -Wsign-compare flags from > configure.ac. Perhaps my gcc does not like libdrm for some reason :P I think I just used CFLAGS= during configure, and it worked jan > > -Emil -- Jan Vesely -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150209/81728fb7/attachment.sig>
[libdrm][PATCH 3/2] Fix always true comparison.
The only user I found is xserver, it can return -1 under certain conditions. So check for -1 explicitly. Signed-off-by: Jan Vesely --- I could not find whether it's actually legal to return encoded negative values in get_perm. This is a quick fix to detect the one case that I found. xf86drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xf86drm.c b/xf86drm.c index fb673b5..8e54ac9 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -335,7 +335,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type) drm_server_info->get_perms(&serv_group, &serv_mode); devmode = serv_mode ? serv_mode : DRM_DEV_MODE; devmode &= ~(S_IXUSR|S_IXGRP|S_IXOTH); - group = (serv_group >= 0) ? serv_group : DRM_DEV_GID; + group = (serv_group != ~0U) ? serv_group : DRM_DEV_GID; } #if !defined(UDEV) -- 2.1.0
[PATCH] gma500: condition with no effect
The if and the else branch code are identical - so the condition has no effect on the effective code - this patch removes the condition and the duplicated code. Signed-off-by: Nicholas Mc Guire --- Patch was only compile tested with x86_64_defconfig + CONFIG_DRM_GMA500=m Patch is against 3.19.0-rc7 (localversion-next is -next-20150209) drivers/gpu/drm/gma500/mdfld_dsi_dpi.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c index d4813e0..1893fc9 100644 --- a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c +++ b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c @@ -975,10 +975,7 @@ struct mdfld_dsi_encoder *mdfld_dsi_dpi_init(struct drm_device *dev, return NULL; } - if (dsi_connector->pipe) - dpi_output->panel_on = 0; - else - dpi_output->panel_on = 0; + dpi_output->panel_on = 0; dpi_output->dev = dev; if (mdfld_get_panel_type(dev, pipe) != TC35876X) -- 1.7.10.4
[PATCH v2] drm: atmel-hlcdc: Atomic mode-setting conversion
Hello Boris, On Fri, Feb 06, 2015 at 04:22:23PM +0100, Boris Brezillon wrote: > Convert the HLCDC driver to atomic mode-setting. > > Signed-off-by: Boris Brezillon > --- I am getting the following trace with this patch applied, which seems pretty straightforward to fix. Apart from that, it works perfectly, you can add my: Tested-by: Sylvain Rochet [ cut here ] WARNING: CPU: 0 PID: 9 at drivers/clk/clk.c:992 clk_disable+0x28/0x34() Modules linked in: CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 3.19.0-rc7-next-20150204+ #90 Hardware name: Atmel SAMA5 (Device Tree) Workqueue: events output_poll_execute [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (warn_slowpath_common+0x84/0xb0) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null) from [] (clk_disable+0x28/0x34) [] (clk_disable) from [] (atmel_hlcdc_crtc_disable+0xe8/0x114) [] (atmel_hlcdc_crtc_disable) from [] (__drm_helper_disable_unused_functions+0xa4/0xd8) [] (__drm_helper_disable_unused_functions) from [] (drm_helper_disable_unused_functions+0x14/0x20) [] (drm_helper_disable_unused_functions) from [] (drm_fbdev_cma_init+0x78/0xfc) [] (drm_fbdev_cma_init) from [] (atmel_hlcdc_fb_output_poll_changed+0x30/0x40) [] (atmel_hlcdc_fb_output_poll_changed) from [] (output_poll_execute+0x148/0x188) [] (output_poll_execute) from [] (process_one_work+0xfc/0x310) [] (process_one_work) from [] (worker_thread+0x60/0x478) [] (worker_thread) from [] (kthread+0xd4/0xec) [] (kthread) from [] (ret_from_fork+0x14/0x34) ---[ end trace 9500ebf8d7076b60 ]--- [ cut here ] WARNING: CPU: 0 PID: 9 at drivers/clk/clk.c:898 clk_unprepare+0x24/0x2c() Modules linked in: CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: GW 3.19.0-rc7-next-20150204+ #90 Hardware name: Atmel SAMA5 (Device Tree) Workqueue: events output_poll_execute [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (warn_slowpath_common+0x84/0xb0) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null) from [] (clk_unprepare+0x24/0x2c) [] (clk_unprepare) from [] (atmel_hlcdc_crtc_disable+0xf0/0x114) [] (atmel_hlcdc_crtc_disable) from [] (__drm_helper_disable_unused_functions+0xa4/0xd8) [] (__drm_helper_disable_unused_functions) from [] (drm_helper_disable_unused_functions+0x14/0x20) [] (drm_helper_disable_unused_functions) from [] (drm_fbdev_cma_init+0x78/0xfc) [] (drm_fbdev_cma_init) from [] (atmel_hlcdc_fb_output_poll_changed+0x30/0x40) [] (atmel_hlcdc_fb_output_poll_changed) from [] (output_poll_execute+0x148/0x188) [] (output_poll_execute) from [] (process_one_work+0xfc/0x310) [] (process_one_work) from [] (worker_thread+0x60/0x478) [] (worker_thread) from [] (kthread+0xd4/0xec) [] (kthread) from [] (ret_from_fork+0x14/0x34) ---[ end trace 9500ebf8d7076b61 ]--- Sylvain
[PATCH] vt_buffer: drop console buffer copying optimisations
On 9 February 2015 at 10:49, Geert Uytterhoeven wrote: > On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone wrote: >> On 5 February 2015 at 11:35, One Thousand Gnomes >> wrote: >>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS) >>> >>> #endif >>> >>> around that and its sorted as an option everyone can leave off but the >>> afflicted. >> >> Well, given all the distros will enable that, might as well be #if >> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER). > > All distros on 1 out of 29 architectures? It's a fairly popular architecture. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vt_buffer: drop console buffer copying optimisations
On 5 February 2015 at 11:35, One Thousand Gnomes wrote: >> If I'm not mistaken, that would be as simple as adding >> >> #define VT_BUF_HAVE_RW. >> #define scr_writew(val, addr) (*(addr) = (val)) >> #define scr_readw(addr) (*(addr)) >> >> to arch/x86/include/asm/vga.h. > > and stick an > > #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS) > > #endif > > around that and its sorted as an option everyone can leave off but the > afflicted. Well, given all the distros will enable that, might as well be #if !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER). -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vt_buffer: drop console buffer copying optimisations
On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone wrote:
> On 5 February 2015 at 11:35, One Thousand Gnomes
> wrote:
>>> If I'm not mistaken, that would be as simple as adding
>>>
>>> #define VT_BUF_HAVE_RW.
>>> #define scr_writew(val, addr) (*(addr) = (val))
>>> #define scr_readw(addr) (*(addr))
>>>
>>> to arch/x86/include/asm/vga.h.
>>
>> and stick an
>>
>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>>
>> #endif
>>
>> around that and its sorted as an option everyone can leave off but the
>> afflicted.
>
> Well, given all the distros will enable that, might as well be #if
> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
All distros on 1 out of 29 architectures?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vt_buffer: drop console buffer copying optimisations
On Mon, 9 Feb 2015 11:00:55 + Daniel Stone wrote: > On 9 February 2015 at 10:49, Geert Uytterhoeven > wrote: > > On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone > > wrote: > >> On 5 February 2015 at 11:35, One Thousand Gnomes > >> wrote: > >>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS) > >>> > >>> #endif > >>> > >>> around that and its sorted as an option everyone can leave off but the > >>> afflicted. > >> > >> Well, given all the distros will enable that, might as well be #if > >> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER). > > > > All distros on 1 out of 29 architectures? > > It's a fairly popular architecture. I imagine most distros wouldn't enable it even on x86. It's an incredibly obscure setup from the evidence of how long it took to get reported. Most distributions don't support non PAE processors and other far more common things 8) Alan -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
