https://bugzilla.kernel.org/show_bug.cgi?id=172421
Bug ID: 172421
Summary: radeon: allow to set the TMDS frequency by a special
kernel parameter
Product: Drivers
Version: 2.5
Kernel Version: 4.8.0-rc7+
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: enhancement
Priority: P1
Component: Video(DRI - non Intel)
Assignee: …
[View More]drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: estellnb(a)elstel.org
Regression: No
Despite different claims by ATI in 2016 Radeon R5 230 graphics cards featuring
HDMI, DVI and VGA had originally been sold as 4K-ready up to the year 2015. The
only prove I have for this is a comercial invoice from Nexus Mobile and a
packaging card. As far as I know Radeon R5 230 cards currently sold can still
be run stable and reliable under UltraHD provided that you apply the right
kernel patch (see for the attachement). Unfortunately neither my former
merchant nor ATI have responded about my questions concerning this change in
trade and marketing policy.
My request would now be to integrate the provided patch into the mainline
kernel. It does not change the behaviour of the radeon driver unless you
specify a nonzero value for the radeon.hdmimhz parameter. If you do I have
tested the R5 230 cards I have to run stable and reliably for days. At least
the 2GB variant of this card has largely sufficient resources for proficient
desktop computing under UltraHD including image manipulation in 3840x2160.
While never officially discussed for the radeon driver nouveau is already
implementing a similar parameter called nouveau.hdmimhz since kernel 4.5.x.
Though it thereby becomes possible to specify a hdmimhz that is far above the
cards technical possibilties the nouveau developers I have talked with say that
it would rarely be possible to damage any card by overcloking the TMDS. In deed
I have successfully been overclocking my GeForce 9600M GT to feature 4K/2160p.
Even specifying values considerable higher than 225MHz did not damage my
GeForce 9600M GT though the screen stayed black upon the nouveau driver
initialization. While the Radeon R5 230 works well at 297MHz (as long as you
specify that via radeon.hdmimhz) I have similarly to the GeForce 9600M GT tried
to overclock a Radeon R7 240. It did produce stable images at a higher hdmimhz
like 330 though the HDMI input of my monitor features no more than 30Hz at
3840x2160 (tested with or without a DP-adapter).
While it remains questionable if the provided patch can improve things for
newer Radeon cards I would believe it to be beneficial for some elder cards. At
least it is known to be beneficial for the R5 230 initially marketed as
4K-ready. The according radeon patch provided with this report has so far
already been accepted by the Mageia 6 distribution. Though the attached patch
is for application at the current 4.8.0-rcX+ kernels most of my machines that
rely on it still run with 4.6.0.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
Hi!
This is a prototype of HDMI output support for the Renesas r8a7795 SoC and
Salvator-X board. It is based on the renesas-devel-20160516-v4.6 tree and
includes the bridge API conversion patches to the adv7511 and rcar-du
drivers written by Archit Taneja.
The obvious issue with this series is the awkward binding of the dw-hdmi
bridge IP, which can be seen in the "drm: rcar-du: Add dw_hdmi driver
startup" patch. Any comments on how to implement this interface properly
are much appreciated.
…
[View More]Functionally, this series works as expected on both connectors, but EDID
reading is currently broken.
CU
Uli
Archit Taneja (2):
drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder
drm: i2c: adv7511: Convert to drm_bridge
Koji Matsuoka (12):
media: vsp1: Set format to RPF input source
drm: bridge/dw_hdmi: Fix R-Car Gen3 device support
drm: rcar-du: Add R8A7795 device support
drm: rcar-du: Add dw_hdmi driver startup
drm: rcar-du: Add DPLL support
drm: rcar-du: Fix display registers for R-Car Gen3
drm: rcar-du: Fix VSP plane number per devices
drm: rcar-du: Fix VSP feed plane number
drm: rcar-du: Add pixel format support
drm: rcar-du: Fix display max size to 4096x2160 size
arm64: dts: salvator-x: Add DU pins, HDMI connectors and encoder
arm64: configs: Enable R-Car DU related config
Kuninori Morimoto (1):
arm64: defconfig: add VIDEO_RENESAS_FCP
Ulrich Hecht (5):
v4l: vsp1: Change VSP1 LIF linebuffer FIFO
pinctrl: sh-pfc: r8a7795: Add DU support
pinctrl: sh-pfc: r8a7795: Add HDMI CEC support
arm64: dts: r8a7795: Add HDMI encoder support
arm64: dts: r8a7795: add HDMI support to DU
Vladimir Zapolskiy (1):
drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 107 +++++
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 33 +-
arch/arm64/configs/defconfig | 15 +
drivers/gpu/drm/bridge/dw-hdmi.c | 489 +++++++++++++++++++--
drivers/gpu/drm/i2c/adv7511.c | 224 ++++++----
drivers/gpu/drm/rcar-du/Kconfig | 2 +
drivers/gpu/drm/rcar-du/Makefile | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 97 +++-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 12 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 20 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 6 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 13 +-
drivers/gpu/drm/rcar-du/rcar_du_group.c | 5 +
drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 117 -----
drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 --
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 260 ++++++++---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 68 ++-
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 +
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 8 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 7 +-
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 19 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 51 ++-
drivers/media/platform/vsp1/vsp1_drm.c | 6 +
drivers/media/platform/vsp1/vsp1_lif.c | 6 +-
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 113 +++++
include/drm/bridge/dw_hdmi.h | 9 +
27 files changed, 1388 insertions(+), 346 deletions(-)
delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h
--
2.7.4
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=53391
Summary: nouveau: wrong display output order
Product: Drivers
Version: 2.5
Kernel Version: 3.8-rc6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org
ReportedBy: stijn+bugs(a)linux-ipv6.be
…
[View More]Regression: No
My graphics card is a Gainward GTX480
(http://www.gainward.com/main/vgapro.php?id=238). It has 2 DVI outputs, and 1
mini HDMI output. The DVI outputs are numbered on the card, with DVI 1 being
the closest to the PCIe slot, then DVI 2, and finally the mini HDMI.
My primary (left) monitor, is connected to DVI 1, my secondary (right) monitor
to DVI 2. When I boot the computer, the BIOS initializes and uses the monitor
on DVI 1. Grub is displayed on the primary monitor, and the kernel initially
outputs to the primary monitor as well.
However, as soon as the nouveau module is loaded, the primary monitor goes to
standby and the kernel now uses the secondary monitor (on DVI 2) as primary.
When X starts (no Xorg.conf file), it is also displayed on the secondary
monitor.
When using either efifb, vesafb or uvesafb, the monitor on DVI 1 is always the
primary monitor. X with nvidia.ko also uses DVI 1 as the primary display.
Finally, when booting Windows, the startup screen is also displayed on the
monitor connected to DVI 1.
Here comes the weird part: when I am in X, and run xrandr, it does show 3
connected devices: DVI-I-1, DVI-I-2, and HDMI-1, with DVI-I-2 being the only
active one. So it seems that in X, the output order is correct, but with
nouveaufb the DVI connectors are swapped.
I will attach the output of dmesg here. If anything else is needed, please let
me know and I'll be happy to add it.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=85421
Bug ID: 85421
Summary: radeon stalled, GPU lockup, reset and failed on
resume; crashed by firefox.
Product: Drivers
Version: 2.5
Kernel Version: 3.16.3
Hardware: x86-64
OS: Linux
Tree: Fedora
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: …
[View More]drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: htl10(a)users.sourceforge.net
Regression: No
Created attachment 152191
--> https://bugzilla.kernel.org/attachment.cgi?id=152191&action=edit
/var/log/messages from radeon 0000:00:01.0: ring 0 stalled to reboot.
I was away from the computer when the radeon dri driver crashed; I left a fair
number of firefox windows on/tab, some of them may have videos (from BBC news
web site) and animated gifs from another web site on; but it crashed about 5-10
minutes after I was away and I was aware of it because the laptop blipped.
# lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Mullins [Radeon R3 Graphics]
some excerpt from the attached logs are:
...
[ 8770.250116] radeon 0000:00:01.0: ring 0 stalled for more than 10012msec
[ 8770.250128] radeon 0000:00:01.0: GPU lockup (waiting for 0x0000000000056034
last fence id 0x0000000000056031 on ring 0)
[ 8770.298635] radeon 0000:00:01.0: Saved 14196 dwords of commands on ring 0.
[ 8770.298663] radeon 0000:00:01.0: GPU softreset: 0x0000000C
...
[ 8770.313299] radeon 0000:00:01.0: GPU reset succeeded, trying to resume
...
[ 8770.339724] [drm] ring test on 0 succeeded in 3 usecs
[ 8770.518568] [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed
(scratch(0x3010C)=0xCAFEDEAD)
[ 8770.752885] [drm:cik_sdma_ring_test] *ERROR* radeon: ring 3 test failed
(0xCAFEDEAD)
[ 8770.752892] [drm:cik_resume] *ERROR* cik startup failed on resume
[ 8780.753181] radeon 0000:00:01.0: ring 0 stalled for more than 10001msec
[ 8780.753193] radeon 0000:00:01.0: GPU lockup (waiting for 0x00000000000560f7
last fence id 0x0000000000056031 on ring 0)
[ 8780.753199] [drm:cik_ib_test] *ERROR* radeon: fence wait failed (-35).
[ 8780.753209] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-35).
[ 8780.753215] radeon 0000:00:01.0: ib ring test failed (-35).
[ 8780.762131] radeon 0000:00:01.0: GPU softreset: 0x0000000C
...
The kernel is a largely fedora 3.16.3-200 one grabbed from the koji srpm but
with the additional patch from
https://bugzilla.kernel.org/show_bug.cgi?id=71051#c8
drv ati 7.4.0 , mesa 10.2.8, glamor from git 347ef4 .
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=107381
Bug ID: 107381
Summary: radeon VCE init error (-110) -- AMD/Intel Mars Hybrid
Graphics
Product: Drivers
Version: 2.5
Kernel Version: 4.3
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)…
[View More]kernel-bugs.osdl.org
Reporter: schmod(a)gmail.com
Regression: No
Created attachment 192261
--> https://bugzilla.kernel.org/attachment.cgi?id=192261&action=edit
dmesg output
Since upgrading to Ubuntu 15.10, I have encountered graphics performance
issues, and have occasionally experienced lockups during boot.
I have encountered this issue on kernel 4.2.0 and 4.3.0, and it seems to have
affected users on other distributions as well:
https://bugs.launchpad.net/fedora/+source/linux/+bug/1512848https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803087https://bugzilla.redhat.com/show_bug.cgi?id=1262649
Notably, this issue seems to primarily impact users with The ATI "Mars"
chipset, on machines that have an Intel/AMD hybrid graphics hardware
configuration.
This shows up in dmesg (full log attached, because there's a fair amount of
seemingly-useful context):
[ 4.917369] radeon 0000:01:00.0: VCE init error (-110).
Some other context from my PC:
$ xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x6a cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 5
associated providers: 2 name:Intel
Provider 1: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0
associated providers: 2 name:radeon
Provider 2: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0
associated providers: 2 name:radeon
$ lspci -k (trimmed to omit likely-irrelevant devices)
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller
(rev 09)
Subsystem: Samsung Electronics Co Ltd Device c0e6
Kernel driver in use: ivb_uncore
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor
PCI Express Root Port (rev 09)
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
DeviceName: Onboard IGD
Subsystem: Samsung Electronics Co Ltd Device c0e6
Kernel driver in use: i915
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon
HD 8670A/8670M/8750M] (rev ff)
Kernel driver in use: radeon
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for
more than 5secs aborting, when disabled via
vgaswitcheroo
Product: Drivers
Version: 2.5
Kernel Version: Linux version 3.6.9-1-ARCH (tobias@T-POWA-LX) (gcc
version 4.7.2 (GCC) ) #1 SMP PREEMPT Tue Dec 4
08:04:10 CET 2012
Platform: All
OS/Version: …
[View More]Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org
ReportedBy: a(a)anrd.net
Regression: Yes
Created an attachment (id=88591)
--> (https://bugzilla.kernel.org/attachment.cgi?id=88591)
journald log
After updating from 3.6.6 to 3.6.9 my laptop with Intel graphics and ATI HD
5650 will not resume from suspend. I use vgaswitcheroo to disable the ATI card
at boot. On resume the computer almost hangs (I can press power button and wait
5 minutes for a proper shutdown, but no other interaction is possible). It logs
a lot of messages saying:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing D098 (len 72,
WS 0, PS 0) @ 0xD0C7
Steps to reproduce:
echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch
[suspend and resume]
Actual results:
Almost freeze.
Expected results:
Resume and work as normal.
Log is attached, but if you need anything else just ask.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=94061
Bug ID: 94061
Summary: [radeon - Kaveri] dpm works badly - much to high power
consumption compared to catalyst
Product: Drivers
Version: 2.5
Kernel Version: 3.14.x ... 3.19.
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
…
[View More]Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: abcdmail(a)freenet.de
Regression: No
With all kernel versions >= 3.14 (I didn't test versions below), radeon / dpm
consumes about 6 W more compared to catalyst in idle mode (X-server 1.15 /
1.16) with Kaveri graphics (AMD A10-7800 Radeon R7).
Idle mode: Xorg runs (KDE 4.11.x), screen saver off, static screen, load: 0.0
If the screen is turned off by X, the power consumption finally reaches the
same level as with catalyst. It's raising immediately again at the moment the
screen is switched on again by X.
Seams the lowest rate is never reached as long as even a static screen has to
be drawn - but it should!
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=78111
Bug ID: 78111
Summary: APU turbo core boost not working when radeon.dpm=1
Product: Drivers
Version: 2.5
Kernel Version: 3.14.6
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
…
[View More]Reporter: bgz.marko(a)gmail.com
Regression: No
I am testing with A6-1450 APU on Arch Linux. If I pass radeon.dpm=1 parameter
at boot and start a single core workload then turbostat will report max
frequency of about 1000 MHz:
Core CPU Avg_MHz Bzy_MHz TSC_MHz time
- - 262 998 998 5**
0 0 12 998 998 5**
1 1 998 998 998
2 2 16 998 998
3 3 21 998 998
"cpupower frequency-info" reports that boost state support is supported, but
not active:
boost state support:
Supported: yes
Active: no
However, when dynamic power management is disabled (radeon.dpm=0), turbostat
reports higher frequencies for single core load, up to 1300 Mhz:
Core CPU Avg_MHz Bzy_MHz TSC_MHz time
- - 320 1214 998 5**
0 0 9 1226 998 5**
1 1 13 1194 998
2 2 41 1143 998
3 3 1216 1216 998
"cpupower frequency-info" confirms that boost is now active.
boost state support:
Supported: yes
Active: yes
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]