[PATCH 1/2 v2] vgaarb: Don't default exclusively to first video device with mem+io

2014-08-28 Thread Bruno Prémont
On Tue, 26 August 2014 Andreas Noever  wrote:
> On Sun, Aug 24, 2014 at 11:09 PM, Bruno Pr?mont wrote:
> > With commit 20cde694027e boot video device detection was moved from
> > efifb to x86 and ia64 pci/fixup.c.
> >
> > For dual-GPU Apple computers above change represents a regression as
> > code in efifb did forcefully override vga_default_device while the
> > merge did not (vgaarb happens prior to PCI fixup).
> >
> > To improve on initial device selection by vgaarb (it cannot know if
> > PCI device not behind bridges see/decode legacy VGA I/O or not), move
> > the screen_info based check from pci_video_fixup to vgaarb's init
> > function and use it to refine/override decision taken while adding
> > the individual PCI VGA devices.
> > This way PCI fixup has no reason to adjust vga_default_device
> > anymore but can depend on its value for flagging shadowed VBIOS.
> >
> > This has the nice benefit of removing duplicated code but does
> > introduce a #if defined() block in vgaarb.
> > Not all architectures have screen_info and would cause compile to
> > fail without it.
> >
> > Reported-By: Andreas Noever 
> > CC: Matthew Garrett 
> > CC: stable at vger.kernel.org # v3.5+
> > Signed-off-by: Bruno Pr?mont 
> > ---
> > Andreas, does this work properly for you, including the improvement
> > on i915 complaint about VBIOS going from KERN_ERR to KERN_INFO?
> Yep, thanks!
> 
> >
> > Other arches using PCI and vgaarb that have screen_info may want
> > to be added to the #if defined() block or even introduce a new
> > CONFIG_HAVE_SCREEN_INFO or similar...

Bjorn, can you queue these two patches, probably going through -next
for a week and passing them to Linus for -rc4, adding Andreas's Tested-by
to Patch 1/2 v2?

Thanks,
Bruno


[Bug 81444] [drm:radeon_uvd_free_handles] *ERROR* Error destroying UVD (-22)!

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=81444

Harald Judt  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Harald Judt  ---
After pulling from drm-next-3.18-wip into 3.16 and applying the patch, I
haven't seen the issue (error -22) again. In general, UVD playback seems more
stable now. Earlier, smplayer would suddenly and for some unknown reason start
playing the video twice as fast, with the audio playing normally. This issue is
gone too, though I can't tell whether this is because of upgrading to 3.16.0 or
because of other changes.

With kdenlive I experience a lot of crashes when media-libs/mlt is built with
vdpau support, though. These crashes do not happen when not using vdpau. I'm
not sure why they happen, perhaps because of using "non-standard" video sizes
for input files. I will try to get a gdb backtrace, but I guess that will be
better posted at another place (or at least in another bug report)?

So far, it seems fixed for me, I'll reopen otherwise. Thanks for the 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/20140828/c8aeab30/attachment.html>


(UVD RS780 first impression)

2014-08-28 Thread Stefan Lange
[...]

>> Sounds like you're missing
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=80771e47b6c1e47ab55f17311e1d4e227a9eb3d8
>> .
>
> Agree, that is exactly the expected behavior if you don't use the
> necessary mesa patch.
>
> Please make sure you actually installed mesa into the correct path etc
>
> Christian.
>
>

Thanks a lot to both of you for your quick reply and the hints. I 
haven't had the chance yet to have another look due to lack of time. 
I'll give it another try during the weekend, trying to make sure that 
the patched mesa is actually used.

Stefan


[Bug 83205] New: GPU lockup when entering settings in Verdun game with HyperZ enabled

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83205

  Priority: medium
Bug ID: 83205
  Assignee: dri-devel at lists.freedesktop.org
   Summary: GPU lockup when entering settings in Verdun game with
HyperZ enabled
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: geecko.dev at free.fr
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

When playing Verdun (http://store.steampowered.com/app/242860/), every time I
go to the settings I get a GPU lockup. Without R600_DEBUG=hyperz everything is
fine.

I'm using mesa 4ca203f, llvm 216658, xorg-server 1.16, xf86-video-ati 7.4.0 on
Arch Linux. I tried on Linux 3.14, 3.16 and 3.17rc2 with the same results. My
graphics card is a HD 7950.

Here's my journalctl log: http://pastebin.com/s80VLPtr

-- 
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/20140828/ddc52804/attachment.html>


[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82050

--- Comment #30 from Mathieu Belanger  ---
Yes.

Minecraft is unplayable with latest Kernel+latest Mesa.

In the beginning, it's smooth.. after 30 sec or so it start to stuter a
little... By the five minutes mark. if you move in the game, it pause for like
5 to 7 seconde, move for 2 secondes, pause for 5 secondes...

By pause I mean the whole system pause, mouse, other terminals.. Everything.

I think it's related to this bug, it started with the kernel 3.17 (Like the OP,
I did update mesa, llvm, libdrm, glamor...)

going back to 3.16 did not fix it, I got to downgrade Mesa and LLVM too (to the
first relase of the first of this month to be sure) and after that, I played
for like 4 hours without any issue.

I tried to revert 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 but I got massive
gfx corruptions.

-- 
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/20140828/0d2bcca5/attachment.html>


[PATCH v3] drm/ast: Add reduced blanking modes for wide screen mode

2014-08-28 Thread Y.C. Chen
From: "Y.C. Chen" 

Signed-off-by: Egbert Eich 
Signed-off-by: Y.C. Chen 

v3: based on [PATCH 1/2] drm/ast: Add missing entry to dclk_table[].
Add reduced blanking modes, improve mode matching to
identify these modes by thier sync polarities.
---
 drivers/gpu/drm/ast/ast_mode.c   | 42 +++-
 drivers/gpu/drm/ast/ast_tables.h | 42 
 2 files changed, 58 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 5389350..19ada0b 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -80,6 +80,8 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc, 
struct drm_display_mo
struct ast_private *ast = crtc->dev->dev_private;
u32 refresh_rate_index = 0, mode_id, color_index, refresh_rate;
u32 hborder, vborder;
+   bool check_sync;
+   struct ast_vbios_enhtable *best = NULL;

switch (crtc->primary->fb->bits_per_pixel) {
case 8:
@@ -141,14 +143,34 @@ static bool ast_get_vbios_mode_info(struct drm_crtc 
*crtc, struct drm_display_mo
}

refresh_rate = drm_mode_vrefresh(mode);
-   while (vbios_mode->enh_table->refresh_rate < refresh_rate) {
-   vbios_mode->enh_table++;
-   if ((vbios_mode->enh_table->refresh_rate > refresh_rate) ||
-   (vbios_mode->enh_table->refresh_rate == 0xff)) {
-   vbios_mode->enh_table--;
-   break;
+   check_sync = vbios_mode->enh_table->flags & WideScreenMode;
+   do {
+   struct ast_vbios_enhtable *loop = vbios_mode->enh_table;
+
+   while (loop->refresh_rate != 0xff) {
+   if ((check_sync) &&
+   (((mode->flags & DRM_MODE_FLAG_NVSYNC)  &&
+ (loop->flags & PVSync))  ||
+((mode->flags & DRM_MODE_FLAG_PVSYNC)  &&
+ (loop->flags & NVSync))  ||
+((mode->flags & DRM_MODE_FLAG_NHSYNC)  &&
+ (loop->flags & PHSync))  ||
+((mode->flags & DRM_MODE_FLAG_PHSYNC)  &&
+ (loop->flags & NHSync {
+   loop++;
+   continue;
+   }
+   if (loop->refresh_rate <= refresh_rate
+   && (!best || loop->refresh_rate > 
best->refresh_rate))
+   best = loop;
+   loop++;
}
-   }
+   if (best || !check_sync)
+   break;
+   check_sync = 0;
+   } while (1);
+   if (best)
+   vbios_mode->enh_table = best;

hborder = (vbios_mode->enh_table->flags & HBorder) ? 8 : 0;
vborder = (vbios_mode->enh_table->flags & VBorder) ? 8 : 0;
@@ -419,8 +441,10 @@ static void ast_set_sync_reg(struct drm_device *dev, 
struct drm_display_mode *mo
struct ast_private *ast = dev->dev_private;
u8 jreg;

-   jreg = ast_io_read8(ast, AST_IO_MISC_PORT_READ);
-   jreg |= (vbios_mode->enh_table->flags & SyncNN);
+   jreg  = ast_io_read8(ast, AST_IO_MISC_PORT_READ);
+   jreg &= ~0xC0;
+   if (vbios_mode->enh_table->flags & NVSync) jreg |= 0x80;
+   if (vbios_mode->enh_table->flags & NHSync) jreg |= 0x40;
ast_io_write8(ast, AST_IO_MISC_PORT_WRITE, jreg);
 }

diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h
index 05c01ea..28ce659 100644
--- a/drivers/gpu/drm/ast/ast_tables.h
+++ b/drivers/gpu/drm/ast/ast_tables.h
@@ -35,14 +35,18 @@
 #define HalfDCLK0x0002
 #define DoubleScanMode  0x0004
 #define LineCompareOff  0x0008
-#define SyncPP  0x
-#define SyncPN  0x0040
-#define SyncNP  0x0080
-#define SyncNN  0x00C0
 #define HBorder 0x0020
 #define VBorder 0x0010
-#define WideScreenMode 0x0100
-#define NewModeInfo0x0200
+#define WideScreenMode 0x0100
+#define NewModeInfo0x0200
+#define NHSync 0x0400
+#define PHSync 0x0800
+#define NVSync 0x1000
+#define PVSync 0x2000
+#defineSyncPP  (PVSync | PHSync)
+#defineSyncPN  (PVSync | NHSync)
+#defineSyncNP  (NVSync | PHSync)
+#defineSyncNN  (NVSync | NHSync)

 /* DCLK Index */
 #define VCLK25_175 0x00
@@ -72,6 

[PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller

2014-08-28 Thread Boris BREZILLON
Hi Laurent,

On Thu, 28 Aug 2014 14:19:22 +0200
Laurent Pinchart  wrote:

> Hi Boris,

[...]

> >
> > I don't have any VGA connector (or I'm missing something :-)),
> 
> My bad.

No problem.

> 
> > but I have an LCD panel and an RGB to HDMI encoder connected on the same RGB
> > connector.
> 
> There's no such thing as an RGB connector in DRM. Your SoC has a parallel RGB 
> video output (I assume it's a DPI bus). From a DRM point of view, that bus 
> corresponds to the output of the CRTC.

Okay, this mean I'll have to dispatch some of the code I've put in
atmel_hlcdc_output.c into atmel_hlcdc_crtc.c (BTW, any chance you could
take a look at this files ?).

> 
> > > As DRM hardcodes the pipeline model to CRTC -> encoder -> connector, you
> > > will also need a DRM encoder in the VGA path. I suppose your board has a
> > > VGA DAC, that's the component you should expose as a DRM encoder (even if
> > > it can't be controlled and doesn't limit the valid modes).
> > 
> > Actually, my problem is that both devices are connected on the same RGB
> > connector, and thus share the same display mode (resolution, HSYNC,
> > VSYNC, RGB output mode, ...).
> > This means that all remote devices have to agree on a specific mode if
> > we want to mirror the display on several output devices, otherwise we
> > must disable one of the output devices.
> 
> That's not really a problem. From a DRM perspective you need to model your 
> device as
> 
> ,--.   ,---.   ,-.
> | CRTC | -+--> | Dummy Encoder | > | Panel Connector |
> `--?  |`---?   `-?
>   |,---.   ,-.
>   \--> | HDMI Encoder  | > | HDMI Connector  |
>`---?   `-?
> 
> The HDMI pipeline is pretty straightforward.
> 
> You have told me that the panel has a parallel RGB input without any encoder 
> in the panel pipeline (by the way, which panel model are you using ?). 
> However, DRM requires an encoder in every pipeline. You will thus need to 
> instantiate a dummy encoder. One option would be to set the encoder and 
> connector types to DRM_MODE_ENCODER_LVDS and DRM_MODE_CONNECTOR_LVDS 
> respectively, as that's what userspace usually expects for panels. That 
> doesn't reflect the reality in your case though, so creating a new 
> DRM_MODE_CONNECTOR_DPI type might be needed, possibly to be used with 
> DRM_MODE_ENCODER_NONE.
> 
> As neither encoder can modify the mode, the same mode will be output on the 
> two connectors.

There are still several things to I'd like to understand:
 1) who's gonna configure the RGB bus output format (RGB444, RGB666,
RGB888) which directly depends on the device connected on this bus:
the CRTC or the dummy and HDMI encoders.
 2) Where should the HDMI encoder/connector support be implemented:
in drivers/gpu/drm/atmel-hlcdc, drivers/gpu/drm/bridge or somewhere
else. My point is that I don't want to add specific support for the
Sil902x transmitter chip in the hlcdc driver.

Sorry if these are silly questions, but I'm still trying to understand
how my case should be modeled :-).

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


[PATCH] r600g, radeonsi: Inform the kernel if a BO will likely be accessed by the CPU

2014-08-28 Thread Michel Dänzer
From: Michel D?nzer 

This allows the kernel to prevent such BOs from ever being stored in the
CPU inaccessible part of VRAM.

Signed-off-by: Michel D?nzer 
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 23 ++-
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c   |  8 +++-
 src/gallium/winsys/radeon/drm/radeon_winsys.h   |  3 ++-
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index acdabc0..1a6e97d 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -126,6 +126,7 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
flags = RADEON_FLAG_GTT_WC;
break;
}
+   flags = RADEON_FLAG_CPU_ACCESS;
/* fall through */
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_IMMUTABLE:
@@ -136,23 +137,27 @@ bool r600_init_resource(struct r600_common_screen 
*rscreen,
break;
}

-   /* Use GTT for all persistent mappings with older kernels, because they
-* didn't always flush the HDP cache before CS execution.
-*
-* Write-combined CPU mappings are fine, the kernel ensures all CPU
-* writes finish before the GPU executes a command stream.
-*/
-   if (rscreen->info.drm_minor < 40 &&
-   res->b.b.target == PIPE_BUFFER &&
+   if (res->b.b.target == PIPE_BUFFER &&
res->b.b.flags & (PIPE_RESOURCE_FLAG_MAP_PERSISTENT |
  PIPE_RESOURCE_FLAG_MAP_COHERENT)) {
-   res->domains = RADEON_DOMAIN_GTT;
+   /* Use GTT for all persistent mappings with older kernels,
+* because they didn't always flush the HDP cache before CS
+* execution.
+*
+* Write-combined CPU mappings are fine, the kernel ensures all 
CPU
+* writes finish before the GPU executes a command stream.
+*/
+   if (rscreen->info.drm_minor < 40)
+   res->domains = RADEON_DOMAIN_GTT;
+   else if (res->domains & RADEON_DOMAIN_VRAM)
+   flags |= RADEON_FLAG_CPU_ACCESS;
}

/* Tiled textures are unmappable. Always put them in VRAM. */
if (res->b.b.target != PIPE_BUFFER &&
rtex->surface.level[0].mode >= RADEON_SURF_MODE_1D) {
res->domains = RADEON_DOMAIN_VRAM;
+   flags &= ~RADEON_FLAG_CPU_ACCESS;
}

/* Allocate a new resource. */
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 73f8d38..03b9b1d 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -478,7 +478,11 @@ const struct pb_vtbl radeon_bo_vtbl = {
 };

 #ifndef RADEON_GEM_GTT_WC
-#define RADEON_GEM_GTT_WC (1 << 2)
+#define RADEON_GEM_GTT_WC  (1 << 2)
+#endif
+#ifndef RADEON_GTM_CPU_ACCESS
+/* BO is expected to be accessed by the CPU */
+#define RADEON_GEM_CPU_ACCESS  (1 << 3)
 #endif

 static struct pb_buffer *radeon_bomgr_create_bo(struct pb_manager *_mgr,
@@ -505,6 +509,8 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,

 if (rdesc->flags & RADEON_FLAG_GTT_WC)
 args.flags |= RADEON_GEM_GTT_WC;
+if (rdesc->flags & RADEON_FLAG_CPU_ACCESS)
+args.flags |= RADEON_GEM_CPU_ACCESS;

 if (drmCommandWriteRead(rws->fd, DRM_RADEON_GEM_CREATE,
 , sizeof(args))) {
diff --git a/src/gallium/winsys/radeon/drm/radeon_winsys.h 
b/src/gallium/winsys/radeon/drm/radeon_winsys.h
index dbd58f1..69bf6ed 100644
--- a/src/gallium/winsys/radeon/drm/radeon_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_winsys.h
@@ -66,7 +66,8 @@ enum radeon_bo_domain { /* bitfield */
 };

 enum radeon_bo_flag { /* bitfield */
-   RADEON_FLAG_GTT_WC = (1 << 0)
+RADEON_FLAG_GTT_WC = (1 << 0),
+RADEON_FLAG_CPU_ACCESS = (1 << 1),
 };

 enum radeon_bo_usage { /* bitfield */
-- 
2.1.0



[PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag

2014-08-28 Thread Michel Dänzer
From: Michel D?nzer 

This flag is a hint that userspace expects the BO to be accessed by the
CPU. We can use that hint to prevent such BOs from ever being stored in
the CPU inaccessible part of VRAM.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_object.c | 11 +--
 include/uapi/drm/radeon_drm.h  |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index dc74cc5..908ea541 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -143,7 +143,12 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
*rbo, u32 domain)

for (i = 0; i < c; ++i) {
rbo->placements[i].fpfn = 0;
-   rbo->placements[i].lpfn = 0;
+   if ((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
+   (rbo->placements[i].flags & TTM_PL_FLAG_VRAM))
+   rbo->placements[i].lpfn =
+   rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
+   else
+   rbo->placements[i].lpfn = 0;
}

/*
@@ -151,7 +156,9 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
*rbo, u32 domain)
 * improve fragmentation quality.
 * 512kb was measured as the most optimal number.
 */
-   if (rbo->tbo.mem.size > 512 * 1024) {
+   if (!((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
+ (rbo->placements[i].flags & TTM_PL_FLAG_VRAM)) &&
+   rbo->tbo.mem.size > 512 * 1024) {
for (i = 0; i < c; i++) {
rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
}
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 509b2d7..bf0067b 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -799,6 +799,8 @@ struct drm_radeon_gem_info {
 #define RADEON_GEM_NO_BACKING_STORE(1 << 0)
 #define RADEON_GEM_GTT_UC  (1 << 1)
 #define RADEON_GEM_GTT_WC  (1 << 2)
+/* BO is expected to be accessed by the CPU */
+#define RADEON_GEM_CPU_ACCESS  (1 << 3)

 struct drm_radeon_gem_create {
uint64_tsize;
-- 
2.1.0



[PATCH v2] drm: fix division-by-zero on dumb_create()

2014-08-28 Thread David Herrmann
Kinda unexpected, but DIV_ROUND_UP() can overflow if passed an argument
bigger than UINT_MAX - DIVISOR. Fix this by testing for "!cpp" before
using it in the following division.

Note that DIV_ROUND_UP() is defined as:
#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))

..this will obviously overflow if (n + d - 1) is bigger than UINT_MAX.

Reported-by: Tommi Rantala 
Signed-off-by: David Herrmann 
Reviewed-by: Rob Clark 
---
v2: add comment that DIV_ROUND_UP() might overflow
add Rob's r-b

 drivers/gpu/drm/drm_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f09b752..61b6978 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4720,8 +4720,8 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
return -EINVAL;

/* overflow checks for 32bit size calculations */
-   cpp = DIV_ROUND_UP(args->bpp, 8);
-   if (cpp > 0xU / args->width)
+   cpp = DIV_ROUND_UP(args->bpp, 8); /* might overflow! */
+   if (!cpp || cpp > 0xU / args->width)
return -EINVAL;
stride = cpp * args->width;
if (args->height > 0xU / stride)
-- 
2.1.0



[PATCH] gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig

2014-08-28 Thread Fabio Estevam
On Fri, Jun 20, 2014 at 12:06 AM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry.
>
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/gpu/ipu-v3/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
> index 2f228a2..8696d20 100644
> --- a/drivers/gpu/ipu-v3/Kconfig
> +++ b/drivers/gpu/ipu-v3/Kconfig
> @@ -1,6 +1,6 @@
>  config IMX_IPUV3_CORE
> tristate "IPUv3 core support"
> -   depends on SOC_IMX5 || SOC_IMX6Q || SOC_IMX6SL || ARCH_MULTIPLATFORM
> +   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
> depends on RESET_CONTROLLER
> help
>   Choose this if you have a i.MX5/6 system and want to use the Image

Not sure who would take this one?

$ ./scripts/get_maintainer.pl -f drivers/gpu/ipu-v3/Kconfig
Greg Kroah-Hartman  (commit_signer:1/1=100%)
Lucas Stach  (commit_signer:1/1=100%)
Philipp Zabel 
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:7/7=100%)
linux-kernel at vger.kernel.org (open list)%)

It seems we need an entry for drivers/gpu/ipu-v3 in MAINTAINERS?


[PATCH 3/7] drm/exynos: Renaming DP training vswing pre emph defines

2014-08-28 Thread Jingoo Han
On Thursday, August 28, 2014 1:33 PM, Sonika Sonika wrote:
> On 8/28/2014 6:25 AM, Jingoo Han wrote:
> > On Friday, August 08, 2014 7:54 PM, Sonika Jindal wrote:
> >>
> >> From: Sonika Jindal 
> >>
> >> Rename the defines to have levels instead of values for vswing and
> >> pre-emph levels as the values may differ in other scenarios like low 
> >> vswing of
> >> eDP1.4 where the values are different.
> >>
> >> Done using following cocci patch for each define:
> >> @@
> >> @@
> >>
> >>   # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
> >> + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> >>
> >> ...
> >>
> >> Signed-off-by: Sonika Jindal 
> >> ---
> >>   drivers/gpu/drm/exynos/exynos_dp_core.c |4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> >> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> >> index 4f3c7eb..02602a8 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> >> @@ -329,8 +329,8 @@ static int exynos_dp_link_start(struct 
> >> exynos_dp_device *dp)
> >>return retval;
> >>
> >>for (lane = 0; lane < lane_count; lane++)
> >> -  buf[lane] = DP_TRAIN_PRE_EMPHASIS_0 |
> >> -  DP_TRAIN_VOLTAGE_SWING_400;
> >> +  buf[lane] = DP_TRAIN_PRE_EMPH_LEVEL_0 |
> >> +  DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
> >
> > NAK!
> >
> > It makes build error. Please build your patch, before sending the patch.
> > It is a rule when submitting patches.
> >
> > Please, fix it as follows.
> >
> > +   buf[lane] = DP_TRAIN_PRE_EMPHASIS_LEVEL_0|
> > +   DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
> >
> I think the first patch which you have taken (which adds new defines) is
> the one from the previous series for the same change. In the second
> version, I have named them as DP_TRAIN_PRE_EMPH_LEVEL_* which was done
> using cocci. Following is from that patch:

Oh, I see. Sorry for annoying you.
However, how about tagging V2, V3.. into patches? For instance,
'[PATCH V2 3/7] drm/exynos: Renaming DP training vswing pre emph defines'
It will be helpful, in order to prevent the same mistakes happening again.

Also, the patch looks good.
Acked-by: Jingoo Han 

Best regards,
Jingoo Han

>   # define DP_TRAIN_PRE_EMPHASIS_0(0 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_0   (0 << 3)
>   # define DP_TRAIN_PRE_EMPHASIS_3_5  (1 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_1   (1 << 3)
>   # define DP_TRAIN_PRE_EMPHASIS_6(2 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_2   (2 << 3)
>   # define DP_TRAIN_PRE_EMPHASIS_9_5  (3 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_3   (3 << 3)
> > Best regards,
> > Jingoo Han
> >
> >>
> >>retval = exynos_dp_write_bytes_to_dpcd(dp, DP_TRAINING_LANE0_SET,
> >>lane_count, buf);
> >> --
> >> 1.7.10.4
> >



[PATCH 9/9] drm/i915: split intel_pipe_set_base() into check() and commit()

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

Take out some parts of  code that can fail from it and move them to
intel_pipe_check_base(), the only failure point in intel_pipe_set_base()
now is the fb pinning procudure.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 39 
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eb6febf..ead2f24 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2661,17 +2661,11 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc 
*crtc)
 }

 static int
-intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
+intel_pipe_check_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
 {
struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
-   struct drm_framebuffer *old_fb = crtc->primary->fb;
-   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
-   struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
-   int ret;

if (intel_crtc_has_pending_flip(crtc)) {
DRM_ERROR("pipe is still busy with an old pageflip\n");
@@ -2691,6 +2685,22 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return -EINVAL;
}

+   return 0;
+}
+
+static int
+intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
+   struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
+   struct drm_framebuffer *old_fb = crtc->primary->fb;
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
+   int ret;
+
mutex_lock(>struct_mutex);
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret == 0)
@@ -9868,6 +9878,10 @@ free_work:
if (ret == -EIO) {
 out_hang:
intel_crtc_wait_for_pending_flips(crtc);
+   ret = intel_pipe_check_base(crtc, crtc->x, crtc->y, fb);
+   if (ret)
+   return ret;
+
ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
if (ret == 0 && event)
drm_send_vblank_event(dev, pipe, event);
@@ -11396,6 +11410,10 @@ static int intel_crtc_set_config(struct drm_mode_set 
*set)

intel_crtc_wait_for_pending_flips(set->crtc);

+   ret = intel_pipe_check_base(set->crtc, set->x, set->y, set->fb);
+   if (ret)
+   goto fail;
+
ret = intel_pipe_set_base(set->crtc,
  set->x, set->y, set->fb);

@@ -11620,12 +11638,17 @@ intel_check_primary_plane(struct drm_plane *plane, 
struct drm_crtc *crtc,
.x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
.y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
};
+   int ret;

-   return drm_plane_helper_check_update(plane, crtc, fb,
+   ret = drm_plane_helper_check_update(plane, crtc, fb,
, , ,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true, visible);
+   if (ret)
+   return ret;
+
+   return intel_pipe_check_base(crtc, src.x1, src.y1, fb);
 }

 static int
-- 
1.9.3



[PATCH 8/9] drm/i915: return error if fb is NULL

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

intel_pipe_check_base() should return an error is the fb received is
set to NULL.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 42bd6c6..eb6febf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2681,7 +2681,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
/* no fb bound */
if (!fb) {
DRM_ERROR("No FB bound\n");
-   return 0;
+   return -EINVAL;
}

if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
-- 
1.9.3



[PATCH 7/9] drm/i915: split intel_primary_plane_setplane() into check() and commit()

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.

More work is expected on this to get a better split of the two steps.
Ideally the commit() step should never fail.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 63 
 1 file changed, 49 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 86c8fa3..42bd6c6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11594,16 +11594,13 @@ disable_unpin:
 }

 static int
-intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
+intel_check_primary_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y, uint32_t src_w,
+ uint32_t src_h, bool *visible)
 {
-   struct drm_device *dev = crtc->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
-   struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
struct drm_rect dest = {
/* integer pixels */
.x1 = crtc_x,
@@ -11623,17 +11620,33 @@ intel_primary_plane_setplane(struct drm_plane *plane, 
struct drm_crtc *crtc,
.x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
.y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
};
-   bool visible;
-   int ret;

-   ret = drm_plane_helper_check_update(plane, crtc, fb,
+   return drm_plane_helper_check_update(plane, crtc, fb,
, , ,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
-   false, true, );
+   false, true, visible);
+}

-   if (ret)
-   return ret;
+static int
+intel_commit_primary_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+  unsigned int crtc_w, unsigned int crtc_h,
+  uint32_t src_x, uint32_t src_y, uint32_t src_w,
+  uint32_t src_h, bool visible)
+{
+   struct drm_device *dev = crtc->dev;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
+   struct drm_rect src = {
+   /* 16.16 fixed point */
+   .x1 = src_x,
+   .y1 = src_y,
+   .x2 = src_x + src_w,
+   .y2 = src_y + src_h,
+   };
+   int ret;

/*
 * If the CRTC isn't enabled, we're just pinning the framebuffer,
@@ -11710,6 +11723,28 @@ intel_primary_plane_setplane(struct drm_plane *plane, 
struct drm_crtc *crtc,
return 0;
 }

+static int
+intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned int crtc_h,
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h)
+{
+   bool visible;
+   int ret;
+
+   ret = intel_check_primary_plane(plane, crtc, fb, crtc_x, crtc_y,
+   crtc_w, crtc_h, src_x, src_y,
+   src_w, src_h, );
+   if (ret)
+   return ret;
+
+   intel_commit_primary_plane(plane, crtc, fb, crtc_x, crtc_y, crtc_w,
+  crtc_h, src_x, src_y, src_w, src_h, visible);
+
+   return 0;
+}
+
 /* Common destruction function for both primary and cursor planes */
 static void intel_plane_destroy(struct drm_plane *plane)
 {
-- 
1.9.3



[PATCH 6/9] drm/i915: split intel_crtc_cursor_set_obj() into check() and commit()

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

Create intel_crtc_cursor_create_obj() to check any need setting
before we call intel_crtc_cursor_set_obj() to apply the cursor updates.
intel_crtc_cursor_check_obj() must always be called before
intel_crtc_cursor_set_obj().

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 115 ---
 1 file changed, 80 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0173c53..86c8fa3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8232,30 +8232,25 @@ static bool cursor_size_ok(struct drm_device *dev,
 }

 /*
- * intel_crtc_cursor_set_obj - Set cursor to specified GEM object
+ * intel_crtc_cursor_check_obj - Check settings for a specified GEM object
  *
- * Note that the object's reference will be consumed if the update fails.  If
- * the update succeeds, the reference of the old object (if any) will be
- * consumed.
+ * Note that the object's reference will be consumed if the check fails.  If
+ * the check succeeds, the reference of the old object (if any) will be
+ * consumed in intel_crtc_cursor_set_obj(). It must be called before
+ * intel_crtc_cursor_set_obj()
  */
-static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
+static int intel_crtc_cursor_check_obj(struct drm_crtc *crtc,
 struct drm_i915_gem_object *obj,
 uint32_t width, uint32_t height)
+
 {
struct drm_device *dev = crtc->dev;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
-   unsigned old_width, stride;
-   uint32_t addr;
+   unsigned stride;
int ret;

/* if we want to turn off the cursor ignore width and height */
-   if (!obj) {
-   DRM_DEBUG_KMS("cursor off\n");
-   addr = 0;
-   mutex_lock(>struct_mutex);
-   goto finish;
-   }
+   if (!obj)
+   return 0;

/* Check for which cursor types we support */
if (!cursor_size_ok(dev, width, height)) {
@@ -8302,7 +8297,6 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
*crtc,
goto fail_unpin;
}

-   addr = i915_gem_obj_ggtt_offset(obj);
} else {
int align = IS_I830(dev) ? 16 * 1024 : 256;
ret = i915_gem_object_attach_phys(obj, align);
@@ -8310,8 +8304,50 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
*crtc,
DRM_DEBUG_KMS("failed to attach phys object\n");
goto fail_locked;
}
-   addr = obj->phys_handle->busaddr;
}
+   mutex_unlock(>struct_mutex);
+
+   return 0;
+
+fail_unpin:
+   i915_gem_object_unpin_from_display_plane(obj);
+fail_locked:
+   mutex_unlock(>struct_mutex);
+fail:
+   drm_gem_object_unreference_unlocked(>base);
+   return ret;
+}
+
+/*
+ * intel_crtc_cursor_set_obj - Set cursor to specified GEM object
+ *
+ * intel_crtc_cursor_check_obj() must be called before this function
+ * so check for failures can be done before apply the update.
+ */
+static void intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
+struct drm_i915_gem_object *obj,
+uint32_t width, uint32_t height)
+{
+   struct drm_device *dev = crtc->dev;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
+   unsigned old_width;
+   uint32_t addr;
+
+   /* if we want to turn off the cursor ignore width and height */
+   if (!obj) {
+   DRM_DEBUG_KMS("cursor off\n");
+   addr = 0;
+   mutex_lock(>struct_mutex);
+   goto finish;
+   }
+
+   /* we only need to pin inside GTT if cursor is non-phy */
+   mutex_lock(>struct_mutex);
+   if (!INTEL_INFO(dev)->cursor_needs_physical)
+   addr = i915_gem_obj_ggtt_offset(obj);
+   else
+   addr = obj->phys_handle->busaddr;

  finish:
if (intel_crtc->cursor_bo) {
@@ -8337,15 +8373,6 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
*crtc,
}

intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
-
-   return 0;
-fail_unpin:
-   i915_gem_object_unpin_from_display_plane(obj);
-fail_locked:
-   mutex_unlock(>struct_mutex);
-fail:
-   drm_gem_object_unreference_unlocked(>base);
-   return ret;
 }

 static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
@@ -11733,12 +11760,20 @@ static struct drm_plane 
*intel_primary_plane_create(struct drm_device *dev,
 static int
 intel_cursor_plane_disable(struct drm_plane *plane)
 {
+   int ret;
+
if (!plane->fb)
return 0;

   

[PATCH 5/9] drm/i915: split intel_cursor_plane_update() into check() and commit()

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.

The commit part can still fail, but that should be solved in another
upcoming patch.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 54 ++--
 1 file changed, 40 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a8a8abe..0173c53 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11742,15 +11742,13 @@ intel_cursor_plane_disable(struct drm_plane *plane)
 }

 static int
-intel_cursor_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
+intel_check_cursor_plane(struct drm_plane *plane, struct drm_crtc *crtc,
  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
  unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+ uint32_t src_x, uint32_t src_y, uint32_t src_w,
+ uint32_t src_h, bool *visible)
 {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
-   struct drm_i915_gem_object *obj = intel_fb->obj;
struct drm_rect dest = {
/* integer pixels */
.x1 = crtc_x,
@@ -11770,16 +11768,23 @@ intel_cursor_plane_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
.x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
.y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
};
-   bool visible;
-   int ret;

-   ret = drm_plane_helper_check_update(plane, crtc, fb,
-   , , ,
-   DRM_PLANE_HELPER_NO_SCALING,
-   DRM_PLANE_HELPER_NO_SCALING,
-   true, true, );
-   if (ret)
-   return ret;
+   return drm_plane_helper_check_update(plane, crtc, fb,
+, , ,
+DRM_PLANE_HELPER_NO_SCALING,
+DRM_PLANE_HELPER_NO_SCALING,
+true, true, visible);
+}
+
+static int
+intel_commit_cursor_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ bool visible)
+{
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+   struct drm_i915_gem_object *obj = intel_fb->obj;

crtc->cursor_x = crtc_x;
crtc->cursor_y = crtc_y;
@@ -11794,6 +11799,27 @@ intel_cursor_plane_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
return 0;
}
 }
+
+static int
+intel_cursor_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+   bool visible;
+   int ret;
+
+   ret = intel_check_cursor_plane(plane, crtc, fb, crtc_x, crtc_y, crtc_w,
+  crtc_h, src_x, src_y, src_w, src_h,
+  );
+   if (ret)
+   return ret;
+
+   return intel_commit_cursor_plane(plane, crtc, fb, crtc_x, crtc_y,
+crtc_w, crtc_h, visible);
+}
+
 static const struct drm_plane_funcs intel_cursor_plane_funcs = {
.update_plane = intel_cursor_plane_update,
.disable_plane = intel_cursor_plane_disable,
-- 
1.9.3



[PATCH 4/9] drm/i915: split intel_update_plane into check() and commit()

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.

This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning procedure.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_sprite.c | 128 ++--
 1 file changed, 93 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 4cbe286..b1cb606 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -844,22 +844,32 @@ static bool colorkey_enabled(struct intel_plane 
*intel_plane)
return key.flags != I915_SET_COLORKEY_NONE;
 }

+static bool get_visible(struct drm_rect *src, struct drm_rect *dst,
+   const struct drm_rect *clip,
+   int min_scale, int max_scale)
+{
+   int hscale, vscale;
+
+   hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(hscale < 0);
+
+   vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
+   BUG_ON(vscale < 0);
+
+   return drm_rect_clip_scaled(src, dst, clip, hscale, vscale);
+}
+
 static int
-intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+intel_check_sprite_plane(struct drm_plane *plane, struct drm_crtc *crtc,
   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
   unsigned int crtc_w, unsigned int crtc_h,
   uint32_t src_x, uint32_t src_y,
   uint32_t src_w, uint32_t src_h)
 {
-   struct drm_device *dev = plane->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_plane *intel_plane = to_intel_plane(plane);
-   enum pipe pipe = intel_crtc->pipe;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
-   struct drm_i915_gem_object *old_obj = intel_plane->obj;
-   int ret;
-   bool primary_enabled;
bool visible;
int hscale, vscale;
int max_scale, min_scale;
@@ -882,20 +892,6 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
.x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
.y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
};
-   const struct {
-   int crtc_x, crtc_y;
-   unsigned int crtc_w, crtc_h;
-   uint32_t src_x, src_y, src_w, src_h;
-   } orig = {
-   .crtc_x = crtc_x,
-   .crtc_y = crtc_y,
-   .crtc_w = crtc_w,
-   .crtc_h = crtc_h,
-   .src_x = src_x,
-   .src_y = src_y,
-   .src_w = src_w,
-   .src_h = src_h,
-   };

/* Don't modify another pipe's plane */
if (intel_plane->pipe != intel_crtc->pipe) {
@@ -930,13 +926,7 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
drm_rect_rotate(, fb->width << 16, fb->height << 16,
intel_plane->rotation);

-   hscale = drm_rect_calc_hscale_relaxed(, , min_scale, max_scale);
-   BUG_ON(hscale < 0);
-
-   vscale = drm_rect_calc_vscale_relaxed(, , min_scale, max_scale);
-   BUG_ON(vscale < 0);
-
-   visible = drm_rect_clip_scaled(, , , hscale, vscale);
+   visible = get_visible(, , , max_scale, min_scale);

crtc_x = dst.x1;
crtc_y = dst.y1;
@@ -1027,6 +1017,54 @@ intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
}
}

+   return 0;
+}
+
+static int
+intel_commit_sprite_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+  unsigned int crtc_w, unsigned int crtc_h,
+  uint32_t src_x, uint32_t src_y,
+  uint32_t src_w, uint32_t src_h)
+{
+   struct drm_device *dev = plane->dev;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   enum pipe pipe = intel_crtc->pipe;
+   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+   struct drm_i915_gem_object *obj = intel_fb->obj;
+   struct drm_i915_gem_object *old_obj = intel_plane->obj;
+   int ret;
+   bool primary_enabled;
+   bool visible;
+   int max_scale, min_scale;
+   struct drm_rect src = {
+   /* sample coordinates in 16.16 fixed point */
+   .x1 = src_x,
+   .x2 = src_x + src_w,
+   .y1 = src_y,
+   .y2 = src_y + src_h,
+   };
+   struct drm_rect dst = {
+   /* integer pixels */
+   .x1 = crtc_x,
+   .x2 

[PATCH 3/9] drm/i915: fix memleak in intel_set_config_save_state()

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

If the save_encoder_crtcs or save_connector_encoders allocation fail
we need to free everything we have already allocated.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 05937fe..a8a8abe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11018,13 +11018,13 @@ static int intel_set_config_save_state(struct 
drm_device *dev,
kcalloc(dev->mode_config.num_encoder,
sizeof(struct drm_crtc *), GFP_KERNEL);
if (!config->save_encoder_crtcs)
-   return -ENOMEM;
+   goto free_crtc;

config->save_connector_encoders =
kcalloc(dev->mode_config.num_connector,
sizeof(struct drm_encoder *), GFP_KERNEL);
if (!config->save_connector_encoders)
-   return -ENOMEM;
+   goto free_encoder;

/* Copy data. Note that driver private data is not affected.
 * Should anything bad happen only the expected state is
@@ -11046,6 +11046,12 @@ static int intel_set_config_save_state(struct 
drm_device *dev,
}

return 0;
+
+free_encoder:
+   kfree(config->save_encoder_crtcs);
+free_crtc:
+   kfree(config->save_crtc_enabled);
+   return -ENOMEM;
 }

 static void intel_set_config_restore_state(struct drm_device *dev,
-- 
1.9.3



[PATCH 2/9] drm/i915: trivial: remove unneed set to NULL

2014-08-28 Thread Gustavo Padovan
From: Gustavo Padovan 

At this point of the code the obj var is already NULL, so we don't
need to set it again to NULL.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/i915/intel_display.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b2e4eac..05937fe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8253,7 +8253,6 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
*crtc,
if (!obj) {
DRM_DEBUG_KMS("cursor off\n");
addr = 0;
-   obj = NULL;
mutex_lock(>struct_mutex);
goto finish;
}
-- 
1.9.3



[PATCH 1/9] drm/i915: init sprites with univeral plane init function

2014-08-28 Thread Gustavo Padovan
From: Derek Foreman 

Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.

Signed-off-by: Derek Foreman 
---
 drivers/gpu/drm/i915/intel_sprite.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0bdb00b..4cbe286 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe 
pipe, int plane)
intel_plane->plane = plane;
intel_plane->rotation = BIT(DRM_ROTATE_0);
possible_crtcs = (1 << pipe);
-   ret = drm_plane_init(dev, _plane->base, possible_crtcs,
-_plane_funcs,
-plane_formats, num_plane_formats,
-false);
+   ret = drm_universal_plane_init(dev, _plane->base, possible_crtcs,
+  _plane_funcs,
+  plane_formats, num_plane_formats,
+  DRM_PLANE_TYPE_OVERLAY);
if (ret) {
kfree(intel_plane);
goto out;
-- 
1.9.3



[PULL] drm-intel-fixes

2014-08-28 Thread Jani Nikula

Hi Dave -

Some more fixes for 3.17, mostly stable material.

BR,
Jani.

The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:

  Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-28

for you to fetch changes up to bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a:

  drm/i915: Remove bogus __init annotation from DMI callbacks (2014-08-28 
09:54:27 +0300)


Mathias Krause (1):
  drm/i915: Remove bogus __init annotation from DMI callbacks

Paulo Zanoni (1):
  drm/i915: fix plane/cursor handling when runtime suspended

Scot Doyle (2):
  drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U)
  drm/i915: don't warn if backlight unexpectedly enabled

Ville Syrj?l? (1):
  drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to 
haswell_crtc_disable()

 drivers/gpu/drm/i915/intel_bios.c|  2 +-
 drivers/gpu/drm/i915/intel_crt.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 34 ++
 drivers/gpu/drm/i915/intel_lvds.c|  2 +-
 drivers/gpu/drm/i915/intel_panel.c   |  8 
 5 files changed, 37 insertions(+), 11 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm/gem: Fix kerneldoc typo

2014-08-28 Thread Laurent Pinchart
The drm_gem_private_object_init function is called drm_gem_object_init
in its kerneldoc. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6adee4c..8bb8c08 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -146,7 +146,7 @@ int drm_gem_object_init(struct drm_device *dev,
 EXPORT_SYMBOL(drm_gem_object_init);

 /**
- * drm_gem_object_init - initialize an allocated private GEM object
+ * drm_gem_private_object_init - initialize an allocated private GEM object
  * @dev: drm_device the object should be initialized for
  * @obj: drm_gem_object to initialize
  * @size: object size
-- 
Regards,

Laurent Pinchart



[PATCH] drm/cma: remove to allocate shmfs backing store

2014-08-28 Thread Laurent Pinchart
Hi Joonyoung,

Thank you for the patch.

On Wednesday 27 August 2014 15:26:32 Joonyoung Shim wrote:
> Initialize GEM object using drm_gem_private_object_init instead of
> drm_gem_object_init. It doesn't need to have shmfs backing store because
> the CMA GEM object uses CMA area.
> 
> Signed-off-by: Joonyoung Shim 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c index e467e67..a65cbd0 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -52,7 +52,7 @@ __drm_gem_cma_create(struct drm_device *drm, unsigned int
> size)
> 
>   gem_obj = _obj->base;
> 
> - ret = drm_gem_object_init(drm, gem_obj, size);
> + ret = drm_gem_private_object_init(drm, gem_obj, size);
>   if (ret)
>   goto error;

-- 
Regards,

Laurent Pinchart



[PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller

2014-08-28 Thread Laurent Pinchart
Hi Boris,

On Wednesday 27 August 2014 09:52:35 Boris BREZILLON wrote:
> On Tue, 26 Aug 2014 01:39:21 +0200 Laurent Pinchart wrote:
> > On Thursday 21 August 2014 19:26:33 Boris BREZILLON wrote:
> >> On Thu, 21 Aug 2014 19:08:53 +0200
> >> Laurent Pinchart  wrote:
> >> 
> >> [...]
> >> 
> >> While this could be acceptable when all drivers are statically
> >> linked in the kernel, it might be problematic when you're using
> >> modules, meaning that you won't be able to display anything on your
> >> LCD panel until your HDMI bridge module has been loaded.
> > 
> > No. HDMI should be using proper hotplugging anyway, hence it should
> > be always be loaded anyway. You're in for a world of pain if you
> > think you can run DRM with a driver that's composed of separate
> > kernel modules.
>  
>  I was talking about the external RGB to HDMI encoder, should the
>  driver for this encoder (which is not on On Chip block) be compiled
>  statically too ?
> >>> 
> >>> Given the move to multiplatform kernels we need to aim for as few
> >>> modules compiled in as possible. I'd say this includes HDMI encoders,
> >>> panels and display controllers.
> >>> 
> > Also if you don't want to use deferred probe, then you're in for the
> > full hotplugging panel dance and that implies that you need to fix a
> > bunch of things in DRM (one being the framebuffer console
> > instantiation that I referred to in the other thread).
>  
>  For now, I wait until there is a device connected on the RGB
>  connector (connector status set to connector_status_connected) before
>  creating an fbdev. It might not be the cleanest way to solve this
>  issue, but it works :-).
> >>> 
> >>> Do you create a new drm_encoder at runtime for the HDMI encoder when
> >>> it appears ? I thought the DRM core and API were not able to correctly
> >>> cope with that.
> >> 
> >> I haven't started to work on the HDMI encoder yet, and ATM I only have
> >> a single connector (which is true from an HW POV), which is then bound
> >> to an LCD panel (the only type of remote endpoint I currently support).
> >> 
> >> BTW, I wonder how my use case should be represented in the DRM
> >> subsystem. As I said, from an HW POV I only have one RGB (or whatever
> >> name you choose for it) connector. But on such kind of connectors you
> >> can connect several output devices (panels, encoders, ...).
> >> And in my case I have 2 devices on the same RGB connector: a panel and
> >> an RGB to HDMI converter.
> > 
> > The DRM connector object was initially meant to model a physical user-
> > accessible connector on a board (VGA, DVI, HDMI, ...) and the properties
> > of the monitor plugged into it. It has then been (ab)used to represent
> > panels, as they're similar to monitors.
> > 
> > In your case the VGA and HDMI connectors should be modeled as DRM
> > connectors, the RGB to HDMI encoder as a DRM encoder, and the LCDC as a
> > DRM CRTC.
>
> I don't have any VGA connector (or I'm missing something :-)),

My bad.

> but I have an LCD panel and an RGB to HDMI encoder connected on the same RGB
> connector.

There's no such thing as an RGB connector in DRM. Your SoC has a parallel RGB 
video output (I assume it's a DPI bus). From a DRM point of view, that bus 
corresponds to the output of the CRTC.

> > As DRM hardcodes the pipeline model to CRTC -> encoder -> connector, you
> > will also need a DRM encoder in the VGA path. I suppose your board has a
> > VGA DAC, that's the component you should expose as a DRM encoder (even if
> > it can't be controlled and doesn't limit the valid modes).
> 
> Actually, my problem is that both devices are connected on the same RGB
> connector, and thus share the same display mode (resolution, HSYNC,
> VSYNC, RGB output mode, ...).
> This means that all remote devices have to agree on a specific mode if
> we want to mirror the display on several output devices, otherwise we
> must disable one of the output devices.

That's not really a problem. From a DRM perspective you need to model your 
device as

,--.   ,---.   ,-.
| CRTC | -+--> | Dummy Encoder | > | Panel Connector |
`--?  |`---?   `-?
  |,---.   ,-.
  \--> | HDMI Encoder  | > | HDMI Connector  |
   `---?   `-?

The HDMI pipeline is pretty straightforward.

You have told me that the panel has a parallel RGB input without any encoder 
in the panel pipeline (by the way, which panel model are you using ?). 
However, DRM requires an encoder in every pipeline. You will thus need to 
instantiate a dummy encoder. One option would be to set the encoder and 
connector types to DRM_MODE_ENCODER_LVDS and DRM_MODE_CONNECTOR_LVDS 
respectively, as that's what userspace usually expects for panels. That 
doesn't reflect the reality in your 

[GIT PULL]: few dma-buf updates for 3.17-rc3

2014-08-28 Thread Sumit Semwal
Hi Linus,

The major changes for 3.17 already went via Greg-KH's tree this time
as well; this is a small pull request for dma-buf - all documentation
related.

Could you please pull?


The following changes since commit f1bd473f95e02bc382d4dae94d7f82e2a455e05d:

  Merge branch 'sec-v3.17-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security
(2014-08-27 17:32:37 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/for-3.17-rc3

for you to fetch changes up to 1f58d9465c568eb47cab939bbc4f30ae51863295:

  dma-buf/fence: Fix one more kerneldoc warning (2014-08-28 11:59:38 +0530)


Small dma-buf pull request for 3.17-rc3


Gioh Kim (1):
  Documentation/dma-buf-sharing.txt: update API descriptions

Thierry Reding (2):
  dma-buf/fence: Fix a kerneldoc warning
  dma-buf/fence: Fix one more kerneldoc warning

 Documentation/dma-buf-sharing.txt | 14 --
 drivers/dma-buf/fence.c   |  2 +-
 include/linux/seqno-fence.h   |  1 +
 3 files changed, 10 insertions(+), 7 deletions(-)


[Bug 82455] Failed to allocate virtual address for buffer

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82455

--- Comment #28 from charlie <407883775 at qq.com> ---
>>Looks like maybe your Mesa build picked up a non-Mesa EGL/eglext.h which 
>>doesn't pull in eglmesaext.h, so EGL_MESA_screen_surface isn't defined in 
>>src/egl/main/eglconfig.c .

  Sorry , I am not clean about you saying . Do you means is that the
eglmesaext.h(PATH:include/EGL/eglmesaext.h) need including EGL/eglext.h file?

  I change it , but not help.

  or , I add EGL_MESA_screen_surface define in  src/egl/main/eglconfig.c 

  #define  EGL_MESA_screen_surface 1 .

  the problem didn't solved.

-- 
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/20140828/d90065ec/attachment.html>


[Bug 83184] Screen flickering at low resolution when monitor is attached via VGA dongle to DVI port

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83184

--- Comment #1 from Alex Deucher  ---
What physical connectors are actually on your board?  The vbios seems to think
there is a VGA port and a DVI-I port.  If that does not match reality, we may
need to add a quirk for your card to fix 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/20140828/f33ca40f/attachment.html>


[PATCH] drm/radeon: save/restore the PD addr on suspend/resume

2014-08-28 Thread Michel Dänzer
On 26.08.2014 21:45, Christian K?nig wrote:
> From: Christian K?nig 
>
> This fixes a problem with GPU resets and TLB flushes on SI/CIK.
>
> Signed-off-by: Christian K?nig 

[...]

> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index f2dba50..8810df3 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -918,6 +918,8 @@ struct radeon_vm_manager {
>   u64 vram_base_offset;
>   /* is vm enabled? */
>   boolenabled;
> + /* for hw to save the PD addr on suspend/resume */
> + uint32_tsaved_table_addr[RADEON_NUM_VM];
>   };
>
>   /*
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index 011779b..28b5f06 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -4291,10 +4291,10 @@ static int si_pcie_gart_enable(struct radeon_device 
> *rdev)
>   for (i = 1; i < 16; i++) {
>   if (i < 8)
>   WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (i << 2),
> -rdev->gart.table_addr >> 12);
> +rdev->vm_manager.saved_table_addr[i]);
>   else
>   WREG32(VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((i - 8) << 
> 2),
> -rdev->gart.table_addr >> 12);
> +rdev->vm_manager.saved_table_addr[i]);
>   }
>
>   /* enable context1-15 */

rdev->vm_manager.saved_table_addr[] doesn't get initialized before 
*_gart_enable() is first called from *_startup(), does it? I guess 
that's fine, but the comments in *_gart_enable() should be adapted to 
this change.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer


[Bug 75276] Implement VGPR Register Spilling

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=75276

Christoph Haag  changed:

   What|Removed |Added

 Attachment #103583|0   |1
is obsolete||

--- Comment #37 from Christoph Haag  ---
Comment on attachment 103583
  --> https://bugs.freedesktop.org/attachment.cgi?id=103583
backtrace of unreal engine effects demo with debug

If with "this" you mean the Unreal Engine troubles, they are solved and they
should run.

-- 
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/20140828/fd5b078a/attachment.html>


[Bug 75276] Implement VGPR Register Spilling

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=75276

--- Comment #36 from darkbasic  ---
It must be solved in LLVM, not mesa. You can use my forward-ported llvm git
branch if you need register spilling: https://github.com/darkbasic/llvm

-- 
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/20140828/f5fda7dd/attachment.html>


[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82050

--- Comment #29 from smoki  ---

 I also reported on irc Valley stutter on Kabini, but now i am somhow against
reverting because performance suffer with reverting in other games.

 One other reason simply because i tested it first time on Windows today and
there i have stutter even worse then then any case we have here :D. And i did't
know that :D DX11/DX9/OpenGL any mode all stutter a lot. Our worst combination
is a lot smoother than with Catalyst on Windows :).

 So question is, is there other stuter examples than Unigine Valley?

-- 
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/20140828/db39e2c1/attachment.html>


[Bug 75276] Implement VGPR Register Spilling

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=75276

--- Comment #35 from J. Andrew Lanz-O'Brien  ---
Hello. I'm just wondering if this has been resolved in Mesa 10.3, and if not,
what needs to be done to get it there. Thank you!

-- 
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/20140828/583699d3/attachment.html>


[PATCH 3/7] drm/exynos: Renaming DP training vswing pre emph defines

2014-08-28 Thread Jindal, Sonika


On 8/28/2014 11:36 AM, Jingoo Han wrote:
> On Thursday, August 28, 2014 1:33 PM, Sonika Sonika wrote:
>> On 8/28/2014 6:25 AM, Jingoo Han wrote:
>>> On Friday, August 08, 2014 7:54 PM, Sonika Jindal wrote:

 From: Sonika Jindal 

 Rename the defines to have levels instead of values for vswing and
 pre-emph levels as the values may differ in other scenarios like low 
 vswing of
 eDP1.4 where the values are different.

 Done using following cocci patch for each define:
 @@
 @@

# define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
 + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)

 ...

 Signed-off-by: Sonika Jindal 
 ---
drivers/gpu/drm/exynos/exynos_dp_core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index 4f3c7eb..02602a8 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -329,8 +329,8 @@ static int exynos_dp_link_start(struct 
 exynos_dp_device *dp)
return retval;

for (lane = 0; lane < lane_count; lane++)
 -  buf[lane] = DP_TRAIN_PRE_EMPHASIS_0 |
 -  DP_TRAIN_VOLTAGE_SWING_400;
 +  buf[lane] = DP_TRAIN_PRE_EMPH_LEVEL_0 |
 +  DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
>>>
>>> NAK!
>>>
>>> It makes build error. Please build your patch, before sending the patch.
>>> It is a rule when submitting patches.
>>>
>>> Please, fix it as follows.
>>>
>>> +   buf[lane] = DP_TRAIN_PRE_EMPHASIS_LEVEL_0|
>>> +   DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
>>>
>> I think the first patch which you have taken (which adds new defines) is
>> the one from the previous series for the same change. In the second
>> version, I have named them as DP_TRAIN_PRE_EMPH_LEVEL_* which was done
>> using cocci. Following is from that patch:
>
> Oh, I see. Sorry for annoying you.
> However, how about tagging V2, V3.. into patches? For instance,
> '[PATCH V2 3/7] drm/exynos: Renaming DP training vswing pre emph defines'
> It will be helpful, in order to prevent the same mistakes happening again.
>
Actually I had bumped the version in the cover letter. Because last time 
I had changed the version of all the patches (for some other feature), 
somebody asked me to just change the version at the top when it is a series.
Also, this was a different patch altogether done using cocci, so thought 
it should be fine. Will take care next time :)
Thanks,
Sonika
> Also, the patch looks good.
> Acked-by: Jingoo Han 
>
> Best regards,
> Jingoo Han
>
>># define DP_TRAIN_PRE_EMPHASIS_0  (0 << 3)
>> +# define DP_TRAIN_PRE_EMPH_LEVEL_0  (0 << 3)
>># define DP_TRAIN_PRE_EMPHASIS_3_5(1 << 3)
>> +# define DP_TRAIN_PRE_EMPH_LEVEL_1  (1 << 3)
>># define DP_TRAIN_PRE_EMPHASIS_6  (2 << 3)
>> +# define DP_TRAIN_PRE_EMPH_LEVEL_2  (2 << 3)
>># define DP_TRAIN_PRE_EMPHASIS_9_5(3 << 3)
>> +# define DP_TRAIN_PRE_EMPH_LEVEL_3  (3 << 3)
>>> Best regards,
>>> Jingoo Han
>>>

retval = exynos_dp_write_bytes_to_dpcd(dp, 
 DP_TRAINING_LANE0_SET,
lane_count, buf);
 --
 1.7.10.4
>>>
>


[PATCH] radeon: Test for PCI root bus before assuming bus->self

2014-08-28 Thread Dave Airlie
> On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson
>  wrote:
>> If we assign a Radeon device to a virtual machine, we can no longer
>> assume a fixed hardware topology, like the GPU having a parent device.
>> This patch simply adds a few pci_is_root_bus() tests to avoid passing
>> a NULL pointer to PCI access functions, allowing the radeon driver to
>> work in a QEMU 440FX machine with an assigned HD8570 on the emulated
>> PCI root bus.
>>
>> Signed-off-by: Alex Williamson 
>

Does this mean inside a VM we can't enable pcie 2 speeds?

This could lead to a quite disappointing speed decrease for DMA transfers.

Dave.


[PATCH v2 17/17] drm/exynos/ipp: add file checks for ioctls

2014-08-28 Thread Andrzej Hajda
Process should not have access to ipp nodes created by another
process. The patch adds necessary checks.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index fc8bb67..d233cfc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -318,7 +318,8 @@ static void ipp_print_property(struct 
drm_exynos_ipp_property *property,
sz->hsize, sz->vsize, config->flip, config->degree);
 }

-static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property)
+static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property,
+   struct drm_file *file)
 {
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
@@ -339,8 +340,12 @@ static int ipp_find_and_set_property(struct 
drm_exynos_ipp_property *property)
 */
mutex_lock(>cmd_lock);
list_for_each_entry(c_node, >cmd_list, list) {
-   if ((c_node->property.prop_id == prop_id) &&
-   (c_node->state == IPP_STATE_STOP)) {
+   if (c_node->property.prop_id == prop_id) {
+   if (c_node->filp != file)
+   break;
+   if (c_node->state != IPP_STATE_STOP)
+   break;
+
mutex_unlock(>cmd_lock);
DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n",
property->cmd, (int)ippdrv);
@@ -418,7 +423,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
 */
if (property->prop_id) {
DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);
-   return ipp_find_and_set_property(property);
+   return ipp_find_and_set_property(property, file);
}

/* find ipp driver using ipp id */
@@ -1032,7 +1037,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
void *data,

c_node = ipp_find_obj(>prop_idr, >prop_lock,
cmd_ctrl->prop_id);
-   if (!c_node) {
+   if (!c_node || c_node->filp != file) {
DRM_ERROR("invalid command node list.\n");
return -ENODEV;
}
-- 
1.9.1



[PATCH v2 16/17] drm/exynos/ipp: remove file argument from node related functions

2014-08-28 Thread Andrzej Hajda
Since file pointer is preserved in c_node passing it
as argument in node functions is redundant.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 05f0f4e..fc8bb67 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,

 static struct drm_exynos_ipp_mem_node
*ipp_get_mem_node(struct drm_device *drm_dev,
-   struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
 {
@@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
dma_addr_t *addr;

addr = exynos_drm_gem_get_dma_addr(drm_dev,
-   qbuf->handle[i], file);
+   qbuf->handle[i], c_node->filp);
if (IS_ERR(addr)) {
DRM_ERROR("failed to get addr.\n");
ipp_put_mem_node(drm_dev, c_node, m_node);
@@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event *event)
 }

 static int ipp_get_event(struct drm_device *drm_dev,
-   struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
 {
@@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e) {
spin_lock_irqsave(_dev->event_lock, flags);
-   file->event_space += sizeof(e->event);
+   c_node->filp->event_space += sizeof(e->event);
spin_unlock_irqrestore(_dev->event_lock, flags);
return -ENOMEM;
}
@@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e->event.prop_id = qbuf->prop_id;
e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
e->base.event = >event.base;
-   e->base.file_priv = file;
+   e->base.file_priv = c_node->filp;
e->base.destroy = ipp_free_event;
mutex_lock(_node->event_lock);
list_add_tail(>base.link, _node->event_list);
@@ -899,7 +897,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
/* find command node */
c_node = ipp_find_obj(>prop_idr, >prop_lock,
qbuf->prop_id);
-   if (!c_node) {
+   if (!c_node || c_node->filp != file) {
DRM_ERROR("failed to get command node.\n");
return -ENODEV;
}
@@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
switch (qbuf->buf_type) {
case IPP_BUF_ENQUEUE:
/* get memory node */
-   m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
+   m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
if (IS_ERR(m_node)) {
DRM_ERROR("failed to get m_node.\n");
return PTR_ERR(m_node);
@@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
 */
if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
/* get event for destination buffer */
-   ret = ipp_get_event(drm_dev, file, c_node, qbuf);
+   ret = ipp_get_event(drm_dev, c_node, qbuf);
if (ret) {
DRM_ERROR("failed to get event.\n");
goto err_clean_node;
-- 
1.9.1



[PATCH v2 15/17] drm/exynos/fimc: fix source buffer registers

2014-08-28 Thread Andrzej Hajda
FIMC in default mode of operation uses only one input buffer,
but the driver used also second buffer, as a result only the
first frame was processed correctly. The patch fixes it.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 59ba8bb..e2c43b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -722,24 +722,24 @@ static int fimc_src_set_addr(struct device *dev,
case IPP_BUF_ENQUEUE:
config = >config[EXYNOS_DRM_OPS_SRC];
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_Y],
-   EXYNOS_CIIYSA(buf_id));
+   EXYNOS_CIIYSA0);

if (config->fmt == DRM_FORMAT_YVU420) {
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
-   EXYNOS_CIICBSA(buf_id));
+   EXYNOS_CIICBSA0);
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
-   EXYNOS_CIICRSA(buf_id));
+   EXYNOS_CIICRSA0);
} else {
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
-   EXYNOS_CIICBSA(buf_id));
+   EXYNOS_CIICBSA0);
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
-   EXYNOS_CIICRSA(buf_id));
+   EXYNOS_CIICRSA0);
}
break;
case IPP_BUF_DEQUEUE:
-   fimc_write(ctx, 0x0, EXYNOS_CIIYSA(buf_id));
-   fimc_write(ctx, 0x0, EXYNOS_CIICBSA(buf_id));
-   fimc_write(ctx, 0x0, EXYNOS_CIICRSA(buf_id));
+   fimc_write(ctx, 0x0, EXYNOS_CIIYSA0);
+   fimc_write(ctx, 0x0, EXYNOS_CIICBSA0);
+   fimc_write(ctx, 0x0, EXYNOS_CIICRSA0);
break;
default:
/* bypass */
-- 
1.9.1



[PATCH v2 14/17] drm/exynos/fimc: simplify buffer queuing

2014-08-28 Thread Andrzej Hajda
The patch removes redundant checks, redundant HW reads
and simplifies code.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
v2:
- fixed bit cleaning operation
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 64 
 1 file changed, 15 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 62ba033..59ba8bb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1126,67 +1126,34 @@ static int fimc_dst_set_size(struct device *dev, int 
swap,
return 0;
 }

-static int fimc_dst_get_buf_count(struct fimc_context *ctx)
-{
-   u32 cfg, buf_num;
-
-   cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
-
-   buf_num = hweight32(cfg);
-
-   DRM_DEBUG_KMS("buf_num[%d]\n", buf_num);
-
-   return buf_num;
-}
-
-static int fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
+static void fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
enum drm_exynos_ipp_buf_type buf_type)
 {
-   struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   bool enable;
-   u32 cfg;
-   u32 mask = 0x0001 << buf_id;
-   int ret = 0;
unsigned long flags;
+   u32 buf_num;
+   u32 cfg;

DRM_DEBUG_KMS("buf_id[%d]buf_type[%d]\n", buf_id, buf_type);

spin_lock_irqsave(>lock, flags);

-   /* mask register set */
cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);

-   switch (buf_type) {
-   case IPP_BUF_ENQUEUE:
-   enable = true;
-   break;
-   case IPP_BUF_DEQUEUE:
-   enable = false;
-   break;
-   default:
-   dev_err(ippdrv->dev, "invalid buf ctrl parameter.\n");
-   ret =  -EINVAL;
-   goto err_unlock;
-   }
+   if (buf_type == IPP_BUF_ENQUEUE)
+   cfg |= (1 << buf_id);
+   else
+   cfg &= ~(1 << buf_id);

-   /* sequence id */
-   cfg &= ~mask;
-   cfg |= (enable << buf_id);
fimc_write(ctx, cfg, EXYNOS_CIFCNTSEQ);

-   /* interrupt enable */
-   if (buf_type == IPP_BUF_ENQUEUE &&
-   fimc_dst_get_buf_count(ctx) >= FIMC_BUF_START)
-   fimc_mask_irq(ctx, true);
+   buf_num = hweight32(cfg);

-   /* interrupt disable */
-   if (buf_type == IPP_BUF_DEQUEUE &&
-   fimc_dst_get_buf_count(ctx) <= FIMC_BUF_STOP)
+   if (buf_type == IPP_BUF_ENQUEUE && buf_num >= FIMC_BUF_START)
+   fimc_mask_irq(ctx, true);
+   else if (buf_type == IPP_BUF_DEQUEUE && buf_num <= FIMC_BUF_STOP)
fimc_mask_irq(ctx, false);

-err_unlock:
spin_unlock_irqrestore(>lock, flags);
-   return ret;
 }

 static int fimc_dst_set_addr(struct device *dev,
@@ -1244,7 +1211,9 @@ static int fimc_dst_set_addr(struct device *dev,
break;
}

-   return fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
+   fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
+
+   return 0;
 }

 static struct exynos_drm_ipp_ops fimc_dst_ops = {
@@ -1299,10 +1268,7 @@ static irqreturn_t fimc_irq_handler(int irq, void 
*dev_id)

DRM_DEBUG_KMS("buf_id[%d]\n", buf_id);

-   if (fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE) < 0) {
-   DRM_ERROR("failed to dequeue.\n");
-   return IRQ_HANDLED;
-   }
+   fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE);

event_work->ippdrv = ippdrv;
event_work->buf_id[EXYNOS_DRM_OPS_DST] = buf_id;
-- 
1.9.1



[PATCH v2 13/17] drm/exynos/fimc: do not enable fimc twice

2014-08-28 Thread Andrzej Hajda
The patch removes redundant H/W activation.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 6dc9c41..62ba033 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1598,12 +1598,9 @@ static int fimc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)

fimc_clear_bits(ctx, EXYNOS_CIOCTRL, EXYNOS_CIOCTRL_WEAVE_MASK);

-   if (cmd == IPP_CMD_M2M) {
+   if (cmd == IPP_CMD_M2M)
fimc_set_bits(ctx, EXYNOS_MSCTRL, EXYNOS_MSCTRL_ENVID);

-   fimc_set_bits(ctx, EXYNOS_MSCTRL, EXYNOS_MSCTRL_ENVID);
-   }
-
return 0;
 }

-- 
1.9.1



[PATCH v2 12/17] drm/exynos/fimc: avoid clearing overflow bits

2014-08-28 Thread Andrzej Hajda
Overflow bits shall be cleared by H/W.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 34367ff..6dc9c41 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -341,9 +341,6 @@ static bool fimc_check_ovf(struct fimc_context *ctx)
fimc_set_bits(ctx, EXYNOS_CIWDOFST,
EXYNOS_CIWDOFST_CLROVFIY | EXYNOS_CIWDOFST_CLROVFICB |
EXYNOS_CIWDOFST_CLROVFICR);
-   fimc_clear_bits(ctx, EXYNOS_CIWDOFST,
-   EXYNOS_CIWDOFST_CLROVFIY | EXYNOS_CIWDOFST_CLROVFICB |
-   EXYNOS_CIWDOFST_CLROVFICR);

dev_err(ippdrv->dev, "occurred overflow at %d, status 0x%x.\n",
ctx->id, status);
-- 
1.9.1



[PATCH v2 11/17] drm/exynos/ipp: remove events during command cleaning

2014-08-28 Thread Andrzej Hajda
Events were removed only during stop command, as a result
there were memory leaks if program prematurely exited.
This patch fixes it.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 155 
 1 file changed, 78 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 341db52..05f0f4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -600,6 +600,81 @@ static void ipp_clean_mem_nodes(struct drm_device *drm_dev,
mutex_unlock(_node->mem_lock);
 }

+static void ipp_free_event(struct drm_pending_event *event)
+{
+   kfree(event);
+}
+
+static int ipp_get_event(struct drm_device *drm_dev,
+   struct drm_file *file,
+   struct drm_exynos_ipp_cmd_node *c_node,
+   struct drm_exynos_ipp_queue_buf *qbuf)
+{
+   struct drm_exynos_ipp_send_event *e;
+   unsigned long flags;
+
+   DRM_DEBUG_KMS("ops_id[%d]buf_id[%d]\n", qbuf->ops_id, qbuf->buf_id);
+
+   e = kzalloc(sizeof(*e), GFP_KERNEL);
+   if (!e) {
+   spin_lock_irqsave(_dev->event_lock, flags);
+   file->event_space += sizeof(e->event);
+   spin_unlock_irqrestore(_dev->event_lock, flags);
+   return -ENOMEM;
+   }
+
+   /* make event */
+   e->event.base.type = DRM_EXYNOS_IPP_EVENT;
+   e->event.base.length = sizeof(e->event);
+   e->event.user_data = qbuf->user_data;
+   e->event.prop_id = qbuf->prop_id;
+   e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
+   e->base.event = >event.base;
+   e->base.file_priv = file;
+   e->base.destroy = ipp_free_event;
+   mutex_lock(_node->event_lock);
+   list_add_tail(>base.link, _node->event_list);
+   mutex_unlock(_node->event_lock);
+
+   return 0;
+}
+
+static void ipp_put_event(struct drm_exynos_ipp_cmd_node *c_node,
+   struct drm_exynos_ipp_queue_buf *qbuf)
+{
+   struct drm_exynos_ipp_send_event *e, *te;
+   int count = 0;
+
+   mutex_lock(_node->event_lock);
+   list_for_each_entry_safe(e, te, _node->event_list, base.link) {
+   DRM_DEBUG_KMS("count[%d]e[0x%x]\n", count++, (int)e);
+
+   /*
+* qbuf == NULL condition means all event deletion.
+* stop operations want to delete all event list.
+* another case delete only same buf id.
+*/
+   if (!qbuf) {
+   /* delete list */
+   list_del(>base.link);
+   kfree(e);
+   }
+
+   /* compare buffer id */
+   if (qbuf && (qbuf->buf_id ==
+   e->event.buf_id[EXYNOS_DRM_OPS_DST])) {
+   /* delete list */
+   list_del(>base.link);
+   kfree(e);
+   goto out_unlock;
+   }
+   }
+
+out_unlock:
+   mutex_unlock(_node->event_lock);
+   return;
+}
+
 static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
 {
@@ -610,6 +685,9 @@ static void ipp_clean_cmd_node(struct ipp_context *ctx,
cancel_work_sync(_node->stop_work->work);
cancel_work_sync(_node->event_work->work);

+   /* put event */
+   ipp_put_event(c_node, NULL);
+
for_each_ipp_ops(i)
ipp_clean_mem_nodes(ctx->subdrv.drm_dev, c_node, i);

@@ -706,81 +784,6 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
*ippdrv,
return ret;
 }

-static void ipp_free_event(struct drm_pending_event *event)
-{
-   kfree(event);
-}
-
-static int ipp_get_event(struct drm_device *drm_dev,
-   struct drm_file *file,
-   struct drm_exynos_ipp_cmd_node *c_node,
-   struct drm_exynos_ipp_queue_buf *qbuf)
-{
-   struct drm_exynos_ipp_send_event *e;
-   unsigned long flags;
-
-   DRM_DEBUG_KMS("ops_id[%d]buf_id[%d]\n", qbuf->ops_id, qbuf->buf_id);
-
-   e = kzalloc(sizeof(*e), GFP_KERNEL);
-   if (!e) {
-   spin_lock_irqsave(_dev->event_lock, flags);
-   file->event_space += sizeof(e->event);
-   spin_unlock_irqrestore(_dev->event_lock, flags);
-   return -ENOMEM;
-   }
-
-   /* make event */
-   e->event.base.type = DRM_EXYNOS_IPP_EVENT;
-   e->event.base.length = sizeof(e->event);
-   e->event.user_data = qbuf->user_data;
-   e->event.prop_id = qbuf->prop_id;
-   e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
-   e->base.event = >event.base;
-   e->base.file_priv = file;
-   e->base.destroy = ipp_free_event;
-   mutex_lock(_node->event_lock);
-   list_add_tail(>base.link, _node->event_list);
-   mutex_unlock(_node->event_lock);
-
-   

[PATCH v2 10/17] drm/exynos/ipp: stop hardware before freeing memory

2014-08-28 Thread Andrzej Hajda
Memory shouldn't be freed when hardware is still running.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index fff3509..341db52 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1282,12 +1282,15 @@ static int ipp_stop_property(struct drm_device *drm_dev,
struct drm_exynos_ipp_cmd_node *c_node)
 {
struct drm_exynos_ipp_property *property = _node->property;
-   int ret = 0, i;
+   int i;

DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);

/* put event */
ipp_put_event(c_node, NULL);
+   /* stop operations */
+   if (ippdrv->stop)
+   ippdrv->stop(ippdrv->dev, property->cmd);

/* check command */
switch (property->cmd) {
@@ -1303,16 +1306,10 @@ static int ipp_stop_property(struct drm_device *drm_dev,
break;
default:
DRM_ERROR("invalid operations.\n");
-   ret = -EINVAL;
-   goto err_clear;
+   return -EINVAL;
}

-err_clear:
-   /* stop operations */
-   if (ippdrv->stop)
-   ippdrv->stop(ippdrv->dev, property->cmd);
-
-   return ret;
+   return 0;
 }

 void ipp_sched_cmd(struct work_struct *work)
-- 
1.9.1



[PATCH v2 09/17] drm/exynos/ipp: replace work_struct casting with better constructs

2014-08-28 Thread Andrzej Hajda
Type casting should be avoided if possible. In case of
work_struct it can be simply replaced by reference to member field.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c| 2 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 3 +--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 6 +++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 3 +--
 4 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 177e7bc..34367ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1309,7 +1309,7 @@ static irqreturn_t fimc_irq_handler(int irq, void *dev_id)

event_work->ippdrv = ippdrv;
event_work->buf_id[EXYNOS_DRM_OPS_DST] = buf_id;
-   queue_work(ippdrv->event_workq, (struct work_struct *)event_work);
+   queue_work(ippdrv->event_workq, _work->work);

return IRQ_HANDLED;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 9e3ff16..c6a013f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1326,8 +1326,7 @@ static irqreturn_t gsc_irq_handler(int irq, void *dev_id)
buf_id[EXYNOS_DRM_OPS_SRC];
event_work->buf_id[EXYNOS_DRM_OPS_DST] =
buf_id[EXYNOS_DRM_OPS_DST];
-   queue_work(ippdrv->event_workq,
-   (struct work_struct *)event_work);
+   queue_work(ippdrv->event_workq, _work->work);
}

return IRQ_HANDLED;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 857817c..fff3509 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -790,7 +790,7 @@ static void ipp_handle_cmd_work(struct device *dev,

cmd_work->ippdrv = ippdrv;
cmd_work->c_node = c_node;
-   queue_work(ctx->cmd_workq, (struct work_struct *)cmd_work);
+   queue_work(ctx->cmd_workq, _work->work);
 }

 static int ipp_queue_buf_with_run(struct device *dev,
@@ -1318,7 +1318,7 @@ err_clear:
 void ipp_sched_cmd(struct work_struct *work)
 {
struct drm_exynos_ipp_cmd_work *cmd_work =
-   (struct drm_exynos_ipp_cmd_work *)work;
+   container_of(work, struct drm_exynos_ipp_cmd_work, work);
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
struct drm_exynos_ipp_property *property;
@@ -1531,7 +1531,7 @@ err_event_unlock:
 void ipp_sched_event(struct work_struct *work)
 {
struct drm_exynos_ipp_event_work *event_work =
-   (struct drm_exynos_ipp_event_work *)work;
+   container_of(work, struct drm_exynos_ipp_event_work, work);
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
int ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 55af6b4..b6a37d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -156,8 +156,7 @@ static irqreturn_t rotator_irq_handler(int irq, void *arg)
event_work->ippdrv = ippdrv;
event_work->buf_id[EXYNOS_DRM_OPS_DST] =
rot->cur_buf_id[EXYNOS_DRM_OPS_DST];
-   queue_work(ippdrv->event_workq,
-   (struct work_struct *)event_work);
+   queue_work(ippdrv->event_workq, _work->work);
} else {
DRM_ERROR("the SFR is set illegally\n");
}
-- 
1.9.1



[PATCH v2 08/17] drm/exynos/ipp: clean memory nodes on command node cleaning

2014-08-28 Thread Andrzej Hajda
The nodes should be removed before removing command node.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 05f103e..857817c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -603,11 +603,16 @@ static void ipp_clean_mem_nodes(struct drm_device 
*drm_dev,
 static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
 {
+   int i;
+
/* cancel works */
cancel_work_sync(_node->start_work->work);
cancel_work_sync(_node->stop_work->work);
cancel_work_sync(_node->event_work->work);

+   for_each_ipp_ops(i)
+   ipp_clean_mem_nodes(ctx->subdrv.drm_dev, c_node, i);
+
/* delete list */
list_del(_node->list);

-- 
1.9.1



[PATCH v2 07/17] drm/exynos/ipp: move nodes cleaning to separate function

2014-08-28 Thread Andrzej Hajda
The patch introduces ipp_clean_mem_nodes function which replaces
redundant code. Additionally memory node function definitions
are moved up to increase its visibility.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 229 +++-
 1 file changed, 106 insertions(+), 123 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index ab7b74c..05f103e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -498,6 +498,108 @@ err_clear:
return ret;
 }

+static int ipp_put_mem_node(struct drm_device *drm_dev,
+   struct drm_exynos_ipp_cmd_node *c_node,
+   struct drm_exynos_ipp_mem_node *m_node)
+{
+   int i;
+
+   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
+
+   if (!m_node) {
+   DRM_ERROR("invalid dequeue node.\n");
+   return -EFAULT;
+   }
+
+   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
+
+   /* put gem buffer */
+   for_each_ipp_planar(i) {
+   unsigned long handle = m_node->buf_info.handles[i];
+   if (handle)
+   exynos_drm_gem_put_dma_addr(drm_dev, handle,
+   c_node->filp);
+   }
+
+   list_del(_node->list);
+   kfree(m_node);
+
+   return 0;
+}
+
+static struct drm_exynos_ipp_mem_node
+   *ipp_get_mem_node(struct drm_device *drm_dev,
+   struct drm_file *file,
+   struct drm_exynos_ipp_cmd_node *c_node,
+   struct drm_exynos_ipp_queue_buf *qbuf)
+{
+   struct drm_exynos_ipp_mem_node *m_node;
+   struct drm_exynos_ipp_buf_info *buf_info;
+   int i;
+
+   m_node = kzalloc(sizeof(*m_node), GFP_KERNEL);
+   if (!m_node)
+   return ERR_PTR(-ENOMEM);
+
+   buf_info = _node->buf_info;
+
+   /* operations, buffer id */
+   m_node->ops_id = qbuf->ops_id;
+   m_node->prop_id = qbuf->prop_id;
+   m_node->buf_id = qbuf->buf_id;
+   INIT_LIST_HEAD(_node->list);
+
+   DRM_DEBUG_KMS("m_node[0x%x]ops_id[%d]\n", (int)m_node, qbuf->ops_id);
+   DRM_DEBUG_KMS("prop_id[%d]buf_id[%d]\n", qbuf->prop_id, m_node->buf_id);
+
+   for_each_ipp_planar(i) {
+   DRM_DEBUG_KMS("i[%d]handle[0x%x]\n", i, qbuf->handle[i]);
+
+   /* get dma address by handle */
+   if (qbuf->handle[i]) {
+   dma_addr_t *addr;
+
+   addr = exynos_drm_gem_get_dma_addr(drm_dev,
+   qbuf->handle[i], file);
+   if (IS_ERR(addr)) {
+   DRM_ERROR("failed to get addr.\n");
+   ipp_put_mem_node(drm_dev, c_node, m_node);
+   return ERR_PTR(-EFAULT);
+   }
+
+   buf_info->handles[i] = qbuf->handle[i];
+   buf_info->base[i] = *addr;
+   DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
+ buf_info->base[i], buf_info->handles[i]);
+   }
+   }
+
+   mutex_lock(_node->mem_lock);
+   list_add_tail(_node->list, _node->mem_list[qbuf->ops_id]);
+   mutex_unlock(_node->mem_lock);
+
+   return m_node;
+}
+
+static void ipp_clean_mem_nodes(struct drm_device *drm_dev,
+  struct drm_exynos_ipp_cmd_node *c_node, int ops)
+{
+   struct drm_exynos_ipp_mem_node *m_node, *tm_node;
+   struct list_head *head = _node->mem_list[ops];
+
+   mutex_lock(_node->mem_lock);
+
+   list_for_each_entry_safe(m_node, tm_node, head, list) {
+   int ret;
+
+   ret = ipp_put_mem_node(drm_dev, c_node, m_node);
+   if (ret)
+   DRM_ERROR("failed to put m_node.\n");
+   }
+
+   mutex_unlock(_node->mem_lock);
+}
+
 static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
 {
@@ -599,89 +701,6 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
*ippdrv,
return ret;
 }

-static int ipp_put_mem_node(struct drm_device *drm_dev,
-   struct drm_exynos_ipp_cmd_node *c_node,
-   struct drm_exynos_ipp_mem_node *m_node)
-{
-   int i;
-
-   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
-
-   if (!m_node) {
-   DRM_ERROR("invalid dequeue node.\n");
-   return -EFAULT;
-   }
-
-   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
-
-   /* put gem buffer */
-   for_each_ipp_planar(i) {
-   unsigned long handle = m_node->buf_info.handles[i];
-   if (handle)
-   exynos_drm_gem_put_dma_addr(drm_dev, handle,
-   

[PATCH v2 06/17] drm/exynos/ipp: free partially allocated resources on error

2014-08-28 Thread Andrzej Hajda
In case of allocation errors some already allocated buffers
were not freed. The patch fixes it.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 67 -
 1 file changed, 32 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 060a198..ab7b74c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -599,6 +599,35 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
*ippdrv,
return ret;
 }

+static int ipp_put_mem_node(struct drm_device *drm_dev,
+   struct drm_exynos_ipp_cmd_node *c_node,
+   struct drm_exynos_ipp_mem_node *m_node)
+{
+   int i;
+
+   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
+
+   if (!m_node) {
+   DRM_ERROR("invalid dequeue node.\n");
+   return -EFAULT;
+   }
+
+   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
+
+   /* put gem buffer */
+   for_each_ipp_planar(i) {
+   unsigned long handle = m_node->buf_info.handles[i];
+   if (handle)
+   exynos_drm_gem_put_dma_addr(drm_dev, handle,
+   c_node->filp);
+   }
+
+   list_del(_node->list);
+   kfree(m_node);
+
+   return 0;
+}
+
 static struct drm_exynos_ipp_mem_node
*ipp_get_mem_node(struct drm_device *drm_dev,
struct drm_file *file,
@@ -619,6 +648,7 @@ static struct drm_exynos_ipp_mem_node
m_node->ops_id = qbuf->ops_id;
m_node->prop_id = qbuf->prop_id;
m_node->buf_id = qbuf->buf_id;
+   INIT_LIST_HEAD(_node->list);

DRM_DEBUG_KMS("m_node[0x%x]ops_id[%d]\n", (int)m_node, qbuf->ops_id);
DRM_DEBUG_KMS("prop_id[%d]buf_id[%d]\n", qbuf->prop_id, m_node->buf_id);
@@ -634,7 +664,8 @@ static struct drm_exynos_ipp_mem_node
qbuf->handle[i], file);
if (IS_ERR(addr)) {
DRM_ERROR("failed to get addr.\n");
-   goto err_clear;
+   ipp_put_mem_node(drm_dev, c_node, m_node);
+   return ERR_PTR(-EFAULT);
}

buf_info->handles[i] = qbuf->handle[i];
@@ -649,40 +680,6 @@ static struct drm_exynos_ipp_mem_node
mutex_unlock(_node->mem_lock);

return m_node;
-
-err_clear:
-   kfree(m_node);
-   return ERR_PTR(-EFAULT);
-}
-
-static int ipp_put_mem_node(struct drm_device *drm_dev,
-   struct drm_exynos_ipp_cmd_node *c_node,
-   struct drm_exynos_ipp_mem_node *m_node)
-{
-   int i;
-
-   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
-
-   if (!m_node) {
-   DRM_ERROR("invalid dequeue node.\n");
-   return -EFAULT;
-   }
-
-   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
-
-   /* put gem buffer */
-   for_each_ipp_planar(i) {
-   unsigned long handle = m_node->buf_info.handles[i];
-   if (handle)
-   exynos_drm_gem_put_dma_addr(drm_dev, handle,
-   c_node->filp);
-   }
-
-   /* delete list in queue */
-   list_del(_node->list);
-   kfree(m_node);
-
-   return 0;
 }

 static void ipp_free_event(struct drm_pending_event *event)
-- 
1.9.1



[PATCH v2 05/17] drm/exynos/ipp: remove unused field in command node

2014-08-28 Thread Andrzej Hajda
Since command node have file pointer dev field became useless.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 81f780e..060a198 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -444,7 +444,6 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
property->prop_id, property->cmd, (int)ippdrv);

/* stored property information and ippdrv in private data */
-   c_node->dev = dev;
c_node->property = *property;
c_node->state = IPP_STATE_IDLE;
c_node->filp = file;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 0311035..2a61547 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -48,7 +48,6 @@ struct drm_exynos_ipp_cmd_work {
 /*
  * A structure of command node.
  *
- * @dev: IPP device.
  * @list: list head to command queue information.
  * @event_list: list head of event.
  * @mem_list: list head to source,destination memory queue information.
@@ -65,7 +64,6 @@ struct drm_exynos_ipp_cmd_work {
  * @filp: associated file pointer.
  */
 struct drm_exynos_ipp_cmd_node {
-   struct device   *dev;
struct list_headlist;
struct list_headevent_list;
struct list_headmem_list[EXYNOS_DRM_OPS_MAX];
-- 
1.9.1



[PATCH v2 04/17] drm/exynos/ipp: remove only related commands on file close

2014-08-28 Thread Andrzej Hajda
On file close driver should remove only command nodes created
via this file.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index bbe9968..81f780e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1681,14 +1681,11 @@ static int ipp_subdrv_open(struct drm_device *drm_dev, 
struct device *dev,
 static void ipp_subdrv_close(struct drm_device *drm_dev, struct device *dev,
struct drm_file *file)
 {
-   struct drm_exynos_file_private *file_priv = file->driver_priv;
struct exynos_drm_ippdrv *ippdrv = NULL;
struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp_cmd_node *c_node, *tc_node;
int count = 0;

-   DRM_DEBUG_KMS("for priv[0x%x]\n", (int)file_priv->ipp_dev);
-
list_for_each_entry(ippdrv, _drm_ippdrv_list, drv_list) {
mutex_lock(>cmd_lock);
list_for_each_entry_safe(c_node, tc_node,
@@ -1696,7 +1693,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev, 
struct device *dev,
DRM_DEBUG_KMS("count[%d]ippdrv[0x%x]\n",
count++, (int)ippdrv);

-   if (c_node->dev == file_priv->ipp_dev) {
+   if (c_node->filp == file) {
/*
 * userland goto unnormal state. process killed.
 * and close the file.
-- 
1.9.1



[PATCH v2 03/17] drm/exynos/ipp: move file reference from memory to command node

2014-08-28 Thread Andrzej Hajda
Command node should contain file reference to distinguish commands
created by different processes.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 ++---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 ++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 9770966..bbe9968 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -75,7 +75,6 @@ struct drm_exynos_ipp_mem_node {
u32 prop_id;
u32 buf_id;
struct drm_exynos_ipp_buf_info  buf_info;
-   struct drm_file *filp;
 };

 /*
@@ -448,6 +447,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
c_node->dev = dev;
c_node->property = *property;
c_node->state = IPP_STATE_IDLE;
+   c_node->filp = file;

c_node->start_work = ipp_create_cmd_work();
if (IS_ERR(c_node->start_work)) {
@@ -645,7 +645,6 @@ static struct drm_exynos_ipp_mem_node
}
}

-   m_node->filp = file;
mutex_lock(_node->mem_lock);
list_add_tail(_node->list, _node->mem_list[qbuf->ops_id]);
mutex_unlock(_node->mem_lock);
@@ -677,7 +676,7 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
unsigned long handle = m_node->buf_info.handles[i];
if (handle)
exynos_drm_gem_put_dma_addr(drm_dev, handle,
-   m_node->filp);
+   c_node->filp);
}

/* delete list in queue */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 6f48d62..0311035 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -62,6 +62,7 @@ struct drm_exynos_ipp_cmd_work {
  * @stop_work: stop command work structure.
  * @event_work: event work structure.
  * @state: state of command node.
+ * @filp: associated file pointer.
  */
 struct drm_exynos_ipp_cmd_node {
struct device   *dev;
@@ -78,6 +79,7 @@ struct drm_exynos_ipp_cmd_node {
struct drm_exynos_ipp_cmd_work *stop_work;
struct drm_exynos_ipp_event_work *event_work;
enum drm_exynos_ipp_state   state;
+   struct drm_file *filp;
 };

 /*
-- 
1.9.1



[PATCH v2 02/17] drm/exynos/ipp: cancel works before command node clean

2014-08-28 Thread Andrzej Hajda
All pending works should be canceled prior to its removal.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index da917ca..9770966 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -502,6 +502,11 @@ err_clear:
 static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
 {
+   /* cancel works */
+   cancel_work_sync(_node->start_work->work);
+   cancel_work_sync(_node->stop_work->work);
+   cancel_work_sync(_node->event_work->work);
+
/* delete list */
list_del(_node->list);

-- 
1.9.1



[PATCH v2 01/17] drm/exynos/ipp: remove fake pm callbacks

2014-08-28 Thread Andrzej Hajda
PM callbacks in ipp core do nothing, so the patch removes it.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 51 -
 1 file changed, 51 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index c411399..da917ca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1808,63 +1808,12 @@ static int ipp_remove(struct platform_device *pdev)
return 0;
 }

-static int ipp_power_ctrl(struct ipp_context *ctx, bool enable)
-{
-   DRM_DEBUG_KMS("enable[%d]\n", enable);
-
-   return 0;
-}
-
-#ifdef CONFIG_PM_SLEEP
-static int ipp_suspend(struct device *dev)
-{
-   struct ipp_context *ctx = get_ipp_context(dev);
-
-   if (pm_runtime_suspended(dev))
-   return 0;
-
-   return ipp_power_ctrl(ctx, false);
-}
-
-static int ipp_resume(struct device *dev)
-{
-   struct ipp_context *ctx = get_ipp_context(dev);
-
-   if (!pm_runtime_suspended(dev))
-   return ipp_power_ctrl(ctx, true);
-
-   return 0;
-}
-#endif
-
-#ifdef CONFIG_PM_RUNTIME
-static int ipp_runtime_suspend(struct device *dev)
-{
-   struct ipp_context *ctx = get_ipp_context(dev);
-
-   return ipp_power_ctrl(ctx, false);
-}
-
-static int ipp_runtime_resume(struct device *dev)
-{
-   struct ipp_context *ctx = get_ipp_context(dev);
-
-   return ipp_power_ctrl(ctx, true);
-}
-#endif
-
-static const struct dev_pm_ops ipp_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(ipp_suspend, ipp_resume)
-   SET_RUNTIME_PM_OPS(ipp_runtime_suspend, ipp_runtime_resume, NULL)
-};
-
 struct platform_driver ipp_driver = {
.probe  = ipp_probe,
.remove = ipp_remove,
.driver = {
.name   = "exynos-drm-ipp",
.owner  = THIS_MODULE,
-   .pm = _pm_ops,
},
 };

-- 
1.9.1



[PATCH v2 00/17] drm/exynos/ipp: image post processing fixes and improvements, part four

2014-08-28 Thread Andrzej Hajda
This set of patches contains various improvement and fixes
for exynos_drm ipp framework.
The patchset is based on exynos-drm-next branch.

IPP framework was tested for regressions on exynos4210-trats target.

In the 2nd version of the series I have included changes proposed by Joonyoung 
Shim.
I have decided to resend whole series because the changes caused merge 
conflicts and
two separate patches have been added to the series.
Changes are described in comit messages.

Regards
Andrzej


Andrzej Hajda (17):
  drm/exynos/ipp: remove fake pm callbacks
  drm/exynos/ipp: cancel works before command node clean
  drm/exynos/ipp: move file reference from memory to command node
  drm/exynos/ipp: remove only related commands on file close
  drm/exynos/ipp: remove unused field in command node
  drm/exynos/ipp: free partially allocated resources on error
  drm/exynos/ipp: move nodes cleaning to separate function
  drm/exynos/ipp: clean memory nodes on command node cleaning
  drm/exynos/ipp: replace work_struct casting with better constructs
  drm/exynos/ipp: stop hardware before freeing memory
  drm/exynos/ipp: remove events during command cleaning
  drm/exynos/fimc: avoid clearing overflow bits
  drm/exynos/fimc: do not enable fimc twice
  drm/exynos/fimc: simplify buffer queuing
  drm/exynos/fimc: fix source buffer registers
  drm/exynos/ipp: remove file argument from node related functions
  drm/exynos/ipp: add file checks for ioctls

 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  90 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 397 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   3 +-
 5 files changed, 195 insertions(+), 302 deletions(-)

-- 
1.9.1



[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag

2014-08-28 Thread Alex Deucher
On Thu, Aug 28, 2014 at 4:57 AM, Christian K?nig
 wrote:
> Am 28.08.2014 um 08:56 schrieb Michel D?nzer:
>
>> From: Michel D?nzer 
>>
>> This flag is a hint that userspace expects the BO to be accessed by the
>> CPU. We can use that hint to prevent such BOs from ever being stored in
>> the CPU inaccessible part of VRAM.
>>
>> Signed-off-by: Michel D?nzer 
>
>
> This patch is Reviewed-by: Christian K?nig 

Applied to my -next tree.

>
> I think we need a similar negative flags as well, e.g.
> RADEON_GEM_NO_CPU_ACCESS.
>
> This way we can stop forcing buffers into the visible VRAM while pinning
> them for scanout.


How about the attached patch?

Alex

>
> Regards,
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/radeon/radeon_object.c | 11 +--
>>   include/uapi/drm/radeon_drm.h  |  2 ++
>>   2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>> b/drivers/gpu/drm/radeon/radeon_object.c
>> index dc74cc5..908ea541 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -143,7 +143,12 @@ void radeon_ttm_placement_from_domain(struct
>> radeon_bo *rbo, u32 domain)
>> for (i = 0; i < c; ++i) {
>> rbo->placements[i].fpfn = 0;
>> -   rbo->placements[i].lpfn = 0;
>> +   if ((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
>> +   (rbo->placements[i].flags & TTM_PL_FLAG_VRAM))
>> +   rbo->placements[i].lpfn =
>> +   rbo->rdev->mc.visible_vram_size >>
>> PAGE_SHIFT;
>> +   else
>> +   rbo->placements[i].lpfn = 0;
>> }
>> /*
>> @@ -151,7 +156,9 @@ void radeon_ttm_placement_from_domain(struct radeon_bo
>> *rbo, u32 domain)
>>  * improve fragmentation quality.
>>  * 512kb was measured as the most optimal number.
>>  */
>> -   if (rbo->tbo.mem.size > 512 * 1024) {
>> +   if (!((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
>> + (rbo->placements[i].flags & TTM_PL_FLAG_VRAM)) &&
>> +   rbo->tbo.mem.size > 512 * 1024) {
>> for (i = 0; i < c; i++) {
>> rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
>> }
>> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
>> index 509b2d7..bf0067b 100644
>> --- a/include/uapi/drm/radeon_drm.h
>> +++ b/include/uapi/drm/radeon_drm.h
>> @@ -799,6 +799,8 @@ struct drm_radeon_gem_info {
>>   #define RADEON_GEM_NO_BACKING_STORE   (1 << 0)
>>   #define RADEON_GEM_GTT_UC (1 << 1)
>>   #define RADEON_GEM_GTT_WC (1 << 2)
>> +/* BO is expected to be accessed by the CPU */
>> +#define RADEON_GEM_CPU_ACCESS  (1 << 3)
>> struct drm_radeon_gem_create {
>> uint64_tsize;
>
>
> ___
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-add-RADEON_GEM_NO_CPU_ACCESS-BO-creation-.patch
Type: text/x-diff
Size: 1902 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140828/cf6d8a9f/attachment.patch>


[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag

2014-08-28 Thread Christian König
Am 28.08.2014 um 08:56 schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> This flag is a hint that userspace expects the BO to be accessed by the
> CPU. We can use that hint to prevent such BOs from ever being stored in
> the CPU inaccessible part of VRAM.
>
> Signed-off-by: Michel D?nzer 

This patch is Reviewed-by: Christian K?nig 

I think we need a similar negative flags as well, e.g. 
RADEON_GEM_NO_CPU_ACCESS.

This way we can stop forcing buffers into the visible VRAM while pinning 
them for scanout.

Regards,
Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_object.c | 11 +--
>   include/uapi/drm/radeon_drm.h  |  2 ++
>   2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index dc74cc5..908ea541 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -143,7 +143,12 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
>   
>   for (i = 0; i < c; ++i) {
>   rbo->placements[i].fpfn = 0;
> - rbo->placements[i].lpfn = 0;
> + if ((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
> + (rbo->placements[i].flags & TTM_PL_FLAG_VRAM))
> + rbo->placements[i].lpfn =
> + rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
> + else
> + rbo->placements[i].lpfn = 0;
>   }
>   
>   /*
> @@ -151,7 +156,9 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
>* improve fragmentation quality.
>* 512kb was measured as the most optimal number.
>*/
> - if (rbo->tbo.mem.size > 512 * 1024) {
> + if (!((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
> +   (rbo->placements[i].flags & TTM_PL_FLAG_VRAM)) &&
> + rbo->tbo.mem.size > 512 * 1024) {
>   for (i = 0; i < c; i++) {
>   rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
>   }
> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
> index 509b2d7..bf0067b 100644
> --- a/include/uapi/drm/radeon_drm.h
> +++ b/include/uapi/drm/radeon_drm.h
> @@ -799,6 +799,8 @@ struct drm_radeon_gem_info {
>   #define RADEON_GEM_NO_BACKING_STORE (1 << 0)
>   #define RADEON_GEM_GTT_UC   (1 << 1)
>   #define RADEON_GEM_GTT_WC   (1 << 2)
> +/* BO is expected to be accessed by the CPU */
> +#define RADEON_GEM_CPU_ACCESS(1 << 3)
>   
>   struct drm_radeon_gem_create {
>   uint64_tsize;



[PATCH 1/2] drm/ttm: move fpfn and lpfn into each placement

2014-08-28 Thread Michel Dänzer
On 22.08.2014 17:13, Christian K?nig wrote:
> From: Christian K?nig 
>
> This allows us to more fine grained specify where to place the buffer object.
>
> Signed-off-by: Christian K?nig 

Tested-and-Acked-by: Michel D?nzer 

(for radeon)


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer


[PATCH] drm/radeon: save/restore the PD addr on suspend/resume

2014-08-28 Thread Christian König
Am 28.08.2014 um 05:43 schrieb Michel D?nzer:
> On 26.08.2014 21:45, Christian K?nig wrote:
>> From: Christian K?nig 
>>
>> This fixes a problem with GPU resets and TLB flushes on SI/CIK.
>>
>> Signed-off-by: Christian K?nig 
>
> [...]
>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h 
>> b/drivers/gpu/drm/radeon/radeon.h
>> index f2dba50..8810df3 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -918,6 +918,8 @@ struct radeon_vm_manager {
>>   u64vram_base_offset;
>>   /* is vm enabled? */
>>   boolenabled;
>> +/* for hw to save the PD addr on suspend/resume */
>> +uint32_tsaved_table_addr[RADEON_NUM_VM];
>>   };
>>
>>   /*
>> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
>> index 011779b..28b5f06 100644
>> --- a/drivers/gpu/drm/radeon/si.c
>> +++ b/drivers/gpu/drm/radeon/si.c
>> @@ -4291,10 +4291,10 @@ static int si_pcie_gart_enable(struct 
>> radeon_device *rdev)
>>   for (i = 1; i < 16; i++) {
>>   if (i < 8)
>>   WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (i << 2),
>> -   rdev->gart.table_addr >> 12);
>> +   rdev->vm_manager.saved_table_addr[i]);
>>   else
>>   WREG32(VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((i - 8) << 2),
>> -   rdev->gart.table_addr >> 12);
>> +   rdev->vm_manager.saved_table_addr[i]);
>>   }
>>
>>   /* enable context1-15 */
>
> rdev->vm_manager.saved_table_addr[] doesn't get initialized before 
> *_gart_enable() is first called from *_startup(), does it? I guess 
> that's fine, but the comments in *_gart_enable() should be adapted to 
> this change.

It gets zero initialized on allocation. But your right I only updated 
the code comment on CIK, not on SI and NI.

Going to fix this in a follow up patch,
Christian.


[PATCH] drm/i915: Remove bogus __init annotation from DMI callbacks

2014-08-28 Thread Jani Nikula
On Wed, 27 Aug 2014, Mathias Krause  wrote:
> The __init annotations for the DMI callback functions are wrong as this
> code can be called even after the module has been initialized, e.g. like
> this:
>
>   # echo 1 > /sys/bus/pci/devices/:00:02.0/remove
>   # modprobe i915
>   # echo 1 > /sys/bus/pci/rescan
>
> The first command will remove the PCI device from the kernel's device
> list so the second command won't see it right away. But as it registers
> a PCI driver it'll see it on the third command. If the system happens to
> match one of the DMI table entries we'll try to call a function in long
> released memory and generate an Oops, at best.
>
> Fix this by removing the bogus annotation.
>
> Modpost should have caught that one but it ignores section reference
> mismatches from the .rodata section. :/
>
> Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT")
> Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...")
> Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...")
> Signed-off-by: Mathias Krause 
> Cc: Daniel Vetter 
> Cc: Duncan Laurie 
> Cc: Jarod Wilson 
> Cc: Rusty Russell   # Can modpost be fixed?
> Cc: stable at vger.kernel.org

Nice catch! Thanks for the patch, pushed to drm-intel-fixes.

BR,
Jani.



> ---
>
> In the long run me might want to move the DMI tests to some __init code
> to be able to mark the DMI tables as __initconst, thereby allowing to
> release this memory after module initialization. That would safe us some
> ~11 kB of memory, as the DMI data shouldn't change at run-time.
>
>  drivers/gpu/drm/i915/intel_bios.c |2 +-
>  drivers/gpu/drm/i915/intel_crt.c  |2 +-
>  drivers/gpu/drm/i915/intel_lvds.c |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index a66955037e4e..eee79e1c3222 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1123,7 +1123,7 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
>   }
>  }
>  
> -static int __init intel_no_opregion_vbt_callback(const struct dmi_system_id 
> *id)
> +static int intel_no_opregion_vbt_callback(const struct dmi_system_id *id)
>  {
>   DRM_DEBUG_KMS("Falling back to manually reading VBT from "
> "VBIOS ROM for %s\n",
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index e8abfce40976..9212e6504e0f 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -804,7 +804,7 @@ static const struct drm_encoder_funcs intel_crt_enc_funcs 
> = {
>   .destroy = intel_encoder_destroy,
>  };
>  
> -static int __init intel_no_crt_dmi_callback(const struct dmi_system_id *id)
> +static int intel_no_crt_dmi_callback(const struct dmi_system_id *id)
>  {
>   DRM_INFO("Skipping CRT initialization for %s\n", id->ident);
>   return 1;
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 881361c0f27e..fdf40267249c 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -538,7 +538,7 @@ static const struct drm_encoder_funcs 
> intel_lvds_enc_funcs = {
>   .destroy = intel_encoder_destroy,
>  };
>  
> -static int __init intel_no_lvds_dmi_callback(const struct dmi_system_id *id)
> +static int intel_no_lvds_dmi_callback(const struct dmi_system_id *id)
>  {
>   DRM_INFO("Skipping LVDS initialization for %s\n", id->ident);
>   return 1;
> -- 
> 1.7.10.4
>

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH 3/7] drm/exynos: Renaming DP training vswing pre emph defines

2014-08-28 Thread Jindal, Sonika


On 8/28/2014 6:25 AM, Jingoo Han wrote:
> On Friday, August 08, 2014 7:54 PM, Sonika Jindal wrote:
>>
>> From: Sonika Jindal 
>>
>> Rename the defines to have levels instead of values for vswing and
>> pre-emph levels as the values may differ in other scenarios like low vswing 
>> of
>> eDP1.4 where the values are different.
>>
>> Done using following cocci patch for each define:
>> @@
>> @@
>>
>>   # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
>> + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
>>
>> ...
>>
>> Signed-off-by: Sonika Jindal 
>> ---
>>   drivers/gpu/drm/exynos/exynos_dp_core.c |4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..02602a8 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -329,8 +329,8 @@ static int exynos_dp_link_start(struct exynos_dp_device 
>> *dp)
>>  return retval;
>>
>>  for (lane = 0; lane < lane_count; lane++)
>> -buf[lane] = DP_TRAIN_PRE_EMPHASIS_0 |
>> -DP_TRAIN_VOLTAGE_SWING_400;
>> +buf[lane] = DP_TRAIN_PRE_EMPH_LEVEL_0 |
>> +DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
>
> NAK!
>
> It makes build error. Please build your patch, before sending the patch.
> It is a rule when submitting patches.
>
> Please, fix it as follows.
>
> + buf[lane] = DP_TRAIN_PRE_EMPHASIS_LEVEL_0|
> + DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
>
I think the first patch which you have taken (which adds new defines) is 
the one from the previous series for the same change. In the second 
version, I have named them as DP_TRAIN_PRE_EMPH_LEVEL_* which was done 
using cocci. Following is from that patch:
  # define DP_TRAIN_PRE_EMPHASIS_0  (0 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_0 (0 << 3)
  # define DP_TRAIN_PRE_EMPHASIS_3_5(1 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_1 (1 << 3)
  # define DP_TRAIN_PRE_EMPHASIS_6  (2 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_2 (2 << 3)
  # define DP_TRAIN_PRE_EMPHASIS_9_5(3 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_3 (3 << 3)
> Best regards,
> Jingoo Han
>
>>
>>  retval = exynos_dp_write_bytes_to_dpcd(dp, DP_TRAINING_LANE0_SET,
>>  lane_count, buf);
>> --
>> 1.7.10.4
>


[PATCH 3/7] drm/exynos: Renaming DP training vswing pre emph defines

2014-08-28 Thread Jingoo Han
On Friday, August 08, 2014 7:54 PM, Sonika Jindal wrote:
> 
> From: Sonika Jindal 
> 
> Rename the defines to have levels instead of values for vswing and
> pre-emph levels as the values may differ in other scenarios like low vswing of
> eDP1.4 where the values are different.
> 
> Done using following cocci patch for each define:
> @@
> @@
> 
>  # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
> + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> 
> ...
> 
> Signed-off-by: Sonika Jindal 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4f3c7eb..02602a8 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -329,8 +329,8 @@ static int exynos_dp_link_start(struct exynos_dp_device 
> *dp)
>   return retval;
> 
>   for (lane = 0; lane < lane_count; lane++)
> - buf[lane] = DP_TRAIN_PRE_EMPHASIS_0 |
> - DP_TRAIN_VOLTAGE_SWING_400;
> + buf[lane] = DP_TRAIN_PRE_EMPH_LEVEL_0 |
> + DP_TRAIN_VOLTAGE_SWING_LEVEL_0;

NAK!

It makes build error. Please build your patch, before sending the patch.
It is a rule when submitting patches.

Please, fix it as follows.

+   buf[lane] = DP_TRAIN_PRE_EMPHASIS_LEVEL_0|
+   DP_TRAIN_VOLTAGE_SWING_LEVEL_0;

Best regards,
Jingoo Han

> 
>   retval = exynos_dp_write_bytes_to_dpcd(dp, DP_TRAINING_LANE0_SET,
>   lane_count, buf);
> --
> 1.7.10.4



[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

2014-08-28 Thread Jingoo Han
On Wednesday, August 27, 2014 1:31 PM, Jindal, Sonika wrote:
> On 8/26/2014 4:58 PM, Thierry Reding wrote:
> > On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jindal at intel.com wrote:
> >> From: Sonika Jindal 
> >>
> >> Adding new defines, older one will be removed in the last patch in the 
> >> series.
> >> This is to rename the defines to have levels instead of values for vswing 
> >> and
> >> pre-emph levels as the values may differ in other scenarios like low 
> >> vswing of
> >> eDP1.4 where the values are different.
> >>
> >> Done using following cocci patch for each define:
> >> @@
> >> @@
> >>
> >>   # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
> >> + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> >
> > Could this perhaps be simply:
> >
> > #define DP_TRAIN_VOLTAGE_SWING(x) ((x) << 0)
> >
> > As it is, there's no information about the value within the symbolic
> > name anyway, so _LEVEL_* really isn't that useful and keeping several
> > macros for each value seems isn't either.
> >
> I feel _LEVEL_* makes it more readable and since there are only 4 values
> possible, it is ok to have 4 different macros for readability purpose.
> What do you think?

(+cc Damien Lespiau)

Personally, I also think that LEVEL_* looks more readable. 

Best regards,
Jingoo Han

> > An alternative would be to provide a second set of defines for eDP 1.4
> > where the name implies the meaning and then use them as appropriate.
> >
> > Thierry
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Bug 83185] [radeonsi] "random" gpu lookup without recovery (VM fault spam in dmesg)

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83185

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Christian K?nig  ---
That's a known issue. Make sure your kernel has patch "drm/radeon: save/restore
the PD addr on suspend/resume".

-- 
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/20140828/3f9b7efd/attachment.html>


[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82050

--- Comment #28 from Andy Furniss  ---
(In reply to comment #27)
> (In reply to comment #26)
> > No difference with those.
> 
> Bummer, thanks for testing anyway.
> 
> I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for
> review, but it's strange: I couldn't notice any significant difference in
> stutter in Valley regardless of any of these changes.
> 
> BTW, what CPU are you using?

It's an AMD Phenom II x4 965be.

I always set cpufreq ondemand to perf when testing so it's forced @ 3.4GHz.

When I noticed that ffmpeg x11grab made the pauses "normal" length I did try a
different test with cpus loaded by compiling, but this didn't do 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/20140828/1c3befe5/attachment.html>


[Bug 83185] New: [radeonsi] "random" gpu lookup without recovery (VM fault spam in dmesg)

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83185

  Priority: medium
Bug ID: 83185
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [radeonsi] "random" gpu lookup without recovery (VM
fault spam in dmesg)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: osbios at web.de
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

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

Got this random gpu lookup. Nothing special was running, just firefox and a few
xterm.

Ubuntu 14.04. With Oibaf PPA.
Radeon 7870 (Pitcairn)
kernel 3.17.0-rc2

-- 
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/20140828/6461271a/attachment.html>


[PATCH 06/15] drm/exynos/ipp: free partially allocated resources on error

2014-08-28 Thread Joonyoung Shim
Hi,

On 08/27/2014 07:27 PM, Andrzej Hajda wrote:
> On 08/26/2014 07:00 AM, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
>>> In case of allocation errors some already allocated buffers
>>> were not freed. The patch fixes it.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 68 
>>> -
>>>  1 file changed, 33 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> index 060a198..728f3b9 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> @@ -599,6 +599,37 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
>>> *ippdrv,
>>> return ret;
>>>  }
>>>  
>>> +static int ipp_put_mem_node(struct drm_device *drm_dev,
>>> +   struct drm_exynos_ipp_cmd_node *c_node,
>>> +   struct drm_exynos_ipp_mem_node *m_node)
>>> +{
>>> +   int i;
>>> +
>>> +   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>>> +
>>> +   if (!m_node) {
>>> +   DRM_ERROR("invalid dequeue node.\n");
>>> +   return -EFAULT;
>>> +   }
>>> +
>>> +   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>>> +
>>> +   /* put gem buffer */
>>> +   for_each_ipp_planar(i) {
>>> +   unsigned long handle = m_node->buf_info.handles[i];
>>> +   if (handle)
>>> +   exynos_drm_gem_put_dma_addr(drm_dev, handle,
>>> +   c_node->filp);
>>> +   }
>>> +
>>> +   /* conditionally remove from queue */
>>> +   if (m_node->list.next)
>> How about do INIT_LIST_HEAD for list in ipp_get_mem_node()?
> 
> I am not sure if it is better. For sure it adds unnecessary
> initialization sequence.

In other words, this NULL checking is unnecessary if you initialize the
list_head by INIT_LIST_HEAD.

> Maybe adding list_is_initialized inline function to list.h would be the
> best solution.

There is just list_empty and we can't know whether list is initialized
or not. I recommend to use initialized list_head.

Thanks.

> 
> Regards
> Andrzej
> 
>>
>>> +   list_del(_node->list);
>>> +   kfree(m_node);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  static struct drm_exynos_ipp_mem_node
>>> *ipp_get_mem_node(struct drm_device *drm_dev,
>>> struct drm_file *file,
>>> @@ -634,7 +665,8 @@ static struct drm_exynos_ipp_mem_node
>>> qbuf->handle[i], file);
>>> if (IS_ERR(addr)) {
>>> DRM_ERROR("failed to get addr.\n");
>>> -   goto err_clear;
>>> +   ipp_put_mem_node(drm_dev, c_node, m_node);
>>> +   return ERR_PTR(-EFAULT);
>>> }
>>>  
>>> buf_info->handles[i] = qbuf->handle[i];
>>> @@ -649,40 +681,6 @@ static struct drm_exynos_ipp_mem_node
>>> mutex_unlock(_node->mem_lock);
>>>  
>>> return m_node;
>>> -
>>> -err_clear:
>>> -   kfree(m_node);
>>> -   return ERR_PTR(-EFAULT);
>>> -}
>>> -
>>> -static int ipp_put_mem_node(struct drm_device *drm_dev,
>>> -   struct drm_exynos_ipp_cmd_node *c_node,
>>> -   struct drm_exynos_ipp_mem_node *m_node)
>>> -{
>>> -   int i;
>>> -
>>> -   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>>> -
>>> -   if (!m_node) {
>>> -   DRM_ERROR("invalid dequeue node.\n");
>>> -   return -EFAULT;
>>> -   }
>>> -
>>> -   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>>> -
>>> -   /* put gem buffer */
>>> -   for_each_ipp_planar(i) {
>>> -   unsigned long handle = m_node->buf_info.handles[i];
>>> -   if (handle)
>>> -   exynos_drm_gem_put_dma_addr(drm_dev, handle,
>>> -   c_node->filp);
>>> -   }
>>> -
>>> -   /* delete list in queue */
>>> -   list_del(_node->list);
>>> -   kfree(m_node);
>>> -
>>> -   return 0;
>>>  }
>>>  
>>>  static void ipp_free_event(struct drm_pending_event *event)
>>>
>>
> 
> 



[Bug 83184] New: Screen flickering at low resolution when monitor is attached via VGA dongle to DVI port

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83184

  Priority: medium
Bug ID: 83184
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Screen flickering at low resolution when monitor is
attached via VGA dongle to DVI port
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: Rainer.Koenig at ts.fujitsu.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 105377
  --> https://bugs.freedesktop.org/attachment.cgi?id=105377=edit
dmesg output with drm debug information

Encountered a strange problem with Radeon HD 6250 (or HD 6310) on a Fujitsu
D3003-S1x mainboard. Occurs with every tested linux distribution and older and
newer kernels. 

Problem occurs only when a monitor is attached via VGA to the DVI port. If the
monitor is attached via DVI then the problem does not occur.

Problem is that
- Monitor is flickering sporadically 
- Monitor resolution is fixed to 1024x768 instead of higher resolutions that
are possible
- xrandr shows 2 monitors while just one monitor is attached

Tried to debug this with kernel parameter drm.debug=14 (dmesg log is attached)
and found the following messages that would explain the flickering screen.

[4.098364] [drm:radeon_connector_analog_encoder_conflict_solve] 1:
conflicting encoders switching off DVI-I-1
[4.098369] [drm:radeon_connector_analog_encoder_conflict_solve] in favor of
VGA-1
[4.219817] [drm:radeon_connector_analog_encoder_conflict_solve] 1:
conflicting encoders switching off VGA-1
[4.219830] [drm:radeon_connector_analog_encoder_conflict_solve] in favor of
DVI-I-1
[4.231344] [drm:radeon_connector_analog_encoder_conflict_solve] 1:
conflicting encoders switching off DVI-I-1
[4.231350] [drm:radeon_connector_analog_encoder_conflict_solve] in favor of
VGA-1
[   13.949336] [drm:radeon_connector_analog_encoder_conflict_solve] 1:
conflicting encoders switching off VGA-1
[   13.949350] [drm:radeon_connector_analog_encoder_conflict_solve] in favor of
DVI-I-1
[   13.967886] [drm:radeon_connector_analog_encoder_conflict_solve] 1:
conflicting encoders switching off DVI-I-1
[   13.967891] [drm:radeon_connector_analog_encoder_conflict_solve] in favor of
VGA-1
[   14.023332] [drm:radeon_connector_analog_encoder_conflict_solve] 1:
conflicting encoders switching off VGA-1
[   14.023345] [drm:radeon_connector_analog_encoder_conflict_solve] in favor of
DVI-I-1
[   14.056688] [drm:radeon_connector_analog_encoder_conflict_solve] 1:
conflicting encoders switching off DVI-I-1
[   14.056694] [drm:radeon_connector_analog_encoder_conflict_solve] in favor of
VGA-1

The problem is still to find the root cause that leads to the issue of having
"conflicting encoders". Any idea what could cause this behaviour?

Regards
Rainer

-- 
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/20140828/1d362734/attachment-0001.html>


[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

2014-08-28 Thread Damien Lespiau
On Wed, Aug 27, 2014 at 03:11:08PM +0200, Thierry Reding wrote:
> > So we're left with
> > 
> >   #define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> > 
> > Vs
> > 
> >   #define DP_TRAIN_VOLTAGE_SWING_LEVEL(x) ((x) << 0)
> > 
> > The second variant doesn't really bring much more clarity? Can we just
> > go with the first?
> 
> I think the parameterized version is more convenient, especially if you
> want to use that during training sequences and iterate over the levels.

That's a fair point, but today's code manages to do without that nicety.

I think these kind of refinements could go in series with code actually
using them on top.

> But I don't feel too strongly about it, so either way is fine with me.

Thanks, taking some of your time to provide feedback is always
appreciated!

-- 
Damien


[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83148

Fabio Pedretti  changed:

   What|Removed |Added

   Hardware|x86-64 (AMD64)  |All
   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core

-- 
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/20140828/00d426a3/attachment.html>


[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82050

--- Comment #27 from Michel D?nzer  ---
(In reply to comment #26)
> No difference with those.

Bummer, thanks for testing anyway.

I submitted the change reverting the behaviour of PIPE_USAGE_STREAM for review,
but it's strange: I couldn't notice any significant difference in stutter in
Valley regardless of any of these changes.

BTW, what CPU are you using?

-- 
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/20140828/b4f7eff0/attachment.html>


[git pull] drm fixes

2014-08-28 Thread Dave Airlie

Hi Linus,

Nothing major, one core oops fixes, some radeon oops fixes, some sti 
driver fixups, msm driver fixes and a minor Kconfig update for the ww 
mutex debugging.

Dave.

The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:

  Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to b8d758d29fda0ece817237718909ed2622f024f1:

  drm/ast: Add missing entry to dclk_table[] (2014-08-28 12:26:42 +1000)


Alex Deucher (1):
  drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2)

Alex Williamson (1):
  radeon: Test for PCI root bus before assuming bus->self

Christian K?nig (1):
  drm/radeon: save/restore the PD addr on suspend/resume

Dave Airlie (3):
  Merge branch 'drm-fixes-3.17' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge branch 'msm-fixes-3.17' of 
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge branch 'drm-3.17-rc2-sti-fixes' of 
git://git.linaro.org/people/benjamin.gaignard/kernel into drm-fixes

David Herrmann (1):
  drm: fix division-by-zero on dumb_create()

Jingoo Han (1):
  drm: sti: Add missing dependency on RESET_CONTROLLER

Kiran Padwal (1):
  drm: sti: Make of_device_id array const

Rob Clark (4):
  drm/msm: avoid flood of kernel logs on faults
  drm/msm/mdp4: request vblank during modeset
  drm/msm: fix compile error for non-dt builds
  ww-mutex: clarify help text for DEBUG_WW_MUTEX_SLOWPATH

Wei Yongjun (5):
  drm: sti: tvout: fix return value check in sti_tvout_probe()
  drm: sti: hdmi: fix return value check in sti_hdmi_probe()
  drm: sti: hda: fix return value check in sti_hda_probe()
  drm: sti: Fix return value check in sti_drm_platform_probe()
  drm/msm: Fix missing unlock on error in msm_fbdev_create()

Y.C. Chen (1):
  drm/ast: Add missing entry to dclk_table[]

 drivers/gpu/drm/ast/ast_tables.h |  1 +
 drivers/gpu/drm/drm_crtc.c   |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c |  2 ++
 drivers/gpu/drm/msm/msm_drv.c|  3 +--
 drivers/gpu/drm/msm/msm_fbdev.c  |  2 +-
 drivers/gpu/drm/msm/msm_iommu.c  |  4 ++--
 drivers/gpu/drm/radeon/cik.c | 26 +++---
 drivers/gpu/drm/radeon/ni.c  |  9 -
 drivers/gpu/drm/radeon/r600.c| 26 --
 drivers/gpu/drm/radeon/radeon.h  |  2 ++
 drivers/gpu/drm/radeon/rv770.c   | 23 ---
 drivers/gpu/drm/radeon/si.c  | 21 ++---
 drivers/gpu/drm/sti/Kconfig  |  1 +
 drivers/gpu/drm/sti/sti_drm_drv.c|  4 ++--
 drivers/gpu/drm/sti/sti_hda.c| 10 +-
 drivers/gpu/drm/sti/sti_hdmi.c   | 10 +-
 drivers/gpu/drm/sti/sti_tvout.c  |  6 +++---
 lib/Kconfig.debug|  4 
 18 files changed, 92 insertions(+), 65 deletions(-)


[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83148

--- Comment #14 from smoki  ---
(In reply to comment #13)
> Created attachment 105365 [details] [review]
> u_vbuf: Make sure all caps are initialized
> 
> Does this patch help? I think caps.user_vertex_buffers being randomly 1
> could explain the symptoms.

 Yes, patch worked.

-- 
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/20140828/de7fd348/attachment.html>


[Bug 82455] Failed to allocate virtual address for buffer

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82455

--- Comment #27 from Michel D?nzer  ---
(In reply to comment #26)
>  Some place in mesa code you are still useing 4096 . 

Please be more specific. Do you still need the change you described in comment
17, or something else?


> libEGL debug: attribute 0x3033 has an invalid value 0x8
> libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in eglChooseConfig

Looks like maybe your Mesa build picked up a non-Mesa EGL/eglext.h which
doesn't pull in eglmesaext.h, so EGL_MESA_screen_surface isn't defined in
src/egl/main/eglconfig.c .

-- 
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/20140828/4d116329/attachment.html>


[Bug 82455] Failed to allocate virtual address for buffer

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82455

--- Comment #26 from charlie <407883775 at qq.com> ---
 Some place in mesa code you are still useing 4096 . 
 I am setting environment EGL_LOG_LEVEL=debug EGL_PLATFORM=drm R600_DEBUG=nodma
, and I am running egltri_screen.There havn't a tringle display in the
screen center. the message info as follow :

libEGL debug: Native platform type: drm (environment overwrite)
libEGL debug: EGL search path is /usr/lib64/egl
libEGL debug: added egl_dri2 to module array
libEGL debug: the best driver is DRI2
EGL_VERSION = 1.4 (DRI2)
libEGL debug: attribute 0x3033 has an invalid value 0x8
libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in eglChooseConfig

EGLUT: failed to choose a config

-- 
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/20140828/a79e3b75/attachment-0001.html>


[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83148

--- Comment #13 from Michel D?nzer  ---
Created attachment 105365
  --> https://bugs.freedesktop.org/attachment.cgi?id=105365=edit
u_vbuf: Make sure all caps are initialized

Does this patch help? I think caps.user_vertex_buffers being randomly 1 could
explain the symptoms.

-- 
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/20140828/7da40b4d/attachment.html>


[Bug 82918] [tahiti xt] dota2 crashes

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82918

--- Comment #13 from Michel D?nzer  ---
If you attach the output from R600_DEBUG=vs,gs,ps , we might be able to check
if current LLVM still chokes on 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/20140828/3420f7be/attachment.html>


[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

2014-08-28 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83148

Michel D?nzer  changed:

   What|Removed |Added

 CC||eric at anholt.net

--- Comment #12 from Michel D?nzer  ---
(In reply to comment #8)
> [...] problem started with http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=bbbe3b65adee44c164532d7afb4ff8fd8f88bbf4

Eric, any ideas? I haven't seen this myself yet, but several people have
bisected these problems to your commit above.

The only obvious semantic difference I can see before and after the patch is
that before it, all formats out of a group with at least one unsupported format
were converted, whereas after it, supported formats are always used directly,
even if some other related formats are not supported.

-- 
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/20140828/d7ddec57/attachment.html>