[PATCH 00/14] drm/exynos: rewrite fimg2d error handling

2015-08-27 Thread Tobias Jakobi
Hey Emil,


Emil Velikov wrote:
> Hi Tobias,
> 
> On 24 August 2015 at 15:13, Tobias Jakobi  
> wrote:
>> Hello,
>>
>> during the discussion about the last patchset touching the
>> fimg2d code, it became apparent that the error handling for
>> the command submission is currently unsatisfactory.
>>
>> This series rewrites the handling. All functions that submit
>> command buffers now first check if enough space is available
>> and only then proceed to build the command buffers.
>>
>> In particular the command buffer is no longer left in a
>> half-finished state, since parameters passed to the functions
>> are now validated before command submission. For this some
>> validation functions are introduced.
>>
>> This should also increase performance if the bottleneck is
>> the submission part, since adding commands to the buffer
>> is now more lightweight.
>>
>> Last but not least some prefix was added to messages printed
>> by fprintf and printf, and the G2D context struct was moved
>> out of the public header.
>>
>>
> Thanks for going with my earlier suggestion and untangling all this.
> 
> I've went through the lot and it looks great afaict. Fwiw for the series
> Reviewed-by: Emil Velikov 
thanks for the review and the help on IRC!


> As pretty much none of this is hardware specific and/or requires
> additional knowledge of the kernel module I'm inclined to pull this in
> even if we don't get too many reviewers. We better keep it around for
> a couple of weeks in case others are swamped with unrelated work atm,
> yet willing to take a look.
Sure, I'm going to wait and do some pings from time to time :)


With best wishes,
Tobias

> 
> Cheers,
> Emil
> 



[Bug 91641] white cursor with planetary annihilation

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91641

Alex Deucher  changed:

   What|Removed |Added

 Resolution|FIXED   |NOTOURBUG

-- 
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/20150827/c15baf58/attachment-0001.html>


[Bug 91775] Wrong openGL version

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91775

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #5 from Alex Deucher  ---
You need mesa built against llvm 3.7 for OGL 4.1.  I don't think oibaf uses
llvm 3.7.

-- 
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/20150827/9cd6fc79/attachment.html>


[Bug 91775] Wrong openGL version

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91775

--- Comment #4 from 19.jaime.91 at gmail.com ---
My card is Cape Verde Radeon HD 7760. I'm using oibaf drivers(git)

-- 
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/20150827/b4404efb/attachment.html>


[Bug 91775] Wrong openGL version

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91775

19.jaime.91 at gmail.com changed:

   What|Removed |Added

 Attachment #117953|Output  |dmesg
description||

-- 
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/20150827/0b4af7fe/attachment.html>


[Bug 91775] Wrong openGL version

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91775

--- Comment #3 from 19.jaime.91 at gmail.com ---
Created attachment 117954
  --> https://bugs.freedesktop.org/attachment.cgi?id=117954=edit
xorg

-- 
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/20150827/0ec918da/attachment.html>


[Bug 91775] Wrong openGL version

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91775

--- Comment #2 from 19.jaime.91 at gmail.com ---
Created attachment 117953
  --> https://bugs.freedesktop.org/attachment.cgi?id=117953=edit
Output

Now I'm with the privatives, but I attach anyway.

-- 
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/20150827/47338f37/attachment.html>


[Bug 91641] white cursor with planetary annihilation

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91641

kdj0c at djinvi.net changed:

   What|Removed |Added

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

--- Comment #8 from kdj0c at djinvi.net ---
Fixed in latest Planetary Annihilation update.

release note include :

"Fix some cursors on certain Linux drivers"

http://steamcommunity.com/games/233250/announcements/detail/125327186128569099

-- 
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/20150827/50fa6777/attachment.html>


[Bug 91780] Rendering issues with geometry shader

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91780

--- Comment #4 from Jonas Wielicki  ---
(In reply to Dieter Nützel from comment #2)
> Can you please try with
> 
> R600_DEBUG=nosb

Yes, I tried that (should have mentioned it, sorry) and it shows the problem.

> And maybe test Mesa-demo 'gsraytrace'?

Will try that later.

-- 
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/20150827/50b203f8/attachment.html>


[Bug 91780] Rendering issues with geometry shader

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91780

--- Comment #3 from Glenn Kennard  ---
Dieter, those are unrelated to this issue, which appears to be something
specific to GL_LINES_ADJACENCY primitive type.

The piglit test glsl-1.50-geometry-primitive-types GL_TRIANGLE_STRIP_ADJACENCY
fails which might be related, but curiously the lines adjacency types pass.

-- 
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/20150827/df8891e1/attachment-0001.html>


[Bug 91780] Rendering issues with geometry shader

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91780

--- Comment #2 from Dieter Nützel  ---
Can you please try with

R600_DEBUG=nosb

And maybe test Mesa-demo 'gsraytrace'?

I got several geometry shader glitches/crashes on Turks, here.
Bugs are open:
https://bugs.freedesktop.org/show_bug.cgi?id=83319
https://bugs.freedesktop.org/show_bug.cgi?id=91503

-- 
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/20150827/b0ebd2ec/attachment.html>


[Bug 91780] Rendering issues with geometry shader

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91780

--- Comment #1 from Jonas Wielicki  ---
Created attachment 117952
  --> https://bugs.freedesktop.org/attachment.cgi?id=117952=edit
screenshot of the problem

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


[Bug 91780] Rendering issues with geometry shader

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91780

Bug ID: 91780
   Summary: Rendering issues with geometry shader
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: jonas at wielicki.name
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 117951
  --> https://bugs.freedesktop.org/attachment.cgi?id=117951=edit
apitrace which shows the problem

In the attached apitrace, *sometimes* (about 50% of the runs) rendering issues
can be observed. They manifest in appearantly missing geometry (compare
attached screenshot; the UI has been disabled for taking the apitrace).

Steps to reproduce:
1. DRI_PRIME=1 apitrace replay r600-renderbug-noui.trace
2. If step 1 did not show the behaviour, retry a few times.

Expected results:
Rendering should work and show a terrain without holes

Actual results:
Holes in the terrain

The results have been observed on mesa-11.0.0-rc1 with and without
http://lists.freedesktop.org/archives/mesa-dev/2015-August/092766.html applied.

The same code has never (in 50+ tests) shown the issue on the Intel integrated
GPU.

The application which produces the given behaviour can be found at 
https://github.com/horazont/scc/tree/f31d90e1579ebda14ce7a0417339b2cd448efde8

The geometry shader is in:
https://github.com/horazont/scc/blob/f31d90e1579ebda14ce7a0417339b2cd448efde8/game/resources/shaders/terrain/main.geom

The usage is in:
https://github.com/horazont/scc/blob/f31d90e1579ebda14ce7a0417339b2cd448efde8/libffengine-render/src/render/fancyterrain.cpp
(search for draw_elements, GL_GEOMETRY_SHADER, GL_LINES_ADJACENCY)


In another commit, the geometry shader has been disabled
(<https://github.com/horazont/scc/commit/4e1e298b02723efcf6555c1c4a7efa31682cf79b>),
which appears to fix the problem or make it very hard to reproduce.


radeon GPU:
Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD
6630M/6650M/6750M/7670M/7690M] (rev ff)  {6630M according to notebook specs}
intel GPU:
Intel Corporation 2nd Generation Core Processor Family Integrated Graphics
Controller (rev 09)

-- 
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/20150827/b79810b9/attachment.html>


drm/exynos: g2d userptr memory corruption

2015-08-27 Thread Tobias Jakobi
Tobias Jakobi wrote:
> Next I looked into Jerome's question about whethere the G2D is
> cache coherent with the CPU. I looked into old Android code and
> found FIMG2D_AXI_MODE_REG, a register that currently isn't
> touched in the DRM code.
> It seems to manipulate signals to the AXI Master interface.
> 
> The register looks like this:
> [0:3] ARCACHE
> [4:7] AWCACHE
> [8:15] ARUSERS
> [16:23] AWUSERS
> [24:25] MaxBurstLength
Correction, it looks like this:
[0:3] ARCACHE
[4:7] AWCACHE
[8:12] ARUSERS
[16:20] AWUSERS
[24:25] MaxBurstLength
(the rest of the bits are reserved)

With best wishes,
Tobias



[PATCH 1/1] signals: kill block_all_signals() and unblock_all_signals()

2015-08-27 Thread Oleg Nesterov
It is hardly possible to enumerate all problems with block_all_signals()
and unblock_all_signals(). Just for example,

1. block_all_signals(SIGSTOP/etc) simply can't help if the caller is
   multithreaded. Another thread can dequeue the signal and force the
   group stop.

2. Even is the caller is single-threaded, it will "stop" anyway. It
   will not sleep, but it will spin in kernel space until SIGCONT or
   SIGKILL.

And a lot more. In short, this interface doesn't work at all, at least
the last 10+ years.

Signed-off-by: Oleg Nesterov 
---
 drivers/gpu/drm/drm_lock.c |   41 ---
 include/drm/drmP.h |1 -
 include/linux/sched.h  |7 +-
 kernel/signal.c|   51 +---
 4 files changed, 2 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index f861361..4477b87 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -38,8 +38,6 @@
 #include "drm_legacy.h"
 #include "drm_internal.h"

-static int drm_notifier(void *priv);
-
 static int drm_lock_take(struct drm_lock_data *lock_data, unsigned int 
context);

 /**
@@ -115,14 +113,8 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
 * really probably not the correct answer but lets us debug xkb
 * xserver for now */
if (!file_priv->is_master) {
-   sigemptyset(>sigmask);
-   sigaddset(>sigmask, SIGSTOP);
-   sigaddset(>sigmask, SIGTSTP);
-   sigaddset(>sigmask, SIGTTIN);
-   sigaddset(>sigmask, SIGTTOU);
dev->sigdata.context = lock->context;
dev->sigdata.lock = master->lock.hw_lock;
-   block_all_signals(drm_notifier, dev, >sigmask);
}

if (dev->driver->dma_quiescent && (lock->flags & _DRM_LOCK_QUIESCENT))
@@ -163,7 +155,6 @@ int drm_legacy_unlock(struct drm_device *dev, void *data, 
struct drm_file *file_
/* FIXME: Should really bail out here. */
}

-   unblock_all_signals();
return 0;
 }

@@ -282,38 +273,6 @@ int drm_legacy_lock_free(struct drm_lock_data *lock_data, 
unsigned int context)
 }

 /**
- * If we get here, it means that the process has called DRM_IOCTL_LOCK
- * without calling DRM_IOCTL_UNLOCK.
- *
- * If the lock is not held, then let the signal proceed as usual.  If the lock
- * is held, then set the contended flag and keep the signal blocked.
- *
- * \param priv pointer to a drm_device structure.
- * \return one if the signal should be delivered normally, or zero if the
- * signal should be blocked.
- */
-static int drm_notifier(void *priv)
-{
-   struct drm_device *dev = priv;
-   struct drm_hw_lock *lock = dev->sigdata.lock;
-   unsigned int old, new, prev;
-
-   /* Allow signal delivery if lock isn't held */
-   if (!lock || !_DRM_LOCK_IS_HELD(lock->lock)
-   || _DRM_LOCKING_CONTEXT(lock->lock) != dev->sigdata.context)
-   return 1;
-
-   /* Otherwise, set flag to force call to
-  drmUnlock */
-   do {
-   old = lock->lock;
-   new = old | _DRM_LOCK_CONT;
-   prev = cmpxchg(>lock, old, new);
-   } while (prev != old);
-   return 0;
-}
-
-/**
  * This function returns immediately and takes the hw lock
  * with the kernel context if it is free, otherwise it gets the highest 
priority when and if
  * it is eventually released.
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 62c4077..0859c35 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -815,7 +815,6 @@ struct drm_device {

struct drm_sg_mem *sg;  /**< Scatter gather memory */
unsigned int num_crtcs;  /**< Number of CRTCs on this 
device */
-   sigset_t sigmask;

struct {
int context;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 26a2e61..f192cfe 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1489,9 +1489,7 @@ struct task_struct {

unsigned long sas_ss_sp;
size_t sas_ss_size;
-   int (*notifier)(void *priv);
-   void *notifier_data;
-   sigset_t *notifier_mask;
+
struct callback_head *task_works;

struct audit_context *audit_context;
@@ -2382,9 +2380,6 @@ static inline int dequeue_signal_lock(struct task_struct 
*tsk, sigset_t *mask, s
return ret;
 }

-extern void block_all_signals(int (*notifier)(void *priv), void *priv,
- sigset_t *mask);
-extern void unblock_all_signals(void);
 extern void release_task(struct task_struct * p);
 extern int send_sig_info(int, struct siginfo *, struct task_struct *);
 extern int force_sigsegv(int, struct task_struct *);
diff --git a/kernel/signal.c b/kernel/signal.c
index d51c5dd..a5f4f85 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -508,41 +508,6 @@ int unhandled_signal(struct task_struct *tsk, int 

[PATCH 0/1] signals: kill block_all_signals() and unblock_all_signals()

2015-08-27 Thread Oleg Nesterov
On 05/26, Dave Airlie wrote:
>
> On 26 May 2015 at 02:50, Oleg Nesterov  wrote:
> > On 05/25, Richard Weinberger wrote:
> >>
> >> Is this functionality still in use/needed?
> >
> > All I can say it doesn't work.
> >
> >> Otherwise we could get rid of block_all_signals() and unpuzzle the 
> >> signaling
> >> code a bit. :-)
> >
> > Yes. I do not even remember when I reported this the first time. Perhaps
> > more than 10 years ago.
> >
> > See the last attempt in 2011: https://lkml.org/lkml/2011/7/12/263
> > I copied this email below.
> >
> > Dave. Lets finally kill this horror? I am going to send a patch unless
> > you stop me ;)
>
> There were follow up on that thread 4 years ago, but we are probably
> at the stage where this thing can die,

Heh.

I tried to kill this horror so many years, and forgot to send the patch
after you finally blessed it ;)

Could you please review?

> I suspect any hw using it has died out, and any new hardware won't be
> doing evil things with drm locks

even if it does, let me repeat that block_all_signals() simply do not
work. At all. if ->notifier() returns 0, this thread will burn CPU until
SIGCONT or SIGKILL. Or it will stop anyway if multi-threaded.

Oleg.



[PATCH 00/14] drm/exynos: rewrite fimg2d error handling

2015-08-27 Thread Emil Velikov
Hi Tobias,

On 24 August 2015 at 15:13, Tobias Jakobi  
wrote:
> Hello,
>
> during the discussion about the last patchset touching the
> fimg2d code, it became apparent that the error handling for
> the command submission is currently unsatisfactory.
>
> This series rewrites the handling. All functions that submit
> command buffers now first check if enough space is available
> and only then proceed to build the command buffers.
>
> In particular the command buffer is no longer left in a
> half-finished state, since parameters passed to the functions
> are now validated before command submission. For this some
> validation functions are introduced.
>
> This should also increase performance if the bottleneck is
> the submission part, since adding commands to the buffer
> is now more lightweight.
>
> Last but not least some prefix was added to messages printed
> by fprintf and printf, and the G2D context struct was moved
> out of the public header.
>
>
Thanks for going with my earlier suggestion and untangling all this.

I've went through the lot and it looks great afaict. Fwiw for the series
Reviewed-by: Emil Velikov 

As pretty much none of this is hardware specific and/or requires
additional knowledge of the kernel module I'm inclined to pull this in
even if we don't get too many reviewers. We better keep it around for
a couple of weeks in case others are swamped with unrelated work atm,
yet willing to take a look.

Cheers,
Emil


[PATCH v2] drm/exynos: implement atomic_{begin/flush} of DECON

2015-08-27 Thread Hyungwon Hwang
Each CRTC's atomic_{begin/flush} must stop/start the update of shadow
registers to active register in the functions. This patch achieves these
purpose by moving the setting of protection bits to those functions from
decon_update_plane.

v2: rebased to the branch exynos-drm-next

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 34 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 30 ++-
 2 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 8d65e45..f24dc2d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -219,6 +219,17 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx, int win,
writel(val, ctx->addr + DECON_SHADOWCON);
 }

+static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->suspended)
+   return;
+
+   decon_shadow_protect_win(ctx, plane->zpos, true);
+}
+
 static void decon_update_plane(struct exynos_drm_crtc *crtc,
   struct exynos_drm_plane *plane)
 {
@@ -232,8 +243,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, win, true);
-
val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
writel(val, ctx->addr + DECON_VIDOSDxA(win));

@@ -265,15 +274,10 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
val |= WINCONx_ENWIN_F;
writel(val, ctx->addr + DECON_WINCONx(win));

-   decon_shadow_protect_win(ctx, win, false);
-
/* standalone update */
val = readl(ctx->addr + DECON_UPDATE);
val |= STANDALONE_UPDATE_F;
writel(val, ctx->addr + DECON_UPDATE);
-
-   if (ctx->i80_if)
-   atomic_set(>win_updated, 1);
 }

 static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -301,6 +305,20 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
writel(val, ctx->addr + DECON_UPDATE);
 }

+static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->suspended)
+   return;
+
+   decon_shadow_protect_win(ctx, plane->zpos, false);
+
+   if (ctx->i80_if)
+   atomic_set(>win_updated, 1);
+}
+
 static void decon_swreset(struct decon_context *ctx)
 {
unsigned int tries;
@@ -455,8 +473,10 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable_vblank  = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.commit = decon_commit,
+   .atomic_begin   = decon_atomic_begin,
.update_plane   = decon_update_plane,
.disable_plane  = decon_disable_plane,
+   .atomic_flush   = decon_atomic_flush,
.te_handler = decon_te_irq_handler,
 };

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 7651499..c74e30e 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -383,6 +383,17 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx,
writel(val, ctx->regs + SHADOWCON);
 }

+static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->suspended)
+   return;
+
+   decon_shadow_protect_win(ctx, plane->zpos, true);
+}
+
 static void decon_update_plane(struct exynos_drm_crtc *crtc,
   struct exynos_drm_plane *plane)
 {
@@ -410,9 +421,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
 * is set.
 */

-   /* protect windows */
-   decon_shadow_protect_win(ctx, win, true);
-
/* buffer start address */
val = (unsigned long)plane->dma_addr[0];
writel(val, ctx->regs + VIDW_BUF_START(win));
@@ -510,14 +518,22 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
val &= ~WINCONx_ENWIN;
writel(val, ctx->regs + WINCON(win));

-   /* unprotect windows */
-   decon_shadow_protect_win(ctx, win, false);
-
val = readl(ctx->regs + DECON_UPDATE);
val |= DECON_UPDATE_STANDALONE_F;
writel(val, ctx->regs + DECON_UPDATE);
 }

+static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if 

[Bug 91778] white screen in unigine tropics and sanctuary with 11RC1

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91778

Bug ID: 91778
   Summary: white screen in unigine tropics and sanctuary with
11RC1
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: 375gnu at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 117949
  --> https://bugs.freedesktop.org/attachment.cgi?id=117949=edit
stdout+stderr combined from tropics

After upgrade to mesa 11RC1 with llvm 3.7RC3 unigine tropics and sanctuary show
only blank white screen instead of 3d scene (buttons, fps counter and logo are
shown).

Stderr is full of messages like 

GLShader::loadFragment(): error in "core/shaders/render/fragment_fade.shader"
file
defines:
UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_SAMPLE_SHADING,USE_ARB_TEXTURE_MULTISAMPLE,HAS_ARB_DRAW_INSTANCED
0:129(7): error: syntax error, unexpected SAMPLE, expecting ',' or ';'

It was fine with mesa 10.6.3 and llvm 3.5.

My HW is radeon 7750, so I'm using radeonsi.

-- 
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/20150827/1b7369de/attachment-0001.html>


[PATCH] drm/exynos: implement {prepare/cleanup}_plane of DECON

2015-08-27 Thread Hyungwon Hwang
Each CRTC's {prepare/cleanup}_plane must stop/start the update of shadow
registers to active register in the functions. This patch achieves these
purpose by moving the setting of protection bits to those functions from
decon_update_plane.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 34 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 30 ++-
 2 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 8d65e45..bd465ac 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -219,6 +219,17 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx, int win,
writel(val, ctx->addr + DECON_SHADOWCON);
 }

+static void decon_prepare_plane(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->suspended)
+   return;
+
+   decon_shadow_protect_win(ctx, plane->zpos, true);
+}
+
 static void decon_update_plane(struct exynos_drm_crtc *crtc,
   struct exynos_drm_plane *plane)
 {
@@ -232,8 +243,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, win, true);
-
val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
writel(val, ctx->addr + DECON_VIDOSDxA(win));

@@ -265,15 +274,10 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
val |= WINCONx_ENWIN_F;
writel(val, ctx->addr + DECON_WINCONx(win));

-   decon_shadow_protect_win(ctx, win, false);
-
/* standalone update */
val = readl(ctx->addr + DECON_UPDATE);
val |= STANDALONE_UPDATE_F;
writel(val, ctx->addr + DECON_UPDATE);
-
-   if (ctx->i80_if)
-   atomic_set(>win_updated, 1);
 }

 static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -301,6 +305,20 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
writel(val, ctx->addr + DECON_UPDATE);
 }

+static void decon_cleanup_plane(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->suspended)
+   return;
+
+   decon_shadow_protect_win(ctx, plane->zpos, false);
+
+   if (ctx->i80_if)
+   atomic_set(>win_updated, 1);
+}
+
 static void decon_swreset(struct decon_context *ctx)
 {
unsigned int tries;
@@ -455,8 +473,10 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable_vblank  = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.commit = decon_commit,
+   .prepare_plane  = decon_prepare_plane,
.update_plane   = decon_update_plane,
.disable_plane  = decon_disable_plane,
+   .cleanup_plane  = decon_cleanup_plane,
.te_handler = decon_te_irq_handler,
 };

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 7651499..d0edc56 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -383,6 +383,17 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx,
writel(val, ctx->regs + SHADOWCON);
 }

+static void decon_prepare_plane(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->suspended)
+   return;
+
+   decon_shadow_protect_win(ctx, plane->zpos, true);
+}
+
 static void decon_update_plane(struct exynos_drm_crtc *crtc,
   struct exynos_drm_plane *plane)
 {
@@ -410,9 +421,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
 * is set.
 */

-   /* protect windows */
-   decon_shadow_protect_win(ctx, win, true);
-
/* buffer start address */
val = (unsigned long)plane->dma_addr[0];
writel(val, ctx->regs + VIDW_BUF_START(win));
@@ -510,14 +518,22 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
val &= ~WINCONx_ENWIN;
writel(val, ctx->regs + WINCON(win));

-   /* unprotect windows */
-   decon_shadow_protect_win(ctx, win, false);
-
val = readl(ctx->regs + DECON_UPDATE);
val |= DECON_UPDATE_STANDALONE_F;
writel(val, ctx->regs + DECON_UPDATE);
 }

+static void decon_cleanup_plane(struct exynos_drm_crtc *crtc,
+   struct exynos_drm_plane *plane)
+{
+   struct decon_context *ctx = crtc->ctx;
+
+   if (ctx->suspended)
+   

[PATCH v2 0/6] drm/dp: i2c-over-aux short write support

2015-08-27 Thread Ville Syrjälä
On Thu, Aug 27, 2015 at 05:34:45PM +0300, Jani Nikula wrote:
> On Thu, 27 Aug 2015, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > I found these lying around in a branch. Most have r-b or ack from last time
> > [1] (the tegra patch doesn't). I also included the radeon 20bit AUX address
> > fix that seems to have fallen through the cracks as well.
> >
> > I rebased these on top of my i2c-over-aux retry count series [2] since that
> > fixes a regression and so it's more urgent to get in.
> 
> How about pushing both to a branch on some repo, and throwing them at
> some of the bugs we have open?

Pushed the lot to: git://github.com/vsyrjala/linux.git i2c_aux_short_write_4

It's sitting top of drm-intel-nightly from a few days ago.

> 
> BR,
> Jani.
> 
> >
> > [1] http://lists.freedesktop.org/archives/dri-devel/2015-March/079254.html
> > [2] http://lists.freedesktop.org/archives/dri-devel/2015-August/089250.html
> >
> > Ville Syrjälä (6):
> >   drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/
> >   drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
> >   drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
> >   drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
> >   drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE
> > requests
> >   drm/radeon: Send out the full AUX address
> >
> >  drivers/gpu/drm/drm_dp_helper.c  | 43 
> > 
> >  drivers/gpu/drm/i915/intel_dp.c  |  1 +
> >  drivers/gpu/drm/radeon/atombios_dp.c |  6 +++--
> >  drivers/gpu/drm/tegra/dpaux.c|  3 ++-
> >  include/drm/drm_dp_helper.h  |  2 +-
> >  5 files changed, 47 insertions(+), 8 deletions(-)
> >
> > -- 
> > 2.4.6
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Ville Syrjälä
Intel OTC


[PATCH 1/6] drm: prime: Honour O_RDWR during prime-handle-to-fd

2015-08-27 Thread Emil Velikov
Hi all,

On 27 August 2015 at 00:29, Tiago Vignatti  wrote:
> From: Daniel Thompson 
>
> Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
> (DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
> to mmap() the resulting dma-buf even when this is supported by the
> DRM driver.
>
> It is trivial to relax the restriction and permit read/write access.
> This is safe because the flags are seldom touched by drm; mostly they
> are passed verbatim to dma_buf calls.
>
Strictly speaking shouldn't this patch be the last one in the series ?
I.e. we should lift this restriction, after the sync method
(ioctl/syscall/etc.) is in place. Or perhaps I missed something ?

Thanks
Emil


[PATCH v2 0/6] drm/dp: i2c-over-aux short write support

2015-08-27 Thread Jani Nikula
On Thu, 27 Aug 2015, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> I found these lying around in a branch. Most have r-b or ack from last time
> [1] (the tegra patch doesn't). I also included the radeon 20bit AUX address
> fix that seems to have fallen through the cracks as well.
>
> I rebased these on top of my i2c-over-aux retry count series [2] since that
> fixes a regression and so it's more urgent to get in.

How about pushing both to a branch on some repo, and throwing them at
some of the bugs we have open?

BR,
Jani.

>
> [1] http://lists.freedesktop.org/archives/dri-devel/2015-March/079254.html
> [2] http://lists.freedesktop.org/archives/dri-devel/2015-August/089250.html
>
> Ville Syrjälä (6):
>   drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/
>   drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
>   drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
>   drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
>   drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE
> requests
>   drm/radeon: Send out the full AUX address
>
>  drivers/gpu/drm/drm_dp_helper.c  | 43 
> 
>  drivers/gpu/drm/i915/intel_dp.c  |  1 +
>  drivers/gpu/drm/radeon/atombios_dp.c |  6 +++--
>  drivers/gpu/drm/tegra/dpaux.c|  3 ++-
>  include/drm/drm_dp_helper.h  |  2 +-
>  5 files changed, 47 insertions(+), 8 deletions(-)
>
> -- 
> 2.4.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Ville Syrjälä
On Thu, Aug 27, 2015 at 03:28:53PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 27 August 2015 at 15:09, Ville Syrjälä  linux.intel.com> wrote:
> > On Thu, Aug 27, 2015 at 04:00:05PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 15:50 schreef Ville Syrjälä:
> >> > I don't think so. Speaking for i915, I think we've just rejected legacy 
> >> > page
> >> > flips entirely with the pipe is off on account of drm_vblank_get() 
> >> > failing.
> >> No atomic driver handles this case correctly. You can't get vblank events 
> >> with the crtc off.
> >
> > I don't understand what you're saying. Should there be a comma after
> > "No" ? If not, then I'm not sure what they don't handle.
> 
> I think you're arguing over the definition of 'correctly' perhaps?
> 
> >> >> I don't see why this should be relaxed. It just complicates things and 
> >> >> you have nothing to stick in for the vblank counter.
> >> > We could stick the last vbl count/timestamp in there.
> >> >
> >> > Not allowing means userspace is forced to consider the dpms state
> >> > whenever it wants to call the atomic ioctl.
> >> Userspace was the one turning off the crtc in the first place; it 
> >> shouldn't continue flipping but preserve power. :-)
> >
> > Meh. Much simpler to write code when you don't have to worry about such
> > details.
> >
> > In the kernel it should amount to
> > if (!pipe_active)
> > send_event
> 
> No, thankyou. Asking for an event, having the request succeed, and
> never getting an event, is a deathtrap.

Obviously the event gets sent if the operation succeeds. I never
suggested anything else.

> PAGE_FLIP_EVENT should mean
> that either an event gets delivered for every CRTC in crtc_state, or
> the request getting rejected. Nothing else.
> 
> > We anyway need something like that for the crtc getting disabled case,
> > don't we?
> 
> Yes, which I was getting at previously. We know when the CRTC gets
> disabled - we have to, in order to sensibly unpin etc - so that's when
> the event gets sent.
> 
> Cheers,
> Daniel

-- 
Ville Syrjälä
Intel OTC


[PATCH] drm/exynos: fix exynos_drm_gem_prime_import_sg_table() error handling

2015-08-27 Thread Joonyoung Shim
If exynos_drm_gem_init() is failed, the result is ERR_PTR, so we should
just return the result. If not, wrong porinter will be referenced from
err label.

Reported-by: Dan Carpenter 
Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 3e4a64a..4842a31 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -569,10 +569,8 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device 
*dev,
int ret;

exynos_gem_obj = exynos_drm_gem_init(dev, attach->dmabuf->size);
-   if (IS_ERR(exynos_gem_obj)) {
-   ret = PTR_ERR(exynos_gem_obj);
-   goto err;
-   }
+   if (IS_ERR(exynos_gem_obj))
+   return exynos_gem_obj;

exynos_gem_obj->dma_addr = sg_dma_address(sgt->sgl);

-- 
1.9.1



[PATCH 6/6] drm/radeon: Send out the full AUX address

2015-08-27 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index ca372c5..bd73b40 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -171,8 +171,9 @@ radeon_dp_aux_transfer_atom(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
return -E2BIG;

tx_buf[0] = msg->address & 0xff;
-   tx_buf[1] = msg->address >> 8;
-   tx_buf[2] = msg->request << 4;
+   tx_buf[1] = (msg->address >> 8) & 0xff;
+   tx_buf[2] = (msg->request << 4) |
+   ((msg->address >> 16) & 0xf);
tx_buf[3] = msg->size ? (msg->size - 1) : 0;

switch (msg->request & ~DP_AUX_I2C_MOT) {
-- 
2.4.6



[PATCH 5/6] drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests

2015-08-27 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
when we continue to poll for the completion of the request.

v2: Don't assume DP_AUX_I2C_WRITE is 0 even though it is, to make the
code more obvious to the casual reader (Jani)

Acked-by: Alex Deucher 
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_helper.c | 43 +
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ee5cd86..a717f4c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -496,6 +496,27 @@ static int drm_dp_i2c_retry_count(const struct 
drm_dp_aux_msg *msg,
return DIV_ROUND_UP(i2c_len, aux_len + AUX_RETRY_INTERVAL);
 }

+static void drm_dp_i2c_msg_set_request(struct drm_dp_aux_msg *msg,
+  const struct i2c_msg *i2c_msg)
+{
+   msg->request = (i2c_msg->flags & I2C_M_RD) ?
+   DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
+   msg->request |= DP_AUX_I2C_MOT;
+}
+
+static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
+{
+   /*
+* In case of i2c defer or short i2c ack reply to a write,
+* we need to switch to WRITE_STATUS_UPDATE to drain the
+* rest of the message
+*/
+   if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
+   msg->request &= DP_AUX_I2C_MOT;
+   msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
+   }
+}
+
 /*
  * FIXME currently assumes 10 kHz as some real world devices seem
  * to require it. We should query/set the speed via DPCD if supported.
@@ -576,6 +597,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
 * Both native ACK and I2C ACK replies received. We
 * can assume the transfer was successful.
 */
+   if (ret != msg->size)
+   drm_dp_i2c_msg_write_status_update(msg);
return ret;

case DP_AUX_I2C_REPLY_NACK:
@@ -593,6 +616,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (defer_i2c < 7)
defer_i2c++;
usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 
100);
+   drm_dp_i2c_msg_write_status_update(msg);
continue;

default:
@@ -658,10 +682,7 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,

for (i = 0; i < num; i++) {
msg.address = msgs[i].addr;
-   msg.request = (msgs[i].flags & I2C_M_RD) ?
-   DP_AUX_I2C_READ :
-   DP_AUX_I2C_WRITE;
-   msg.request |= DP_AUX_I2C_MOT;
+   drm_dp_i2c_msg_set_request(, [i]);
/* Send a bare address packet to start the transaction.
 * Zero sized messages specify an address only (bare
 * address) transaction.
@@ -669,6 +690,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
msg.buffer = NULL;
msg.size = 0;
err = drm_dp_i2c_do_msg(aux, );
+
+   /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+   drm_dp_i2c_msg_set_request(, [i]);
+
if (err < 0)
break;
/* We want each transaction to be as large as possible, but
@@ -681,6 +709,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
msg.size = min(transfer_size, msgs[i].len - j);

err = drm_dp_i2c_drain_msg(aux, );
+
+   /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+   drm_dp_i2c_msg_set_request(, [i]);
+
if (err < 0)
break;
transfer_size = err;
-- 
2.4.6



[PATCH 4/6] drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes

2015-08-27 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

A address-only I2C_WRITE can't be replied with a short i2c ack, but I
suppose it could be replied with an i2c defer. So the code should be
prepared for an address-only I2C_WRITE_STATUS_UPDATE.

Cc: Thierry Reding 
Cc: "Terje Bergström" 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/tegra/dpaux.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 1cc09ff..6aecb66 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -119,6 +119,7 @@ static ssize_t tegra_dpaux_transfer(struct drm_dp_aux *aux,
 */
if (msg->size < 1) {
switch (msg->request & ~DP_AUX_I2C_MOT) {
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
case DP_AUX_I2C_WRITE:
case DP_AUX_I2C_READ:
value = DPAUX_DP_AUXCTL_CMD_ADDRESS_ONLY;
-- 
2.4.6



[PATCH 3/6] drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE

2015-08-27 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.

Looks like radeon doesn't do anything special with the request type,
so hopefully just treating it the same as a i2c write is enough.

Cc: Alex Deucher 
Cc: "Christian König" 
Acked-by: Alex Deucher 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index f81e0d7..ca372c5 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -178,6 +178,7 @@ radeon_dp_aux_transfer_atom(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
/* The atom implementation only supports writes with a max 
payload of
 * 12 bytes since it uses 4 bits for the total count (header + 
payload)
 * in the parameter space.  The atom interface supports 16 byte
-- 
2.4.6



[PATCH 2/6] drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE

2015-08-27 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.

i915 doesn't try to interpret wht request type apart from separating
reads from writes, and so we should be able to treat this the same as
a normal i2c write.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..acd01da 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -974,6 +974,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
txsize = msg->size ? HEADER_SIZE + msg->size : 
BARE_ADDRESS_SIZE;
rxsize = 2; /* 0 or 1 data bytes */

-- 
2.4.6



[PATCH 1/6] drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/

2015-08-27 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the
spec.

Acked-by: Alex Deucher 
Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/tegra/dpaux.c | 2 +-
 include/drm/drm_dp_helper.h   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 224a7dc..1cc09ff 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -149,7 +149,7 @@ static ssize_t tegra_dpaux_transfer(struct drm_dp_aux *aux,

break;

-   case DP_AUX_I2C_STATUS:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
if (msg->request & DP_AUX_I2C_MOT)
value |= DPAUX_DP_AUXCTL_CMD_MOT_RQ;
else
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 499e9f6..d0c8810 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -46,7 +46,7 @@

 #define DP_AUX_I2C_WRITE   0x0
 #define DP_AUX_I2C_READ0x1
-#define DP_AUX_I2C_STATUS  0x2
+#define DP_AUX_I2C_WRITE_STATUS_UPDATE 0x2
 #define DP_AUX_I2C_MOT 0x4
 #define DP_AUX_NATIVE_WRITE0x8
 #define DP_AUX_NATIVE_READ 0x9
-- 
2.4.6



[PATCH v2 0/6] drm/dp: i2c-over-aux short write support

2015-08-27 Thread ville.syrj...@linux.intel.com
From: Ville Syrjälä 

I found these lying around in a branch. Most have r-b or ack from last time
[1] (the tegra patch doesn't). I also included the radeon 20bit AUX address
fix that seems to have fallen through the cracks as well.

I rebased these on top of my i2c-over-aux retry count series [2] since that
fixes a regression and so it's more urgent to get in.

[1] http://lists.freedesktop.org/archives/dri-devel/2015-March/079254.html
[2] http://lists.freedesktop.org/archives/dri-devel/2015-August/089250.html

Ville Syrjälä (6):
  drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/
  drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
  drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
  drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
  drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE
requests
  drm/radeon: Send out the full AUX address

 drivers/gpu/drm/drm_dp_helper.c  | 43 
 drivers/gpu/drm/i915/intel_dp.c  |  1 +
 drivers/gpu/drm/radeon/atombios_dp.c |  6 +++--
 drivers/gpu/drm/tegra/dpaux.c|  3 ++-
 include/drm/drm_dp_helper.h  |  2 +-
 5 files changed, 47 insertions(+), 8 deletions(-)

-- 
2.4.6



[Intel-gfx] drm/atomic: Reject events for inactive crtc's.

2015-08-27 Thread Daniel Vetter
On Thu, Aug 27, 2015 at 03:36:09PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 6 August 2015 at 13:49, Daniel Vetter  wrote:
> > On Thu, Aug 06, 2015 at 01:19:35PM +0200, Maarten Lankhorst wrote:
> >> Op 06-08-15 om 11:47 schreef Daniel Stone:
> >> > On 30 July 2015 at 08:03, Maarten Lankhorst
> >> >  wrote:
> >> >> +   if (!state->active && state->event) {
> >> >> +   DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not 
> >> >> active\n",
> >> >> +crtc->base.id);
> >> >> +   return -EINVAL;
> >> >> +   }
> >> > Hmm, even if disabling? Maybe (!crtc->state->active && !state->active)
> >> > && state->event.
> >> How do you want to send a vblank event after disabling?
> >
> > The event would be when we stop scanning out, but yeah that's a bit a
> > tricky one. I guess for now (until we have someone who needs this) we
> > could just merge Maarten's patch as the easier thing to do right now?
> > Maybe with a small code comment that this is intentional?
> 
> Exactly that. Surely this (when the CRTC actually goes dark) is
> something we already know? Assuming you don't have atomic_disable /
> instant-scanout-stop, and have to wait until the next vblank to kill
> it, then how does this work?
>   - create FB
>   - assign FB to plane on CRTC
>   - unreference FB such that plane holds the last remaining reference
>   - set plane->fb == NULL + crtc->active = 0, i.e. SetCrtc(NULL, 0, 0,
> 0, 0, ...)
> 
> You can't immediately unpin/destroy the FB since you might still be
> mid-scanout. So you already need to defer this, and that would be the
> point at which you stop scanout. In a lot of hardware, this is just
> another latched register which takes effect on the next vblank, for
> which you still catch an IRQ - at which point you send the event. If
> you actually have atomic_disable hardware that stops scanout
> immediately, you can just send the event immediately.
> 
> What am I missing?

The userspace which actually wants this and the testcases which makes sure
it works. Until we have that I'd really prefer to just close that
undefined behaviour gap in the atomic api, similar to how we just merged a
patch to disallow switching live planes.

We can always extend this later on easily, there's lots of little features
like this that people suggested for atomic.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH 03/11] drm/exynos: add prepare and cleanup phases for planes

2015-08-27 Thread Inki Dae
On 2015년 08월 27일 00:45, Gustavo Padovan wrote:
> Hi Inki,
> 
> 2015-08-24 Inki Dae :
> 
>> On 2015년 08월 16일 01:26, Gustavo Padovan wrote:
>>> From: Gustavo Padovan 
>>>
>>> .prepare_plane() and .cleanup_plane() allows to perform extra operations
>>> before and after the update of planes. For FIMD for example this will
>>> be used to enable disable the shadow protection bit.
>>>
>>> Signed-off-by: Gustavo Padovan 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 19 +++
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  6 ++
>>>  2 files changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> index 5a19e16..3a89fc9 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> @@ -72,15 +72,34 @@ exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
>>>  static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
>>>  {
>>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>> +   struct drm_plane *plane;
>>>
>>> if (crtc->state->event) {
>>> WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>>> exynos_crtc->event = crtc->state->event;
>>> }
>>> +
>>> +   drm_atomic_crtc_for_each_plane(plane, crtc) {
>>> +   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
>>> +
>>> +   if (exynos_crtc->ops->prepare_plane)
>>> +   exynos_crtc->ops->prepare_plane(exynos_crtc,
>>> +   exynos_plane);
>>
>> There is no any reason to use prepare_plane/cleanup_plane callback
>> names. How about using atomic_begin/atomic_flush callback names instead
>> for consistency between framework and device drivers?
> 
> Either names are fine for me. So let's go with atomic_begin/flush. I'll
> send an updated patchset.

Merged.

Thanks,
Inki Dae

> 
>   Gustavo
> 



[Bug 91775] Wrong openGL version

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91775

--- Comment #1 from Alex Deucher  ---
What card do you have?  Please attach your xorg log and dmesg output.

-- 
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/20150827/e88f03f9/attachment.html>


drm/exynos: g2d userptr memory corruption

2015-08-27 Thread Tobias Jakobi
Hello,

I did some further investigation into this issue.


I extended my test application to also cover GEM/GEM and
GEM/userptr transfers, and also putting GEM allocation
flags into the mix.

You can find the current version here:
https://github.com/tobiasjakobi/libdrm/blob/exynos/tests/exynos/exynos_fimg2d_verify_copy.c

What is interesting is that all GEM/GEM transfer
variants work, regardless of the allocation flags.

In particular I can allocate a cacheable GEM buffer
and the verification still works. This confuses me
since everything point into the direction that this
is a cache flush / cache coherency issue. So why
doesn't this happen for GEM buffers as well if we
allow caching to happen there?



Next I hacked up a custom ioctl to trigger
flush_cache_all(), outer_flush_all() and
outer_sync(), issuing this ioctl after filling the
buffers and also after the g2d operations. This
somehow helps, in the sense that the test application
runs longer. But it also makes the system prone to
lockups. Looks like calling outer_flush_all() a lot
triggers these. I don't know why this happens but
IIRC one shouldn't call these low-level functions
from driver code anyway.



Next I checked the DMA-API and looked into dma_sync_sg_for_cpu
and dma_sync_sg_for_device. But the driver code already does this:
1) dma_map before starting the engine
2) dma_unmap after the engine finishes

The DMA-API HOWTO explicitly says that the sync functions are
only there if I modify the buffer with the CPU between map
and unmap. Which is not the case here.

In particular I traced what dma_{map,unmap} do depending
on the DMA direction and deep down the callstack some
flush/invalidate stuff is called. And the GEM cases show
that this is somehow working.



Next I looked into Jerome's question about whethere the G2D is
cache coherent with the CPU. I looked into old Android code and
found FIMG2D_AXI_MODE_REG, a register that currently isn't
touched in the DRM code.
It seems to manipulate signals to the AXI Master interface.

The register looks like this:
[0:3] ARCACHE
[4:7] AWCACHE
[8:15] ARUSERS
[16:23] AWUSERS
[24:25] MaxBurstLength

If I understand ARM's AXI specifications correctly then you
can set cache coherent operation by setting AxUSER[0]=1 and
AxCACHE[1]=1.

The initialization values for AxCACHE and AxUSERS are all
zero, so the default seems to be non-coherent operation.
But still after setting the bits in FIMG2D_AXI_MODE_REG I
don't see any change in behaviour -- the issue stays.



Any idea what I'm missing here?

With best wishes,
Tobias


On 2015-08-19 16:41, Rob Clark wrote:
> On Wed, Aug 19, 2015 at 10:08 AM, Jerome Glisse  
> wrote:
>> On Wed, Aug 19, 2015 at 03:53:44PM +0200, Tobias Jakobi wrote:
>>> Adding Jérôme to Cc. I think he looked the userptr code before, so 
>>> maybe
>>> he has some idea what is going wrong here.
>>> 
>>> I also had a look at the code, but my knowledge about the DMA API is
>>> almost nonexistant. However I can see that before doing any DMA via 
>>> the
>>> G2D on the buffer the code calls dma_map() on it, and also unmaps it
>>> when the commandlist is finished.
>>> 
>>> 
>>> With best wishes,
>>> Tobias
>>> 
>>> 
>>> Tobias Jakobi wrote:
>>> > Thanks Lucas for the explanation!
>>> >
>>> >
>>> > Lucas Stach wrote:
>>> >> Hi Tobias,
>>> >>
>>> >> Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
>>> >>> Hello,
>>> >>>
>>> >>> some time ago I checked whether I could use the userptr functionality to
>>> >>> do zero-copy from userspace allocated buffers via the G2D. This didn't
>>> >>> work out so well, so kinda put this to the bottom of my TODO list.
>>> >>>
>>> >>> Now that IOMMU support has landed and Jan Kara has rewrote page pinning
>>> >>> using frame vectors (see [1]) I gave userptr another try.
>>> >>>
>>> >>> The results are much better. I'm not experiencing any kernel lockups or
>>> >>> sysmmu pagefaults anymore. However the image now suffers from visual
>>> >>> artifacts. These images show the nature of the artifacts:
>>> >>> http://i.imgur.com/nzT6g3Y.jpg
>>> >>> http://i.imgur.com/wkuYI6X.jpg
>>> >>>
>>> >>> The corruption always manifests itself in these pixel lines of fixed
>>> >>> size and wrong color.
>>> >>>
>>> >>> I have written a testcase as part of libdrm for this issue:
>>> >>> https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71
>>> >>>
>>> >>> It allocates N (N an even number) buffers which are aligned to the
>>> >>> system pagesize. Then it does this each iteration:
>>> >>> 1) Fill the first N/2 buffers with random data
>>> >>> 2) Copy the first half to the second half of the buffers
>>> >>> 3) memcmp() first and second half (verification pass)
>>> >>>
>>> >>> Usually this verification already fails on the first iteration. An
>>> >>> interesting observation is that increasing (!) the buffer size (so the
>>> >>> amount of pixels that have to copied per buffer grows) makes this issue
>>> >>> less likely to happen.
>>> >>>
>>> >>> 

[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Ville Syrjälä
On Thu, Aug 27, 2015 at 04:00:05PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 15:50 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 03:05:38PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:52 schreef Ville Syrjälä:
> >>> On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
>  Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:19 schreef Daniel Stone:
> >>> Hi,
> >>>
> >>> On 4 August 2015 at 12:34, Maarten Lankhorst
> >>>  wrote:
>  Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
>  "drm/atomic: Cleanup on error properly in the atomic ioctl."
>  cleaned up some error paths, but didn't fix the TEST_ONLY path.
>  In the check only case plane->fb shouldn't be updated, and
>  the vblank events should be cleared as on failure.
> >>> Bikeshedding a bit ...
> >>>
> >>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> >>> to mention this in the commit message; in this case, the main change
> >>> is about plane->{,old_}fb.
> >> Even testing with PAGE_FLIP_EVENT would be useful because
> >> event && !crtc_state->active should not be allowed. In that case test
> >> could succeed but commit could fail.
> > Why would commit fail when the we're in DPMS off? I would suggest it
> > should be allowed. The operation would just a be a nop from a HW point
> > of view, all the calculation/checks would still be performed.
> >
>  You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
> >>> What's so special about the event here? Just send it out as soon as the
> >>> state has been swapped.
> >> Previously this has been disallowed for legacy page flips.
> > I don't think so. Speaking for i915, I think we've just rejected legacy page
> > flips entirely with the pipe is off on account of drm_vblank_get() failing.
> No atomic driver handles this case correctly. You can't get vblank events 
> with the crtc off.

I don't understand what you're saying. Should there be a comma after
"No" ? If not, then I'm not sure what they don't handle.

> >> I don't see why this should be relaxed. It just complicates things and you 
> >> have nothing to stick in for the vblank counter.
> > We could stick the last vbl count/timestamp in there.
> >
> > Not allowing means userspace is forced to consider the dpms state
> > whenever it wants to call the atomic ioctl.
> Userspace was the one turning off the crtc in the first place; it shouldn't 
> continue flipping but preserve power. :-)

Meh. Much simpler to write code when you don't have to worry about such
details.

In the kernel it should amount to
if (!pipe_active)
send_event

We anyway need something like that for the crtc getting disabled case,
don't we?

-- 
Ville Syrjälä
Intel OTC


[PATCH 2/2] drm/exynos: implement atomic_{begin/flush} of FIMD and DECON

2015-08-27 Thread Inki Dae
On 2015년 08월 20일 11:33, Hyungwon Hwang wrote:
> Each CRTC's atomic_{begin/flush} must stop/start the update of shadow
> registers to active register in the functions. This patch achieves these
> purpose by moving the setting of protection bits to those functions from
> {fimd/decon}_update_plane.

Hyungwon,
Gustavo already posted atomic_begin/flush support. However, he didn't
consider decon drivers.

Can you post only atomic_begin/flush support for decon drivers?

Thanks,
Inki Dae

> 
> Signed-off-by: Hyungwon Hwang 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 47 +---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 47 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 51 
> ++-
>  3 files changed, 103 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 484e312..fef0333 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -31,6 +31,7 @@ struct decon_context {
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[WINDOWS_NR];
> + unsigned intupdated_plane;
>   void __iomem*addr;
>   struct clk  *clks[6];
>   unsigned intdefault_win;
> @@ -204,17 +205,17 @@ static void decon_win_set_pixfmt(struct decon_context 
> *ctx, unsigned int win,
>   writel(val, ctx->addr + DECON_WINCONx(win));
>  }
>  
> -static void decon_shadow_protect_win(struct decon_context *ctx, int win,
> - bool protect)
> +static void decon_shadow_protect_win(struct decon_context *ctx,
> + unsigned int win_bits, bool protect)
>  {
>   u32 val;
>  
>   val = readl(ctx->addr + DECON_SHADOWCON);
>  
>   if (protect)
> - val |= SHADOWCON_Wx_PROTECT(win);
> + val |= win_bits;
>   else
> - val &= ~SHADOWCON_Wx_PROTECT(win);
> + val &= ~win_bits;
>  
>   writel(val, ctx->addr + DECON_SHADOWCON);
>  }
> @@ -232,8 +233,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
>   if (ctx->suspended)
>   return;
>  
> - decon_shadow_protect_win(ctx, win, true);
> -
>   val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
>   writel(val, ctx->addr + DECON_VIDOSDxA(win));
>  
> @@ -265,15 +264,12 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
>   val |= WINCONx_ENWIN_F;
>   writel(val, ctx->addr + DECON_WINCONx(win));
>  
> - decon_shadow_protect_win(ctx, win, false);
> -
>   /* standalone update */
>   val = readl(ctx->addr + DECON_UPDATE);
>   val |= STANDALONE_UPDATE_F;
>   writel(val, ctx->addr + DECON_UPDATE);
>  
> - if (ctx->i80_if)
> - atomic_set(>win_updated, 1);
> + ctx->updated_plane |= SHADOWCON_Wx_PROTECT(win);
>  }
>  
>  static void decon_disable_plane(struct exynos_drm_crtc *crtc,
> @@ -286,14 +282,14 @@ static void decon_disable_plane(struct exynos_drm_crtc 
> *crtc,
>   if (ctx->suspended)
>   return;
>  
> - decon_shadow_protect_win(ctx, win, true);
> + decon_shadow_protect_win(ctx, SHADOWCON_Wx_PROTECT(win), true);
>  
>   /* window disable */
>   val = readl(ctx->addr + DECON_WINCONx(win));
>   val &= ~WINCONx_ENWIN_F;
>   writel(val, ctx->addr + DECON_WINCONx(win));
>  
> - decon_shadow_protect_win(ctx, win, false);
> + decon_shadow_protect_win(ctx, SHADOWCON_Wx_PROTECT(win), false);
>  
>   /* standalone update */
>   val = readl(ctx->addr + DECON_UPDATE);
> @@ -405,6 +401,31 @@ void decon_te_irq_handler(struct exynos_drm_crtc *crtc)
>   drm_crtc_handle_vblank(>crtc->base);
>  }
>  
> +static void decon_begin(struct exynos_drm_crtc *crtc)
> +{
> + struct decon_context *ctx = crtc->ctx;
> + int i;
> + unsigned int val = 0;
> +
> + for (i = 0; i < WINDOWS_NR; i++)
> + val |= SHADOWCON_Wx_PROTECT(i);
> +
> + /* protect windows */
> + decon_shadow_protect_win(ctx, val, true);
> +}
> +
> +static void decon_flush(struct exynos_drm_crtc *crtc)
> +{
> + struct decon_context *ctx = crtc->ctx;
> +
> + if (ctx->updated_plane) {
> + decon_shadow_protect_win(ctx, ctx->updated_plane, false);
> +
> + if (ctx->i80_if)
> + atomic_set(>win_updated, 1);
> + }
> +}
> +
>  static void decon_clear_channels(struct exynos_drm_crtc *crtc)
>  {
>   struct decon_context *ctx = crtc->ctx;
> @@ -458,6 +479,8 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
>   .update_plane   = decon_update_plane,
>   .disable_plane  = decon_disable_plane,
>   .te_handler = 

[PATCH 3/6] dma-buf: Add ioctls to allow userspace to flush

2015-08-27 Thread Tiago Vignatti
On 08/27/2015 05:03 AM, Chris Wilson wrote:
> On Wed, Aug 26, 2015 at 08:29:15PM -0300, Tiago Vignatti wrote:
>> +#ifndef _DMA_BUF_UAPI_H_
>> +#define _DMA_BUF_UAPI_H_
>> +
>> +enum dma_buf_sync_flags {
>> +DMA_BUF_SYNC_READ = (1 << 0),
>> +DMA_BUF_SYNC_WRITE = (2 << 0),
>> +DMA_BUF_SYNC_RW = (3 << 0),
>> +DMA_BUF_SYNC_START = (0 << 2),
>> +DMA_BUF_SYNC_END = (1 << 2),
>> +
>> +DMA_BUF_SYNC_VALID_FLAGS_MASK = DMA_BUF_SYNC_RW |
>> +DMA_BUF_SYNC_END
>> +};
>> +
>> +/* begin/end dma-buf functions used for userspace mmap. */
>> +struct dma_buf_sync {
>> +enum dma_buf_sync_flags flags;
>
> It is better to use explicitly sized types. And since this is not 64b
> padded, probably best to add that padding now.

ahh, I've changed it to use enum instead. If I rollback to use defines 
then do you think works better? Like this:

struct dma_buf_sync {
   __u64 flags;
};

#define DMA_BUF_SYNC_READ  (1 << 0)
#define DMA_BUF_SYNC_WRITE (2 << 0)
#define DMA_BUF_SYNC_RW(3 << 0)
#define DMA_BUF_SYNC_START (0 << 2)
#define DMA_BUF_SYNC_END   (1 << 2)
#define DMA_BUF_SYNC_VALID_FLAGS_MASK \
   (DMA_BUF_SYNC_RW | DMA_BUF_SYNC_END)

#define DMA_BUF_BASE'b'
#define DMA_BUF_IOCTL_SYNC  _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)



[PATCH 3/6] dma-buf: Add ioctls to allow userspace to flush

2015-08-27 Thread Tiago Vignatti
On 08/27/2015 09:06 AM, Hwang, Dongseong wrote:
> On Thu, Aug 27, 2015 at 2:29 AM, Tiago Vignatti
>> +#define DMA_BUF_BASE   'b'
>
> 'b' is occupied by vme and qat driver;
> https://github.com/torvalds/linux/blob/master/Documentation/ioctl/ioctl-number.txt#L201

I believe this is alright, as noted in that txt file: "Because of the 
large number of drivers, many drivers share a partial letter with other 
drivers".

> is it bad idea for drm.h to include these definition?
> http://lxr.free-electrons.com/source/include/uapi/drm/drm.h#L684

this is not a drm code and other type of device drivers might want to 
use it as well.

Tiago


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Ville Syrjälä
On Thu, Aug 27, 2015 at 03:05:38PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:52 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> >>> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
>  Op 27-08-15 om 14:19 schreef Daniel Stone:
> > Hi,
> >
> > On 4 August 2015 at 12:34, Maarten Lankhorst
> >  wrote:
> >> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> >> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> >> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> >> In the check only case plane->fb shouldn't be updated, and
> >> the vblank events should be cleared as on failure.
> > Bikeshedding a bit ...
> >
> > An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> > to mention this in the commit message; in this case, the main change
> > is about plane->{,old_}fb.
>  Even testing with PAGE_FLIP_EVENT would be useful because
>  event && !crtc_state->active should not be allowed. In that case test
>  could succeed but commit could fail.
> >>> Why would commit fail when the we're in DPMS off? I would suggest it
> >>> should be allowed. The operation would just a be a nop from a HW point
> >>> of view, all the calculation/checks would still be performed.
> >>>
> >> You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
> > What's so special about the event here? Just send it out as soon as the
> > state has been swapped.
> Previously this has been disallowed for legacy page flips.

I don't think so. Speaking for i915, I think we've just rejected legacy page
flips entirely with the pipe is off on account of drm_vblank_get() failing.

> I don't see why this should be relaxed. It just complicates things and you 
> have nothing to stick in for the vblank counter.

We could stick the last vbl count/timestamp in there.

Not allowing means userspace is forced to consider the dpms state
whenever it wants to call the atomic ioctl.

-- 
Ville Syrjälä
Intel OTC


[PATCH v3 1/3] drm: add drm_of_encoder_active_endpoint helpers

2015-08-27 Thread Daniel Vetter
On Thu, Aug 27, 2015 at 12:56:05PM +0200, Philipp Zabel wrote:
> This patch adds a helper to parse the encoder endpoint connected to the
> encoder's crtc and two helpers to return its id and port id.
> 
> This can be used to determine input mux setting from endpoint or port ids.
> 
> Suggested-by: Daniel Kurtz 
> Reviewed-by: Daniel Kurtz 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/drm_of.c | 34 ++
>  include/drm/drm_of.h | 33 +
>  2 files changed, 67 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index be38840..0c9714cd 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -61,3 +61,37 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>   return possible_crtcs;
>  }
>  EXPORT_SYMBOL(drm_of_find_possible_crtcs);
> +
> +/*
> + * drm_of_encoder_active_endpoint - return the active encoder endpoint
> + * @node: device tree node containing encoder input ports
> + * @encoder: drm_encoder
> + *
> + * Given an encoder device node and a drm_encoder with a connected crtc,
> + * parse the encoder endpoint connecting to the crtc port.
> + */

Can you please write proper kerneldoc for this plus pull drm_of.c into the
docbook template? Some overview comments in a DOC: section (maybe even
with code snippets/examples, we can do those now in 4.3) would be even
better.
-Daniel

> +int drm_of_encoder_active_endpoint(struct device_node *node,
> +struct drm_encoder *encoder,
> +struct of_endpoint *endpoint)
> +{
> + struct device_node *ep;
> + struct drm_crtc *crtc = encoder->crtc;
> + struct device_node *port;
> + int ret;
> +
> + if (!node || !crtc)
> + return -EINVAL;
> +
> + for_each_endpoint_of_node(node, ep) {
> + port = of_graph_get_remote_port(ep);
> + of_node_put(port);
> + if (port == crtc->port) {
> + ret = of_graph_parse_endpoint(ep, endpoint);
> + of_node_put(ep);
> + return ret;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 2441f71..efd3b44 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -1,18 +1,51 @@
>  #ifndef __DRM_OF_H__
>  #define __DRM_OF_H__
>  
> +#include 
> +
>  struct drm_device;
> +struct drm_encoder;
>  struct device_node;
>  
>  #ifdef CONFIG_OF
>  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  struct device_node *port);
> +extern int drm_of_encoder_active_endpoint(struct device_node *node,
> +   struct drm_encoder *encoder,
> +   struct of_endpoint *endpoint);
>  #else
>  static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> struct device_node *port)
>  {
>   return 0;
>  }
> +
> +static inline int drm_of_encoder_active_endpoint(struct device_node *node,
> +  struct drm_encoder *encoder,
> +  struct of_endpoint *endpoint)
> +{
> + return -EINVAL;
> +}
>  #endif
>  
> +static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
> + struct drm_encoder *encoder)
> +{
> + struct of_endpoint endpoint;
> + int ret = drm_of_encoder_active_endpoint(node, encoder,
> +  );
> +
> + return ret ?: endpoint.id;
> +}
> +
> +static inline int drm_of_encoder_active_port_id(struct device_node *node,
> + struct drm_encoder *encoder)
> +{
> + struct of_endpoint endpoint;
> + int ret = drm_of_encoder_active_endpoint(node, encoder,
> +  );
> +
> + return ret ?: endpoint.port;
> +}
> +
>  #endif /* __DRM_OF_H__ */
> -- 
> 2.5.0
> 

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


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Maarten Lankhorst
Op 27-08-15 om 15:50 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 03:05:38PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:52 schreef Ville Syrjälä:
>>> On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
 Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:19 schreef Daniel Stone:
>>> Hi,
>>>
>>> On 4 August 2015 at 12:34, Maarten Lankhorst
>>>  wrote:
 Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
 "drm/atomic: Cleanup on error properly in the atomic ioctl."
 cleaned up some error paths, but didn't fix the TEST_ONLY path.
 In the check only case plane->fb shouldn't be updated, and
 the vblank events should be cleared as on failure.
>>> Bikeshedding a bit ...
>>>
>>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
>>> to mention this in the commit message; in this case, the main change
>>> is about plane->{,old_}fb.
>> Even testing with PAGE_FLIP_EVENT would be useful because
>> event && !crtc_state->active should not be allowed. In that case test
>> could succeed but commit could fail.
> Why would commit fail when the we're in DPMS off? I would suggest it
> should be allowed. The operation would just a be a nop from a HW point
> of view, all the calculation/checks would still be performed.
>
 You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
>>> What's so special about the event here? Just send it out as soon as the
>>> state has been swapped.
>> Previously this has been disallowed for legacy page flips.
> I don't think so. Speaking for i915, I think we've just rejected legacy page
> flips entirely with the pipe is off on account of drm_vblank_get() failing.
No atomic driver handles this case correctly. You can't get vblank events with 
the crtc off.
>> I don't see why this should be relaxed. It just complicates things and you 
>> have nothing to stick in for the vblank counter.
> We could stick the last vbl count/timestamp in there.
>
> Not allowing means userspace is forced to consider the dpms state
> whenever it wants to call the atomic ioctl.
Userspace was the one turning off the crtc in the first place; it shouldn't 
continue flipping but preserve power. :-)

~Maarten


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Ville Syrjälä
On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
> >> Op 27-08-15 om 14:19 schreef Daniel Stone:
> >>> Hi,
> >>>
> >>> On 4 August 2015 at 12:34, Maarten Lankhorst
> >>>  wrote:
>  Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
>  "drm/atomic: Cleanup on error properly in the atomic ioctl."
>  cleaned up some error paths, but didn't fix the TEST_ONLY path.
>  In the check only case plane->fb shouldn't be updated, and
>  the vblank events should be cleared as on failure.
> >>> Bikeshedding a bit ...
> >>>
> >>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> >>> to mention this in the commit message; in this case, the main change
> >>> is about plane->{,old_}fb.
> >> Even testing with PAGE_FLIP_EVENT would be useful because
> >> event && !crtc_state->active should not be allowed. In that case test
> >> could succeed but commit could fail.
> > Why would commit fail when the we're in DPMS off? I would suggest it
> > should be allowed. The operation would just a be a nop from a HW point
> > of view, all the calculation/checks would still be performed.
> >
> You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.

What's so special about the event here? Just send it out as soon as the
state has been swapped.

-- 
Ville Syrjälä
Intel OTC


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Ville Syrjälä
On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
> Op 27-08-15 om 14:19 schreef Daniel Stone:
> > Hi,
> >
> > On 4 August 2015 at 12:34, Maarten Lankhorst
> >  wrote:
> >> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> >> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> >> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> >> In the check only case plane->fb shouldn't be updated, and
> >> the vblank events should be cleared as on failure.
> > Bikeshedding a bit ...
> >
> > An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> > to mention this in the commit message; in this case, the main change
> > is about plane->{,old_}fb.
> Even testing with PAGE_FLIP_EVENT would be useful because
> event && !crtc_state->active should not be allowed. In that case test
> could succeed but commit could fail.

Why would commit fail when the we're in DPMS off? I would suggest it
should be allowed. The operation would just a be a nop from a HW point
of view, all the calculation/checks would still be performed.

> 
> Though I guess you're right and it's currently not allowed.
> >> @@ -1532,7 +1533,7 @@ retry:
> >> ret = drm_atomic_check_only(state);
> >> /* _check_only() does not free state, unlike _commit() */
> >> if (!ret)
> >> -   drm_atomic_state_free(state);
> >> +   goto free;
> >> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> >> ret = drm_atomic_async_commit(state);
> >> } else {
> >> @@ -1566,6 +1567,7 @@ out:
> >> }
> >>
> >> if (ret) {
> >> +free:
> > This is a bit nasty. Can we please move the label above the
> > conditional and change the condition to (ret || flags & TEST_ONLY)?
> > Doing that, you could also move the label above the (ret == -EDEADLK)
> > check, which would cover ->atomic_check needing to grab other states
> > (global resources?) and failing.
> If our bookkeeping is correct then it won't be harmful to fixup old_fb.
> Cleaning up more old_fb for more planes than initially had fb updates can 
> always
> happen anyway, because a modeset will add all affected planes.
> 
> How about the below patch? Apply with git am --scissors
> 
> >8--
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but allowed -EDEADLK to
> leak vblank events.
> 
> Additionally check_only was updating plane->fb, which should
> not be done when checking a new configuration only.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2448f42480f..78ffb4965548 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1542,7 +1542,8 @@ retry:
>   copied_props++;
>   }
>  
> - if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
> + if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> + !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
>   plane = obj_to_plane(obj);
>   plane_mask |= (1 << drm_plane_index(plane));
>   plane->old_fb = plane->fb;
> @@ -1564,10 +1565,11 @@ retry:
>   }
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> + /*
> +  * Unlike commit, check_only does not clean up state.
> +  * Below we call drm_atomic_state_free for it.
> +  */
>   ret = drm_atomic_check_only(state);
> - /* _check_only() does not free state, unlike _commit() */
> - if (!ret)
> - drm_atomic_state_free(state);
>   } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>   ret = drm_atomic_async_commit(state);
>   } else {
> @@ -1594,25 +1596,24 @@ out:
>   plane->old_fb = NULL;
>   }
>  
> + if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc_state->event)
> + continue;
> +
> + destroy_vblank_event(dev, file_priv,
> +  crtc_state->event);
> + }
> + }
> +
>   if (ret == -EDEADLK) {
>   drm_atomic_state_clear(state);
>   drm_modeset_backoff();
>   goto retry;
>   }
>  
> - if (ret) {
> - if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (!crtc_state->event)
> - continue;
> -
> - destroy_vblank_event(dev, file_priv,
> -  crtc_state->event);
> - }
> -  

[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Daniel Stone
On 27 August 2015 at 15:34, Ville Syrjälä  
wrote:
> On Thu, Aug 27, 2015 at 03:28:53PM +0100, Daniel Stone wrote:
>> On 27 August 2015 at 15:09, Ville Syrjälä > linux.intel.com> wrote:
>> > In the kernel it should amount to
>> > if (!pipe_active)
>> > send_event
>>
>> No, thankyou. Asking for an event, having the request succeed, and
>> never getting an event, is a deathtrap.
>
> Obviously the event gets sent if the operation succeeds. I never
> suggested anything else.

Er, yeah. Totally missed the ! in the condition. As you were.

Cheers,
Daniel


[Bug 91775] Wrong openGL version

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91775

Bug ID: 91775
   Summary: Wrong openGL version
   Product: Mesa
   Version: git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: trivial
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: 19.jaime.91 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Supposely I should be reported to have OpenGL 4.1, but I get 3.3. I don't know
if the problem is that my card doesn't use the mesa radeonsi driver and uses
r600. Where can I check that?

-- 
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/20150827/d8ec7562/attachment-0001.html>


[Intel-gfx] drm/atomic: Reject events for inactive crtc's.

2015-08-27 Thread Daniel Stone
Hi,

On 6 August 2015 at 13:49, Daniel Vetter  wrote:
> On Thu, Aug 06, 2015 at 01:19:35PM +0200, Maarten Lankhorst wrote:
>> Op 06-08-15 om 11:47 schreef Daniel Stone:
>> > On 30 July 2015 at 08:03, Maarten Lankhorst
>> >  wrote:
>> >> +   if (!state->active && state->event) {
>> >> +   DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not 
>> >> active\n",
>> >> +crtc->base.id);
>> >> +   return -EINVAL;
>> >> +   }
>> > Hmm, even if disabling? Maybe (!crtc->state->active && !state->active)
>> > && state->event.
>> How do you want to send a vblank event after disabling?
>
> The event would be when we stop scanning out, but yeah that's a bit a
> tricky one. I guess for now (until we have someone who needs this) we
> could just merge Maarten's patch as the easier thing to do right now?
> Maybe with a small code comment that this is intentional?

Exactly that. Surely this (when the CRTC actually goes dark) is
something we already know? Assuming you don't have atomic_disable /
instant-scanout-stop, and have to wait until the next vblank to kill
it, then how does this work?
  - create FB
  - assign FB to plane on CRTC
  - unreference FB such that plane holds the last remaining reference
  - set plane->fb == NULL + crtc->active = 0, i.e. SetCrtc(NULL, 0, 0,
0, 0, ...)

You can't immediately unpin/destroy the FB since you might still be
mid-scanout. So you already need to defer this, and that would be the
point at which you stop scanout. In a lot of hardware, this is just
another latched register which takes effect on the next vblank, for
which you still catch an IRQ - at which point you send the event. If
you actually have atomic_disable hardware that stops scanout
immediately, you can just send the event immediately.

What am I missing?

Cheers,
Daniel


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Daniel Stone
Hi,

On 27 August 2015 at 15:09, Ville Syrjälä  
wrote:
> On Thu, Aug 27, 2015 at 04:00:05PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 15:50 schreef Ville Syrjälä:
>> > I don't think so. Speaking for i915, I think we've just rejected legacy 
>> > page
>> > flips entirely with the pipe is off on account of drm_vblank_get() failing.
>> No atomic driver handles this case correctly. You can't get vblank events 
>> with the crtc off.
>
> I don't understand what you're saying. Should there be a comma after
> "No" ? If not, then I'm not sure what they don't handle.

I think you're arguing over the definition of 'correctly' perhaps?

>> >> I don't see why this should be relaxed. It just complicates things and 
>> >> you have nothing to stick in for the vblank counter.
>> > We could stick the last vbl count/timestamp in there.
>> >
>> > Not allowing means userspace is forced to consider the dpms state
>> > whenever it wants to call the atomic ioctl.
>> Userspace was the one turning off the crtc in the first place; it shouldn't 
>> continue flipping but preserve power. :-)
>
> Meh. Much simpler to write code when you don't have to worry about such
> details.
>
> In the kernel it should amount to
> if (!pipe_active)
> send_event

No, thankyou. Asking for an event, having the request succeed, and
never getting an event, is a deathtrap. PAGE_FLIP_EVENT should mean
that either an event gets delivered for every CRTC in crtc_state, or
the request getting rejected. Nothing else.

> We anyway need something like that for the crtc getting disabled case,
> don't we?

Yes, which I was getting at previously. We know when the CRTC gets
disabled - we have to, in order to sensibly unpin etc - so that's when
the event gets sent.

Cheers,
Daniel


[PATCH 1/6] drm: prime: Honour O_RDWR during prime-handle-to-fd

2015-08-27 Thread Tiago Vignatti
On 08/27/2015 01:36 PM, Emil Velikov wrote:
> Hi all,
>
> On 27 August 2015 at 00:29, Tiago Vignatti  
> wrote:
>> From: Daniel Thompson 
>>
>> Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
>> (DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
>> to mmap() the resulting dma-buf even when this is supported by the
>> DRM driver.
>>
>> It is trivial to relax the restriction and permit read/write access.
>> This is safe because the flags are seldom touched by drm; mostly they
>> are passed verbatim to dma_buf calls.
>>
> Strictly speaking shouldn't this patch be the last one in the series ?
> I.e. we should lift this restriction, after the sync method
> (ioctl/syscall/etc.) is in place. Or perhaps I missed something ?

I think you're right about it, Emil.

Thank you,

Tiago



[PATCH -next] drm/vmwgfx: Allow dropped masters render-node like access on legacy nodes

2015-08-27 Thread Thomas Hellstrom
On 08/27/2015 02:55 PM, Thomas Hellstrom wrote:
> Applications like gnome-shell may try to render after dropping master
> privileges. Since the driver should now be safe against this scenario,
> allow those applications to use their legacy node like a render node.
>
> Signed-off-by: Thomas Hellstrom 
> Reviewed-by: Sinclair Yeh 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 ++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 5 +
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 03854d6..e13b20b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1052,10 +1052,15 @@ static struct vmw_master *vmw_master_check(struct 
> drm_device *dev,
>   }
>  
>   /*
> -  * Check if we were previously master, but now dropped.
> +  * Check if we were previously master, but now dropped. In that
> +  * case, allow at least render node functionality.
>*/
>   if (vmw_fp->locked_master) {
>   mutex_unlock(>master_mutex);
> +
> + if (flags & DRM_RENDER_ALLOW)
> + return NULL;
> +
>   DRM_ERROR("Dropped master trying to access ioctl that "
> "requires authentication.\n");
>   return ERR_PTR(-EACCES);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 5b8595b..4f0794d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -911,6 +911,11 @@ vmw_surface_handle_reference(struct vmw_private 
> *dev_priv,
> "surface reference.\n");
>   return -EACCES;
>   }
> + if (ACCESS_ONCE(vmw_fpriv(file_priv)->locked_master)) {
> + DRM_ERROR("Locked master refused legacy "
> +   "surface reference.\n");

Actually, a return -EACCES is missing here. I'll send out a v2.

/Thomas



[PATCH 3/6] dma-buf: Add ioctls to allow userspace to flush

2015-08-27 Thread Hwang, Dongseong
On Thu, Aug 27, 2015 at 2:29 AM, Tiago Vignatti
 wrote:
> From: Daniel Vetter 
>
> The userspace might need some sort of cache coherency management e.g. when CPU
> and GPU domains are being accessed through dma-buf at the same time. To
> circumvent this problem there are begin/end coherency markers, that forward
> directly to existing dma-buf device drivers vfunc hooks. Userspace can make 
> use
> of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence would be
> used like following:
>  - mmap dma-buf fd
>  - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
>to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
>want (with the new data being consumed by the GPU or say scanout 
> device)
>  - munamp once you don't need the buffer any more
>
> v2 (Tiago): Fix header file type names (u64 -> __u64)
> v3 (Tiago): Add documentation. Use enum dma_buf_sync_flags to the begin/end
> dma-buf functions. Check for overflows in start/length.
> v4 (Tiago): use 2d regions for sync.
> v5 (Tiago): forget about 2d regions (v4); use _IOW in DMA_BUF_IOCTL_SYNC and
> remove range information from struct dma_buf_sync.
>
> Cc: Sumit Semwal 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Tiago Vignatti 
> ---
>  Documentation/dma-buf-sharing.txt | 12 +++
>  drivers/dma-buf/dma-buf.c | 43 
> +++
>  include/uapi/linux/dma-buf.h  | 41 +
>  3 files changed, 96 insertions(+)
>  create mode 100644 include/uapi/linux/dma-buf.h
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 4f4a84b..ec0ab1d 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,6 +352,18 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd.
>
> +   Also, the userspace might need some sort of cache coherency management 
> e.g.
> +   when CPU and GPU domains are being accessed through dma-buf at the same
> +   time. To circumvent this problem there are begin/end coherency markers, 
> that
> +   forward directly to existing dma-buf device drivers vfunc hooks. Userspace
> +   can make use of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The
> +   sequence would be used like following:
> + - mmap dma-buf fd
> + - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. 
> read/write
> +   to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
> +   want (with the new data being consumed by the GPU or say scanout 
> device)
> + - munamp once you don't need the buffer any more
> +
>  2. Supporting existing mmap interfaces in importers
>
> Similar to the motivation for kernel cpu access it is again important that
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index b2ac13b..9a298bd 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -34,6 +34,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  static inline int is_dma_buf_file(struct file *);
>
>  struct dma_buf_list {
> @@ -251,11 +253,52 @@ out:
> return events;
>  }
>
> +static long dma_buf_ioctl(struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> +   struct dma_buf *dmabuf;
> +   struct dma_buf_sync sync;
> +   enum dma_data_direction direction;
> +
> +   dmabuf = file->private_data;
> +
> +   if (!is_dma_buf_file(file))
> +   return -EINVAL;
> +
> +   switch (cmd) {
> +   case DMA_BUF_IOCTL_SYNC:
> +   if (copy_from_user(, (void __user *) arg, sizeof(sync)))
> +   return -EFAULT;
> +
> +   if (sync.flags & DMA_BUF_SYNC_RW)
> +   direction = DMA_BIDIRECTIONAL;
> +   else if (sync.flags & DMA_BUF_SYNC_READ)
> +   direction = DMA_FROM_DEVICE;
> +   else if (sync.flags & DMA_BUF_SYNC_WRITE)
> +   direction = DMA_TO_DEVICE;
> +   else
> +   return -EINVAL;
> +
> +   if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> +   return -EINVAL;
> +
> +   if (sync.flags & DMA_BUF_SYNC_END)
> +   dma_buf_end_cpu_access(dmabuf, direction);
> +   else
> +   dma_buf_begin_cpu_access(dmabuf, direction);
> +
> +   return 0;
> +   default:
> +   return -ENOTTY;
> +   }
> +}
> +
>  static const struct file_operations dma_buf_fops = {
> .release= dma_buf_release,
> .mmap   = dma_buf_mmap_internal,
> .llseek = dma_buf_llseek,
> .poll   = dma_buf_poll,
> +   .unlocked_ioctl = dma_buf_ioctl,
>  };
>
>  /*
> diff --git a/include/uapi/linux/dma-buf.h 

[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Maarten Lankhorst
Op 27-08-15 om 14:52 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 02:50:34PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:48 schreef Ville Syrjälä:
>>> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
 Op 27-08-15 om 14:19 schreef Daniel Stone:
> Hi,
>
> On 4 August 2015 at 12:34, Maarten Lankhorst
>  wrote:
>> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
>> "drm/atomic: Cleanup on error properly in the atomic ioctl."
>> cleaned up some error paths, but didn't fix the TEST_ONLY path.
>> In the check only case plane->fb shouldn't be updated, and
>> the vblank events should be cleared as on failure.
> Bikeshedding a bit ...
>
> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> to mention this in the commit message; in this case, the main change
> is about plane->{,old_}fb.
 Even testing with PAGE_FLIP_EVENT would be useful because
 event && !crtc_state->active should not be allowed. In that case test
 could succeed but commit could fail.
>>> Why would commit fail when the we're in DPMS off? I would suggest it
>>> should be allowed. The operation would just a be a nop from a HW point
>>> of view, all the calculation/checks would still be performed.
>>>
>> You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.
> What's so special about the event here? Just send it out as soon as the
> state has been swapped.
Previously this has been disallowed for legacy page flips. I don't see why this 
should be relaxed. It just complicates things and you have nothing to stick in 
for the vblank counter.

~Maarten


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Maarten Lankhorst
Op 27-08-15 om 14:48 schreef Ville Syrjälä:
> On Thu, Aug 27, 2015 at 02:43:35PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 14:19 schreef Daniel Stone:
>>> Hi,
>>>
>>> On 4 August 2015 at 12:34, Maarten Lankhorst
>>>  wrote:
 Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
 "drm/atomic: Cleanup on error properly in the atomic ioctl."
 cleaned up some error paths, but didn't fix the TEST_ONLY path.
 In the check only case plane->fb shouldn't be updated, and
 the vblank events should be cleared as on failure.
>>> Bikeshedding a bit ...
>>>
>>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
>>> to mention this in the commit message; in this case, the main change
>>> is about plane->{,old_}fb.
>> Even testing with PAGE_FLIP_EVENT would be useful because
>> event && !crtc_state->active should not be allowed. In that case test
>> could succeed but commit could fail.
> Why would commit fail when the we're in DPMS off? I would suggest it
> should be allowed. The operation would just a be a nop from a HW point
> of view, all the calculation/checks would still be performed.
>
You can commit, just not with PAGE_FLIP_EVENT set when crtc is inactive.

~Maarten


[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Maarten Lankhorst
Op 27-08-15 om 14:19 schreef Daniel Stone:
> Hi,
>
> On 4 August 2015 at 12:34, Maarten Lankhorst
>  wrote:
>> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
>> "drm/atomic: Cleanup on error properly in the atomic ioctl."
>> cleaned up some error paths, but didn't fix the TEST_ONLY path.
>> In the check only case plane->fb shouldn't be updated, and
>> the vblank events should be cleared as on failure.
> Bikeshedding a bit ...
>
> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
> to mention this in the commit message; in this case, the main change
> is about plane->{,old_}fb.
Even testing with PAGE_FLIP_EVENT would be useful because
event && !crtc_state->active should not be allowed. In that case test
could succeed but commit could fail.

Though I guess you're right and it's currently not allowed.
>> @@ -1532,7 +1533,7 @@ retry:
>> ret = drm_atomic_check_only(state);
>> /* _check_only() does not free state, unlike _commit() */
>> if (!ret)
>> -   drm_atomic_state_free(state);
>> +   goto free;
>> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>> ret = drm_atomic_async_commit(state);
>> } else {
>> @@ -1566,6 +1567,7 @@ out:
>> }
>>
>> if (ret) {
>> +free:
> This is a bit nasty. Can we please move the label above the
> conditional and change the condition to (ret || flags & TEST_ONLY)?
> Doing that, you could also move the label above the (ret == -EDEADLK)
> check, which would cover ->atomic_check needing to grab other states
> (global resources?) and failing.
If our bookkeeping is correct then it won't be harmful to fixup old_fb.
Cleaning up more old_fb for more planes than initially had fb updates can always
happen anyway, because a modeset will add all affected planes.

How about the below patch? Apply with git am --scissors

>8--
Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but allowed -EDEADLK to
leak vblank events.

Additionally check_only was updating plane->fb, which should
not be done when checking a new configuration only.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2448f42480f..78ffb4965548 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1542,7 +1542,8 @@ retry:
copied_props++;
}

-   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
+   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
+   !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
plane = obj_to_plane(obj);
plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
@@ -1564,10 +1565,11 @@ retry:
}

if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
+   /*
+* Unlike commit, check_only does not clean up state.
+* Below we call drm_atomic_state_free for it.
+*/
ret = drm_atomic_check_only(state);
-   /* _check_only() does not free state, unlike _commit() */
-   if (!ret)
-   drm_atomic_state_free(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_async_commit(state);
} else {
@@ -1594,25 +1596,24 @@ out:
plane->old_fb = NULL;
}

+   if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   if (!crtc_state->event)
+   continue;
+
+   destroy_vblank_event(dev, file_priv,
+crtc_state->event);
+   }
+   }
+
if (ret == -EDEADLK) {
drm_atomic_state_clear(state);
drm_modeset_backoff();
goto retry;
}

-   if (ret) {
-   if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (!crtc_state->event)
-   continue;
-
-   destroy_vblank_event(dev, file_priv,
-crtc_state->event);
-   }
-   }
-
+   if (ret || arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
drm_atomic_state_free(state);
-   }

drm_modeset_drop_locks();
drm_modeset_acquire_fini();



[PATCH v2] drm/atomic: Fix bookkeeping with TEST_ONLY, v2.

2015-08-27 Thread Daniel Stone
Hi,

On 27 August 2015 at 13:43, Maarten Lankhorst
 wrote:
> Op 27-08-15 om 14:19 schreef Daniel Stone:
>> On 4 August 2015 at 12:34, Maarten Lankhorst
>>  wrote:
>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
>> to mention this in the commit message; in this case, the main change
>> is about plane->{,old_}fb.
> Even testing with PAGE_FLIP_EVENT would be useful because
> event && !crtc_state->active should not be allowed. In that case test
> could succeed but commit could fail.

Will reply to that in the (very old) thread.

>> This is a bit nasty. Can we please move the label above the
>> conditional and change the condition to (ret || flags & TEST_ONLY)?
>> Doing that, you could also move the label above the (ret == -EDEADLK)
>> check, which would cover ->atomic_check needing to grab other states
>> (global resources?) and failing.
> If our bookkeeping is correct then it won't be harmful to fixup old_fb.
> Cleaning up more old_fb for more planes than initially had fb updates can 
> always
> happen anyway, because a modeset will add all affected planes.

It won't happen: plane_mask will always be 0, because it's only set in
the branch which is now !TEST_ONLY. So yeah, it's safe to just skip
the label completely.

> How about the below patch? Apply with git am --scissors
>
> >8--
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but allowed -EDEADLK to
> leak vblank events.
>
> Additionally check_only was updating plane->fb, which should
> not be done when checking a new configuration only.
>
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2448f42480f..78ffb4965548 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1542,7 +1542,8 @@ retry:
> copied_props++;
> }
>
> -   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
> +   if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> +   !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
> plane = obj_to_plane(obj);
> plane_mask |= (1 << drm_plane_index(plane));
> plane->old_fb = plane->fb;
> @@ -1564,10 +1565,11 @@ retry:
> }
>
> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> +   /*
> +* Unlike commit, check_only does not clean up state.
> +* Below we call drm_atomic_state_free for it.
> +*/
> ret = drm_atomic_check_only(state);
> -   /* _check_only() does not free state, unlike _commit() */
> -   if (!ret)
> -   drm_atomic_state_free(state);
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_async_commit(state);
> } else {
> @@ -1594,25 +1596,24 @@ out:
> plane->old_fb = NULL;
> }
>
> +   if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> +   if (!crtc_state->event)
> +   continue;
> +
> +   destroy_vblank_event(dev, file_priv,
> +crtc_state->event);
> +   }
> +   }

Yeah, moving this looks good for fixing the -EDEADLK leak. So, great.
Can you please add a comment above though noting that we don't need to
call this branch on (ret == 0 && flags & DRM_MODE_ATOMIC_TEST_ONLY),
as we do for freeing the state, because TEST_ONLY and PAGE_FLIP_EVENT
are mutually exclusive? Otherwise the next person to come along and
have the same idea of allowing them is probably going to break this.
:P

With that though, feel free to send it directly with:
Reviewed-by: Daniel Stone 

Cheers,
Daniel


[PATCH] drm/atomic: Make sure lock is held in trylock contexts.

2015-08-27 Thread Maarten Lankhorst
This will make sure we get a lockdep spat in all cases
even if the context is a complete garbage pointer.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 9abee87c1501..7c9ca2381d78 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -305,6 +305,8 @@ static inline int modeset_lock(struct drm_modeset_lock 
*lock,
WARN_ON(ctx->contended);

if (ctx->trylock_only) {
+   lockdep_assert_held(>ww_ctx);
+
if (!ww_mutex_trylock(>mutex))
return -EBUSY;
else



[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83226

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

(In reply to sweeneygj from comment #31)
> Should the code test both the EDID and output_csc != BYPASS before
> attempting the range change?

Yes.  Good catch.  Patch attached.

-- 
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/20150827/f3e75b79/attachment.html>


[PATCH] drm/edid: Allow comma separated edid binaries. (v2)

2015-08-27 Thread Jani Nikula
On Wed, 26 Aug 2015, Bob Paauwe  wrote:
> Allow comma separated filenames in the edid_firmware parameter.
>
> For example:
>
> edid_firmware=eDP-1:edid/1280x480.bin,DP-2:edid/1920x1080.bin
>
> v2: Use strsep() to simplify parsing of comma seperated string. (Matt)
> Move initial bail before strdup. (Matt)
>
> Reviewed-by: Matt Roper 
> Signed-off-by: Bob Paauwe 
> ---
>  drivers/gpu/drm/drm_edid_load.c | 44 
> -
>  1 file changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index c5605fe..93b9275 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -264,27 +264,53 @@ out:
>  int drm_load_edid_firmware(struct drm_connector *connector)
>  {
>   const char *connector_name = connector->name;
> - char *edidname = edid_firmware, *last, *colon;
> + char *edidname, *last, *colon, *fwstr, *edidstr, *fallback = NULL;
>   int ret;
>   struct edid *edid;
>  
> - if (*edidname == '\0')
> + if (edid_firmware[0] == '\0')
>   return 0;
>  
> - colon = strchr(edidname, ':');
> - if (colon != NULL) {
> - if (strncmp(connector_name, edidname, colon - edidname))
> - return 0;
> - edidname = colon + 1;
> - if (*edidname == '\0')
> - return 0;
> + /*
> +  * If there are multiple edid files specified and separated
> +  * by commas, search through the list looking for one that
> +  * matches the connector.
> +  *
> +  * If there's one or more that don't't specify a connector, keep
> +  * the last one found one as a fallback.
> +  */
> + fwstr = kstrdup(edid_firmware, GFP_KERNEL);
> + edidstr = fwstr;
> +
> + while ((edidname = strsep(, ","))) {
> + colon = strchr(edidname, ':');
> + if (colon != NULL) {
> + if (strncmp(connector_name, edidname, colon-edidname))
> + continue;
> + edidname = colon + 1;
> + break;
> + } else {
> + if (*edidname != '\0') /* corner case: multiple ',' */
> + fallback = edidname;
> + }
> +
>   }
>  
> + if (fallback == NULL && edidname == NULL) {
> + kfree(fwstr);
> + return 0;
> + }
> +
> + if (edidname == NULL && fallback)
> + edidname = fallback;
> +

I guess I might write that as either:

if (!edidname)
edidname = fallback;

if (!edidname) {
kfree(fwstr);
return 0;
}

or:

if (!edidname) {
if (!fallback) {
kfree(fwstr);
return 0;
}
edidname = fallback;
}

to make it faster to read, but meh. Up to you.

This will need an update to Documentation/kernel-parameters.txt
though. With that updated, this is

Reviewed-by: Jani Nikula 


>   last = edidname + strlen(edidname) - 1;
>   if (*last == '\n')
>   *last = '\0';
>  
>   edid = edid_load(connector, edidname, connector_name);
> + kfree(fwstr);
> +
>   if (IS_ERR_OR_NULL(edid))
>   return 0;
>  
> -- 
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH v3 3/3] drm/rockchip: remove rockchip_drm_encoder_get_mux_id

2015-08-27 Thread Heiko Stuebner
Hi Philipp,

Am Donnerstag, 27. August 2015, 12:56:07 schrieb Philipp Zabel:
> It is replaced by drm_of_encoder_active_endpoint_id.
> 
> Suggested-by: Daniel Kurtz 
> Reviewed-by: Daniel Kurtz 
> Signed-off-by: Philipp Zabel 

the person working the most on the rockchip dw_hdmi currently is probably 
Yakir Yang (included now).

But even to me with my general Rockchip work area outside the drm this looks 
good, as there isn't any functional change present in the moved function, so

Reviewed-by: Heiko Stuebner 


Heiko

> ---
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30
> - drivers/gpu/drm/rockchip/rockchip_drm_drv.h |
>  2 --
>  3 files changed, 1 insertion(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c index 80d6fc8..042eb95 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -201,7 +201,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct
> drm_encoder *encoder) u32 val;
>   int mux;
> 
> - mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
> + mux = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
>   if (mux)
>   val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
>   else
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 9a0c291..12094d0 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -379,36 +379,6 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
>   rockchip_drm_sys_resume)
>  };
> 
> -/*
> - * @node: device tree node containing encoder input ports
> - * @encoder: drm_encoder
> - */
> -int rockchip_drm_encoder_get_mux_id(struct device_node *node,
> - struct drm_encoder *encoder)
> -{
> - struct device_node *ep;
> - struct drm_crtc *crtc = encoder->crtc;
> - struct of_endpoint endpoint;
> - struct device_node *port;
> - int ret;
> -
> - if (!node || !crtc)
> - return -EINVAL;
> -
> - for_each_endpoint_of_node(node, ep) {
> - port = of_graph_get_remote_port(ep);
> - of_node_put(port);
> - if (port == crtc->port) {
> - ret = of_graph_parse_endpoint(ep, );
> - of_node_put(ep);
> - return ret ?: endpoint.id;
> - }
> - }
> -
> - return -EINVAL;
> -}
> -EXPORT_SYMBOL_GPL(rockchip_drm_encoder_get_mux_id);
> -
>  static int compare_of(struct device *dev, void *data)
>  {
>   struct device_node *np = data;
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h index dc4e5f0..20d6ac1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -56,8 +56,6 @@ int rockchip_register_crtc_funcs(struct drm_device *dev,
>const struct rockchip_crtc_funcs *crtc_funcs,
>int pipe);
>  void rockchip_unregister_crtc_funcs(struct drm_device *dev, int pipe);
> -int rockchip_drm_encoder_get_mux_id(struct device_node *node,
> - struct drm_encoder *encoder);
>  int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int
> connector_type, int out_mode);
>  int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,



[PATCH] drm/atomic: Fix bookkeeping with TEST_ONLY.

2015-08-27 Thread Daniel Stone
Hi,

On 4 August 2015 at 12:34, Maarten Lankhorst
 wrote:
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> In the check only case plane->fb shouldn't be updated, and
> the vblank events should be cleared as on failure.

Bikeshedding a bit ...

An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
to mention this in the commit message; in this case, the main change
is about plane->{,old_}fb.

> @@ -1532,7 +1533,7 @@ retry:
> ret = drm_atomic_check_only(state);
> /* _check_only() does not free state, unlike _commit() */
> if (!ret)
> -   drm_atomic_state_free(state);
> +   goto free;
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_async_commit(state);
> } else {
> @@ -1566,6 +1567,7 @@ out:
> }
>
> if (ret) {
> +free:

This is a bit nasty. Can we please move the label above the
conditional and change the condition to (ret || flags & TEST_ONLY)?
Doing that, you could also move the label above the (ret == -EDEADLK)
check, which would cover ->atomic_check needing to grab other states
(global resources?) and failing.

Cheers,
Daniel


[GIT PULL] Synopsis DesignWare HDMI driver development updates

2015-08-27 Thread Dave Airlie
On 22 August 2015 at 00:01, Russell King  wrote:
> I've now dropped this into linux-next so that it can get some time there,
> and still be merged during the 4.3 merge window should it open this Sunday.
>

Oh I sent the edid fix to Linus and was waiting for to backmerge before
pulling this, I've taken it now .

Dave.


[PATCH 6/6] drm/imx: enable ARGB4444 16-bit color format

2015-08-27 Thread Philipp Zabel
From: Lucas Stach 

This patch allows to use the ARGB color format on planes.

Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index c6a0973..664ed68 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -29,6 +29,7 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_XBGR1555,
DRM_FORMAT_RGBA5551,
DRM_FORMAT_BGRA5551,
+   DRM_FORMAT_ARGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
DRM_FORMAT_ABGR,
@@ -210,6 +211,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
case DRM_FORMAT_ABGR1555:
case DRM_FORMAT_RGBA5551:
case DRM_FORMAT_BGRA5551:
+   case DRM_FORMAT_ARGB:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
case DRM_FORMAT_RGBA:
-- 
2.5.0



[PATCH 5/6] gpu: ipu-v3: add support for ARGB4444 16-bit color format

2015-08-27 Thread Philipp Zabel
From: Lucas Stach 

This patch adds support for the ARGB color format.

Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c |  1 +
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index acf0729..8ba3e51 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -65,6 +65,7 @@ enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 
drm_fourcc)
case DRM_FORMAT_BGR565:
case DRM_FORMAT_RGB888:
case DRM_FORMAT_BGR888:
+   case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_RGBX:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 0e6b868..63eb16b 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -524,6 +524,14 @@ static const struct ipu_rgb def_argb_16 = {
.bits_per_pixel = 16,
 };

+static const struct ipu_rgb def_argb_16_ = {
+   .red= { .offset =  8, .length = 4, },
+   .green  = { .offset =  4, .length = 4, },
+   .blue   = { .offset =  0, .length = 4, },
+   .transp = { .offset = 12, .length = 4, },
+   .bits_per_pixel = 16,
+};
+
 static const struct ipu_rgb def_abgr_16 = {
.red= { .offset =  0, .length = 5, },
.green  = { .offset =  5, .length = 5, },
@@ -649,6 +657,9 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
case DRM_FORMAT_BGRA5551:
ipu_cpmem_set_format_rgb(ch, _bgra_16);
break;
+   case DRM_FORMAT_ARGB:
+   ipu_cpmem_set_format_rgb(ch, _argb_16_);
+   break;
default:
return -EINVAL;
}
-- 
2.5.0



[PATCH 4/6] drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats

2015-08-27 Thread Philipp Zabel
This patch allows to use the RGBX and RGBA 8:8:8:8 formats.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index e0f3082..c6a0973 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -33,6 +33,10 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ABGR,
DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGBA,
+   DRM_FORMAT_RGBX,
+   DRM_FORMAT_BGRA,
+   DRM_FORMAT_BGRA,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_YUV420,
@@ -208,6 +212,8 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_RGBA:
+   case DRM_FORMAT_BGRA:
ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
break;
default:
-- 
2.5.0



[PATCH 3/6] gpu: ipu-v3: add support for RGBX8888 and RGBA8888 pixel formats

2015-08-27 Thread Philipp Zabel
This patch adds support for the RGBA, RGBX, BGRA, and
BGRX in-memory formats.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index d26b8be..0e6b868 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -452,7 +452,7 @@ void ipu_cpmem_set_yuv_planar(struct ipuv3_channel *ch,
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_yuv_planar);

-static const struct ipu_rgb def_rgb_32 = {
+static const struct ipu_rgb def_xrgb_32 = {
.red= { .offset = 16, .length = 8, },
.green  = { .offset =  8, .length = 8, },
.blue   = { .offset =  0, .length = 8, },
@@ -460,7 +460,7 @@ static const struct ipu_rgb def_rgb_32 = {
.bits_per_pixel = 32,
 };

-static const struct ipu_rgb def_bgr_32 = {
+static const struct ipu_rgb def_xbgr_32 = {
.red= { .offset =  0, .length = 8, },
.green  = { .offset =  8, .length = 8, },
.blue   = { .offset = 16, .length = 8, },
@@ -468,6 +468,22 @@ static const struct ipu_rgb def_bgr_32 = {
.bits_per_pixel = 32,
 };

+static const struct ipu_rgb def_rgbx_32 = {
+   .red= { .offset = 24, .length = 8, },
+   .green  = { .offset = 16, .length = 8, },
+   .blue   = { .offset =  8, .length = 8, },
+   .transp = { .offset =  0, .length = 8, },
+   .bits_per_pixel = 32,
+};
+
+static const struct ipu_rgb def_bgrx_32 = {
+   .red= { .offset =  8, .length = 8, },
+   .green  = { .offset = 16, .length = 8, },
+   .blue   = { .offset = 24, .length = 8, },
+   .transp = { .offset =  0, .length = 8, },
+   .bits_per_pixel = 32,
+};
+
 static const struct ipu_rgb def_rgb_24 = {
.red= { .offset = 16, .length = 8, },
.green  = { .offset =  8, .length = 8, },
@@ -595,11 +611,19 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
break;
case DRM_FORMAT_ABGR:
case DRM_FORMAT_XBGR:
-   ipu_cpmem_set_format_rgb(ch, _bgr_32);
+   ipu_cpmem_set_format_rgb(ch, _xbgr_32);
break;
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
-   ipu_cpmem_set_format_rgb(ch, _rgb_32);
+   ipu_cpmem_set_format_rgb(ch, _xrgb_32);
+   break;
+   case DRM_FORMAT_RGBA:
+   case DRM_FORMAT_RGBX:
+   ipu_cpmem_set_format_rgb(ch, _rgbx_32);
+   break;
+   case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_BGRX:
+   ipu_cpmem_set_format_rgb(ch, _bgrx_32);
break;
case DRM_FORMAT_BGR888:
ipu_cpmem_set_format_rgb(ch, _bgr_24);
-- 
2.5.0



[PATCH 2/6] drm/imx: enable 15-bit RGB with 1-bit alpha formats

2015-08-27 Thread Philipp Zabel
This patch enables the ARGB1555, ABGR1555, RGBA5551,
and BGRA5551 formats to be used on planes.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 435eec1..e0f3082 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -23,8 +23,12 @@
 #define to_ipu_plane(x)container_of(x, struct ipu_plane, base)

 static const uint32_t ipu_plane_formats[] = {
+   DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
+   DRM_FORMAT_RGBA5551,
+   DRM_FORMAT_BGRA5551,
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
DRM_FORMAT_ABGR,
@@ -198,6 +202,10 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
/* Enable local alpha on partial plane */
switch (fb->pixel_format) {
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_ABGR1555:
+   case DRM_FORMAT_RGBA5551:
+   case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
-- 
2.5.0



[PATCH 1/6] gpu: ipu-v3: add support for 15-bit RGB with 1-bit alpha formats

2015-08-27 Thread Philipp Zabel
This patch adds support for ARGB1555, ABGR1555, RGBA5551, and BGRA5551
in-memory formats.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c |  4 
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 44 +
 2 files changed, 48 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 00f2058..acf0729 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -57,6 +57,10 @@ EXPORT_SYMBOL_GPL(ipu_srm_dp_sync_update);
 enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc)
 {
switch (drm_fourcc) {
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_ABGR1555:
+   case DRM_FORMAT_RGBA5551:
+   case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_RGB565:
case DRM_FORMAT_BGR565:
case DRM_FORMAT_RGB888:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 3bf05bc..d26b8be 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -500,6 +500,38 @@ static const struct ipu_rgb def_bgr_16 = {
.bits_per_pixel = 16,
 };

+static const struct ipu_rgb def_argb_16 = {
+   .red= { .offset = 10, .length = 5, },
+   .green  = { .offset =  5, .length = 5, },
+   .blue   = { .offset =  0, .length = 5, },
+   .transp = { .offset = 15, .length = 1, },
+   .bits_per_pixel = 16,
+};
+
+static const struct ipu_rgb def_abgr_16 = {
+   .red= { .offset =  0, .length = 5, },
+   .green  = { .offset =  5, .length = 5, },
+   .blue   = { .offset = 10, .length = 5, },
+   .transp = { .offset = 15, .length = 1, },
+   .bits_per_pixel = 16,
+};
+
+static const struct ipu_rgb def_rgba_16 = {
+   .red= { .offset = 11, .length = 5, },
+   .green  = { .offset =  6, .length = 5, },
+   .blue   = { .offset =  1, .length = 5, },
+   .transp = { .offset =  0, .length = 1, },
+   .bits_per_pixel = 16,
+};
+
+static const struct ipu_rgb def_bgra_16 = {
+   .red= { .offset =  1, .length = 5, },
+   .green  = { .offset =  6, .length = 5, },
+   .blue   = { .offset = 11, .length = 5, },
+   .transp = { .offset =  0, .length = 1, },
+   .bits_per_pixel = 16,
+};
+
 #define Y_OFFSET(pix, x, y)((x) + pix->width * (y))
 #define U_OFFSET(pix, x, y)((pix->width * pix->height) +   \
 (pix->width * (y) / 4) + (x) / 2)
@@ -581,6 +613,18 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
case DRM_FORMAT_BGR565:
ipu_cpmem_set_format_rgb(ch, _bgr_16);
break;
+   case DRM_FORMAT_ARGB1555:
+   ipu_cpmem_set_format_rgb(ch, _argb_16);
+   break;
+   case DRM_FORMAT_ABGR1555:
+   ipu_cpmem_set_format_rgb(ch, _abgr_16);
+   break;
+   case DRM_FORMAT_RGBA5551:
+   ipu_cpmem_set_format_rgb(ch, _rgba_16);
+   break;
+   case DRM_FORMAT_BGRA5551:
+   ipu_cpmem_set_format_rgb(ch, _bgra_16);
+   break;
default:
return -EINVAL;
}
-- 
2.5.0



[PATCH] drm/imx: ipuv3-plane: enforce the same physical base address for multiplanar formats

2015-08-27 Thread Philipp Zabel
The IPU IDMAC handles multiplanar formats using a base address and relative
offsets for the secondary planes. Since those offsets must be positive
and not too large and can't be changed when doing a page flip while scanout
is active, just enforce the same physical base address on all planes.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 878a643..435eec1 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -62,22 +62,45 @@ static inline int calc_bandwidth(int width, int height, 
unsigned int vref)
 int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct drm_framebuffer *fb,
   int x, int y)
 {
-   struct drm_gem_cma_object *cma_obj;
+   struct drm_gem_cma_object *cma_obj[3];
unsigned long eba;
-   int active;
+   int active, i;

-   cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
-   if (!cma_obj) {
-   DRM_DEBUG_KMS("entry is null.\n");
-   return -EFAULT;
+   for (i = 0; i < drm_format_num_planes(fb->pixel_format); i++) {
+   cma_obj[i] = drm_fb_cma_get_gem_obj(fb, i);
+   if (!cma_obj[i]) {
+   DRM_DEBUG_KMS("plane %d entry is null.\n", i);
+   return -EFAULT;
+   }
}

dev_dbg(ipu_plane->base.dev->dev, "phys = %pad, x = %d, y = %d",
-   _obj->paddr, x, y);
+   _obj[0]->paddr, x, y);

-   eba = cma_obj->paddr + fb->offsets[0] +
+   eba = cma_obj[0]->paddr + fb->offsets[0] +
  fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;

+   switch (fb->pixel_format) {
+   case DRM_FORMAT_YUV420:
+   case DRM_FORMAT_YVU420:
+   /*
+* Multiplanar formats have to meet the following restrictions:
+* - The (up to) three plane addresses are EBA, EBA+UBO, EBA+VBO
+* - EBA, UBO and VBO are a multiple of 8
+* - UBO and VBO are unsigned and not larger than 0xf8
+* - Only EBA may be changed while scanout is active
+*
+* For now, enforce the same physical base address for all
+* planes.
+*/
+   if (cma_obj[0]->paddr != cma_obj[1]->paddr ||
+   cma_obj[0]->paddr != cma_obj[2]->paddr) {
+   DRM_DEBUG_KMS("plane base addresses differ.\n");
+   return -EINVAL;
+   }
+   break;
+   }
+
if (ipu_plane->enabled) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
-- 
2.5.0



[PATCH v3 3/3] drm/rockchip: remove rockchip_drm_encoder_get_mux_id

2015-08-27 Thread Philipp Zabel
It is replaced by drm_of_encoder_active_endpoint_id.

Suggested-by: Daniel Kurtz 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 --
 3 files changed, 1 insertion(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..042eb95 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -201,7 +201,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct 
drm_encoder *encoder)
u32 val;
int mux;

-   mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
+   mux = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (mux)
val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
else
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 9a0c291..12094d0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -379,36 +379,6 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
rockchip_drm_sys_resume)
 };

-/*
- * @node: device tree node containing encoder input ports
- * @encoder: drm_encoder
- */
-int rockchip_drm_encoder_get_mux_id(struct device_node *node,
-   struct drm_encoder *encoder)
-{
-   struct device_node *ep;
-   struct drm_crtc *crtc = encoder->crtc;
-   struct of_endpoint endpoint;
-   struct device_node *port;
-   int ret;
-
-   if (!node || !crtc)
-   return -EINVAL;
-
-   for_each_endpoint_of_node(node, ep) {
-   port = of_graph_get_remote_port(ep);
-   of_node_put(port);
-   if (port == crtc->port) {
-   ret = of_graph_parse_endpoint(ep, );
-   of_node_put(ep);
-   return ret ?: endpoint.id;
-   }
-   }
-
-   return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(rockchip_drm_encoder_get_mux_id);
-
 static int compare_of(struct device *dev, void *data)
 {
struct device_node *np = data;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..20d6ac1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -56,8 +56,6 @@ int rockchip_register_crtc_funcs(struct drm_device *dev,
 const struct rockchip_crtc_funcs *crtc_funcs,
 int pipe);
 void rockchip_unregister_crtc_funcs(struct drm_device *dev, int pipe);
-int rockchip_drm_encoder_get_mux_id(struct device_node *node,
-   struct drm_encoder *encoder);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
  int out_mode);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
-- 
2.5.0



[PATCH v3 2/3] drm/imx: remove imx_drm_encoder_get_mux_id

2015-08-27 Thread Philipp Zabel
It is replaced by drm_of_encoder_active_port_id.

Suggested-by: Daniel Kurtz 
Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Add missing #include drm_of.h to imx-ldb.c
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c | 30 --
 drivers/gpu/drm/imx/imx-drm.h  |  2 --
 drivers/gpu/drm/imx/imx-ldb.c  |  5 +++--
 4 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 644edf6..4aad6bc 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -119,7 +119,7 @@ static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder 
*encoder,
 static void dw_hdmi_imx_encoder_commit(struct drm_encoder *encoder)
 {
struct imx_hdmi *hdmi = container_of(encoder, struct imx_hdmi, encoder);
-   int mux = imx_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
+   int mux = drm_of_encoder_active_port_id(hdmi->dev->of_node, encoder);

regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
   IMX6Q_GPR3_HDMI_MUX_CTL_MASK,
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 74f505b..8f85585 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -431,36 +431,6 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
 }
 EXPORT_SYMBOL_GPL(imx_drm_encoder_parse_of);

-/*
- * @node: device tree node containing encoder input ports
- * @encoder: drm_encoder
- */
-int imx_drm_encoder_get_mux_id(struct device_node *node,
-  struct drm_encoder *encoder)
-{
-   struct imx_drm_crtc *imx_crtc = imx_drm_find_crtc(encoder->crtc);
-   struct device_node *ep;
-   struct of_endpoint endpoint;
-   struct device_node *port;
-   int ret;
-
-   if (!node || !imx_crtc)
-   return -EINVAL;
-
-   for_each_endpoint_of_node(node, ep) {
-   port = of_graph_get_remote_port(ep);
-   of_node_put(port);
-   if (port == imx_crtc->crtc->port) {
-   ret = of_graph_parse_endpoint(ep, );
-   of_node_put(ep);
-   return ret ? ret : endpoint.port;
-   }
-   }
-
-   return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(imx_drm_encoder_get_mux_id);
-
 static const struct drm_ioctl_desc imx_drm_ioctls[] = {
/* none so far */
 };
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 28e776d..10ed4e1 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -45,8 +45,6 @@ int imx_drm_set_bus_format_pins(struct drm_encoder *encoder,
 int imx_drm_set_bus_format(struct drm_encoder *encoder,
u32 bus_format);

-int imx_drm_encoder_get_mux_id(struct device_node *node,
-   struct drm_encoder *encoder);
 int imx_drm_encoder_parse_of(struct drm_device *drm,
struct drm_encoder *encoder, struct device_node *np);

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index abacc8f..9a0347e 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -215,7 +216,7 @@ static void imx_ldb_encoder_commit(struct drm_encoder 
*encoder)
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
-   int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
+   int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);

drm_panel_prepare(imx_ldb_ch->panel);

@@ -265,7 +266,7 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder 
*encoder,
int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
unsigned long serial_clk;
unsigned long di_clk = mode->clock * 1000;
-   int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
+   int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);

if (mode->clock > 17) {
dev_warn(ldb->dev,
-- 
2.5.0



[PATCH v3 1/3] drm: add drm_of_encoder_active_endpoint helpers

2015-08-27 Thread Philipp Zabel
This patch adds a helper to parse the encoder endpoint connected to the
encoder's crtc and two helpers to return its id and port id.

This can be used to determine input mux setting from endpoint or port ids.

Suggested-by: Daniel Kurtz 
Reviewed-by: Daniel Kurtz 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/drm_of.c | 34 ++
 include/drm/drm_of.h | 33 +
 2 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index be38840..0c9714cd 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -61,3 +61,37 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
return possible_crtcs;
 }
 EXPORT_SYMBOL(drm_of_find_possible_crtcs);
+
+/*
+ * drm_of_encoder_active_endpoint - return the active encoder endpoint
+ * @node: device tree node containing encoder input ports
+ * @encoder: drm_encoder
+ *
+ * Given an encoder device node and a drm_encoder with a connected crtc,
+ * parse the encoder endpoint connecting to the crtc port.
+ */
+int drm_of_encoder_active_endpoint(struct device_node *node,
+  struct drm_encoder *encoder,
+  struct of_endpoint *endpoint)
+{
+   struct device_node *ep;
+   struct drm_crtc *crtc = encoder->crtc;
+   struct device_node *port;
+   int ret;
+
+   if (!node || !crtc)
+   return -EINVAL;
+
+   for_each_endpoint_of_node(node, ep) {
+   port = of_graph_get_remote_port(ep);
+   of_node_put(port);
+   if (port == crtc->port) {
+   ret = of_graph_parse_endpoint(ep, endpoint);
+   of_node_put(ep);
+   return ret;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 2441f71..efd3b44 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -1,18 +1,51 @@
 #ifndef __DRM_OF_H__
 #define __DRM_OF_H__

+#include 
+
 struct drm_device;
+struct drm_encoder;
 struct device_node;

 #ifdef CONFIG_OF
 extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
   struct device_node *port);
+extern int drm_of_encoder_active_endpoint(struct device_node *node,
+ struct drm_encoder *encoder,
+ struct of_endpoint *endpoint);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
 {
return 0;
 }
+
+static inline int drm_of_encoder_active_endpoint(struct device_node *node,
+struct drm_encoder *encoder,
+struct of_endpoint *endpoint)
+{
+   return -EINVAL;
+}
 #endif

+static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
+   struct drm_encoder *encoder)
+{
+   struct of_endpoint endpoint;
+   int ret = drm_of_encoder_active_endpoint(node, encoder,
+);
+
+   return ret ?: endpoint.id;
+}
+
+static inline int drm_of_encoder_active_port_id(struct device_node *node,
+   struct drm_encoder *encoder)
+{
+   struct of_endpoint endpoint;
+   int ret = drm_of_encoder_active_endpoint(node, encoder,
+);
+
+   return ret ?: endpoint.port;
+}
+
 #endif /* __DRM_OF_H__ */
-- 
2.5.0



[PATCH v3 0/3] drm_of_encoder_active_endpoint helpers

2015-08-27 Thread Philipp Zabel
Hi,

could I please get an Acked-by for patch 3 from someone who feels
responsible for the rockchip hdmi driver?
This patch factors out the mostly identical imx_drm_encoder_get_mux_id and
rockchip_drm_encoder_get_mux_id functions into a common helper to parse
the active endpoint and two inline functions to return its id or port id.

Changes since v2:
 - Add missing #include drm_of.h to imx-ldb.c

regards
Philipp

Philipp Zabel (3):
  drm: add drm_of_encoder_active_endpoint helpers
  drm/imx: remove imx_drm_encoder_get_mux_id
  drm/rockchip: remove rockchip_drm_encoder_get_mux_id

 drivers/gpu/drm/drm_of.c| 34 +
 drivers/gpu/drm/imx/dw_hdmi-imx.c   |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c  | 30 -
 drivers/gpu/drm/imx/imx-drm.h   |  2 --
 drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 --
 include/drm/drm_of.h| 33 
 9 files changed, 72 insertions(+), 68 deletions(-)

-- 
2.5.0



[PATCH 2/2] arm:dts:ls1021a: Add SiI902x dts node

2015-08-27 Thread Jianwei Wang
The SiI902x is a HDMI transmitter.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..c3140f0 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -79,6 +79,12 @@

  {
status = "okay";
+
+   hdmi: sii9022a at 39 {
+   compatible = "sii902x";
+   reg = <0x39>;
+   interrupts = ;
+   };
 };

  {
-- 
2.1.0.27.g96db324



[PATCH 1/2] drm/layerscape: Add HDMI support for DCU DRM driver

2015-08-27 Thread Jianwei Wang
Some Freescale SoCs, there has an DVI/HDMI controller and a PHY,
attached to one of their display controller unit's LCDC interfaces.
This patch adds a driver for SiI902x. The SiI902x is a HDMI
transmitter It supports resolutions from standard definition
480i/p and 576i/p all the way to high-definition 720p, 1080i,
and 1080p, the highest resolution supported by HDTVs today.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 .../devicetree/bindings/video/SiI902x.txt  |  17 +
 drivers/gpu/drm/fsl-dcu/Makefile   |   1 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c | 639 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  10 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h   |  10 +
 5 files changed, 677 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/SiI902x.txt
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c

diff --git a/Documentation/devicetree/bindings/video/SiI902x.txt 
b/Documentation/devicetree/bindings/video/SiI902x.txt
new file mode 100644
index 000..d304499
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/SiI902x.txt
@@ -0,0 +1,17 @@
+Device-Tree bindings for the SiI902x hdmi transmitter.
+
+Required properties:
+- compatible:  Should be "sii902x".
+- reg: The I2C address of the device.
+- interrupts:  Interrupt number to the cpu.
+
+Example:
+
+ {
+   status = "okay";
+   hdmi: sii9022a at 39 {
+ compatible = "sii902x";
+ reg = <0x39>;
+ interrupts = ;
+   };
+};
diff --git a/drivers/gpu/drm/fsl-dcu/Makefile b/drivers/gpu/drm/fsl-dcu/Makefile
index 6ea1523..98cacc2 100644
--- a/drivers/gpu/drm/fsl-dcu/Makefile
+++ b/drivers/gpu/drm/fsl-dcu/Makefile
@@ -1,6 +1,7 @@
 fsl-dcu-drm-y := fsl_dcu_drm_drv.o \
 fsl_dcu_drm_kms.o \
 fsl_dcu_drm_rgb.o \
+fsl_dcu_drm_hdmi.o \
 fsl_dcu_drm_plane.o \
 fsl_dcu_drm_crtc.o \
 fsl_dcu_drm_fbdev.o
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
new file mode 100644
index 000..b91c8ca
--- /dev/null
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
@@ -0,0 +1,639 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * Freescale DCU drm device driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "fsl_dcu_drm_drv.h"
+#include "fsl_dcu_drm_output.h"
+
+#define SII902X_INPUT_BUS_FMT  0x08
+#define SII902X_TPI_AVI_INPUT_FMT  0x09
+#define SII902X_TPI_AVI_OUTPUT_FMT 0x0A
+#define SII902X_SYS_CONTROL0x1A
+#define SII902X_SYS_CTR_DDC_REQBIT(2)
+#define SII902X_SYS_CTR_DDC_BUS_AVAI   (BIT(2) | BIT(1))
+#define SII902X_TPI_FAMILY_DEV_ID  0x1B
+#define SII902X_TPI_DEV_REV_ID 0x1C
+#define SII902X_TPI_REV_LEVEL_ID   0x1D
+#define SII902X_POWER_STATE0x1E
+#define SII902X_TPI_AUDIO_CFG0 0x24
+#define SII902X_TPI_AUDIO_CFG1 0x25
+#define SII902X_TPI_AUDIO_CFG2 0x26
+#define SII902X_TPI_AUDIO_CFG3 0x27
+#define SII902X_TPI_HDCP_REV   0x30
+#define SII902X_TPI_INT_ENABLE 0x3C
+#define SII902X_TPI_INT_STATUS 0x3D
+#define SII902X_TPI_INT_PLUG_INBIT(2)
+#define SII902X_GENERAL_PURPOSE_IO00xBC
+#define SII902X_GENERAL_PURPOSE_IO10xBD
+#define SII902X_GENERAL_PURPOSE_IO20xBE
+#define SII902X_TRANS_MODE_DIFF0xC7
+
+bool g_enable_hdmi;
+
+struct sii902x_data {
+   struct i2c_client *client;
+   struct delayed_work det_work;
+   struct fb_info *fbi;
+   struct fsl_dcu_drm_hdmicon *hdmicon;
+} *sii902x;
+
+static struct i2c_client *sii902x_to_i2c(struct sii902x_data *sii902x)
+{
+   return sii902x->client;
+}
+
+static s32 sii902x_write(const struct i2c_client *client,
+u8 command, u8 value)
+{
+   return i2c_smbus_write_byte_data(client, command, value);
+}
+
+static s32 sii902x_read(const struct i2c_client *client, u8 command)
+{
+   int val;
+
+   val = i2c_smbus_read_word_data(client, command);
+
+   return val & 0xff;
+}
+
+static void sii902x_power_up_tx(struct sii902x_data *sii902x)
+{
+   struct i2c_client *client = sii902x_to_i2c(sii902x);
+   int val;
+
+   val = sii902x_read(client, SII902X_POWER_STATE);
+   val &= ~0x3;
+   sii902x_write(client, SII902X_POWER_STATE, val);
+}
+
+static int sii902x_get_edid_preconfig(void)
+{
+   int old, dat, ret = 0, cnt = 100;
+
+   old = sii902x_read(sii902x->client, SII902X_SYS_CONTROL);
+
+   

[PATCH 1/2] drm/layerscape: Add HDMI support for DCU DRM driver

2015-08-27 Thread Rob Herring
On Wed, Aug 26, 2015 at 11:19 PM, Jianwei Wang
 wrote:
> Some Freescale SoCs, there has an DVI/HDMI controller and a PHY,
> attached to one of their display controller unit's LCDC interfaces.
> This patch adds a driver for SiI902x. The SiI902x is a HDMI
> transmitter It supports resolutions from standard definition
> 480i/p and 576i/p all the way to high-definition 720p, 1080i,
> and 1080p, the highest resolution supported by HDTVs today.
>
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> ---
>  .../devicetree/bindings/video/SiI902x.txt  |  17 +
>  drivers/gpu/drm/fsl-dcu/Makefile   |   1 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c | 639 
> +

This is a separate chip. It should not be part of the FSL DCU driver.

>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  10 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h   |  10 +
>  5 files changed, 677 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/SiI902x.txt
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
>
> diff --git a/Documentation/devicetree/bindings/video/SiI902x.txt 
> b/Documentation/devicetree/bindings/video/SiI902x.txt
> new file mode 100644
> index 000..d304499
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/SiI902x.txt
> @@ -0,0 +1,17 @@
> +Device-Tree bindings for the SiI902x hdmi transmitter.
> +
> +Required properties:
> +- compatible:  Should be "sii902x".

This should have the vendor prefix sil. It should also be specific to
which chip number. There is already a binding for the 9022 in
vexpress-v2m.dtsi, so we should use the same binding although it is
not documented. I'm not too sure about the -tpi and -cpi parts of the
binding though. It appears the device has multiple i2c addresses which
is fairly common. I would not do multiple nodes like was done. If the
secondary addresses are known or programmable thru the primary
address, we can just hardcode them in the driver (ADV7511 is an
example). If we don't know the addresses, then we can just put
multiple addresses in the reg property.

Rob

> +- reg: The I2C address of the device.
> +- interrupts:  Interrupt number to the cpu.
> +
> +Example:
> +
> + {
> +   status = "okay";
> +   hdmi: sii9022a at 39 {
> + compatible = "sii902x";
> + reg = <0x39>;
> + interrupts = ;
> +   };

You should be using the OF graph to describe the connection to the DCU output.

Rob


[PATCH 04/12] gpu: imx: fix support for interlaced modes

2015-08-27 Thread Philipp Zabel
Am Donnerstag, den 27.08.2015, 09:54 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Aug 27, 2015 at 10:39:12AM +0200, Philipp Zabel wrote:
> > Hi Russell,
> > 
> > Am Samstag, den 08.08.2015, 17:03 +0100 schrieb Russell King:
> > > The support for interlaced video modes seems to be broken; we don't use
> > > anything other than the vtotal/htotal from the timing information to
> > > define the various sync counters.
> > 
> > I finally made time to test this series:
> > 
> > Tested-by: Philipp Zabel 
> > on i.MX6 GK802 via HDMI connected to a TV (1080p60, 1080i60).
> > 
> > Unfortunately these timings are completely different from what Freescale
> > came up with for the TV Encoder on i.MX5, but the code we have currently
> > in mainline doesn't work for that either. I suppose I'll follow up with
> > a patch that adds yet another sync counter setup for the i.MX5/TVE case.
> > 
> > I'd like to take the two ipu-v3 patches, making a few small changes on
> > this one:
> 
> Please don't split the series up.  The reason it's a series is because
> there's interdependencies between the patches.

In that case, can I take the whole series? Or would you like to respin
and have my Acked-by: Philipp Zabel  with the
changes below:

> > > Freescale patches for interlaced video support contain an alternative
> > > sync counter setup, which we include here.  This setup produces the
> > > hsync and vsync via the normal counter 2 and 3, but moves the display
> > > enable signal from counter 5 to counter 6.  Therefore, we need to
> > > change the display controller setup as well.
> > > 
> > > The corresponding Freescale patches for this change are:
> > >   iMX6-HDMI-support-interlaced-display-mode.patch
> > >   IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch
> > > 
> > > This produces a working interlace format output from the IPU.
> > 
> > ... on i.MX6 via HDMI.
> 
> It should also be correct for any other source which wants interlaced
> output.

... on i.MX6, then. Right now I don't know what is the effect of the
undocumented settings on the i.MX5's IPUv3M.

> > > Signed-off-by: Russell King 
> > > ---
> > >  drivers/gpu/ipu-v3/ipu-dc.c | 18 ---
> > >  drivers/gpu/ipu-v3/ipu-di.c | 79 
> > > +
> > >  2 files changed, 51 insertions(+), 46 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
> > > index 9ef2e1f54ca4..aa560855c1dc 100644
> > > --- a/drivers/gpu/ipu-v3/ipu-dc.c
> > > +++ b/drivers/gpu/ipu-v3/ipu-dc.c
> > > @@ -183,12 +183,22 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct 
> > > ipu_di *di, bool interlaced,
> > >   }
> > >  
> > >   if (interlaced) {
> > > - dc_link_event(dc, DC_EVT_NL, 0, 3);
> > > - dc_link_event(dc, DC_EVT_EOL, 0, 2);
> > > - dc_link_event(dc, DC_EVT_NEW_DATA, 0, 1);
> > > + int word, addr;
> > > +
> > > + if (dc->di) {
> > > + addr = 1;
> > > + word = 1;
> > 
> > These two are really one and the same. The address written to the link
> > register for the given event has to point to the address of the
> > microcode instruction written to the template memory that should be
> > executed on this event.
> > 
> > I'd like to drop the word variable and use addr for both.
> 
> Ok.  As I said in the commit message, this code comes from Freescale's
> patches which I pointed to above.
[...]
> > > @@ -211,66 +215,59 @@ static void ipu_di_sync_config_interlaced(struct 
> > > ipu_di *di,
> > >   sig->mode.hback_porch + sig->mode.hfront_porch;
> > >   u32 v_total = sig->mode.vactive + sig->mode.vsync_len +
> > >   sig->mode.vback_porch + sig->mode.vfront_porch;
> > > - u32 reg;
> > >   struct di_sync_config cfg[] = {
> > >   {
> > > - .run_count = h_total / 2 - 1,
> > > - .run_src = DI_SYNC_CLK,
> > > + /* 1: internal VSYNC for each frame */
> > > + .run_count = v_total * 2 - 1,
> > > + .run_src = 3,   /* == counter 7 */
> > 
> > Do you know why this works? The Reference Manual v2 lists that value as
> > "NA" in the DI counter #1 Run Resolution field.
> 
> Yes, I noticed that Freescale were using values for the source fields
> which were marked as NA in the manual.  As it works, I can only assume
> that the engineer who came up with this setup has more knowledge than
> is public.

I'd like small a comment here that yes, we know this is marked as
NA/Reserved in the manuals.

[...]
> I went through the counter setup to understand how it works, and it
> seems correct provided you accept that the various source values do
> work as the code claims, which includes creating the vsync at the
> appropriate half-scanline position without needing this hack.
> 
> It's not easy to work back from the counter setup to get a mental
> picture of what's going on, but it is possible to do so.


[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83226

--- Comment #31 from sweeneygj at gmx.com ---
I have a DCE3 (RS880) and a monitor which supports RGB quantisation.

before executing the EDID test the values are 

radeon_encoder->output_csc = RADEON_OUTPUT_CSC_BYPASS
frame.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT

then it executes the EDID test

if (drm_rgb_quant_range_selectable(radeon_connector_edid(connector))) {
   if (radeon_encoder->output_csc == RADEON_OUTPUT_CSC_TVRGB)
  frame.quantization_range = HDMI_QUANTIZATION_RANGE_LIMITED;
   else
  frame.quantization_range = HDMI_QUANTIZATION_RANGE_FULL;  
} else {
   frame.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
}

and the monitor loses sync and displays a blank screen.

Should the code test both the EDID and output_csc != BYPASS before attempting
the range change?

-- 
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/20150827/ddf4e3e5/attachment.html>


[PATCH v2] drm/exynos: implement atomic_{begin/flush} of DECON

2015-08-27 Thread Daniel Stone
On 27 August 2015 at 10:21, Hyungwon Hwang  wrote:
> Each CRTC's atomic_{begin/flush} must stop/start the update of shadow
> registers to active register in the functions. This patch achieves these
> purpose by moving the setting of protection bits to those functions from
> decon_update_plane.
>
> v2: rebased to the branch exynos-drm-next
>
> Signed-off-by: Hyungwon Hwang 

Reviewed-by: Daniel Stone 

Cheers,
Daniel

>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 34 
> +--
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 30 ++-
>  2 files changed, 51 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 8d65e45..f24dc2d 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -219,6 +219,17 @@ static void decon_shadow_protect_win(struct 
> decon_context *ctx, int win,
> writel(val, ctx->addr + DECON_SHADOWCON);
>  }
>
> +static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
> +   struct exynos_drm_plane *plane)
> +{
> +   struct decon_context *ctx = crtc->ctx;
> +
> +   if (ctx->suspended)
> +   return;
> +
> +   decon_shadow_protect_win(ctx, plane->zpos, true);
> +}
> +
>  static void decon_update_plane(struct exynos_drm_crtc *crtc,
>struct exynos_drm_plane *plane)
>  {
> @@ -232,8 +243,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
> if (ctx->suspended)
> return;
>
> -   decon_shadow_protect_win(ctx, win, true);
> -
> val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
> writel(val, ctx->addr + DECON_VIDOSDxA(win));
>
> @@ -265,15 +274,10 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
> val |= WINCONx_ENWIN_F;
> writel(val, ctx->addr + DECON_WINCONx(win));
>
> -   decon_shadow_protect_win(ctx, win, false);
> -
> /* standalone update */
> val = readl(ctx->addr + DECON_UPDATE);
> val |= STANDALONE_UPDATE_F;
> writel(val, ctx->addr + DECON_UPDATE);
> -
> -   if (ctx->i80_if)
> -   atomic_set(>win_updated, 1);
>  }
>
>  static void decon_disable_plane(struct exynos_drm_crtc *crtc,
> @@ -301,6 +305,20 @@ static void decon_disable_plane(struct exynos_drm_crtc 
> *crtc,
> writel(val, ctx->addr + DECON_UPDATE);
>  }
>
> +static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
> +   struct exynos_drm_plane *plane)
> +{
> +   struct decon_context *ctx = crtc->ctx;
> +
> +   if (ctx->suspended)
> +   return;
> +
> +   decon_shadow_protect_win(ctx, plane->zpos, false);
> +
> +   if (ctx->i80_if)
> +   atomic_set(>win_updated, 1);
> +}
> +
>  static void decon_swreset(struct decon_context *ctx)
>  {
> unsigned int tries;
> @@ -455,8 +473,10 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
> .enable_vblank  = decon_enable_vblank,
> .disable_vblank = decon_disable_vblank,
> .commit = decon_commit,
> +   .atomic_begin   = decon_atomic_begin,
> .update_plane   = decon_update_plane,
> .disable_plane  = decon_disable_plane,
> +   .atomic_flush   = decon_atomic_flush,
> .te_handler = decon_te_irq_handler,
>  };
>
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 7651499..c74e30e 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -383,6 +383,17 @@ static void decon_shadow_protect_win(struct 
> decon_context *ctx,
> writel(val, ctx->regs + SHADOWCON);
>  }
>
> +static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
> +   struct exynos_drm_plane *plane)
> +{
> +   struct decon_context *ctx = crtc->ctx;
> +
> +   if (ctx->suspended)
> +   return;
> +
> +   decon_shadow_protect_win(ctx, plane->zpos, true);
> +}
> +
>  static void decon_update_plane(struct exynos_drm_crtc *crtc,
>struct exynos_drm_plane *plane)
>  {
> @@ -410,9 +421,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
>  * is set.
>  */
>
> -   /* protect windows */
> -   decon_shadow_protect_win(ctx, win, true);
> -
> /* buffer start address */
> val = (unsigned long)plane->dma_addr[0];
> writel(val, ctx->regs + VIDW_BUF_START(win));
> @@ -510,14 +518,22 @@ static void decon_disable_plane(struct exynos_drm_crtc 
> *crtc,
> val &= ~WINCONx_ENWIN;
> writel(val, ctx->regs + WINCON(win));
>
> -   /* unprotect windows */
> -   

[PATCH 0/9] dw-hdmi audio support

2015-08-27 Thread Philipp Zabel
Am Samstag, den 08.08.2015, 17:09 +0100 schrieb Russell King - ARM
Linux:
> Following on from the previous sub-series, this sub-series adds audio
> support to dw-hdmi.
> 
> The two different variants are now in this patch: AHB audio support
> found on iMX6 platforms, and I2S support found on Rockchip patches.
> Thanks to Yakir Yang for contributing the I2S support.
> 
> I suspect that there is still some discussion to be had on this
> series, though I would like to see it moving forward so that we can
> get something merged.

Tested-by: Philipp Zabel 
on i.MX6 GK802 via HDMI connected to a TV (stereo only).

except for the i2s patch, which is broken in this series.

regards
Philipp



[PATCH 04/12] gpu: imx: fix support for interlaced modes

2015-08-27 Thread Philipp Zabel
Hi Russell,

Am Samstag, den 08.08.2015, 17:03 +0100 schrieb Russell King:
> The support for interlaced video modes seems to be broken; we don't use
> anything other than the vtotal/htotal from the timing information to
> define the various sync counters.

I finally made time to test this series:

Tested-by: Philipp Zabel 
on i.MX6 GK802 via HDMI connected to a TV (1080p60, 1080i60).

Unfortunately these timings are completely different from what Freescale
came up with for the TV Encoder on i.MX5, but the code we have currently
in mainline doesn't work for that either. I suppose I'll follow up with
a patch that adds yet another sync counter setup for the i.MX5/TVE case.

I'd like to take the two ipu-v3 patches, making a few small changes on
this one:

> Freescale patches for interlaced video support contain an alternative
> sync counter setup, which we include here.  This setup produces the
> hsync and vsync via the normal counter 2 and 3, but moves the display
> enable signal from counter 5 to counter 6.  Therefore, we need to
> change the display controller setup as well.
> 
> The corresponding Freescale patches for this change are:
>   iMX6-HDMI-support-interlaced-display-mode.patch
>   IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch
> 
> This produces a working interlace format output from the IPU.

... on i.MX6 via HDMI.

> Signed-off-by: Russell King 
> ---
>  drivers/gpu/ipu-v3/ipu-dc.c | 18 ---
>  drivers/gpu/ipu-v3/ipu-di.c | 79 
> +
>  2 files changed, 51 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
> index 9ef2e1f54ca4..aa560855c1dc 100644
> --- a/drivers/gpu/ipu-v3/ipu-dc.c
> +++ b/drivers/gpu/ipu-v3/ipu-dc.c
> @@ -183,12 +183,22 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di 
> *di, bool interlaced,
>   }
>  
>   if (interlaced) {
> - dc_link_event(dc, DC_EVT_NL, 0, 3);
> - dc_link_event(dc, DC_EVT_EOL, 0, 2);
> - dc_link_event(dc, DC_EVT_NEW_DATA, 0, 1);
> + int word, addr;
> +
> + if (dc->di) {
> + addr = 1;
> + word = 1;

These two are really one and the same. The address written to the link
register for the given event has to point to the address of the
microcode instruction written to the template memory that should be
executed on this event.

I'd like to drop the word variable and use addr for both.

> + } else {
> + addr = 0;
> + word = 0;
> + }
> +
> + dc_link_event(dc, DC_EVT_NL, addr, 3);
> + dc_link_event(dc, DC_EVT_EOL, addr, 2);
> + dc_link_event(dc, DC_EVT_NEW_DATA, addr, 1);
>  
>   /* Init template microcode */
> - dc_write_tmpl(dc, 0, WROD(0), 0, map, SYNC_WAVE, 0, 8, 1);
> + dc_write_tmpl(dc, word, WROD(0), 0, map, SYNC_WAVE, 0, 6, 1);
>   } else {
>   if (dc->di) {
>   dc_link_event(dc, DC_EVT_NL, 2, 3);
> diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
> index a96991c5c15f..359268e3a166 100644
> --- a/drivers/gpu/ipu-v3/ipu-di.c
> +++ b/drivers/gpu/ipu-v3/ipu-di.c
> @@ -71,6 +71,10 @@ enum di_sync_wave {
>   DI_SYNC_HSYNC = 3,
>   DI_SYNC_VSYNC = 4,
>   DI_SYNC_DE = 6,
> +
> + DI_SYNC_CNT1 = 2,   /* counter >= 2 only */
> + DI_SYNC_CNT4 = 5,   /* counter >= 5 only */
> + DI_SYNC_CNT5 = 6,   /* counter >= 6 only */
>  };
>  
>  #define SYNC_WAVE 0
> @@ -211,66 +215,59 @@ static void ipu_di_sync_config_interlaced(struct ipu_di 
> *di,
>   sig->mode.hback_porch + sig->mode.hfront_porch;
>   u32 v_total = sig->mode.vactive + sig->mode.vsync_len +
>   sig->mode.vback_porch + sig->mode.vfront_porch;
> - u32 reg;
>   struct di_sync_config cfg[] = {
>   {
> - .run_count = h_total / 2 - 1,
> - .run_src = DI_SYNC_CLK,
> + /* 1: internal VSYNC for each frame */
> + .run_count = v_total * 2 - 1,
> + .run_src = 3,   /* == counter 7 */

Do you know why this works? The Reference Manual v2 lists that value as
"NA" in the DI counter #1 Run Resolution field.

>   }, {
> - .run_count = h_total - 11,
> + /* PIN2: HSYNC waveform */
> + .run_count = h_total - 1,
>   .run_src = DI_SYNC_CLK,
> - .cnt_down = 4,
> + .cnt_polarity_gen_en = 1,
> + .cnt_polarity_trigger_src = DI_SYNC_CLK,
> + .cnt_down = sig->mode.hsync_len * 2,
>   }, {
> - .run_count = v_total * 2 - 1,
> - .run_src = DI_SYNC_INT_HSYNC,
> -  

[PATCH] drm/msm/mdp5: enable clocks in hw_init and set_irqmask

2015-08-27 Thread Archit Taneja


On 08/26/2015 08:42 PM, hali at codeaurora.org wrote:
>> 2015-08-26 9:55 GMT-04:00  :
>>> Hi Archit,
>>>
 mdp5_hw_init and mdp5_set_irqmask configure registers but may not have
 clocks enabled.

 Add mdp5_enable/disable calls in these funcs to ensure clocks are
 enabled. We need this until we get proper runtime pm support.

 Signed-off-by: Archit Taneja 
 ---
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 10 --
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  2 ++
   2 files changed, 10 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
 b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
 index b1f73be..9fabfca 100644
 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
 +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
 @@ -24,9 +24,15 @@
   void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask,
uint32_t old_irqmask)
   {
 - mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_MDP_INTR_CLEAR(0),
 + struct mdp5_kms *mdp5_kms = to_mdp5_kms(mdp_kms);
 +
 + mdp5_enable(mdp5_kms);
 +
 + mdp5_write(mdp5_kms, REG_MDP5_MDP_INTR_CLEAR(0),
irqmask ^ (irqmask & old_irqmask));
 - mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_MDP_INTR_EN(0),
 irqmask);
 + mdp5_write(mdp5_kms, REG_MDP5_MDP_INTR_EN(0), irqmask);
 +
 + mdp5_disable(mdp5_kms);
   }
>>>
>>> mdp5_set_irqmask() can be invoked in atomic context, clk_prepare() is
>>> not
>>> allowed in this function because it may cause process to sleep. We can
>>> enable the clocks in the caller at initialization.

Oh, oops. I missed that.

>>
>> iirc, it will be called with at least one spinlock held..
>>
>> We do already move the enable/disable_vblank() paths off to a worker
>> so that we can ensure things are enabled before we get into
>> update_irq()..  the only other path to update_irq() should be when
>> driver code does mdp_irq_register/unregister().. so maybe we should
>> just require that the mdp4/mdp5 kms code only calls those when clk's
>> are already enabled (which should be mostly true already, I think)
>>
>> BR,
>> -R
>
> Yes, the only case that not been covered is mdp5_irq_postinstall(). We can
> enable clocks in this function. Actually, this is what we are doing in
> downstream test.

It works fine if I put it in postinstall. I'll update the patch and resend.

Thanks,
Archit

>>

   static void mdp5_irq_error_handler(struct mdp_irq *irq, uint32_t
 irqstatus)
 diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
 b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
 index 047cb04..2b760f5 100644
 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
 +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
 @@ -32,6 +32,7 @@ static int mdp5_hw_init(struct msm_kms *kms)
unsigned long flags;

pm_runtime_get_sync(dev->dev);
 + mdp5_enable(mdp5_kms);

/* Magic unknown register writes:
 *
 @@ -63,6 +64,7 @@ static int mdp5_hw_init(struct msm_kms *kms)

mdp5_ctlm_hw_reset(mdp5_kms->ctlm);

 + mdp5_disable(mdp5_kms);
pm_runtime_put_sync(dev->dev);

return 0;
 --
 The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
 Forum,
 hosted by The Linux Foundation


>>>
>>>
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


[PATCH -next] drm/vmwgfx: Allow dropped masters render-node like access on legacy nodes v2

2015-08-27 Thread Thomas Hellstrom
Applications like gnome-shell may try to render after dropping master
privileges. Since the driver should now be safe against this scenario,
allow those applications to use their legacy node like a render node.

v2: Add missing return statement.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 6 ++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index d87dce4..f143a75 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -993,10 +993,15 @@ static struct vmw_master *vmw_master_check(struct 
drm_device *dev,
}

/*
-* Check if we were previously master, but now dropped.
+* Check if we were previously master, but now dropped. In that
+* case, allow at least render node functionality.
 */
if (vmw_fp->locked_master) {
mutex_unlock(>master_mutex);
+
+   if (flags & DRM_RENDER_ALLOW)
+   return NULL;
+
DRM_ERROR("Dropped master trying to access ioctl that "
  "requires authentication.\n");
return ERR_PTR(-EACCES);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 4d0c98e..7fc3e8a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -906,6 +906,12 @@ vmw_surface_handle_reference(struct vmw_private *dev_priv,
  "surface reference.\n");
return -EACCES;
}
+   if (ACCESS_ONCE(vmw_fpriv(file_priv)->locked_master)) {
+   DRM_ERROR("Locked master refused legacy "
+ "surface reference.\n");
+   return -EACCES;
+   }
+
handle = u_handle;
}

-- 
1.7.11.7



[PATCH] drm/edid: Allow comma separated edid binaries. (v3)

2015-08-27 Thread Bob Paauwe
Allow comma separated filenames in the edid_firmware parameter.

For example:

edid_firmware=eDP-1:edid/1280x480.bin,DP-2:edid/1920x1080.bin

v2: Use strsep() to simplify parsing of comma seperated string. (Matt)
Move initial bail before strdup. (Matt)
v3: Changed conditionals after while loop to make more readable (Jani)
Updated kernel-parameters.txt to reflect changes (Jani)

Reviewed-by: Jani Nikula 
Reviewed-by: Matt Roper 
Signed-off-by: Bob Paauwe 
---
 Documentation/kernel-parameters.txt | 15 +++--
 drivers/gpu/drm/drm_edid_load.c | 42 ++---
 2 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index cd03a0f..a0cab10 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -915,11 +915,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
The filter can be disabled or changed to another
driver later using sysfs.

-   drm_kms_helper.edid_firmware=[:]
-   Broken monitors, graphic adapters and KVMs may
-   send no or incorrect EDID data sets. This parameter
-   allows to specify an EDID data set in the
-   /lib/firmware directory that is used instead.
+   drm_kms_helper.edid_firmware=[:][,[:]]
+   Broken monitors, graphic adapters, KVMs and EDIDless
+   panels may send no or incorrect EDID data sets.
+   This parameter allows to specify an EDID data sets
+   in the /lib/firmware directory that are used instead.
Generic built-in EDID data sets are used, if one of
edid/1024x768.bin, edid/1280x1024.bin,
edid/1680x1050.bin, or edid/1920x1080.bin is given
@@ -928,7 +928,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
available in Documentation/EDID/HOWTO.txt. An EDID
data set will only be used for a particular connector,
if its name and a colon are prepended to the EDID
-   name.
+   name. Each connector may use a unique EDID data
+   set by separating the files with a comma.  An EDID
+   data set with no connector name will be used for
+   any connectors not explicitly specified.

dscc4.setup=[NET]

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index c5605fe..a203e154 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -264,20 +264,44 @@ out:
 int drm_load_edid_firmware(struct drm_connector *connector)
 {
const char *connector_name = connector->name;
-   char *edidname = edid_firmware, *last, *colon;
+   char *edidname, *last, *colon, *fwstr, *edidstr, *fallback = NULL;
int ret;
struct edid *edid;

-   if (*edidname == '\0')
+   if (edid_firmware[0] == '\0')
return 0;

-   colon = strchr(edidname, ':');
-   if (colon != NULL) {
-   if (strncmp(connector_name, edidname, colon - edidname))
-   return 0;
-   edidname = colon + 1;
-   if (*edidname == '\0')
+   /*
+* If there are multiple edid files specified and separated
+* by commas, search through the list looking for one that
+* matches the connector.
+*
+* If there's one or more that don't't specify a connector, keep
+* the last one found one as a fallback.
+*/
+   fwstr = kstrdup(edid_firmware, GFP_KERNEL);
+   edidstr = fwstr;
+
+   while ((edidname = strsep(, ","))) {
+   colon = strchr(edidname, ':');
+   if (colon != NULL) {
+   if (strncmp(connector_name, edidname, colon-edidname))
+   continue;
+   edidname = colon + 1;
+   break;
+   } else {
+   if (*edidname != '\0') /* corner case: multiple ',' */
+   fallback = edidname;
+   }
+
+   }
+
+   if (!edidname) {
+   if (!fallback) {
+   kfree(fwstr);
return 0;
+   }
+   edidname = fallback;
}

last = edidname + strlen(edidname) - 1;
@@ -285,6 +309,8 @@ int drm_load_edid_firmware(struct drm_connector *connector)
*last = '\0';

edid = edid_load(connector, edidname, connector_name);
+   kfree(fwstr);
+
if (IS_ERR_OR_NULL(edid))
return 0;

-- 
2.1.0



[PATCH 04/12] gpu: imx: fix support for interlaced modes

2015-08-27 Thread Russell King - ARM Linux
On Thu, Aug 27, 2015 at 10:39:12AM +0200, Philipp Zabel wrote:
> Hi Russell,
> 
> Am Samstag, den 08.08.2015, 17:03 +0100 schrieb Russell King:
> > The support for interlaced video modes seems to be broken; we don't use
> > anything other than the vtotal/htotal from the timing information to
> > define the various sync counters.
> 
> I finally made time to test this series:
> 
> Tested-by: Philipp Zabel 
> on i.MX6 GK802 via HDMI connected to a TV (1080p60, 1080i60).
> 
> Unfortunately these timings are completely different from what Freescale
> came up with for the TV Encoder on i.MX5, but the code we have currently
> in mainline doesn't work for that either. I suppose I'll follow up with
> a patch that adds yet another sync counter setup for the i.MX5/TVE case.
> 
> I'd like to take the two ipu-v3 patches, making a few small changes on
> this one:

Please don't split the series up.  The reason it's a series is because
there's interdependencies between the patches.

> > Freescale patches for interlaced video support contain an alternative
> > sync counter setup, which we include here.  This setup produces the
> > hsync and vsync via the normal counter 2 and 3, but moves the display
> > enable signal from counter 5 to counter 6.  Therefore, we need to
> > change the display controller setup as well.
> > 
> > The corresponding Freescale patches for this change are:
> >   iMX6-HDMI-support-interlaced-display-mode.patch
> >   IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch
> > 
> > This produces a working interlace format output from the IPU.
> 
> ... on i.MX6 via HDMI.

It should also be correct for any other source which wants interlaced
output.

> > Signed-off-by: Russell King 
> > ---
> >  drivers/gpu/ipu-v3/ipu-dc.c | 18 ---
> >  drivers/gpu/ipu-v3/ipu-di.c | 79 
> > +
> >  2 files changed, 51 insertions(+), 46 deletions(-)
> > 
> > diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
> > index 9ef2e1f54ca4..aa560855c1dc 100644
> > --- a/drivers/gpu/ipu-v3/ipu-dc.c
> > +++ b/drivers/gpu/ipu-v3/ipu-dc.c
> > @@ -183,12 +183,22 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di 
> > *di, bool interlaced,
> > }
> >  
> > if (interlaced) {
> > -   dc_link_event(dc, DC_EVT_NL, 0, 3);
> > -   dc_link_event(dc, DC_EVT_EOL, 0, 2);
> > -   dc_link_event(dc, DC_EVT_NEW_DATA, 0, 1);
> > +   int word, addr;
> > +
> > +   if (dc->di) {
> > +   addr = 1;
> > +   word = 1;
> 
> These two are really one and the same. The address written to the link
> register for the given event has to point to the address of the
> microcode instruction written to the template memory that should be
> executed on this event.
> 
> I'd like to drop the word variable and use addr for both.

Ok.  As I said in the commit message, this code comes from Freescale's
patches which I pointed to above.

> > +   } else {
> > +   addr = 0;
> > +   word = 0;
> > +   }
> > +
> > +   dc_link_event(dc, DC_EVT_NL, addr, 3);
> > +   dc_link_event(dc, DC_EVT_EOL, addr, 2);
> > +   dc_link_event(dc, DC_EVT_NEW_DATA, addr, 1);
> >  
> > /* Init template microcode */
> > -   dc_write_tmpl(dc, 0, WROD(0), 0, map, SYNC_WAVE, 0, 8, 1);
> > +   dc_write_tmpl(dc, word, WROD(0), 0, map, SYNC_WAVE, 0, 6, 1);
> > } else {
> > if (dc->di) {
> > dc_link_event(dc, DC_EVT_NL, 2, 3);
> > diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
> > index a96991c5c15f..359268e3a166 100644
> > --- a/drivers/gpu/ipu-v3/ipu-di.c
> > +++ b/drivers/gpu/ipu-v3/ipu-di.c
> > @@ -71,6 +71,10 @@ enum di_sync_wave {
> > DI_SYNC_HSYNC = 3,
> > DI_SYNC_VSYNC = 4,
> > DI_SYNC_DE = 6,
> > +
> > +   DI_SYNC_CNT1 = 2,   /* counter >= 2 only */
> > +   DI_SYNC_CNT4 = 5,   /* counter >= 5 only */
> > +   DI_SYNC_CNT5 = 6,   /* counter >= 6 only */
> >  };
> >  
> >  #define SYNC_WAVE 0
> > @@ -211,66 +215,59 @@ static void ipu_di_sync_config_interlaced(struct 
> > ipu_di *di,
> > sig->mode.hback_porch + sig->mode.hfront_porch;
> > u32 v_total = sig->mode.vactive + sig->mode.vsync_len +
> > sig->mode.vback_porch + sig->mode.vfront_porch;
> > -   u32 reg;
> > struct di_sync_config cfg[] = {
> > {
> > -   .run_count = h_total / 2 - 1,
> > -   .run_src = DI_SYNC_CLK,
> > +   /* 1: internal VSYNC for each frame */
> > +   .run_count = v_total * 2 - 1,
> > +   .run_src = 3,   /* == counter 7 */
> 
> Do you know why this works? The Reference Manual v2 lists that value as
> "NA" in the DI counter #1 Run Resolution field.

Yes, I noticed that Freescale were using values for the source fields
which 

[Intel-gfx] [PATCH] drm/atomic: refuse changing CRTC for planes directly

2015-08-27 Thread Daniel Vetter
On Wed, Aug 26, 2015 at 05:51:46PM -0400, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 3:49 PM, Daniel Vetter  
> wrote:
> > Very strictly speaking this is possible if you have special hw and
> > genlocked CRTCs. In general switching a plane between two active CRTC
> > just won't work so well and is probably not tested at all. Just forbid
> > it.
> >
> > I've put this into the core since right now no helper or driver copes
> > with it, no userspace has code for it and no one asks for it. Yes
> > there's piles of corner-cases where this would be possible to do this
> > like:
> > - switch from inactive crtc to active crtc
> > - swithc from active crtc to inactive crtc
> > - genlocked display
> > - invisible plane (to do whatever)
> > - idle plane hw due to dsi cmd mode/psr
> > - whatever
> > but looking at details it's not that easy to implement this correctly.
> > Hence just put it into the core and add a comment, since the only
> > userspace we have right now for atomic (weston) doesn't want to use
> > direct plane switching either.
> 
> I suspect that eventually we'll want to make this a helper exposed to
> drivers and push this check down into the drivers.. perhaps that is
> not until weston (and/or atomic based hwc) grows driver specific
> userspace plugin type API to make smarter hw specific decisions..
> until then, this is probably the most reasonable thing to do.. so

Yeah this really is just to plug a "undefined behaviour" gap in the abi
until we know what exactly we want and have some userspace needing this.

> (w/ s/swihc/switch/ fix smashed in above)
> 
> Reviewed-by: Rob Clark 

Fixed to drm-misc, thanks for the review.
-Daniel

> 
> 
> > v2: don't bother with complexity and just outright disallow plane
> > switching without the intermediate OFF state. Simplifies drivers, we
> > don't have any hw that could do it anyway and current atomic userspace
> > (weston) works like this already anyway.
> >
> > v3: Bikeshed function name (Ville) and add comment (Rob).
> >
> > v4: Also bikeshed commit message (Rob).
> >
> > Cc: Thierry Reding 
> > Cc: Maarten Lankhorst 
> > Cc: Daniel Stone 
> > Acked-by: Daniel Stone 
> > Signed-off-by: Daniel Vetter 
> >
> > ---
> >
> > Imo this is bikeshedded enough, so either someone takes this or
> > someone else can mangle this patch more.
> > -Daniel
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 27 +++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 1066e4b658cf..40ddd6aa100f 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -663,6 +663,27 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > return 0;
> >  }
> >
> > +static bool
> > +plane_switching_crtc(struct drm_atomic_state *state,
> > +struct drm_plane *plane,
> > +struct drm_plane_state *plane_state)
> > +{
> > +   struct drm_crtc_state *crtc_state, *curr_crtc_state;
> > +
> > +   if (!plane->state->crtc || !plane_state->crtc)
> > +   return false;
> > +
> > +   if (plane->state->crtc == plane_state->crtc)
> > +   return false;
> > +
> > +   /* This could be refined, but currently there's no helper or driver 
> > code
> > +* to implement direct switching of active planes nor userspace to 
> > take
> > +* advantage of more direct plane switching without the intermediate
> > +* full OFF state.
> > +*/
> > +   return true;
> > +}
> > +
> >  /**
> >   * drm_atomic_plane_check - check plane state
> >   * @plane: plane to check
> > @@ -734,6 +755,12 @@ static int drm_atomic_plane_check(struct drm_plane 
> > *plane,
> > return -ENOSPC;
> > }
> >
> > +   if (plane_switching_crtc(state->state, plane, state)) {
> > +   DRM_DEBUG_ATOMIC("[PLANE:%d] switching CRTC directly\n",
> > +plane->base.id);
> > +   return -EINVAL;
> > +   }
> > +
> > return 0;
> >  }
> >
> > --
> > 2.5.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[PATCH 3/6] dma-buf: Add ioctls to allow userspace to flush

2015-08-27 Thread Chris Wilson
On Wed, Aug 26, 2015 at 08:29:15PM -0300, Tiago Vignatti wrote:
> +#ifndef _DMA_BUF_UAPI_H_
> +#define _DMA_BUF_UAPI_H_
> +
> +enum dma_buf_sync_flags {
> + DMA_BUF_SYNC_READ = (1 << 0),
> + DMA_BUF_SYNC_WRITE = (2 << 0),
> + DMA_BUF_SYNC_RW = (3 << 0),
> + DMA_BUF_SYNC_START = (0 << 2),
> + DMA_BUF_SYNC_END = (1 << 2),
> +
> + DMA_BUF_SYNC_VALID_FLAGS_MASK = DMA_BUF_SYNC_RW |
> + DMA_BUF_SYNC_END
> +};
> +
> +/* begin/end dma-buf functions used for userspace mmap. */
> +struct dma_buf_sync {
> + enum dma_buf_sync_flags flags;

It is better to use explicitly sized types. And since this is not 64b
padded, probably best to add that padding now.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH] drm/atomic: refuse changing CRTC for planes directly

2015-08-27 Thread Maarten Lankhorst
Op 26-08-15 om 21:49 schreef Daniel Vetter:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
>
> I've put this into the core since right now no helper or driver copes
> with it, no userspace has code for it and no one asks for it. Yes
> there's piles of corner-cases where this would be possible to do this
> like:
> - switch from inactive crtc to active crtc
> - swithc from active crtc to inactive crtc
> - genlocked display
> - invisible plane (to do whatever)
> - idle plane hw due to dsi cmd mode/psr
> - whatever
> but looking at details it's not that easy to implement this correctly.
> Hence just put it into the core and add a comment, since the only
> userspace we have right now for atomic (weston) doesn't want to use
> direct plane switching either.
>
> v2: don't bother with complexity and just outright disallow plane
> switching without the intermediate OFF state. Simplifies drivers, we
> don't have any hw that could do it anyway and current atomic userspace
> (weston) works like this already anyway.
>
> v3: Bikeshed function name (Ville) and add comment (Rob).
>
> v4: Also bikeshed commit message (Rob).
>
> Cc: Thierry Reding 
> Cc: Maarten Lankhorst 
Acked-by: Maarten Lankhorst 
> Cc: Daniel Stone 
> Acked-by: Daniel Stone 
> Signed-off-by: Daniel Vetter 
>
> ---
>
> Imo this is bikeshedded enough, so either someone takes this or
> someone else can mangle this patch more.
> -Daniel
> ---
>  drivers/gpu/drm/drm_atomic.c | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1066e4b658cf..40ddd6aa100f 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -663,6 +663,27 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   return 0;
>  }
>  
> +static bool
> +plane_switching_crtc(struct drm_atomic_state *state,
> +  struct drm_plane *plane,
> +  struct drm_plane_state *plane_state)
> +{
> + struct drm_crtc_state *crtc_state, *curr_crtc_state;
> +
> + if (!plane->state->crtc || !plane_state->crtc)
> + return false;
> +
> + if (plane->state->crtc == plane_state->crtc)
> + return false;
> +
> + /* This could be refined, but currently there's no helper or driver code
> +  * to implement direct switching of active planes nor userspace to take
> +  * advantage of more direct plane switching without the intermediate
> +  * full OFF state.
> +  */
> + return true;
> +}
> +
>  /**
>   * drm_atomic_plane_check - check plane state
>   * @plane: plane to check
> @@ -734,6 +755,12 @@ static int drm_atomic_plane_check(struct drm_plane 
> *plane,
>   return -ENOSPC;
>   }
>  
> + if (plane_switching_crtc(state->state, plane, state)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d] switching CRTC directly\n",
> +  plane->base.id);
> + return -EINVAL;
> + }
> +
>   return 0;
>  }
>  



[PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.

2015-08-27 Thread Dave Airlie
On 27 August 2015 at 00:30, Rob Herring  wrote:
> On Wed, Aug 26, 2015 at 7:09 AM, Thierry Reding
>  wrote:
>> On Wed, Aug 26, 2015 at 01:52:29PM +0200, Daniel Vetter wrote:
>>> On Tue, Aug 25, 2015 at 04:42:18PM -0400, Rob Clark wrote:
>>> > On Mon, Aug 24, 2015 at 9:47 AM, Rob Herring  
>>> > wrote:
>>> > > On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt  wrote:
>>> > >> Stephen Warren  writes:
>>> > >>
>>> > >>> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>>> >  Signed-off-by: Eric Anholt 
>>> > >>>
>>> > >>> This one definitely needs a patch description, since someone might not
>>> > >>> know what a VC4 is, and "git log" won't show the text from the binding
>>> > >>> doc itself. I'd suggest adding the initial paragraph of the binding 
>>> > >>> doc
>>> > >>> as the patch description, or more.
>>> > >>>
>>> >  diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
>>> >  b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>>> > >>
>>> >  +- hvss: List of references to HVS video scalers
>>> >  +- encoders: List of references to output encoders (HDMI, SDTV)
>>> > >>>
>>> > >>> Would it make sense to make all those nodes child node of the vc4
>>> > >>> object. That way, there's no need to have these lists of objects; they
>>> > >>> can be automatically built up as the DT is enumerated. I know that 
>>> > >>> e.g.
>>> > >>> the NVIDIA Tegra host1x binding works this way, and I think it may 
>>> > >>> have
>>> > >>> been inspired by other similar cases.
>>> > >>
>>> > >> I've looked at tegra, and the component system used by msm appears to 
>>> > >> be
>>> > >> nicer than it.  To follow tegra's model, it looks like I need to build
>>> > >> this extra bus thing corresponding to host1x that is effectively the
>>> > >> drivers/base/component.c code, so that I can get at vc4's structure 
>>> > >> from
>>> > >> the component drivers.
>>> > >>
>>> > >>> Of course, this is only appropriate if the HW modules really are
>>> > >>> logically children of the VC4 HW module. Perhaps they aren't. If they
>>> > >>> aren't though, I wonder what this "vc4" module actually represents in 
>>> > >>> HW?
>>> > >>
>>> > >> It's the subsystem, same as we use a subsystem node for msm, sti,
>>> > >> rockchip, imx, and exynos.  This appears to be the common model of how
>>> > >> the collection of graphics-related components is represented in the DT.
>>> > >
>>> > > I think most of these bindings are wrong. They are grouped together
>>> > > because that is what DRM wants not because that reflects the h/w. So
>>> > > convince me this is one block, not that it is what other people do.
>>> >
>>> > I think, when it comes to more complex driver subsystems (like drm in
>>> > particular) we have a bit of mismatch between how things look from the
>>> > "pure hw ignoring sw" perspective, and the "how sw and in particular
>>> > userspace expects things" perspective.  Maybe it is less a problem in
>>> > other subsystems, where bindings map to things that are only visible
>>> > in the kernel, or well defined devices like uart or sata controller.
>>> > But when given the choice, I'm going to err on the side of not
>>> > confusing userspace and the large software stack that sits above
>>> > drm/kms, over dt purity.
>>> >
>>> > Maybe it would be nice to have a sort of dt overlay that adds the bits
>>> > needed to tie together hw blocks that should be assembled into a
>>> > single logical device for linux and userspace (but maybe not some
>>> > other hypothetical operating system).  But so far that doesn't exist.
>>> > All we have is a hammer (devicetree), everything looks like a nail.
>>> > End result is we end up adding some things in the bindings which
>>> > aren't purely about the hw.  Until someone invents a screwdriver, I'm
>>> > not sure what else to do.  In the end, other hypothetical OS is free
>>> > to ignore those extra fields in the bindings if it doesn't need them.
>>> > So meh?
>>>
>>> I thought we agreed a while back that these kind of "pull everything for
>>> the logical device together" dt nodes which just have piles of phandles
>>> are totally accepted? At least that's the point behind the component
>>> helpers, and Eric even suggested to create dt-specific component helpers
>>> to cut down a bit on the usual boilerplate. dt maintainers are also fine
>>> with this approach afaik. From my understanding tegra with the host1x bus
>>> really is the odd one out and not the norm.
>>
>> I agree that in many aspects Tegra is somewhat special. But the same
>> principles that the host1x infrastructure uses could be implemented in a
>> similar way for other DRM drivers. You can easily collect information
>> about subdevices by walking the device tree and matching on known
>> compatible strings. And you can also instantiate the top-level device
>> from driver code rather than have it in DT. It should still be possible
>> to make this work without an artificial device node in DT. The component
>> 

[PATCH -next] drm/vmwgfx: Allow dropped masters render-node like access on legacy nodes

2015-08-27 Thread Thomas Hellstrom
Applications like gnome-shell may try to render after dropping master
privileges. Since the driver should now be safe against this scenario,
allow those applications to use their legacy node like a render node.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 5 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 03854d6..e13b20b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1052,10 +1052,15 @@ static struct vmw_master *vmw_master_check(struct 
drm_device *dev,
}

/*
-* Check if we were previously master, but now dropped.
+* Check if we were previously master, but now dropped. In that
+* case, allow at least render node functionality.
 */
if (vmw_fp->locked_master) {
mutex_unlock(>master_mutex);
+
+   if (flags & DRM_RENDER_ALLOW)
+   return NULL;
+
DRM_ERROR("Dropped master trying to access ioctl that "
  "requires authentication.\n");
return ERR_PTR(-EACCES);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 5b8595b..4f0794d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -911,6 +911,11 @@ vmw_surface_handle_reference(struct vmw_private *dev_priv,
  "surface reference.\n");
return -EACCES;
}
+   if (ACCESS_ONCE(vmw_fpriv(file_priv)->locked_master)) {
+   DRM_ERROR("Locked master refused legacy "
+ "surface reference.\n");
+   }
+
handle = u_handle;
}

-- 
2.4.3



[Bug 91516] Hang on Dota 2 Reborn with Unsafe Math

2015-08-27 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91516

sarnex  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from sarnex  ---
I cannot reproduce this on llvm git, older llvm, or older mesa. Maybe the game
changed.

-- 
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/20150827/136c9ca9/attachment.html>