[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from Alex Deucher  ---
Created attachment 115885
  --> https://bugs.freedesktop.org/attachment.cgi?id=115885=edit
possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/230a0fff/attachment.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux

[bugzilla-dae...@freedesktop.org]

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

--- Comment #107 from Alex Deucher  ---
(In reply to Samir Ibradžić from comment #105)
> Here is dmesg with 88, 93, 95 & 97 applied, it looks strange as non-zero
> DPCD values are reported from beginning and they never change. 

I don't think you are experiencing the same issue.  Let's continue debugging
your issue on bug 90320.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/c5d507d7/attachment.html>

drm/exynos: Add atomic modesetting support

[Daniel Stone]

Hi,

On Monday, May 18, 2015, Gustavo Padovan  wrote:

> Hi Tobias,
>
> 2015-05-15 Tobias Jakobi >:
> > I did another run with drm.debug=0xff and also tried to figure out where
> the
> > div-by-zero comes from.
> >
> > The only division I see is in fimd_calc_clkdiv() (which is called by
> > fimd_commit()). So it looks like 'ideal_clk' is zero when calling
> > DIV_ROUND_UP().
> >
> > 'htotal' and 'vtotal' can't be zero, since this is checked early in
> > fimd_commit(). So 'vrefresh' has to be zero. Maybe this helps?
>
> What is is the output when you run with this patch:
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 12ab80c..f5d215d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -310,6 +310,8 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
> unsigned long ideal_clk = mode->htotal * mode->vtotal *
> mode->vrefresh;
> u32 clkdiv;
>
> +   DRM_DEBUG_KMS("vrefresh %d\n", mode->vrefresh);
> +
> if (ctx->i80_if) {
> /*
>  * The frame done interrupt should be occurred prior to the
> @@ -328,6 +330,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc
> *crtc,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
>  {
> +   DRM_DEBUG_KMS("vrefresh %d\n", adjusted_mode->vrefresh);
> if (adjusted_mode->vrefresh == 0)
> adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
>

vrefresh can legitimately be zero, which makes this FIMD_DEFAULT_FRAMERATE
assignment problematic rather than harmless.

If it's zero, you can find a vrefresh value with drm_mode_vrefresh, which
will calculate it for you.

Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/6b003875/attachment.html>

drm/nouveau/fb: namespace + nvidia gpu names (no binary change)

[Dan Carpenter]

Hello Ben Skeggs,

The patch 639c308effb9: "drm/nouveau/fb: namespace + nvidia gpu names
(no binary change)" from Jan 14, 2015, leads to the following static
checker warning:

drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c:1297 
gk104_ram_train_init()
error: potential null dereference 'train'.  (kzalloc returns null)

drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
  1280  static int
  1281  gk104_ram_train_init(struct nvkm_fb *pfb)
  1282  {
  1283  u8 ramcfg = nvbios_ramcfg_index(nv_subdev(pfb));
  1284  struct gk104_ram_train *train;
  1285  int ret = -ENOMEM, i;
  1286  
  1287  if ((train = kzalloc(sizeof(*train), GFP_KERNEL))) {
 ^^^
Assume the allocation fails.

  1288  for (i = 0; i < 0x100; i++) {
  1289  ret = gk104_ram_train_type(pfb, i, ramcfg, 
train);
  1290  if (ret && ret != -ENOENT)
  1291  break;
  1292  }
  1293  }
  1294  
  1295  switch (pfb->ram->type) {
  1296  case NV_MEM_TYPE_GDDR5:
  1297  ret = gk104_ram_train_init_0(pfb, train);
  ^
Dereferenced inside the gk104_ram_train_init_0() function.

  1298  break;
  1299  default:
  1300  ret = 0;
  1301  break;
  1302  }
  1303  
  1304  kfree(train);
  1305  return ret;
  1306  }

regards,
dan carpenter

[Bug 87856] Driver load fails with no error on ppc64 host

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Alex Deucher  ---
All it needs to contain is the following.

Section "Device"
Identifier "Radeon"
Driver "radeon"
Option "NoAccel" "true"
EndSection

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/76bb27de/attachment.html>

[BUG/REGRESSION] Radeon HDMI casuses oops on Acube Sam460ex amcc 460ex power board

[Julian Margetson]

 at address 
0x0008
[   30.148251] Faulting instruction address: 0xc04a5218
[   33.013394] Oops: Kernel access of bad area, sig: 11 [#1]
[   33.019129] PREEMPT Canyonlands
[   33.022469] Modules linked in:
[   33.025713] CPU: 0 PID: 1940 Comm: Xorg Not tainted 4.0.4-Sam460ex #1
[   33.032516] task: edd4a920 ti: ede6a000 task.ti: ede6a000
[   33.038216] NIP: c04a5218 LR: c04a5544 CTR: 
[   33.043460] REGS: ede6bc30 TRAP: 0300   Not tainted  (4.0.4-Sam460ex)
[   33.050264] MSR: 00029000 <CE,EE,ME>  CR: 24004442  XER: 
[   33.056818] DEAR: 0008 ESR: 
GPR00: c04a5530 ede6bce0 edd4a920 ee9c   c0ac2c04 61626c69
GPR08:    ede6bce0 2400 b7f08afc b862fab0 b862e530
GPR16:   6f23c730 ede6be18 c03add64 ee9a2578 0001 4000
GPR24: 4000 c0719b98 eeb61200 c08d825c ee4e6000 ee9c  ea8f9f00
[   33.091359] NIP [c04a5218] radeon_audio_enable+0x4/0x18
[   33.096883] LR [c04a5544] radeon_audio_detect+0x150/0x1bc
[   33.102582] Call Trace:
[   33.105164] [ede6bce0] [c04a5530] radeon_audio_detect+0x13c/0x1bc 
(unreliable)
[   33.112838] [ede6bd00] [c03e69b4] radeon_dvi_detect+0x3a8/0x3cc
[   33.119112] [ede6bd30] [c0391cf8] 
drm_helper_probe_single_connector_modes_merge_bits+0xf4/0x448
[   33.128318] [ede6bd70] [c03ade48] drm_mode_getconnector+0xe4/0x334
[   33.134861] [ede6be10] [c03a0bf4] drm_ioctl+0x348/0x464
[   33.140408] [ede6bed0] [c00ce2e4] do_vfs_ioctl+0x52c/0x6e8
[   33.146214] [ede6bf20] [c00ce4e0] SyS_ioctl+0x40/0x68
[   33.151572] [ede6bf40] [c000ab1c] ret_from_syscall+0x0/0x3c
[   33.157472] --- interrupt: c01 at 0x6fb001dc
[   33.157472] LR = 0x6fb00100
[   33.165272] Instruction dump:
[   33.168425] 8129012c 806a0018 2f89 419e0018 81290004 2f89 419e000c 
7d2903a6
[   33.176731] 4e800420 3860 4e800020 81231cd8 <81290008> 2f89 4d9e0020 
7d2903a6
[   33.340269] ---[ end trace 3e0a38b7fc789e38 ]---
[   33.344890]
[   33.368364] init: bluetooth main process (2019) terminated with status 1
[   33.399413] init: bluetooth main process ended, respawning
  * Starting Mount filesystems on boot

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/bb86abc7/attachment.html>

[PATCH] drm/tegra: rgb: Use atomic DPMS helpers

[Dmitry Osipenko]

Panel DPMS got broken after adding support for atomic modesetting.
Fix it by making RGB output use of generic atomic DPMS helpers.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/rgb.c | 49 -
 1 file changed, 17 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 7cd833f..46cbaf2 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -88,13 +88,8 @@ static void tegra_dc_write_regs(struct tegra_dc *dc,
tegra_dc_writel(dc, table[i].value, table[i].offset);
 }

-static void tegra_rgb_connector_dpms(struct drm_connector *connector,
-int mode)
-{
-}
-
 static const struct drm_connector_funcs tegra_rgb_connector_funcs = {
-   .dpms = tegra_rgb_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.reset = drm_atomic_helper_connector_reset,
.detect = tegra_output_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -125,21 +120,28 @@ static const struct drm_encoder_funcs 
tegra_rgb_encoder_funcs = {
.destroy = tegra_output_encoder_destroy,
 };

-static void tegra_rgb_encoder_dpms(struct drm_encoder *encoder, int mode)
+static void tegra_rgb_encoder_mode_set(struct drm_encoder *encoder,
+  struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted)
 {
 }

-static void tegra_rgb_encoder_prepare(struct drm_encoder *encoder)
+static void tegra_rgb_encoder_disable(struct drm_encoder *encoder)
 {
-}
+   struct tegra_output *output = encoder_to_output(encoder);
+   struct tegra_rgb *rgb = to_rgb(output);

-static void tegra_rgb_encoder_commit(struct drm_encoder *encoder)
-{
+   if (output->panel)
+   drm_panel_disable(output->panel);
+
+   tegra_dc_write_regs(rgb->dc, rgb_disable, ARRAY_SIZE(rgb_disable));
+   tegra_dc_commit(rgb->dc);
+
+   if (output->panel)
+   drm_panel_unprepare(output->panel);
 }

-static void tegra_rgb_encoder_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted)
+static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
 {
struct tegra_output *output = encoder_to_output(encoder);
struct tegra_rgb *rgb = to_rgb(output);
@@ -174,21 +176,6 @@ static void tegra_rgb_encoder_mode_set(struct drm_encoder 
*encoder,
drm_panel_enable(output->panel);
 }

-static void tegra_rgb_encoder_disable(struct drm_encoder *encoder)
-{
-   struct tegra_output *output = encoder_to_output(encoder);
-   struct tegra_rgb *rgb = to_rgb(output);
-
-   if (output->panel)
-   drm_panel_disable(output->panel);
-
-   tegra_dc_write_regs(rgb->dc, rgb_disable, ARRAY_SIZE(rgb_disable));
-   tegra_dc_commit(rgb->dc);
-
-   if (output->panel)
-   drm_panel_unprepare(output->panel);
-}
-
 static int
 tegra_rgb_encoder_atomic_check(struct drm_encoder *encoder,
   struct drm_crtc_state *crtc_state,
@@ -231,11 +218,9 @@ tegra_rgb_encoder_atomic_check(struct drm_encoder *encoder,
 }

 static const struct drm_encoder_helper_funcs tegra_rgb_encoder_helper_funcs = {
-   .dpms = tegra_rgb_encoder_dpms,
-   .prepare = tegra_rgb_encoder_prepare,
-   .commit = tegra_rgb_encoder_commit,
.mode_set = tegra_rgb_encoder_mode_set,
.disable = tegra_rgb_encoder_disable,
+   .enable = tegra_rgb_encoder_enable,
.atomic_check = tegra_rgb_encoder_atomic_check,
 };

-- 
2.4.0

[Bug 87856] Driver load fails with no error on ppc64 host

[bugzilla-dae...@freedesktop.org]

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

--- Comment #6 from kristof  ---
(In reply to Alex Deucher from comment #5)
> (In reply to kristof from comment #4)
> > PS : can someone tells me if it this an "abnornal" things in the last dmesg
> > | egrep 'drm|radeon' please ?
> > 
> > Thanks and have a nice day
> 
> The kernel side looks fine.  It appears to be a problem with the usermode
> stack.  You might be able to work around it by disabling acceleration.  Try
> adding:
> Option "NoAccel" "True"
> to the device section of your xorg config.
> 
> I'm not really sure how well the usermode stuff works on BE systems.
Hi Alex and thanks for response,

Forgot to mention that I don't use :
* xorg.conf
* no options in my yaboot.conf
* all the OS installation stand by default, just patch Mesa-lib

In this case, should I generate a xorg.conf then use it ?

Regards,

Kristof

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/c33bf74e/attachment.html>

[BUG/REGRESSION] Radeon HDMI casuses oops on Acube Sam460ex amcc 460ex power board

[Alex Deucher]

On Mon, May 18, 2015 at 6:41 PM, Julian Margetson  wrote:
> On 5/18/2015 4:59 PM, Alex Deucher wrote:
>
Snip



>  * Starting NTP server ntpd   [   28.819002] Unable to handle kernel
> paging request for data at address 0x0008
> [   28.860330] Faulting instruction address: 0xc04a5218
> [   30.874910] Oops: Kernel access of bad area, sig: 11 [#1]
> [   30.892488] PREEMPT Canyonlands
> [   30.907764] Modules linked in:
> [   30.922944] CPU: 0 PID: 1949 Comm: Xorg Not tainted 4.0.4-Sam460ex #4
> [   30.941699] task: edd7a920 ti: ee6d task.ti: ee6d
> [   30.959284] NIP: c04a5218 LR: c04a5544 CTR: 
> [   30.976315] REGS: ee6d1c30 TRAP: 0300   Not tainted  (4.0.4-Sam460ex)
> [   30.995038] MSR: 00029000   CR: 24004242  XER: 
> [   31.013805] DEAR: 0008 ESR: 
> GPR00: c04a5530 ee6d1ce0 edd7a920 ee984000   c0ac2c04
> 61626c69
> GPR08:    ee6d1ce0 24004244 b7e90afc b84d1ab0
> b84d0530
> GPR16:   6f23c730 ee6d1e18 c03add64 eea00578 0001
> 4000
> GPR24: 4000 c0719b98 eeb62200 c08d825c ee4e4000 ee984000 
> eeaf8f00
> [   31.111915] NIP [c04a5218] radeon_audio_enable+0x4/0x18
> [   31.130834] LR [c04a5544] radeon_audio_detect+0x150/0x1bc
> [   31.150046] Call Trace:
> [   31.166259] [ee6d1ce0] [c04a5530] radeon_audio_detect+0x13c/0x1bc
> (unreliable)
> [   31.187768] [ee6d1d00] [c03e69b4] radeon_dvi_detect+0x3a8/0x3cc
> [   31.207983] [ee6d1d30] [c0391cf8]
> drm_helper_probe_single_connector_modes_merge_bits+0xf4/0x448
> [   31.231287] [ee6d1d70] [c03ade48] drm_mode_getconnector+0xe4/0x334
> [   31.25] [ee6d1e10] [c03a0bf4] drm_ioctl+0x348/0x464
> [   31.272107] [ee6d1ed0] [c00ce2e4] do_vfs_ioctl+0x52c/0x6e8
> [   31.292084] [ee6d1f20] [c00ce4e0] SyS_ioctl+0x40/0x68
> [   31.311408] [ee6d1f40] [c000ab1c] ret_from_syscall+0x0/0x3c
> [   31.331466] --- interrupt: c01 at 0x6fb001dc
> [   31.331466] LR = 0x6fb00100
> [   31.368093] Instruction dump:
> [   31.385716] 8129012c 806a0018 2f89 419e0018 81290004 2f89
> 419e000c 7d2903a6
> [   31.408631] 4e800420 3860 4e800020 81231cd8 <81290008> 2f89
> 4d9e0020 7d2903a6
> [   31.587312] ---[ end trace 2a6dca2844a1913c ]---
> [   31.591930]
> [   32.489288] init: bluetooth main process (2051) terminated with status 1
> [   32.501384] init: bluetooth main process ended, respawning
> [   33.156098] init: bluetooth main process (2076) terminated with status 1
> [   33.183330] init: bluetooth main process ended, respawning
> [   33.859517] init: bluetooth main process (2124) terminated with status 1
> [   33.880582] init: bluetooth main process ended, respawning
> [   34.450457] init: bluetooth main process (2177) terminated with status 1
> [   34.457287] init: bluetooth main process ended, respawning
>  * Starting Mount filesystems on boot[ OK ]
>

Are you sure you booted the right kernel and applied both patches?  I
don't see any of the debugging output from the patch.

Alex

[BUG/REGRESSION] Radeon HDMI casuses oops on Acube Sam460ex amcc 460ex power board

[Julian Margetson]

On 5/18/2015 4:59 PM, Alex Deucher wrote:
> On Mon, May 18, 2015 at 1:48 PM, Julian Margetson  wrote:
>> On 5/18/2015 12:08 PM, Alex Deucher wrote:
>>> On Sun, May 17, 2015 at 7:20 PM, Julian Margetson 
>>> wrote:
 Kernels 4.03 and 4.04  oops with HDMI connection on Acube Sam460ex amcc
 460ex powerpc  board.

 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8 is the first bad commit

 commit 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8
 Author: Alex Deucher 
 Date:   Tue Apr 7 09:52:42 2015 -0400

   drm/radeon: only mark audio as connected if the monitor supports it
 (v3)

   commit 0f55db36d49d45b80eff0c0a2a498766016f458b upstream.

   Otherwise the driver may try and send audio which may confuse the
   monitor.

   v2: set pin to NULL if no audio
   v3: avoid crash with analog encoders

   Signed-off-by: Alex Deucher 
   Signed-off-by: Greg Kroah-Hartman 

 :04 04 de0366a6790f5c91d175bcb89cb34956bbe72b26
 bbdb5734961f824558152c7c34a840c78bc3a9a9 M drivers

>>> The attached patch should fix it up.
>>>
>>> Alex
>>>
>>>
 [2.587570] Linux agpgart interface v0.103
 [2.591997] [drm] Initialized drm 1.1.0 20060810
 [2.596892] [drm] radeon kernel modesetting enabled.
 [2.602989] [drm] initializing kernel modesetting (VERDE 0x1002:0x683F
 0x1545:0x7750).
 [2.611161] [drm] register mmio base: 0xe9000
 [2.615935] [drm] register mmio size: 262144
 [2.952043] ATOM BIOS: C44501
 [2.955323] radeon 0001:81:00.0: VRAM: 1024M 0x -
 0x3FFF (1024M used)
 [2.964253] radeon 0001:81:00.0: GTT: 1024M 0x4000 -
 0x7FFF
 [2.971938] [drm] Detected VRAM RAM=1024M, BAR=256M
 [2.976840] [drm] RAM width 128bits DDR
 [2.980898] [TTM] Zone  kernel: Available graphics memory: 379358 kiB
 [2.987383] [TTM] Zone highmem: Available graphics memory: 1034718 kiB
 [2.993934] [TTM] Initializing pool allocator
 [2.998331] [TTM] Initializing DMA pool allocator
 [3.003153] [drm] radeon: 1024M of VRAM memory ready
 [3.008162] [drm] radeon: 1024M of GTT memory ready.
 [3.013203] [drm] Loading verde Microcode
 [3.017266] [drm] Internal thermal controller with fan control
 [3.023437] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0
 [3.077284] [drm] radeon: dpm initialized
 [3.081503] [drm] GART: num cpu pages 262144, num gpu pages 262144
 [3.093142] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0
 [3.125984] [drm] PCIE GART of 1024M enabled (table at
 0x00277000).
 [3.133327] radeon 0001:81:00.0: WB enabled
 [3.137565] radeon 0001:81:00.0: fence driver on ring 0 use gpu addr
 0x4c00 and cpu addr 0xffc01c00
 [3.147697] radeon 0001:81:00.0: fence driver on ring 1 use gpu addr
 0x4c04 and cpu addr 0xffc01c04
 [3.157827] radeon 0001:81:00.0: fence driver on ring 2 use gpu addr
 0x4c08 and cpu addr 0xffc01c08
 [3.167957] radeon 0001:81:00.0: fence driver on ring 3 use gpu addr
 0x4c0c and cpu addr 0xffc01c0c
 [3.178078] radeon 0001:81:00.0: fence driver on ring 4 use gpu addr
 0x4c10 and cpu addr 0xffc01c10
 [3.209673] radeon 0001:81:00.0: fence driver on ring 5 use gpu addr
 0x00075a18 and cpu addr 0xf90b5a18
 [3.219822] [drm] Supports vblank timestamp caching Rev 2
 (21.10.2013).
 [3.226457] [drm] Driver supports precise vblank timestamp query.
 [3.232584] radeon 0001:81:00.0: radeon: MSI limited to 32-bit
 [3.238466] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
 [3.244586] [drm] radeon: irq initialized.
 [4.006339] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
 (scratch(0x850C)=0xCAFEDEAD)
 [4.015198] radeon 0001:81:00.0: disabling GPU acceleration
 [4.220071] [drm] Radeon Display Connectors
 [4.224651] [drm] Connector 0:
 [4.227787] [drm]   HDMI-A-1
 [4.230754] [drm]   HPD4
 [4.233328] [drm]   DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578
 0x657c
 0x657c
 [4.240806] [drm]   Encoders:
 [4.243815] [drm] DFP1: INTERNAL_UNIPHY2
 [4.248131] [drm] Connector 1:
 [4.251227] [drm]   DVI-I-1
 [4.254051] [drm]   HPD2
 [4.256608] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568
 0x656c
 0x656c
 [4.264034] [drm]   Encoders:
 [4.267021] [drm] DFP2: INTERNAL_UNIPHY
 [4.271223] [drm] CRT1: INTERNAL_KLDSCP_DAC1
 [4.390562] [drm] fb mappable at 0x80478000
 [4.394789] [drm] vram apper at 0x8000
 [4.398905] [drm] size 8294400
 [4.401978] [drm] fb depth 

[RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

[Robert Bragg]

On Fri, May 8, 2015 at 5:21 PM, Peter Zijlstra  wrote:
>
> So I've not yet went through the entire series; but I'm wondering if its
> at all possible to re-use some of this work:
>
> lkml.kernel.org/r/1428453299-19121-1-git-send-email-sukadev at 
> linux.vnet.ibm.com
>
> That's for a Power8 HV call that can basically return an array of
> values; which on a superficial level sounds a bit like what this GPU
> hardware does.

Thanks for this pointer.

I think the main similarity here is the ability to capture multiple
counters consistent for the same point in time, but in our case we
don't have an explicitly controlled transaction mechanism like this.

Although we can collect a large set of counters in a latched fashion -
so they are self consistent - the selection of counters included in
our OA unit reports is more rigid.

Most of our counters aren't independently aggregated, they are derived
from signals selected as part of the OA unit configuration and the
values are only maintained by the OA unit itself, so a
re-configuration to select different signals will discard the counter
values of currently selected signals.

afik re-configuring our signal selection is also relatively slow too
(I was told this last week at least, but I haven't tested it myself)
and so it's really geared towards applications or tools choosing a
configuration to maintain for a relatively long time while profiling a
workload.

I think the other big difference here is that we don't have a way to
explicitly trigger a report to be written from the cpu. (Although we
can read the OA counters via mmio, it's only intended for debug
purposes as this subverts the hw latching of counters) This means it
would be difficult to try and treat this like a transaction including
a fixed set of event->read()s without a way for pmu->commit_txn() to
trigger a report.

>
> Let me read more of this..

Thanks.

- Robert

[RFC PATCH v2] perf: Add PERF_EVENT_IOC_FLUSH ioctl

[Robert Bragg]

To allow for pmus that may have internal buffering (e.g. the hardware
itself writes out data to its own circular buffer which is only
periodically forwarded to userspace via perf) this ioctl enables
userspace to explicitly ensure it has received all samples before a
point in time.

v2: return int error status

Signed-off-by: Robert Bragg 
---
 include/linux/perf_event.h  | 7 +++
 include/uapi/linux/perf_event.h | 1 +
 kernel/events/core.c| 5 +
 3 files changed, 13 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index cf1d096..0c591eb 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -305,6 +305,13 @@ struct pmu {
 * Free pmu-private AUX data structures
 */
void (*free_aux)(void *aux); /* optional */
+
+   /*
+* Flush buffered samples (E.g. for pmu hardware that writes samples to
+* some intermediate buffer) userspace may need to explicitly ensure
+* such samples have been forwarded to perf.
+*/
+   int (*flush)(struct perf_event *event); /*optional 
*/
 };

 /**
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 309211b..cbf1b80 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -389,6 +389,7 @@ struct perf_event_attr {
 #define PERF_EVENT_IOC_SET_FILTER  _IOW('$', 6, char *)
 #define PERF_EVENT_IOC_ID  _IOR('$', 7, __u64 *)
 #define PERF_EVENT_IOC_SET_BPF _IOW('$', 8, __u32)
+#define PERF_EVENT_IOC_FLUSH   _IO ('$', 9)

 enum perf_event_ioc_flags {
PERF_IOC_FLAG_GROUP = 1U << 0,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 3fe532a..72daee6 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4079,6 +4079,11 @@ static long _perf_ioctl(struct perf_event *event, 
unsigned int cmd, unsigned lon
case PERF_EVENT_IOC_SET_BPF:
return perf_event_set_bpf_prog(event, arg);

+   case PERF_EVENT_IOC_FLUSH:
+   if (event->pmu->flush)
+   return event->pmu->flush(event);
+   return 0;
+
default:
return -ENOTTY;
}
-- 
2.4.1

[RFC PATCH] squash: be more careful stopping oacontrol updates

[Robert Bragg]

This makes sure we've stopped touching oacontrol before we start
resetting OA, PM and clock gating. Shouldn't strictly be needed since we
know that oacontrol will have been disabled before we start destroying
an event but it seems worth highlighting that update_oacontrol() could
still be running asynchronously and stopping it early in case it might
become an issue in the future.
---
 drivers/gpu/drm/i915/i915_oa_perf.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_perf.c 
b/drivers/gpu/drm/i915/i915_oa_perf.c
index bf1c1d6..e47ed90 100644
--- a/drivers/gpu/drm/i915/i915_oa_perf.c
+++ b/drivers/gpu/drm/i915/i915_oa_perf.c
@@ -166,12 +166,21 @@ static void i915_oa_event_destroy(struct perf_event 
*event)
 {
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), oa_pmu.pmu);
+   unsigned long lock_flags;

WARN_ON(event->parent);

-   oa_buffer_destroy(i915);
-
+   /* Stop updating oacontrol via _oa_context_pin_[un]notify()... */
+   spin_lock_irqsave(>oa_pmu.lock, lock_flags);
i915->oa_pmu.specific_ctx = NULL;
+   spin_unlock_irqrestore(>oa_pmu.lock, lock_flags);
+
+   /* Don't let the compiler start resetting OA, PM and clock gating
+* state before we've stopped update_oacontrol()
+*/
+   barrier();
+
+   oa_buffer_destroy(i915);

BUG_ON(i915->oa_pmu.exclusive_event != event);
i915->oa_pmu.exclusive_event = NULL;
@@ -513,6 +522,11 @@ static int i915_oa_event_init(struct perf_event *event)
return 0;
 }

+/* Note: Although pmu methods are called with the corresponding
+ * perf_event_context lock taken (so we don't need to worry about our pmu
+ * methods contending with each other) update_oacontrol() may be called
+ * asynchronously via the i915_oa_pmu_[un]register() hooks.
+ */
 static void update_oacontrol(struct drm_i915_private *dev_priv)
 {
BUG_ON(!spin_is_locked(_priv->oa_pmu.lock));
-- 
2.4.1

[RFC PATCH v2] drm/i915: Expose PMU for Observation Architecture

[Robert Bragg]

Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer and this patch exposes that
capability to userspace via the perf interface.

To start with this only enables the A (aggregating) counters with the
simplest configuration requirements.

Only Haswell is supported currently.

v2:
- fix deadlock in init_oa_buffer error path
- EBADF for bad drm fd, EINVAL for failure to lookup ctx
- mmio write barriers, after OA reconfigure, before unlocks
- use i915_mutex_lock_interruptible within event init

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_dma.c |   6 +
 drivers/gpu/drm/i915/i915_drv.h |  53 +++
 drivers/gpu/drm/i915/i915_gem_context.c |  45 +-
 drivers/gpu/drm/i915/i915_oa_perf.c | 762 
 drivers/gpu/drm/i915/i915_reg.h |  68 +++
 include/uapi/drm/i915_drm.h |  29 ++
 7 files changed, 954 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b7ddf48..b5ebfbe 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -15,6 +15,7 @@ i915-y := i915_drv.o \

 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_PERF_EVENTS) += i915_oa_perf.o

 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a238889..c299e18 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -818,6 +818,11 @@ int i915_driver_load(struct drm_device *dev, unsigned long 
flags)
mutex_init(_priv->modeset_restore_lock);
mutex_init(_priv->csr_lock);

+   /* Must at least be registered before trying to pin any context
+* otherwise i915_oa_context_pin_notify() will lock an un-initialized
+* spinlock, upsetting lockdep checks */
+   i915_oa_pmu_register(dev);
+
intel_pm_setup(dev);

intel_display_crc_init(dev);
@@ -1067,6 +1072,7 @@ int i915_driver_unload(struct drm_device *dev)
return ret;
}

+   i915_oa_pmu_unregister(dev);
intel_power_domains_fini(dev_priv);

intel_gpu_ips_teardown();
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a66d6b..dd475ca 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 /* General customization:
@@ -1839,6 +1840,35 @@ struct drm_i915_private {
 */
struct workqueue_struct *dp_wq;

+#ifdef CONFIG_PERF_EVENTS
+   struct {
+   struct pmu pmu;
+   spinlock_t lock;
+   struct hrtimer timer;
+   struct pt_regs dummy_regs;
+
+   struct perf_event *exclusive_event;
+   struct intel_context *specific_ctx;
+   bool event_active;
+
+   bool periodic;
+   u32 period_exponent;
+
+   u32 metrics_set;
+
+   struct {
+   struct drm_i915_gem_object *obj;
+   u32 gtt_offset;
+   u8 *addr;
+   u32 head;
+   u32 tail;
+   int format;
+   int format_size;
+   spinlock_t flush_lock;
+   } oa_buffer;
+   } oa_pmu;
+#endif
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct {
int (*execbuf_submit)(struct drm_device *dev, struct drm_file 
*file,
@@ -3012,6 +3042,20 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
 int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);

+#ifdef CONFIG_PERF_EVENTS
+void i915_oa_context_pin_notify(struct drm_i915_private *dev_priv,
+   struct intel_context *context);
+void i915_oa_context_unpin_notify(struct drm_i915_private *dev_priv,
+ struct intel_context *context);
+#else
+static inline void
+i915_oa_context_pin_notify(struct drm_i915_private *dev_priv,
+  struct intel_context *context) {}
+static inline void
+i915_oa_context_unpin_notify(struct drm_i915_private *dev_priv,
+struct intel_context *context) {}
+#endif
+
 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct drm_device *dev,
  struct i915_address_space *vm,
@@ -3121,6 +3165,15 @@ int i915_parse_cmds(struct intel_engine_cs *ring,
u32 batch_len,
bool is_master);

+/* i915_oa_perf.c */
+#ifdef CONFIG_PERF_EVENTS
+extern void 

drm/exynos: Add atomic modesetting support

[Gustavo Padovan]

2015-05-18 Daniel Stone :

> Hi,
> 
> On Monday, May 18, 2015, Gustavo Padovan  wrote:
> 
> > Hi Tobias,
> >
> > 2015-05-15 Tobias Jakobi >:
> > > I did another run with drm.debug=0xff and also tried to figure out where
> > the
> > > div-by-zero comes from.
> > >
> > > The only division I see is in fimd_calc_clkdiv() (which is called by
> > > fimd_commit()). So it looks like 'ideal_clk' is zero when calling
> > > DIV_ROUND_UP().
> > >
> > > 'htotal' and 'vtotal' can't be zero, since this is checked early in
> > > fimd_commit(). So 'vrefresh' has to be zero. Maybe this helps?
> >
> > What is is the output when you run with this patch:
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 12ab80c..f5d215d 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -310,6 +310,8 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
> > unsigned long ideal_clk = mode->htotal * mode->vtotal *
> > mode->vrefresh;
> > u32 clkdiv;
> >
> > +   DRM_DEBUG_KMS("vrefresh %d\n", mode->vrefresh);
> > +
> > if (ctx->i80_if) {
> > /*
> >  * The frame done interrupt should be occurred prior to the
> > @@ -328,6 +330,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc
> > *crtc,
> > const struct drm_display_mode *mode,
> > struct drm_display_mode *adjusted_mode)
> >  {
> > +   DRM_DEBUG_KMS("vrefresh %d\n", adjusted_mode->vrefresh);
> > if (adjusted_mode->vrefresh == 0)
> > adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
> >
> 
> vrefresh can legitimately be zero, which makes this FIMD_DEFAULT_FRAMERATE
> assignment problematic rather than harmless.
> 
> If it's zero, you can find a vrefresh value with drm_mode_vrefresh, which
> will calculate it for you.

So better try this. Ideally fimd_mode_fixup should go away too, I'll do a proper
patch once we know this works.

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 12ab80c..363353b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -307,9 +307,17 @@ static void fimd_iommu_detach_devices(struct fimd_context 
*ctx)
 static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
const struct drm_display_mode *mode)
 {
-   unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
+   unsigned long ideal_clk;
+   int vrefresh;
u32 clkdiv;

+   if (mode->vrefresh == 0)
+   vrefresh = drm_mode_vrefresh(mode);
+   else
+   vrefresh = mode->vrefresh;
+
+   ideal_clk =  mode->htotal * mode->vtotal * vrefresh;
+
if (ctx->i80_if) {
/*
 * The frame done interrupt should be occurred prior to the

[Bug 90263] GPU card fans run full speed at all times

[bugzilla-dae...@freedesktop.org]

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

--- Comment #10 from Alex Deucher  ---
(In reply to Todd from comment #9)
> "Newer" is an odd description. The card is from 2011.

Newer relative to the original Barts cards.  IIRC, smc fan control was
introduced sometime after the original barts launch.  Most cards just used the
fan profile set up in the vbios.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/3a6ccdbb/attachment-0001.html>

[Intel-gfx] [RFC PATCH 07/11] drm/i915: Expose PMU for Observation Architecture

[Robert Bragg]

On 7 May 2015 15:58, "Chris Wilson"  wrote:
>
> On Thu, May 07, 2015 at 03:15:50PM +0100, Robert Bragg wrote:
> > + /* We bypass the default perf core perf_paranoid_cpu() ||
> > +  * CAP_SYS_ADMIN check by using the PERF_PMU_CAP_IS_DEVICE
> > +  * flag and instead authenticate based on whether the current
> > +  * pid owns the specified context, or require CAP_SYS_ADMIN
> > +  * when collecting cross-context metrics.
> > +  */
> > + dev_priv->oa_pmu.specific_ctx = NULL;
> > + if (oa_attr.single_context) {
> > + u32 ctx_id = oa_attr.ctx_id;
> > + unsigned int drm_fd = oa_attr.drm_fd;
> > + struct fd fd = fdget(drm_fd);
> > +
> > + if (fd.file) {
>
> Specify a ctx and not providing the right fd should be its own error,
> either EBADF or EINVAL.

Right, I went for both in the end; EBADF if fdget fails and EINVAL if
the fd is ok but we fail to lookup a context with it.

>
> > + dev_priv->oa_pmu.specific_ctx =
> > + lookup_context(dev_priv, fd.file, ctx_id);
> > + }
>
> Missing fdput

Ah yes; fixed.

>
> > + }
> > +
> > + if (!dev_priv->oa_pmu.specific_ctx && !capable(CAP_SYS_ADMIN))
> > + return -EACCES;
> > +
> > + mutex_lock(_priv->dev->struct_mutex);
>
> i915_mutex_interruptible, probably best to couple into the GPU error
> handling here as well especially as init_oa_buffer() will go onto touch
> GPU internals.

Ok, using i915_mutex_interruptible makes sense, I've also moved the
locking into init_oa_buffer.

About the GPU error handling, do you have any thoughts on what could
be most helpful here? I'm thinking a.t.m of extending
i915_capture_reg_state() in i915_gpu_error.c to capture the OACONTROL
+ OASTATUS state and perhaps all the UCGCTL unit clock gating state
too.

>
> > + ret = init_oa_buffer(event);
> > + mutex_unlock(_priv->dev->struct_mutex);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + BUG_ON(dev_priv->oa_pmu.exclusive_event);
> > + dev_priv->oa_pmu.exclusive_event = event;
> > +
> > + event->destroy = i915_oa_event_destroy;
> > +
> > + /* PRM - observability performance counters:
> > +  *
> > +  *   OACONTROL, performance counter enable, note:
> > +  *
> > +  *   "When this bit is set, in order to have coherent counts,
> > +  *   RC6 power state and trunk clock gating must be disabled.
> > +  *   This can be achieved by programming MMIO registers as
> > +  *   0xA094=0 and 0xA090[31]=1"
> > +  *
> > +  *   In our case we are expected that taking pm + FORCEWAKE
> > +  *   references will effectively disable RC6 and trunk clock
> > +  *   gating.
> > +  */
> > + intel_runtime_pm_get(dev_priv);
> > + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
>
> That is a nuisance. Aside: Why isn't OA inside the powerctx? Is a subset
> valid with forcewake? It does perturb the system greatly to disable rc6,
> so I wonder if it could be made optional?

Yes, it's a shame.

I probably only really know enough about the OA unit design to be
dangerous and won't try and comment in detail here, but I think
there's more to it than not saving state in a power context. As I
understand it, there were a number of design changes made to enable
OA+RC6 support for BDW+, including having the OA unit automatically
write out reports to the OA buffer when entering RC6.

I think just FORCEWAKE_RENDER would work here, but only say that
because it looks like HSW only has the render forcewake domain from
what I could tell.

I think I need to update the comment above these lines as I don't
think these will affect crclk gating; these just handle disabling RC6.

The WIP patch I sent out basically represents me trying to get to the
bottom of the clock gating constraints we have.

At this point I think I need to disable CS unit gating via UCGCTL1, as
well as DOP gating for the render trunk clock via MISCCPCTL but I'm
not entirely confident about that just yet. At least empirically I see
these fixing some issues in rudimentary testing.

>
> > +
> > + return 0;
> > +}
> > +
> > +static void update_oacontrol(struct drm_i915_private *dev_priv)
> > +{
> > + BUG_ON(!spin_is_locked(_priv->oa_pmu.lock));
> > +
> > + if (dev_priv->oa_pmu.event_active) {
> > + unsigned long ctx_id = 0;
> > + bool pinning_ok = false;
> > +
> > + if (dev_priv->oa_pmu.specific_ctx) {
> > + struct intel_context *ctx =
> > + dev_priv->oa_pmu.specific_ctx;
> > + struct drm_i915_gem_object *obj =
> > + ctx->legacy_hw_ctx.rcs_state;
>
> If only there was ctx->legacy_hw_ctx.rcs_vma...

ok, not sure if this is a prod to add that, a heads up that this is
coming or seething because some prior attempt to add this was nack'd.


>
> > +
> > + if 

[Intel-gfx] [RFC PATCH 07/11] drm/i915: Expose PMU for Observation Architecture

[Robert Bragg]

On 7 May 2015 15:37, "Chris Wilson"  wrote:
>
> On Thu, May 07, 2015 at 03:15:50PM +0100, Robert Bragg wrote:
> > +static int init_oa_buffer(struct perf_event *event)
> > +{
> > + struct drm_i915_private *dev_priv =
> > + container_of(event->pmu, typeof(*dev_priv), oa_pmu.pmu);
> > + struct drm_i915_gem_object *bo;
> > + int ret;
> > +
> > + BUG_ON(!IS_HASWELL(dev_priv->dev));
> > + BUG_ON(!mutex_is_locked(_priv->dev->struct_mutex));
> > + BUG_ON(dev_priv->oa_pmu.oa_buffer.obj);
> > +
> > + spin_lock_init(_priv->oa_pmu.oa_buffer.flush_lock);
> > +
> > + /* NB: We over allocate the OA buffer due to the way raw sample
data
> > +  * gets copied from the gpu mapped circular buffer into the perf
> > +  * circular buffer so that only one copy is required.
> > +  *
> > +  * For each perf sample (raw->size + 4) needs to be 8 byte
aligned,
> > +  * where the 4 corresponds to the 32bit raw->size member that's
> > +  * added to the sample header that userspace sees.
> > +  *
> > +  * Due to the + 4 for the size member: when we copy a report to
the
> > +  * userspace facing perf buffer we always copy an additional 4
bytes
> > +  * from the subsequent report to make up for the miss alignment,
but
> > +  * when a report is at the end of the gpu mapped buffer we need to
> > +  * read 4 bytes past the end of the buffer.
> > +  */
> > + bo = i915_gem_alloc_object(dev_priv->dev, OA_BUFFER_SIZE +
PAGE_SIZE);
> > + if (bo == NULL) {
> > + DRM_ERROR("Failed to allocate OA buffer\n");
> > + ret = -ENOMEM;
> > + goto err;
> > + }
> > + dev_priv->oa_pmu.oa_buffer.obj = bo;
> > +
> > + ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> > + if (ret)
> > + goto err_unref;
> > +
> > + /* PreHSW required 512K alignment, HSW requires 16M */
> > + ret = i915_gem_obj_ggtt_pin(bo, SZ_16M, 0);
> > + if (ret)
> > + goto err_unref;
> > +
> > + dev_priv->oa_pmu.oa_buffer.gtt_offset =
i915_gem_obj_ggtt_offset(bo);
> > + dev_priv->oa_pmu.oa_buffer.addr = vmap_oa_buffer(bo);
>
> You can look forward to both i915_gem_object_create_internal() and
> i915_gem_object_pin_vmap()

Okey, will do, thanks.

>
> > +
> > + /* Pre-DevBDW: OABUFFER must be set with counters off,
> > +  * before OASTATUS1, but after OASTATUS2 */
> > + I915_WRITE(GEN7_OASTATUS2, dev_priv->oa_pmu.oa_buffer.gtt_offset |
> > +GEN7_OASTATUS2_GGTT); /* head */
> > + I915_WRITE(GEN7_OABUFFER, dev_priv->oa_pmu.oa_buffer.gtt_offset);
> > + I915_WRITE(GEN7_OASTATUS1, dev_priv->oa_pmu.oa_buffer.gtt_offset |
> > +GEN7_OASTATUS1_OABUFFER_SIZE_16M); /* tail */
> > +
> > + DRM_DEBUG_DRIVER("OA Buffer initialized, gtt offset = 0x%x, vaddr
= %p",
> > +  dev_priv->oa_pmu.oa_buffer.gtt_offset,
> > +  dev_priv->oa_pmu.oa_buffer.addr);
> > +
> > + return 0;
> > +
> > +err_unref:
> > + drm_gem_object_unreference_unlocked(>base);
>
> But what I really what to say was:
> mutex deadlock^^^

Yikes, I've pushed an updated patch addressing this and can reply with a
new patch here in a bit.

Thanks,
- Robert


> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/284de99d/attachment-0001.html>

[Bug 90510] [radeon][tahiti xt] IA_MULTI_VGT_PARAM programming seems broken

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Arek Ruśniak  ---
Hi, I follow 
https://bugs.freedesktop.org/show_bug.cgi?id=90370
and 
https://bugs.freedesktop.org/show_bug.cgi?id=90484

R600_DEBUG='switch_on_eop' doesn't work for VERDE. Some glitches appear at
screen as before, maybe even worse. I've tested L4D2 only.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/c32003c8/attachment.html>

[BUG/REGRESSION] Radeon HDMI casuses oops on Acube Sam460ex amcc 460ex power board

[Alex Deucher]

b0
> b7b6a530
> GPR16:   6f23c730 edd11e18 c03add64 eeb34578 0001
> 4000
> GPR24: 4000 c0719b98 fff2 eeb62200 eeb63e00 eea3ef00 eea38000
> 
> [   34.748139] NIP [c04a520c] radeon_audio_enable+0x4/0x18
> [   34.753657] LR [c04a54ec] radeon_audio_detect+0x104/0x134
> [   34.759355] Call Trace:
> [   34.761938] [edd11ce0] [c04a54b8] radeon_audio_detect+0xd0/0x134
> (unreliable)
> [   34.769523] [edd11d00] [c03e69a8] radeon_dvi_detect+0x39c/0x3c0
> [   34.775800] [edd11d30] [c0391cf8]
> drm_helper_probe_single_connector_modes_merge_bits+0xf4/0x448
> [   34.785005] [edd11d70] [c03ade48] drm_mode_getconnector+0xe4/0x334
> [   34.791548] [edd11e10] [c03a0bf4] drm_ioctl+0x348/0x464
> [   34.797095] [edd11ed0] [c00ce2e4] do_vfs_ioctl+0x52c/0x6e8
> [   34.802910] [edd11f20] [c00ce4e0] SyS_ioctl+0x40/0x68
> [   34.808260] [edd11f40] [c000ab1c] ret_from_syscall+0x0/0x3c
> [   34.814160] --- interrupt: c01 at 0x6fb001dc
> [   34.814160] LR = 0x6fb00100
> [   34.821960] Instruction dump:
> [   34.825112] 8129012c 806a0018 2f89 419e0018 81290004 2f89
> 419e000c 7d2903a6
> [   34.833418] 4e800420 3860 4e800020 81231cd8 <81290008> 2f89
> 4d9e0020 7d2903a6
> [   34.996734] ---[ end trace c29f79df28960722 ]---
> [   35.001353]
>
>  * Starting Mount filesystems on boot
>
-- next part --
diff --git a/drivers/gpu/drm/radeon/radeon_audio.c 
b/drivers/gpu/drm/radeon/radeon_audio.c
index a07561d..5c261da 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.c
+++ b/drivers/gpu/drm/radeon/radeon_audio.c
@@ -473,12 +473,16 @@ void radeon_audio_detect(struct drm_connector *connector,
radeon_encoder = to_radeon_encoder(encoder);
dig = radeon_encoder->enc_priv;

+   DRM_INFO("encoder id: 0x%x\n", radeon_encoder->encoder_id);
+
if (!dig->afmt)
return;

if (status == connector_status_connected) {
struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);

+   DRM_INFO("connector_status_connected\n");
+
if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort 
&&
radeon_dp_getsinktype(radeon_connector) ==
CONNECTOR_OBJECT_ID_DISPLAYPORT)
@@ -486,14 +490,21 @@ void radeon_audio_detect(struct drm_connector *connector,
else
radeon_encoder->audio = rdev->audio.hdmi_funcs;

+   DRM_INFO("audio: 0x%p\n", radeon_encoder->audio);
+
dig->afmt->pin = radeon_audio_get_pin(encoder);
if (drm_detect_monitor_audio(radeon_connector_edid(connector))) 
{
+   DRM_INFO("enabling audio\n");
radeon_audio_enable(rdev, dig->afmt->pin, 0xf);
} else {
+   DRM_INFO("disabling audio\n");
radeon_audio_enable(rdev, dig->afmt->pin, 0);
dig->afmt->pin = NULL;
}
+   DRM_INFO("pin: 0x%p\n", dig->afmt->pin);
} else {
+   DRM_INFO("connector_status_disconnected\n");
+   DRM_INFO("pin: 0x%p\n", dig->afmt->pin);
radeon_audio_enable(rdev, dig->afmt->pin, 0);
dig->afmt->pin = NULL;
}
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-properly-select-encoder-in-radeon_audio_d.patch
Type: text/x-patch
Size: 3410 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/64d833b4/attachment-0001.bin>

drm/exynos: Add atomic modesetting support

[Gustavo Padovan]

Hi Tobias,

2015-05-15 Tobias Jakobi :

> Hello,
> 
> I did another run with drm.debug=0xff and also tried to figure out where the
> div-by-zero comes from.
> 
> The only division I see is in fimd_calc_clkdiv() (which is called by
> fimd_commit()). So it looks like 'ideal_clk' is zero when calling
> DIV_ROUND_UP().
> 
> 'htotal' and 'vtotal' can't be zero, since this is checked early in
> fimd_commit(). So 'vrefresh' has to be zero. Maybe this helps?

What is is the output when you run with this patch:

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 12ab80c..f5d215d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -310,6 +310,8 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
u32 clkdiv;

+   DRM_DEBUG_KMS("vrefresh %d\n", mode->vrefresh);
+
if (ctx->i80_if) {
/*
 * The frame done interrupt should be occurred prior to the
@@ -328,6 +330,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
+   DRM_DEBUG_KMS("vrefresh %d\n", adjusted_mode->vrefresh);
if (adjusted_mode->vrefresh == 0)
adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;

[Intel-gfx] [PATCH v2 02/17] drm/atomic: Allow drivers to subclass drm_atomic_state, v3

[Daniel Vetter]

On Mon, May 18, 2015 at 10:06:40AM +0200, Maarten Lankhorst wrote:
> Drivers may need to store the state of shared resources, such as PLLs
> or FIFO space, into the atomic state. Allow this by making it possible
> to subclass drm_atomic_state.
> 
> Changes since v1:
> - Change member names for functions to atomic_state_(alloc,clear)
> - Change __drm_atomic_state_new to drm_atomic_state_init
> - Allow free function to be overridden too, in case extra memory is
>   allocated in alloc.
> Changes since v2:
> - Rename *_default_free to default_release, to make clear it doesn't
>   free the state object itself.

I'd have gone with just _release since we don't have a ->release hook nor
a drm_atomic_helper_state_release wrapper. But that's really a bikeshed
now ;-)

> Cc: dri-devel at lists.freedesktop.org
> Acked-by: Ander Conselvan de Oliveira  intel.com>
> Signed-off-by: Maarten Lankhorst 

Applied to topic/drm-misc, thanks.
-Daniel

> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c6277a4a1f2f..cd1b16b25716 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,7 +30,15 @@
>  #include 
>  #include 
>  
> -static void kfree_state(struct drm_atomic_state *state)
> +/**
> + * drm_atomic_state_default_release -
> + * release memory initialized by drm_atomic_state_init
> + * @state: atomic state
> + *
> + * Free all the memory allocated by drm_atomic_state_init.
> + * This is useful for drivers that subclass the atomic state.
> + */
> +void drm_atomic_state_default_release(struct drm_atomic_state *state)
>  {
>   kfree(state->connectors);
>   kfree(state->connector_states);
> @@ -38,24 +46,20 @@ static void kfree_state(struct drm_atomic_state *state)
>   kfree(state->crtc_states);
>   kfree(state->planes);
>   kfree(state->plane_states);
> - kfree(state);
>  }
> +EXPORT_SYMBOL(drm_atomic_state_default_release);
>  
>  /**
> - * drm_atomic_state_alloc - allocate atomic state
> + * drm_atomic_state_init - init new atomic state
>   * @dev: DRM device
> + * @state: atomic state
>   *
> - * This allocates an empty atomic state to track updates.
> + * Default implementation for filling in a new atomic state.
> + * This is useful for drivers that subclass the atomic state.
>   */
> -struct drm_atomic_state *
> -drm_atomic_state_alloc(struct drm_device *dev)
> +int
> +drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
>  {
> - struct drm_atomic_state *state;
> -
> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (!state)
> - return NULL;
> -
>   /* TODO legacy paths should maybe do a better job about
>* setting this appropriately?
>*/
> @@ -92,31 +96,50 @@ drm_atomic_state_alloc(struct drm_device *dev)
>  
>   state->dev = dev;
>  
> - DRM_DEBUG_ATOMIC("Allocate atomic state %p\n", state);
> + DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state);
>  
> - return state;
> + return 0;
>  fail:
> - kfree_state(state);
> + drm_atomic_state_default_release(state);
> + return -ENOMEM;
> +}
> +EXPORT_SYMBOL(drm_atomic_state_init);
> +
> +/**
> + * drm_atomic_state_alloc - allocate atomic state
> + * @dev: DRM device
> + *
> + * This allocates an empty atomic state to track updates.
> + */
> +struct drm_atomic_state *
> +drm_atomic_state_alloc(struct drm_device *dev)
> +{
> + struct drm_mode_config *config = >mode_config;
> + struct drm_atomic_state *state;
> +
> + if (!config->funcs->atomic_state_alloc) {
> + state = kzalloc(sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return NULL;
> + if (drm_atomic_state_init(dev, state) < 0) {
> + kfree(state);
> + return NULL;
> + }
> + return state;
> + }
>  
> - return NULL;
> + return config->funcs->atomic_state_alloc(dev);
>  }
>  EXPORT_SYMBOL(drm_atomic_state_alloc);
>  
>  /**
> - * drm_atomic_state_clear - clear state object
> + * drm_atomic_state_default_clear - clear base atomic state
>   * @state: atomic state
>   *
> - * When the w/w mutex algorithm detects a deadlock we need to back off and 
> drop
> - * all locks. So someone else could sneak in and change the current modeset
> - * configuration. Which means that all the state assembled in @state is no
> - * longer an atomic update to the current state, but to some arbitrary 
> earlier
> - * state. Which could break assumptions the driver's ->atomic_check likely
> - * relies on.
> - *
> - * Hence we must clear all cached state and completely start over, using this
> - * function.
> + * Default implementation for clearing atomic state.
> + * This is useful for drivers that subclass the atomic state.
>   */
> -void drm_atomic_state_clear(struct drm_atomic_state *state)
> +void drm_atomic_state_default_clear(struct drm_atomic_state *state)
>  {
>   struct drm_device *dev = 

[Bug 90484] LLVM >=r237140 causes gpu lockups Spec Ops: The Line

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Arek Ruśniak  ---
It's complicated a little bit more than i thought.
r237139 is affected too, but need more time(about 100-120 sec)to trigger, this
is why i didn't see it before. Now i've tried r230876 and time to trigger ~ 11
min. And a really dunno what interval should i take. 

But still trying.

Sylvain i will try it and give feedback to you. (and i have Cape Verde XT
(hd7770), I should buy Pitcairn but i was to stingy:)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/4a6314b0/attachment.html>

[Bug 90263] GPU card fans run full speed at all times

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Todd  ---
"Newer" is an odd description. The card is from 2011. For reference, it is a
Gigabyte GV-R687OC-1GD.

http://www.gigabyte.com/products/product-page.aspx?pid=3663

If you need additional information, just ask.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/125564a7/attachment-0001.html>

[PATCH v2 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Vladimir Zapolskiy]

The change adds support of internal HDMI I2C master controller, this
subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.

The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.

Signed-off-by: Vladimir Zapolskiy 
---
Changes since v1:
- fixed a devm_kfree() signature
- split completions for read and write operations

 drivers/gpu/drm/bridge/dw_hdmi.c | 341 ++-
 1 file changed, 335 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 49cafb6..7f64e73 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1,15 +1,17 @@
 /*
+ * DesignWare High-Definition Multimedia Interface (HDMI) driver
+ *
+ * Copyright (C) 2013-2015 Mentor Graphics Inc.
  * Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010, Guennadi Liakhovetski 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
- * Designware High-Definition Multimedia Interface (HDMI) driver
- *
- * Copyright (C) 2010, Guennadi Liakhovetski 
  */
+
 #include 
 #include 
 #include 
@@ -28,6 +30,26 @@

 #include "dw_hdmi.h"

+/* HDMI_IH_I2CM_STAT0 and HDMI_IH_MUTE_I2CM_STAT0 register bits */
+#define HDMI_IH_I2CM_STAT0_ERROR   BIT(0)
+#define HDMI_IH_I2CM_STAT0_DONEBIT(1)
+
+/* HDMI_I2CM_OPERATION register bits */
+#define HDMI_I2CM_OPERATION_READ   BIT(0)
+#define HDMI_I2CM_OPERATION_READ_EXT   BIT(1)
+#define HDMI_I2CM_OPERATION_WRITE  BIT(4)
+
+/* HDMI_I2CM_INT register bits */
+#define HDMI_I2CM_INT_DONE_MASKBIT(2)
+#define HDMI_I2CM_INT_DONE_POL BIT(3)
+
+/* HDMI_I2CM_CTLINT register bits */
+#define HDMI_I2CM_CTLINT_ARB_MASK  BIT(2)
+#define HDMI_I2CM_CTLINT_ARB_POL   BIT(3)
+#define HDMI_I2CM_CTLINT_NAC_MASK  BIT(6)
+#define HDMI_I2CM_CTLINT_NAC_POL   BIT(7)
+
+
 #define HDMI_EDID_LEN  512

 #define RGB0
@@ -102,6 +124,19 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

+struct dw_hdmi_i2c {
+   struct i2c_adapter  adap;
+
+   spinlock_t  lock;
+   struct completion   cmp_r;
+   struct completion   cmp_w;
+   u8  stat;
+
+   u8  operation_reg;
+   u8  slave_reg;
+   boolis_regaddr;
+};
+
 struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
@@ -111,6 +146,7 @@ struct dw_hdmi {
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
+   struct dw_hdmi_i2c *i2c;

struct hdmi_data_info hdmi_data;
const struct dw_hdmi_plat_data *plat_data;
@@ -179,6 +215,249 @@ static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 
data, unsigned int reg,
hdmi_modb(hdmi, data << shift, mask, reg);
 }

+static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>i2c->lock, flags);
+
+   /* Set Fast Mode speed */
+   hdmi_writeb(hdmi, 0x0b, HDMI_I2CM_DIV);
+
+   /* Software reset */
+   hdmi_writeb(hdmi, 0x00, HDMI_I2CM_SOFTRSTZ);
+
+   /* Set done, not acknowledged and arbitration interrupt polarities */
+   hdmi_writeb(hdmi, HDMI_I2CM_INT_DONE_POL, HDMI_I2CM_INT);
+   hdmi_writeb(hdmi, HDMI_I2CM_CTLINT_NAC_POL | HDMI_I2CM_CTLINT_ARB_POL,
+   HDMI_I2CM_CTLINT);
+
+   /* Clear DONE and ERROR interrupts */
+   hdmi_writeb(hdmi, HDMI_IH_I2CM_STAT0_ERROR | HDMI_IH_I2CM_STAT0_DONE,
+   HDMI_IH_I2CM_STAT0);
+
+   /* Mute DONE and ERROR interrupts */
+   hdmi_writeb(hdmi, HDMI_IH_I2CM_STAT0_ERROR | HDMI_IH_I2CM_STAT0_DONE,
+   HDMI_IH_MUTE_I2CM_STAT0);
+
+   spin_unlock_irqrestore(>i2c->lock, flags);
+}
+
+static int dw_hdmi_i2c_read(struct dw_hdmi *hdmi,
+   unsigned char *buf, int length)
+{
+   int stat;
+   unsigned long flags;
+   struct dw_hdmi_i2c *i2c = hdmi->i2c;
+
+   spin_lock_irqsave(>lock, flags);
+
+   i2c->operation_reg = HDMI_I2CM_OPERATION_READ;
+
+   if (!i2c->is_regaddr) {
+   dev_dbg(hdmi->dev, "set read register address to 0\n");
+   i2c->slave_reg = 0x00;
+   i2c->is_regaddr = true;
+   }
+
+   while (length--) {
+   reinit_completion(>cmp_r);
+   i2c->stat = 0;
+
+   hdmi_writeb(hdmi, i2c->slave_reg++, HDMI_I2CM_ADDRESS);
+   hdmi_writeb(hdmi, i2c->operation_reg, 

[PATCH 1/2] drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name

[Vladimir Zapolskiy]

I2CM_ADDRESS became a MESS, fix it, also change guarding define
to __DW_HDMI_H__ , since the driver is not IMX specific.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/bridge/dw_hdmi.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index 175dbc8..ee7f7ed 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -7,8 +7,8 @@
  * (at your option) any later version.
  */

-#ifndef __IMX_HDMI_H__
-#define __IMX_HDMI_H__
+#ifndef __DW_HDMI_H__
+#define __DW_HDMI_H__

 /* Identification Registers */
 #define HDMI_DESIGN_ID  0x
@@ -525,7 +525,7 @@

 /* I2C Master Registers (E-DDC) */
 #define HDMI_I2CM_SLAVE 0x7E00
-#define HDMI_I2CMESS0x7E01
+#define HDMI_I2CM_ADDRESS   0x7E01
 #define HDMI_I2CM_DATAO 0x7E02
 #define HDMI_I2CM_DATAI 0x7E03
 #define HDMI_I2CM_OPERATION 0x7E04
@@ -1031,4 +1031,4 @@ enum {
HDMI_A_VIDPOLCFG_HSYNCPOL_ACTIVE_LOW = 0x0,
 };

-#endif /* __IMX_HDMI_H__ */
+#endif /* __DW_HDMI_H__ */
-- 
2.1.4

[PATCH v2 0/2] drm: bridge/dw_hdmi: add I2C bus adapter support

[Vladimir Zapolskiy]

This change adds support of internal HDMI I2C master controller,
originally the controller has its own separate driver written from
scratch http://patchwork.ozlabs.org/patch/405100 but due to shared
register space and interrupt with HDMI driver, it makes sense to
merge the code of both drivers.

The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.

To use/test the change "ddc-i2c-bus" DT property must be omitted and
pin settings must be updated accordingly, here is an example for
iMX6 SabreLite:

---8<---
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 0b28a9d..22d4431 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -174,7 +174,6 @@
 };

  {
-   ddc-i2c-bus = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hdmi>;
status = "okay";
 };

@@ -193,13 +192,6 @@
};
 };

- {
-   clock-frequency = <10>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_i2c2>;
-   status = "okay";
-};
-
  {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -284,10 +276,10 @@
>;
};

-   pinctrl_i2c2: i2c2grp {
+   pinctrl_hdmi: hdmigrp {
fsl,pins = <
-   MX6QDL_PAD_KEY_COL3__I2C2_SCL   
0x4001b8b1
-   MX6QDL_PAD_KEY_ROW3__I2C2_SDA   
0x4001b8b1
+   MX6QDL_PAD_KEY_COL3__HDMI_TX_DDC_SCL
0x4001b8b1
+   MX6QDL_PAD_KEY_ROW3__HDMI_TX_DDC_SDA
0x4001b8b1
>;
};

---8<---

Changes since v1:
- fixed a devm_kfree() signature
- split completions for read and write operations

Vladimir Zapolskiy (2):
  drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name
  drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

 drivers/gpu/drm/bridge/dw_hdmi.c | 341 ++-
 drivers/gpu/drm/bridge/dw_hdmi.h |   8 +-
 2 files changed, 339 insertions(+), 10 deletions(-)

-- 
2.1.4

[PATCH] radeon: Deinline indirect register accessor functions

[Ilia Mirkin]

On Mon, May 18, 2015 at 3:04 PM, Christian König
 wrote:
> On 18.05.2015 20:50, Denys Vlasenko wrote:
>>
>> On 05/18/2015 08:06 PM, Christian König wrote:
>>>
>>> I'm actually surprised how often people come along with that. The last
>>> time we tried this it caused a noticeable performance drop.
>>>
>>> Basic problem is that this line:

 +if ((reg < rdev->rmmio_size || reg < RADEON_MIN_MMIO_SIZE) &&
 !always_indirect)
>>>
>>> optimizes away in most of the cases which reduces the call to a readl
>>> which is way faster than the spinlock path.
>>>
>>> So this is a NAK,
>>
>>
>> Fair enough.
>>
>> I'm preparing a v2 where the fast branch of r100_mm_{r,w}reg() will stay
>> inlined.
>>
> Sounds good to be, but IIRC that was suggested the last time this came up as
> well. You might just want to google a bit why it wasn't done like this
> before submitting the patch for review.
>
> BTW: Please CC the dri-devel list as well, cause not everybody is reading on
> linux-kernel.

http://lists.freedesktop.org/archives/dri-devel/2014-April/057349.html
...
http://lists.freedesktop.org/archives/dri-devel/2014-April/057520.html

Actually Lauri was *inlining* the function, not out-of-lining. I made
the suggestion (and you agreed at the time) that the slow-path should
be kept out of line, but apparently there was still high CPU overhead
as a result?

Cheers,

  -ilia

[Bug 87856] Driver load fails with no error on ppc64 host

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Alex Deucher  ---
(In reply to kristof from comment #4)
> PS : can someone tells me if it this an "abnornal" things in the last dmesg
> | egrep 'drm|radeon' please ?
> 
> Thanks and have a nice day

The kernel side looks fine.  It appears to be a problem with the usermode
stack.  You might be able to work around it by disabling acceleration.  Try
adding:
Option "NoAccel" "True"
to the device section of your xorg config.

I'm not really sure how well the usermode stuff works on BE systems.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/be21073d/attachment.html>

[Bug 90484] LLVM >=r237140 causes gpu lockups Spec Ops: The Line

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Sylvain BERTRAND  ---
Since you are on PITCAIRN, give a try with R600_DEBUG=switch_on_eop

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/28eefce8/attachment.html>

[Bug 90370] [radeonsi] dota2 suffers from many glitches

[bugzilla-dae...@freedesktop.org]

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

Sylvain BERTRAND  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/cf18b1fd/attachment.html>

[BUG/REGRESSION] Radeon HDMI casuses oops on Acube Sam460ex amcc 460ex power board

[Julian Margetson]

On 5/18/2015 12:08 PM, Alex Deucher wrote:
> On Sun, May 17, 2015 at 7:20 PM, Julian Margetson  wrote:
>> Kernels 4.03 and 4.04  oops with HDMI connection on Acube Sam460ex amcc
>> 460ex powerpc  board.
>>
>> 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8 is the first bad commit
>>
>> commit 016a255b7835ee7e49a3eba3c14ba0bc0221a4f8
>> Author: Alex Deucher 
>> Date:   Tue Apr 7 09:52:42 2015 -0400
>>
>>  drm/radeon: only mark audio as connected if the monitor supports it (v3)
>>
>>  commit 0f55db36d49d45b80eff0c0a2a498766016f458b upstream.
>>
>>  Otherwise the driver may try and send audio which may confuse the
>>  monitor.
>>
>>  v2: set pin to NULL if no audio
>>  v3: avoid crash with analog encoders
>>
>>  Signed-off-by: Alex Deucher 
>>  Signed-off-by: Greg Kroah-Hartman 
>>
>> :04 04 de0366a6790f5c91d175bcb89cb34956bbe72b26
>> bbdb5734961f824558152c7c34a840c78bc3a9a9 M drivers
>>
> The attached patch should fix it up.
>
> Alex
>
>
>>
>> [2.587570] Linux agpgart interface v0.103
>> [2.591997] [drm] Initialized drm 1.1.0 20060810
>> [2.596892] [drm] radeon kernel modesetting enabled.
>> [2.602989] [drm] initializing kernel modesetting (VERDE 0x1002:0x683F
>> 0x1545:0x7750).
>> [2.611161] [drm] register mmio base: 0xe9000
>> [2.615935] [drm] register mmio size: 262144
>> [2.952043] ATOM BIOS: C44501
>> [2.955323] radeon 0001:81:00.0: VRAM: 1024M 0x -
>> 0x3FFF (1024M used)
>> [2.964253] radeon 0001:81:00.0: GTT: 1024M 0x4000 -
>> 0x7FFF
>> [2.971938] [drm] Detected VRAM RAM=1024M, BAR=256M
>> [2.976840] [drm] RAM width 128bits DDR
>> [2.980898] [TTM] Zone  kernel: Available graphics memory: 379358 kiB
>> [2.987383] [TTM] Zone highmem: Available graphics memory: 1034718 kiB
>> [2.993934] [TTM] Initializing pool allocator
>> [2.998331] [TTM] Initializing DMA pool allocator
>> [3.003153] [drm] radeon: 1024M of VRAM memory ready
>> [3.008162] [drm] radeon: 1024M of GTT memory ready.
>> [3.013203] [drm] Loading verde Microcode
>> [3.017266] [drm] Internal thermal controller with fan control
>> [3.023437] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0
>> [3.077284] [drm] radeon: dpm initialized
>> [3.081503] [drm] GART: num cpu pages 262144, num gpu pages 262144
>> [3.093142] [drm] probing gen 2 caps for device aaa1:bed1 = 18cc41/0
>> [3.125984] [drm] PCIE GART of 1024M enabled (table at
>> 0x00277000).
>> [3.133327] radeon 0001:81:00.0: WB enabled
>> [3.137565] radeon 0001:81:00.0: fence driver on ring 0 use gpu addr
>> 0x4c00 and cpu addr 0xffc01c00
>> [3.147697] radeon 0001:81:00.0: fence driver on ring 1 use gpu addr
>> 0x4c04 and cpu addr 0xffc01c04
>> [3.157827] radeon 0001:81:00.0: fence driver on ring 2 use gpu addr
>> 0x4c08 and cpu addr 0xffc01c08
>> [3.167957] radeon 0001:81:00.0: fence driver on ring 3 use gpu addr
>> 0x4c0c and cpu addr 0xffc01c0c
>> [3.178078] radeon 0001:81:00.0: fence driver on ring 4 use gpu addr
>> 0x4c10 and cpu addr 0xffc01c10
>> [3.209673] radeon 0001:81:00.0: fence driver on ring 5 use gpu addr
>> 0x00075a18 and cpu addr 0xf90b5a18
>> [3.219822] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [3.226457] [drm] Driver supports precise vblank timestamp query.
>> [3.232584] radeon 0001:81:00.0: radeon: MSI limited to 32-bit
>> [3.238466] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
>> [3.244586] [drm] radeon: irq initialized.
>> [4.006339] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
>> (scratch(0x850C)=0xCAFEDEAD)
>> [4.015198] radeon 0001:81:00.0: disabling GPU acceleration
>> [4.220071] [drm] Radeon Display Connectors
>> [4.224651] [drm] Connector 0:
>> [4.227787] [drm]   HDMI-A-1
>> [4.230754] [drm]   HPD4
>> [4.233328] [drm]   DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578 0x657c
>> 0x657c
>> [4.240806] [drm]   Encoders:
>> [4.243815] [drm] DFP1: INTERNAL_UNIPHY2
>> [4.248131] [drm] Connector 1:
>> [4.251227] [drm]   DVI-I-1
>> [4.254051] [drm]   HPD2
>> [4.256608] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
>> 0x656c
>> [4.264034] [drm]   Encoders:
>> [4.267021] [drm] DFP2: INTERNAL_UNIPHY
>> [4.271223] [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [4.390562] [drm] fb mappable at 0x80478000
>> [4.394789] [drm] vram apper at 0x8000
>> [4.398905] [drm] size 8294400
>> [4.401978] [drm] fb depth is 24
>> [4.405225] [drm]pitch is 7680
>> [4.700581] Console: switching to colour frame buffer device 240x67
>> [4.779669] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer device
>> [4.786489] radeon 0001:81:00.0: registered panic notifier
>> [4.796803] [drm] Initialized radeon 2.41.0 20080528 for 

[Bug 90510] [radeon][tahiti xt] IA_MULTI_VGT_PARAM programming seems broken

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Sylvain BERTRAND  ---
There are still some glitches, but they are rare.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/4652fca5/attachment.html>

[Bug 90510] [radeon][tahiti xt] IA_MULTI_VGT_PARAM programming seems broken

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 90510
   Summary: [radeon][tahiti xt] IA_MULTI_VGT_PARAM programming
seems broken
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: sylvain.bertrand at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

This is a follow-up of the bug #90370.
source engine games produce tons of graphical glitches, unless
R600_DEBUG='switch_on_eop' is defined.
Tested with dota2/portal2. For portal2, the amount of glitches depends on
the level you choose.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/79cfefe3/attachment-0001.html>

[Bug 90370] [radeonsi] dota2 suffers from many glitches

[bugzilla-dae...@freedesktop.org]

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

--- Comment #16 from Sylvain BERTRAND  ---
Got lucky and nailed the second one (for 99.99% of the glitches):
R600_DEBUG='switch_on_eop' fixed 99.99% of the glitches in dota2/portal2.
I open a more specific bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/d4093caa/attachment.html>

[Bug 90263] GPU card fans run full speed at all times

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Alex Deucher  ---
Apparently you have a newer barts card that has limited default fan profile. 
Support for SMC fan control would need to be written for pre-SI cards and
reviewed for release.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/192d12d1/attachment.html>

[PATCH] drm/radeon: clean up radeon_audio_enable

[Alex Deucher]

- make it static
- fix mask/bool handling for last param

Signed-off-by: Alex Deucher 
Cc: stable at vgter.kernel.org
---
 drivers/gpu/drm/radeon/radeon_audio.c | 18 +-
 drivers/gpu/drm/radeon/radeon_audio.h |  2 --
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_audio.c 
b/drivers/gpu/drm/radeon/radeon_audio.c
index 31b60f6..9e9f6a1 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.c
+++ b/drivers/gpu/drm/radeon/radeon_audio.c
@@ -242,6 +242,13 @@ static struct radeon_audio_funcs dce6_dp_funcs = {
.dpms = evergreen_dp_enable,
 };

+static void radeon_audio_enable(struct radeon_device *rdev,
+   struct r600_audio_pin *pin, u8 enable_mask)
+{
+   if (rdev->audio.funcs->enable)
+   rdev->audio.funcs->enable(rdev, pin, enable_mask);
+}
+
 static void radeon_audio_interface_init(struct radeon_device *rdev)
 {
if (ASIC_IS_DCE6(rdev)) {
@@ -307,7 +314,7 @@ int radeon_audio_init(struct radeon_device *rdev)

/* disable audio.  it will be set up later */
for (i = 0; i < rdev->audio.num_pins; i++)
-   radeon_audio_enable(rdev, >audio.pin[i], false);
+   radeon_audio_enable(rdev, >audio.pin[i], 0);

return 0;
 }
@@ -443,13 +450,6 @@ static void radeon_audio_select_pin(struct drm_encoder 
*encoder)
radeon_encoder->audio->select_pin(encoder);
 }

-void radeon_audio_enable(struct radeon_device *rdev,
-   struct r600_audio_pin *pin, u8 enable_mask)
-{
-   if (rdev->audio.funcs->enable)
-   rdev->audio.funcs->enable(rdev, pin, enable_mask);
-}
-
 void radeon_audio_detect(struct drm_connector *connector,
 enum drm_connector_status status)
 {
@@ -507,7 +507,7 @@ void radeon_audio_fini(struct radeon_device *rdev)
return;

for (i = 0; i < rdev->audio.num_pins; i++)
-   radeon_audio_enable(rdev, >audio.pin[i], false);
+   radeon_audio_enable(rdev, >audio.pin[i], 0);

rdev->audio.enabled = false;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_audio.h 
b/drivers/gpu/drm/radeon/radeon_audio.h
index c92d059..8438304 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.h
+++ b/drivers/gpu/drm/radeon/radeon_audio.h
@@ -74,8 +74,6 @@ u32 radeon_audio_endpoint_rreg(struct radeon_device *rdev,
 void radeon_audio_endpoint_wreg(struct radeon_device *rdev,
u32 offset, u32 reg, u32 v);
 struct r600_audio_pin *radeon_audio_get_pin(struct drm_encoder *encoder);
-void radeon_audio_enable(struct radeon_device *rdev,
-   struct r600_audio_pin *pin, u8 enable_mask);
 void radeon_audio_fini(struct radeon_device *rdev);
 void radeon_audio_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode);
-- 
1.8.3.1

[PATCH] drm/radeon: properly select encoder in radeon_audio_detect

[Alex Deucher]

Need to handle DVI where we way end up with an analog encoder
in some cases.

Reported-by: Julian Margetson 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_audio.c  | 18 ++
 drivers/gpu/drm/radeon/radeon_connectors.c |  2 +-
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_audio.c 
b/drivers/gpu/drm/radeon/radeon_audio.c
index dcb7796..31b60f6 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.c
+++ b/drivers/gpu/drm/radeon/radeon_audio.c
@@ -453,22 +453,24 @@ void radeon_audio_enable(struct radeon_device *rdev,
 void radeon_audio_detect(struct drm_connector *connector,
 enum drm_connector_status status)
 {
-   struct radeon_device *rdev;
-   struct radeon_encoder *radeon_encoder;
+   struct drm_device *dev = connector->dev;
+   struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder_atom_dig *dig;
+   const struct drm_connector_helper_funcs *connector_funcs =
+   connector->helper_private;
+   struct drm_encoder *encoder = connector_funcs->best_encoder(connector);
+   struct radeon_encoder *radeon_encoder;

-   if (!connector || !connector->encoder)
+   if (!connector || !encoder)
return;

-   if (!radeon_encoder_is_digital(connector->encoder))
+   if (!radeon_encoder_is_digital(encoder))
return;

-   rdev = connector->encoder->dev->dev_private;
-
if (!radeon_audio_chipset_supported(rdev))
return;

-   radeon_encoder = to_radeon_encoder(connector->encoder);
+   radeon_encoder = to_radeon_encoder(encoder);
dig = radeon_encoder->enc_priv;

if (!dig->afmt)
@@ -484,7 +486,7 @@ void radeon_audio_detect(struct drm_connector *connector,
else
radeon_encoder->audio = rdev->audio.hdmi_funcs;

-   dig->afmt->pin = radeon_audio_get_pin(connector->encoder);
+   dig->afmt->pin = radeon_audio_get_pin(encoder);
if (drm_detect_monitor_audio(radeon_connector_edid(connector))) 
{
radeon_audio_enable(rdev, dig->afmt->pin, 0xf);
} else {
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index d17d251..c251eac 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1379,7 +1379,7 @@ out:
/* updated in get modes as well since we need to know if it's analog or 
digital */
radeon_connector_update_scratch_regs(connector, ret);

-   if (radeon_audio != 0) {
+   if ((radeon_audio != 0) && (radeon_connector->use_digital)) {
radeon_connector_get_edid(connector);
radeon_audio_detect(connector, ret);
}
-- 
1.8.3.1

[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds

[Alex Deucher]

Since we are messing with state in the worker.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 7162c93..5b12c3f 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,10 +79,12 @@ static void radeon_hotplug_work_func(struct work_struct 
*work)
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;

+   mutex_lock(_config->mutex);
if (mode_config->num_connector) {
list_for_each_entry(connector, _config->connector_list, 
head)
radeon_connector_hotplug(connector);
}
+   mutex_unlock(_config->mutex);
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(dev);
 }
@@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct *work)
struct drm_connector *connector;

/* this should take a mutex */
+   mutex_lock(_config->mutex);
if (mode_config->num_connector) {
list_for_each_entry(connector, _config->connector_list, 
head)
radeon_connector_hotplug(connector);
}
+   mutex_unlock(_config->mutex);
 }
 /**
  * radeon_driver_irq_preinstall_kms - drm irq preinstall callback
-- 
1.8.3.1

[PATCH] drm/radeon: make dpcd parameters const

[Alex Deucher]

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 8 
 drivers/gpu/drm/radeon/radeon_mode.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 3e3290c..ed173d3 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -253,7 +253,7 @@ void radeon_dp_aux_init(struct radeon_connector 
*radeon_connector)
 #define DP_VOLTAGE_MAX DP_TRAIN_VOLTAGE_SWING_LEVEL_3
 #define DP_PRE_EMPHASIS_MAXDP_TRAIN_PRE_EMPH_LEVEL_3

-static void dp_get_adjust_train(u8 link_status[DP_LINK_STATUS_SIZE],
+static void dp_get_adjust_train(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count,
u8 train_set[4])
 {
@@ -311,7 +311,7 @@ static int dp_get_max_dp_pix_clock(int link_rate,
 /* radeon specific DP functions */

 int radeon_dp_get_max_link_rate(struct drm_connector *connector,
-   u8 dpcd[DP_DPCD_SIZE])
+   const u8 dpcd[DP_DPCD_SIZE])
 {
int max_link_rate;

@@ -328,7 +328,7 @@ int radeon_dp_get_max_link_rate(struct drm_connector 
*connector,
  * if the max lane# < low rate lane# then use max lane# instead.
  */
 static int radeon_dp_get_dp_lane_number(struct drm_connector *connector,
-   u8 dpcd[DP_DPCD_SIZE],
+   const u8 dpcd[DP_DPCD_SIZE],
int pix_clock)
 {
int bpp = convert_bpc_to_bpp(radeon_get_monitor_bpc(connector));
@@ -347,7 +347,7 @@ static int radeon_dp_get_dp_lane_number(struct 
drm_connector *connector,
 }

 static int radeon_dp_get_dp_link_clock(struct drm_connector *connector,
-  u8 dpcd[DP_DPCD_SIZE],
+  const u8 dpcd[DP_DPCD_SIZE],
   int pix_clock)
 {
int bpp = convert_bpc_to_bpp(radeon_get_monitor_bpc(connector));
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index fa91a17..6de5459 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -754,7 +754,7 @@ extern bool radeon_dp_getdpcd(struct radeon_connector 
*radeon_connector);
 extern int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
struct drm_connector *connector);
 int radeon_dp_get_max_link_rate(struct drm_connector *connector,
-   u8 *dpcd);
+   const u8 *dpcd);
 extern void radeon_dp_set_rx_power_state(struct drm_connector *connector,
 u8 power_state);
 extern void radeon_dp_aux_init(struct radeon_connector *radeon_connector);
-- 
1.8.3.1

[BUG/REGRESSION] Radeon HDMI casuses oops on Acube Sam460ex amcc 460ex power board

[Alex Deucher]

r device
> [4.786489] radeon 0001:81:00.0: registered panic notifier
> [4.796803] [drm] Initialized radeon 2.41.0 20080528 for 0001:81:00.0 on
> minor 0
>
> [   31.191562] Unable to handle kernel paging request for data at address
> 0x0008
> [   31.258832] Faulting instruction address: 0xc04a51bc
> [   34.049506] Oops: Kernel access of bad area, sig: 11 [#1]
> [   34.055246] PREEMPT Canyonlands
> [   34.058586] Modules linked in:
> [   34.061830] CPU: 0 PID: 1998 Comm: Xorg Not tainted 4.0.3-Sam460ex #2
> [   34.068633] task: edee4c60 ti: ede8a000 task.ti: ede8a000
> [   34.074334] NIP: c04a51bc LR: c04a546c CTR: c03e5050
> [   34.079578] REGS: ede8bc30 TRAP: 0300   Not tainted  (4.0.3-Sam460ex)
> [   34.086381] MSR: 00029000 <CE,EE,ME>  CR: 20004422  XER: 
> [   34.092944] DEAR: 0008 ESR: 
> GPR00: c04a5438 ede8bce0 edee4c60 eea84000   c071
> 
> GPR08:   eeac0400 ede8bce0 2000 b7a55afc b80efab0
> b80ee530
> GPR16:   6f23c730 ede8be18 c03add44 eeac0578 0001
> 4000
> GPR24: 4000 c0719b98 fff2 0001 eeb61200 eea84000 eea8df00
> 
> [   34.127485] NIP [c04a51bc] radeon_audio_enable+0x4/0x18
> [   34.133000] LR [c04a546c] radeon_audio_detect+0xd4/0x104
> [   34.138604] Call Trace:
> [   34.141185] [ede8bce0] [c04a5438] radeon_audio_detect+0xa0/0x104
> (unreliable)
> [   34.148771] [ede8bd00] [c03e6958] radeon_dvi_detect+0x390/0x3b4
> [   34.155046] [ede8bd30] [c0391cec]
> drm_helper_probe_single_connector_modes_merge_bits+0xf4/0x448
> [   34.164253] [ede8bd70] [c03ade28] drm_mode_getconnector+0xe4/0x334
> [   34.170796] [ede8be10] [c03a0be8] drm_ioctl+0x348/0x464
> [   34.176343] [ede8bed0] [c00ce2e8] do_vfs_ioctl+0x52c/0x6e8
> [   34.182158] [ede8bf20] [c00ce4e4] SyS_ioctl+0x40/0x68
> [   34.187515] [ede8bf40] [c000ab1c] ret_from_syscall+0x0/0x3c
> [   34.193417] --- interrupt: c01 at 0x6fb001dc
> [   34.193417] LR = 0x6fb00100
> [   34.201216] Instruction dump:
> [   34.204368] 8129012c 806a0018 2f89 419e0018 81290004 2f89
> 419e000c 7d2903a6
> [   34.212674] 4e800420 3860 4e800020 81231cd8 <81290008> 2f89
> 4d9e0020 7d2903a6
> [   34.376219] ---[ end trace 803e15e46b991816 ]---
> [   34.380843]
>  * Starting Mount filesystems on boot[ OK ]
>  *
>
>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-properly-select-encoder-in-radeon_audio_d.patch
Type: text/x-patch
Size: 2848 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/22f77d32/attachment.bin>

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2015-05-08:
- skl plane scaler support (Chandra Kondru)
- enable hsw cmd parser (Daniel and fix from Rebecca Palmer)
- skl dc5/6 support (low power display modes) from Suketu
- dp compliance testing patches (Todd Previte)
- dp link training optimization (Mika Kahola)
- fixes to make skl resume work (Damien)
- rework modeset code to fully use atomic state objects (Ander)
- pile of bxt w/a patchs from Nick Hoath
- (linear) partial gtt mmap support (Joonas Lahtinen)

Cheers, Daniel


The following changes since commit e1dee1973c74a0408b108d88c57a15be8a2d6d84:

  Merge tag 'drm-intel-next-2015-04-23-fixed' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2015-05-08 20:51:06 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-05-08

for you to fetch changes up to 214a2b7fab215b1e979fbae51225b01b8fc58288:

  drm/i915: Update DRIVER_DATE to 20150508 (2015-05-08 17:38:19 +0200)


- skl plane scaler support (Chandra Kondru)
- enable hsw cmd parser (Daniel and fix from Rebecca Palmer)
- skl dc5/6 support (low power display modes) from Suketu
- dp compliance testing patches (Todd Previte)
- dp link training optimization (Mika Kahola)
- fixes to make skl resume work (Damien)
- rework modeset code to fully use atomic state objects (Ander)
- pile of bxt w/a patchs from Nick Hoath
- (linear) partial gtt mmap support (Joonas Lahtinen)


A.Sunil Kamath (2):
  drm/i915/skl: Implement enable/disable for Display C5 state.
  Implement enable/disable for Display C6 state

Ander Conselvan de Oliveira (28):
  drm/i915: Don't check for NULL before freeing state
  drm/i915: Call drm helpers when duplicating crtc and plane states
  drm/i915: Use for_each_connector_in_state helper macro
  drm/i915: Extract mode_changed computation out of stage_output_config()
  drm/i915: Add crtc states before calling compute_config()
  drm/i915: Don't pretend we can calculate multiple pipe_configs
  drm/i915: Calculate a new pipe_config based on new enabled state
  drm/i915: Remove all *_pipes flags from modeset
  drm/i915: Remove saved_mode from __intel_set_mode()
  drm/i915: Move compute part of __intel_set_mode() to separate function
  drm/i915: Simplify error handling in __intel_set_mode()
  drm/i915: Don't modeset with old mode when set_crtc fails
  drm/i915: Add primary plane to atomic state in legacy modeset
  drm/i915: Delete fb, x and y parameters from mode set functions
  drm/i915: Don't use struct intel_set_config *_changed flags
  drm/i915: Don't use staged config to calculate mode_changed flags
  drm/i915: Unify modeset and flip paths of intel_crtc_set_config()
  drm/i915: Simplify intel_set_config_compute_mode_changes() a bit
  drm/i915: Stage new modeset state straight into atomic state
  drm/i915: Remove save/restore logic from intel_crtc_set_config()
  drm/i915: Update crtc state active flag based on DPMS
  drm/atomic: Make mode_fixup() optional for check_modeset()
  drm/i915: Use atomic helpers for computing changed flags
  drm/i915: Take ownership of atomic state on success in intel_set_mode()
  drm/i915: Preserve shared DPLL information in new pipe_config
  drm/i915: Don't use plane update helper in legacy mode set
  drm/i915: Swap atomic state in legacy modeset
  drm/i915: Get rid of intel_crtc_set_state()

Chandra Konduru (2):
  drm/i915: skylake primary plane scaling using shared scalers
  drm/i915: skylake sprite plane scaling using shared scalers

Chris Wilson (3):
  drm/i915: Add RPS thresholds to debugfs/i915_frequency_info
  drm/i915: Remove incorrect restriction on 32bit offsets in ppGTT backend
  drm/i915: Remove locking for get-caching query

Damien Lespiau (7):
  drm/i915/skl: Add the INIT power domain to the MISC I/O power well
  drm/i915/skl: Fix the CTRL typo in the DPLL_CRTL1 defines
  drm/i915: Re-order the PCU opcodes
  drm/i915: Merge the GEN9 memory latency PCU opcode with its friends
  drm/i915/skl: Make the Misc I/O power well part of the PLLS domain
  drm/i915/skl: Fix WaDisableChickenBitTSGBarrierAckForFFSliceCS
  drm/i915/skl: Re-indent part of skl_ddi_calculate_wrpll()

Dan Carpenter (1):
  drm/i915: checking IS_ERR() instead of NULL

Daniel Vetter (4):
  drm/i915: Simplify cmd-parser DISPATCH_SECURE check
  drm/i915/skl: Add support to load SKL CSR firmware.
  drm/edid: Kerneldoc for newly added edid_corrupt
  drm/i915: Update DRIVER_DATE to 20150508

Deepak S (1):
  drm/i915: Setup static bias for GPU

Fabian Frederick (1):
  drm/i915: use ERR_CAST instead of ERR_PTR/PTR_ERR

Jani Nikula (2):
  drm/i915: make drm_crtc_helper_funcs const data
  drm/i915/audio: do not mess with 

[PATCH v2 02/17] drm/atomic: Allow drivers to subclass drm_atomic_state, v3

[Maarten Lankhorst]

Drivers may need to store the state of shared resources, such as PLLs
or FIFO space, into the atomic state. Allow this by making it possible
to subclass drm_atomic_state.

Changes since v1:
- Change member names for functions to atomic_state_(alloc,clear)
- Change __drm_atomic_state_new to drm_atomic_state_init
- Allow free function to be overridden too, in case extra memory is
  allocated in alloc.
Changes since v2:
- Rename *_default_free to default_release, to make clear it doesn't
  free the state object itself.

Cc: dri-devel at lists.freedesktop.org
Acked-by: Ander Conselvan de Oliveira 
Signed-off-by: Maarten Lankhorst 

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c6277a4a1f2f..cd1b16b25716 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,7 +30,15 @@
 #include 
 #include 

-static void kfree_state(struct drm_atomic_state *state)
+/**
+ * drm_atomic_state_default_release -
+ * release memory initialized by drm_atomic_state_init
+ * @state: atomic state
+ *
+ * Free all the memory allocated by drm_atomic_state_init.
+ * This is useful for drivers that subclass the atomic state.
+ */
+void drm_atomic_state_default_release(struct drm_atomic_state *state)
 {
kfree(state->connectors);
kfree(state->connector_states);
@@ -38,24 +46,20 @@ static void kfree_state(struct drm_atomic_state *state)
kfree(state->crtc_states);
kfree(state->planes);
kfree(state->plane_states);
-   kfree(state);
 }
+EXPORT_SYMBOL(drm_atomic_state_default_release);

 /**
- * drm_atomic_state_alloc - allocate atomic state
+ * drm_atomic_state_init - init new atomic state
  * @dev: DRM device
+ * @state: atomic state
  *
- * This allocates an empty atomic state to track updates.
+ * Default implementation for filling in a new atomic state.
+ * This is useful for drivers that subclass the atomic state.
  */
-struct drm_atomic_state *
-drm_atomic_state_alloc(struct drm_device *dev)
+int
+drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *state;
-
-   state = kzalloc(sizeof(*state), GFP_KERNEL);
-   if (!state)
-   return NULL;
-
/* TODO legacy paths should maybe do a better job about
 * setting this appropriately?
 */
@@ -92,31 +96,50 @@ drm_atomic_state_alloc(struct drm_device *dev)

state->dev = dev;

-   DRM_DEBUG_ATOMIC("Allocate atomic state %p\n", state);
+   DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state);

-   return state;
+   return 0;
 fail:
-   kfree_state(state);
+   drm_atomic_state_default_release(state);
+   return -ENOMEM;
+}
+EXPORT_SYMBOL(drm_atomic_state_init);
+
+/**
+ * drm_atomic_state_alloc - allocate atomic state
+ * @dev: DRM device
+ *
+ * This allocates an empty atomic state to track updates.
+ */
+struct drm_atomic_state *
+drm_atomic_state_alloc(struct drm_device *dev)
+{
+   struct drm_mode_config *config = >mode_config;
+   struct drm_atomic_state *state;
+
+   if (!config->funcs->atomic_state_alloc) {
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return NULL;
+   if (drm_atomic_state_init(dev, state) < 0) {
+   kfree(state);
+   return NULL;
+   }
+   return state;
+   }

-   return NULL;
+   return config->funcs->atomic_state_alloc(dev);
 }
 EXPORT_SYMBOL(drm_atomic_state_alloc);

 /**
- * drm_atomic_state_clear - clear state object
+ * drm_atomic_state_default_clear - clear base atomic state
  * @state: atomic state
  *
- * When the w/w mutex algorithm detects a deadlock we need to back off and drop
- * all locks. So someone else could sneak in and change the current modeset
- * configuration. Which means that all the state assembled in @state is no
- * longer an atomic update to the current state, but to some arbitrary earlier
- * state. Which could break assumptions the driver's ->atomic_check likely
- * relies on.
- *
- * Hence we must clear all cached state and completely start over, using this
- * function.
+ * Default implementation for clearing atomic state.
+ * This is useful for drivers that subclass the atomic state.
  */
-void drm_atomic_state_clear(struct drm_atomic_state *state)
+void drm_atomic_state_default_clear(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
struct drm_mode_config *config = >mode_config;
@@ -162,6 +185,32 @@ void drm_atomic_state_clear(struct drm_atomic_state *state)
state->plane_states[i] = NULL;
}
 }
+EXPORT_SYMBOL(drm_atomic_state_default_clear);
+
+/**
+ * drm_atomic_state_clear - clear state object
+ * @state: atomic state
+ *
+ * When the w/w mutex algorithm detects a deadlock we need to back off and drop
+ * all locks. So someone else could sneak in and change the current 

[Bug 87856] Driver load fails with no error on ppc64 host

[bugzilla-dae...@freedesktop.org]

B62).
[   13.544639] radeon :04:00.0: Using 64-bit DMA iommu bypass
[   13.544658] [drm] register mmio base: 0x9000
[   13.544663] [drm] register mmio size: 65536
[   13.544841] radeon :04:00.0: Invalid ROM contents
[   13.544868] radeon :04:00.0: Invalid ROM contents
[   13.544881] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[   13.544972] [drm] Using device-tree clock info
[   13.545019] [drm] Generation 2 PCI interface, using max accessible memory
[   13.545031] radeon :04:00.0: VRAM: 128M 0x9800 -
0x9FFF (128M used)
[   13.545040] radeon :04:00.0: GTT: 512M 0x7800 -
0x97FF
[   13.549473] [drm] Detected VRAM RAM=128M, BAR=128M
[   13.549489] [drm] RAM width 128bits DDR
[   13.549842] [drm] radeon: 128M of VRAM memory ready
[   13.549850] [drm] radeon: 512M of GTT memory ready.
[   13.549915] [drm] GART: num cpu pages 8192, num gpu pages 131072
[   13.550164] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
[   13.579036] [drm] PCIE GART of 512M enabled (table at 0x9804).
[   13.582052] radeon :04:00.0: WB enabled
[   13.582150] radeon :04:00.0: fence driver on ring 0 use gpu addr
0x7800 and cpu addr 0xc0004d1f
[   13.583048] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   13.583066] [drm] Driver supports precise vblank timestamp query.
[   13.583081] radeon :04:00.0: radeon: MSI limited to 32-bit
[   13.583135] [drm] radeon: irq initialized.
[   13.583180] [drm] Loading R300 Microcode
[   13.655061] radeon :04:00.0: firmware: direct-loading firmware
radeon/R300_cp.bin
[   13.655383] [drm] radeon: ring at 0x7801
[   13.655421] [drm] ring test succeeded in 0 usecs
[   13.655637] [drm] ib test succeeded in 0 usecs
[   13.689091] [drm] Connector Table: 8 (imac g5 isight)
[   13.689133] [drm] No TMDS info found in BIOS
[   13.689285] [drm] No TV DAC info found in BIOS
[   13.689444] [drm] Radeon Display Connectors
[   13.689450] [drm] Connector 0:
[   13.689454] [drm]   DVI-D-1
[   13.689459] [drm]   HPD1
[   13.689465] [drm]   DDC: 0x68 0x68 0x68 0x68 0x68 0x68 0x68 0x68
[   13.689470] [drm]   Encoders:
[   13.689475] [drm] DFP1: INTERNAL_TMDS1
[   13.689479] [drm] Connector 1:
[   13.689483] [drm]   VGA-1
[   13.689489] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[   13.689494] [drm]   Encoders:
[   13.689498] [drm] CRT2: INTERNAL_DAC2
[   13.689503] [drm] Connector 2:
[   13.689507] [drm]   SVIDEO-1
[   13.689511] [drm]   Encoders:
[   13.689515] [drm] TV1: INTERNAL_DAC2
[   13.888366] [drm] fb mappable at 0x980C
[   13.888385] [drm] vram apper at 0x9800
[   13.888390] [drm] size 5242880
[   13.888395] [drm] fb depth is 24
[   13.888399] [drm]pitch is 5760
[   13.955320] radeon :04:00.0: fb0: radeondrmfb frame buffer device
[   13.955425] radeon :04:00.0: registered panic notifier
[   13.984018] [drm] Initialized radeon 2.39.0 20080528 for :04:00.0 on
minor 0

PS : can someone tells me if it this an "abnornal" things in the last dmesg |
egrep 'drm|radeon' please ?

Thanks and have a nice day

Kristof

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/d279154d/attachment-0001.html>

[PULL] drm-amdkfd-next

[Oded Gabbay]

On Mon, May 18, 2015 at 9:29 AM, Oded Gabbay  wrote:

> Hi Dave,
>
> Here is the pull request of amdkfd for 4.2
>
> drm-amdkfd-next-2015-05-18:
>
> - Add the interrupts & events modules, including new IOCTLs to create and
> wait
>   on events. The HSA RT open source stack is mainly using events to know
> when
>   a dispatched work has been completed. In addition, this module is
>   a pre-requisite for the next module I'm going to upstream - debugger
> support
>
>   This module also handles H/W exceptions, such as memory exception
> received
>   through the IOMMUv2 H/W and Bad Opcode exception receieved from the GPU.
>
> - Adding a new kernel module parameter to let the user decide whether he
> wants
>   to receive a SIGTERM when a memory exception occurs inside the GPU
> kernel and
>   the HSA application doesn't wait on an appropriate event, or if he just
> want
>   to receive notification about this event in dmesg. The default is the
> latter.
>
> - Additional improvements for SDMA code
>
> - Update my email address in Maintainers file as I'm leaving AMD in two
> weeks.
>
> Thanks,
>
> Oded
>
> The following changes since commit
> dde10068e1a4798fa44e68a5d08b5dfe3602cbba:
>
>   Merge branch 'drm-armada-devel' of git://
> ftp.arm.linux.org.uk/~rmk/linux-arm into drm-next (2015-05-15 15:24:41
> +1000)
>
> are available in the git repository at:
>
>   ssh://gabbayo at people.freedesktop.org/~gabbayo/linux
> tags/drm-amdkfd-next-2015-05-18
>
> for you to fetch changes up to a441b1ddc5ad53aaa9e6d4d0b98387b1cf0a9ba8:
>
>   drm/amdkfd: change driver version to 0.7.2 (2015-05-18 09:15:28 +0300)
>
> 
> Alexey Skidanov (2):
>   drm/amdkfd: Add memory exception handling
>   drm/amdkfd: Add bad opcode exception handling
>
> Andrew Lewycky (4):
>   drm/amdkfd: Add interrupt handling module
>   drm/amdkfd: add events IOCTL set definitions
>   drm/amdkfd: Add the events module
>   drm/amdkfd: Implement events IOCTLs
>
> Firo Yang (1):
>   drm/amdkfd: Remove unessary void pointer cast
>
> Oded Gabbay (7):
>   drm/amdkfd: reformat some debug prints
>   drm/amdkfd: Use new struct for asic specific ops
>   drm/amdkfd: make the sdma vm init to be asic specific
>   MAINTAINERS: update amdkfd Oded's email address
>   drm/radeon: Add init interrupt kfd->kgd interface
>   drm/amdkfd: Add module parameter of send_sigterm
>   drm/amdkfd: change driver version to 0.7.2
>
>  MAINTAINERS|   2 +-
>  drivers/gpu/drm/amd/amdkfd/Makefile|   1 +
>  drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c   |  66 ++
>  drivers/gpu/drm/amd/amdkfd/cik_int.h   |  41 +
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  87 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c|  52 +-
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  30 +-
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  21 +-
>  .../drm/amd/amdkfd/kfd_device_queue_manager_cik.c  |  18 +-
>  .../drm/amd/amdkfd/kfd_device_queue_manager_vi.c   |  10 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c  |  15 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_events.c| 965
> +
>  drivers/gpu/drm/amd/amdkfd/kfd_events.h|  84 ++
>  drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 188 
>  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |   5 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_module.c|   9 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  75 ++
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c   |  27 +-
>  drivers/gpu/drm/amd/include/kgd_kfd_interface.h|   2 +
>  drivers/gpu/drm/radeon/cik_reg.h   |   2 +
>  drivers/gpu/drm/radeon/cikd.h  |   1 +
>  drivers/gpu/drm/radeon/radeon_kfd.c|  21 +-
>  include/uapi/linux/kfd_ioctl.h |  96 +-
>  23 files changed, 1778 insertions(+), 40 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
>  create mode 100644 drivers/gpu/drm/amd/amdkfd/cik_int.h
>  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.c
>  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.h
>  create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>

​Fixing Alex's email address.​
​Sorry.​

-- 
  Oded
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/1a96a4a1/attachment.html>

[PULL] drm-amdkfd-next

[Oded Gabbay]

Hi Dave,

Here is the pull request of amdkfd for 4.2

drm-amdkfd-next-2015-05-18:

- Add the interrupts & events modules, including new IOCTLs to create and wait
  on events. The HSA RT open source stack is mainly using events to know when 
  a dispatched work has been completed. In addition, this module is 
  a pre-requisite for the next module I'm going to upstream - debugger support

  This module also handles H/W exceptions, such as memory exception received 
  through the IOMMUv2 H/W and Bad Opcode exception receieved from the GPU.

- Adding a new kernel module parameter to let the user decide whether he wants
  to receive a SIGTERM when a memory exception occurs inside the GPU kernel and
  the HSA application doesn't wait on an appropriate event, or if he just want
  to receive notification about this event in dmesg. The default is the latter.

- Additional improvements for SDMA code

- Update my email address in Maintainers file as I'm leaving AMD in two weeks.

Thanks,

Oded

The following changes since commit dde10068e1a4798fa44e68a5d08b5dfe3602cbba:

  Merge branch 'drm-armada-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm 
into drm-next (2015-05-15 15:24:41 +1000)

are available in the git repository at:

  ssh://gabbayo at people.freedesktop.org/~gabbayo/linux 
tags/drm-amdkfd-next-2015-05-18

for you to fetch changes up to a441b1ddc5ad53aaa9e6d4d0b98387b1cf0a9ba8:

  drm/amdkfd: change driver version to 0.7.2 (2015-05-18 09:15:28 +0300)


Alexey Skidanov (2):
  drm/amdkfd: Add memory exception handling
  drm/amdkfd: Add bad opcode exception handling

Andrew Lewycky (4):
  drm/amdkfd: Add interrupt handling module
  drm/amdkfd: add events IOCTL set definitions
  drm/amdkfd: Add the events module
  drm/amdkfd: Implement events IOCTLs

Firo Yang (1):
  drm/amdkfd: Remove unessary void pointer cast

Oded Gabbay (7):
  drm/amdkfd: reformat some debug prints
  drm/amdkfd: Use new struct for asic specific ops
  drm/amdkfd: make the sdma vm init to be asic specific
  MAINTAINERS: update amdkfd Oded's email address
  drm/radeon: Add init interrupt kfd->kgd interface
  drm/amdkfd: Add module parameter of send_sigterm
  drm/amdkfd: change driver version to 0.7.2

 MAINTAINERS|   2 +-
 drivers/gpu/drm/amd/amdkfd/Makefile|   1 +
 drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c   |  66 ++
 drivers/gpu/drm/amd/amdkfd/cik_int.h   |  41 +
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  87 +-
 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  52 +-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  30 +-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  21 +-
 .../drm/amd/amdkfd/kfd_device_queue_manager_cik.c  |  18 +-
 .../drm/amd/amdkfd/kfd_device_queue_manager_vi.c   |  10 +-
 drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c  |  15 +-
 drivers/gpu/drm/amd/amdkfd/kfd_events.c| 965 +
 drivers/gpu/drm/amd/amdkfd/kfd_events.h|  84 ++
 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 188 
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |   5 +-
 drivers/gpu/drm/amd/amdkfd/kfd_module.c|   9 +-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  75 ++
 drivers/gpu/drm/amd/amdkfd/kfd_process.c   |  27 +-
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h|   2 +
 drivers/gpu/drm/radeon/cik_reg.h   |   2 +
 drivers/gpu/drm/radeon/cikd.h  |   1 +
 drivers/gpu/drm/radeon/radeon_kfd.c|  21 +-
 include/uapi/linux/kfd_ioctl.h |  96 +-
 23 files changed, 1778 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c
 create mode 100644 drivers/gpu/drm/amd/amdkfd/cik_int.h
 create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.c
 create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_events.h
 create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c

[PATCH] drm/atomic: remove duplicated assignment of old_plane_state

[Daniel Vetter]

On Fri, May 15, 2015 at 04:12:27PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> old_plane_state is already assigned to old_state->plane_states[i] inside
> for_each_plane_in_state(). Here we remove an the extra assignment.
> 
> Signed-off-by: Gustavo Padovan 

Applied to topic/drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5d30592..c9af027 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1130,8 +1130,6 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>   if (!funcs)
>   continue;
>  
> - old_plane_state = old_state->plane_states[i];
> -
>   /*
>* Special-case disabling the plane if drivers support it.
>*/
> -- 
> 2.1.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/dp: Fix comment in DP helper

[Daniel Vetter]

On Wed, May 13, 2015 at 12:30:46PM +0100, Jon Hunter wrote:
> Commit 4f71d0cb76339 ("drm/dp: add a hw mutex around the transfer
> functions. (v2)"), renamed the functions drm_dp_aux_register_i2c_bus()
> and drm_dp_aux_unregister_i2c_bus() to drm_dp_aux_register() and
> drm_dp_aux_unregister(), respectively. However, a comment referring to
> the original names was not updated in the DP helper header file. Hence,
> correct these names.
> 
> Signed-off-by: Jon Hunter 

Applied to topic/drm-misc, thanks.
-Daniel

> ---
>  include/drm/drm_dp_helper.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 523f04c90dea..2e86f642fc33 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -679,9 +679,9 @@ struct drm_dp_aux_msg {
>   * An AUX channel can also be used to transport I2C messages to a sink. A
>   * typical application of that is to access an EDID that's present in the
>   * sink device. The .transfer() function can also be used to execute such
> - * transactions. The drm_dp_aux_register_i2c_bus() function registers an
> - * I2C adapter that can be passed to drm_probe_ddc(). Upon removal, drivers
> - * should call drm_dp_aux_unregister_i2c_bus() to remove the I2C adapter.
> + * transactions. The drm_dp_aux_register() function registers an I2C
> + * adapter that can be passed to drm_probe_ddc(). Upon removal, drivers
> + * should call drm_dp_aux_unregister() to remove the I2C adapter.
>   * The I2C adapter uses long transfers by default; if a partial response is
>   * received, the adapter will drop down to the size given by the partial
>   * response for this transaction only.
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 90484] LLVM >=r237140 causes gpu lockups Spec Ops: The Line

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Michel Dänzer  ---
Please run the game with the environment variable R600_DEBUG=vs,gs,ps and
attach the stderr output corresponding to the good and bad case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/6ec13970/attachment.html>

[Bug 90263] GPU card fans run full speed at all times

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Todd  ---
What additional information is required to diagnose and solve this problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150518/4633cecc/attachment.html>