[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109955

--- Comment #102 from Rodney A Morris  ---
Created attachment 145367
  --> https://bugs.freedesktop.org/attachment.cgi?id=145367=edit
Full dmesg from Stellaris crash

I had another crash and soft lockup tonight playing Stellaris through Steam. 
Unfortunately, while I had the mesa debuginfo packages installed, I did not
have the debug kernel installed.

  /:-:\  
   :---:: 
 :---/shhOHbmp---:\  OS: Fedora release 30 (Thirty) x86_64 
   /---omMMMNNNMMD  ---: Kernel: 5.2.13-200.fc30.x86_64 
  :---sNMNMP.---:Uptime: 25 mins 
 :---:MMMdP------\   Packages: 2202 (rpm), 27 (flatpak) 
,:MMMd---:   Shell: bash 5.0.7 
::MMMd---.---:   Resolution: 2560x1440 
:oNMNho .:   DE: GNOME 3.32.2 
:-- .+shhhMMMmhhy++   .--/   WM: GNOME Shell 
:----:MMMd--:WM Theme: Adwaita 
:-   /MMMd-; Theme: Adapta-Nokto-Eta [GTK2/3] 
:---/hMMMy:  Icons: Adwaita [GTK2/3] 
:-- :dMNdhhdNMMNo;   Terminal: tilix 
:---:sdNNds::CPU: Intel i7-6850K (12) @ 4.000GHz 
:--:://:-::  GPU: AMD ATI Radeon RX Vega 56/64 
:-://Memory: 2478MiB / 32084MiB 

OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.1.6

> Game being played: 


Stellaris through Steam for Linux.  Like other times Discord is running.

> Native or Wine or Wine+DXVK:


Native

> 
> Crash type: Game crash? Full System freeze? System freeze but still can drop
> to tty?


Screen goes black suddenly while music continues plays for less than a minute;
music begins to loop; and computer reboots.

> 
> DMESG output after the crash:
Below is the pertinent dmesg messages.  Full file attached.

[ 5292.563342] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out or interrupted!
[ 5297.683350] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring page1 timeout,
signaled seq=97861046, emitted seq=97861048
[ 5297.683465] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process  pid 0 thread  pid 0
[ 5297.683470] amdgpu :06:00.0: GPU reset begin!
[ 5297.693302] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=1321512, emitted seq=1321513
[ 5297.693406] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process stellaris pid 5624 thread stellaris:cs0 pid 5625
[ 5297.693409] amdgpu :06:00.0: GPU reset begin!
[ 5297.709624] pcieport :00:03.0: AER: Uncorrected (Non-Fatal) error
received: :00:03.0
[ 5297.709631] pcieport :00:03.0: AER: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, (Requester ID)
[ 5297.709634] pcieport :00:03.0: AER:   device [8086:6f08] error
status/mask=4000/
[ 5297.709637] pcieport :00:03.0: AER:[14] CmpltTO   
(First)
[ 5297.709706] pcieport :00:03.0: AER: Device recovery failed
[ 5302.803236] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]]
*ERROR* [CRTC:47:crtc-0] flip_done timed out
[ 5307.923355] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:47:crtc-0]
hw_done or flip_done timed out
[ 5318.163235] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]]
*ERROR* [CRTC:47:crtc-0] flip_done timed out
[ 5328.403235] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]]
*ERROR* [PLANE:45:plane-5] flip_done timed out
[ 5328.717149] amdgpu: [powerplay] No response from smu
[ 5328.717151] amdgpu: [powerplay] Failed message: 0xe, input parameter: 0x0,
error code: 0x0
[ 5329.031482] amdgpu: [powerplay] No response from smu
[ 5329.345845] amdgpu: [powerplay] No response from smu
[ 5329.345847] amdgpu: [powerplay] Failed message: 0x42, input parameter: 0x1,
error code: 0x0
[ 5329.659470] amdgpu: [powerplay] No response from smu
[ 5329.973320] amdgpu: [powerplay] No response from smu
[ 5329.973322] amdgpu: [powerplay] Failed message: 0x24, input parameter: 0x0,
error code: 0x0
[ 5330.044255] [drm] REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif
line:634
[ 5330.044255] [ cut here ]
[ 5330.044355] WARNING: CPU: 9 PID: 7317 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:329
generic_reg_wait.cold+0x31/0x53 [amdgpu]
[ 5330.044356] Modules linked in: rfcomm xt_CHECKSUM xt_MASQUERADE tun bridge
stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat
ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat
iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables
ip6table_filter ip6_tables iptable_filter ip_tables bnep nct6775 

[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=111481

--- Comment #39 from Shmerl  ---
I also get such freezes when opening a new tab in Firefox (once in a while),
and when using ksysguard to read amdgpu sensors with Sapphire Pulse RX 5700 XT.
I'm going to try this patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109955

--- Comment #101 from Rodney A Morris  ---
(In reply to Rodney A Morris from comment #99)
> Created attachment 145366 [details]
> apitrace of Hearts of Iron IV hard lock
> 
> Apitrace from hard lock playing Hearts of Iron IV without Steam.  The replay
> from this trace will hard lock the computer, though inconsistently.  I've
> replayed the trace three times. The replay hard locked computer one time.

neofetch from hardlock:

  /:-:\  
   :---:: 
 :---/shhOHbmp---:\  OS: Fedora release 30 (Thirty) x86_64 
   /---omMMMNNNMMD  ---: Kernel: 5.2.13-200.fc30.x86_64 
  :---sNMNMP.---:Uptime: 25 mins 
 :---:MMMdP------\   Packages: 2202 (rpm), 27 (flatpak) 
,:MMMd---:   Shell: bash 5.0.7 
::MMMd---.---:   Resolution: 2560x1440 
:oNMNho .:   DE: GNOME 3.32.2 
:-- .+shhhMMMmhhy++   .--/   WM: GNOME Shell 
:----:MMMd--:WM Theme: Adwaita 
:-   /MMMd-; Theme: Adapta-Nokto-Eta [GTK2/3] 
:---/hMMMy:  Icons: Adwaita [GTK2/3] 
:-- :dMNdhhdNMMNo;   Terminal: tilix 
:---:sdNNds::CPU: Intel i7-6850K (12) @ 4.000GHz 
:--:://:-::  GPU: AMD ATI Radeon RX Vega 56/64 
:-://Memory: 2478MiB / 32084MiB 

OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.1.6

Note:  hard lock replayed occurred when the Discord flatpak is also running.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109955

--- Comment #100 from Rodney A Morris  ---
(In reply to Rodney A Morris from comment #99)
> Created attachment 145366 [details]
> apitrace of Hearts of Iron IV hard lock
> 
> Apitrace from hard lock playing Hearts of Iron IV without Steam.  The replay
> from this trace will hard lock the computer, though inconsistently.  I've
> replayed the trace three times. The replay hard locked computer one time.

neofetch from hardlock:

  /:-:\  
   :---:: 
 :---/shhOHbmp---:\  OS: Fedora release 30 (Thirty) x86_64 
   /---omMMMNNNMMD  ---: Kernel: 5.2.13-200.fc30.x86_64 
  :---sNMNMP.---:Uptime: 25 mins 
 :---:MMMdP------\   Packages: 2202 (rpm), 27 (flatpak) 
,:MMMd---:   Shell: bash 5.0.7 
::MMMd---.---:   Resolution: 2560x1440 
:oNMNho .:   DE: GNOME 3.32.2 
:-- .+shhhMMMmhhy++   .--/   WM: GNOME Shell 
:----:MMMd--:WM Theme: Adwaita 
:-   /MMMd-; Theme: Adapta-Nokto-Eta [GTK2/3] 
:---/hMMMy:  Icons: Adwaita [GTK2/3] 
:-- :dMNdhhdNMMNo;   Terminal: tilix 
:---:sdNNds::CPU: Intel i7-6850K (12) @ 4.000GHz 
:--:://:-::  GPU: AMD ATI Radeon RX Vega 56/64 
:-://Memory: 2478MiB / 32084MiB 

OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.1.6

Note:  hard lock replayed occurred when the Discord flatpak is also running.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109955

--- Comment #99 from Rodney A Morris  ---
Created attachment 145366
  --> https://bugs.freedesktop.org/attachment.cgi?id=145366=edit
apitrace of Hearts of Iron IV hard lock

Apitrace from hard lock playing Hearts of Iron IV without Steam.  The replay
from this trace will hard lock the computer, though inconsistently.  I've
replayed the trace three times. The replay hard locked computer one time.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: sun8i-ui/vi: Fix layer zpos change/atomic modesetting

2019-09-14 Thread Ondřej Jirman
On Sun, Sep 15, 2019 at 12:03:37AM +0200, megous hlavni wrote:
> From: Ondrej Jirman 
> 
> There are various issues that this re-work of sun8i_[uv]i_layer_enable
> function fixes:
> 
> - Make sure that we re-initialize zpos on reset
> - Minimize register updates by doing them only when state changes
> - Fix issue where DE pipe might get disabled even if it is no longer
>   used by the layer that's currently calling sun8i_ui_layer_enable
> - .atomic_disable callback is not really needed because .atomic_update
>   can do the disable too, so drop the duplicate code

See more discussion here:

  https://groups.google.com/d/msg/linux-sunxi/9A7ukdtvNpM/2Z2bAhA9AwAJ
 
o.

> Signed-off-by: Ondrej Jirman 
> ---
>  drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 112 -
>  drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 112 -
>  2 files changed, 142 insertions(+), 82 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c 
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> index dd2a1c851939..b88e8ac5ad1c 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -24,10 +24,11 @@
>  #include "sun8i_ui_scaler.h"
>  
>  static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer, int channel,
> -   int overlay, bool enable, unsigned int zpos,
> -   unsigned int old_zpos)
> +   int overlay, bool was_enabled, bool enable,
> +   unsigned int zpos, unsigned int old_zpos)
>  {
>   u32 val, bld_base, ch_base;
> + unsigned int old_pipe_ch;
>  
>   bld_base = sun8i_blender_base(mixer);
>   ch_base = sun8i_channel_base(mixer, channel);
> @@ -35,28 +36,57 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer 
> *mixer, int channel,
>   DRM_DEBUG_DRIVER("%sabling channel %d overlay %d\n",
>enable ? "En" : "Dis", channel, overlay);
>  
> - if (enable)
> - val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
> - else
> - val = 0;
> + if (!was_enabled != !enable) {
> + val = enable ? SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN : 0;
>  
> - regmap_update_bits(mixer->engine.regs,
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, overlay),
> -SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
> -
> - if (!enable || zpos != old_zpos) {
>   regmap_update_bits(mixer->engine.regs,
> -SUN8I_MIXER_BLEND_PIPE_CTL(bld_base),
> -SUN8I_MIXER_BLEND_PIPE_CTL_EN(old_zpos),
> -0);
> +SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, 
> overlay),
> +SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
> + }
>  
> - regmap_update_bits(mixer->engine.regs,
> + /*
> +  * If this layer was enabled and is being disabled or if it is
> +  * enabled and just changing zpos, clear the old route, if it is
> +  * still configured to this layer in HW.
> +  */
> + if ((was_enabled && !enable) || (enable && zpos != old_zpos)) {
> + /* get channel the pipe for old_zpos is routed to from the HW */
> + regmap_read(mixer->engine.regs,
>  SUN8I_MIXER_BLEND_ROUTE(bld_base),
> -SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(old_zpos),
> -0);
> +_pipe_ch);
> + old_pipe_ch &= SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(old_zpos);
> + old_pipe_ch >>= SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(old_zpos);
> +
> + /*
> +  * Check that pipe for old_zpos is still routed to our layer,
> +  * and clear/disable it if it is.
> +  */
> +
> + if (old_pipe_ch == channel) {
> + DRM_DEBUG_DRIVER("chan=%d en=%d->%d zpos=%d->%d\n",
> +channel, was_enabled, enable, old_zpos, zpos);
> +
> + DRM_DEBUG_DRIVER("  disable pipe %d\n", old_zpos);
> +
> + regmap_update_bits(mixer->engine.regs,
> +SUN8I_MIXER_BLEND_ROUTE(bld_base),
> +
> SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(old_zpos),
> +0);
> +
> + regmap_update_bits(mixer->engine.regs,
> +SUN8I_MIXER_BLEND_PIPE_CTL(bld_base),
> +
> SUN8I_MIXER_BLEND_PIPE_CTL_EN(old_zpos),
> +0);
> + }
>   }
>  
> - if (enable) {
> + /*
> +  * If enabling this layer or changin zpos, set route to this layer.
> +  */
> + if ((enable && !was_enabled) || (enable && zpos != old_zpos)) {
> +   

[PATCH] drm: sun8i-ui/vi: Fix layer zpos change/atomic modesetting

2019-09-14 Thread megous
From: Ondrej Jirman 

There are various issues that this re-work of sun8i_[uv]i_layer_enable
function fixes:

- Make sure that we re-initialize zpos on reset
- Minimize register updates by doing them only when state changes
- Fix issue where DE pipe might get disabled even if it is no longer
  used by the layer that's currently calling sun8i_ui_layer_enable
- .atomic_disable callback is not really needed because .atomic_update
  can do the disable too, so drop the duplicate code

Signed-off-by: Ondrej Jirman 
---
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 112 -
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 112 -
 2 files changed, 142 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c 
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index dd2a1c851939..b88e8ac5ad1c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -24,10 +24,11 @@
 #include "sun8i_ui_scaler.h"
 
 static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer, int channel,
- int overlay, bool enable, unsigned int zpos,
- unsigned int old_zpos)
+ int overlay, bool was_enabled, bool enable,
+ unsigned int zpos, unsigned int old_zpos)
 {
u32 val, bld_base, ch_base;
+   unsigned int old_pipe_ch;
 
bld_base = sun8i_blender_base(mixer);
ch_base = sun8i_channel_base(mixer, channel);
@@ -35,28 +36,57 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer 
*mixer, int channel,
DRM_DEBUG_DRIVER("%sabling channel %d overlay %d\n",
 enable ? "En" : "Dis", channel, overlay);
 
-   if (enable)
-   val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
-   else
-   val = 0;
+   if (!was_enabled != !enable) {
+   val = enable ? SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN : 0;
 
-   regmap_update_bits(mixer->engine.regs,
-  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, overlay),
-  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
-
-   if (!enable || zpos != old_zpos) {
regmap_update_bits(mixer->engine.regs,
-  SUN8I_MIXER_BLEND_PIPE_CTL(bld_base),
-  SUN8I_MIXER_BLEND_PIPE_CTL_EN(old_zpos),
-  0);
+  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, 
overlay),
+  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
+   }
 
-   regmap_update_bits(mixer->engine.regs,
+   /*
+* If this layer was enabled and is being disabled or if it is
+* enabled and just changing zpos, clear the old route, if it is
+* still configured to this layer in HW.
+*/
+   if ((was_enabled && !enable) || (enable && zpos != old_zpos)) {
+   /* get channel the pipe for old_zpos is routed to from the HW */
+   regmap_read(mixer->engine.regs,
   SUN8I_MIXER_BLEND_ROUTE(bld_base),
-  SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(old_zpos),
-  0);
+  _pipe_ch);
+   old_pipe_ch &= SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(old_zpos);
+   old_pipe_ch >>= SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(old_zpos);
+
+   /*
+* Check that pipe for old_zpos is still routed to our layer,
+* and clear/disable it if it is.
+*/
+
+   if (old_pipe_ch == channel) {
+   DRM_DEBUG_DRIVER("chan=%d en=%d->%d zpos=%d->%d\n",
+  channel, was_enabled, enable, old_zpos, zpos);
+
+   DRM_DEBUG_DRIVER("  disable pipe %d\n", old_zpos);
+
+   regmap_update_bits(mixer->engine.regs,
+  SUN8I_MIXER_BLEND_ROUTE(bld_base),
+  
SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(old_zpos),
+  0);
+
+   regmap_update_bits(mixer->engine.regs,
+  SUN8I_MIXER_BLEND_PIPE_CTL(bld_base),
+  
SUN8I_MIXER_BLEND_PIPE_CTL_EN(old_zpos),
+  0);
+   }
}
 
-   if (enable) {
+   /*
+* If enabling this layer or changin zpos, set route to this layer.
+*/
+   if ((enable && !was_enabled) || (enable && zpos != old_zpos)) {
+   DRM_DEBUG_DRIVER("chan=%d en=%d->%d zpos=%d->%d\n",
+  channel, was_enabled, enable, old_zpos, zpos);
+
val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(zpos);
 
regmap_update_bits(mixer->engine.regs,
@@ -69,6 +99,8 @@ 

Re: [PATCH libdrm] meson: Fix sys/mkdev.h detection on Solaris

2019-09-14 Thread Eric Engestrom
On Friday, 2019-09-13 16:26:55 -0700, Alan Coopersmith wrote:
> On 9/10/19 5:55 AM, Eric Engestrom wrote:
> > On Monday, 2019-09-09 16:51:16 -0700, Alan Coopersmith wrote:
> > > On Solaris, sys/sysmacros.h has long-deprecated copies of major() & 
> > > minor()
> > > but not makedev().  sys/mkdev.h has all three and is the preferred choice.
> > > 
> > > So we check for sys/mkdev.h first, as autoconf's AC_HEADER_MAJOR does.
> > 
> > Reviewed-by: Eric Engestrom 
> > 
> > Alternatively, how about this?
> > ---8<---
> > diff --git a/meson.build b/meson.build
> > index bc5cfc588d0c621a9725..263f691ab2b9107f5be1 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -183,9 +183,14 @@ foreach header : ['sys/sysctl.h', 'sys/select.h', 
> > 'alloca.h']
> > config.set('HAVE_' + header.underscorify().to_upper(),
> >   cc.compiles('#include <@0@>'.format(header), name : '@0@ 
> > works'.format(header)))
> >   endforeach
> > -if cc.has_header_symbol('sys/sysmacros.h', 'major')
> > +if (cc.has_header_symbol('sys/sysmacros.h', 'major') and
> > +  cc.has_header_symbol('sys/sysmacros.h', 'minor') and
> > +  cc.has_header_symbol('sys/sysmacros.h', 'makedev'))
> > config.set10('MAJOR_IN_SYSMACROS', true)
> > -elif cc.has_header_symbol('sys/mkdev.h', 'major')
> > +endif
> > +if (cc.has_header_symbol('sys/mkdev.h', 'major') and
> > +  cc.has_header_symbol('sys/mkdev.h', 'minor') and
> > +  cc.has_header_symbol('sys/mkdev.h', 'makedev'))
> > config.set10('MAJOR_IN_MKDEV', true)
> >   endif
> >   config.set10('HAVE_OPEN_MEMSTREAM', cc.has_function('open_memstream'))
> > --->8---
> > 
> > Makes both checks independent and represent the reality of what's wanted
> > more accurately (despite the historical name of the macro).
> 
> That works:
> 
> Header  has symbol "major" : YES (cached)
> Header  has symbol "minor" : YES
> Header  has symbol "makedev" : NO
> Header  has symbol "major" : YES
> Header  has symbol "minor" : YES
> Header  has symbol "makedev" : YES
> 
> Would you like me to resubmit with that, or do you want to submit it?
> 
> If you want to go ahead, then:
> 
> Reviewed-by: Alan Coopersmith 
> Tested-by: Alan Coopersmith 

Just pushed it as 827a2a2042359ac93a9b082ee9584b43baa1a3f7; thanks for
testing it!

I've also tagged you on a Mesa MR to the same effect, in case you want
to give it a go :)

> 
> -- 
>   -Alan Coopersmith-   alan.coopersm...@oracle.com
>Oracle Solaris Engineering - https://blogs.oracle.com/alanc
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm fixes for 5.3-rc9

2019-09-14 Thread Linus Torvalds
On Thu, Sep 12, 2019 at 8:56 AM Dave Airlie  wrote:
>
> Hey Linus,
>
> From the maintainer summit, just some last minute fixes for final,
> details in the tag.

So because my mailbox was more unruly than normal (because of same
maintainer summit travel), I almost missed this email entirely.

Why? Because you don't have the normal "git pull" anywhere in the
email, so it doesn't trigger my search for important emails.

There's a "git" in the email body, but there's not a "pull" anywhere.
Could you add either a "please pull" or something to the email body -
or to make things _really_ obvious, add the "[GIT PULL]" prefix to the
subject line? Or anything, really, to whatever script or workflow you
use to generate these?

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/2] drm/bridge: Add NWL MIPI DSI host controller support

2019-09-14 Thread Guido Günther
Hi Andrzej,
thanks for having a look!

On Fri, Sep 13, 2019 at 11:31:43AM +0200, Andrzej Hajda wrote:
> On 09.09.2019 04:25, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found on
> > i.MX8 SoCs.
> >
> > It adds support for the i.MX8MQ but the same IP can be found on
> > e.g. the i.MX8QXP.
> >
> > It has been tested on the Librem 5 devkit using mxsfb.
> >
> > Signed-off-by: Guido Günther 
> > Co-developed-by: Robert Chiras 
> > Signed-off-by: Robert Chiras 
> > Tested-by: Robert Chiras 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig   |   2 +
> >  drivers/gpu/drm/bridge/Makefile  |   1 +
> >  drivers/gpu/drm/bridge/nwl-dsi/Kconfig   |  16 +
> >  drivers/gpu/drm/bridge/nwl-dsi/Makefile  |   4 +
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 499 
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h |  65 +++
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 696 +++
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112 
> 
> 
> Why do you need separate files nwl-drv.[ch] and nwl-dsi.[ch] ? I guess
> you can merge all into one file, maybe with separate file for NWL
> register definitions.

Idea is to have driver setup, soc specific hooks and revision specific
quirks in one file and the dsi specific parts in another. If that
doesn't fly I can merge into one if that's a requirement.

> >  8 files changed, 1395 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 1cc9f502c1f2..7980b5c2156f 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
> >  
> >  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> >  
> > +source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
> > +
> >  source "drivers/gpu/drm/bridge/synopsys/Kconfig"
> >  
> >  endmenu
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf5a6f8..d9f6c0f77592 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> >  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> >  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> >  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
> >  obj-y += synopsys/
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig 
> > b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > new file mode 100644
> > index ..7fa678e3b5e2
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > @@ -0,0 +1,16 @@
> > +config DRM_NWL_MIPI_DSI
> > +   tristate "Northwest Logic MIPI DSI Host controller"
> > +   depends on DRM
> > +   depends on COMMON_CLK
> > +   depends on OF && HAS_IOMEM
> > +   select DRM_KMS_HELPER
> > +   select DRM_MIPI_DSI
> > +   select DRM_PANEL_BRIDGE
> > +   select GENERIC_PHY_MIPI_DPHY
> > +   select MFD_SYSCON
> > +   select MULTIPLEXER
> > +   select REGMAP_MMIO
> > +   help
> > + This enables the Northwest Logic MIPI DSI Host controller as
> > + for example found on NXP's i.MX8 Processors.
> > +
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile 
> > b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > new file mode 100644
> > index ..804baf2f1916
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
> > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
> > +header-test-y += nwl-drv.h nwl-dsi.h
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c 
> > b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > new file mode 100644
> > index ..9ff43d2de127
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > @@ -0,0 +1,499 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * i.MX8 NWL MIPI DSI host driver
> > + *
> > + * Copyright (C) 2017 NXP
> > + * Copyright (C) 2019 Purism SPC
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> 
> Alphabetic order

Fixed for v6.

> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "nwl-drv.h"
> > +#include "nwl-dsi.h"
> > +
> > +#define DRV_NAME "nwl-dsi"
> > +
> > +/* Possible platform specific clocks */
> > +#define NWL_DSI_CLK_CORE   "core"
> > +
> > +static const struct regmap_config nwl_dsi_regmap_config = {
> > +   .reg_bits = 

Re: [PATCH 6/9] drm/msm: use drm_debug_enabled() to check for debug categories

2019-09-14 Thread Rob Clark
On Fri, Sep 13, 2019 at 4:52 AM Jani Nikula  wrote:
>
> Allow better abstraction of the drm_debug global variable in the
> future. No functional changes.
>
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Jani Nikula 

Reviewed-by: Rob Clark 

I don't think this should conflict w/ anything, so land via drm-misc?

BR,
-R

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> index 9e40f559c51f..00e3353f9aad 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> @@ -29,7 +29,7 @@
>   */
>  #define DPU_DEBUG(fmt, ...)\
> do {   \
> -   if (unlikely(drm_debug & DRM_UT_KMS))  \
> +   if (unlikely(drm_debug_enabled(DRM_UT_KMS)))   \
> DRM_DEBUG(fmt, ##__VA_ARGS__); \
> else   \
> pr_debug(fmt, ##__VA_ARGS__);  \
> @@ -41,7 +41,7 @@
>   */
>  #define DPU_DEBUG_DRIVER(fmt, ...) \
> do {   \
> -   if (unlikely(drm_debug & DRM_UT_DRIVER))   \
> +   if (unlikely(drm_debug_enabled(DRM_UT_DRIVER)))\
> DRM_ERROR(fmt, ##__VA_ARGS__); \
> else   \
> pr_debug(fmt, ##__VA_ARGS__);  \
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic

2019-09-14 Thread Rob Clark
On Wed, Sep 11, 2019 at 7:39 PM John Stultz  wrote:
>
> On Wed, Sep 4, 2019 at 3:26 AM Andrzej Hajda  wrote:
> > On 03.09.2019 18:18, John Stultz wrote:
> > > On Mon, Sep 2, 2019 at 6:22 AM Andrzej Hajda  wrote:
> > >> On 30.08.2019 19:00, Rob Clark wrote:
> > >>> On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda  
> > >>> wrote:
> >  Of course it seems you have different opinion what is the right thing 
> >  in
> >  this case, so if you convince us that your approach is better one can
> >  revert the patch.
> > >>> I guess my strongest / most immediate opinion is to not break other
> > >>> existing adv75xx bridge users.
> > >>
> > >> It is pity that breakage happened, and next time we should be more
> > >> strict about testing other platforms, before patch acceptance.
> > >>
> > >> But reverting it now will break also platform which depend on it.
> > > I'm really of no opinion of which approach is better here, but I will
> > > say that when a patch breaks previously working boards, that's a
> > > regression and justifying that some other board is now enabled that
> > > would be broken by the revert (of a patch that is not yet upstream)
> > > isn't really a strong argument.
> > >
> > > I'm happy to work with folks to try to fixup the kirin driver if this
> > > patch really is the right approach, but we need someone to do the same
> > > for the db410c, and I don't think its fair to just dump that work onto
> > > folks under the threat of the board breaking.
> >
> >
> > These drivers should be fixed anyway - assumption that
> > drm_bridge/drm_panel will be registered before the bus it is attached to
> > is just incorrect.
> >
> > So instead of reverting, fixing and then re-applying the patch I have
> > gently proposed shorter path. If you prefer long path we can try to go
> > this way.
> >
> > Matt, is the pure revert OK for you or is it possible to prepare some
> > workaround allowing cooperation with both approaches?
>
> Rob/Andrzej: What's the call here?
>
> Should I resubmit the kirin fix for the adv7511 regression here?
> Or do we revert the adv7511 patch? I believe db410c still needs a fix.
>
> I'd just like to keep the HiKey board from breaking, so let me know so
> I can get the fix submitted if needed.
>

Does the kirin fix break things if the adv7511 patch is reverted?  If
not, I'd submit it anyways.

Hopefully by next weekend I'll be finished with my move and unpacked
enough to be able to setup db410c + monitor to start working on fixing
db410c.  So perhaps one option would be to wait a week, and see if I
can come up with something small enough to land as a post-merge-window
fix, with the fallback being to revert and try again next merge
window?

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 111232] 3200 Memory Crash My System

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=111232

--- Comment #8 from bibitocarlos  ---
And cant revert the commit with 5.3, i get git conflict...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100239] Incorrect rendering in CS:GO

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100239

--- Comment #26 from Bruno Jacquet (Xaapyks)  ---
(In reply to Michel Dänzer from comment #25)
> (In reply to Bruno Jacquet (Xaapyks) from comment #23)
> > So I'd say the issue is still there.
> 
> Maybe you have a ~/.drirc or other drirc file which gets picked up and
> disables radeonsi_zerovram? (E.g. due to ever starting the old "driconf"
> application with a driver which supported the option)

~/.drirc and /etc/drirc do not exist on my fs.
/usr/share/drirc.d only contains 00-mesa-defaults.conf which is not modified
from what the mesa build provides and is packaged in Arch.

strace seems to confirm it is not loading any other "drirc" file any and I
don't have any "*MESA*" or "*GL*" env var.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 111685] [Polaris 30] [Bisected] Kernel BUG during boot when amdgpu.dpm=0

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=111685

--- Comment #1 from Omar Ahmad  ---
Created attachment 145360
  --> https://bugs.freedesktop.org/attachment.cgi?id=145360=edit
Full log after the hang

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 111685] [Polaris 30] [Bisected] Kernel BUG during boot when amdgpu.dpm=0

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=111685

Bug ID: 111685
   Summary: [Polaris 30] [Bisected] Kernel BUG during boot when
amdgpu.dpm=0
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: not set
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: omar.squircle...@gmail.com

Created attachment 145359
  --> https://bugs.freedesktop.org/attachment.cgi?id=145359=edit
Bisect log

To reproduce, pass the parameter amdgpu.dpm=0 to a kernel v5.2 or higher. The
kernel will hang at boot. v5.1 boots correctly.

I have bisected the kernel between v5.1 and v5.2, the bisect log is attached
below.

The last three lines from the log are as follow, the full log is attached
below:

kernel: BUG: unable to handle page fault for address: 91fe41bdf5f8
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x) - not-present page

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 204845] New: firmware load failed Ryzen 2500U Raven

2019-09-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=204845

Bug ID: 204845
   Summary: firmware load failed Ryzen 2500U Raven
   Product: Drivers
   Version: 2.5
Kernel Version: 5.2.14
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: tjb...@scarlet.be
Regression: No

Created attachment 284963
  --> https://bugzilla.kernel.org/attachment.cgi?id=284963=edit
full dmesg

Lenovo Thinkpad E585
BIOS R0UET74W (1.54 ) latest

doing a cold start this morning - no video, but waas able to ssh into the
notebook and inspect dmesg data.
doing a warm restart gave the same problem.

After doing halt and power off, the next cold boot worked.
This has happend from time to ime in the past with previous kernels.



Sep 14 08:12:24 [kernel] [1.949510] amdgpu :05:00.0:
remove_conflicting_pci_framebuffers: bar 0: 0xb000 -> 0xbfff
Sep 14 08:12:24 [kernel] [1.949518] amdgpu :05:00.0:
remove_conflicting_pci_framebuffers: bar 2: 0xc000 -> 0xc01f
Sep 14 08:12:24 [kernel] [1.949524] amdgpu :05:00.0:
remove_conflicting_pci_framebuffers: bar 5: 0xc080 -> 0xc087
Sep 14 08:12:24 [kernel] [1.949532] amdgpu :05:00.0: vgaarb: deactivate
vga console
Sep 14 08:12:24 [kernel] [1.949813] [drm] initializing kernel modesetting
(RAVEN 0x1002:0x15DD 0x17AA:0x506F 0xC4).
Sep 14 08:12:24 [kernel] [1.949838] [drm] register mmio base: 0xC080
Sep 14 08:12:24 [kernel] [1.949842] [drm] register mmio size: 524288
Sep 14 08:12:24 [kernel] [1.949864] [drm] add ip block number 0

Sep 14 08:12:24 [kernel] [1.949868] [drm] add ip block number 1 
Sep 14 08:12:24 [kernel] [1.949872] [drm] add ip block number 2 
Sep 14 08:12:24 [kernel] [1.949875] [drm] add ip block number 3 
Sep 14 08:12:24 [kernel] [1.949879] [drm] add ip block number 4 
Sep 14 08:12:24 [kernel] [1.949882] [drm] add ip block number 5 
Sep 14 08:12:24 [kernel] [1.949886] [drm] add ip block number 6 
Sep 14 08:12:24 [kernel] [1.949889] [drm] add ip block number 7 
Sep 14 08:12:24 [kernel] [1.949893] [drm] add ip block number 8 
Sep 14 08:12:24 [kernel] [1.952490] [drm] VCN decode is enabled in VM mode
Sep 14 08:12:24 [kernel] [1.952497] [drm] VCN encode is enabled in VM mode
Sep 14 08:12:24 [kernel] [1.952501] [drm] VCN jpeg decode is enabled in VM
mode
Sep 14 08:12:24 [kernel] [1.987498] [drm] BIOS signature incorrect 0 0
Sep 14 08:12:24 [kernel] [1.989513] ATOM BIOS: 113-RAVEN-107
Sep 14 08:12:24 [kernel] [1.989555] [drm] RAS INFO: ras initialized
successfully, hardware ability[0] ras_mask[0]
Sep 14 08:12:24 [kernel] [1.989562] [drm] vm size is 262144 GB, 4 levels,
block size is 9-bit, fragment size is 9-bit
Sep 14 08:12:24 [kernel] [1.989578] amdgpu :05:00.0: VRAM: 256M
0x00F4 - 0x00F40FFF (256M used)
Sep 14 08:12:24 [kernel] [1.989582] amdgpu :05:00.0: GART: 1024M
0x - 0x3FFF
Sep 14 08:12:24 [kernel] [1.989585] amdgpu :05:00.0: AGP: 267419648M
0x00F8 - 0x
Sep 14 08:12:24 [kernel] [1.989593] [drm] Detected VRAM RAM=256M, BAR=256M
Sep 14 08:12:24 [kernel] [1.989595] [drm] RAM width 64bits DDR4
Sep 14 08:12:24 [kernel] [1.990172] [TTM] Initializing pool allocator
Sep 14 08:12:24 [kernel] [1.990177] [TTM] Initializing DMA pool allocator
Sep 14 08:12:24 [kernel] [1.990210] [drm] amdgpu: 256M of VRAM memory ready
Sep 14 08:12:24 [kernel] [1.990213] [drm] amdgpu: 3072M of GTT memory
ready.
Sep 14 08:12:24 [kernel] [1.990229] [drm] GART: num cpu pages 262144, num
gpu pages 262144
Sep 14 08:12:24 [kernel] [1.990618] [drm] PCIE GART of 1024M enabled (table
at 0x00F40090).
Sep 14 08:12:24 [kernel] [1.998124] [drm] use_doorbell being set to: [true]
Sep 14 08:12:24 [kernel] [2.000501] [drm] Found VCN firmware Version ENC:
1.9 DEC: 1 VEP: 0 Revision: 28
Sep 14 08:12:24 [kernel] [2.000506] [drm] PSP loading VCN firmware
Sep 14 08:12:24 [kernel] [2.023616] [drm] reserve 0x40 from
0xf400c0 for PSP TMR SIZE
Sep 14 08:12:24 [kernel] [2.551302] psmouse serio1: synaptics: queried max
coordinates: x [..5676], y [..4690]
Sep 14 08:12:24 [kernel] [2.602790] psmouse serio1: synaptics: queried min
coordinates: x [1266..], y [1162..]
Sep 14 08:12:24 [kernel] [2.602798] psmouse serio1: synaptics: Trying to
set up SMBus access
Sep 14 08:12:24 [kernel] [2.607101] psmouse serio1: synaptics: SMbus
companion is not ready yet
Sep 14 08:12:24 [kernel] [3.534708] input: PS/2 Synaptics TouchPad as
/devices/platform/i8042/serio1/input/input4
Sep 14 08:12:24 [kernel] [6.547828] mousedev: PS/2 mouse device common for
all mice
Sep 14 08:12:24 [kernel] [ 

[Bug 111684] amdgpu-dkms 19.30-855429 fails to compiler on kernel 5.2

2019-09-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=111684

Bug ID: 111684
   Summary: amdgpu-dkms 19.30-855429 fails to compiler on kernel
5.2
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: not set
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: witold.baryluk+freedesk...@gmail.com

Created attachment 145358
  --> https://bugs.freedesktop.org/attachment.cgi?id=145358=edit
make.log from attempted dkms build of amdgpu

I know it is somehow expected due to very new kernel, but reporting anyway, as
maybe it is related to something else than new kernel.

root@debian:/var/lib/dkms/amdgpu/19.30-855429/build# grep error make.log
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_drv.c:1238:2: error:
implicit declaration of function ‘drm_kms_helper_poll_disable’; did you mean
‘drm_fb_helper_pan_display’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_connectors.c:735:7:
error: implicit declaration of function ‘drm_kms_helper_is_poll_worker’; did
you mean ‘drm_fb_helper_initial_config’?
[-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_device.c:1021:3:
error: implicit declaration of function ‘drm_kms_helper_poll_enable’; did you
mean ‘drm_fb_helper_fill_info’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_drv.c:1277:2: error:
implicit declaration of function ‘drm_kms_helper_poll_enable’; did you mean
‘drm_fb_helper_fill_info’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_connectors.c:835:16:
error: ‘drm_helper_probe_single_connector_modes’ undeclared here (not in a
function); did you mean ‘drm_helper_move_panel_connectors_to_head’?
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_drv.c:1453:21: error:
‘DRIVER_IRQ_SHARED’ undeclared here (not in a function); did you mean
‘TIMER_IRQSAFE’?
cc1: some warnings being treated as errors
cc1: some warnings being treated as errors
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_device.c:1024:3:
error: implicit declaration of function ‘drm_kms_helper_poll_disable’; did you
mean ‘drm_fb_helper_pan_display’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_device.c:2846:4:
error: implicit declaration of function ‘drm_crtc_force_disable_all’; did you
mean ‘drm_helper_force_disable_all’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_device.c:3110:3:
error: implicit declaration of function ‘drm_helper_hpd_irq_event’; did you
mean ‘drm_fb_helper_hotplug_event’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_device.c:3112:3:
error: implicit declaration of function ‘drm_kms_helper_hotplug_event’; did you
mean ‘drm_fb_helper_hotplug_event’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_fb.c:270:2: error:
implicit declaration of function ‘drm_fb_helper_fill_fix’; did you mean
‘drm_fb_helper_fill_info’? [-Werror=implicit-function-declaration]
/var/lib/dkms/amdgpu/19.30-855429/build/amd/amdgpu/amdgpu_fb.c:281:2: error:
implicit declaration of function ‘drm_fb_helper_fill_var’; did you mean
‘drm_fb_helper_fill_info’? [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
cc1: some warnings being treated as errors
root@debian:/var/lib/dkms/amdgpu/19.30-855429/build#  


root@debian:/var/lib/dkms/amdgpu/19.30-855429/build# dpkg -l | grep linux-head
ii  linux-headers-5.2.0-2-amd64 5.2.9-2
  amd64Header files for Linux 5.2.0-2-amd64
ii  linux-headers-5.2.0-2-common5.2.9-2
  all  Common header files for Linux 5.2.0-2
ii  linux-headers-amd64 5.2+106
  amd64Header files for Linux amd64 configuration
(meta-package)


gcc version 9.2.1 20190821 (Debian 9.2.1-4) 

Full make.log in the attachment.

Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel