[Bug 93826] 144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #27 from Yves W. --- Same for me. flickering problems @144hz,120hz and even 100hz when using newer kernel (tested 4.8.0 ubuntu kernel) or amdgpu-pro 16.30.3-315407 driver with any kernel - with default driver and default kernel (Linux Mint 18 -> 4.4.0-38-generi) it's working at 2560x1440 @144hz, no flickering issues. -> tried using the Ubuntu 4.8.0 kernel -> flickering at 2560x1440 @144hz,120 and 100hz. only 60hz works without flickering -> with the amdgpu-pro 16.30.3-315407 driver from amd site, it's always flickering at 2560x1440 @144hz,120 and 100hz. only 60hz works without flickering system info: --- lshw -c video - *-display Beschreibung: VGA compatible controller Produkt: Hawaii PRO [Radeon R9 290] Hersteller: Advanced Micro Devices, Inc. [AMD/ATI] Physische ID: 0 Bus-Informationen: pci at :03:00.0 Version: 00 Breite: 64 bits Takt: 33MHz Fähigkeiten: pm pciexpress msi vga_controller bus_master cap_list rom Konfiguration: driver=radeon latency=0 Ressourcen: irq:50 memory:e000-efff memory:f000-f07f ioport:e000(GröÃe=256) memory:fbe0-fbe3 memory:fbe4-fbe5 *-display Beschreibung: VGA compatible controller Produkt: Hawaii PRO [Radeon R9 290] Hersteller: Advanced Micro Devices, Inc. [AMD/ATI] Physische ID: 0 Bus-Informationen: pci at :06:00.0 Version: 00 Breite: 64 bits Takt: 33MHz Fähigkeiten: pm pciexpress msi vga_controller bus_master cap_list rom Konfiguration: driver=radeon latency=0 Ressourcen: irq:51 memory:c000-cfff memory:d000-d07f ioport:d000(GröÃe=256) memory:fbd0-fbd3 memory:fbd4-fbd5 xrandr -- Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384 DisplayPort-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95 + 143.86* 144.00 119.8899.90 additional info: --- -using driver from ppa: deb http://ppa.launchpad.net/oibaf/graphics-drivers/ubuntu xenial main vs. amdgpu-pro 16.30.3-315407 dpkg -l | grep '^ii' | grep radeon -- ii libdrm-radeon1:amd64 2.4.71+git1610040630.a44c9c~gd~x amd64Userspace interface to radeon-specific kernel DRM services -- runtime ii libdrm-radeon1:i386 2.4.71+git1610040630.a44c9c~gd~x i386 Userspace interface to radeon-specific kernel DRM services -- runtime ii radeontool 1.6.3-1 amd64utility to control ATI Radeon backlight functions on laptops ii xserver-xorg-video-radeon 1:7.7.99+git1609271931.3fc839~gd~x amd64X.Org X server -- AMD/ATI Radeon display driver tomb raider v.1.1.1 benchmark: - FPS:min | max | avg. radeon: 97.4| 145.4 | 123.4 amdgpu-pro 16.30.3-315407: 50.5| 94.9| 79.8 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/bed83e26/attachment.html>
[Bug 93826] 144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #28 from Yves W. --- bah all got displaced, here again my little benchmark :) tomb raider v.1.1.1 benchmark: - FPS:min | max | avg. - radeon:97.4 | 145.4 | 123.4 amdgpu-pro 16.30.3-315407: 50.5 | 94.9 | 79.8 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/782307c2/attachment.html>
[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 Yves W. changed: What|Removed |Added Summary|144Hz graphic glitches and |2560x1440 @144Hz graphic |bad refresh rate|glitches and bad refresh ||rate -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/f03ca2b3/attachment.html>
[PATCH v2 1/2] dt-bindings: add bindings doc for ZTE VOU display controller
On Mon, Oct 03, 2016 at 12:44:29PM -0500, Rob Herring wrote:
> > +Example:
> > +
> > +vou: vou at 144 {
> > + compatible = "zte,zx296718-vou";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0x144 0x1>;
> > + ranges;
>
> You still have overlapping addresses. Explicitly list the sub ranges in
> reg here used by the VOU driver if the driver usage doesn't overlap. If
> there is overlap (2 drivers accessing the same range), then you need
> some APIs between the components (or possibly regmap).
The driver matching "zte,zx296718-vou" doesn't map or access the any
'reg' address. The 'reg' property here is more like a hint telling
that the VOU block covers the address space of all child devices.
I will simply drop the 'reg' property here.
> Also, don't do an empty ranges here. Fill it in so the child nodes are
> just offsets of 0x144
Okay. I thought that empty 'ranges' is fine as long as parent and child
address spaces are identical (1:1 mapping).
So with your suggestion, I made the changes below. Let me know if this
is still not what you are asking for.
Shawn
-8<-
diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt
b/Documentation/devicetree/bindings/display/zte,vou.txt
index d03ba4c4810c..6bb4ab2517ef 100644
--- a/Documentation/devicetree/bindings/display/zte,vou.txt
+++ b/Documentation/devicetree/bindings/display/zte,vou.txt
@@ -56,14 +56,13 @@ vou: vou at 144 {
compatible = "zte,zx296718-vou";
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x144 0x1>;
- ranges;
+ ranges = <0 0x144 0x1>;
- dpc: dpc at 144 {
+ dpc: dpc at 0 {
compatible = "zte,zx296718-dpc";
- reg = <0x144 0x1000>, <0x1441000 0x1000>,
- <0x1445000 0x1000>, <0x1446000 0x1000>,
- <0x144a000 0x1000>;
+ reg = <0x 0x1000>, <0x1000 0x1000>,
+ <0x5000 0x1000>, <0x6000 0x1000>,
+ <0xa000 0x1000>;
reg-names = "osd", "timing_ctrl",
"dtrc", "vou_ctrl",
"otfppu";
@@ -74,9 +73,9 @@ vou: vou at 144 {
"main_wclk", "aux_wclk";
};
- hdmi: hdmi at 144c000 {
+ hdmi: hdmi at c000 {
compatible = "zte,zx296718-hdmi";
- reg = <0x144c000 0x4000>;
+ reg = <0xc000 0x4000>;
interrupts = ;
[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=97634 --- Comment #5 from Arek RuÅniak --- I've just tried newest drm-next-4.9-wip: 1c22b05623e5e03ada5a767951eac3203b246be9 and there is something new in kernel log: [ 3430.379659] amdgpu :01:00.0: fb1: amdgpudrmfb frame buffer device [ 3431.438851] [drm:gfx_v6_0_ring_test_ib] *ERROR* amdgpu: IB test timed out [ 3431.438862] [drm:amdgpu_ib_ring_tests] *ERROR* amdgpu: failed testing IB on GFX ring (-110). [ 3431.438866] [drm:amdgpu_device_init] *ERROR* ib ring test failed (-110). [ 3431.871374] [drm:amdgpu_late_init] *ERROR* late_init of IP block failed -22 [ 3431.871381] amdgpu :01:00.0: amdgpu_late_init failed [ 3431.871386] amdgpu :01:00.0: Fatal error during GPU init [ 3431.871390] [drm] amdgpu: finishing device. after that, sysrq works only (and ssh). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/76bebeac/attachment-0001.html>
[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=97634 --- Comment #6 from Arek RuÅniak --- Created attachment 127149 --> https://bugs.freedesktop.org/attachment.cgi?id=127149&action=edit full dmesg for next-drm-4.9-wip: 1c22b05 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/02eeca70/attachment.html>
[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #152 from clogged.drainpipe at gmail.com --- Tahiti LE is still broken, after 3 years. Not trying to be a dick, but FFS, at this point ALL the other cards based on very similar chips(7950, 7970, 280X) work very well, and yet this one is still broken. I mean really, once you have all the work well done for all similar cards, how can it be so hard to bring this one to life? I just upgraded from a HD4890 to a Tahiti LE card. I did not bother to check how well it is supported under Linux before buying it, because I assumed that all GCN1 cards are very well supported via radeonsi. Now I found out, that my card is probably the only one that is not supported at all, so to say I am mad would be an understatement. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/419623cf/attachment.html>
[Bug 98170] [vdpau] Error when calling vdp_output_surface_create
https://bugs.freedesktop.org/show_bug.cgi?id=98170 Bug ID: 98170 Summary: [vdpau] Error when calling vdp_output_surface_create Product: Mesa Version: 12.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 Assignee: dri-devel at lists.freedesktop.org Reporter: bagzy92 at gmail.com QA Contact: dri-devel at lists.freedesktop.org I'm running Gentoo linux amd64 with radeon r300 driver. From version 12.0.1 VDPAU is broken. I also have tried mesa-git, but bug is still there. VDPAU works good with mesa 11.2.2 witch i use right now. Here is the output from mplayer: https://bpaste.net/show/53e11a71da14 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/f21e3505/attachment.html>
[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #153 from Vedran MiletiÄ --- (In reply to madmalkav from comment #151) > Created attachment 124324 [details] > dmesg after the mesa dump > > No more "Ring stalled..." messages with kernel 4.7rc1 madmalkav, any more recent findings? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/77b5d034/attachment.html>
[Bug 98168] [vulkan, radv] Talos rendering glitches on Ultra settings on Tonga
https://bugs.freedesktop.org/show_bug.cgi?id=98168 --- Comment #5 from Vedran MiletiÄ --- Also affects RX 480 according to Christoph Haag: https://youtu.be/GltTu_BA7rc?t=85 https://youtu.be/dS2HLt5BjFY -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/d36fd982/attachment.html>
[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #154 from madmalkav --- Nothing. More people doing tests surely will help, getting one of this cards to a developer will be great, but I can't afford that at the moment -come on, AMD, you surely have one or two on a basement...- -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/aefa6a02/attachment.html>
[Bug 97852] Unreal Engine corrupted preview viewport
https://bugs.freedesktop.org/show_bug.cgi?id=97852 --- Comment #2 from Markus --- (In reply to Nicolai Hähnle from comment #1) > Hi Markus, can you provide an apitrace that can reproduce the corruption? Hi Nicolai, I'm not familiar with debugging Mesa. Could you please provide a link to documentation on how I can obtain the information you need? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/ca6e62a5/attachment.html>
[PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels
Hi Rob, On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote: > On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote: > > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. > > Multiple incompatible data link layers have been used over time to > > transmit image data to LVDS panels. This binding supports display panels > > compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG > > specifications. > > > > Signed-off-by: Laurent Pinchart > > > > --- > > > > .../bindings/display/panel/panel-lvds.txt | 119 > > 1 file changed, 119 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/panel-lvds.txt> > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt > > b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt new file > > mode 100644 > > index ..250861f2673e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt > > @@ -0,0 +1,119 @@ > > +Generic LVDS Panel > > +== > > + > > +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. > > Multiple > > +incompatible data link layers have been used over time to transmit image > > data > > +to LVDS panels. This bindings supports display panels compatible with the > > +following specifications. > > + > > +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, > > February > > +1999 (Version 1.0), Japan Electronic Industry Development Association > > (JEIDA) > > +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National > > +Semiconductor > > +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video > > +Electronics Standards Association (VESA) > > + > > +Device compatible with those specifications have been marketed under the > > +FPD-Link and FlatLink brands. > > + > > + > > +Required properties: > > +- compatible: shall contain "panel-lvds" > > Maybe as a fallback, but on its own, no way. Which brings an interesting question: when designing generic DT bindings, what's the rule regarding > > +- width-mm: panel display width in millimeters > > +- height-mm: panel display height in millimeters > > This is already documented for all panels IIRC. Note that this DT binding has nothing to do with the simple-panel binding. It is instead similar to the panel-dpi and panel-dsi-cm bindings (which currently don't but should specify the panel size in DT). The LVDS panel driver will *not* include any panel-specific information such as size or timings, these are specified in DT. > > +- data-mapping: the color signals mapping order, "jeida-18", "jeida-24" > > + or "vesa-24" > > Maybe this should be part of the compatible. I've thought about it, but given that some panels support selecting between multiple modes (through a mode pin that is usually hardwired), I believe a separate DT property makes sense. Furthermore, LVDS data organization is controlled by the combination of both data-mapping and data-mirror. It makes little sense from my point of view to handle one as part of the compatible string and the other one as a separate property. > > +Optional properties: > > +- label: a symbolic name for the panel > > Could be for any panel or display connector. Yes, but I'm not sure to understand how that's relevant :-) > > +- avdd-supply: reference to the regulator that powers the panel > analog supply > > +- dvdd-supply: reference to the regulator that powers the panel digital > > supply > > Which one has to be powered on first, what voltage, and with what time > in between? This is why "generic" or "simple" bindings don't work. The above-mentioned specifications also define connectors, pinouts and power supplies, but many LVDS panels compatible with the LVDS physical and data layers use a different connector with small differences in power supplies. I believe the voltage is irrelevant here, it doesn't need to be controlled by the operating system. Power supplies order and timing is relevant, I'll investigate the level of differences between panels. I'm also fine with dropping those properties for now. > > +- data-mirror: if set, reverse the bit order on all data lanes (6 to 0 > > instead > > + of 0 to 6) > > + > > +Required nodes: > > +- One "panel-timing" node containing video timings, in accordance with > > the > > + display timing bindings defined in > > + Documentation/devicetree/bindings/display/display-timing.txt. > > I'll let Thierry comment on this one. > > > +- One "port" child node for the LVDS input port, in accordance with the > > + video interface bindings defined in > > + Documentation/devicetree/bindings/media/video-interfaces.txt. > > + > > + > > +LVDS data mappings are defined as follows. > > + > > +- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and > > + [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. > > + > > +Slot
[Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.
https://bugs.freedesktop.org/show_bug.cgi?id=98172
Bug ID: 98172
Summary: Concurrent call to glClientWaitSync results in
segfault in one of the waiters.
Product: Mesa
Version: 11.2
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
Assignee: dri-devel at lists.freedesktop.org
Reporter: shinji.suzuki at gmail.com
QA Contact: dri-devel at lists.freedesktop.org
In my app, a fence is created in Thread-A and it gets passed to Thread-B and
Thread-C to be waited upon. (Each thread has its own context.)
Thread-A issues the call, fence = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE,
0).
Thread-B and C issue the call, glClientWaitSync(fence,
GL_SYNC_FLUSH_COMMANDS_BIT, GL_TIMEOUT_IGNORED);
Most of the time, wait in both clients succeed but occasionally one of them
generates segfault. Upon inspection of generated core, it turned out so->fence
in the expression "&so->fence" at line 113 in
src/mesa/state_tracker/st_cb_syncobj.c is NULL, which should be causing the
segfault down the call chain through screen->fence_reference. I think there is
race in executing the code block. If I introduce a mutex in my app with which
to avoid concurrent call to glClientWaitSync, I don't observe segfault
happening.
Here is the snippet of code in question from st_cb_syncobj.c:
if (so->fence &&
screen->fence_finish(screen, so->fence, timeout)) {
screen->fence_reference(screen, &so->fence, NULL);
so->b.StatusFlag = GL_TRUE;
}
My environment is;
Ubuntu 16.04 LTS
Linux a7da 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
libgl1-mesa-dri:amd64 / 11.2.0-1ubuntu2.2
Radeon HD3300
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/410e7b5e/attachment.html>
[PATCH] drm: use the right function name in documentation
There is no late_unregister(), it looks like the comment meant
late_register(). Also fix a typo while at it.
Signed-off-by: Grazvydas Ignotas
---
include/drm/drm_connector.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 51a15de..43c5cd7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -345,7 +345,7 @@ struct drm_connector_funcs {
*
* This optional hook should be used to unregister the additional
* userspace interfaces attached to the connector from
-* late_unregister(). It is called from drm_connector_unregister(),
+* late_register(). It is called from drm_connector_unregister(),
* early in the driver unload sequence to disable userspace access
* before data structures are torndown.
*/
@@ -365,7 +365,7 @@ struct drm_connector_funcs {
* @atomic_duplicate_state:
*
* Duplicate the current atomic state for this connector and return it.
-* The core and helpers gurantee that any atomic state duplicated with
+* The core and helpers guarantee that any atomic state duplicated with
* this hook and still owned by the caller (i.e. not transferred to the
* driver by calling ->atomic_commit() from struct
* &drm_mode_config_funcs) will be cleaned up by calling the
--
2.7.4
[Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.
https://bugs.freedesktop.org/show_bug.cgi?id=98172 --- Comment #1 from shinji.suzuki at gmail.com --- Oops, the line number is 114 rather than 113. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/468b33f3/attachment.html>
[Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.
https://bugs.freedesktop.org/show_bug.cgi?id=98172 shinji.suzuki at gmail.com changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org QA Contact|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core CC||shinji.suzuki at gmail.com -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/346276ae/attachment.html>
[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #155 from smoki --- At this point people might wanna try amdgpu driver too from agd5f tree... i think i saw some commits for harvested chips there maybe week ago. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/2585acbc/attachment.html>
[PATCH] drm/amdgpu: use .early_unregister hook to remove DP AUX i2c
When DisplayPort AUX channel i2c adapter is registered, drm_connector's
kdev member is used as a parent, so we get sysfs structure like:
/drm/card1/card1-DP-2/i2c-12
Because of that, there is a problem when drm core (and not the driver)
calls drm_connector_unregister(), it removes parent sysfs entries
('card1-DP-2' in our example) while the i2c adapter is still registered.
Later we get a WARN when we try to unregister the i2c adapter:
WARNING: CPU: 3 PID: 1374 at fs/sysfs/group.c:243
sysfs_remove_group+0x14c/0x150
sysfs group 82911e40 not found for kobject 'i2c-12'
To fix it, we can use the .early_unregister hook to unregister the i2c
adapter before drm_connector's sysfs is torn down.
Signed-off-by: Grazvydas Ignotas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 76a7830..09b76a8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -765,7 +765,7 @@ amdgpu_connector_lvds_detect(struct drm_connector
*connector, bool force)
return ret;
}
-static void amdgpu_connector_destroy(struct drm_connector *connector)
+static void amdgpu_connector_unregister(struct drm_connector *connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
@@ -773,6 +773,12 @@ static void amdgpu_connector_destroy(struct drm_connector
*connector)
drm_dp_aux_unregister(&amdgpu_connector->ddc_bus->aux);
amdgpu_connector->ddc_bus->has_aux = false;
}
+}
+
+static void amdgpu_connector_destroy(struct drm_connector *connector)
+{
+ struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
+
amdgpu_connector_free_edid(connector);
kfree(amdgpu_connector->con_priv);
drm_connector_unregister(connector);
@@ -826,6 +832,7 @@ static const struct drm_connector_funcs
amdgpu_connector_lvds_funcs = {
.dpms = drm_helper_connector_dpms,
.detect = amdgpu_connector_lvds_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
+ .early_unregister = amdgpu_connector_unregister,
.destroy = amdgpu_connector_destroy,
.set_property = amdgpu_connector_set_lcd_property,
};
@@ -936,6 +943,7 @@ static const struct drm_connector_funcs
amdgpu_connector_vga_funcs = {
.dpms = drm_helper_connector_dpms,
.detect = amdgpu_connector_vga_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
+ .early_unregister = amdgpu_connector_unregister,
.destroy = amdgpu_connector_destroy,
.set_property = amdgpu_connector_set_property,
};
@@ -1203,6 +1211,7 @@ static const struct drm_connector_funcs
amdgpu_connector_dvi_funcs = {
.detect = amdgpu_connector_dvi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = amdgpu_connector_set_property,
+ .early_unregister = amdgpu_connector_unregister,
.destroy = amdgpu_connector_destroy,
.force = amdgpu_connector_dvi_force,
};
@@ -1493,6 +1502,7 @@ static const struct drm_connector_funcs
amdgpu_connector_dp_funcs = {
.detect = amdgpu_connector_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = amdgpu_connector_set_property,
+ .early_unregister = amdgpu_connector_unregister,
.destroy = amdgpu_connector_destroy,
.force = amdgpu_connector_dvi_force,
};
@@ -1502,6 +1512,7 @@ static const struct drm_connector_funcs
amdgpu_connector_edp_funcs = {
.detect = amdgpu_connector_dp_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = amdgpu_connector_set_lcd_property,
+ .early_unregister = amdgpu_connector_unregister,
.destroy = amdgpu_connector_destroy,
.force = amdgpu_connector_dvi_force,
};
--
2.7.4
[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #156 from smoki --- Or it was 3 weeks ago :D anyway who knows some magic touches like this might change something: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.7&id=d207295db45b576eddf60749c0c24fc8528f3c80 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/5b3a9c33/attachment.html>
[Bug 97852] Unreal Engine corrupted preview viewport
https://bugs.freedesktop.org/show_bug.cgi?id=97852 --- Comment #3 from Nicolai Hähnle --- Use this tool: https://github.com/apitrace/apitrace to record a session that shows the problem. Once installed, you basically just run `apitrace trace `. The documentation linked to in the readme is generally pretty good. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/903261f1/attachment.html>
[PATCH] README: Fix typos and grammar
Signed-off-by: Fabio Estevam --- README | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README b/README index 603a1c1..15b3064 100644 --- a/README +++ b/README @@ -1,7 +1,7 @@ libdrm - userspace library for drm This is libdrm, a userspace library for accessing the DRM, direct -rendering manager, on Linux, BSD and other operating systes that +rendering manager, on Linux, BSD and other operating systems that support the ioctl interface. The library provides wrapper functions for the ioctls to avoid exposing the kernel interface directly, and for chipsets with drm memory manager, support for tracking relocations @@ -15,7 +15,7 @@ with an older kernel. Compiling - -libdrm is a standard autotools packages and follows the normal +libdrm is a standard autotools package and follows the normal configure, build and install steps. The first step is to configure the package, which is done by running the configure shell script: @@ -37,5 +37,5 @@ and once make finishes successfully, install the package using make install -If you are install into a system location, you will need to be root to -perform the install step. +If you are installing into a system location, you will need to be root +to perform the install step. -- 2.7.4
[PATCH] drm/amd/powerplay: don't give up if DPM is already running
Currently the driver crashes if smu7_enable_dpm_tasks() returns early,
which it does if DPM is already active. It seems to be better just to
continue anyway, at least I haven't noticed any ill effects. It's also
unclear at what state the hardware was left by the previous driver, so
IMO it's better to always fully initialize.
Way to reproduce:
$ modprobe amdgpu
$ rmmod amdgpu
$ modprobe amdgpu
...
DPM is already running right now, no need to enable DPM!
...
failed to send message 18b ret is 0
BUG: unable to handle kernel paging request at ed01fc9ab21f
Call Trace:
smu7_set_power_state_tasks+0x499/0x1940 [amdgpu]
phm_set_power_state+0xcb/0x120 [amdgpu]
psm_adjust_power_state_dynamic+0x11e/0x1b0 [amdgpu]
pem_task_adjust_power_state+0xb9/0xd0 [amdgpu]
pem_excute_event_chain+0x7d/0xe0 [amdgpu]
pem_handle_event_unlocked+0x49/0x60 [amdgpu]
pem_handle_event+0xe/0x10 [amdgpu]
pp_dpm_dispatch_tasks+0xe0/0x190 [amdgpu]
amdgpu_pm_compute_clocks+0x10c/0xc60 [amdgpu]
dce_v11_0_crtc_dpms+0x7d/0x150 [amdgpu]
dce_v11_0_crtc_disable+0x90/0x4a0 [amdgpu]
drm_helper_disable_unused_functions+0x67/0x80 [drm_kms_helper]
amdgpu_fbdev_init+0x13e/0x170 [amdgpu]
amdgpu_device_init+0x1aeb/0x2490 [amdgpu]
Signed-off-by: Grazvydas Ignotas
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index f6afa6a..327030b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -1166,8 +1166,8 @@ static int smu7_enable_dpm_tasks(struct pp_hwmgr *hwmgr)
tmp_result = (!smum_is_dpm_running(hwmgr)) ? 0 : -1;
PP_ASSERT_WITH_CODE(tmp_result == 0,
- "DPM is already running right now, no need to enable
DPM!",
- return 0);
+ "DPM is already running",
+ );
if (smu7_voltage_control(hwmgr)) {
tmp_result = smu7_enable_voltage_control(hwmgr);
--
2.7.4
[Bug 177131] New: Nouveau: GPU lockup regression with Linux 4.8
https://bugzilla.kernel.org/show_bug.cgi?id=177131 Bug ID: 177131 Summary: Nouveau: GPU lockup regression with Linux 4.8 Product: Drivers Version: 2.5 Kernel Version: 4.8.1 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: bastian.beischer at rwth-aachen.de Regression: No Hello, I'm running Arch Linux x86_64 (testing repository) on a Lenovo T420 Laptop. Arch just recently shipped the kernels 4.8 and 4.8.1 and since then I experience the following lockup (lines from journalctl | grep kernel | grep nouveau): Oct 09 16:41:27 winterfell kernel: fb: switching to nouveaufb from VESA VGA Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: NVIDIA GF119 (0d9170a1) Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: bios: version 75.19.15.01.02 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: fb: 1024 MiB DDR3 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: VRAM: 1024 MiB Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: GART: 1048576 MiB Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: TMDS table version 2.0 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB version 4.0 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 00: 01800323 00010034 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 01: 02811300 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 02: 028223a6 0f220010 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 03: 02822362 00020010 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 04: 048333b6 0f220010 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 05: 04833372 00020010 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 06: 088443c6 0f220010 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB outp 07: 08844382 00020010 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB conn 00: 0040 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB conn 01: 0100 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB conn 02: 00101246 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB conn 03: 00202346 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: DCB conn 04: 00410446 Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: MM: using COPY0 for buffer copies Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: DRM: allocated 1600x1024 fb: 0x6, bo 8802137b4c00 Oct 09 16:41:27 winterfell kernel: fbcon: nouveaufb (fb0) is primary device Oct 09 16:41:27 winterfell kernel: nouveau :01:00.0: fb0: nouveaufb frame buffer device Oct 09 16:41:27 winterfell kernel: [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 0 Oct 09 16:43:00 winterfell kernel: nouveau :01:00.0: fifo: read fault at 36 engine 00 [PGRAPH] client 14 [CCACHE] reason 02 [PAGE_NOT_PRESENT] on channel 6 [003fbab000 Xorg[623]] Oct 09 16:43:00 winterfell kernel: nouveau :01:00.0: fifo: gr engine fault on channel 6, recovering... Oct 09 16:48:16 winterfell kernel: nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon Oct 09 16:48:21 winterfell kernel: nouveau :01:00.0: Xorg[623]: failed to idle channel 6 [Xorg[623]] Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: Xorg[623]: failed to idle channel 6 [Xorg[623]] Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: chid 0 mthd 0080 data 5080 0001 Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: Core: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 0080: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 0084: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 0088: f000 Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: Core - DAC 0: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 0180: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 0184: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 0188: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 0190: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: Core - DAC 1: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 01a0: 0002 Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp: 01a4: Oct 09 16:48:36 winterfell kernel: nouveau :01:00.0: disp:
[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games, WebGL apps, or after extended periods of time
https://bugs.freedesktop.org/show_bug.cgi?id=93341 Jean-François Fortin Tam changed: What|Removed |Added Summary|GPU lockups on RadeonHD |GPU lockups on RadeonHD |7770 (radeonsi driver) when |7770 (radeonsi driver) when |running OpenGL games or |running OpenGL games, WebGL |after extended periods of |apps, or after extended |time|periods of time --- Comment #13 from Jean-François Fortin Tam --- Just to be 110% sure: I put in a completely new, top-quality 650w power supply into the machine, and the problem persists with the F4 map webgl demo. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/046f50d2/attachment.html>
[Bug 98176] External HDMI monitor not woken from sleep/power saving mode when coming back from idle
https://bugs.freedesktop.org/show_bug.cgi?id=98176 Bug ID: 98176 Summary: External HDMI monitor not woken from sleep/power saving mode when coming back from idle Product: Mesa Version: 12.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: nekohayo at gmail.com QA Contact: dri-devel at lists.freedesktop.org I have a LG 25UM58-P 2560x1080 monitor, which only has two HDMI inputs, connected to my Radeon 7770's HDMI port. It works fine, except that whenever the computer/radeon puts the monitor to sleep (when I lock my screen or put the computer into suspend mode), the screen monitor loses the signal and turns off entirely, requiring me to force-turn-it-on whenever I reactivate my computer and unlock my screen. This did not happen with my previous monitor connected over DVI, and I thought "oh well, maybe it's a quirk of the new monitor"... except that while testing out a nVidia FX 580 with the Nouveau driver today, I realized that this driver was able to wake up the screen from GNOME Shell's screen lock, so that indicates that leads me to believe the radeonsi driver actually is the one causing the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161009/29dc7012/attachment.html>
