[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105760

--- Comment #14 from mathieu.dut...@gmail.com  ---
Thanks, but no time for that.
Reverted to 17.10

Le lun. 25 juin 2018 à 00:31,  a écrit :

> *Comment # 13  on
> bug 105760  from
> taij...@posteo.de  *
>
> Have you tried again on any of the 4.18rc? I am currently testing 4.18-rc2 and
> altough I have some other bug there, this one seems to be gone for me.
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

-- 
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: linux-next: build warning after merge of the drm tree

[Stephen Rothwell]

Hi all,

On Mon, 25 Jun 2018 14:22:07 +1000 Stephen Rothwell  
wrote:
>
> Hi Paul,
 
Hmm, not Paul at all :-)

-- 
Cheers,
Stephen Rothwell


pgpyQcUemQHUo.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: build warning after merge of the drm tree

[Stephen Rothwell]

Hi Paul,

After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/gpu/drm/gma500/mdfld_intel_display.c: In function 
'mdfld__intel_pipe_set_base':
drivers/gpu/drm/gma500/mdfld_intel_display.c:170:26: warning: unused variable 
'psbfb' [-Wunused-variable]
  struct psb_framebuffer *psbfb = to_psb_fb(fb);
  ^

Introduced by commit

  c7cbed560ce2 ("drm/gma500: Fix Medfield for drm_framebuffer move")

-- 
Cheers,
Stephen Rothwell


pgp1lT44SIwrC.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate

[Chen-Yu Tsai]

On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
 wrote:
> Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
>> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
>> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec 
>>
>> wrote:
>> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
>> > >> 
>> > >
>> > > wrote:
>> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> napisal(a):
>> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> > >> >>
>> > >> >>  wrote:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>>
>> napisal(a):
>> > >> >> >> Hi,
>> > >> >> >>
>> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
>> > >> >> >> > in
>> > >> >> >> > order
>> > >> >> >> > to work.
>> > >> >> >> >
>> > >> >> >> > Add support for such TCONs.
>> > >> >> >> >
>> > >> >> >> > Signed-off-by: Jernej Skrabec 
>> > >> >> >> > ---
>> > >> >> >> >
>> > >> >> >> >  drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++
>> > >> >> >> >  drivers/gpu/drm/sun4i/sun4i_tcon.h |  4 
>> > >> >> >> >  2 files changed, 15 insertions(+)
>> > >> >> >> >
>> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> > >> >> >> > 08747fc3ee71..0afb5a94a414
>> > >> >> >> > 100644
>> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
>> > >> >> >> > device
>> > >> >> >> > *dev,
>> > >> >> >> >
>> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > >> >> >> > return PTR_ERR(tcon->clk);
>> > >> >> >> >
>> > >> >> >> > }
>> > >> >> >> >
>> > >> >> >> > +
>> > >> >> >> > +   if (tcon->quirks->has_tcon_top_gate) {
>> > >> >> >> > +   tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > >> >> >> > +   if (IS_ERR(tcon->top_clk)) {
>> > >> >> >> > +   dev_err(dev, "Couldn't get the TCON TOP bus
>> > >> >> >> > clock\n");
>> > >> >> >> > +   return PTR_ERR(tcon->top_clk);
>> > >> >> >> > +   }
>> > >> >> >> > +   clk_prepare_enable(tcon->top_clk);
>> > >> >> >> > +   }
>> > >> >> >> > +
>> > >> >> >>
>> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
>> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
>> > >> >> >> functional?
>> > >> >> >>
>> > >> >> >> I find it quite odd to have a clock that isn't meant for a
>> > >> >> >> particular
>> > >> >> >> device to actually be wired to another device. I'm not saying
>> > >> >> >> this
>> > >> >> >> isn't the case, but it would be a first.
>> > >> >> >
>> > >> >> > Documentation doesn't say much about that gate. I did few tests
>> > >> >> > and
>> > >> >> > TCON
>> > >> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> > >> >> > disabled. However, there is no image, as expected.
>> > >> >>
>> > >> >> The R40 manual does include it in the diagram, on page 504. There's
>> > >> >> also
>> > >> >> a
>> > >> >> mux to select whether the clock comes directly from the CCU or the
>> > >> >> TV
>> > >> >> encoder (a feedback mode?). I assume this is the gate you are
>> > >> >> referring
>> > >> >> to
>> > >> >> here, in which case it is not a bus clock, but rather the TCON
>> > >> >> module
>> > >> >> or
>> > >> >> channel clock, strangely routed.
>> > >> >>
>> > >> >> > More interestingly, I enabled test pattern directly in TCON to
>> > >> >> > eliminate
>> > >> >> > influence of the mixer. As soon as I disabled that gate, test
>> > >> >> > pattern
>> > >> >> > on
>> > >> >> > HDMI screen was gone, which suggest that this gate influences
>> > >> >> > something
>> > >> >> > inside TCON.
>> > >> >> >
>> > >> >> > Another test I did was that I moved enable/disable gate code to
>> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> > >> >> >
>> > >> >> > I'll ask AW engineer what that gate actually does, but from what I
>> > >> >> > saw,
>> > >> >> > I
>> > >> >> > would say that most appropriate location to enable/disable TCON
>> > >> >> > TOP
>> > >> >> > TV
>> > >> >> > TCON
>> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
>> > >> >> > any
>> > >> >> > TV
>> > >> >> > TCON is in use and enable appropriate gate. However, that doesn't
>> > >> >> > sound
>> > >> >> > right to me for some reason.
>> > >> >>
>> > >> >> If what I said above it true, then yes, the appropriate location to
>> > >> >> enable
>> > >> >> it is the TCON driver, but moreover, the representation of the clock
>> > >> >> tree
>> > >> >> should be fixed such that the TCON takes the clock from the TCON TOP
>> > >> >> 

Re: [PATCH v2 01/10] drm/exynos: rename "bridge_node" to "mic_bridge_node"

[Inki Dae]

Hi,

I will start to review patch sets for -fixes first so I queued your four 
patches and you can check exynos-drm-next-todo branch for it.

Thanks,
Inki Dae

2018년 05월 30일 21:15에 Maciej Purski 이(가) 쓴 글:
> When adding support for peripheral out bridges, the "bridge" name
> becomes imprecise as it refers to a different device than the
> "out_bridge".
> 
> Signed-off-by: Maciej Purski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index eae44fd..9599e6b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -279,7 +279,7 @@ struct exynos_dsi {
>   struct list_head transfer_list;
>  
>   const struct exynos_dsi_driver_data *driver_data;
> - struct device_node *bridge_node;
> + struct device_node *mic_bridge_node;
>  };
>  
>  #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
> @@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>   if (ret < 0)
>   return ret;
>  
> - dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
> + dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>  
>   return 0;
>  }
> @@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
> device *master,
>   struct drm_encoder *encoder = dev_get_drvdata(dev);
>   struct exynos_dsi *dsi = encoder_to_dsi(encoder);
>   struct drm_device *drm_dev = data;
> - struct drm_bridge *bridge;
> + struct drm_bridge *mic_bridge;
>   int ret;
>  
>   drm_encoder_init(drm_dev, encoder, _dsi_encoder_funcs,
> @@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct 
> device *master,
>   return ret;
>   }
>  
> - if (dsi->bridge_node) {
> - bridge = of_drm_find_bridge(dsi->bridge_node);
> - if (bridge)
> - drm_bridge_attach(encoder, bridge, NULL);
> + if (dsi->mic_bridge_node) {
> + mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
> + if (mic_bridge)
> + drm_bridge_attach(encoder, mic_bridge, NULL);
>   }
>  
>   return mipi_dsi_host_register(>dsi_host);
> @@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device 
> *pdev)
>  {
>   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>  
> - of_node_put(dsi->bridge_node);
> + of_node_put(dsi->mic_bridge_node);
>  
>   pm_runtime_disable(>dev);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107021] AMDGPU crash when Power Management switches off screen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107021

Bug ID: 107021
   Summary: AMDGPU crash when Power Management switches off screen
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: frikr...@gmail.com

Created attachment 140310
  --> https://bugs.freedesktop.org/attachment.cgi?id=140310=edit
Trace from dmesg

With "Screen Energy Saving" selected in KDE, my screen does not return to
active state when I use the keyboard or mouse. Instead, the screen remains
blank indefinitely, until system restart or Xorg is killed. This has occurred
in Gnome as well as KDE Plasma 5.13. Each time this occurs, dmesg shows a trace
similar to the one attached. The system only seems to lock when screen is
blanked by power management and I am able to eventually recover by SSHing in
and killing Xorg/SDDM. I have not experienced any issues with "Screen Energy
Saving" disabled.

Steps to reproduce:

1. Enable "Screen Energy Saving" in KDE (or it's Gnome equivalent).
2. Wait time specified and system will not return from screen sleep state.

Other relevant information:

Linux: Arch Linux
Kernel: 4.17.2
AMDGPU: 18.0.1
Xorg: 1.20.0
Hardware:
Motherboard: ROG CROSSHAIR VII HERO, BIOS 0702 05/29/2018
GPU: Radeon RX Vega 64

-- 
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

linux-next: build failure after merging the drm tree

[Stephen Rothwell]

Hi all,

After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

samples/vfio-mdev/mbochs.c:827:3: error: 'struct dma_buf_ops' has no member 
named 'map_atomic'
  .map_atomic   = mbochs_kmap_atomic_dmabuf,
   ^~
samples/vfio-mdev/mbochs.c:827:18: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  .map_atomic   = mbochs_kmap_atomic_dmabuf,
  ^
samples/vfio-mdev/mbochs.c:827:18: note: (near initialization for 
'mbochs_dmabuf_ops')
samples/vfio-mdev/mbochs.c:827:18: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
samples/vfio-mdev/mbochs.c:827:18: note: (near initialization for 
'mbochs_dmabuf_ops.unmap')

Caused by commit

  f664a5269542 ("dma-buf: remove kmap_atomic interface")

interacting with commit

  a5e6e6505f38 ("sample: vfio bochs vbe display (host device for bochs-drm)")

from Linus' tree (v4.18-rc1).

I added the following just to disable the sample code until it can
be repaired.

From: Stephen Rothwell 
Date: Mon, 25 Jun 2018 11:11:38 +1000
Subject: [PATCH] sample: disable the VFIO mdpy example mediated device sample 
code

it was broken by the removal of the dmap-buf kmap_atomic interface.

Signed-off-by: Stephen Rothwell 
---
 samples/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/samples/Kconfig b/samples/Kconfig
index bd133efc1a56..84bf618ad628 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -135,6 +135,7 @@ config SAMPLE_VFIO_MDEV_MDPY_FB
 config SAMPLE_VFIO_MDEV_MBOCHS
tristate "Build VFIO mdpy example mediated device sample code -- 
loadable modules only"
depends on VFIO_MDEV_DEVICE && m
+   depends on BROKEN
select DMA_SHARED_BUFFER
help
  Build a virtual display sample driver for use as a VFIO
-- 
2.17.1

-- 
Cheers,
Stephen Rothwell


pgpUZOaqk28om.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/etnaviv: Fix driver unregistering

[Fabio Estevam]

From: Fabio Estevam 

Russell King reported:

"When removing and reloading the etnaviv module, the following splat
occurs:

sysfs: cannot create duplicate filename '/devices/platform/etnaviv'
CPU: 0 PID: 1471 Comm: modprobe Not tainted 4.17.0+ #1608
Hardware name: Marvell Dove (Cubox)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r6:ef033e38 r5:ee07b340 r4:edb9d000 r3:
[] (show_stack) from [] (dump_stack+0x20/0x28)
[] (dump_stack) from [] (sysfs_warn_dup+0x5c/0x70)
[] (sysfs_warn_dup) from [] (sysfs_create_dir_ns+0x90/0x98)
..."

Commit 246774d17fc0 ("drm/etnaviv: remove the need for a gpu-subsystem
DT node") introduced DRM registration via
platform_device_register_simple(), but missed to call
platform_device_unregister() inside etnaviv_exit().

Fix the problem by calling platform_device_unregister() inside
etnaviv_exit(). While at it, also rearrange the function calls
in the exit path to make them happen in the opposite order of
registration.

Tested on a imx6-sabresd board.

Cc: 
Fixes: 246774d17fc0 ("drm/etnaviv: remove the need for a gpu-subsystem DT node")
Reported-by: Russell King 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Make the exit path symmetrical to the init path by calling
platform_device_unregister() inside for_each_compatible_node()

 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index e5013a9..626ad8b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -631,6 +631,8 @@ static struct platform_driver etnaviv_platform_driver = {
},
 };
 
+static struct platform_device *etnaviv_drm;
+
 static int __init etnaviv_init(void)
 {
int ret;
@@ -654,7 +656,8 @@ static int __init etnaviv_init(void)
if (!of_device_is_available(np))
continue;
 
-   platform_device_register_simple("etnaviv", -1, NULL, 0);
+   etnaviv_drm = platform_device_register_simple("etnaviv", -1,
+ NULL, 0);
of_node_put(np);
break;
}
@@ -665,8 +668,19 @@ module_init(etnaviv_init);
 
 static void __exit etnaviv_exit(void)
 {
-   platform_driver_unregister(_gpu_driver);
+   struct device_node *np;
+
+   for_each_compatible_node(np, NULL, "vivante,gc") {
+   if (!of_device_is_available(np))
+   continue;
+
+   platform_device_unregister(etnaviv_drm);
+   of_node_put(np);
+   break;
+   }
+
platform_driver_unregister(_platform_driver);
+   platform_driver_unregister(_gpu_driver);
 }
 module_exit(etnaviv_exit);
 
-- 
2.7.4

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

[Bug 107020] Dolphin freezes only with OpenGL

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107020

--- Comment #1 from John  ---
Tested Dolphin Versions 
4.0 6223 
5.0 8155 
5.0 7309

-- 
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 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105760

--- Comment #13 from taij...@posteo.de ---
Have you tried again on any of the 4.18rc? I am currently testing 4.18-rc2 and
altough I have some other bug there, this one seems to be gone for me.

-- 
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 107020] Dolphin freezes only with OpenGL

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107020

Bug ID: 107020
   Summary: Dolphin freezes only with OpenGL
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: johnpaul...@yahoo.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 140309
  --> https://bugs.freedesktop.org/attachment.cgi?id=140309=edit
Xorg log following the freeze

I launch any game in dolphin and after playing a few minutes it will freeze,
forcing me to terminate the application. If I switch the Backend APi to Vulkan
there is no problems.

CPU:AMD 1950x 16core
ram: (32GB)3200mhz
GPU: AMD Vega 64

Linux Distro: Manjaro

-- 
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 106263] amdgpu produces several stracktraces (Fiji, Bonaire) at boot since kernel 4.16.4

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106263

--- Comment #7 from erhar...@mailbox.org ---
Issue still persent on 4.17.2.

-- 
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 102372] [dc] [kabini] Errors during startup - X doesn't start

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102372

--- Comment #13 from Lyude Paul  ---
Poke: this should be reverted, as mentioned in IRC enabling DC has
unfortunately broken the displays on this TONGA GPU as well. GPU info:

[AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] (rev f1)

more info
https://people.freedesktop.org/~lyudess/archive/06-24-2018/4.17-rc-breaks-lyude-machine.txt

-- 
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 106957] GPU runtime suspend broken since 4.17

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106957

--- Comment #10 from Lukas Wunner  ---
It looks like no pull request was sent out for the sound subsystem this week,
so I'm afraid the fix will not appear in mainline earlier than 4.18-rc3.

-- 
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 V3 5/7] backlight: qcom-wled: Add support for WLED4 peripheral

[Bjorn Andersson]

On Wed 20 Jun 04:00 PDT 2018, kgu...@codeaurora.org wrote:

> On 2018-06-20 10:44, Bjorn Andersson wrote:
> > On Tue 19 Jun 04:13 PDT 2018, Kiran Gunda wrote:
> > 
> > > WLED4 peripheral is present on some PMICs like pmi8998 and
> > > pm660l. It has a different register map and configurations
> > > are also different. Add support for it.
> > > 
> > > Signed-off-by: Kiran Gunda 
> > > ---
> > >  drivers/video/backlight/qcom-wled.c | 635
> > > 
> > >  1 file changed, 503 insertions(+), 132 deletions(-)
> > 
> > Split this further into a patch that does structural preparation of
> > WLED3 support and then an addition of WLED4, the mixture makes parts of
> > this patch almost impossible to review. Please find some comments below.
> > 
> Sure. I will split it in the next series.

Thanks!

> > > 
> > > diff --git a/drivers/video/backlight/qcom-wled.c
> > > b/drivers/video/backlight/qcom-wled.c
> > [..]
> > > 
> > >  /* WLED3 sink registers */
> > >  #define WLED3_SINK_REG_SYNC  0x47
> > 
> > Drop the 3 from this if it's common between the two.
> > 
> > > -#define  WLED3_SINK_REG_SYNC_MASK0x07
> > > +#define  WLED3_SINK_REG_SYNC_MASKGENMASK(2, 0)
> > > +#define  WLED4_SINK_REG_SYNC_MASKGENMASK(3, 0)
> > >  #define  WLED3_SINK_REG_SYNC_LED1BIT(0)
> > >  #define  WLED3_SINK_REG_SYNC_LED2BIT(1)
> > >  #define  WLED3_SINK_REG_SYNC_LED3BIT(2)
> > > +#define  WLED4_SINK_REG_SYNC_LED4BIT(3)
> > >  #define  WLED3_SINK_REG_SYNC_ALL 0x07
> > > +#define  WLED4_SINK_REG_SYNC_ALL 0x0f
> > >  #define  WLED3_SINK_REG_SYNC_CLEAR   0x00
> > > 
> > [..]
> > > +static int wled4_set_brightness(struct wled *wled, u16 brightness)
> > 
> > Afaict this is identical to wled3_set_brightness() with the exception
> > that there's a minimum brightness and the base address for the
> > brightness registers are different.
> > 
> > I would suggest that you add a min_brightness to wled and that you
> > figure out a way to carry the brightness base register address; and by
> > that you squash these two functions.
> > 
> There are four different parameters. 1) minimum brightness 2) WLED base
> addresses
> 3) Brightness base addresses 4) the brightness sink registers address
> offsets also
> different for wled 3 and wled4. (in wled3 0x40, 0x42, 0x44, where as in
> wled4 0x57, 0x67, 0x77, 0x87).
> 

Sorry, I must have gotten lost in the defines, I see the difference
between the two register layouts now. If you retain the old mechanism of
doing the math openly in the function this would have been obvious.

> Irrelevant to this patch, but wled5 has some more extra registers to
> set the brightness.  Keeping this in mind, it is better to have
> separate functions? Otherwise we will have to use the version checks
> in the wled_set_brightness function, if we have the common function.

Okay, so it sounds reasonable to split this out to some degree.

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

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Ard Biesheuvel]

On 22 June 2018 at 20:30, Sinan Kaya  wrote:
> On 6/22/2018 2:01 PM, Ard Biesheuvel wrote:
>>> Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is
>>> described as
>>>
>>> """
>>> Base address of graphics linear frame buffer. Info contains
>>> information required to allow software to draw directly to the
>>> frame buffer without using Blt().Offset zero in
>>> FrameBufferBase represents the upper left pixel of the
>>> display.
>>> """
>> I just tried AMD Radeon and NVidia graphics cards on a system with
>> non-1:1 mapped MMIO windows, and in both cases, the GOP protocol
>> structure is populated correctly, i.e., using the CPU address not the
>> PCIe address.
>>
>> EDK2 only recently gained support for MMIO translation in the host
>> bridge driver, so I so wonder if this is a platform issue rather than
>> a driver issue. It may be worth a try to dump the results of
>> GetBarAttributes() of all PCI I/O protocol instances (either in UEFI
>> or in the stub), to double check that the correct values are returned.
>>
>
> Thanks for checking out other platforms. I'll mark the issue as a BIOS
> issue and bounce your feedback to the BIOS provider.
>

I screwed up my testing, unfortunately. Both the public AMD GOP driver
I tried, and the Nvidia GT218 under x86 emulation break when using
MMIO translation. However, GraphicsOutputDxe in the EDK2 tree gets it
right, and uses PciIo->GetBarAttributes() to get the address of the
framebuffer region, which will return the CPU address not the PCI
address.

> Let's hold onto this patch for the moment.
>

Yes. I'd like to get this resolved as well, but if the drivers are
dereferencing BAR values as CPU addresses, this is unlikely to be the
only thing that is broken under outbound translation.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH] drm/nouveau/secboot/acr: Remove VLA usage

[Kees Cook]

On Fri, Jun 22, 2018 at 10:50 AM, Karol Herbst  wrote:
> On Thu, May 24, 2018 at 7:24 PM, Kees Cook  wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> allocates the working buffers before starting the writing so it won't
>> abort in the middle. This needs an initial walk of the lists to figure
>> out how large the buffer should be.
>>
>> [1] 
>> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>>
>> Signed-off-by: Kees Cook 
>> ---
>>  .../nouveau/nvkm/subdev/secboot/acr_r352.c| 25 ---
>>  .../nouveau/nvkm/subdev/secboot/acr_r367.c| 16 +++-
>>  2 files changed, 37 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c 
>> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>> index a721354249ce..d02e183717dc 100644
>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>> @@ -414,6 +414,20 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct 
>> list_head *imgs,
>>  {
>> struct ls_ucode_img *_img;
>> u32 pos = 0;
>> +   u32 max_desc_size = 0;
>> +   u8 *gdesc;
>> +
>> +   /* Figure out how large we need gdesc to be. */
>> +   list_for_each_entry(_img, imgs, node) {
>> +   const struct acr_r352_ls_func *ls_func =
>> +   
>> acr->func->ls_func[_img->falcon_id];
>> +
>> +   max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
>> +   }
>> +
>> +   gdesc = kmalloc(max_desc_size, GFP_KERNEL);
>> +   if (!gdesc)
>> +   return -ENOMEM;
>>
>> nvkm_kmap(wpr_blob);
>>
>> @@ -421,7 +435,6 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct 
>> list_head *imgs,
>> struct ls_ucode_img_r352 *img = ls_ucode_img_r352(_img);
>> const struct acr_r352_ls_func *ls_func =
>> 
>> acr->func->ls_func[_img->falcon_id];
>> -   u8 gdesc[ls_func->bl_desc_size];
>>
>
> if there are no guarantees that (ls_func->bl_desc_size & 0x4 == 0),
> then we need to memset a bit more, because 4 bytes at the time are
> actually copied inside nvkm_gpuobj_memcpy_to later in that code, but
> the last 4 bytes are only partly memset to 0.

I think this is unchanged from the original code, yes? The memset() is
always against bl_desc_size; I haven't changed that.

> If ls_func->bl_desc_size is always a multiple of 0x4, then it isn't as
> important, but still better to be fixed. Or maybe
> nvkm_gpuobj_memcpy_to should do that handling and check if the size is
> a multiple of 0x4 and otherwise handle that case?
>
> Same is valid for the changes in the r367 file.

Should I resend with both the allocation and the memset getting
rounded up to the next multiple of 4?

-Kees

-- 
Kees Cook
Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Ard Biesheuvel]

On 22 June 2018 at 15:55, Ard Biesheuvel  wrote:
> On 22 June 2018 at 15:52, Sinan Kaya  wrote:
>> Hi Ard,
>>
>> On 6/22/2018 7:21 AM, Ard Biesheuvel wrote:
>>> Apologies for only bringing this up now, but I think this patch is
>>> wrong after all.
>>>
>>> screen_info.lfb_base is supposed to be a CPU address, and so
>>> translating it like this is wrong. If you end up with a PCI address
>>> here, you have made a mistake in hacking support for PCI outbound
>>> translations into UEFI. Other users such as UEFI itself or GRUB will
>>> treat this as a CPU physical address as well, so the kernel should not
>>> treat it any differently.
>>
>> The behavior I'm seeing is from a UEFI BIOS vendor. I did not write the
>> code for it...
>>
>> I was asked to debug it.
>>
>> I'd like to dive into your statement about UEFI and GRUB using this address
>> as physical addresses.
>>
>> AFAIK, all PCI outbound requests go through PCI IO protocol in UEFI and the
>> translation information is hidden inside the UEFI PCI Host Bridge driver.
>> Drivers are not allowed to access PCI resources directly especially as a
>> memory mapped address.
>>
>> This particular vendor is programming the BAR address into the GOP protocol.
>> Since the host bridge driver is doing a translation, we are hitting this
>> issue.
>>
>> Is there a UEFI spec reference about the definition of this field?
>>
>
> Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is
> described as
>
> """
> Base address of graphics linear frame buffer. Info contains
> information required to allow software to draw directly to the
> frame buffer without using Blt().Offset zero in
> FrameBufferBase represents the upper left pixel of the
> display.
> """

I just tried AMD Radeon and NVidia graphics cards on a system with
non-1:1 mapped MMIO windows, and in both cases, the GOP protocol
structure is populated correctly, i.e., using the CPU address not the
PCIe address.

EDK2 only recently gained support for MMIO translation in the host
bridge driver, so I so wonder if this is a platform issue rather than
a driver issue. It may be worth a try to dump the results of
GetBarAttributes() of all PCI I/O protocol instances (either in UEFI
or in the stub), to double check that the correct values are returned.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Sinan Kaya]

On 6/22/2018 2:01 PM, Ard Biesheuvel wrote:
>> Yes, it is part of the PCI I/O protocol definition. FrameBufferBase is
>> described as
>>
>> """
>> Base address of graphics linear frame buffer. Info contains
>> information required to allow software to draw directly to the
>> frame buffer without using Blt().Offset zero in
>> FrameBufferBase represents the upper left pixel of the
>> display.
>> """
> I just tried AMD Radeon and NVidia graphics cards on a system with
> non-1:1 mapped MMIO windows, and in both cases, the GOP protocol
> structure is populated correctly, i.e., using the CPU address not the
> PCIe address.
> 
> EDK2 only recently gained support for MMIO translation in the host
> bridge driver, so I so wonder if this is a platform issue rather than
> a driver issue. It may be worth a try to dump the results of
> GetBarAttributes() of all PCI I/O protocol instances (either in UEFI
> or in the stub), to double check that the correct values are returned.
> 

Thanks for checking out other platforms. I'll mark the issue as a BIOS
issue and bounce your feedback to the BIOS provider.

Let's hold onto this patch for the moment.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107015] The GPU Vega 56 randomly hang while I playing in the Mad Max game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107015

--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Created attachment 140302
  --> https://bugs.freedesktop.org/attachment.cgi?id=140302=edit
place 3

-- 
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 107015] The GPU Vega 56 randomly hang while I playing in the Mad Max game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107015

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 140301
  --> https://bugs.freedesktop.org/attachment.cgi?id=140301=edit
place 2

-- 
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 107015] The GPU Vega 56 randomly hang while I playing in the Mad Max game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107015

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
Created attachment 140300
  --> https://bugs.freedesktop.org/attachment.cgi?id=140300=edit
place 1

-- 
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 107015] The GPU Vega 56 randomly hang while I playing in the Mad Max game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107015

Bug ID: 107015
   Summary: The GPU Vega 56 randomly hang  while I playing in the
Mad Max game
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

$ inxi -bM
System:Host: localhost.localdomain Kernel: 4.18.0-0.rc0.git9.1.fc29.x86_64
x86_64 bits: 64
   Desktop: Gnome 3.29.2 Distro: Fedora release 29 (Rawhide)
Machine:   Device: desktop System: Gigabyte product: Z87M-D3H serial: N/A
   Mobo: Gigabyte model: Z87M-D3H serial: N/A UEFI: American Megatrends
v: F11 date: 08/12/2014
Batteryhidpp__0: charge: N/A condition: NA/NA Wh
CPU:   Quad core Intel Core i7-4770 (-MT-MCP-) speed/max: 3699/3900 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Vega 10 XT [Radeon RX Vega
64]
   Display Server: wayland (X.org 12 ) drivers: modesetting,fbdev,vesa
Resolution: 3840x2160@59.98hz
   OpenGL: renderer: Radeon RX Vega (VEGA10, DRM 3.26.0,
4.18.0-0.rc0.git9.1.fc29.x86_64, LLVM 6.0.1)
   version: 4.5 Mesa 18.1.2
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller driver: r8169
Drives:HDD Total Size: 16241.0GB (24.7% used)
Info:  Processes: 415 Uptime: 4:20 Memory: 17322.8/32036.9MB Client: Shell
(bash) inxi: 2.3.56 


[26824.860113] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=12904377, last emitted seq=12904379
[26824.860141] [drm] GPU recovery disabled.
[26869.094908] sysrq: SysRq : Show Blocked State
[26869.095021]   taskPC stack   pid father
[26869.095488] kworker/u16:0   D12040 10033  2 0x8000
[26869.095511] Workqueue: events_unbound commit_work [drm_kms_helper]
[26869.095514] Call Trace:
[26869.095519]  ? __schedule+0x2e2/0xb00
[26869.095525]  ? dma_fence_default_wait+0x231/0x370
[26869.095527]  schedule+0x2f/0x90
[26869.095529]  schedule_timeout+0x35c/0x520
[26869.095533]  ? find_held_lock+0x34/0xa0
[26869.095538]  ? mark_held_locks+0x57/0x80
[26869.095550]  ? _raw_spin_unlock_irqrestore+0x4b/0x60
[26869.09]  ? dma_fence_default_wait+0x231/0x370
[26869.095557]  dma_fence_default_wait+0x25d/0x370
[26869.095560]  ? dma_fence_release+0x160/0x160
[26869.095564]  dma_fence_wait_timeout+0x4f/0x270
[26869.095568]  reservation_object_wait_timeout_rcu+0x236/0x4e0
[26869.095635]  amdgpu_dm_do_flip+0x112/0x350 [amdgpu]
[26869.095678]  amdgpu_dm_atomic_commit_tail+0x6f2/0xd00 [amdgpu]
[26869.095723]  commit_tail+0x3d/0x70 [drm_kms_helper]
[26869.095727]  process_one_work+0x27d/0x650
[26869.095746]  worker_thread+0x3c/0x390
[26869.095752]  ? process_one_work+0x650/0x650
[26869.095755]  kthread+0x120/0x140
[26869.095758]  ? kthread_create_worker_on_cpu+0x70/0x70
[26869.095763]  ret_from_fork+0x3a/0x50

This hangs occurred in different places, see screenshots.
But every time when I overplayed, I could not reproduce hang again, unlike this
issue (https://bugs.freedesktop.org/show_bug.cgi?id=106877) the game Rise of
the Tomb Raider the hang is reproduced 100%.

-- 
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 107015] The GPU Vega 56 randomly hang while I playing in the Mad Max game

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107015

--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 140299
  --> https://bugs.freedesktop.org/attachment.cgi?id=140299=edit
dmesg

-- 
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 105273] [r350] missing background, transparency not working & other glitches in ETR (AGP, ppc, mesa-18.1.2)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105273

erhar...@mailbox.org changed:

   What|Removed |Added

Summary|[r350] missing background,  |[r350] missing background,
   |transparency not working &  |transparency not working &
   |other glitches in ETR (AGP, |other glitches in ETR (AGP,
   |ppc, mesa-18.0.0_rc4)   |ppc, mesa-18.1.2)

--- Comment #7 from erhar...@mailbox.org ---
Tried mesa-18.1.2 but still no luck.

$ glxinfo | grep -i opengl
r300: DRM version: 2.50.0, Name: ATI R350, ID: 0x4e48, GB: 2, Z: 1
r300: GART size: 253 MB, VRAM size: 256 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: ATI R350
OpenGL version string: 2.1 Mesa 18.1.2
OpenGL shading language version string: 1.20
OpenGL extensions:
r300: DRM version: 2.50.0, Name: ATI R350, ID: 0x4e48, GB: 2, Z: 1
r300: GART size: 253 MB, VRAM size: 256 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106258

--- Comment #40 from Timothy Pearson  ---
(In reply to foxbat from comment #39)
> (In reply to Michel Dänzer from comment #35)
> > Created attachment 140257 [details] [review] [review]
> > drm/amdgpu: GPU vs CPU page size fixes in  amdgpu_vm_bo_split_mapping
> > 
> > Does this patch help?
> 
> Hi Michel,
> 
> I have applied the patch and so far it appears to help a lot. I have not
> been able to reproduce any amdgpu crashes/errors so far. I will continue
> running with the patch and let you know if I have any issues.

I can confirm that Michel's patch, along with the following patches, also
enable full 3D acceleration via 64-bit DMA across a wide range of tested
applications:

https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-June/174985.html

https://scm.raptorengineering.com/scm/#changesetPanel;6IQvJHpVSM;578e2d761554130f7c6abfe821c2509912a00ac6;commit

https://scm.raptorengineering.com/scm/#changesetPanel;6IQvJHpVSM;461333cedd470140eb1e1667608da2a6d65a58e5;commit

https://bugs.freedesktop.org/show_bug.cgi?id=107012

All of these patches have been submitted upstream to the respective maintainers
for review.  When Michel's is submitted and merged, we should try to get some
of this downstream into the various distros as well.

-- 
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 199749] amdgpu on Ryzen 2400G freeze randomly

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199749

--- Comment #15 from notsyncing (song...@gmail.com) ---
Still freezed under two Android source compilation + 2 intellij idea + 10
firefox tabs + EVE online playing after 3 hours. Sysrq does not work, need hard
reset. No log was recorded.

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