date:20150331

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

--- Comment #25 from Christoph Haag  ---
Created attachment 114793
  --> https://bugs.freedesktop.org/attachment.cgi?id=114793=edit
dmesg with blizzard's heroes of the storm beta in wine

When playing Heroes of the Storm (I think you need a beta key to play) with
wine (wine-staging with csmt, I admit), I get a lot of GPU problems with
radeonsi.

I've seen "radeon :01:00.0: Packet0 not allowed!" and a lot of GPU faults,
so perhaps it is related.

It's kinda unplayable with radeonsi because it often hangs and it takes several
seconds for it to recover.

recent llvm 3.7 svn, recent mesa git, linux 3.19-ck

-- 
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/20150331/417ee084/attachment.html>

[Bug 89012] Incorrect interpolation on R600 and SI

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

Marek OlÅ¡Ã¡k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Marek OlÅ¡Ã¡k  ---
This is how the hardware works. Even though it may lead to incorrect rendering
sometimes, there is no workaround. This issue has been reported to hardware
designers.

-- 
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/20150331/7008819a/attachment.html>

[Bug 86320] Monitor on DisplayPort doesn't wake up

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

thomas at gstaedtner.net  changed:

   What|Removed |Added

 CC||thomas at gstaedtner.net

--- Comment #5 from thomas at gstaedtner.net  ---
Created attachment 114792
  --> https://bugs.freedesktop.org/attachment.cgi?id=114792=edit
Xorg.0.log after failure

I have the same issue.
In fact, I've been having this issue for years, probably since I own the
hardware.

The issue happens when I turn off my screen and turn it back on, and does so
reproducibly.
It only affects DisplayPort.

My card is a Cayman, and I'm building the X stack from git.

I've attached the relevant dmesg and the Xorg.0.log directly after the issue
appeared.

-- 
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/20150331/c013e013/attachment.html>

[Bug 86320] Monitor on DisplayPort doesn't wake up

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

--- Comment #4 from thomas at gstaedtner.net  ---
Created attachment 114791
  --> https://bugs.freedesktop.org/attachment.cgi?id=114791=edit
dmesg with bootup and failure

-- 
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/20150331/579c81be/attachment.html>

[PATCH] Revert "drm/i915: Performed deferred clflush inside set-cache-level"

2015-03-31 Thread Sudip Mukherjee

This reverts commit <0f71979ab7fbd0c71c41c2798de3d33937915434>.

my display was getting garbled for a moment very frequently. it looked
like when the screen was getting refreshed then something was going
wrong.
git bisect gave this as the first bad commit, and after reverting it
now display is not having that problem.

Signed-off-by: Sudip Mukherjee 
---

my system is x86_64.
lspci -k gives:
"VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core 
processor Graphics Controller (rev 09)
Subsystem: Foxconn International, Inc. Device 0d74
Kernel driver in use: i915"

This is my bisect log:
# bad: [e42391cd048809d903291d07f86ed3934ce138e9] Linux 4.0-rc6
# good: [b7392d2247cfe6771f95d256374f1a8e6a6f48d6] Linux 3.19-rc2
git bisect start 'v4.0-rc6' 'v3.19-rc2' '--' 'drivers/gpu/drm/i915/'
# good: [d2182a660808d9053a605e3ebc8c46a323ec6e5d] drm/i915: Don't register 
HDMI connectors for eDP ports on VLV/CHV
git bisect good d2182a660808d9053a605e3ebc8c46a323ec6e5d
# bad: [36d21f4c557a2b18ed7c9d254060d4ca07a6c5c7] drm/i915/dsi: remove 
unnecessary dsi device callbacks
git bisect bad 36d21f4c557a2b18ed7c9d254060d4ca07a6c5c7
# good: [72f95afa5faaf899f7344879b6ccd5f0cb271b28] drm/i915: Removed duplicate 
members from submit_request
git bisect good 72f95afa5faaf899f7344879b6ccd5f0cb271b28
# good: [2844a9214759901f382086644842e39ad6f7d894] drm/i915: Use pipe_name() in 
the get_plane_config() functions
git bisect good 2844a9214759901f382086644842e39ad6f7d894
# bad: [1b842c89bd8eb0e9619e1aba071c9a5529b7a179] drm/i915: Fix kzalloc() 
smatch warnings in get_initial_plane_config()
git bisect bad 1b842c89bd8eb0e9619e1aba071c9a5529b7a179
# good: [8d360dffd6d8634868e433128d5178bea14cc42c] drm/i915: Specify bsd rings 
through exec flag
git bisect good 8d360dffd6d8634868e433128d5178bea14cc42c
# good: [1197b4f230fb7c8fe3a9b549596fe130b09a0db2] drm/i915: Balance context 
pinning on reset cleanup
git bisect good 1197b4f230fb7c8fe3a9b549596fe130b09a0db2
# bad: [0f71979ab7fbd0c71c41c2798de3d33937915434] drm/i915: Performed deferred 
clflush inside set-cache-level
git bisect bad 0f71979ab7fbd0c71c41c2798de3d33937915434
# good: [a7cbedec8317a5cacecb567674fdbc1c3fb22de8] drm/i915: Rename unpin_count 
to pin_count
git bisect good a7cbedec8317a5cacecb567674fdbc1c3fb22de8

 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem.c | 31 ++-
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..abe6c16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2054,7 +2054,6 @@ struct drm_i915_gem_object {
 */
unsigned long gt_ro:1;
unsigned int cache_level:3;
-   unsigned int cache_dirty:1;

unsigned int has_dma_mapping:1;

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 27ea6bd..e9341e9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3647,14 +3647,11 @@ i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 * snooping behaviour occurs naturally as the result of our domain
 * tracking.
 */
-   if (!force && cpu_cache_is_coherent(obj->base.dev, obj->cache_level)) {
-   obj->cache_dirty = true;
+   if (!force && cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
return false;
-   }

trace_i915_gem_object_clflush(obj);
drm_clflush_sg(obj->pages);
-   obj->cache_dirty = false;

return true;
 }
@@ -3836,11 +3833,27 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
vma->node.color = cache_level;
obj->cache_level = cache_level;

-   if (obj->cache_dirty &&
-   obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
-   cpu_write_needs_clflush(obj)) {
-   if (i915_gem_clflush_object(obj, true))
-   i915_gem_chipset_flush(obj->base.dev);
+   if (cpu_write_needs_clflush(obj)) {
+   u32 old_read_domains, old_write_domain;
+
+   /* If we're coming from LLC cached, then we haven't
+* actually been tracking whether the data is in the
+* CPU cache or not, since we only allow one bit set
+* in obj->write_domain and have been skipping the clflushes.
+* Just set it to the CPU cache for now.
+*/
+   i915_gem_object_retire(obj);
+   WARN_ON(obj->base.write_domain & ~I915_GEM_DOMAIN_CPU);
+
+   old_read_domains = obj->base.read_domains;
+   old_write_domain = obj->base.write_domain;
+
+   obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+
+   trace_i915_gem_object_change_domain(obj,
+   old_read_domains,
+

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

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

--- Comment #14 from Andy Furniss  ---
(In reply to Alex Deucher from comment #13)
> I've posted an updated audio-fixes branch that may help:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes

Doesn't seem to change anything for me.

-- 
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/20150331/2a486557/attachment.html>

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

2015-03-31 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #18 from Frederik vom Hofe  ---
Yes, I merged it via git.

Basicly this is all I have done:
git pull
git checkout v4.0-rc6
git checkout -b v4.0-rc6-hdmi-patch
git remote add agd5f git://people.freedesktop.org/~agd5f/linux
git fetch agd5f
git merge agd5f/audio-fixes

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 89785] GPU Fault 147 and Ring Stalls and Tests Fail in Pillars of Eternity

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

--- Comment #10 from Tom Stellard  ---
Created attachment 114780
  --> https://bugs.freedesktop.org/attachment.cgi?id=114780=edit
Fix for bug described in commet 4

This patch should fix the problem I described in comment 4, can you test it?

-- 
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/20150331/bd3bc935/attachment.html>

[PATCH] drm: rockchip: Turn off VT switching on suspend

2015-03-31 Thread Caesar Wang

drm/rockchip already has support for disabling all displays on suspend
and enabling them on resume.

Disable automatic VT switching on suspend by the pm console tracking
layer.

Tested on veyron, used `echo mem > sys/power/state`
  => verified no VT switch

Reviewed-by: Daniel Kurtz 
Signed-off-by: Caesar Wang 
---

 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index a5d889a..eb4e0db 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
@@ -119,6 +119,9 @@ static int rockchip_drm_fbdev_create(struct drm_fb_helper 
*helper,
DRM_DEBUG_KMS("FB [%dx%d]-%d kvaddr=%p offset=%ld size=%d\n",
  fb->width, fb->height, fb->depth, rk_obj->kvaddr,
  offset, size);
+
+   fbi->skip_vt_switch = true;
+
return 0;

 err_drm_framebuffer_unref:
-- 
1.9.1

[PATCH 0/1] drm: rockchip: Turn off VT switching on suspend

2015-03-31 Thread Caesar Wang

drm/rockchip already has support for disabling all displays on suspend
and enabling them on resume.

Disable automatic VT switching on suspend by the pm console tracking
layer.

Tested on veyron, used `echo mem > sys/power/state`
  => verified no VT switch.



Caesar Wang (1):
  drm: rockchip: Turn off VT switching on suspend

 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
1.9.1

[Bug 89850] Lightning bug on Pillars of Eternity with R600_DEBUG=llvm set

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

kilobug  changed:

   What|Removed |Added

 Attachment #114779|text/plain  |image/png
  mime type||

-- 
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/20150331/d7ab09b7/attachment.html>

[Bug 89829] [bisected] radeonsi, commit 2cf48c creates artefacts in some applications (worst being Flash animations that are garbage)

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

--- Comment #3 from Laura Ekstrand  ---
Does this bug happen on any drivers/platforms besides Chromium on radeonsi?

I don't have the setup you have, so it's hard for me to test this.  I took a
look at the named commit, but it's pretty benign.  No error messages are
changed and the functionality is not directly related to framebuffer objects. 
(It's the code for Gen buffer objects).  I would be really surprised if this
was actually the culprit.

-- 
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/20150331/3c017c1e/attachment-0001.html>

[PATCH v3 2/3] drm: bridge/dw_hdmi_rockchip: improve hdmi eye-diagram test

On Mon, Mar 09, 2015 at 05:43:19PM +0800, Yakir Yang wrote:
> As for 1920x1080 display resolution, we should turn on the
> Transmitter Trailer-B.
> 
> Signed-off-by: Yakir Yang 
> ---

BTW, one of:

 drm/rockchip: dw_hdmi-rockchip: ...
 drm/rockchip: dw_hdmi: ...
 drm: rockchip: dw_hdmi-rockchip: ...
 drm: rockchip: dw_hdmi: ...
 drm: rockchip/dw_hdmi-rockchip: ...
 drm: rockchip/dw_hdmi: ...

might be a better subject line for patches which only touch the rockchip
part of this driver.  I'd also suggest one of:

 drm/imx: dw_hdmi-imx: ...
 drm/imx: dw_hdmi: ...
 drm: imx: dw_hdmi-imx: ...
 drm: imx: dw_hdmi: ...
 drm: imx/dw_hdmi-imx: ...
 drm: imx/dw_hdmi: ...

for iMX-only patches.  It doesn't really mater which as we already have
a mixture of these formats already.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[Bug 89850] Lightning bug on Pillars of Eternity with R600_DEBUG=llvm set

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

Bug ID: 89850
   Summary: Lightning bug on Pillars of Eternity with
R600_DEBUG=llvm set
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: kilobug at kilobug.org
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 114779
  --> https://bugs.freedesktop.org/attachment.cgi?id=114779=edit
Screenshot with and without bug

When Pillars of Eternity (GOG version 1.0.0.1, native Linux version) is runned
with R600_DEBUG=llvm or any combination of it (R600_DEBUG="sb hyperz llvm" for
example), the lightning is completely saturated to white. It works well with no
R600_DEBUG or with R600_DEBUG="sb hyperz".

Included screenshots with the bug and without it. Since the bug doesn't happen
using default settings, I put the severity as minor.

Additional information :

- GPU = Radeon HD 6850

- OS = Debian Sid

- Mesa version = 10.6~git1503070909.1ca39e~gd~u from Oibaf's PPA

- libllvm version = 1:3.6-2

-- 
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/20150331/84e1b34a/attachment.html>

Aw: [PATCH 3/8] drm/exynos: remove struct *_win_data abstraction on planes

2015-03-31 Thread Tobias Jakobi

Hello,

I just wanted to point out that this doesn't apply to exynos-drm-fixes, which 
was probably caused by Daniel's pitch patch here:
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-fixes=57aaaf373ede95ebaaf90695071f7b1f4a97795f

With best wishes,
Tobias


Gesendet:Â Dienstag, 31. MÃ¤rz 2015 um 17:47 Uhr
Von:Â "Gustavo Padovan" 
An:Â linux-samsung-soc at vger.kernel.org
Cc:Â dri-devel at lists.freedesktop.org, inki.dae at samsung.com, jy0922.shim 
at samsung.com, "Gustavo Padovan" 
Betreff:Â [PATCH 3/8] drm/exynos: remove struct *_win_data abstraction on planes
From: Gustavo Padovan 

struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.

It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.

v2: check for return of exynos_plane_init()

Signed-off-by: Gustavo Padovan 

fixup! drm/exynos: remove struct *_win_data abstraction on planes
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 166 --
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 184 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 23 +---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 125 +
drivers/gpu/drm/exynos/exynos_mixer.c | 214 ++---
10 files changed, 250 insertions(+), 497 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..cd67037 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -28,6 +28,7 @@
#include 

#include "exynos_drm_crtc.h"
+#include "exynos_drm_plane.h"
#include "exynos_drm_drv.h"
#include "exynos_drm_fbdev.h"
#include "exynos_drm_iommu.h"
@@ -41,32 +42,16 @@

#define WINDOWS_NR 2

-struct decon_win_data {
- unsigned int ovl_x;
- unsigned int ovl_y;
- unsigned int offset_x;
- unsigned int offset_y;
- unsigned int ovl_width;
- unsigned int ovl_height;
- unsigned int fb_width;
- unsigned int fb_height;
- unsigned int bpp;
- unsigned int pixel_format;
- dma_addr_t dma_addr;
- bool enabled;
- bool resume;
-};
-
struct decon_context {
struct device *dev;
struct drm_device *drm_dev;
struct exynos_drm_crtc *crtc;
+ struct exynos_drm_plane planes[WINDOWS_NR];
struct clk *pclk;
struct clk *aclk;
struct clk *eclk;
struct clk *vclk;
void __iomem *regs;
- struct decon_win_data win_data[WINDOWS_NR];
unsigned int default_win;
unsigned long irq_flags;
bool i80_if;
@@ -296,59 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
}
}

-static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
- struct exynos_drm_plane *plane)
-{
- struct decon_context *ctx = crtc->ctx;
- struct decon_win_data *win_data;
- int win, padding;
-
- if (!plane) {
- DRM_ERROR("plane is NULL\n");
- return;
- }
-
- win = plane->zpos;
- if (win == DEFAULT_ZPOS)
- win = ctx->default_win;
-
- if (win < 0 || win >= WINDOWS_NR)
- return;
-
-
- win_data = >win_data[win];
-
- padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
- win_data->offset_x = plane->fb_x;
- win_data->offset_y = plane->fb_y;
- win_data->fb_width = plane->fb_width + padding;
- win_data->fb_height = plane->fb_height;
- win_data->ovl_x = plane->crtc_x;
- win_data->ovl_y = plane->crtc_y;
- win_data->ovl_width = plane->crtc_width;
- win_data->ovl_height = plane->crtc_height;
- win_data->dma_addr = plane->dma_addr[0];
- win_data->bpp = plane->bpp;
- win_data->pixel_format = plane->pixel_format;
-
- DRM_DEBUG_KMS("offset_x = %d, offset_y = %d\n",
- win_data->offset_x, win_data->offset_y);
- DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
- win_data->ovl_width, win_data->ovl_height);
- DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
- DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
- plane->fb_width, plane->crtc_width);
-}
-
static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
{
- struct decon_win_data *win_data = >win_data[win];
+ struct exynos_drm_plane *plane = >planes[win];
unsigned long val;
+ int padding;

val = readl(ctx->regs + WINCON(win));
val &= ~WINCONx_BPPMODE_MASK;

- switch (win_data->pixel_format) {
+ switch (plane->pixel_format) {
case DRM_FORMAT_RGB565:
val |= WINCONx_BPPMODE_16BPP_565;
val |= WINCONx_BURSTLEN_16WORD;
@@ -397,7 +339,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win)
break;
}

- DRM_DEBUG_KMS("bpp = %d\n", win_data->bpp);
+ DRM_DEBUG_KMS("bpp = %d\n", plane->bpp);

/*
* In case of exynos, setting dma-burst to 16Word causes permanent
@@ -407,7 +349,8 @@ static void decon_win_set_pixfmt(struct

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

2015-03-31 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #17 from Alex Deucher  ---
(In reply to Frederik vom Hofe from comment #16)
> Tested the patch with v4.0rc6, makes no difference for me.

Did you test all 3 patches on that branch?

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=audio-fixes=40376b60a558434abbeabeec0d39374c15cc33af
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=audio-fixes=b12f4be774671735b067f72d569c5b6d6f9ab955
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=audio-fixes=e6704b242a1257259a5b3e8742a0411ce7dcfb48

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 4/4] drm/radeon: allow creating overlapping userptrs

From: Christian KÃ¶nig 

Similar to the Intel implementation, but instead of just falling back to a
global linear list when we have an overlapping userptr request we accumulate
all overlapping userptrs in a local list.

Signed-off-by: Christian KÃ¶nig 
---
 drivers/gpu/drm/radeon/radeon.h|   2 +-
 drivers/gpu/drm/radeon/radeon_mn.c | 102 +++--
 2 files changed, 76 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 35ab65d..a0c272e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -507,7 +507,7 @@ struct radeon_bo {
pid_t   pid;

struct radeon_mn*mn;
-   struct interval_tree_node   mn_it;
+   struct list_headmn_list;
 };
 #define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, gem_base)

diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
b/drivers/gpu/drm/radeon/radeon_mn.c
index 572b4db..0170137 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -53,6 +53,11 @@ struct radeon_mn {
struct rb_root  objects;
 };

+struct radeon_mn_node {
+   struct interval_tree_node   it;
+   struct list_headbos;
+};
+
 /**
  * radeon_mn_destroy - destroy the rmn
  *
@@ -64,14 +69,21 @@ static void radeon_mn_destroy(struct work_struct *work)
 {
struct radeon_mn *rmn = container_of(work, struct radeon_mn, work);
struct radeon_device *rdev = rmn->rdev;
-   struct radeon_bo *bo, *next;
+   struct radeon_mn_node *node, *next_node;
+   struct radeon_bo *bo, *next_bo;

mutex_lock(>mn_lock);
mutex_lock(>lock);
hash_del(>node);
-   rbtree_postorder_for_each_entry_safe(bo, next, >objects, mn_it.rb) 
{
-   interval_tree_remove(>mn_it, >objects);
-   bo->mn = NULL;
+   rbtree_postorder_for_each_entry_safe(node, next_node, >objects,
+it.rb) {
+
+   interval_tree_remove(>it, >objects);
+   list_for_each_entry_safe(bo, next_bo, >bos, mn_list) {
+   bo->mn = NULL;
+   list_del_init(>mn_list);
+   }
+   kfree(node);
}
mutex_unlock(>lock);
mutex_unlock(>mn_lock);
@@ -121,29 +133,33 @@ static void radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,

it = interval_tree_iter_first(>objects, start, end);
while (it) {
+   struct radeon_mn_node *node;
struct radeon_bo *bo;
int r;

-   bo = container_of(it, struct radeon_bo, mn_it);
+   node = container_of(it, struct radeon_mn_node, it);
it = interval_tree_iter_next(it, start, end);

-   r = radeon_bo_reserve(bo, true);
-   if (r) {
-   DRM_ERROR("(%d) failed to reserve user bo\n", r);
-   continue;
-   }
+   list_for_each_entry(bo, >bos, mn_list) {

-   r = reservation_object_wait_timeout_rcu(bo->tbo.resv, true,
-   false, MAX_SCHEDULE_TIMEOUT);
-   if (r)
-   DRM_ERROR("(%d) failed to wait for user bo\n", r);
+   r = radeon_bo_reserve(bo, true);
+   if (r) {
+   DRM_ERROR("(%d) failed to reserve user bo\n", 
r);
+   continue;
+   }

-   radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_CPU);
-   r = ttm_bo_validate(>tbo, >placement, false, false);
-   if (r)
-   DRM_ERROR("(%d) failed to validate user bo\n", r);
+   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
+   true, false, MAX_SCHEDULE_TIMEOUT);
+   if (r)
+   DRM_ERROR("(%d) failed to wait for user bo\n", 
r);

-   radeon_bo_unreserve(bo);
+   radeon_ttm_placement_from_domain(bo, 
RADEON_GEM_DOMAIN_CPU);
+   r = ttm_bo_validate(>tbo, >placement, false, 
false);
+   if (r)
+   DRM_ERROR("(%d) failed to validate user bo\n", 
r);
+
+   radeon_bo_unreserve(bo);
+   }
}

mutex_unlock(>lock);
@@ -220,24 +236,44 @@ int radeon_mn_register(struct radeon_bo *bo, unsigned 
long addr)
unsigned long end = addr + radeon_bo_size(bo) - 1;
struct radeon_device *rdev = bo->rdev;
struct radeon_mn *rmn;
+   struct radeon_mn_node *node = NULL;
+   struct list_head bos;
struct interval_tree_node *it;

rmn = radeon_mn_get(rdev);
if (IS_ERR(rmn))

[PATCH 3/4] drm/radeon: add userptr config option

From: Christian KÃ¶nig 

This allows selecting CONFIG_MMU_NOTIFIER if it isn't already selected.

Signed-off-by: Christian KÃ¶nig 
---
 drivers/gpu/drm/radeon/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 970f8e9..421ae13 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -1,3 +1,11 @@
+config DRM_RADEON_USERPTR
+   bool "Always enable userptr support"
+   depends on DRM_RADEON
+   select MMU_NOTIFIER
+   help
+ This option selects CONFIG_MMU_NOTIFIER if it isn't already
+ selected to enabled full userptr support.
+
 config DRM_RADEON_UMS
bool "Enable userspace modesetting on radeon (DEPRECATED)"
depends on DRM_RADEON
-- 
1.9.1

[PATCH 2/4] drm/radeon: fix wait in radeon_mn_invalidate_range_start

From: Christian KÃ¶nig 

We need to wait for all fences, not just the exclusive one.

Signed-off-by: Christian KÃ¶nig 
Cc: 
---
 drivers/gpu/drm/radeon/radeon_mn.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
b/drivers/gpu/drm/radeon/radeon_mn.c
index a69bd44..572b4db 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -122,7 +122,6 @@ static void radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,
it = interval_tree_iter_first(>objects, start, end);
while (it) {
struct radeon_bo *bo;
-   struct fence *fence;
int r;

bo = container_of(it, struct radeon_bo, mn_it);
@@ -134,12 +133,10 @@ static void radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,
continue;
}

-   fence = reservation_object_get_excl(bo->tbo.resv);
-   if (fence) {
-   r = radeon_fence_wait((struct radeon_fence *)fence, 
false);
-   if (r)
-   DRM_ERROR("(%d) failed to wait for user bo\n", 
r);
-   }
+   r = reservation_object_wait_timeout_rcu(bo->tbo.resv, true,
+   false, MAX_SCHEDULE_TIMEOUT);
+   if (r)
+   DRM_ERROR("(%d) failed to wait for user bo\n", r);

radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_CPU);
r = ttm_bo_validate(>tbo, >placement, false, false);
-- 
1.9.1

[PATCH 1/4] drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr

From: Christian KÃ¶nig 

We somehow try to free the SG table twice.

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

Signed-off-by: Christian KÃ¶nig 
Cc: 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d02aa1d..b292aca 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -598,6 +598,10 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
enum dma_data_direction direction = write ?
DMA_BIDIRECTIONAL : DMA_TO_DEVICE;

+   /* double check that we don't free the table twice */
+   if (!ttm->sg->sgl)
+   return;
+
/* free the sg table and pages again */
dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);

-- 
1.9.1

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

2015-03-31 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #16 from Frederik vom Hofe  ---
Tested the patch with v4.0rc6, makes no difference for me.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] drm/radeon: add video usability info support for VCE

On 31.03.2015 17:19, Leo Liu wrote:
> v2: bump version to make sure userspace backward compatibility
>
> Signed-off-by: Leo Liu 

Reviewed-by: Christian KÃ¶nig 

> ---
>   drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
>   drivers/gpu/drm/radeon/radeon_vce.c | 1 +
>   2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index d688f6c..7d620d4 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -89,9 +89,10 @@
>*   2.40.0 - Add RADEON_GEM_GTT_WC/UC, flush HDP cache before submitting
>*CS to GPU on >= r600
>*   2.41.0 - evergreen/cayman: Add SET_BASE/DRAW_INDIRECT command parsing 
> support
> + *   2.42.0 - Add VCE/VUI (Video Usability Information) support
>*/
>   #define KMS_DRIVER_MAJOR2
> -#define KMS_DRIVER_MINOR 41
> +#define KMS_DRIVER_MINOR 42
>   #define KMS_DRIVER_PATCHLEVEL   0
>   int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>   int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
> b/drivers/gpu/drm/radeon/radeon_vce.c
> index 976fe43..24f849f 100644
> --- a/drivers/gpu/drm/radeon/radeon_vce.c
> +++ b/drivers/gpu/drm/radeon/radeon_vce.c
> @@ -571,6 +571,7 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
>   case 0x0405: // rate control
>   case 0x0407: // motion estimation
>   case 0x0408: // rdo
> + case 0x0409: // vui
>   break;
>   
>   case 0x0301: // encode

[PATCH -v2 0/8] drm/exynos: clean up patches (preparing for atomic)

2015-03-31 Thread Joonyoung Shim

Hi,

On 03/26/2015 11:10 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> Here goes some clean ups to the exynos drivers. The main clean ups is
> the presetting and zpos making the property immutable and the removal
> of *_win_data structures.
> 
> v2 contains a extra patch to fix alpha setting for planes in fimd, so
> now fimd works fine even after the removal of struct fimd_win_data.
> 

Looks good to me except trivial comment.

Thanks.

>   Gustavo
>   
> ---
> Gustavo Padovan (7):
>   drm/exynos: fimd: fix alpha setting for XR24 pixel format
>   drm/exynos: remove unused exynos_crtc->win_enable() callback
>   drm/exynos: remove struct *_win_data abstraction on planes
>   drm/exynos: preset zpos value for overlay planes
>   drm/exynos: make zpos property immutable
>   drm/exynos: remove exynos_plane_destroy()
>   drm/exynos: remove leftover functions declarations
> 
> Mandeep Singh Baines (1):
>   drm/exynos: track vblank events on a per crtc basis
> 
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 176 --
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 101 ++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|  27 
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|  20 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 226 
> -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c  |  66 ++---
>  drivers/gpu/drm/exynos/exynos_drm_plane.h  |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 134 -
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 217 ++-
>  include/video/samsung_fimd.h   |   5 +
>  11 files changed, 337 insertions(+), 649 deletions(-)
>

[PATCH v3 0/3] Improve eye-diagram & single-ended test for rk3288 hdmi

On Mon, Mar 09, 2015 at 05:42:21PM +0800, Yakir Yang wrote:
> RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz,
> and single-ended test would failed when display mode is 74.25MHz.

Has anyone reviewed these changes yet?  I don't see any replies, nor
are they in David's git tree.  To me, they look mostly fine - the only
issue I get is that the final patch doesn't apply cleanly to dw_hdmi.h
since they're generated against a tree which has audio support merged.
I also see no regressions on iMX6, so I think they can be merged.

Unless anyone has any objections, I'll add these to my queue for David.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH -v2 3/8] drm/exynos: remove struct *_win_data abstraction on planes

2015-03-31 Thread Joonyoung Shim

Hi,

On 03/26/2015 11:10 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> directly.
> 
> It changes how planes are created and remove .win_mode_set() callback
> that was only filling all *_win_data structs.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 164 --
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   9 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|  14 --
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|   5 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 182 +
>  drivers/gpu/drm/exynos/exynos_drm_plane.c  |  23 +---
>  drivers/gpu/drm/exynos/exynos_drm_plane.h  |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 123 -
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 212 
> ++---
>  10 files changed, 242 insertions(+), 497 deletions(-)
> 

[snip]

> @@ -818,7 +762,9 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>  {
>   struct decon_context *ctx = dev_get_drvdata(dev);
>   struct drm_device *drm_dev = data;
> - int ret;
> + struct exynos_drm_plane *exynos_plane;
> + enum drm_plane_type type;
> + int zpos, ret;
>  
>   ret = decon_ctx_initialize(ctx, drm_dev);
>   if (ret) {
> @@ -826,8 +772,16 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   return ret;
>   }
>  
> - ctx->crtc = exynos_drm_crtc_create(drm_dev, ctx->pipe,
> -EXYNOS_DISPLAY_TYPE_LCD,
> + for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> + type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + DRM_PLANE_TYPE_OVERLAY;
> + exynos_plane_init(drm_dev, >planes[zpos], 1 << ctx->pipe,
> +   type);

Doesn't error checking need about return value of exynos_plane_init?

Thanks.

[PATCH 2/2] drm/exynos: fix the initialization order in FIMD

2015-03-31 Thread Joonyoung Shim

Hi,

Sorry for late comments.

On 03/13/2015 07:32 PM, Inki Dae wrote:
> On 2015ë 03ì 12ì¼ 13:36, Hyungwon Hwang wrote:
>> Since commit 0f04cf8df0b20a97369cb634663fef0578cbf273 ("drm/exynos:
>> fix wrong pipe calculation for crtc"), fimd_clear_channel() can be
>> called when is_drm_iommu_supported() returns true. In this case,
>> the kernel is going to be panicked because crtc is not set yet.
> 
> Nice catch!!!
> 
>>
>> [1.211156] [drm] Initialized drm 1.1.0 20060810
>> [1.216785] Unable to handle kernel NULL pointer dereference at virtual 
>> address 0350
>> [1.223415] pgd = c0004000
>> [1.226086] [0350] *pgd=
>> [1.229649] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>> [1.234940] Modules linked in:
>> [1.237982] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 
>> 4.0.0-rc1-00062-g7a7cc79-dirty #123
>> [1.246136] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [1.252214] task: ee8c8000 ti: ee8d task.ti: ee8d
>> [1.257606] PC is at fimd_wait_for_vblank+0x8/0xc8
>> [1.262370] LR is at fimd_bind+0x138/0x1a8
>> [1.266450] pc : []lr : []psr: 2113
>> [1.266450] sp : ee8d1d28  ip :   fp : 
>> [1.277906] r10: 0001  r9 : c09d693c  r8 : c0a2d6a8
>> [1.283114] r7 : 0034  r6 : 0001  r5 : ee0bb400  r4 : ee244c10
>> [1.289624] r3 :   r2 :   r1 : 0001  r0 : 
>> [1.296135] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
>> kernel
>> [1.303426] Control: 10c5387d  Table: 4000404a  DAC: 0015
>> [1.309154] Process swapper/0 (pid: 1, stack limit = 0xee8d0210)
>> [1.315143] Stack: (0xee8d1d28 to 0xee8d2000)
>> [1.319486] 1d20:    c0113d18 ee0bb400 ee0bb400 
>> ee245c30 eebbe210
>> [1.327645] 1d40: ee008a40 ee244c10 ee0bb400 0001 0034 c02fb834 
>>  c030a858
>> [1.335804] 1d60: ee244a10 eeb60780 ee008a40 eeb60740 ee0bb400 c03030d0 
>>  
>> [1.343963] 1d80: ee244a10 ee0bb400  eeb60740 eeb60810  
>>  c02f6ba4
>> [1.352123] 1da0: ee0bb400   c02e0500 ee244a00 c0a04a14 
>> ee0bb400 c02e1de4
>> [1.360282] 1dc0:  c030a858 0002 eeb60820 eeb60820 0002 
>> eeb60780 c03033d4
>> [1.368441] 1de0: c06e9cec  ee244a10 eeb60780 c0a056f8 c03035fc 
>> c0a04b24 c0a04b24
>> [1.376600] 1e00: ee244a10 0001 c0a049d0 c02f6d34 c0ad462c eeba0790 
>>  ee244a10
>> [1.384759] 1e20: ffed c0a049d0  c03090b0 ee244a10 c0ad462c 
>> c0a2d840 c03077a0
>> [1.392919] 1e40: eeb5e880 c024b738 08db ee244a10 c0a049d0 ee244a44 
>>  c09e71d8
>> [1.401078] 1e60: 00c6 c0307a6c c0a049d0  c03079e0 c0305ea8 
>> ee826e5c ee1dc7b4
>> [1.409237] 1e80: c0a049d0 eeb5e880 c0a058a8 c0306e2c c0896204 c0a049d0 
>> c06e9d10 c0a049d0
>> [1.417396] 1ea0: c06e9d10 c0ad4600  c0308360  0003 
>> c06e9d10 c02f6e14
>> [1.42] 1ec0:  c0896204     
>>  
>> [1.433714] 1ee0:   c02f6d5c c02f6d5c  eeb5d740 
>> c09e71d8 c0008a30
>> [1.441874] 1f00: ef7fca5e   0066  ee8d1f28 
>> c003ff1c c02514e8
>> [1.450033] 1f20: 6113  c093906c ef7fca5e 00c6 c004018c 
>>  c093906c
>> [1.458192] 1f40: c08a9690 c093840c 0006 0006 c09eb2ac c09c0d74 
>> 0006 c09c0d54
>> [1.466351] 1f60: c0a3d680 c09745a0 c09d693c 00c6  c0974db4 
>> 0006 0006
>> [1.474510] 1f80: c09745a0   c0692e00   
>>  
>> [1.482669] 1fa0:  c0692e08  c000f040   
>>  
>> [1.490828] 1fc0:       
>>  
>> [1.498988] 1fe0:     0013  
>>  
>> [1.507159] [] (fimd_wait_for_vblank) from [] 
>> (fimd_bind+0x138/0x1a8)
>> [1.515313] [] (fimd_bind) from [] 
>> (component_bind_all+0xc4/0x20c)
>> [1.523209] [] (component_bind_all) from [] 
>> (exynos_drm_load+0xa0/0x140)
>> [1.531632] [] (exynos_drm_load) from [] 
>> (drm_dev_register+0xa0/0xf4)
>> [1.539788] [] (drm_dev_register) from [] 
>> (drm_platform_init+0x44/0xcc)
>> [1.548121] [] (drm_platform_init) from [] 
>> (try_to_bring_up_master.part.1+0xc8/0x104)
>> [1.557668] [] (try_to_bring_up_master.part.1) from 
>> [] (component_master_add_with_match+0xd0/0x118)
>> [1.568431] [] (component_master_add_with_match) from 
>> [] (exynos_drm_platform_probe+0xf0/0x118)
>> [1.578847] [] (exynos_drm_platform_probe) from [] 
>> (platform_drv_probe+0x48/0x98)
>> [1.588052] [] (platform_drv_probe) from [] 
>> (driver_probe_device+0x140/0x380)
>> [1.596902] [] (driver_probe_device) from [] 
>> (__driver_attach+0x8c/0x90)
>> [

[PATCH] Revert "drm/i915: Performed deferred clflush inside set-cache-level"

2015-03-31 Thread Chris Wilson

On Tue, Mar 31, 2015 at 08:40:12PM +0530, Sudip Mukherjee wrote:
> This reverts commit <0f71979ab7fbd0c71c41c2798de3d33937915434>.
> 
> my display was getting garbled for a moment very frequently. it looked
> like when the screen was getting refreshed then something was going
> wrong.
> git bisect gave this as the first bad commit, and after reverting it
> now display is not having that problem.

Hmm, I fear you would be just papering over a bug. Could you please file
a bug on bugs.freedesktop.org so that we can root cause this?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PULL] topic/drm-misc

On Tue, Mar 31, 2015 at 04:29:56PM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> Final drm-misc pull for 4.0, just various things all over, including a few

s/4.0/4.1 ofc ;-)
-Daniel

> more important atomic fixes. btw I didn't pick up the vmwgfx patch from
> Ville's series, but one patch has one hunk touching vmwgfx and
> Thomas/Jakob didn't get around to ack it. I figured it's simple enough to
> be ok though.
> 
> Cheers, Daniel
> 
> 
> The following changes since commit ae10c2248593fb84c6951d67c98c9c934997e56a:
> 
>   Merge branch 'drm/next/rcar-du' of git://linuxtv.org/pinchartl/fbdev into 
> drm-next (2015-03-23 09:34:32 +1000)
> 
> are available in the git repository at:
> 
>   git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-03-31
> 
> for you to fetch changes up to 066626d5d5548d7ff63772a840b8d40a0d278825:
> 
>   drm: line wrap DRM_IOCTL_DEF* macros (2015-03-31 09:18:40 +0200)
> 
> 
> Ander Conselvan de Oliveira (2):
>   drm/atomic: Clear crtcs, connectors and planes when clearing state
>   drm/atomic: Don't try to free a NULL state
> 
> Daniel Stone (6):
>   drm: mode: Fix typo in kerneldoc
>   drm: fb_helper: Simplify exit condition
>   drm: mode: Allow NULL modes for equality check
>   drm: crtc_helper: Update hwmode before mode_set call
>   drm: atomic: Expose CRTC active property
>   drm: atomic: Allow setting CRTC active property
> 
> Daniel Vetter (1):
>   drm/atomic-helpers: Properly avoid full modeset dance
> 
> Emil Velikov (1):
>   drm: line wrap DRM_IOCTL_DEF* macros
> 
> Ville SyrjÃ¤lÃ¤ (6):
>   drm/dp: Print the number of bytes processed for aux nacks
>   drm: Fix DRM_IOCTL_DEF_DRV()
>   drm: Drop ioctl->cmd_drv
>   drm: Simplify core vs. drv ioctl handling
>   drm: Use max() to make the ioctl alloc size code cleaner
>   drm: Rewrite drm_ioctl_flags() to resemble the new drm_ioctl() code
> 
>  drivers/gpu/drm/drm_atomic.c| 27 +
>  drivers/gpu/drm/drm_atomic_helper.c |  6 ++--
>  drivers/gpu/drm/drm_crtc_helper.c   |  9 +++---
>  drivers/gpu/drm/drm_dp_helper.c |  4 +--
>  drivers/gpu/drm/drm_fb_helper.c |  6 ++--
>  drivers/gpu/drm/drm_ioctl.c | 60 
> +
>  drivers/gpu/drm/drm_modes.c |  8 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  4 +--
>  include/drm/drmP.h  | 10 +--
>  9 files changed, 80 insertions(+), 54 deletions(-)
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

[PULL] drm-intel-next

Hi Dave,

Final i915 pull for 4.1, except maybe I'll throw in a bxt stage1 enabling
patch if it's ready in time - all the core changes have landed already so
impact would be minimal, as usual.

drm-intel-next-2015-03-27:
- DP link rate refactoring from Ville
- byt/bsw rps tuning from Chris
- kerneldoc for the shrinker code
- more dynamic ppgtt pte work (Michel, Ben, ...)
- vlv dpll code refactoring to prep fro bxt (Imre)
- refactoring the sprite colorkey code (Ville)
- rotated ggtt view support from Tvrtko
- roll out struct drm_atomic_state to prep for atomic update (Ander)

Cheers, Daniel


The following changes since commit 0f9e9cd61f46c07246e30871fd638ffeaca3c576:

  Merge tag 'drm-intel-fixes-2015-03-19' into drm-intel-next (2015-03-20 
11:44:34 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-03-27-merge

for you to fetch changes up to 6e0aa8018f9c676b115b7ca6c20a056fc57c68a9:

  Merge tag 'v4.0-rc6' into drm-intel-next (2015-03-30 16:37:08 +0200)


Ahmed S. Darwish (1):
  can: kvaser_usb: Fix tx queue start/stop race conditions

Al Viro (3):
  caif: fix MSG_OOB test in caif_seqpkt_recvmsg()
  rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg()
  net: validate the range we feed to iov_iter_init() in 
sys_sendto/sys_recvfrom

Alex Deucher (1):
  drm/radeon: drop ttm two ended allocation

Alexandru M Stan (1):
  ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

Alexey Kodanev (2):
  net: sysctl_net_core: check SNDBUF and RCVBUF for min length
  vxlan: fix wrong usage of VXLAN_VID_MASK

Ameen Ali (1):
  tulip_core.c : out-of-bounds check.

Ameya Palande (1):
  mfd: kempld-core: Fix callback return value check

Ander Conselvan de Oliveira (19):
  drm/i915: Add intel_atomic_get_crtc_state() helper function
  drm/i915: Pass acquire ctx also to intel_release_load_detect_pipe()
  drm/i915: Allocate a drm_atomic_state for the legacy modeset code
  drm/i915: Allocate a crtc_state also when the crtc is being disabled
  drm/i915: Implement connector state duplication
  drm/i915: Update dummy connector atomic state with current config
  drm/i915: Copy the staged connector config to the legacy atomic state
  drm/i915: Don't use encoder->new_crtc in intel_modeset_pipe_config()
  drm/i915: Don't use encoder->new_crtc in compute_baseline_pipe_bpp()
  drm/i915: Don't depend on encoder->new_crtc in intel_dp_compute_config()
  drm/i915: Don't depend on encoder->new_crtc in intel_hdmi_compute_config
  drm/i915: Use atomic state in intel_ddi_crtc_get_new_encoder()
  drm/i915: Don't use staged config in intel_dp_mst_compute_config()
  drm/i915: Don't use encoder->new_crtc in intel_lvds_compute_config()
  drm/i915: Pass an atomic state to modeset_global_resources() functions
  drm/i915: Convert intel_pipe_will_have_type() to using atomic state
  drm/i915: Don't look at staged config crtc when changing DRRS state
  drm/i915: Remove usage of encoder->new_crtc from clock computations
  drm/i915: Handle error to get connector state when staging config

Andrei Otcheretianski (2):
  iwlwifi: mvm: Fix ROC removal
  mac80211: count interfaces correctly for combination checks

Andrzej Hajda (1):
  drm/exynos: remove unused files

Andy Lutomirski (2):
  x86/asm/entry/32: Fix user_mode() misuses
  x86/asm/entry: Check for syscall exit work with IRQs disabled

Andy Shevchenko (2):
  spi: dw-mid: clear BUSY flag fist and test other one
  dmaengine: dw: append MODULE_ALIAS for platform driver

Ard Biesheuvel (1):
  crypto: arm/aes update NEON AES module to latest OpenSSL version

Arnaldo Carvalho de Melo (1):
  perf annotate: Fix fallback to unparsed disassembler line

Arnd Bergmann (3):
  usb: musb: fix Kconfig regression
  rds: avoid potential stack overflow
  Merge tag 'v4.0-rockchip-armfixes1' of 
git://git.kernel.org/.../mmind/linux-rockchip into fixes

Axel Lin (20):
  phy: miphy28lp: Avoid calling of_get_child_count() multiple times
  phy: miphy365x: Avoid calling of_get_child_count() multiple times
  phy: armada375-usb2: Set drvdata for phy and use it
  phy: xgene: Remove duplicate code to set ctx->dev
  phy: miphy28lp: Add missing .owner field in miphy28lp_ops
  phy: exynos-mipi-video: Fixup the test for state->regmap
  phy: exynos-mipi-video: Use spin_lock to protct state->regmap rmw 
operations
  phy: exynos-dp-video: Kill exynos_dp_video_phy_pwr_isol function
  phy: hix5hd2-sata: Check return value of platform_get_resource
  phy: samsung-usb2: Remove NULL terminating entry from phys array
  phy: ti-pipe3: Simplify ti_pipe3_dpll_wait_lock implementation
  phy: rockchip-usb: Fixup rockchip_usb_phy_power_on failure path
  phy: exynos5-usbdrd: Fix off-by-one valid value checking for

[PULL] topic/drm-misc

Hi Dave,

Final drm-misc pull for 4.0, just various things all over, including a few
more important atomic fixes. btw I didn't pick up the vmwgfx patch from
Ville's series, but one patch has one hunk touching vmwgfx and
Thomas/Jakob didn't get around to ack it. I figured it's simple enough to
be ok though.

Cheers, Daniel


The following changes since commit ae10c2248593fb84c6951d67c98c9c934997e56a:

  Merge branch 'drm/next/rcar-du' of git://linuxtv.org/pinchartl/fbdev into 
drm-next (2015-03-23 09:34:32 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-03-31

for you to fetch changes up to 066626d5d5548d7ff63772a840b8d40a0d278825:

  drm: line wrap DRM_IOCTL_DEF* macros (2015-03-31 09:18:40 +0200)


Ander Conselvan de Oliveira (2):
  drm/atomic: Clear crtcs, connectors and planes when clearing state
  drm/atomic: Don't try to free a NULL state

Daniel Stone (6):
  drm: mode: Fix typo in kerneldoc
  drm: fb_helper: Simplify exit condition
  drm: mode: Allow NULL modes for equality check
  drm: crtc_helper: Update hwmode before mode_set call
  drm: atomic: Expose CRTC active property
  drm: atomic: Allow setting CRTC active property

Daniel Vetter (1):
  drm/atomic-helpers: Properly avoid full modeset dance

Emil Velikov (1):
  drm: line wrap DRM_IOCTL_DEF* macros

Ville SyrjÃ¤lÃ¤ (6):
  drm/dp: Print the number of bytes processed for aux nacks
  drm: Fix DRM_IOCTL_DEF_DRV()
  drm: Drop ioctl->cmd_drv
  drm: Simplify core vs. drv ioctl handling
  drm: Use max() to make the ioctl alloc size code cleaner
  drm: Rewrite drm_ioctl_flags() to resemble the new drm_ioctl() code

 drivers/gpu/drm/drm_atomic.c| 27 +
 drivers/gpu/drm/drm_atomic_helper.c |  6 ++--
 drivers/gpu/drm/drm_crtc_helper.c   |  9 +++---
 drivers/gpu/drm/drm_dp_helper.c |  4 +--
 drivers/gpu/drm/drm_fb_helper.c |  6 ++--
 drivers/gpu/drm/drm_ioctl.c | 60 +
 drivers/gpu/drm/drm_modes.c |  8 -
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  4 +--
 include/drm/drmP.h  | 10 +--
 9 files changed, 80 insertions(+), 54 deletions(-)

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

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

2015-03-31 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #15 from Alex Deucher  ---
I've posted an updated audio-fixes branch that may help:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

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

--- Comment #13 from Alex Deucher  ---
I've posted an updated audio-fixes branch that may help:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=audio-fixes

-- 
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/20150331/0b542d14/attachment.html>

[PATCH] android: remove unnecessary TARGET_OUT_HEADERS variable

2015-03-31 Thread Chih-Wei Huang

Signed-off-by: Chih-Wei Huang 
---
 tests/modetest/Android.mk | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/modetest/Android.mk b/tests/modetest/Android.mk
index aee3564..0fdfe68 100644
--- a/tests/modetest/Android.mk
+++ b/tests/modetest/Android.mk
@@ -7,8 +7,6 @@ LOCAL_SRC_FILES := $(MODETEST_FILES)

 LOCAL_MODULE := modetest

-LOCAL_C_INCLUDES += $(TARGET_OUT_HEADERS)/libdrm
-
 LOCAL_SHARED_LIBRARIES := libdrm

 include $(BUILD_EXECUTABLE)
-- 
1.9.3

[Bug 89831] [r600] r600_asm.c:310:assign_alu_units: Assertion `0' failed.

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

--- Comment #4 from Jacob Litewski  ---
SE_Logs.txt

https://drive.google.com/file/d/0Bx0XCc8l_ekmcTlSZFQtcXc0TDg/view?usp=sharing

-- 
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/20150331/639f02b2/attachment.html>

[Bug 89831] [r600] r600_asm.c:310:assign_alu_units: Assertion `0' failed.

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

Jacob Litewski  changed:

   What|Removed |Added

 Attachment #114743|0   |1
is obsolete||

--- Comment #3 from Jacob Litewski  ---
Created attachment 114768
  --> https://bugs.freedesktop.org/attachment.cgi?id=114768=edit
Backtrace from wine after applying proposed patch

-- 
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/20150331/e1979444/attachment.html>

[Bug 89831] [r600] r600_asm.c:310:assign_alu_units: Assertion `0' failed.

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

--- Comment #2 from Jacob Litewski  ---
The game still crashes for me with the proposed fix. Attaching the backtrace
from wine and the logs generated with 

WINEDEBUG=+d3dadapter9,+d3d9 TSGI_PRINT_SANITY=1 NINE_TGSI_DUMP=1
R600_DEBUG=all WINEPREFIX="/home/hackhalo2/.local/share/wineprefixes/steam"
wine C:\\windows\\command\\start.exe steam://rungameid/244850 2>&1 | tee
~/SE_Logs.txt

-- 
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/20150331/d0ebaba2/attachment.html>

GPU driver crashes on Thinkpad Tablet 10

2015-03-31 Thread Sébastien Bourdeauducq

On 03/31/2015 10:50 AM, Dave Airlie wrote:
> Get 4.0.0-rc6. 4.0.0-rc4 is a few weeks old already.

Ok. The Tablet 10 still contains more bugs than a rain forest with -rc6,
but not when switching VTs.

[PATCH v3] drm/msm: Initial add DSI connector support

2015-03-31 Thread Hai Li

This change adds the DSI connector support in msm drm driver.

v1: Initial change
v2:
- Address comments from Archit + minor clean-ups
- Rebase to not depend on msm_drm_sub_dev change [Rob's comment]
v3: Fix issues when initialization is failed

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Kconfig   |   11 +
 drivers/gpu/drm/msm/Makefile  |4 +
 drivers/gpu/drm/msm/dsi/dsi.c |  212 
 drivers/gpu/drm/msm/dsi/dsi.h |  117 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 1993 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  705 
 drivers/gpu/drm/msm/dsi/dsi_phy.c |  352 ++
 drivers/gpu/drm/msm/msm_drv.h |   29 +
 8 files changed, 3423 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1e6a907..5ba5631 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
  Compile in support for logging register reads/writes in a format
  that can be parsed by envytools demsm tool.  If enabled, register
  logging can be switched on via msm.reglog=y module param.
+
+config DRM_MSM_DSI
+   bool "Enable DSI support in MSM DRM driver"
+   depends on DRM_MSM
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   default y
+   help
+ Choose this option if you have a need for MIPI DSI connector
+ support.
+
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 674a132..5c144cc 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -50,5 +50,9 @@ msm-y := \

 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+   dsi/dsi_host.o \
+   dsi/dsi_manager.o \
+   dsi/dsi_phy.o

 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
new file mode 100644
index 000..28d1f95
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "dsi.h"
+
+struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi *msm_dsi)
+{
+   if (!msm_dsi || !msm_dsi->panel)
+   return NULL;
+
+   return (msm_dsi->panel_flags & MIPI_DSI_MODE_VIDEO) ?
+   msm_dsi->encoders[MSM_DSI_VIDEO_ENCODER_ID] :
+   msm_dsi->encoders[MSM_DSI_CMD_ENCODER_ID];
+}
+
+static void dsi_destroy(struct msm_dsi *msm_dsi)
+{
+   if (!msm_dsi)
+   return;
+
+   msm_dsi_manager_unregister(msm_dsi);
+   if (msm_dsi->host) {
+   msm_dsi_host_destroy(msm_dsi->host);
+   msm_dsi->host = NULL;
+   }
+
+   platform_set_drvdata(msm_dsi->pdev, NULL);
+}
+
+static struct msm_dsi *dsi_init(struct platform_device *pdev)
+{
+   struct msm_dsi *msm_dsi = NULL;
+   int ret;
+
+   if (!pdev) {
+   dev_err(>dev, "no dsi device\n");
+   ret = -ENXIO;
+   goto fail;
+   }
+
+   msm_dsi = devm_kzalloc(>dev, sizeof(*msm_dsi), GFP_KERNEL);
+   if (!msm_dsi) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+   DBG("dsi probed=%p", msm_dsi);
+
+   msm_dsi->pdev = pdev;
+   platform_set_drvdata(pdev, msm_dsi);
+
+   /* Init dsi host */
+   ret = msm_dsi_host_init(msm_dsi);
+   if (ret)
+   goto fail;
+
+   /* Register to dsi manager */
+   ret = msm_dsi_manager_register(msm_dsi);
+   if (ret)
+   goto fail;
+
+   return msm_dsi;
+
+fail:
+   if (msm_dsi)
+   dsi_destroy(msm_dsi);
+
+   return ERR_PTR(ret);
+}
+
+static int dsi_bind(struct device *dev, struct device *master, void *data)
+{
+   struct drm_device *drm = dev_get_drvdata(master);
+   struct msm_drm_private *priv = drm->dev_private;
+   struct platform_device *pdev = to_platform_device(dev);
+   struct msm_dsi *msm_dsi;
+
+   DBG("");
+   msm_dsi = dsi_init(pdev);
+   if (IS_ERR(msm_dsi))
+   return PTR_ERR(msm_dsi);
+
+

[GIT PULL] imx-drm changes to use media bus formats and LDB drm_panel support

Hi Dave,

The ldb patches in this series depend on the of-graph helpers that are
included in the "Use of-graph helpers to loop over endpoints" pull
request I've just send. Could you please merge this series after the
other?

The following changes since commit d7de390bff7ad0f551fc0e409543e98db86a65df:

  Merge branch 'drm-atmel-hlcdc-4.1-fixes' of 
git://github.com/bbrezillon/linux-at91 into drm-next (2015-03-31 13:38:01 +1000)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2015-03-31

for you to fetch changes up to 5e501ed7253b369a8a9ec553c35238a3d6808f28:

  drm/imx: imx-ldb: allow to determine bus format from the connected panel 
(2015-03-31 12:44:50 +0200)


imx-drm changes to use media bus formats and LDB drm_panel support

- Add media bus formats needed by imx-drm
- Switch to use media bus formats to describe the pixel format
  on the internal parallel bus between display interface and
  encoders
- Some preparations for TV Output via TVEv2 on i.MX5
- Add drm_panel support to the i.MX LVDS driver, allow to
  determine the bus pixel format from the panel descriptor.


Boris Brezillion (1):
  Add RGB444_1X12 and RGB565_1X16 media bus formats

Philipp Zabel (11):
  drm/imx: Add support for interlaced scanout
  drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2
  Add LVDS RGB media bus formats
  Add BGR888_1X24 and GBR888_1X24 media bus formats
  Add YUV8_1X24 media bus format
  Add RGB666_1X24_CPADHI media bus format
  drm/imx: switch to use media bus formats
  drm/imx: consolidate bus format variable names
  drm/imx: imx-ldb: add drm_panel support
  drm/imx: imx-ldb: reset display clock input when disabling LVDS
  drm/imx: imx-ldb: allow to determine bus format from the connected panel

 Documentation/DocBook/media/v4l/subdev-formats.xml | 426 -
 Documentation/devicetree/bindings/drm/imx/ldb.txt  |  62 ++-
 drivers/gpu/drm/imx/Kconfig|   1 +
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |   2 +-
 drivers/gpu/drm/imx/imx-drm-core.c |  14 +-
 drivers/gpu/drm/imx/imx-drm.h  |  10 +-
 drivers/gpu/drm/imx/imx-ldb.c  | 196 +++---
 drivers/gpu/drm/imx/imx-tve.c  |   6 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  24 +-
 drivers/gpu/drm/imx/ipuv3-plane.c  |   7 +-
 drivers/gpu/drm/imx/ipuv3-plane.h  |   2 +-
 drivers/gpu/drm/imx/parallel-display.c |  13 +-
 drivers/gpu/ipu-v3/ipu-dc.c|  18 +-
 include/uapi/linux/media-bus-format.h  |  13 +-
 include/video/imx-ipu-v3.h |   2 +-
 15 files changed, 668 insertions(+), 128 deletions(-)

regards
Philipp

[GIT PULL] Use of-graph helpers to loop over endpoints

Hi Dave,

now that the of-graph helper tag has been merged into
  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
could you merge it and these patches that use it to clean up looping
over of-graph endpoints in drm drivers:

The following changes since commit d7de390bff7ad0f551fc0e409543e98db86a65df:

  Merge branch 'drm-atmel-hlcdc-4.1-fixes' of 
git://github.com/bbrezillon/linux-at91 into drm-next (2015-03-31 13:38:01 +1000)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/of-graph-drm-2015-03-31

for you to fetch changes up to 70dab9e2de9691f550416968f818be115c7b5491:

  drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint reference on 
break (2015-03-31 12:07:51 +0200)


drm: Use of-graph helpers to loop over endpoints

Convert all drm callers that use of_graph_get_next_endpoint to loop over
of-graph endpoints to the newly introduced for_each_endpoint_of_node
helper macro.


Philipp Zabel (8):
  of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
  of: Add for_each_endpoint_of_node helper macro
  of: Add of_graph_get_port_by_id function
  Merge tag 'of-graph-for-4.0' of git://git.pengutronix.de/git/pza/linux 
into for-next
  drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs
  drm/imx: use for_each_endpoint_of_node macro in imx_drm_encoder_get_mux_id
  drm/rcar-du: use for_each_endpoint_of_node macro
  drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint 
reference on break

 drivers/coresight/of_coresight.c  | 13 ++-
 drivers/gpu/drm/drm_of.c  | 10 ++
 drivers/gpu/drm/imx/imx-drm-core.c| 20 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 25 +++---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   | 11 +++---
 drivers/media/platform/am437x/am437x-vpfe.c   |  1 -
 drivers/media/platform/soc_camera/soc_camera.c|  3 +-
 drivers/of/base.c | 41 ++-
 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |  7 +---
 include/linux/of_graph.h  | 18 ++
 10 files changed, 71 insertions(+), 78 deletions(-)

regards
Philipp

[GIT PULL] imx-drm DI clock divider and IC downscaler limit fixes

Hi Dave,

please consider pulling in these fixes for hardware limits in the IPU DI
divider and IPU IC downscaler bit fields into drm-next.

The following changes since commit 91fd89660ba2e8ee59a587294fa9b17761691b05:

  Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2015-03-30 12:17:27 +1000)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2015-03-31

for you to fetch changes up to 8f361b279f76b1e9548c9b3e59da63d3dec11bea:

  gpu: ipu-v3: turns out the IPU can only downsize 4:1 (2015-03-31 12:03:55 
+0200)


imx-drm limit fixes

Fix IPU IC downscaler to its hardware limitation of 4:1 and the
IPU DI pixel clock divider integer part to 8-bit.


Philipp Zabel (2):
  gpu: ipu-v3: limit pixel clock divider to 8-bits
  gpu: ipu-v3: turns out the IPU can only downsize 4:1

 drivers/gpu/ipu-v3/ipu-di.c | 9 +++--
 drivers/gpu/ipu-v3/ipu-ic.c | 4 ++--
 2 files changed, 5 insertions(+), 8 deletions(-)

regards
Philipp

[RFT PATCHv2] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-03-31 Thread Andreas Färber

Am 27.03.2015 um 20:21 schrieb Javier Martinez Canillas:
> Hello Krzysztof,
> 
> On 03/27/2015 05:08 PM, Krzysztof Kozlowski wrote:
>> After adding display power domain for Exynos5250 in commit
>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>> display on Chromebook Snow and others stopped working after boot.
>>
>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>> This clock is required by Display Port and is enabled by bootloader.
>> However when FIMD driver probing was deferred, the display power domain
>> was turned off. This effectively reset the value of DP clock enable
>> register.
>>
>> When exynos-dp is later probed, the clock is not enabled and display is
>> not properly configured:
>>
>> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
>> exynos-dp 145b.dp-controller: unable to config video
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> Reported-by: Javier Martinez Canillas 
>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>> Cc: 
>>
>> ---
>>
>> This should fix issue reported by Javier [1][2].
>>
> 
> I tested this patch and does indeed solves both issues I reported
> The exynos-dp probe deferral does not make the display to not be
> working and also disabling and enabling the display with:
> 
> with /sys/devices/platform/exynos-drm/graphics/fb0/blank works.
> 
> Thanks a lot for fixing this issue.
> 
> On an Exynos5250 Snow Chromebook:
> 
> Tested-by: Javier Martinez Canillas 

Seems to fix Spring Chromebook as well,

Tested-by: Andreas FÃ¤rber 

Thanks a lot,

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 NÃ¼rnberg, Germany
GF: Felix ImendÃ¶rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG NÃ¼rnberg)

[PATCH RFC 02/11] drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()

On Tue, Mar 31, 2015 at 05:02:20AM -0400, Yang Kuankuan wrote:
> Besides, as you are going an dw_hdmi cleanups, I want to point another bugs
> that relate to the HDMI CTS test. There are somethings wrong with General
> Control Pack, as for now the encoder color depth is 8-bit packing mode,
> so the color depth only support 24 bits per pixel video, In this case the
> CD filed in GCP should set to "Color Depth Not indicated".

I'm not sure I follow.

According to the iMX6 documentation, setting the CD field to either 
or 0100 indicates that the color depth is 24 bits per pixel, 8 bits per
component, 8 bit packing mode - there's no documented difference between
these.

Are you saying that you wish to pass something other than 24 bpp video
to your HDMI encoder?

> In the end we should keep the *csc_color_depth(HDMI_CSC_SCALE)* &
> *color_depth(HDMI_VP_PR_CD)* to zero, code should modify like this GCP
> would test pass:

>From what you're describing, you want CD field = 0 and CSC_SCALE = 0.
It looks like hdmi_video_packetize() will set the CD field to zero if
hdmi_data.enc_color_depth = 0, but that would cause hdmi_video_sample()
and hdmi_video_csc() to fail.  Maybe those two functions should be fixed
to accept a color depth of zero, and maybe you need to set
enc_color_depth to 0?

Interestingly, HDMI_CSC_SCALE_CSC_COLORDE_PTH_24BPP is defined to be
zero, but again, in the iMX6 data, it could take a value of either
0x00 or 0x40.  I think hdmi_video_csc() should set this to 0x40 if
hdmi_data.enc_color_depth = 0, and 0x40 for hdmi_data.enc_color_depth = 8.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

GPU driver crashes on Thinkpad Tablet 10

2015-03-31 Thread Dave Airlie

On 31 March 2015 at 00:53, SÃ©bastien Bourdeauducq  wrote:
> Hi,
>
> when you are looking for Linux bugs, the Baytrail-based Lenovo Thinkpad
> Tablet 10 is the perfect choice. When you are looking for a
> tablet/laptop, not so much and I am regularly annoyed, among many other
> things, by GPU driver crashes that can be reproduced by switching from X
> to a text VT (using Ctrl-Alt-Fx). The trace in the kernel messages is below.
>
> Kernel 3.13 does not have the problem. 4.0.0-rc4 does.
>

Get 4.0.0-rc6. 4.0.0-rc4 is a few weeks old already.
Dave.

[PATCH 8/8] drm/exynos: track vblank events on a per crtc basis

From: Mandeep Singh Baines 

The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.

Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.

Signed-off-by: Mandeep Singh Baines 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 92 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  | 13 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  6 +--
 3 files changed, 44 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 47dd2b0..eb49195 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
-   !atomic_read(_crtc->pending_flip),
-   HZ/20))
-   atomic_set(_crtc->pending_flip, 0);
+   (exynos_crtc->event == NULL), HZ/20))
+   exynos_crtc->event = NULL;
drm_crtc_vblank_off(crtc);
}

@@ -164,11 +163,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
 uint32_t page_flip_flags)
 {
struct drm_device *dev = crtc->dev;
-   struct exynos_drm_private *dev_priv = dev->dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
-   int ret = -EINVAL;
+   int ret;

/* when the page flip is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -176,48 +174,49 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
return -EINVAL;
}

-   mutex_lock(>struct_mutex);
+   if (!event)
+   return -EINVAL;

-   if (event) {
-   /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
-   event->pipe = exynos_crtc->pipe;
+   spin_lock_irq(>event_lock);
+   if (exynos_crtc->event) {
+   ret = -EBUSY;
+   goto out;
+   }

-   ret = drm_vblank_get(dev, exynos_crtc->pipe);
-   if (ret) {
-   DRM_DEBUG("failed to acquire vblank counter\n");
+   ret = drm_vblank_get(dev, exynos_crtc->pipe);
+   if (ret) {
+   DRM_DEBUG("failed to acquire vblank counter\n");
+   goto out;
+   }

-   goto out;
-   }
+   exynos_crtc->event = event;
+   spin_unlock_irq(>event_lock);

+   /*
+* the pipe from user always is 0 so we can set pipe number
+* of current owner to event.
+*/
+   event->pipe = exynos_crtc->pipe;
+
+   crtc->primary->fb = fb;
+   crtc_w = fb->width - crtc->x;
+   crtc_h = fb->height - crtc->y;
+   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, crtc->x, crtc->y,
+ crtc_w, crtc_h);
+   if (ret) {
+   crtc->primary->fb = old_fb;
spin_lock_irq(>event_lock);
-   list_add_tail(>base.link,
-   _priv->pageflip_event_list);
-   atomic_set(_crtc->pending_flip, 1);
+   exynos_crtc->event = NULL;
+   drm_vblank_put(dev, exynos_crtc->pipe);
spin_unlock_irq(>event_lock);
-
-   crtc->primary->fb = fb;
-   crtc_w = fb->width - crtc->x;
-   crtc_h = fb->height - crtc->y;
-   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
-   if (ret) {
-   crtc->primary->fb = old_fb;
-
-   spin_lock_irq(>event_lock);
-   drm_vblank_put(dev, exynos_crtc->pipe);
-   list_del(>base.link);
-   atomic_set(_crtc->pending_flip, 0);
-   spin_unlock_irq(>event_lock);
-
-   goto out;
-   }
+   return ret;
}
+
+   return 0;
+
 out:
-   mutex_unlock(>struct_mutex);
+   spin_unlock_irq(>event_lock);

[PATCH 7/8] drm/exynos: remove leftover functions declarations

From: Gustavo Padovan 

These functions were already removed by previous cleanup work, but these
ones were left behind.

Signed-off-by: Gustavo Padovan 
Acked-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index e1fd2ef..0ecd8fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -28,12 +28,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device *dev, 
int pipe);
 void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe);
 void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb);

-void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc,
-   struct exynos_drm_plane *plane);
-void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos);
-void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
-void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);
-
 /* This function gets pipe value to crtc device matched with out_type. */
 int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
unsigned int out_type);
-- 
2.1.0

[PATCH 6/8] drm/exynos: remove exynos_plane_destroy()

From: Gustavo Padovan 

The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 2fbac9b..2b0479e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -178,16 +178,10 @@ static int exynos_disable_plane(struct drm_plane *plane)
return 0;
 }

-static void exynos_plane_destroy(struct drm_plane *plane)
-{
-   exynos_disable_plane(plane);
-   drm_plane_cleanup(plane);
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = exynos_update_plane,
.disable_plane  = exynos_disable_plane,
-   .destroy= exynos_plane_destroy,
+   .destroy= drm_plane_cleanup,
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
-- 
2.1.0

[PATCH 5/8] drm/exynos: make zpos property immutable

From: Gustavo Padovan 

We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 504bd6e..2fbac9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -184,27 +184,10 @@ static void exynos_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
 }

-static int exynos_plane_set_property(struct drm_plane *plane,
-struct drm_property *property,
-uint64_t val)
-{
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_private *dev_priv = dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property) {
-   exynos_plane->zpos = val;
-   return 0;
-   }
-
-   return -EINVAL;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = exynos_update_plane,
.disable_plane  = exynos_disable_plane,
.destroy= exynos_plane_destroy,
-   .set_property   = exynos_plane_set_property,
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
@@ -216,8 +199,8 @@ static void exynos_plane_attach_zpos_property(struct 
drm_plane *plane,

prop = dev_priv->plane_zpos_property;
if (!prop) {
-   prop = drm_property_create_range(dev, 0, "zpos", 0,
-MAX_PLANE - 1);
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+"zpos", 0, MAX_PLANE - 1);
if (!prop)
return;

-- 
2.1.0

[PATCH 4/8] drm/exynos: preset zpos value for overlay planes

From: Gustavo Padovan 

Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.

Also all places that were storing zpos positions are now unsigned int.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 20 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  7 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c  | 16 +---
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |  3 ++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 17 +
 drivers/gpu/drm/exynos/exynos_mixer.c  | 11 +--
 7 files changed, 37 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index cd67037..e37f3e5 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -378,7 +378,7 @@ static void decon_win_set_colkey(struct decon_context *ctx, 
unsigned int win)
  * @protect: 1 to protect (disable updates)
  */
 static void decon_shadow_protect_win(struct decon_context *ctx,
-   int win, bool protect)
+unsigned int win, bool protect)
 {
u32 bits, val;

@@ -392,12 +392,12 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx,
writel(val, ctx->regs + SHADOWCON);
 }

-static void decon_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
 {
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *mode = >base.mode;
struct exynos_drm_plane *plane;
-   int padding, win = zpos;
+   int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
@@ -405,9 +405,6 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc, 
int zpos)
if (ctx->suspended)
return;

-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;

@@ -513,16 +510,12 @@ static void decon_win_commit(struct exynos_drm_crtc 
*crtc, int zpos)
plane->enabled = true;
 }

-static void decon_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
 {
struct decon_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
-   int win = zpos;
u32 val;

-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;

@@ -764,7 +757,8 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
enum drm_plane_type type;
-   int zpos, ret;
+   unsigned int zpos;
+   int ret;

ret = decon_ctx_initialize(ctx, drm_dev);
if (ret) {
@@ -776,7 +770,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
ret = exynos_plane_init(drm_dev, >planes[zpos],
-   1 << ctx->pipe, type);
+   1 << ctx->pipe, type, zpos);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8a2f943..26d6de1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -21,7 +21,6 @@
 #define MAX_CRTC   3
 #define MAX_PLANE  5
 #define MAX_FB_BUFFER  4
-#define DEFAULT_ZPOS   -1

 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc, base)
 #define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
@@ -104,7 +103,7 @@ struct exynos_drm_plane {
unsigned int pitch;
uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
-   int zpos;
+   unsigned int zpos;
unsigned int index_color;

bool default_win:1;
@@ -189,8 +188,8 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
-   void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
-   void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
+   void (*win_commit)(struct

[PATCH 3/8] drm/exynos: remove struct *_win_data abstraction on planes

From: Gustavo Padovan 

struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.

It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.

v2: check for return of exynos_plane_init()

Signed-off-by: Gustavo Padovan 

fixup! drm/exynos: remove struct *_win_data abstraction on planes
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 166 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   9 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  14 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   5 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 184 ++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  23 +---
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 125 +
 drivers/gpu/drm/exynos/exynos_mixer.c  | 214 ++---
 10 files changed, 250 insertions(+), 497 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..cd67037 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -28,6 +28,7 @@
 #include 

 #include "exynos_drm_crtc.h"
+#include "exynos_drm_plane.h"
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_iommu.h"
@@ -41,32 +42,16 @@

 #define WINDOWS_NR 2

-struct decon_win_data {
-   unsigned intovl_x;
-   unsigned intovl_y;
-   unsigned intoffset_x;
-   unsigned intoffset_y;
-   unsigned intovl_width;
-   unsigned intovl_height;
-   unsigned intfb_width;
-   unsigned intfb_height;
-   unsigned intbpp;
-   unsigned intpixel_format;
-   dma_addr_t  dma_addr;
-   boolenabled;
-   boolresume;
-};
-
 struct decon_context {
struct device   *dev;
struct drm_device   *drm_dev;
struct exynos_drm_crtc  *crtc;
+   struct exynos_drm_plane planes[WINDOWS_NR];
struct clk  *pclk;
struct clk  *aclk;
struct clk  *eclk;
struct clk  *vclk;
void __iomem*regs;
-   struct decon_win_data   win_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long   irq_flags;
booli80_if;
@@ -296,59 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
}
 }

-static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
-   struct exynos_drm_plane *plane)
-{
-   struct decon_context *ctx = crtc->ctx;
-   struct decon_win_data *win_data;
-   int win, padding;
-
-   if (!plane) {
-   DRM_ERROR("plane is NULL\n");
-   return;
-   }
-
-   win = plane->zpos;
-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
-   if (win < 0 || win >= WINDOWS_NR)
-   return;
-
-
-   win_data = >win_data[win];
-
-   padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
-   win_data->offset_x = plane->fb_x;
-   win_data->offset_y = plane->fb_y;
-   win_data->fb_width = plane->fb_width + padding;
-   win_data->fb_height = plane->fb_height;
-   win_data->ovl_x = plane->crtc_x;
-   win_data->ovl_y = plane->crtc_y;
-   win_data->ovl_width = plane->crtc_width;
-   win_data->ovl_height = plane->crtc_height;
-   win_data->dma_addr = plane->dma_addr[0];
-   win_data->bpp = plane->bpp;
-   win_data->pixel_format = plane->pixel_format;
-
-   DRM_DEBUG_KMS("offset_x = %d, offset_y = %d\n",
-   win_data->offset_x, win_data->offset_y);
-   DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
-   win_data->ovl_width, win_data->ovl_height);
-   DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
-   DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
-   plane->fb_width, plane->crtc_width);
-}
-
 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
 {
-   struct decon_win_data *win_data = >win_data[win];
+   struct exynos_drm_plane *plane = >planes[win];
unsigned long val;
+   int padding;

val = readl(ctx->regs + WINCON(win));
val &= ~WINCONx_BPPMODE_MASK;

-   switch (win_data->pixel_format) {
+   switch (plane->pixel_format) {
case DRM_FORMAT_RGB565:
val |=

[PATCH 2/8] drm/exynos: remove unused exynos_crtc->win_enable() callback

From: Gustavo Padovan 

None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9afd390..4e8f0b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -174,7 +174,6 @@ struct exynos_drm_display {
  * hardware overlay is updated.
  * @win_mode_set: copy drm overlay info to hw specific overlay info.
  * @win_commit: apply hardware specific overlay data to registers.
- * @win_enable: enable hardware specific overlay.
  * @win_disable: disable hardware specific overlay.
  * @te_handler: trigger to transfer video image at the tearing effect
  * synchronization signal if there is a page flip request.
@@ -192,7 +191,6 @@ struct exynos_drm_crtc_ops {
void (*win_mode_set)(struct exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane);
void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
-   void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
 };
-- 
2.1.0

[PATCH 1/8] drm/exynos: fimd: fix alpha setting for XR24 pixel format

From: Gustavo Padovan 

XR24 planes were not shown properly, so now set the right registers
to correctly enable displaying these planes.

It also moves the alpha register settings to fimd_win_set_pixfmt()
to keep all pixel format stuff together.

v2: remove leftover var alpha

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 33 +---
 include/video/samsung_fimd.h |  5 +
 2 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 925fc69..4c56fa7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -54,6 +54,9 @@
 /* size control register for hardware windows 1 ~ 2. */
 #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)

+#define VIDWnALPHA0(win)   (VIDW_ALPHA + 0x00 + (win) * 8)
+#define VIDWnALPHA1(win)   (VIDW_ALPHA + 0x04 + (win) * 8)
+
 #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
 #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) + (win) * 8)
 #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)
@@ -623,6 +626,24 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx, 
unsigned int win)
}

writel(val, ctx->regs + WINCON(win));
+
+   /* hardware window 0 doesn't support alpha channel. */
+   if (win != 0) {
+   /* OSD alpha */
+   val = VIDISD14C_ALPHA0_R(0xf) |
+   VIDISD14C_ALPHA0_G(0xf) |
+   VIDISD14C_ALPHA0_B(0xf) |
+   VIDISD14C_ALPHA1_R(0xf) |
+   VIDISD14C_ALPHA1_G(0xf) |
+   VIDISD14C_ALPHA1_B(0xf);
+
+   writel(val, ctx->regs + VIDOSD_C(win));
+
+   val = VIDW_ALPHA_R(0xf) | VIDW_ALPHA_G(0xf) |
+   VIDW_ALPHA_G(0xf);
+   writel(val, ctx->regs + VIDWnALPHA0(win));
+   writel(val, ctx->regs + VIDWnALPHA1(win));
+   }
 }

 static void fimd_win_set_colkey(struct fimd_context *ctx, unsigned int win)
@@ -670,7 +691,7 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc, 
int zpos)
struct fimd_context *ctx = crtc->ctx;
struct fimd_win_data *win_data;
int win = zpos;
-   unsigned long val, alpha, size;
+   unsigned long val, size;
unsigned int last_x;
unsigned int last_y;

@@ -747,16 +768,6 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc, 
int zpos)
DRM_DEBUG_KMS("osd pos: tx = %d, ty = %d, bx = %d, by = %d\n",
win_data->offset_x, win_data->offset_y, last_x, last_y);

-   /* hardware window 0 doesn't support alpha channel. */
-   if (win != 0) {
-   /* OSD alpha */
-   alpha = VIDISD14C_ALPHA1_R(0xf) |
-   VIDISD14C_ALPHA1_G(0xf) |
-   VIDISD14C_ALPHA1_B(0xf);
-
-   writel(alpha, ctx->regs + VIDOSD_C(win));
-   }
-
/* OSD size */
if (win != 3 && win != 4) {
u32 offset = VIDOSD_D(win);
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index a20e4a3..5132428 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -289,6 +289,11 @@
 #define VIDISD14C_ALPHA1_B_LIMIT   0xf
 #define VIDISD14C_ALPHA1_B(_x) ((_x) << 0)

+#define VIDW_ALPHA 0x021c
+#define VIDW_ALPHA_R(_x)   ((_x) << 16)
+#define VIDW_ALPHA_G(_x)   ((_x) << 8)
+#define VIDW_ALPHA_B(_x)   ((_x) << 0)
+
 /* Video buffer addresses */
 #define VIDW_BUF_START(_buff)  (0xA0 + ((_buff) * 8))
 #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
-- 
2.1.0

[PATCH -v3 0/8] drm/exynos: clean up patches (preparing for atomic)

From: Gustavo Padovan 

Hi,

Here goes some clean ups to the exynos drivers. The main clean ups is
the presetting and zpos making the property immutable and the removal
of *_win_data structures.

v2 contains a extra patch to fix alpha setting for planes in fimd, so
now fimd works fine even after the removal of struct fimd_win_data.

v3 removes a leftover var in the first commit and address the comment from
Joonyoung about checking the return value of exynos_plane_init()

Gustavo

--
Gustavo Padovan (7):
  drm/exynos: fimd: fix alpha setting for XR24 pixel format
  drm/exynos: remove unused exynos_crtc->win_enable() callback
  drm/exynos: remove struct *_win_data abstraction on planes
  drm/exynos: preset zpos value for overlay planes
  drm/exynos: make zpos property immutable
  drm/exynos: remove exynos_plane_destroy()
  drm/exynos: remove leftover functions declarations

Mandeep Singh Baines (1):
  drm/exynos: track vblank events on a per crtc basis

 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 178 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 101 ++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   7 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  27 
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  20 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 228 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  66 ++---
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |   7 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 136 +
 drivers/gpu/drm/exynos/exynos_mixer.c  | 219 ++-
 include/video/samsung_fimd.h   |   5 +
 11 files changed, 345 insertions(+), 649 deletions(-)

-- 
2.1.0

[PATCH -v2 3/8] drm/exynos: remove struct *_win_data abstraction on planes

2015-03-31 Joonyoung Shim :

> Hi,
> 
> On 03/26/2015 11:10 PM, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > struct {fimd,mixer,vidi}_win_data was just keeping the same data
> > as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> > directly.
> > 
> > It changes how planes are created and remove .win_mode_set() callback
> > that was only filling all *_win_data structs.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 164 --
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   9 +-
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   1 +
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c|  14 --
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h|   5 +-
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 182 +
> >  drivers/gpu/drm/exynos/exynos_drm_plane.c  |  23 +---
> >  drivers/gpu/drm/exynos/exynos_drm_plane.h  |   6 +-
> >  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 123 -
> >  drivers/gpu/drm/exynos/exynos_mixer.c  | 212 
> > ++---
> >  10 files changed, 242 insertions(+), 497 deletions(-)
> > 
> 
> [snip]
> 
> > @@ -818,7 +762,9 @@ static int decon_bind(struct device *dev, struct device 
> > *master, void *data)
> >  {
> > struct decon_context *ctx = dev_get_drvdata(dev);
> > struct drm_device *drm_dev = data;
> > -   int ret;
> > +   struct exynos_drm_plane *exynos_plane;
> > +   enum drm_plane_type type;
> > +   int zpos, ret;
> >  
> > ret = decon_ctx_initialize(ctx, drm_dev);
> > if (ret) {
> > @@ -826,8 +772,16 @@ static int decon_bind(struct device *dev, struct 
> > device *master, void *data)
> > return ret;
> > }
> >  
> > -   ctx->crtc = exynos_drm_crtc_create(drm_dev, ctx->pipe,
> > -  EXYNOS_DISPLAY_TYPE_LCD,
> > +   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> > +   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> > +   DRM_PLANE_TYPE_OVERLAY;
> > +   exynos_plane_init(drm_dev, >planes[zpos], 1 << ctx->pipe,
> > + type);
> 
> Doesn't error checking need about return value of exynos_plane_init?

Sure, I think it is needed too. I'll send a new patch set shortly.

Gustavo

[PATCH 1/4] drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr

2015-03-31 Thread Alex Deucher

On Tue, Mar 31, 2015 at 11:36 AM, Christian KÃ¶nig
 wrote:
> From: Christian KÃ¶nig 
>
> We somehow try to free the SG table twice.
>
> Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734
>
> Signed-off-by: Christian KÃ¶nig 
> Cc: 

For the series:
Reviewed-by: Alex Deucher 

I've added the first two to my -fixes tree.

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index d02aa1d..b292aca 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -598,6 +598,10 @@ static void radeon_ttm_tt_unpin_userptr(struct ttm_tt 
> *ttm)
> enum dma_data_direction direction = write ?
> DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
>
> +   /* double check that we don't free the table twice */
> +   if (!ttm->sg->sgl)
> +   return;
> +
> /* free the sg table and pages again */
> dma_unmap_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
>
> --
> 1.9.1
>

[PATCH v2] drm/radeon: add video usability info support for VCE

2015-03-31 Thread Alex Deucher

On Tue, Mar 31, 2015 at 11:33 AM, Christian KÃ¶nig
 wrote:
> On 31.03.2015 17:19, Leo Liu wrote:
>>
>> v2: bump version to make sure userspace backward compatibility
>>
>> Signed-off-by: Leo Liu 
>
>
> Reviewed-by: Christian KÃ¶nig 

Applied to my -next tree.  Thanks!

Alex

>
>
>> ---
>>   drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
>>   drivers/gpu/drm/radeon/radeon_vce.c | 1 +
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index d688f6c..7d620d4 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -89,9 +89,10 @@
>>*   2.40.0 - Add RADEON_GEM_GTT_WC/UC, flush HDP cache before
>> submitting
>>*CS to GPU on >= r600
>>*   2.41.0 - evergreen/cayman: Add SET_BASE/DRAW_INDIRECT command
>> parsing support
>> + *   2.42.0 - Add VCE/VUI (Video Usability Information) support
>>*/
>>   #define KMS_DRIVER_MAJOR  2
>> -#define KMS_DRIVER_MINOR   41
>> +#define KMS_DRIVER_MINOR   42
>>   #define KMS_DRIVER_PATCHLEVEL 0
>>   int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>>   int radeon_driver_unload_kms(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_vce.c
>> b/drivers/gpu/drm/radeon/radeon_vce.c
>> index 976fe43..24f849f 100644
>> --- a/drivers/gpu/drm/radeon/radeon_vce.c
>> +++ b/drivers/gpu/drm/radeon/radeon_vce.c
>> @@ -571,6 +571,7 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
>> case 0x0405: // rate control
>> case 0x0407: // motion estimation
>> case 0x0408: // rdo
>> +   case 0x0409: // vui
>> break;
>> case 0x0301: // encode
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC 01/11] drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()

On Tue, Mar 31, 2015 at 02:55:53AM -0400, Yang Kuankuan wrote:
> Hi Russell,
> 
> I'm okay with this change, and also I am preparing that collect N/CTS
> setting to an array, like this :
> 
> struct n_cts {
> unsigned int cts;
> unsigned int n;
> };
> 
> struct tmds_n_cts {
> unsigned long tmds;
> /* 1 entry each for 32KHz, 44.1KHz, and 48KHz */
> struct n_cts n_cts[3];
> };
> 
> static const struct tmds_n_cts n_cts_table[] = {
> { 25175000, {{ 28125,  4576}, { 31250,  7007}, { 25175, 6144} } },
> }

I think this is something which should be a common helper rather than
being specific to the driver.  I believe these are the standard values
for coherent audio/video clocks which can be found in the HDMI
specifications.  Such a helper should document that it is only for
use when the audio and video clocks are coherent.

(The HDMI spec gives alternative N values for use with auto-CTS value
generation for non-coherent clocks.)

I'd also prefer the lookup to use the same units as the drm_display_mode
video clock specification, which is kHz, so we can eventually kill the
needless *1000 in dw_hdmi.

One of the issues with using a common helper is that the common helper
would include the 1.001 clocks, which are allegedly unsupported by the
FSL iMX6 implementation, and, if proven that they don't work, we would
need some way to disable audio for those devices.

> But I am confused by the "hdmi->ratio", this variable was modify to
> 100 in bind funciton, then nowhere would change it again. In this
> case "hdmi->ratio" seems an unused variable, can we remove it ?

I guess the FSL sources should be checked to find out what the intended
use for that was, and we then need to decide whether to keep it (and
implement it) or remove it.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] drm/radeon: add video usability info support for VCE

2015-03-31 Thread Leo Liu

v2: bump version to make sure userspace backward compatibility

Signed-off-by: Leo Liu 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
 drivers/gpu/drm/radeon/radeon_vce.c | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index d688f6c..7d620d4 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -89,9 +89,10 @@
  *   2.40.0 - Add RADEON_GEM_GTT_WC/UC, flush HDP cache before submitting
  *CS to GPU on >= r600
  *   2.41.0 - evergreen/cayman: Add SET_BASE/DRAW_INDIRECT command parsing 
support
+ *   2.42.0 - Add VCE/VUI (Video Usability Information) support
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   41
+#define KMS_DRIVER_MINOR   42
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
b/drivers/gpu/drm/radeon/radeon_vce.c
index 976fe43..24f849f 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -571,6 +571,7 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
case 0x0405: // rate control
case 0x0407: // motion estimation
case 0x0408: // rdo
+   case 0x0409: // vui
break;

case 0x0301: // encode
-- 
2.1.0

[PATCH RFC 06/11] drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio

Hi Russell,

Am Montag, den 30.03.2015, 20:40 +0100 schrieb Russell King:
> iMX6 devices from an errata (ERR005174) where the audio FIFO can be
  ^ suffer from?

> emptied while it is partially full, resulting in misalignment of the
> audio samples.
[...]

regards
Philipp

[PATCH RFC 08/11] sound/core: add DRM ELD helper

Am Montag, den 30.03.2015, 20:40 +0100 schrieb Russell King:
> Add a helper for the EDID like data structure, which is typically passed
> from a HDMI adapter to its associated audio driver.  This informs the
> audio driver of the capabilities of the attached HDMI sink.
> 
> Signed-off-by: Russell King 
> ---
>  include/sound/pcm_drm_eld.h |  6 +++
>  sound/core/Kconfig  |  3 ++
>  sound/core/Makefile |  1 +
>  sound/core/pcm_drm_eld.c| 91 
> +
>  4 files changed, 101 insertions(+)
>  create mode 100644 include/sound/pcm_drm_eld.h
>  create mode 100644 sound/core/pcm_drm_eld.c
> 
> diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h
> new file mode 100644
> index ..93357b25d2e2
> --- /dev/null
> +++ b/include/sound/pcm_drm_eld.h
> @@ -0,0 +1,6 @@
> +#ifndef __SOUND_PCM_DRM_ELD_H
> +#define __SOUND_PCM_DRM_ELD_H
> +
> +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld);
> +
> +#endif
> diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> index 313f22e9d929..b534c8a6046b 100644
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -6,6 +6,9 @@ config SND_PCM
>   tristate
>   select SND_TIMER
>  
> +config SND_PCM_ELD
> + bool
> +
>  config SND_DMAENGINE_PCM
>   tristate
>  
> diff --git a/sound/core/Makefile b/sound/core/Makefile
> index 4daf2f58261c..591b49157b4d 100644
> --- a/sound/core/Makefile
> +++ b/sound/core/Makefile
> @@ -13,6 +13,7 @@ snd-$(CONFIG_SND_JACK)+= jack.o
>  snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o \
>   pcm_memory.o memalloc.o
>  snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
> +snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
>  
>  # for trace-points
>  CFLAGS_pcm_lib.o := -I$(src)
> diff --git a/sound/core/pcm_drm_eld.c b/sound/core/pcm_drm_eld.c
> new file mode 100644
> index ..78d551a1b05f
> --- /dev/null
> +++ b/sound/core/pcm_drm_eld.c
> @@ -0,0 +1,91 @@
> +/*
> + *  PCM DRM helpers
> + *
> + *   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.
> + */

Should this say:

+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.

?

Same for patch 9.

regards
Philipp

[PATCH RFC 09/11] sound/core: add IEC958 channel status helper

Hi,

Am Montag, den 30.03.2015, 20:40 +0100 schrieb Russell King:
> Add a helper to create the IEC958 channel status from an ALSA
> snd_pcm_runtime structure, taking account of the sample rate.
> 
> Signed-off-by: Russell King 
> ---
>  include/sound/pcm_iec958.h |  9 ++
>  sound/core/Kconfig |  3 ++
>  sound/core/Makefile|  2 ++
>  sound/core/pcm_iec958.c| 70 
> ++
>  4 files changed, 84 insertions(+)
>  create mode 100644 include/sound/pcm_iec958.h
>  create mode 100644 sound/core/pcm_iec958.c
> 
> diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
> new file mode 100644
> index ..0eed397aca8e
> --- /dev/null
> +++ b/include/sound/pcm_iec958.h
> @@ -0,0 +1,9 @@
> +#ifndef __SOUND_PCM_IEC958_H
> +#define __SOUND_PCM_IEC958_H
> +
> +#include 
> +
> +int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
> + size_t len);
> +
> +#endif
> diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> index b534c8a6046b..1507469425ec 100644
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -9,6 +9,9 @@ config SND_PCM
>  config SND_PCM_ELD
>   bool
>  
> +config SND_PCM_IEC958
> + bool
> +
>  config SND_DMAENGINE_PCM
>   tristate
>  
> diff --git a/sound/core/Makefile b/sound/core/Makefile
> index 591b49157b4d..70ea06712ec2 100644
> --- a/sound/core/Makefile
> +++ b/sound/core/Makefile
> @@ -14,10 +14,12 @@ snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o 
> pcm_misc.o \
>   pcm_memory.o memalloc.o
>  snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
>  snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
> +snd-pcm-$(CONFIG_SND_PCM_IEC958) += snd-pcm-iec958.o
>  
>  # for trace-points
>  CFLAGS_pcm_lib.o := -I$(src)
>  
> +snd-pcm-iec958-objs := pcm_iec958.o
>  snd-pcm-dmaengine-objs := pcm_dmaengine.o

This fails to build for me on 4.0-rc6:
make[2]: *** No rule to make target 'sound/core/snd-pcm-iec958.o', needed by 
'sound/core/snd-pcm.o'.  Stop.
scripts/Makefile.build:403: recipe for target 'sound/core' failed

unless I change it to either:
--- a/sound/core/Makefile
+++ b/sound/core/Makefile
@@ -14,7 +14,8 @@ snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o 
pcm_misc.o \
pcm_memory.o memalloc.o
 snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
 snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
-snd-pcm-$(CONFIG_SND_PCM_IEC958) += snd-pcm-iec958.o
+
+obj-$(CONFIG_SND_PCM_IEC958) += snd-pcm-iec958.o

 # for trace-points
 CFLAGS_pcm_lib.o := -I$(src)

or:
--- a/sound/core/Makefile
+++ b/sound/core/Makefile
@@ -14,12 +14,11 @@ snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o 
pcm_misc.o \
pcm_memory.o memalloc.o
 snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
 snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
-snd-pcm-$(CONFIG_SND_PCM_IEC958) += snd-pcm-iec958.o
+snd-pcm-$(CONFIG_SND_PCM_IEC958) += pcm_iec958.o

 # for trace-points
 CFLAGS_pcm_lib.o := -I$(src)

-snd-pcm-iec958-objs := pcm_iec958.o
 snd-pcm-dmaengine-objs := pcm_dmaengine.o

 snd-rawmidi-objs  := rawmidi.o

regards
Philipp

[PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver

2015-03-31 Thread Stefan Agner

Hi Jianwei,

The driver worked on a Vybrid VF610 device using the exported
framebuffer. However, when using X-Server through the DRM interface
directly (by using the modesetting driver) I get just a black screen so
far, still investigating the reason. What user-space interfaces did you
test?

When using the FB device and insert a USB HID device, I get some
flickers on the screen. I didn't had those on the dcufb driver, did you
notice something like this too? Probably related to the resolution, I'm
using VGA resolution.

Some comments below.


On 2015-03-26 06:37, Jianwei Wang wrote:
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale SoCs.
> 
> 2D-ACE is a Freescale display controller. 2D-ACE describes
> the functionality of the module extremely well its name is a value
> that cannot be used as a token in programming languages.
> Instead the valid token "DCU" is used to tag the register names and
> function names.
> 
> The Display Controller Unit (DCU) module is a system master that
> fetches graphics stored in internal or external memory and displays
> them on a TFT LCD panel. A wide range of panel sizes is supported
> and the timing of the interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU
> intervention.
> 
> The features:
> (1) Full RGB888 output to TFT LCD panel.
> (2) For the current LCD panel, WQVGA "480x272" is supported.
> (3) Blending of each pixel using up to 4 source layers
> dependent on size of panel.

modetest only shows one layer currently...

> (4) Each graphic layer can be placed with one pixel resolution
> in either axis.
> (5) Each graphic layer support RGB565 and RGB888 direct colors
> without alpha channel
> and BGRA direct colors with an alpha channel.

The array fsl_dcu_drm_plane_formats below shows more formats, does this
commit log needs updating?

> (6) Each graphic layer support alpha blending with 8-bit
> resolution.
> 
> This is a simplified version, only one primary plane, one
> framebuffer created for fbdev, one crtc, one connector for
> TFT LCD panel, an encoder.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> ---
> 
> Changed in V3:
> 
> - Test driver on Vybrid board and add compatible string
> - Remove unused functions
> - set default crtc for encoder
> - replace legacy functions with atomic help functions
> - Set the unique name of the DRM device
> - Implement irq handle function for vblank interrupt
> 
> Changed in v2:Â 
> - Add atomic support
> - Modify bindings file
> - Rename node for compatibility
> - Move platform related code out for compatibility
> 
>  .../devicetree/bindings/drm/fsl/fsl,dcu.txt|  50 
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/fsl/Kconfig|  17 ++
>  drivers/gpu/drm/fsl/Makefile   |   8 +
>  drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c| 193 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h|  30 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c | 165 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h |  26 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c  | 331 
> +
>  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h  | 210 +
>  drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c|  26 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c  |  42 +++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h  |  17 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c| 192 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h|  23 ++
>  16 files changed, 1333 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt
>  create mode 100644 drivers/gpu/drm/fsl/Kconfig
>  create mode 100644 drivers/gpu/drm/fsl/Makefile
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
> 
> diff --git a/Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt
> b/Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt
> new file mode 100644
> index 000..bdc7d5b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt
> @@ -0,0

[PATCH RFC 09/11] sound/core: add IEC958 channel status helper

On Tue, Mar 31, 2015 at 11:10:34AM +0200, Philipp Zabel wrote:
> This fails to build for me on 4.0-rc6:
> make[2]: *** No rule to make target 'sound/core/snd-pcm-iec958.o', needed by 
> 'sound/core/snd-pcm.o'.  Stop.
> scripts/Makefile.build:403: recipe for target 'sound/core' failed

Yes, I originally had this as a separate module, but decided it was silly,
so put it in the main snd-pcm module instead.

Naturally, it builds for me because the target object exists in my build
tree from the first way...

> --- a/sound/core/Makefile
> +++ b/sound/core/Makefile
> @@ -14,12 +14,11 @@ snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o 
> pcm_misc.o \
> pcm_memory.o memalloc.o
>  snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
>  snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
> -snd-pcm-$(CONFIG_SND_PCM_IEC958) += snd-pcm-iec958.o
> +snd-pcm-$(CONFIG_SND_PCM_IEC958) += pcm_iec958.o
>  
>  # for trace-points
>  CFLAGS_pcm_lib.o := -I$(src)
>  
> -snd-pcm-iec958-objs := pcm_iec958.o
>  snd-pcm-dmaengine-objs := pcm_dmaengine.o
>  
>  snd-rawmidi-objs  := rawmidi.o

Yep, that's obviously what I wanted - good catch, thanks!

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 9/9] drm: Fix the 'native defer' message in drm_dp_i2c_do_msg()

The debug message is missing a newline at the end and it makes the
logs hard to read when a device defers a lot. Simple 2-character fix
adds the newline at the end.

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0539758..281bb67 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -433,7 +433,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
return -EREMOTEIO;

case DP_AUX_NATIVE_REPLY_DEFER:
-   DRM_DEBUG_KMS("native defer");
+   DRM_DEBUG_KMS("native defer\n");
/*
 * We could check for I2C bit rate capabilities and if
 * available adjust this interval. We could also be
-- 
1.9.1

[PATCH 7/9] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling

For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.

The solution is to decrement the retry counter when an I2C DEFER is returned
such that another read attempt will be made. This situation should normally
only occur in compliance testing, however, as a worse case real-world
scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers)
for a single transaction to complete. The net result is a slightly slower
response to an EDID read that shouldn't significantly impact overall
performance.

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_dp_helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 79968e3..0539758 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -469,6 +469,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
aux->i2c_defer_count++;
+   /* DP Compliance Test 4.2.2.5 Requirement:
+* Must have at least 7 retries for I2C defers on the
+* transaction to pass this test
+*/
+   retry--;
usleep_range(400, 500);
continue;

-- 
1.9.1

[PATCH 4/9] drm/i915: Add check for corrupt raw EDID header for Displayport compliance testing

Displayport compliance test 4.2.2.6 requires that a source device be capable of 
detecting
a corrupt EDID. To do this, the test sets up an invalid EDID header to be read 
by the source
device. Unfortunately, the DRM EDID reading and parsing functions are actually 
too good in
this case and prevent the source from reading the corrupted EDID. The result is 
a failed
compliance test.

In order to successfully pass the test, the raw EDID header must be checked on 
each read
to see if has been "corrupted". If an invalid raw header is detected, a flag is 
set that
allows the compliance testing code to acknowledge that fact and react 
appropriately. The
flag is automatically cleared on read.

This code is designed to expressly work for compliance testing without 
disrupting normal
operations for EDID reading and parsing.

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_edid.c   | 33 +
 drivers/gpu/drm/i915/intel_dp.c  | 17 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 include/drm/drm_edid.h   |  5 +
 4 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..3d4f473 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -990,6 +990,32 @@ static const u8 edid_header[] = {
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
 };

+
+/* Flag for EDID corruption testing
+ * Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
+ */
+static bool raw_edid_header_corrupted;
+
+/**
+ * drm_raw_edid_header_valid - check to see if the raw header is
+ * corrupt or not. Used solely for Displayport compliance
+ * testing and required by Link CTS Core 1.2 rev1.1 4.2.2.6.
+ * @raw_edid: pointer to raw base EDID block
+ *
+ * Indicates whether the original EDID header as read from the
+ * device was corrupt or not. Clears on read.
+ *
+ * Return: true if the raw header was corrupt, otherwise false
+ */
+bool drm_raw_edid_header_corrupt(void)
+{
+   bool corrupted = raw_edid_header_corrupted;
+
+   raw_edid_header_corrupted = 0;
+   return corrupted;
+}
+EXPORT_SYMBOL(drm_raw_edid_header_corrupt);
+
 /**
  * drm_edid_header_is_valid - sanity check the header of the base EDID block
  * @raw_edid: pointer to raw base EDID block
@@ -1006,6 +1032,13 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
if (raw_edid[i] == edid_header[i])
score++;

+   if (score != 8) {
+   /* Log and set flag here for EDID corruption testing
+* Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
+*/
+   DRM_DEBUG_DRIVER("Raw EDID header invalid\n");
+   raw_edid_header_corrupted = 1;
+   }
return score;
 }
 EXPORT_SYMBOL(drm_edid_header_is_valid);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dc87276..57f8e43 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3824,6 +3824,9 @@ update_status:
   , 1);
if (status <= 0)
DRM_DEBUG_KMS("Could not write test response to sink\n");
+
+   /* Clear flag here, after testing is complete*/
+   intel_dp->compliance_edid_invalid = 0;
 }

 static int
@@ -3896,6 +3899,10 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
+   struct drm_connector *connector = _dp->attached_connector->base;
+   struct i2c_adapter *adapter = _dp->aux.ddc;
+   struct edid *edid_read = NULL;
+
u8 sink_irq_vector;
u8 link_status[DP_LINK_STATUS_SIZE];

@@ -3912,6 +3919,16 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}

+   /* Compliance testing requires an EDID read for all HPD events
+* Link CTS Core 1.2 rev 1.1: Test 4.2.2.1
+* Flag set here will be handled in the EDID test function
+*/
+   edid_read = drm_get_edid(connector, adapter);
+   if (!edid_read || drm_raw_edid_header_corrupt() == 1) {
+   DRM_DEBUG_DRIVER("EDID invalid, setting flag\n");
+   intel_dp->compliance_edid_invalid = 1;
+   }
+
/* Try to read the source of the interrupt */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
intel_dp_get_sink_irq(intel_dp, _irq_vector)) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e7b62be..42e4251 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -651,6 +651,7 @@ struct intel_dp {
/* Displayport compliance testing */
unsigned long compliance_test_type;
bool compliance_testing_active;
+   bool compliance_edid_invalid;
 };

 struct intel_digital_port {
diff --git a/include/drm/drm_edid.h

[PATCH RFC 09/11] sound/core: add IEC958 channel status helper

On Tue, Mar 31, 2015 at 04:30:39AM -0400, Yang Kuankuan wrote:
> >+cs[0] = IEC958_AES0_CON_NOT_COPYRIGHT | IEC958_AES0_CON_EMPHASIS_NONE;
> >+cs[1] = IEC958_AES1_CON_GENERAL;
> >+cs[2] = IEC958_AES2_CON_SOURCE_UNSPEC | IEC958_AES2_CON_CHANNEL_UNSPEC;
> >+cs[3] = IEC958_AES3_CON_CLOCK_1000PPM | fs;
> >+
> 
> Pretty good, also suitable to rockchip platform, but why not add the
> "IEC958_AES2_CON_CHANNEL_MASK" & "IEC958_AES2_CON_WORDLEN" ?
> 
> Seems sample frequency & channle number & word length are the basic
> message :)

I was debating about the word length, and that's something I'll add
later to it - but only if length shows that we have the 5th byte
available in the buffer.  Most users seem to only use the first four
bytes.

As for the channel number, this is intentionally left to the driver -
most cases I've found either the driver isn't interested, or where
they are interested (the only case I know of is my dw_hdmi ahb audio
driver), it's more appropriate to generate a baseline channel status,
and let the driver iterate over the channels adding the appropriate
channel number in.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 9/9] drm: Fix the 'native defer' message in drm_dp_i2c_do_msg()

The debug message is missing a newline at the end and it makes the
logs hard to read when a device defers a lot. Simple 2-character fix
adds the newline at the end.

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0539758..281bb67 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -433,7 +433,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
return -EREMOTEIO;

case DP_AUX_NATIVE_REPLY_DEFER:
-   DRM_DEBUG_KMS("native defer");
+   DRM_DEBUG_KMS("native defer\n");
/*
 * We could check for I2C bit rate capabilities and if
 * available adjust this interval. We could also be
-- 
1.9.1

[PATCH 7/9] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling

For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.

The solution is to decrement the retry counter when an I2C DEFER is returned
such that another read attempt will be made. This situation should normally
only occur in compliance testing, however, as a worse case real-world
scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers)
for a single transaction to complete. The net result is a slightly slower
response to an EDID read that shouldn't significantly impact overall
performance.

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_dp_helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 79968e3..0539758 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -469,6 +469,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
aux->i2c_defer_count++;
+   /* DP Compliance Test 4.2.2.5 Requirement:
+* Must have at least 7 retries for I2C defers on the
+* transaction to pass this test
+*/
+   retry--;
usleep_range(400, 500);
continue;

-- 
1.9.1

[PATCH 4/9] drm/i915: Add check for corrupt raw EDID header for Displayport compliance testing

Displayport compliance test 4.2.2.6 requires that a source device be capable of 
detecting
a corrupt EDID. To do this, the test sets up an invalid EDID header to be read 
by the source
device. Unfortunately, the DRM EDID reading and parsing functions are actually 
too good in
this case and prevent the source from reading the corrupted EDID. The result is 
a failed
compliance test.

In order to successfully pass the test, the raw EDID header must be checked on 
each read
to see if has been "corrupted". If an invalid raw header is detected, a flag is 
set that
allows the compliance testing code to acknowledge that fact and react 
appropriately. The
flag is automatically cleared on read.

This code is designed to expressly work for compliance testing without 
disrupting normal
operations for EDID reading and parsing.

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_edid.c   | 33 +
 drivers/gpu/drm/i915/intel_dp.c  | 17 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 include/drm/drm_edid.h   |  5 +
 4 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..3d4f473 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -990,6 +990,32 @@ static const u8 edid_header[] = {
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
 };

+
+/* Flag for EDID corruption testing
+ * Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
+ */
+static bool raw_edid_header_corrupted;
+
+/**
+ * drm_raw_edid_header_valid - check to see if the raw header is
+ * corrupt or not. Used solely for Displayport compliance
+ * testing and required by Link CTS Core 1.2 rev1.1 4.2.2.6.
+ * @raw_edid: pointer to raw base EDID block
+ *
+ * Indicates whether the original EDID header as read from the
+ * device was corrupt or not. Clears on read.
+ *
+ * Return: true if the raw header was corrupt, otherwise false
+ */
+bool drm_raw_edid_header_corrupt(void)
+{
+   bool corrupted = raw_edid_header_corrupted;
+
+   raw_edid_header_corrupted = 0;
+   return corrupted;
+}
+EXPORT_SYMBOL(drm_raw_edid_header_corrupt);
+
 /**
  * drm_edid_header_is_valid - sanity check the header of the base EDID block
  * @raw_edid: pointer to raw base EDID block
@@ -1006,6 +1032,13 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
if (raw_edid[i] == edid_header[i])
score++;

+   if (score != 8) {
+   /* Log and set flag here for EDID corruption testing
+* Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
+*/
+   DRM_DEBUG_DRIVER("Raw EDID header invalid\n");
+   raw_edid_header_corrupted = 1;
+   }
return score;
 }
 EXPORT_SYMBOL(drm_edid_header_is_valid);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dc87276..57f8e43 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3824,6 +3824,9 @@ update_status:
   , 1);
if (status <= 0)
DRM_DEBUG_KMS("Could not write test response to sink\n");
+
+   /* Clear flag here, after testing is complete*/
+   intel_dp->compliance_edid_invalid = 0;
 }

 static int
@@ -3896,6 +3899,10 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
+   struct drm_connector *connector = _dp->attached_connector->base;
+   struct i2c_adapter *adapter = _dp->aux.ddc;
+   struct edid *edid_read = NULL;
+
u8 sink_irq_vector;
u8 link_status[DP_LINK_STATUS_SIZE];

@@ -3912,6 +3919,16 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}

+   /* Compliance testing requires an EDID read for all HPD events
+* Link CTS Core 1.2 rev 1.1: Test 4.2.2.1
+* Flag set here will be handled in the EDID test function
+*/
+   edid_read = drm_get_edid(connector, adapter);
+   if (!edid_read || drm_raw_edid_header_corrupt() == 1) {
+   DRM_DEBUG_DRIVER("EDID invalid, setting flag\n");
+   intel_dp->compliance_edid_invalid = 1;
+   }
+
/* Try to read the source of the interrupt */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
intel_dp_get_sink_irq(intel_dp, _irq_vector)) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e7b62be..42e4251 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -651,6 +651,7 @@ struct intel_dp {
/* Displayport compliance testing */
unsigned long compliance_test_type;
bool compliance_testing_active;
+   bool compliance_edid_invalid;
 };

 struct intel_digital_port {
diff --git a/include/drm/drm_edid.h

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

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

--- Comment #51 from Vladimir Ysikov  ---
Created attachment 114754
  --> https://bugs.freedesktop.org/attachment.cgi?id=114754=edit
dmesg log

I got same issue playing in Dota 2 and Alt+Tab in firefox.
Radeon 7950, kernel 4.0rc4, mesa-git, llvm-svn, KDE 5, Archlinux x86-64.

-- 
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/20150331/05c401b0/attachment.html>

[PATCH v2] drm: line wrap DRM_IOCTL_DEF* macros

On Mon, Mar 30, 2015 at 05:10:36PM +, Emil Velikov wrote:
> Improve the readability and keeps the lines shorter than 80 columns.
> 
> Signed-off-by: Emil Velikov 

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

> ---
> 
> v2: Rebased against drm-intel topic/drm-misc, commit 
> a0211bb482c(drm/atomic: Don't try to free a NULL state)
> 
> -Emil
> 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 9 +++--
>  include/drm/drmP.h  | 9 +++--
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 1f257ae..266dcd6 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -524,8 +524,13 @@ static int drm_ioctl_permit(u32 flags, struct drm_file 
> *file_priv)
>   return 0;
>  }
>  
> -#define DRM_IOCTL_DEF(ioctl, _func, _flags) \
> - [DRM_IOCTL_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags, 
> .name = #ioctl}
> +#define DRM_IOCTL_DEF(ioctl, _func, _flags)  \
> + [DRM_IOCTL_NR(ioctl)] = {   \
> + .cmd = ioctl,   \
> + .func = _func,  \
> + .flags = _flags,\
> + .name = #ioctl  \
> + }
>  
>  /** Ioctl table */
>  static const struct drm_ioctl_desc drm_ioctls[] = {
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 0d501ed..62c40777 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -261,8 +261,13 @@ struct drm_ioctl_desc {
>   * ioctl, for use by drm_ioctl().
>   */
>  
> -#define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)  \
> - [DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE] = {.cmd = 
> DRM_IOCTL_##ioctl, .func = _func, .flags = _flags, .name = #ioctl}
> +#define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)  
> \
> + [DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE] = {\
> + .cmd = DRM_IOCTL_##ioctl,   \
> + .func = _func,  \
> + .flags = _flags,\
> + .name = #ioctl  \
> +  }
>  
>  /* Event queued up for userspace to read */
>  struct drm_pending_event {
> -- 
> 2.1.3
> 
> ___
> 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 89831] [r600] r600_asm.c:310:assign_alu_units: Assertion `0' failed.

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

--- Comment #1 from Dave Airlie  ---
Created attachment 114746
  --> https://bugs.freedesktop.org/attachment.cgi?id=114746=edit
proposed fix

-- 
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/20150331/286ae8db/attachment.html>

[Bug 89815] DRI3 and EXA: scrambled output when switching monitors

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

--- Comment #4 from Harald Judt  ---
(In reply to Michel DÃ¤nzer from comment #1)
> Please attach /var/log/Xorg.0.log and the output of dmesg, preferably from
> after the problem occurred.

There is nothing strange in dmesg.

The image looks scrambled and is frozen, yet slightly reminiscent of the
original screen.

> What does "switching monitors" mean exactly?

this:
xrandr --output DVI-1 --auto --primary --output HDMI-0 --off
xrandr -s 1360x768

or:
xrandr --output HDMI-0 --auto --primary --output DVI-1 --off


Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384
HDMI-0 connected primary 1920x1200+0+0 (normal left inverted right x axis y
axis) 550mm x 344mm
   1920x1200 59.95*+
   1920x1080 60.0059.9459.93  
   1920x1080i60.0059.94  
   1600x1200 60.00  
   1680x1050 59.88  
   1280x1024 75.0260.02  
   1440x900  59.90  
   1152x864  75.00  
   1280x720  60.0059.94  
   1024x768  75.0870.0760.00  
   1440x480i 59.94  
   832x624   74.55  
   800x600   72.1975.0060.3256.25  
   720x576   50.00  
   720x576i  50.00  
   720x480   60.0059.94  
   720x480i  60.0059.94  
   640x480   75.0072.8166.6760.0059.94  
   720x400   70.08  
   640x400   59.95  
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DVI-0 disconnected (normal left inverted right x axis y axis)
DVI-1 connected (normal left inverted right x axis y axis)
   1920x1200 60.00 +
   1360x768  60.02 +
   1280x1024 75.0260.02  
   1280x768  59.87  
   1024x768  75.0870.0760.00  
   800x600   72.1975.0060.3256.25  
   640x480   75.0072.8160.00  
   720x400   70.08  


Also, a similar issue occurs even with glamour + dri3 (and maybe exa + dri2
etc., but I haven't tested this) for:

xrandr --fb 3840x1200 --output HDMI-0 --mode 1920x1200 --scale-from 3840x1200
--output DVI-1 --off

And the scaling does not work. It recognizes the fb change (the panel pager
reflects this), but the scaling does not change. I've filed a bug for this some
time ago, though things have changed a bit since then:
https://bugs.freedesktop.org/show_bug.cgi?id=80678

-- 
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/20150331/1f04bff1/attachment.html>

[Bug 89815] DRI3 and EXA: scrambled output when switching monitors

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

--- Comment #3 from Harald Judt  ---
Created attachment 114745
  --> https://bugs.freedesktop.org/attachment.cgi?id=114745=edit
Xorg.dri3.exa.log.bz2

Xorg.log DRI3 + EXA (bzip2)

-- 
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/20150331/b75af2fa/attachment.html>

[Bug 89815] DRI3 and EXA: scrambled output when switching monitors

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

--- Comment #2 from Harald Judt  ---
Created attachment 114744
  --> https://bugs.freedesktop.org/attachment.cgi?id=114744=edit
Xorg.dri3.glamour.log.bz2

Xorg.log DRI3 + glamour (bzip2)

-- 
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/20150331/8e9c2b74/attachment-0001.html>

[PATCH RFC 02/11] drm: bridge/dw_hdmi: use drm_hdmi_avi_infoframe_from_display_mode()

 hdmi_writeb(hdmi, (frame.left_bar >> 8) & 0xff, HDMI_FC_AVIELB1);
> + hdmi_writeb(hdmi, frame.right_bar & 0xff, HDMI_FC_AVISRB0);
> + hdmi_writeb(hdmi, (frame.right_bar >> 8) & 0xff, HDMI_FC_AVISRB1);
>   }
>   
>   static void hdmi_av_composer(struct dw_hdmi *hdmi,
> @@ -1244,7 +1252,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   hdmi_enable_audio_clk(hdmi);
>   
>   /* HDMI Initialization Step F - Configure AVI InfoFrame */
> - hdmi_config_AVI(hdmi);
> + hdmi_config_AVI(hdmi, mode);
>   }
>   
>   hdmi_video_packetize(hdmi);

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150331/2a41ddbd/attachment-0001.html>

[Bug 89831] [r600] r600_asm.c:310:assign_alu_units: Assertion `0' failed.

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

Bug ID: 89831
   Summary: [r600] r600_asm.c:310:assign_alu_units: Assertion `0'
failed.
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: HACKhalotwo at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 114743
  --> https://bugs.freedesktop.org/attachment.cgi?id=114743=edit
Backtrace from wine

When I try to load a world in Space Engineers with mesa (64 bit and 32 bit),
wine, and the Radeon open source driver compiled with Gallium Nine support, and
mesa compiled with the --enable-debug flag, it crashes with the supplied
backtrace.

pastebin of the TSGI code it spits into the console:
http://pastebin.com/6eeuDs9A

full console logs:
https://drive.google.com/file/d/0Bx0XCc8l_ekmZU04djJkN1FfOWM/view?usp=sharing

Without using the Gallium Nine driver, the game works as anticipated.

-- 
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/20150331/05035014/attachment.html>

[PATCH RFC 09/11] sound/core: add IEC958 channel status helper

Hi Russell,

On 03/30/2015 03:40 PM, Russell King wrote:
> Add a helper to create the IEC958 channel status from an ALSA
> snd_pcm_runtime structure, taking account of the sample rate.
>
> Signed-off-by: Russell King 
> ---
>   include/sound/pcm_iec958.h |  9 ++
>   sound/core/Kconfig |  3 ++
>   sound/core/Makefile|  2 ++
>   sound/core/pcm_iec958.c| 70 
> ++
>   4 files changed, 84 insertions(+)
>   create mode 100644 include/sound/pcm_iec958.h
>   create mode 100644 sound/core/pcm_iec958.c
>
> diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
> new file mode 100644
> index ..0eed397aca8e
> --- /dev/null
> +++ b/include/sound/pcm_iec958.h
> @@ -0,0 +1,9 @@
> +#ifndef __SOUND_PCM_IEC958_H
> +#define __SOUND_PCM_IEC958_H
> +
> +#include 
> +
> +int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
> + size_t len);
> +
> +#endif
> diff --git a/sound/core/Kconfig b/sound/core/Kconfig
> index b534c8a6046b..1507469425ec 100644
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -9,6 +9,9 @@ config SND_PCM
>   config SND_PCM_ELD
>   bool
>   
> +config SND_PCM_IEC958
> + bool
> +
>   config SND_DMAENGINE_PCM
>   tristate
>   
> diff --git a/sound/core/Makefile b/sound/core/Makefile
> index 591b49157b4d..70ea06712ec2 100644
> --- a/sound/core/Makefile
> +++ b/sound/core/Makefile
> @@ -14,10 +14,12 @@ snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o 
> pcm_misc.o \
>   pcm_memory.o memalloc.o
>   snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o
>   snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o
> +snd-pcm-$(CONFIG_SND_PCM_IEC958) += snd-pcm-iec958.o
>   
>   # for trace-points
>   CFLAGS_pcm_lib.o := -I$(src)
>   
> +snd-pcm-iec958-objs := pcm_iec958.o
>   snd-pcm-dmaengine-objs := pcm_dmaengine.o
>   
>   snd-rawmidi-objs  := rawmidi.o
> diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
> new file mode 100644
> index ..e1ff88a17dde
> --- /dev/null
> +++ b/sound/core/pcm_iec958.c
> @@ -0,0 +1,70 @@
> +/*
> + *  PCM DRM helpers
> + *
> + *   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.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
> status
> + * @runtime: pcm runtime structure with ->rate filled in
> + * @cs: channel status buffer, at least four bytes
> + * @len: length of channel status buffer
> + *
> + * Create the consumer format channel status data in @cs of maximum size
> + * @len corresponding to the parameters of the PCM runtime @runtime.
> + *
> + * Drivers may wish to tweak the contents of the buffer after creation.
> + *
> + * Returns: length of buffer, or negative error code if something failed.
> + */
> +int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
> + size_t len)
> +{
> + unsigned int fs;
> +
> + if (len < 4)
> + return -EINVAL;
> +
> + switch (runtime->rate) {
> + case 32000:
> + fs = IEC958_AES3_CON_FS_32000;
> + break;
> + case 44100:
> + fs = IEC958_AES3_CON_FS_44100;
> + break;
> + case 48000:
> + fs = IEC958_AES3_CON_FS_48000;
> + break;
> + case 88200:
> + fs = IEC958_AES3_CON_FS_88200;
> + break;
> + case 96000:
> + fs = IEC958_AES3_CON_FS_96000;
> + break;
> + case 176400:
> + fs = IEC958_AES3_CON_FS_176400;
> + break;
> + case 192000:
> + fs = IEC958_AES3_CON_FS_192000;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + memset(cs, 0, len);
> +
> + cs[0] = IEC958_AES0_CON_NOT_COPYRIGHT | IEC958_AES0_CON_EMPHASIS_NONE;
> + cs[1] = IEC958_AES1_CON_GENERAL;
> + cs[2] = IEC958_AES2_CON_SOURCE_UNSPEC | IEC958_AES2_CON_CHANNEL_UNSPEC;
> + cs[3] = IEC958_AES3_CON_CLOCK_1000PPM | fs;
> +

Pretty good, also suitable to rockchip platform, but why not add the
"IEC958_AES2_CON_CHANNEL_MASK" & "IEC958_AES2_CON_WORDLEN" ?

Seems sample frequency & channle number & word length are the basic
message :)

Best regards.
Yakir Yang

> + return len;
> +}
> +EXPORT_SYMBOL(snd_pcm_create_iec958_consumer);

[PATCH RFC 06/11] drm: bridge/dw_hdmi: introduce interfaces to enable and disable audio

Hi Russell,

On 03/30/2015 03:40 PM, Russell King wrote:
> iMX6 devices from an errata (ERR005174) where the audio FIFO can be
> emptied while it is partially full, resulting in misalignment of the
> audio samples.
>
> To prevent this, the errata workaround recommends writing N as zero
> until the audio FIFO has been loaded by DMA.  Writing N=0 prevents the
> HDMI bridge from reading from the audio FIFO, effectively disabling
> audio.
>
> This means we need to provide the audio driver with a pair of functions
> to enable/disable audio.  These are dw_hdmi_audio_enable() and
> dw_hdmi_audio_disable().
>
> A spinlock is introduced to ensure that setting the CTS/N values can't
> race, ensuring that the audio driver calling the enable/disable
> functions (which are called in an atomic context) can't race with a
> modeset.
>
> Signed-off-by: Russell King 
> ---
>   drivers/gpu/drm/bridge/dw_hdmi.c | 34 +-
>   include/drm/bridge/dw_hdmi.h |  2 ++
>   2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 245d17e58dec..67f07d15c12b 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -18,6 +18,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #include 
>   #include 
> @@ -124,8 +125,12 @@ struct dw_hdmi {
>   struct i2c_adapter *ddc;
>   void __iomem *regs;
>   
> + spinlock_t audio_lock;
>   struct mutex audio_mutex;
>   unsigned int sample_rate;
> + unsigned int audio_cts;
> + unsigned int audio_n;
> + bool audio_enable;
>   int ratio;
>   
>   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
> @@ -347,7 +352,11 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi 
> *hdmi,
>   dev_dbg(hdmi->dev, "%s: samplerate=%ukHz ratio=%d pixelclk=%luMHz N=%d 
> cts=%d\n",
>   __func__, sample_rate, ratio, pixel_clk, n, cts);
>   
> - hdmi_set_cts_n(hdmi, cts, n);
> + spin_lock_irq(>audio_lock);
> + hdmi->audio_n = n;
> + hdmi->audio_cts = cts;
> + hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
> + spin_unlock_irq(>audio_lock);
>   }
>   
>   static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
> @@ -376,6 +385,28 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, 
> unsigned int rate)
>   }
>   EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
>   
> +void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(>audio_lock, flags);
> + hdmi->audio_enable = true;
> + hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
> + spin_unlock_irqrestore(>audio_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_audio_enable);
> +
> +void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(>audio_lock, flags);
> + hdmi->audio_enable = false;
> + hdmi_set_cts_n(hdmi, hdmi->audio_cts, 0);
> + spin_unlock_irqrestore(>audio_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
> +

It is an smart way to operate audio status that do not relate to the audio
interfaces (AHB or I2S), but I am not sure whether this will work on 
rockchip
platform, I will do some experiment to test it as soon as possible :)

Best regards.
Yakir Yang

>   /*
>* this submodule is responsible for the video data synchronization.
>* for example, for RGB 4:4:4 input, the data map is defined as
> @@ -1579,6 +1610,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
> *master,
>   hdmi->encoder = encoder;
>   
>   mutex_init(>audio_mutex);
> + spin_lock_init(>audio_lock);
>   
>   of_property_read_u32(np, "reg-io-width", );
>   
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index 424b51f6a215..ab5d36e83ea2 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -62,5 +62,7 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
>const struct dw_hdmi_plat_data *plat_data);
>   
>   void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
> +void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
> +void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
>   
>   #endif /* __IMX_HDMI_H__ */

[PATCH RFC 01/11] drm: bridge/dw_hdmi: clean up hdmi_set_clk_regenerator()

Hi Russell,

On 03/30/2015 03:40 PM, Russell King wrote:
> Clean up hdmi_set_clk_regenerator() by allowing it to take the audio
> sample rate and ratio directly, rather than hiding it inside the
> function.  Raise the unsupported pixel clock/sample rate message from
> debug to error level as this results in audio not working correctly.
>
> Signed-off-by: Russell King 
> ---
>   drivers/gpu/drm/bridge/dw_hdmi.c | 32 +++-
>   1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index cca1c3d165e2..49df6c8c4ea8 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -335,39 +335,37 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
> unsigned long pixel_clk,
>   }
>   
>   static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> -  unsigned long pixel_clk)
> + unsigned long pixel_clk, unsigned int sample_rate, unsigned int ratio)
>   {
> - unsigned int clk_n, clk_cts;
> + unsigned int n, cts;
>   
> - clk_n = hdmi_compute_n(hdmi->sample_rate, pixel_clk,
> -hdmi->ratio);
> - clk_cts = hdmi_compute_cts(hdmi->sample_rate, pixel_clk,
> -hdmi->ratio);
> -
> - if (!clk_cts) {
> - dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n",
> - __func__, pixel_clk);
> - return;
> + n = hdmi_compute_n(sample_rate, pixel_clk, ratio);
> + cts = hdmi_compute_cts(sample_rate, pixel_clk, ratio);
> + if (!cts) {
> + dev_err(hdmi->dev,
> + "%s: pixel clock/sample rate not supported: %luMHz / 
> %ukHz\n",
> + __func__, pixel_clk, sample_rate);
>   }
>   
> - dev_dbg(hdmi->dev, "%s: samplerate=%d  ratio=%d  pixelclk=%lu  N=%d 
> cts=%d\n",
> - __func__, hdmi->sample_rate, hdmi->ratio,
> - pixel_clk, clk_n, clk_cts);
> + dev_dbg(hdmi->dev, "%s: samplerate=%ukHz ratio=%d pixelclk=%luMHz N=%d 
> cts=%d\n",
> + __func__, sample_rate, ratio, pixel_clk, n, cts);
>   
> - hdmi_set_cts_n(hdmi, clk_cts, clk_n);
> + hdmi_set_cts_n(hdmi, cts, n);
>   }
>   
>   static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
>   {
>   mutex_lock(>audio_mutex);
> - hdmi_set_clk_regenerator(hdmi, 7425);
> + hdmi_set_clk_regenerator(hdmi, 7425, hdmi->sample_rate,
> +  hdmi->ratio);
>   mutex_unlock(>audio_mutex);
>   }
>   
>   static void hdmi_clk_regenerator_update_pixel_clock(struct dw_hdmi *hdmi)
>   {
>   mutex_lock(>audio_mutex);
> - hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock);
> + hdmi_set_clk_regenerator(hdmi, hdmi->hdmi_data.video_mode.mpixelclock,
> +  hdmi->sample_rate, hdmi->ratio);

I'm okay with this change, and also I am preparing that collect N/CTS
setting to an array, like this :

 struct n_cts {
 unsigned int cts;
 unsigned int n;
 };

 struct tmds_n_cts {
 unsigned long tmds;
 /* 1 entry each for 32KHz, 44.1KHz, and 48KHz */
 struct n_cts n_cts[3];
 };

 static const struct tmds_n_cts n_cts_table[] = {
 { 25175000, {{ 28125,  4576}, { 31250,  7007}, { 25175, 6144} } },
 }

But I am confused by the "hdmi->ratio", this variable was modify to 100 
in bind
funciton, then nowhere would change it again. In this case "hdmi->ratio" 
seems
an unused variable, can we remove it ?

Best regards.
Yakir Yang

>   mutex_unlock(>audio_mutex);
>   }
>

[Bug 89829] [bisected] radeonsi, commit 2cf48c creates artefacts in some applications (worst being Flash animations that are garbage)

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 CC||laura at jlekstrand.net

--- Comment #2 from Michel DÃ¤nzer  ---
Laura, any ideas?

-- 
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/20150331/47080ba7/attachment-0001.html>

[Bug 89829] [bisected] radeonsi, commit 2cf48c creates artefacts in some applications (worst being Flash animations that are garbage)

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

--- Comment #1 from Alexandre Demers  ---
Created attachment 114740
  --> https://bugs.freedesktop.org/attachment.cgi?id=114740=edit
Flash animation wrongly rendered

We should see a carrousel animation. Each time the picture changes, the flash
animation flickers and some OpenGL errors are added in debug mode.

-- 
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/20150331/e030b4c8/attachment.html>

[Bug 89829] [bisected] radeonsi, commit 2cf48c creates artefacts in some applications (worst being Flash animations that are garbage)

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

Bug ID: 89829
Summary: [bisected] radeonsi, commit 2cf48c creates artefacts
in some applications (worst being Flash animations
that are garbage)
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: alexandre.f.demers at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 114739
--> https://bugs.freedesktop.org/attachment.cgi?id=114739=edit
Error log from Chromium on a website with a wrongly rendered flash animation

I've been having rendering issues most notably with Flash (using Pepper Flash
with Chrome) for the last 2 weeks. I just had time to invetigate it. I'm using
latest drm, ddx and mesa from git with a 4.0-rc6 kernel.

Any Flash animation is an absolute mess, the "thing" being displayed instead of
what is expected coming from other parts of what is displayed or was just
displayed elsewhere on the screen.

After bisecting, it appears the culprit commit is 2cf48c

main: Add entry point for CreateBuffers.
Author Laura Ekstrand
Author date 14-12-18 20:10
Parent Revert "main: _mesa_cube_level_complete checks NumLayers."
Child main: Add entry point for NamedBufferStorage.
Branch origin/master (vc4: Drop integer multiplies with 0 to moves of 0.)

main: Add entry point for CreateBuffers.
Reviewed-by: Martin Peres

I'm also attaching an error log from Chromium when debugging a website with a
flash animation (www.environnementestrie.ca).

Here is my bisect log.

--
git bisect log
git bisect start
# bad: [1dcc1ee314a6907213e2abd5337ec0bbba3bd1bf] vc4: Drop integer multiplies
with 0 to moves of 0.
git bisect bad 1dcc1ee314a6907213e2abd5337ec0bbba3bd1bf
# good: [7a37d5c3a48c4adec5b5db589b0cb99dc9296f0c] r600g: Use
R600_MAX_VIEWPORTS instead of 16
git bisect good 7a37d5c3a48c4adec5b5db589b0cb99dc9296f0c
# bad: [a815cd8449c207956176020e752cd0051ed842ec] i965: Don't disable exec
masking for sampler message sends.
git bisect bad a815cd8449c207956176020e752cd0051ed842ec
# good: [567c8d73008a672cb71a84a4724829d34e1652b2] radeonsi: don't emit
PA_SC_LINE_STIPPLE if not rendering lines
git bisect good 567c8d73008a672cb71a84a4724829d34e1652b2
# bad: [64788b2e8dc2ddedc2712ed02b7e9096638b7bae] i965: Throttle to the
previous frame
git bisect bad 64788b2e8dc2ddedc2712ed02b7e9096638b7bae
# bad: [4f513bc330393c4615b4bad98e3e634408123960] main: Refactor
MapBuffer[Range].
git bisect bad 4f513bc330393c4615b4bad98e3e634408123960
# good: [60f77b22b1e3bbef7e4d1f10012acf830d81ed7b] common.py: Fix PEP 8 issues.
git bisect good 60f77b22b1e3bbef7e4d1f10012acf830d81ed7b
# bad: [cb56835f870de01ed9c638d1470af38775bb6f72] main: Add entry point for
NamedBufferData.
git bisect bad cb56835f870de01ed9c638d1470af38775bb6f72
# good: [44ecf0793d872e771edc448436f7a2fd7c3390f5] Revert "main:
_mesa_cube_level_complete checks NumLayers."
git bisect good 44ecf0793d872e771edc448436f7a2fd7c3390f5
# bad: [a76808dc19580855eb39c0904f3254edd765aa50] main: Add entry point for
NamedBufferStorage.
git bisect bad a76808dc19580855eb39c0904f3254edd765aa50
# bad: [2cf48c37c1e2946f7c0648e0a5927a90209f59a4] main: Add entry point for
CreateBuffers.
git bisect bad 2cf48c37c1e2946f7c0648e0a5927a90209f59a4
# first bad commit: [2cf48c37c1e2946f7c0648e0a5927a90209f59a4] main: Add entry
point for CreateBuffers.

--
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/20150331/a1e72f1e/attachment.html>

[Bug 89734] GL_AMD_pinned_memory extension causing a kernel hardlock

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

--- Comment #10 from Michel DÃ¤nzer  ---
(In reply to Christian KÃ¶nig from comment #8)
> @Michel any ideas?

I'm afraid not. :(

-- 
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/20150331/ba2615bc/attachment.html>

[Bug 89808] [Radeon 9600 r300] Xorg fails with radeonfb and KMS

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #4 from Michel DÃ¤nzer  ---
(In reply to Chris Bainbridge from comment #3)
> I retested and it isn't an actual hang. It is this issue:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762047

So it's a lightdm bug, resolving accordingly.


> - With radeonfb and KMS, dmesg shows:
> 
> [4.292750] [drm] Initialized drm 1.1.0 20060810
> [4.292866] [drm] radeon kernel modesetting enabled.
> 
> This is confusing given that KMS isn't enabled. It would be more informative
> to print a warning like "KMS disabled because you have radeonfb enabled".

This message is printed by the radeon driver, which I'm not sure has that
information.


> - Is there any point in having CONFIG_FB_RADEON on a modern kernel?

Yes, e.g. radeon KMS doesn't support suspend/resume yet on Apple PowerPC
laptops.

-- 
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/20150331/4ee83ef8/attachment.html>

[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion