[PATCH 0/5] drm/exynos: rework layer blending setup

2015-05-21 Thread Tobias Jakobi
Gentle reminder that I still haven't heard anything about the series by
the Samsung guys ;)

With best wishes,
Tobias


Tobias Jakobi wrote:
> Hello,
> 
> this is a rework of the layer blending setup in the Exynos DRM mixer. The 
> current setup is static and spread out through the mixer code. This rework 
> pushes all the configuration details into a layer_config array, which 
> specifies the priority of each layer.
> 
> Two arrays are currently found in the code, one for SoC versions with a video 
> processor (VP) and one for SoC versions without VP. The VP gives us one 
> additional layer, the video layer, which natively supports the NV12/NV21 
> pixelformat.
> 
> The blending setup roughly works like this:
> 1) Find the bottom-most enabled layer. Disable all blending for this layer. 
> This is done because we currently don't expose modification of the mixer 
> background to userspace. Once this is done we can add more flexibility here.
> 2) Find the next enabled layer in our layer stack. If the layer has a 
> framebuffer with an alpha-pixelformat attached, enable blending for this 
> layer. If not, disable blending.
> 3) Iterate (2) until all enabled layers are processed.
> 
> The series has been tested on a Hardkernel Odroid-X2 (Exynos4412, which has a 
> VP).
> 
> If you want to use libdrm's modetest to check the series, please apply 
> patches [1] and [2]. This should make it possible to also test a plane with 
> NV12 format (which is located 'behind' the primary plane).
> 
> With best wishes,
> Tobias
> 
> [1] https://patchwork.kernel.org/patch/6349241/
> [2] https://patchwork.kernel.org/patch/6349261/
> 
> 
> Tobias Jakobi (5):
>   drm/exynos: mixer: refactor layer setup
>   drm/exynos: mixer: introduce mixer_layer_blending()
>   drm/exynos: mixer: remove all static blending setup
>   drm/exynos: mixer: do blending setup in mixer_cfg_layer()
>   drm/exynos: mixer: also allow ARGB1555 and ARGB
> 
>  drivers/gpu/drm/exynos/exynos_mixer.c | 246 
> +-
>  drivers/gpu/drm/exynos/regs-mixer.h   |   1 +
>  2 files changed, 213 insertions(+), 34 deletions(-)
> 



[PATCH v4] drm/exynos: calculate vrefresh instead of use a fixed value

2015-05-21 Thread Tobias Jakobi
From: Gustavo Padovan 

When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.

Suggested-by: Daniel Stone 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a0edab8..780c9df 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -41,7 +41,6 @@
  * CPU Interface.
  */

-#define FIMD_DEFAULT_FRAMERATE 60
 #define MIN_FB_WIDTH_FOR_16WORD_BURST 128

 /* position control register for hardware window 0, 2 ~ 4.*/
@@ -329,7 +328,9 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
 {
if (adjusted_mode->vrefresh == 0)
-   adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
+   adjusted_mode->vrefresh = drm_mode_vrefresh(mode);
+   if (adjusted_mode->vrefresh == 0)
+   return false;

return true;
 }
@@ -337,11 +338,16 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc *crtc,
 static void fimd_commit(struct exynos_drm_crtc *crtc)
 {
struct fimd_context *ctx = crtc->ctx;
-   struct drm_display_mode *mode = >base.mode;
+   struct drm_display_mode *mode;
struct fimd_driver_data *driver_data = ctx->driver_data;
void *timing_base = ctx->regs + driver_data->timing_base;
u32 val, clkdiv;

+   if (crtc->base.state)
+   mode = >base.state->adjusted_mode;
+   else
+   mode = >base.mode;
+
if (ctx->suspended)
return;

-- 
2.0.5



[Nouveau] [PATCH v2] nouveau: add coherent BO attribute

2015-05-21 Thread Martin Peres
On 21/05/2015 11:47, Ben Skeggs wrote:
> On 21 May 2015 at 16:08, Alexandre Courbot  wrote:
>> Add a flag allowing Nouveau to specify that an object should be coherent
>> at allocation time. This is required for some class of objects like
>> fences which are randomly-accessed by both the CPU and GPU. This flag
>> instructs the kernel driver to make sure the object remains coherent
>> even on architectures for which coherency is not guaranteed by the bus.
>>
>> Signed-off-by: Alexandre Courbot 
> Reviewed-by: Ben Skeggs 

Pushed!


[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

2015-05-21 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=98751

--- Comment #3 from Mikkel Oscar Lyderik  ---
Created attachment 177571
  --> https://bugzilla.kernel.org/attachment.cgi?id=177571=edit
xorg log

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


[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

2015-05-21 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=98751

--- Comment #2 from Mikkel Oscar Lyderik  ---
Created attachment 177561
  --> https://bugzilla.kernel.org/attachment.cgi?id=177561=edit
dmesg

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


[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

2015-05-21 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=98751

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.

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


[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

2015-05-21 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=98751

Mikkel Oscar Lyderik  changed:

   What|Removed |Added

 CC||mikkeloscar at gmail.com
 Regression|No  |Yes
   Severity|high|normal

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


[Bug 98751] New: radeon: multihead "no signal" on one of the monitors - regression

2015-05-21 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=98751

Bug ID: 98751
   Summary: radeon: multihead "no signal" on one of the monitors -
regression
   Product: Drivers
   Version: 2.5
Kernel Version: 4.0.3+
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: mikkeloscar at gmail.com
Regression: No

Since this commit:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d5c3b64
one of my two monitors doesn't get a signal (it just says "no signal").

The monitors are connected to a Radeon HD 6990 card. One is connected through
HDMI and one through DVI. I'm using the radeon driver.

Most of the time it is the monitor connected through HDMI which doesn't get a
signal, but I was able to switch it around somehow by messing around with
screen orientation in X (not quite sure how to replicate or if it's even
relevant).

I tried to revert the commit in kernel 4.0.4 (latest I tried) and that solves
the problem for me.

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


[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Tobias Jakobi
Gustavo Padovan wrote:
> 2015-05-21 Tobias Jakobi :
> 
>> Gustavo Padovan wrote:
>>> 2015-05-21 Gustavo Padovan :
>>>
 2015-05-21 Tobias Jakobi :

> Hi,
>
> like I said before, this clashes with my commit 'drm/exynos: plane: honor
> buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58),
> which is currently sitting in airlied's drm-fixes.

 Inki has to merge his -fixes tree into exynos-drm-next to solve this.
 It is the only way I can rebase on top of your commit and solve the
 conflict.
 Anyway, I just figured that exynos-drm-next was updated from yesterday
 to today so this v5 doesn't apply on today's tree. I'll send a v6 once
 Inki merges "drm/exynos: plane: honor buffer offset for dma_addr" into
 exynos-drm-next.

 Inki, can you please do that? so we can proceed with atomic and
 hopefully have it ready for 4.2 merge window.
>>>
>>> Actually the patch is on exynos-drm-next but with a different commit id.
>>> I wonder why. Why did you applied it directly to your branch instead of
>>> merging the -fixes tree? Now we have the same commit with the differents
>>> hashes in the tree.
>> I never do merges for my tree, I always rebase (either on stable/linux
>> or torvalds/master). For submitting patches I cherry-pick stuff to the
>> corresponding upstream branch (exynos-drm-next in this case) and then
>> submit via git-send-email.
> 
> Actually I'm asking Inki. He pushed the same patch twice.
Ah, sorry, I'm getting confused here! :D


> 
>   Gustavo
> 



[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90537

--- Comment #5 from pstglia at gmail.com ---
Hi Christian,

> Watch out for memory leaks as well.
> 
> When mesa drops the last reference to the BO by closing it's handle the VA
> mapping should go away automatically. That's the reason why it works for X
> and EGL.
> 
> What you see here is that you manually need to remove the VA mapping because
> there is still a reference to the BO outside of mesa.
> 
> Could be intentional, but could be a bug as well.

Thanks for pointing this out. Just a question: In this case (bug on application
on mapping BOs/VAs) shouldn't we have a crash using other drivers? With r600g
we don't have this problem (tested with an ARUBA A10 5800K), just on radeonsi
(at least on the tests I performed, which are basically running "Antutu
Benchmark" and some other apps).

However r600g/other drivers/hardwares can handle this in a different manner of
course, which could explain why we don't experience this on other hardwares.

> 
> Anyway Michels patch is clearly a good idea.

I've uploaded an testing Android-x86 ISO with Michel patch applied. It's using
Lollipop (5.1), Mesa 10.5.4, Kernel 4.0.3 and LLVM 3.5svn (AOSP). It's also
enabled for radeonsi (this is the main purpose). In case anyone wants to test
it on a radeonsi hardware, here's the link:
https://drive.google.com/file/d/0Bx12U5yGNcQCRWdoWWtNdC0weW8/view?usp=sharing

Thank you all!

pstglia

-- 
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/20150521/8901620c/attachment-0001.html>


[RESEND PATCH 2/2] modetest: only select plane with matching format

2015-05-21 Thread Tobias Jakobi
Hey Emil,

Emil Velikov wrote:
> Hi Tobias
> 
> On 12 May 2015 at 21:17, Tobias Jakobi  
> wrote:
>> Don't assume that a plane supports any kind of pixelformat
>> but do a check first.
>>
>> v2: Simplify the format check.
>> Signed-off-by: Tobias Jakobi 
> Nice catch ! I will push the tomorrow, unless we hear any objections against 
> it.
> 
> Patch 1/2 looks sane imho, although I'm not sure if some of the teams
> has some (automated?) testing which depends on the lack of
> transparency.
I'm not sure what you mean by that ('lack of transparency'). If you
create your primary plane with a XRGB-type format then this patch
doesn't change anything. If you create it with an ARGB-type format then
I can assume that the user wants an alpha-channel (he explicitly asks
for it).

With best wishes,
Tobias


> Curious if pinging people (check git log for a list) at
> #dri-devel or via email might show such users ?
> 
> Cheers,
> Emil
> 



[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Tobias Jakobi
Gustavo Padovan wrote:
> 2015-05-21 Gustavo Padovan :
> 
>> 2015-05-21 Tobias Jakobi :
>>
>>> Hi,
>>>
>>> like I said before, this clashes with my commit 'drm/exynos: plane: honor
>>> buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58),
>>> which is currently sitting in airlied's drm-fixes.
>>
>> Inki has to merge his -fixes tree into exynos-drm-next to solve this.
>> It is the only way I can rebase on top of your commit and solve the
>> conflict.
>> Anyway, I just figured that exynos-drm-next was updated from yesterday
>> to today so this v5 doesn't apply on today's tree. I'll send a v6 once
>> Inki merges "drm/exynos: plane: honor buffer offset for dma_addr" into
>> exynos-drm-next.
>>
>> Inki, can you please do that? so we can proceed with atomic and
>> hopefully have it ready for 4.2 merge window.
> 
> Actually the patch is on exynos-drm-next but with a different commit id.
> I wonder why. Why did you applied it directly to your branch instead of
> merging the -fixes tree? Now we have the same commit with the differents
> hashes in the tree.
I never do merges for my tree, I always rebase (either on stable/linux
or torvalds/master). For submitting patches I cherry-pick stuff to the
corresponding upstream branch (exynos-drm-next in this case) and then
submit via git-send-email.

With best wishes,
Tobias

> 
>   Gustavo
> 



[PATCH] drm/nouveau: add nv_error_ratelimited()

2015-05-21 Thread Rob Clark
When things go badly, the log is flooded with SCHED_ERROR messages,
which is less than useful.  Instead lets ratelimit these so we can
still find the traces leading up to the problems.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/nouveau/include/nvkm/core/printk.h | 9 +
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c   | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c   | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/printk.h 
b/drivers/gpu/drm/nouveau/include/nvkm/core/printk.h
index 8364817..aad5a54 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/printk.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/printk.h
@@ -14,6 +14,15 @@ nv_printk_(struct nvkm_object *, int, const char *, ...);

 #define nv_fatal(o,f,a...) nv_printk((o), FATAL, f, ##a)
 #define nv_error(o,f,a...) nv_printk((o), ERROR, f, ##a)
+#define nv_error_ratelimited(o,f,a...) \
+({ \
+   static DEFINE_RATELIMIT_STATE(_rs,  \
+ DEFAULT_RATELIMIT_INTERVAL,   \
+ DEFAULT_RATELIMIT_BURST); \
+   \
+   if (__ratelimit(&_rs))  \
+   nv_printk((o), ERROR, f, ##a);  \
+})
 #define nv_warn(o,f,a...) nv_printk((o), WARN, f, ##a)
 #define nv_info(o,f,a...) nv_printk((o), INFO, f, ##a)
 #define nv_debug(o,f,a...) nv_printk((o), DEBUG, f, ##a)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
index b745252..d0f47f0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
@@ -523,7 +523,7 @@ gf100_fifo_intr_sched(struct gf100_fifo_priv *priv)
if (!en)
snprintf(enunk, sizeof(enunk), "UNK%02x", code);

-   nv_error(priv, "SCHED_ERROR [ %s ]\n", en ? en->name : enunk);
+   nv_error_ratelimited(priv, "SCHED_ERROR [ %s ]\n", en ? en->name : 
enunk);

switch (code) {
case 0x0a:
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index e10f964..ac67d0b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -576,7 +576,7 @@ gk104_fifo_intr_sched(struct gk104_fifo_priv *priv)
if (!en)
snprintf(enunk, sizeof(enunk), "UNK%02x", code);

-   nv_error(priv, "SCHED_ERROR [ %s ]\n", en ? en->name : enunk);
+   nv_error_ratelimited(priv, "SCHED_ERROR [ %s ]\n", en ? en->name : 
enunk);

switch (code) {
case 0x0a:
-- 
2.4.1



[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90537

--- Comment #4 from Christian König  ---
Watch out for memory leaks as well.

When mesa drops the last reference to the BO by closing it's handle the VA
mapping should go away automatically. That's the reason why it works for X and
EGL.

What you see here is that you manually need to remove the VA mapping because
there is still a reference to the BO outside of mesa.

Could be intentional, but could be a bug as well.

Anyway Michels patch is clearly a good idea.

-- 
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/20150521/210b1b4c/attachment.html>


[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90537

--- Comment #3 from pstglia at gmail.com ---
Hi Michel,

Thanks a lot for your help!

I tested the patch with AMD E1 2100 (KANIBI) and it worked ok (no more
conflicts on bo/va - used kernel 4.0.3 as you pointed). The same app which was
producing the crash (Antutu Benchmark) was executed successfully (2d and 3d
tests).

Now I'm uploading the patched ISO. Will ask on Android-x86 message group for
more volunteers to test it, just to confirm it's ok on more hardwares. I'll
post the ISO link here when upload is complete.


Again, thanks a lot for your nice work!

pstglia

-- 
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/20150521/a5bf016a/attachment.html>


[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

2015-05-21 Thread Thomas Hellstrom
On 05/21/2015 06:07 PM, Daniel Vetter wrote:
> On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote:
>> For actual sharing of buffers with other drivers (ie. actual hardware)
>> we'll need to pimp things out a bit better to deal w/ caching, multiple
>> memory domains, etc.  See thread:
>>
>>   
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html=AwIDAw=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=5PY5xMHJsYyknpy_IWAegxqACOaf4x60CKosyG0oxCw=ciVeRE10840cewxQSgbJ_4YfCH6tU8A1o58k0tHgkD8=
>>  
>>
>> But for the llvmpipe use-case this isn't a problem.  Nor do we really
>> need prime/dri3 (dri2 is sufficient).  So until the other issues are
>> sorted lets remove DRIVER_PRIME.
>>
>> v2: also drop the dead code
>>
>> Signed-off-by: Rob Clark 
> Yeah I'm ok with this too, but it pretty much means vgem is a thing for
> llvmpipe only. And then abusing dumb buffers is imo ok too, since I don't
> care too much what kind of horrors drivers pull of internally.
>
> Acked-by: Daniel Vetter 
>
>
Well in the end, I'm happy whatever way as long as the root problem is
solved.

Acked-by: Thomas Hellstrom 




[Nouveau] [PATCH v2] nouveau: add coherent BO attribute

2015-05-21 Thread Ben Skeggs
On 21 May 2015 at 16:08, Alexandre Courbot  wrote:
> Add a flag allowing Nouveau to specify that an object should be coherent
> at allocation time. This is required for some class of objects like
> fences which are randomly-accessed by both the CPU and GPU. This flag
> instructs the kernel driver to make sure the object remains coherent
> even on architectures for which coherency is not guaranteed by the bus.
>
> Signed-off-by: Alexandre Courbot 
Reviewed-by: Ben Skeggs 

> ---
> Changes since v1:
> None, just added Martin so he can merge the patch. R-b and A-b wanted. :)
>
>  include/drm/nouveau_drm.h | 1 +
>  nouveau/abi16.c   | 3 +++
>  nouveau/nouveau.h | 1 +
>  3 files changed, 5 insertions(+)
>
> diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
> index b18cad02419b..87aefc5e9d2f 100644
> --- a/include/drm/nouveau_drm.h
> +++ b/include/drm/nouveau_drm.h
> @@ -96,6 +96,7 @@ struct drm_nouveau_setparam {
>  #define NOUVEAU_GEM_DOMAIN_VRAM  (1 << 1)
>  #define NOUVEAU_GEM_DOMAIN_GART  (1 << 2)
>  #define NOUVEAU_GEM_DOMAIN_MAPPABLE  (1 << 3)
> +#define NOUVEAU_GEM_DOMAIN_COHERENT  (1 << 4)
>
>  #define NOUVEAU_GEM_TILE_LAYOUT_MASK 0xff00
>  #define NOUVEAU_GEM_TILE_16BPP   0x0001
> diff --git a/nouveau/abi16.c b/nouveau/abi16.c
> index 538f3a730dbe..4ca0bfbaf592 100644
> --- a/nouveau/abi16.c
> +++ b/nouveau/abi16.c
> @@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment,
> if (bo->flags & NOUVEAU_BO_MAP)
> info->domain |= NOUVEAU_GEM_DOMAIN_MAPPABLE;
>
> +   if (bo->flags & NOUVEAU_BO_COHERENT)
> +   info->domain |= NOUVEAU_GEM_DOMAIN_COHERENT;
> +
> if (!(bo->flags & NOUVEAU_BO_CONTIG))
> info->tile_flags = NOUVEAU_GEM_TILE_NONCONTIG;
>
> diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
> index a55e2b020778..4adda0e3594c 100644
> --- a/nouveau/nouveau.h
> +++ b/nouveau/nouveau.h
> @@ -127,6 +127,7 @@ union nouveau_bo_config {
>  #define NOUVEAU_BO_MAP 0x8000
>  #define NOUVEAU_BO_CONTIG  0x4000
>  #define NOUVEAU_BO_NOSNOOP 0x2000
> +#define NOUVEAU_BO_COHERENT 0x1000
>
>  struct nouveau_bo {
> struct nouveau_device *device;
> --
> 2.4.0
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau


[PATCH 3/4] drm/tegra: Add VIC support

2015-05-21 Thread Mikko Perttunen
On 05/21/2015 06:10 PM, Arto Merilainen wrote:
> ...
>>> +
>>> +vic->rst = devm_reset_control_get(dev, "vic03");
>>
>> I might prefer just "vic" as the clock/reset name. The name is often
>> used as a sort of "role" for the clock/reset for the device, not
>> necessarily the raw name of the "correct" clock/reset.
>>
>
> I considered that - but I then noticed that
> drivers/clk/tegra/clk-tegra124.c was already using vic03 variant. I can
> write a patch for changing that too.

Well, the two can be different; the clock-name in device tree kind of 
means "string that i use to refer to a clock that powers the VIC unit". 
It's not really a big deal though, both ways are used in DT bindings.

Mikko



[RFC PATCH] perf: enable fsync to flush buffered samples

2015-05-21 Thread Robert Bragg
Instead of having a PERF_EVENT_IOC_FLUSH ioctl this instead allows
userspace to use fsync for flushing pmu samples, as suggested by Ingo
Molnar - thanks.

For reference I've also pushed a patch to my Mesa branch to test
this: https://github.com/rib/mesa wip/rib/oa-hsw-4.0.0

- Robert

--- >8 ---

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

Signed-off-by: Robert Bragg 
---
 include/linux/perf_event.h |  7 +++
 kernel/events/core.c   | 23 +++
 2 files changed, 30 insertions(+)

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

 /**
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2ba89a1..a604e0c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4728,6 +4728,28 @@ static int perf_fasync(int fd, struct file *filp, int on)
return 0;
 }

+static int perf_fsync(struct file *filp, loff_t start, loff_t end, int 
datasync)
+{
+   struct perf_event *event = filp->private_data;
+   struct perf_event_context *ctx;
+   int ret;
+
+   /* We don't have a use for synchonizing a specific range, or datasync
+* but lets not silently ignore them in case we think of uses later...
+*/
+   if (start != 0 || end != LLONG_MAX || datasync != 0)
+   return -EINVAL;
+
+   if (!event->pmu->flush)
+   return 0;
+
+   ctx = perf_event_ctx_lock(event);
+   ret = event->pmu->flush(event);
+   perf_event_ctx_unlock(event, ctx);
+
+   return ret;
+}
+
 static const struct file_operations perf_fops = {
.llseek = no_llseek,
.release= perf_release,
@@ -4737,6 +4759,7 @@ static const struct file_operations perf_fops = {
.compat_ioctl   = perf_compat_ioctl,
.mmap   = perf_mmap,
.fasync = perf_fasync,
+   .fsync  = perf_fsync,
 };

 /*
-- 
2.4.1



[PATCH 1/2] drm/nouveau: add staging module option

2015-05-21 Thread Ben Skeggs
On 21 May 2015 at 16:04, Alexandre Courbot  wrote:
> On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs  wrote:
>> On 21 May 2015 at 15:49, Alexandre Courbot  wrote:
>>> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs  wrote:
 On 20 May 2015 at 15:56, Alexandre Courbot  wrote:
> Add a module option allowing to enable staging/unstable APIs. This will
> allow us to experiment freely with experimental APIs for a while before
> setting them in stone.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  drm/nouveau/nouveau_drm.c  | 18 ++
>  drm/nouveau/uapi/drm/nouveau_drm.h |  3 +++
>  2 files changed, 21 insertions(+)
>
> diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
> index 89049335b738..e4bd6ed51e73 100644
> --- a/drm/nouveau/nouveau_drm.c
> +++ b/drm/nouveau/nouveau_drm.c
> @@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable 
> (1), optimus only default (-1
>  int nouveau_runtime_pm = -1;
>  module_param_named(runpm, nouveau_runtime_pm, int, 0400);
>
> +MODULE_PARM_DESC(staging, "enable staging APIs");
> +int nouveau_staging = 0;
> +module_param_named(staging, nouveau_staging, int, 0400);
> +
>  static struct drm_driver driver_stub;
>  static struct drm_driver driver_pci;
>  static struct drm_driver driver_platform;
> @@ -895,6 +899,7 @@ nouveau_ioctls[] = {
> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, 
> nouveau_gem_ioctl_cpu_prep, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, 
> nouveau_gem_ioctl_cpu_fini, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
> +   /* Staging ioctls */
>  };
>
>  long
> @@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
> DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
> DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
> DRM_DEBUG_DRIVER("... pstate   : %d\n", nouveau_pstate);
> +   DRM_DEBUG_DRIVER("... staging  : %d\n", nouveau_staging);
>  }
>
>  static const struct dev_pm_ops nouveau_pm_ops = {
> @@ -1088,6 +1094,18 @@ err_free:
>  static int __init
>  nouveau_drm_init(void)
>  {
> +   /* Do not register staging ioctsl if option not specified */
> +   if (!nouveau_staging) {
> +   unsigned i;
> +
> +   /* This keeps us safe is no staging ioctls are defined */
> +   i = min(driver_stub.num_ioctls, 
> DRM_NOUVEAU_STAGING_IOCTL);
> +   while (!nouveau_ioctls[i - 1].func)
> +   i--;
> +
> +   driver_stub.num_ioctls = i;
> +   }
 Hey Alex,

 I've got no specific objection.  But I'm curious as to why you took
 this approach as opposed to just adding "if (!nouveau_staging) return
 -EINVAL;" directly in the experimental ioctls?
>>>
>>> Mainly because we will likely forget to add this check (or to remove
>>> it) in some of the staging ioctls. The current solution doesn't
>>> require us to think about that - and the less things to think about,
>>> the better.
>>>
 I think, in line with
 what's been done in other places, having module options per-api is
 perhaps a better choice too.
>>>
>>> Do you mean that each experimental ioctl should have its own enable
>>> option? I don't mind going that way if you think it is preferable. And
>>> in that case my comment above is void.
>> That would be more preferable I think, and obvious as to what exactly
>> you're enabling.
>>
>>>
>>> But actually I wonder if having these experimental ioctls enabled as
>>> compile options (either individually or as a whole) would not be
>>> better. Some experimental ioctls may require code in staging (like the
>>> PUSHBUF_2 ioctl that I would like to submit next), and I don't think
>>> it is desirable to force extra code or kernel options (in this case,
>>> CONFIG_STAGING) to Nouveau users who will not make use of them. I
>>> remember that we concluded in favor or module options on IRC, but in
>>> the light of this, wouldn't a config option be a less intrusive
>>> choice?
>> Right, but the whole point of this is to encourage the ioctls to not
>> live there for too long, and progress to fully supported interfaces.
>
> Definitely, but my concern is that doing this will make Nouveau depend
> on STAGING for at least short periods of time. Do we really want this?
I admit to having slightly misread your last paragraph.  For cases
such as thas, a config option that depends on STAGING *and* the kernel
parameter should be used.

What is pushbuf2 doing that requires staging btw?  You've linked me to
patches previously, but I missed that.

Ben.


[PATCH libdrm] tegra: Add VIC clear test

2015-05-21 Thread Arto Merilainen
Thank you Emil for your feedback,

On 05/21/2015 05:58 PM, Emil Velikov wrote:
> Hi Arto,
>
> On 21 May 2015 at 14:18, Arto Merilainen  wrote:
>> This patch adds a simple test for testing Video-Image-Compositor
>> engine on Tegra124 SoC. The test case opens a channel and performs
>> a surface clear.
>>
>> Signed-off-by: Arto Merilainen 
>> ---
>>   tests/tegra/Makefile.am  |   3 +-
>>   tests/tegra/host1x.h |  52 ++
>>   tests/tegra/submit_vic.c | 315 +++
>>   tests/tegra/vic.h| 426 
>> +++
>>   4 files changed, 795 insertions(+), 1 deletion(-)
>>   create mode 100644 tests/tegra/host1x.h
>>   create mode 100644 tests/tegra/submit_vic.c
>>   create mode 100644 tests/tegra/vic.h
>>
>
> Please add the two new headers into the noinst_HEADERS list like
> below. Otherwise they won''t end up in the tarball, thus the test will
> fail to build.

I will fix this in the next version.

- Arto


[PATCH 3/4] drm/tegra: Add VIC support

2015-05-21 Thread Arto Merilainen
Thank you Mikko for your comments!

Please see my answers inline.

- Arto

On 05/21/2015 05:40 PM, Mikko Perttunen wrote:
> Hi, very good patch!
>
> Here are a few small comments. Aside those, you should also add a
> section to
> Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt in a
> separate patch.

Will do.

> On 05/21/2015 04:20 PM, Arto Merilainen wrote:
>> This patch adds support for Video Image Compositor engine which
>> can be used for 2d operations.
>>
>> The engine has a microcontroller (Falcon) that acts as a frontend
>> for the rest of the unit. In order to properly utilize the engine,
>> the frontend must be booted before pushing any commands.
>>
>> Signed-off-by: Andrew Chew 
>> Signed-off-by: Arto Merilainen 
>> ---
>>   drivers/gpu/drm/tegra/Makefile |   3 +-
>>   drivers/gpu/drm/tegra/drm.c|   9 +-
>>   drivers/gpu/drm/tegra/drm.h|   1 +
>>   drivers/gpu/drm/tegra/vic.c| 593 
>> +
>>   drivers/gpu/drm/tegra/vic.h| 116 
>>   include/linux/host1x.h |   1 +
>>   6 files changed, 721 insertions(+), 2 deletions(-)
>>   create mode 100644 drivers/gpu/drm/tegra/vic.c
>>   create mode 100644 drivers/gpu/drm/tegra/vic.h
>>
>> diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
>> index 2c66a8db9da4..3bc3566e00b6 100644
>> --- a/drivers/gpu/drm/tegra/Makefile
>> +++ b/drivers/gpu/drm/tegra/Makefile
>> @@ -13,6 +13,7 @@ tegra-drm-y := \
>>  sor.o \
>>  dpaux.o \
>>  gr2d.o \
>> -gr3d.o
>> +gr3d.o \
>> +vic.o
>>
>>   obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
>> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
>> index bfad15a913a0..d947f5f4d801 100644
>> --- a/drivers/gpu/drm/tegra/drm.c
>> +++ b/drivers/gpu/drm/tegra/drm.c
>> @@ -1,6 +1,6 @@
>>   /*
>>* Copyright (C) 2012 Avionic Design GmbH
>> - * Copyright (C) 2012-2013 NVIDIA CORPORATION.  All rights reserved.
>> + * Copyright (C) 2012-2015 NVIDIA CORPORATION.  All rights reserved.
>>*
>>* This program is free software; you can redistribute it and/or modify
>>* it under the terms of the GNU General Public License version 2 as
>> @@ -1048,6 +1048,7 @@ static const struct of_device_id host1x_drm_subdevs[] 
>> = {
>>  { .compatible = "nvidia,tegra124-dc", },
>>  { .compatible = "nvidia,tegra124-sor", },
>>  { .compatible = "nvidia,tegra124-hdmi", },
>> +{ .compatible = "nvidia,tegra124-vic", },
>>  { /* sentinel */ }
>>   };
>>
>> @@ -1097,8 +1098,14 @@ static int __init host1x_drm_init(void)
>>  if (err < 0)
>>  goto unregister_gr2d;
>>
>> +err = platform_driver_register(_vic_driver);
>> +if (err < 0)
>> +goto unregister_gr3d;
>> +
>>  return 0;
>>
>> +unregister_gr3d:
>> +platform_driver_unregister(_gr3d_driver);
>>   unregister_gr2d:
>>  platform_driver_unregister(_gr2d_driver);
>>   unregister_dpaux:
>> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
>> index 0e7756e720c5..a9c02a80d6bf 100644
>> --- a/drivers/gpu/drm/tegra/drm.h
>> +++ b/drivers/gpu/drm/tegra/drm.h
>> @@ -275,5 +275,6 @@ extern struct platform_driver tegra_hdmi_driver;
>>   extern struct platform_driver tegra_dpaux_driver;
>>   extern struct platform_driver tegra_gr2d_driver;
>>   extern struct platform_driver tegra_gr3d_driver;
>> +extern struct platform_driver tegra_vic_driver;
>>
>>   #endif /* HOST1X_DRM_H */
>> diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
>> new file mode 100644
>> index ..b7c5a96697ed
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tegra/vic.c
>> @@ -0,0 +1,593 @@
>> +/*
>> + * Copyright (c) 2015, NVIDIA Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "drm.h"
>> +#include "gem.h"
>> +#include "vic.h"
>> +
>> +#define VIC_IDLE_TIMEOUT_DEFAULT1   /* 10 milliseconds */
>> +#define VIC_IDLE_CHECK_PERIOD   10  /* 10 usec */
>> +
>> +struct vic;
>
> This doesn't seem to be needed here.
>
>> +
>> +struct vic_config {
>> +/* firmware name */
>> +char *ucode_name;
>> +
>> +/* class id */
>> +u32 class_id;
>> +
>> +/* powergate id */
>> +int powergate_id;
>> +};
>> +
>> +struct vic {
>> +struct {
>> +u32 bin_data_offset;
>> +u32 data_offset;
>> +u32 data_size;
>> +u32 code_offset;
>> +u32 size;
>> +} os, fce;
>> +
>> +struct tegra_bo *ucode_bo;
>> +bool ucode_valid;
>> +void *ucode_vaddr;
>> +
>> +bool booted;
>> +
>> +void __iomem *regs;
>> +struct tegra_drm_client client;
>> +struct 

[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

2015-05-21 Thread Daniel Vetter
On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote:
> For actual sharing of buffers with other drivers (ie. actual hardware)
> we'll need to pimp things out a bit better to deal w/ caching, multiple
> memory domains, etc.  See thread:
> 
>   http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html
> 
> But for the llvmpipe use-case this isn't a problem.  Nor do we really
> need prime/dri3 (dri2 is sufficient).  So until the other issues are
> sorted lets remove DRIVER_PRIME.
> 
> v2: also drop the dead code
> 
> Signed-off-by: Rob Clark 

Yeah I'm ok with this too, but it pretty much means vgem is a thing for
llvmpipe only. And then abusing dumb buffers is imo ok too, since I don't
care too much what kind of horrors drivers pull of internally.

Acked-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/vgem/Makefile   |  2 +-
>  drivers/gpu/drm/vgem/vgem_dma_buf.c | 94 
> -
>  drivers/gpu/drm/vgem/vgem_drv.c | 11 +
>  drivers/gpu/drm/vgem/vgem_drv.h | 11 -
>  4 files changed, 2 insertions(+), 116 deletions(-)
>  delete mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
> 
> diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
> index 1055cb7..3f4c7b8 100644
> --- a/drivers/gpu/drm/vgem/Makefile
> +++ b/drivers/gpu/drm/vgem/Makefile
> @@ -1,4 +1,4 @@
>  ccflags-y := -Iinclude/drm
> -vgem-y := vgem_drv.o vgem_dma_buf.o
> +vgem-y := vgem_drv.o
>  
>  obj-$(CONFIG_DRM_VGEM)   += vgem.o
> diff --git a/drivers/gpu/drm/vgem/vgem_dma_buf.c 
> b/drivers/gpu/drm/vgem/vgem_dma_buf.c
> deleted file mode 100644
> index 0254438..000
> --- a/drivers/gpu/drm/vgem/vgem_dma_buf.c
> +++ /dev/null
> @@ -1,94 +0,0 @@
> -/*
> - * Copyright © 2012 Intel Corporation
> - * Copyright © 2014 The Chromium OS Authors
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> - * IN THE SOFTWARE.
> - *
> - * Authors:
> - *Ben Widawsky 
> - *
> - */
> -
> -#include 
> -#include "vgem_drv.h"
> -
> -struct sg_table *vgem_gem_prime_get_sg_table(struct drm_gem_object *gobj)
> -{
> - struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
> - BUG_ON(obj->pages == NULL);
> -
> - return drm_prime_pages_to_sg(obj->pages, obj->base.size / PAGE_SIZE);
> -}
> -
> -int vgem_gem_prime_pin(struct drm_gem_object *gobj)
> -{
> - struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
> - return vgem_gem_get_pages(obj);
> -}
> -
> -void vgem_gem_prime_unpin(struct drm_gem_object *gobj)
> -{
> - struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
> - vgem_gem_put_pages(obj);
> -}
> -
> -void *vgem_gem_prime_vmap(struct drm_gem_object *gobj)
> -{
> - struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
> - BUG_ON(obj->pages == NULL);
> -
> - return vmap(obj->pages, obj->base.size / PAGE_SIZE, 0, PAGE_KERNEL);
> -}
> -
> -void vgem_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
> -{
> - vunmap(vaddr);
> -}
> -
> -struct drm_gem_object *vgem_gem_prime_import(struct drm_device *dev,
> -  struct dma_buf *dma_buf)
> -{
> - struct drm_vgem_gem_object *obj = NULL;
> - int ret;
> -
> - obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> - if (obj == NULL) {
> - ret = -ENOMEM;
> - goto fail;
> - }
> -
> - ret = drm_gem_object_init(dev, >base, dma_buf->size);
> - if (ret) {
> - ret = -ENOMEM;
> - goto fail_free;
> - }
> -
> - get_dma_buf(dma_buf);
> -
> - obj->base.dma_buf = dma_buf;
> - obj->use_dma_buf = true;
> -
> - return >base;
> -
> -fail_free:
> - kfree(obj);
> -fail:
> - return ERR_PTR(ret);
> -}
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index cb3b435..7a207ca 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -302,22 +302,13 @@ 

[PATCH 3/4] drm/tegra: Add VIC support

2015-05-21 Thread Mikko Perttunen
Hi, very good patch!

Here are a few small comments. Aside those, you should also add a
section to
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt in a
separate patch.

Thanks,
Mikko.

On 05/21/2015 04:20 PM, Arto Merilainen wrote:
> This patch adds support for Video Image Compositor engine which
> can be used for 2d operations.
> 
> The engine has a microcontroller (Falcon) that acts as a frontend
> for the rest of the unit. In order to properly utilize the engine,
> the frontend must be booted before pushing any commands.
> 
> Signed-off-by: Andrew Chew 
> Signed-off-by: Arto Merilainen 
> ---
>  drivers/gpu/drm/tegra/Makefile |   3 +-
>  drivers/gpu/drm/tegra/drm.c|   9 +-
>  drivers/gpu/drm/tegra/drm.h|   1 +
>  drivers/gpu/drm/tegra/vic.c| 593 
> +
>  drivers/gpu/drm/tegra/vic.h| 116 
>  include/linux/host1x.h |   1 +
>  6 files changed, 721 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/tegra/vic.c
>  create mode 100644 drivers/gpu/drm/tegra/vic.h
> 
> diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
> index 2c66a8db9da4..3bc3566e00b6 100644
> --- a/drivers/gpu/drm/tegra/Makefile
> +++ b/drivers/gpu/drm/tegra/Makefile
> @@ -13,6 +13,7 @@ tegra-drm-y := \
>   sor.o \
>   dpaux.o \
>   gr2d.o \
> - gr3d.o
> + gr3d.o \
> + vic.o
>  
>  obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index bfad15a913a0..d947f5f4d801 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -1,6 +1,6 @@
>  /*
>   * Copyright (C) 2012 Avionic Design GmbH
> - * Copyright (C) 2012-2013 NVIDIA CORPORATION.  All rights reserved.
> + * Copyright (C) 2012-2015 NVIDIA CORPORATION.  All rights reserved.
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> @@ -1048,6 +1048,7 @@ static const struct of_device_id host1x_drm_subdevs[] = 
> {
>   { .compatible = "nvidia,tegra124-dc", },
>   { .compatible = "nvidia,tegra124-sor", },
>   { .compatible = "nvidia,tegra124-hdmi", },
> + { .compatible = "nvidia,tegra124-vic", },
>   { /* sentinel */ }
>  };
>  
> @@ -1097,8 +1098,14 @@ static int __init host1x_drm_init(void)
>   if (err < 0)
>   goto unregister_gr2d;
>  
> + err = platform_driver_register(_vic_driver);
> + if (err < 0)
> + goto unregister_gr3d;
> +
>   return 0;
>  
> +unregister_gr3d:
> + platform_driver_unregister(_gr3d_driver);
>  unregister_gr2d:
>   platform_driver_unregister(_gr2d_driver);
>  unregister_dpaux:
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 0e7756e720c5..a9c02a80d6bf 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -275,5 +275,6 @@ extern struct platform_driver tegra_hdmi_driver;
>  extern struct platform_driver tegra_dpaux_driver;
>  extern struct platform_driver tegra_gr2d_driver;
>  extern struct platform_driver tegra_gr3d_driver;
> +extern struct platform_driver tegra_vic_driver;
>  
>  #endif /* HOST1X_DRM_H */
> diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
> new file mode 100644
> index ..b7c5a96697ed
> --- /dev/null
> +++ b/drivers/gpu/drm/tegra/vic.c
> @@ -0,0 +1,593 @@
> +/*
> + * Copyright (c) 2015, NVIDIA Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "drm.h"
> +#include "gem.h"
> +#include "vic.h"
> +
> +#define VIC_IDLE_TIMEOUT_DEFAULT 1   /* 10 milliseconds */
> +#define VIC_IDLE_CHECK_PERIOD10  /* 10 usec */
> +
> +struct vic;

This doesn't seem to be needed here.

> +
> +struct vic_config {
> + /* firmware name */
> + char *ucode_name;
> +
> + /* class id */
> + u32 class_id;
> +
> + /* powergate id */
> + int powergate_id;
> +};
> +
> +struct vic {
> + struct {
> + u32 bin_data_offset;
> + u32 data_offset;
> + u32 data_size;
> + u32 code_offset;
> + u32 size;
> + } os, fce;
> +
> + struct tegra_bo *ucode_bo;
> + bool ucode_valid;
> + void *ucode_vaddr;
> +
> + bool booted;
> +
> + void __iomem *regs;
> + struct tegra_drm_client client;
> + struct host1x_channel *channel;
> + struct iommu_domain *domain;
> + struct device *dev;
> + struct clk *clk;
> + struct reset_control *rst;
> +
> + /* Platform configuration */
> + struct vic_config *config;
> +
> + /* for 

[PATCH] drm/vgem: drop DRIVER_PRIME

2015-05-21 Thread Daniel Vetter
On Thu, May 21, 2015 at 05:03:58PM +0200, Thomas Hellstrom wrote:
> Hi, Rob!
> 
> On 05/21/2015 04:53 PM, Rob Clark wrote:
> > For actual sharing of buffers with other drivers (ie. actual hardware)
> > we'll need to pimp things out a bit better to deal w/ caching, multiple
> > memory domains, etc.  See thread:
> >
> >   
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=hZDsGjgypZF71rQfORpnkvT34UoNymdOdW0M3RyIIpQ=6QpYr_rF5y3fBjm48gY5zTJp6Fu87bv2HJYGGJ7VX7s=
> >  
> >
> > But for the llvmpipe use-case this isn't a problem.  Nor do we really
> > need prime/dri3 (dri2 is sufficient).  So until the other issues are
> > sorted lets remove DRIVER_PRIME.
> >
> > NOTE this ends up leaving some basically dead code for prime import/
> > export (mostly because I was rushing to send this before a meeting).
> 
> What worries me a little is what Daniel brought up in his commit
> message, that let's say in the end people add a reasonable interface to
> dma_buf mmap, vgem also needs a corresponding interface... Makes me
> think that the best solution for now
> is perhaps to revert it.

Yeah if we just drop the prime parts vgem is pretty much only for llvmpipe
and other software renderers. And if we add prime it'd be purely
self-import only which rejects any foreign access and reject any foreign
objects. At least I haven't understood yet why we need to import the
dma-bufs first when we could just directly mmap the passed-in fd ...

Anyway I think removing the dead code makes sense - we can easily
resurrect it with git again. Also the current prime code for vgem doesn't
handle self-imports correctly, so isnt' even really useable for
llvmpipe-on-vgem as-is.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

2015-05-21 Thread Chris Wilson
On Thu, May 21, 2015 at 06:07:30PM +0200, Daniel Vetter wrote:
> On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote:
> > For actual sharing of buffers with other drivers (ie. actual hardware)
> > we'll need to pimp things out a bit better to deal w/ caching, multiple
> > memory domains, etc.  See thread:
> > 
> >   http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html
> > 
> > But for the llvmpipe use-case this isn't a problem.  Nor do we really
> > need prime/dri3 (dri2 is sufficient).  So until the other issues are
> > sorted lets remove DRIVER_PRIME.
> > 
> > v2: also drop the dead code
> > 
> > Signed-off-by: Rob Clark 
> 
> Yeah I'm ok with this too, but it pretty much means vgem is a thing for
> llvmpipe only. And then abusing dumb buffers is imo ok too, since I don't
> care too much what kind of horrors drivers pull of internally.

Ugh. But llvmpipe + dumb buffer is much inferior to SHM.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH v3] drm/exynos: calculate vrefresh instead of use a fixed value

2015-05-21 Thread Tobias Jakobi
Hey,

On 2015-05-21 16:06, Gustavo Padovan wrote:
> Hi Tobias,
> 
> 2015-05-21 Tobias Jakobi :
> 
>> Gustavo Padovan wrote:
>> > From: Gustavo Padovan 
>> >
>> > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
>> > for us so we can get the correct value instead of relying on fixed value
>> > defined in a macro. But if vrefresh is still zero we should fail the
>> > update.
>> This works better for me:
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index dc834b8..26e8ae4 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -346,11 +346,16 @@ static bool fimd_mode_fixup(struct 
>> exynos_drm_crtc
>> *crtc,
>>  static void fimd_commit(struct exynos_drm_crtc *crtc)
>>  {
>> struct fimd_context *ctx = crtc->ctx;
>> -   struct drm_display_mode *mode = >base.mode;
>> +   struct drm_display_mode *mode;
>> struct fimd_driver_data *driver_data = ctx->driver_data;
>> void *timing_base = ctx->regs + driver_data->timing_base;
>> u32 val, clkdiv;
>> 
>> +   if (crtc->base.state)
>> +   mode = >base.state->adjusted_mode;
>> +   else
>> +   mode = >base.mode;
>> +
>> if (ctx->suspended)
>> return;
>> 
>> Otherwise I get an oops (nullptr deref) on boot, so 'state' is 
>> probably
>> not initialized yet at this point.
> 
> Would you like to send a proper git patch of this? You can move the
> drm_mode_vrefresh() part to your patch.
I'll try to send out something later this day.


With best wishes,
Tobias




> 
>   Gustavo



[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Tobias Jakobi
Hi,

like I said before, this clashes with my commit 'drm/exynos: plane: 
honor buffer offset for dma_addr' 
(5d878bdb51bd7915ba3def8b531238c67624aa58), which is currently sitting 
in airlied's drm-fixes.

With best wishes,
Tobias



On 2015-05-21 17:02, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Now that no one is using the functions exported by exynos_drm_plane due
> to the atomic conversion we can make remove some of the them or make 
> them
> static.
> 
> v2: remove unused exynos_drm_crtc
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 90 
> +--
>  drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 
>  2 files changed, 37 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index ab50bb7..b385fec 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -62,35 +62,12 @@ static int exynos_plane_get_size(int start,
> unsigned length, unsigned last)
>   return size;
>  }
> 
> -int exynos_check_plane(struct drm_plane *plane, struct drm_framebuffer 
> *fb)
> -{
> - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> - int nr;
> - int i;
> -
> - nr = exynos_drm_fb_get_buf_cnt(fb);
> - for (i = 0; i < nr; i++) {
> - struct exynos_drm_gem_buf *buffer = exynos_drm_fb_buffer(fb, i);
> -
> - if (!buffer) {
> - DRM_DEBUG_KMS("buffer is null\n");
> - return -EFAULT;
> - }
> -
> - exynos_plane->dma_addr[i] = buffer->dma_addr;
> -
> - DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
> - i, (unsigned long)exynos_plane->dma_addr[i]);
> - }
> -
> - return 0;
> -}
> -
> -void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc 
> *crtc,
> -   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> -   unsigned int crtc_w, unsigned int crtc_h,
> -   uint32_t src_x, uint32_t src_y,
> -   uint32_t src_w, uint32_t src_h)
> +static void exynos_plane_mode_set(struct drm_plane *plane, struct
> drm_crtc *crtc,
> +   struct drm_framebuffer *fb,
> +   int crtc_x, int crtc_y,
> +   unsigned int crtc_w, unsigned int crtc_h,
> +   uint32_t src_x, uint32_t src_y,
> +   uint32_t src_w, uint32_t src_h)
>  {
>   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
>   unsigned int actual_w;
> @@ -145,24 +122,6 @@ void exynos_plane_mode_set(struct drm_plane
> *plane, struct drm_crtc *crtc,
>   plane->crtc = crtc;
>  }
> 
> -void
> -exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
> -  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> -  unsigned int crtc_w, unsigned int crtc_h,
> -  uint32_t src_x, uint32_t src_y,
> -  uint32_t src_w, uint32_t src_h)
> -{
> - struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> -
> - exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
> -   crtc_w, crtc_h, src_x >> 16, src_y >> 16,
> -   src_w >> 16, src_h >> 16);
> -
> - if (exynos_crtc->ops->win_commit)
> - exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
> -}
> -
>  static struct drm_plane_funcs exynos_plane_funcs = {
>   .update_plane   = drm_atomic_helper_update_plane,
>   .disable_plane  = drm_atomic_helper_disable_plane,
> @@ -175,22 +134,47 @@ static struct drm_plane_funcs exynos_plane_funcs 
> = {
>  static int exynos_plane_atomic_check(struct drm_plane *plane,
>struct drm_plane_state *state)
>  {
> - return exynos_check_plane(plane, state->fb);
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> + int nr;
> + int i;
> +
> + nr = exynos_drm_fb_get_buf_cnt(state->fb);
> + for (i = 0; i < nr; i++) {
> + struct exynos_drm_gem_buf *buffer =
> + exynos_drm_fb_buffer(state->fb, i);
> +
> + if (!buffer) {
> + DRM_DEBUG_KMS("buffer is null\n");
> + return -EFAULT;
> + }
> +
> + exynos_plane->dma_addr[i] = buffer->dma_addr;
> +
> + DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
> + i, (unsigned long)exynos_plane->dma_addr[i]);
> + }
> +
> + return 0;
>  }
> 
>  static void exynos_plane_atomic_update(struct drm_plane *plane,
>  struct drm_plane_state *old_state)
>  {
>   struct 

[PATCH] drm/vgem: drop DRIVER_PRIME

2015-05-21 Thread Thomas Hellstrom
Hi, Rob!

On 05/21/2015 04:53 PM, Rob Clark wrote:
> For actual sharing of buffers with other drivers (ie. actual hardware)
> we'll need to pimp things out a bit better to deal w/ caching, multiple
> memory domains, etc.  See thread:
>
>   
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=hZDsGjgypZF71rQfORpnkvT34UoNymdOdW0M3RyIIpQ=6QpYr_rF5y3fBjm48gY5zTJp6Fu87bv2HJYGGJ7VX7s=
>  
>
> But for the llvmpipe use-case this isn't a problem.  Nor do we really
> need prime/dri3 (dri2 is sufficient).  So until the other issues are
> sorted lets remove DRIVER_PRIME.
>
> NOTE this ends up leaving some basically dead code for prime import/
> export (mostly because I was rushing to send this before a meeting).

What worries me a little is what Daniel brought up in his commit
message, that let's say in the end people add a reasonable interface to
dma_buf mmap, vgem also needs a corresponding interface... Makes me
think that the best solution for now
is perhaps to revert it.

/Thomas


>
> Signed-off-by: Rob Clark 
> ---
> This is an alternative to removing vgem completely for 4.1, so that
> llvmpipe work can get started in parallel with sorting out the other
> issues for sw + hw access..
>
>  drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index cb3b435..b0316f9 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -302,7 +302,7 @@ static const struct file_operations vgem_driver_fops = {
>  };
>  
>  static struct drm_driver vgem_driver = {
> - .driver_features= DRIVER_GEM | DRIVER_PRIME,
> + .driver_features= DRIVER_GEM,
>   .gem_free_object= vgem_gem_free_object,
>   .gem_vm_ops = _gem_vm_ops,
>   .ioctls = vgem_ioctls,



[PATCH v6 12/12] drm/exynos: remove unnecessary calls to disable_plane()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

The planes are already disabled by the drm_atomic_helper_commit() code
so we don't need to disable the in these two places.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 ---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |  8 
 2 files changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 92a5595..b312364 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -47,8 +47,6 @@ static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_plane *plane;
-   int ret;

if (!exynos_crtc->enabled)
return;
@@ -64,15 +62,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_OFF);

exynos_crtc->enabled = false;
-
-   drm_for_each_legacy_plane(plane, >dev->mode_config.plane_list) {
-   if (plane->crtc != crtc)
-   continue;
-
-   ret = plane->funcs->disable_plane(plane);
-   if (ret)
-   DRM_ERROR("Failed to disable plane %d\n", ret);
-   }
 }

 static bool
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 0648ba4..7b89fd5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -81,17 +81,9 @@ static void exynos_drm_encoder_disable(struct drm_encoder 
*encoder)
 {
struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
struct exynos_drm_display *display = exynos_encoder->display;
-   struct drm_plane *plane;
-   struct drm_device *dev = encoder->dev;

if (display->ops->dpms)
display->ops->dpms(display, DRM_MODE_DPMS_OFF);
-
-   /* all planes connected to this encoder should be also disabled. */
-   drm_for_each_legacy_plane(plane, >mode_config.plane_list) {
-   if (plane->crtc && (plane->crtc == encoder->crtc))
-   plane->funcs->disable_plane(plane);
-   }
 }

 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
-- 
2.1.0



[PATCH v6 11/12] drm/exynos: atomic dpms support

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.

v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms()
- do not use WARN_ON on crtc enable/disable

v3: - Fix build failure after the hdmi change in v2
- Change dpms helper of ptn3460 bridge

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/bridge/ps8622.c |  2 +-
 drivers/gpu/drm/bridge/ptn3460.c|  2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 99 -
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  6 +-
 10 files changed, 71 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index b604326..d686235 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -499,7 +499,7 @@ static void ps8622_connector_destroy(struct drm_connector 
*connector)
 }

 static const struct drm_connector_funcs ps8622_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
.destroy = ps8622_connector_destroy,
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 8ed3617..260bc9f 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -260,7 +260,7 @@ static void ptn3460_connector_destroy(struct drm_connector 
*connector)
 }

 static struct drm_connector_funcs ptn3460_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 195fe60..c9995b1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -954,7 +954,7 @@ static void exynos_dp_connector_destroy(struct 
drm_connector *connector)
 }

 static struct drm_connector_funcs exynos_dp_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 3251652..92a5595 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -22,51 +22,57 @@
 #include "exynos_drm_encoder.h"
 #include "exynos_drm_plane.h"

-static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
+static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(crtc->primary);

-   DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);
-
-   if (exynos_crtc->dpms == mode) {
-   DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
+   if (exynos_crtc->enabled)
return;
-   }
-
-   if (mode > DRM_MODE_DPMS_ON) {
-   /* wait for the completion of page flip. */
-   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
-   (exynos_crtc->event == NULL), HZ/20))
-   exynos_crtc->event = NULL;
-   drm_crtc_vblank_off(crtc);
-   }

if (exynos_crtc->ops->dpms)
-   exynos_crtc->ops->dpms(exynos_crtc, mode);
+   exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_ON);

-   exynos_crtc->dpms = mode;
+   exynos_crtc->enabled = true;

-   if (mode == DRM_MODE_DPMS_ON)
-   drm_crtc_vblank_on(crtc);
-}
+   drm_crtc_vblank_on(crtc);

-static void exynos_drm_crtc_prepare(struct drm_crtc *crtc)
-{
-   /* drm framework doesn't check NULL. */
+   if (exynos_crtc->ops->win_commit)
+   exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
+
+   if (exynos_crtc->ops->commit)
+   exynos_crtc->ops->commit(exynos_crtc);
 }

-static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
+static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- 

[PATCH v6 10/12] drm/exynos: don't disable unused functions at init

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Everything starts disabled so we don't really need to disable anything.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e71e331..e0b085b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -275,9 +275,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)

}

-   /* disable all the possible outputs/crtcs before entering KMS mode */
-   drm_helper_disable_unused_functions(dev);
-
ret = drm_fb_helper_initial_config(helper, PREFERRED_BPP);
if (ret < 0) {
DRM_ERROR("failed to set up hw configuration.\n");
-- 
2.1.0



[PATCH v6 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Now that no one is using the functions exported by exynos_drm_plane due
to the atomic conversion we can make remove some of the them or make them
static.

v2: remove unused exynos_drm_crtc

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 91 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 
 2 files changed, 38 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index e952cbd..c6e5114 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -62,35 +62,12 @@ static int exynos_plane_get_size(int start, unsigned 
length, unsigned last)
return size;
 }

-int exynos_check_plane(struct drm_plane *plane, struct drm_framebuffer *fb)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   int nr;
-   int i;
-
-   nr = exynos_drm_fb_get_buf_cnt(fb);
-   for (i = 0; i < nr; i++) {
-   struct exynos_drm_gem_buf *buffer = exynos_drm_fb_buffer(fb, i);
-
-   if (!buffer) {
-   DRM_DEBUG_KMS("buffer is null\n");
-   return -EFAULT;
-   }
-
-   exynos_plane->dma_addr[i] = buffer->dma_addr + fb->offsets[i];
-
-   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
-   i, (unsigned long)exynos_plane->dma_addr[i]);
-   }
-
-   return 0;
-}
-
-void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+static void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc 
*crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
 {
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
unsigned int actual_w;
@@ -145,24 +122,6 @@ void exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
plane->crtc = crtc;
 }

-void
-exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
-{
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-
-   exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
- crtc_w, crtc_h, src_x >> 16, src_y >> 16,
- src_w >> 16, src_h >> 16);
-
-   if (exynos_crtc->ops->win_commit)
-   exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -175,22 +134,48 @@ static struct drm_plane_funcs exynos_plane_funcs = {
 static int exynos_plane_atomic_check(struct drm_plane *plane,
 struct drm_plane_state *state)
 {
-   return exynos_check_plane(plane, state->fb);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   int nr;
+   int i;
+
+   nr = exynos_drm_fb_get_buf_cnt(state->fb);
+   for (i = 0; i < nr; i++) {
+   struct exynos_drm_gem_buf *buffer =
+   exynos_drm_fb_buffer(state->fb, i);
+
+   if (!buffer) {
+   DRM_DEBUG_KMS("buffer is null\n");
+   return -EFAULT;
+   }
+
+   exynos_plane->dma_addr[i] = buffer->dma_addr +
+   state->fb->offsets[i];
+
+   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
+   i, (unsigned long)exynos_plane->dma_addr[i]);
+   }
+
+   return 0;
 }

 static void exynos_plane_atomic_update(struct drm_plane *plane,
   struct drm_plane_state *old_state)
 {
struct drm_plane_state *state = plane->state;
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(state->crtc);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);

if (!state->crtc)
return;

-   exynos_update_plane(plane, state->crtc, 

[PATCH v6 08/12] drm/exynos: atomic phase 3: convert page flips

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

PageFlips now use the atomic helper to work through the atomic modesetting
API. Async page flips are not supported yet.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 +---
 drivers/gpu/drm/exynos/exynos_drm_fb.c   |  9 -
 2 files changed, 9 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 686fe63..3251652 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -123,67 +123,6 @@ static struct drm_crtc_helper_funcs 
exynos_crtc_helper_funcs = {
.disable= exynos_drm_crtc_disable,
 };

-static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_pending_vblank_event *event,
-uint32_t page_flip_flags)
-{
-   struct drm_device *dev = crtc->dev;
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   unsigned int crtc_w, crtc_h;
-   int ret;
-
-   /* when the page flip is requested, crtc's dpms should be on */
-   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
-   DRM_ERROR("failed page flip request.\n");
-   return -EINVAL;
-   }
-
-   if (!event)
-   return -EINVAL;
-
-   spin_lock_irq(>event_lock);
-   if (exynos_crtc->event) {
-   ret = -EBUSY;
-   goto out;
-   }
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret)
-   goto out;
-
-   ret = drm_vblank_get(dev, exynos_crtc->pipe);
-   if (ret) {
-   DRM_DEBUG("failed to acquire vblank counter\n");
-   goto out;
-   }
-
-   exynos_crtc->event = event;
-   spin_unlock_irq(>event_lock);
-
-   /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
-   event->pipe = exynos_crtc->pipe;
-
-   crtc->primary->fb = fb;
-   crtc_w = fb->width - crtc->x;
-   crtc_h = fb->height - crtc->y;
-   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-   crtc_w, crtc_h, crtc->x, crtc->y,
-   crtc_w, crtc_h);
-
-   if (crtc->primary->state)
-   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
-
-   return 0;
-
-out:
-   spin_unlock_irq(>event_lock);
-   return ret;
-}
-
 static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
@@ -197,7 +136,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)

 static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
-   .page_flip  = exynos_drm_crtc_page_flip,
+   .page_flip  = drm_atomic_helper_page_flip,
.destroy= exynos_drm_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index aa89908..5840d546f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -266,11 +266,18 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
exynos_drm_fbdev_init(dev);
 }

+static int exynos_atomic_commit(struct drm_device *dev,
+   struct drm_atomic_state *state,
+   bool async)
+{
+   return drm_atomic_helper_commit(dev, state, false);
+}
+
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
+   .atomic_commit = exynos_atomic_commit,
 };

 void exynos_drm_mode_config_init(struct drm_device *dev)
-- 
2.1.0



[PATCH v6 07/12] drm/exynos: atomic phase 3: use atomic .set_config helper

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Now that phase 1 and 2 are complete switch .set_config helper to
use the atomic one.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 20e053d..686fe63 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -196,7 +196,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
 }

 static struct drm_crtc_funcs exynos_crtc_funcs = {
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.page_flip  = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
-- 
2.1.0



[PATCH v6 06/12] drm/exynos: atomic phase 3: atomic updates of planes

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Now that phase 1 and 2 are complete we can switch the update/disable_plane
callbacks to their atomic version.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index bf814c8..aa89908 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "exynos_drm_drv.h"
@@ -268,6 +269,8 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };

 void exynos_drm_mode_config_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 6af4636..e952cbd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -164,8 +164,8 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 }

 static struct drm_plane_funcs exynos_plane_funcs = {
-   .update_plane   = drm_plane_helper_update,
-   .disable_plane  = drm_plane_helper_disable,
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
-- 
2.1.0



[PATCH v6 05/12] drm/exynos: atomic phase 2: keep track of framebuffer pointer

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index dbaf161..20e053d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -174,6 +174,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc_w, crtc_h, crtc->x, crtc->y,
crtc_w, crtc_h);

+   if (crtc->primary->state)
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
+
return 0;

 out:
-- 
2.1.0



[PATCH v6 04/12] drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/bridge/ps8622.c   | 4 
 drivers/gpu/drm/bridge/ptn3460.c  | 4 
 drivers/gpu/drm/exynos/exynos_dp_core.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 6 ++
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 2 ++
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 4 
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 4 
 10 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index e895aa7..b604326 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -31,6 +31,7 @@
 #include "drmP.h"
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"

 /* Brightness scale on the Parade chip */
 #define PS8622_MAX_BRIGHTNESS 0xff
@@ -502,6 +503,9 @@ static const struct drm_connector_funcs 
ps8622_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
.destroy = ps8622_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int ps8622_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9d2f053..8ed3617 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -27,6 +27,7 @@

 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"
 #include "drm_edid.h"
 #include "drmP.h"

@@ -263,6 +264,9 @@ static struct drm_connector_funcs ptn3460_connector_funcs = 
{
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int ptn3460_bridge_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 30feb7d..195fe60 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -957,6 +958,9 @@ static struct drm_connector_funcs exynos_dp_connector_funcs 
= {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int exynos_dp_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 54b74e1..dbaf161 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -14,6 +14,8 @@

 #include 
 #include 
+#include 
+#include 

 #include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
@@ -194,8 +196,12 @@ static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.page_flip  = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };

+
 struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
int pipe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 37678cf..ced5c23 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -63,6 +64,9 @@ static struct drm_connector_funcs exynos_dpi_connector_funcs 
= {
.detect = exynos_dpi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = exynos_dpi_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = 

[PATCH v6 03/12] drm/exynos: atomic phase 1: add .mode_set_nofb() callback

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +---
 1 file changed, 9 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 61b8cfe..54b74e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -81,59 +81,16 @@ exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }

-static int
-exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode, int x, int y,
- struct drm_framebuffer *old_fb)
-{
-   struct drm_framebuffer *fb = crtc->primary->fb;
-   unsigned int crtc_w;
-   unsigned int crtc_h;
-   int ret;
-
-   /*
-* copy the mode data adjusted by mode_fixup() into crtc->mode
-* so that hardware can be seet to proper mode.
-*/
-   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret < 0)
-   return ret;
-
-   crtc_w = fb->width - x;
-   crtc_h = fb->height - y;
-   exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, x, y, crtc_w, crtc_h);
-
-   return 0;
-}
-
-static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
+static void
+exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_framebuffer *fb = crtc->primary->fb;
-   unsigned int crtc_w;
-   unsigned int crtc_h;
-   int ret;

-   /* when framebuffer changing is requested, crtc's dpms should be on */
-   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
-   DRM_ERROR("failed framebuffer changing request.\n");
-   return -EPERM;
-   }
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret)
-   return ret;
-
-   crtc_w = fb->width - x;
-   crtc_h = fb->height - y;
-   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+   if (WARN_ON(!crtc->state))
+   return;

-   return 0;
+   if (exynos_crtc->ops->commit)
+   exynos_crtc->ops->commit(exynos_crtc);
 }

 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -158,8 +115,9 @@ static struct drm_crtc_helper_funcs 
exynos_crtc_helper_funcs = {
.prepare= exynos_drm_crtc_prepare,
.commit = exynos_drm_crtc_commit,
.mode_fixup = exynos_drm_crtc_mode_fixup,
-   .mode_set   = exynos_drm_crtc_mode_set,
-   .mode_set_base  = exynos_drm_crtc_mode_set_base,
+   .mode_set   = drm_helper_crtc_mode_set,
+   .mode_set_nofb  = exynos_drm_crtc_mode_set_nofb,
+   .mode_set_base  = drm_helper_crtc_mode_set_base,
.disable= exynos_drm_crtc_disable,
 };

-- 
2.1.0



[PATCH v6 02/12] drm/exynos: atomic phase 1: use drm_plane_helper_disable()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()

exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 29 -
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 142eb4e..bf814c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -136,7 +136,7 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct 
drm_framebuffer *fb)

exynos_fb = to_exynos_fb(fb);

-   return exynos_fb->buf_cnt;
+   return exynos_fb ? exynos_fb->buf_cnt : 0;
 }

 struct drm_framebuffer *
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index b218b7a..87078db 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -162,21 +162,9 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
 }

-static int exynos_disable_plane(struct drm_plane *plane)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc);
-
-   if (exynos_crtc && exynos_crtc->ops->win_disable)
-   exynos_crtc->ops->win_disable(exynos_crtc,
- exynos_plane->zpos);
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_plane_helper_update,
-   .disable_plane  = exynos_disable_plane,
+   .disable_plane  = drm_plane_helper_disable,
.destroy= drm_plane_cleanup,
 };

@@ -201,9 +189,24 @@ static void exynos_plane_atomic_update(struct drm_plane 
*plane,
state->src_w >> 16, state->src_h >> 16);
 }

+static void exynos_plane_atomic_disable(struct drm_plane *plane,
+   struct drm_plane_state *old_state)
+{
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(old_state->crtc);
+
+   if (!old_state->crtc)
+   return;
+
+   if (exynos_crtc->ops->win_disable)
+   exynos_crtc->ops->win_disable(exynos_crtc,
+ exynos_plane->zpos);
+}
+
 static const struct drm_plane_helper_funcs plane_helper_funcs = {
.atomic_check = exynos_plane_atomic_check,
.atomic_update = exynos_plane_atomic_update,
+   .atomic_disable = exynos_plane_atomic_disable,
 };

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



[PATCH v6 01/12] drm/exynos: atomic phase 1: use drm_plane_helper_update()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.

Update all users of exynos_update_plane() accordingly to call
exynos_check_plane() before.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 29 +++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 40 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 +-
 3 files changed, 46 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 9006b94..61b8cfe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -116,6 +116,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
+   int ret;

/* when framebuffer changing is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -123,11 +124,16 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
return -EPERM;
}

+   ret = exynos_check_plane(crtc->primary, fb);
+   if (ret)
+   return ret;
+
crtc_w = fb->width - x;
crtc_h = fb->height - y;
+   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   crtc_w, crtc_h, x, y, crtc_w, crtc_h);

-   return exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-  crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+   return 0;
 }

 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -164,7 +170,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
int ret;

@@ -183,6 +188,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}

+   ret = exynos_check_plane(crtc->primary, fb);
+   if (ret)
+   goto out;
+
ret = drm_vblank_get(dev, exynos_crtc->pipe);
if (ret) {
DRM_DEBUG("failed to acquire vblank counter\n");
@@ -201,17 +210,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc->primary->fb = fb;
crtc_w = fb->width - crtc->x;
crtc_h = fb->height - crtc->y;
-   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
-   if (ret) {
-   crtc->primary->fb = old_fb;
-   spin_lock_irq(>event_lock);
-   exynos_crtc->event = NULL;
-   drm_vblank_put(dev, exynos_crtc->pipe);
-   spin_unlock_irq(>event_lock);
-   return ret;
-   }
+   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   crtc_w, crtc_h, crtc->x, crtc->y,
+   crtc_w, crtc_h);

return 0;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index b1180fb..b218b7a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -144,21 +144,15 @@ void exynos_plane_mode_set(struct drm_plane *plane, 
struct drm_crtc *crtc,
plane->crtc = crtc;
 }

-int
+void
 exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
 struct drm_framebuffer *fb, int crtc_x, int crtc_y,
 unsigned int crtc_w, unsigned int crtc_h,
 uint32_t src_x, uint32_t src_y,
 uint32_t src_w, uint32_t src_h)
 {
-
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   int ret;
-
-   ret = exynos_check_plane(plane, fb);
-   if (ret < 0)
-   return ret;

exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
  crtc_w, crtc_h, src_x >> 16, src_y >> 16,
@@ -166,8 +160,6 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,

if (exynos_crtc->ops->win_commit)
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
-
-   return 0;
 }

 static int exynos_disable_plane(struct drm_plane *plane)
@@ -183,11 +175,37 @@ static int exynos_disable_plane(struct drm_plane *plane)
 }

 static struct drm_plane_funcs exynos_plane_funcs = {
-   .update_plane   = exynos_update_plane,
+   .update_plane   = drm_plane_helper_update,

[PATCH v6 00/12] drm/exynos: atomic modesetting support

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Hi,

Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.

v2: fixes comments by Joonyoung
- remove unused var in patch 09
- use ->disable instead of outdated ->dpms in hdmi code
- remove WARN_ON from crtc enable/disable

v3: fixes comment by Joonyoung
- move the removal of drm_helper_disable_unused_functions() to
separated patch

v4: add patches that remove unnecessary calls to disable_plane()

v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias)

v6: rebase on latest exynos_drm_next

Gustavo Padovan (12):
  drm/exynos: atomic phase 1: use drm_plane_helper_update()
  drm/exynos: atomic phase 1: use drm_plane_helper_disable()
  drm/exynos: atomic phase 1: add .mode_set_nofb() callback
  drm/exynos: atomic phase 2: wire up state reset(), duplicate() and
destroy()
  drm/exynos: atomic phase 2: keep track of framebuffer pointer
  drm/exynos: atomic phase 3: atomic updates of planes
  drm/exynos: atomic phase 3: use atomic .set_config helper
  drm/exynos: atomic phase 3: convert page flips
  drm/exynos: remove exported functions from exynos_drm_plane
  drm/exynos: don't disable unused functions at init
  drm/exynos: atomic dpms support
  drm/exynos: remove unnecessary calls to disable_plane()

 drivers/gpu/drm/bridge/ps8622.c |   6 +-
 drivers/gpu/drm/bridge/ptn3460.c|   6 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 215 
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |  35 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  12 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |   3 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c   | 120 +---
 drivers/gpu/drm/exynos/exynos_drm_plane.h   |  11 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   6 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  10 +-
 15 files changed, 184 insertions(+), 264 deletions(-)

-- 
2.1.0



[PATCH] Revert "drm/vgem: implement virtual GEM"

2015-05-21 Thread Thomas Hellstrom
Acked-by: Thomas Hellstrom 

On 05/21/2015 04:34 PM, Daniel Vetter wrote:
> This reverts commit 502e95c6678505474f1056480310cd9382bacbac.
>
> Originally vgem was just to have a drm driver for software-only
> renders like llvmpipe so that they integrate more nicely with the
> existing compositor protocols like DRI2/3.
>
> Later on Ben extended it to serve as a dma-buf import/export test
> vehicle for debugging. Both of these use-cases imo make sense and are
> on the level of just yet another (virtual) drm driver.
>
> But only just I realized that Google's CrOS plans with vgem are much
> more pervasive - the plan seems to be to use it as the generic
> software mmap path on top of any kind of hw driver buffer objects from
> the underlying SoC gfx hw. That means vgem is now common infrastructre
> which should work for all drivers and properly interact with them, and
> from that point-of-view it definitely falls short on three accounts:
>
> - It directly forwards the current dma-buf ->mmap model, and the
>   consensus for that has always been that it's a toy one at best
>   useful for debugging or super-unlikely fallbacks. Originally it was
>   added mostly as a concession to get people on top of the dma-buf
>   train since Ion has this too.
>
>   For proper mmap support we really need some software begin/end
>   signals, probably best in the form of a set of ioctls on the dma-buf
>   fd that forward to the already existing ->begin/end_cpu_access
>   hooks.
>
>   Not exposing this and not requiring userspace to use them puts a
>   serious burden on any kind of driver that needs to occasionally
>   handle a bit of coherency troubles. Which includes anything on ARM
>   and even more so more fancy stuff like virtual hardware.
>
>   Furthermore the vgem mmap interface doesn't expose any begin/end
>   ioctls either, which means we can't even use the existing dma-buf
>   hooks properly and fix this up in vgem.
>
> - vgem uses the dumb buffer api to expose the the mmap support.
>   Generally I don't care about what kind of horror-shows of abi abuse
>   drivers do (and there's lots of dumb buffer abused out there). But
>   vgem as used now isn't just a driver, but core infrastructure. And
>   the dumb mmap interface really is just for uploading the occasional
>   splash screen, and definitely not for more elaborate buffer object
>   usage.
>
>   Furthermore the dumb buffer api is explictily for kms drivers to be
>   used as framebuffers. Which vgem just isn't.
>
> - The userspace demonstration vehicle seems missing. Yes there's
>   Ajax's old llvmpipe-on-vgem stuff, and there's Ben's old patches to
>   use vgem to put dma-buf on i915 through it's paces. But vgem as-is
>   has long eclipsed these use-cases, but the corresponding CrOS code
>   hasn't been floated around. Which means it's pretty much impossible
>   to gauge whether the proposed ABI is a good fit for the stated
>   goals.
>
> Worse still I tried to raise this with Stéphane on irc and wanted to
> discuss my concerns, but he just shrugged them off that intel hw
> issues aren't his concern (and a few other denials). While intel hw is
> one of the few used by CrOS which actually has a fully coherent gpu
> (well at least the ones with LLC).
>
> Given all that I think vgem just isn't ready yet. I'm definitely not
> opposed to the overall idea, but I do think it needs to be fleshed out
> a bit more. And since the release of 4.1 is fairly close the best
> immediate action seems to be to temporarily revert the vgem driver for
> now.
>
> Cc: Thomas Hellstrom 
> Cc: Dave Airlie 
> Cc: Stéphane Marchesin 
> Cc: Rob Clark 
> Cc: Adam Jackson 
> Cc: Zach Reizner 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/Kconfig |   9 -
>  drivers/gpu/drm/Makefile|   1 -
>  drivers/gpu/drm/vgem/Makefile   |   4 -
>  drivers/gpu/drm/vgem/vgem_dma_buf.c |  94 --
>  drivers/gpu/drm/vgem/vgem_drv.c | 364 
> 
>  drivers/gpu/drm/vgem/vgem_drv.h |  57 --
>  6 files changed, 529 deletions(-)
>  delete mode 100644 drivers/gpu/drm/vgem/Makefile
>  delete mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
>  delete mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
>  delete mode 100644 drivers/gpu/drm/vgem/vgem_drv.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 47f2ce81b412..151a050129e7 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -165,15 +165,6 @@ config DRM_SAVAGE
> Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
> chipset. If M is selected the module will be called savage.
>  
> -config DRM_VGEM
> - tristate "Virtual GEM provider"
> - depends on DRM
> - help
> -   Choose this option to get a virtual graphics memory manager,
> -   as used by Mesa's software renderer for enhanced performance.
> -   If M is selected the module will be called vgem.
> -
> -
>  source 

[PATCH v2] drm: Only create a cmdline mode if no probed modes match

2015-05-21 Thread Chris Wilson
On Mon, Apr 20, 2015 at 03:41:48PM +0200, Radek Dostál wrote:
> On 04/20/2015 03:28 PM, Chris Wilson wrote:
> > The intention of using video=: is primarily to select
> > the user's preferred resolution at startup. Currently we always create a
> > new mode irrespective of whether the monitor has a native mode at the
> > desired resolution. This has the issue that we may then select the fake
> > mode rather the native mode during fb_helper->inital_config() and so
> > if the fake mode is invalid we then end up with a loss of signal. Oops.
> > This invalid fake mode would also be exported to userspace, who
> > potentially may make the same mistake.
> > 
> > To avoid this issue, we filter out the added command line mode if we
> > detect the desired resolution (and clock if specified) amongst the
> > probed modes. This fixes the immediate problem of adding a duplicate
> > mode, but perhaps more generically we should avoid adding a GTF mode if
> > the monitor has an EDID that is not GTF-compatible, or similarly for
> > CVT.
> > 
> > A second issue sneaked into this patch is to add the cmdline mode mode
> > ahead of the absolute fallback 1024x768 mode. That is if the user has
> > specified a mode that we create as a fallback, we do not need to add a
> > second unused fallback mode.
> > 
> > Fixes regression from
> > 
> > commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2
> > Author: Chris Wilson 
> > Date:   Wed Aug 6 10:08:32 2014 +0200
> > 
> > drm: Perform cmdline mode parsing during connector initialisation
> > 
> > that breaks HDMI output on BeagleBone Black with LG TV (model 19LS4R-ZA).
> > 
> > v2: Explicitly delete our earlier cmdline mode
> > 
> > Reported-by: Radek Dostál 
> > Signed-off-by: Chris Wilson 
> > Cc: Radek Dostál 
> > Cc: Jesse Barnes 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: Julia Lemire 
> > Cc: Dave Airlie 
> > Cc: stable at vger.kernel.org
> 
> works now :)
> 
> Tested-by: Radek Dostál 

Daniel, Dave do either or you want to pick this up for your fixes tree?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH] Revert "drm/vgem: implement virtual GEM"

2015-05-21 Thread Daniel Vetter
This reverts commit 502e95c6678505474f1056480310cd9382bacbac.

Originally vgem was just to have a drm driver for software-only
renders like llvmpipe so that they integrate more nicely with the
existing compositor protocols like DRI2/3.

Later on Ben extended it to serve as a dma-buf import/export test
vehicle for debugging. Both of these use-cases imo make sense and are
on the level of just yet another (virtual) drm driver.

But only just I realized that Google's CrOS plans with vgem are much
more pervasive - the plan seems to be to use it as the generic
software mmap path on top of any kind of hw driver buffer objects from
the underlying SoC gfx hw. That means vgem is now common infrastructre
which should work for all drivers and properly interact with them, and
from that point-of-view it definitely falls short on three accounts:

- It directly forwards the current dma-buf ->mmap model, and the
  consensus for that has always been that it's a toy one at best
  useful for debugging or super-unlikely fallbacks. Originally it was
  added mostly as a concession to get people on top of the dma-buf
  train since Ion has this too.

  For proper mmap support we really need some software begin/end
  signals, probably best in the form of a set of ioctls on the dma-buf
  fd that forward to the already existing ->begin/end_cpu_access
  hooks.

  Not exposing this and not requiring userspace to use them puts a
  serious burden on any kind of driver that needs to occasionally
  handle a bit of coherency troubles. Which includes anything on ARM
  and even more so more fancy stuff like virtual hardware.

  Furthermore the vgem mmap interface doesn't expose any begin/end
  ioctls either, which means we can't even use the existing dma-buf
  hooks properly and fix this up in vgem.

- vgem uses the dumb buffer api to expose the the mmap support.
  Generally I don't care about what kind of horror-shows of abi abuse
  drivers do (and there's lots of dumb buffer abused out there). But
  vgem as used now isn't just a driver, but core infrastructure. And
  the dumb mmap interface really is just for uploading the occasional
  splash screen, and definitely not for more elaborate buffer object
  usage.

  Furthermore the dumb buffer api is explictily for kms drivers to be
  used as framebuffers. Which vgem just isn't.

- The userspace demonstration vehicle seems missing. Yes there's
  Ajax's old llvmpipe-on-vgem stuff, and there's Ben's old patches to
  use vgem to put dma-buf on i915 through it's paces. But vgem as-is
  has long eclipsed these use-cases, but the corresponding CrOS code
  hasn't been floated around. Which means it's pretty much impossible
  to gauge whether the proposed ABI is a good fit for the stated
  goals.

Worse still I tried to raise this with Stéphane on irc and wanted to
discuss my concerns, but he just shrugged them off that intel hw
issues aren't his concern (and a few other denials). While intel hw is
one of the few used by CrOS which actually has a fully coherent gpu
(well at least the ones with LLC).

Given all that I think vgem just isn't ready yet. I'm definitely not
opposed to the overall idea, but I do think it needs to be fleshed out
a bit more. And since the release of 4.1 is fairly close the best
immediate action seems to be to temporarily revert the vgem driver for
now.

Cc: Thomas Hellstrom 
Cc: Dave Airlie 
Cc: Stéphane Marchesin 
Cc: Rob Clark 
Cc: Adam Jackson 
Cc: Zach Reizner 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/Kconfig |   9 -
 drivers/gpu/drm/Makefile|   1 -
 drivers/gpu/drm/vgem/Makefile   |   4 -
 drivers/gpu/drm/vgem/vgem_dma_buf.c |  94 --
 drivers/gpu/drm/vgem/vgem_drv.c | 364 
 drivers/gpu/drm/vgem/vgem_drv.h |  57 --
 6 files changed, 529 deletions(-)
 delete mode 100644 drivers/gpu/drm/vgem/Makefile
 delete mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
 delete mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
 delete mode 100644 drivers/gpu/drm/vgem/vgem_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 47f2ce81b412..151a050129e7 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -165,15 +165,6 @@ config DRM_SAVAGE
  Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
  chipset. If M is selected the module will be called savage.

-config DRM_VGEM
-   tristate "Virtual GEM provider"
-   depends on DRM
-   help
- Choose this option to get a virtual graphics memory manager,
- as used by Mesa's software renderer for enhanced performance.
- If M is selected the module will be called vgem.
-
-
 source "drivers/gpu/drm/exynos/Kconfig"

 source "drivers/gpu/drm/rockchip/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4de8d9b006ec..44caabf13041 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -46,7 +46,6 @@ 

[RESEND PATCH 2/2] modetest: only select plane with matching format

2015-05-21 Thread Emil Velikov
Hi Tobias

On 12 May 2015 at 21:17, Tobias Jakobi  wrote:
> Don't assume that a plane supports any kind of pixelformat
> but do a check first.
>
> v2: Simplify the format check.
> Signed-off-by: Tobias Jakobi 
Nice catch ! I will push the tomorrow, unless we hear any objections against it.

Patch 1/2 looks sane imho, although I'm not sure if some of the teams
has some (automated?) testing which depends on the lack of
transparency. Curious if pinging people (check git log for a list) at
#dri-devel or via email might show such users ?

Cheers,
Emil


[PATCH] drm/vgem: implement virtual GEM

2015-05-21 Thread Thomas Hellstrom
On 05/21/2015 04:19 PM, Rob Clark wrote:
> On Thu, May 21, 2015 at 9:49 AM, Thomas Hellstrom  
> wrote:
>> On 05/21/2015 11:13 AM, Daniel Vetter wrote:
>>> On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote:
 On 11/25/2014 02:08 AM, Zachary Reizner wrote:
> After looking into removing platform_device, I found that using
> dma_buf_attach with a NULL device always returns an error, thereby
> preventing me from using VGEM for import and mmap. The solution seems
> to be to skip using dma_buf_attach, and instead use dma_buf_mmap when
> user-space tries to mmap a gem object that was imported into VGEM. The
> drawback to this approach is that most drivers stub their
> dma_buf_ops->mmap implementation. Presumably mmap could be implemented
> for the drivers that this would make sense for. Are there any
> comments, questions, or concerns for this proposed solution?
 I see now that this driver has entered -next, and I'm sorry this comment
 didn't arrive before. I simply missed this discussion :(

 My biggest concern, as stated many many times before, is that dma-buf
 mmap is a horrible interface for incoherent drivers, and for drivers
 that use odd format (tiled) dma-bufs, basically since it doesn't supply
 a dirtied region. Therefore (correct me if I'm wrong) there has been an
 agreement that for purposes outside of ARM SOC, we should simply not
 implement dma-buf mmap for other uses than for internal driver use.

 So assume a real driver implements dma-buf mmap, but it is crawling due
 to coherency- or untiling / tiling operations. How do you tell a generic
 user of the vgem driver *NOT* to mmap for performance reasons? Or is
 this driver only intended for ARM SOC systems?
>>> Seconded. Somehow I thought we've pulled in vgem to support software
>>> rendering like llvmpipe, and I remember that that's been the original
>>> justification. TIL that that's indeed not the case and google is
>>> splattering their cros tree with dma_buf->mmap implementations this is
>>> obviously not the case and the intention really seems to be to use
>>> dma_buf->mmap and vgem as the generic interface to expose buffer objects
>>> of real drivers to software rendering.
>>>
>>> Given that neither vgem nor dma_buf->mmap has any sane concept of handling
>>> coherency I'm really unhappy about this and tempted to just submit the
>>> revert for vgem before 4.1 ships. I'll chat with relevant people a bit
>>> more. Worse I chatted with Stephane today and he brushed this off as
>>> not-my-problem and if this hurts intel intel should fix this. That's not
>>> how a proper usptream interface is getting designd, and coherency handling
>>> is an even more serious problem on arm an virtual hw like vmwgfx.
>> So given how this has turned out, my opinion is that before a usable
>> generic mmap of accelerated buffer objects
>> goes upstream, there should be a proper interface to request regions
>> present and to dirty regions. It seems to me that so far
>> all use-cases are for one- or two-dimensional access so it should be
>> sufficient to start with that and add other access
>> modes later on. Now this is no guarantee that people won't request and
>> dirty the whole dma-buf on each access, but at least
>> that would make people think, and if things become slow it's pretty
>> clear where the problem is.
>>
>> I'm all for delaying vgem until we have such an interface in place.
> so, for llvmpipe use-case, I think dri2 is sufficient.  So why don't
> we just drop DRIVER_PRIME flag for now..
>
> BR,
> -R

Fine with me!

/Thomas



>
>> Thanks,
>> Thomas
>>
>>
>>
>>
>>>  On intel
>>> (well at least big core thanks to the huge coherent cache fabric) this is
>>> mostly a non-issue, except that the patch in the cros tree obviously gets
>>> things wrong.
>>>
>>> Decently pissed tbh.
>>>
>>> Cheers, Daniel
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=AwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=sLK_B5IzlsF7zUqLCrxPQUtxzZt77RtzKxrZaJGYews=tfXDNoFQ1d044YyOewiTg_Qa0gsSvjOZGT603lZtZVo=
>>  



[PATCH 4/4] ARM: tegra: Add VIC for Tegra124

2015-05-21 Thread Arto Merilainen
This patch adds VIC device tree node for Video Image Compositor.

Signed-off-by: Arto Merilainen 
---
 arch/arm/boot/dts/tegra124.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 13cc7ca5e031..626355693a41 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -136,6 +136,17 @@
status = "disabled";
};

+   vic at 5434 {
+   compatible = "nvidia,tegra124-vic";
+   reg = <0x0 0x5434 0x0 0x0004>;
+   clocks = <_car TEGRA124_CLK_VIC03>;
+   clock-names = "vic03";
+   resets = <_car TEGRA124_CLK_VIC03>;
+   reset-names = "vic03";
+
+   iommus = < TEGRA_SWGROUP_VIC>;
+   };
+
sor at 0,5454 {
compatible = "nvidia,tegra124-sor";
reg = <0x0 0x5454 0x0 0x0004>;
-- 
1.8.1.5



[PATCH 3/4] drm/tegra: Add VIC support

2015-05-21 Thread Arto Merilainen
This patch adds support for Video Image Compositor engine which
can be used for 2d operations.

The engine has a microcontroller (Falcon) that acts as a frontend
for the rest of the unit. In order to properly utilize the engine,
the frontend must be booted before pushing any commands.

Signed-off-by: Andrew Chew 
Signed-off-by: Arto Merilainen 
---
 drivers/gpu/drm/tegra/Makefile |   3 +-
 drivers/gpu/drm/tegra/drm.c|   9 +-
 drivers/gpu/drm/tegra/drm.h|   1 +
 drivers/gpu/drm/tegra/vic.c| 593 +
 drivers/gpu/drm/tegra/vic.h| 116 
 include/linux/host1x.h |   1 +
 6 files changed, 721 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/tegra/vic.c
 create mode 100644 drivers/gpu/drm/tegra/vic.h

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 2c66a8db9da4..3bc3566e00b6 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -13,6 +13,7 @@ tegra-drm-y := \
sor.o \
dpaux.o \
gr2d.o \
-   gr3d.o
+   gr3d.o \
+   vic.o

 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index bfad15a913a0..d947f5f4d801 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2012 Avionic Design GmbH
- * Copyright (C) 2012-2013 NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2012-2015 NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -1048,6 +1048,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra124-dc", },
{ .compatible = "nvidia,tegra124-sor", },
{ .compatible = "nvidia,tegra124-hdmi", },
+   { .compatible = "nvidia,tegra124-vic", },
{ /* sentinel */ }
 };

@@ -1097,8 +1098,14 @@ static int __init host1x_drm_init(void)
if (err < 0)
goto unregister_gr2d;

+   err = platform_driver_register(_vic_driver);
+   if (err < 0)
+   goto unregister_gr3d;
+
return 0;

+unregister_gr3d:
+   platform_driver_unregister(_gr3d_driver);
 unregister_gr2d:
platform_driver_unregister(_gr2d_driver);
 unregister_dpaux:
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 0e7756e720c5..a9c02a80d6bf 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -275,5 +275,6 @@ extern struct platform_driver tegra_hdmi_driver;
 extern struct platform_driver tegra_dpaux_driver;
 extern struct platform_driver tegra_gr2d_driver;
 extern struct platform_driver tegra_gr3d_driver;
+extern struct platform_driver tegra_vic_driver;

 #endif /* HOST1X_DRM_H */
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
new file mode 100644
index ..b7c5a96697ed
--- /dev/null
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -0,0 +1,593 @@
+/*
+ * Copyright (c) 2015, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm.h"
+#include "gem.h"
+#include "vic.h"
+
+#define VIC_IDLE_TIMEOUT_DEFAULT   1   /* 10 milliseconds */
+#define VIC_IDLE_CHECK_PERIOD  10  /* 10 usec */
+
+struct vic;
+
+struct vic_config {
+   /* firmware name */
+   char *ucode_name;
+
+   /* class id */
+   u32 class_id;
+
+   /* powergate id */
+   int powergate_id;
+};
+
+struct vic {
+   struct {
+   u32 bin_data_offset;
+   u32 data_offset;
+   u32 data_size;
+   u32 code_offset;
+   u32 size;
+   } os, fce;
+
+   struct tegra_bo *ucode_bo;
+   bool ucode_valid;
+   void *ucode_vaddr;
+
+   bool booted;
+
+   void __iomem *regs;
+   struct tegra_drm_client client;
+   struct host1x_channel *channel;
+   struct iommu_domain *domain;
+   struct device *dev;
+   struct clk *clk;
+   struct reset_control *rst;
+
+   /* Platform configuration */
+   struct vic_config *config;
+
+   /* for firewall - this determines if method 1 should be regarded
+* as an address register */
+   bool method_data_is_addr_reg;
+};
+
+static inline struct vic *to_vic(struct tegra_drm_client *client)
+{
+   return container_of(client, struct vic, client);
+}
+
+void vic_writel(struct vic *vic, u32 v, u32 r)
+{
+   writel(v, vic->regs + r);
+}
+
+u32 vic_readl(struct vic *vic, u32 r)
+{
+   return readl(vic->regs + r);
+}
+
+static int vic_wait_idle(struct vic *vic)
+{
+   u32 timeout = 

[PATCH 2/4] host1x: Pass register value in firewall

2015-05-21 Thread Arto Merilainen
In gr2d and gr3d units the register offset was sufficient for determining
if the register in interest is used for storing a register value.

However, in VIC this is not the case. The operations are passed through
two registers, METHOD0 and METHOD1. Depending on content of METHOD0,
METHOD1 can be either address or data field.

This patch updates the firewall interface to deliver also the register
value to allow book-keeping inside the engine driver.

Signed-off-by: Arto Merilainen 
---
 drivers/gpu/drm/tegra/drm.h  |  4 ++--
 drivers/gpu/drm/tegra/gr2d.c |  4 ++--
 drivers/gpu/drm/tegra/gr3d.c |  4 ++--
 drivers/gpu/host1x/job.c | 35 +++
 include/linux/host1x.h   |  4 ++--
 5 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 659b2fcc986d..0e7756e720c5 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2012 Avionic Design GmbH
- * Copyright (C) 2012-2013 NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2012-2015 NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -70,7 +70,7 @@ struct tegra_drm_client_ops {
int (*open_channel)(struct tegra_drm_client *client,
struct tegra_drm_context *context);
void (*close_channel)(struct tegra_drm_context *context);
-   int (*is_addr_reg)(struct device *dev, u32 class, u32 offset);
+   int (*is_addr_reg)(struct device *dev, u32 class, u32 offset, u32 val);
int (*submit)(struct tegra_drm_context *context,
  struct drm_tegra_submit *args, struct drm_device *drm,
  struct drm_file *file);
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 02cd3e37a6ec..7e4424f15cdf 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012-2013, NVIDIA Corporation.
+ * Copyright (c) 2012-2015, NVIDIA Corporation.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -84,7 +84,7 @@ static void gr2d_close_channel(struct tegra_drm_context 
*context)
host1x_channel_put(context->channel);
 }

-static int gr2d_is_addr_reg(struct device *dev, u32 class, u32 offset)
+static int gr2d_is_addr_reg(struct device *dev, u32 class, u32 offset, u32 val)
 {
struct gr2d *gr2d = dev_get_drvdata(dev);

diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 0b3f2b977ba0..9ceaf35a856b 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2013 Avionic Design GmbH
- * Copyright (C) 2013 NVIDIA Corporation
+ * Copyright (C) 2013-2015 NVIDIA Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -94,7 +94,7 @@ static void gr3d_close_channel(struct tegra_drm_context 
*context)
host1x_channel_put(context->channel);
 }

-static int gr3d_is_addr_reg(struct device *dev, u32 class, u32 offset)
+static int gr3d_is_addr_reg(struct device *dev, u32 class, u32 offset, u32 val)
 {
struct gr3d *gr3d = dev_get_drvdata(dev);

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index b72aa918fa69..77d977bbf922 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -295,9 +295,10 @@ struct host1x_firewall {
u32 count;
 };

-static int check_register(struct host1x_firewall *fw, unsigned long offset)
+static int check_register(struct host1x_firewall *fw,
+ unsigned long offset, u32 val)
 {
-   if (fw->job->is_addr_reg(fw->dev, fw->class, offset)) {
+   if (fw->job->is_addr_reg(fw->dev, fw->class, offset, val)) {
if (!fw->num_relocs)
return -EINVAL;

@@ -311,18 +312,21 @@ static int check_register(struct host1x_firewall *fw, 
unsigned long offset)
return 0;
 }

-static int check_mask(struct host1x_firewall *fw)
+static int check_mask(struct host1x_firewall *fw, struct host1x_job_gather *g)
 {
+   u32 *cmdbuf_base = (u32 *)fw->job->gather_copy_mapped +
+   (g->offset / sizeof(u32));
u32 mask = fw->mask;
u32 reg = fw->reg;
int ret;

while (mask) {
+   u32 val = cmdbuf_base[fw->offset];
if (fw->words == 0)
return -EINVAL;

if (mask & 1) {
-   ret = check_register(fw, reg);
+   ret = check_register(fw, reg, val);
if (ret < 0)
return ret;

@@ -336,17 +340,20 @@ static int check_mask(struct 

[PATCH 1/4] host1x: Store device address to all bufs

2015-05-21 Thread Arto Merilainen
Currently job pinning is optimized to handle only the first buffer
using a certain host1x_bo object and all subsequent buffers using
the same host1x_bo are considered done.

In most cases this is correct, however, in case the same host1x_bo
is used in multiple gathers inside the same job, we skip also
storing the device address (physical or iova) to this buffer.

This patch reworks the host1x_job_pin() to store the device address
to all gathers.

Signed-off-by: Andrew Chew 
Signed-off-by: Arto Merilainen 
---
 drivers/gpu/host1x/job.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 63bd63f3c7df..b72aa918fa69 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -1,7 +1,7 @@
 /*
  * Tegra host1x Job
  *
- * Copyright (c) 2010-2013, NVIDIA Corporation.
+ * Copyright (c) 2010-2015, NVIDIA Corporation.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -538,9 +538,12 @@ int host1x_job_pin(struct host1x_job *job, struct device 
*dev)

g->base = job->gather_addr_phys[i];

-   for (j = i + 1; j < job->num_gathers; j++)
-   if (job->gathers[j].bo == g->bo)
+   for (j = i + 1; j < job->num_gathers; j++) {
+   if (job->gathers[j].bo == g->bo) {
job->gathers[j].handled = true;
+   job->gathers[j].base = g->base;
+   }
+   }

err = do_relocs(job, g->bo);
if (err)
-- 
1.8.1.5



[PATCH 0/4] Add VIC support for Tegra124

2015-05-21 Thread Arto Merilainen
This series adds Video-Image-Compositor (VIC) support for Tegra124. The unit
replaced gr2d engine on T124 and it is effectively used for similar
operations: making simple surface copy and fill operations.

The series consists of four patches: The first patch fixes an issue in the
host1x submit routine which has prevented using same buffer object for
multiple command buffers. The second patch makes a simple improvement to
the firewall to allow implementing address register validator for VIC. The
last two patches in the series make the real modifications to Tegra DRM and
device tree to enable the engine on T124.

The series has been tested on Jetson TK1 by first disabling IOMMU (*),
enabling CMA and running a VIC clear test case that is posted to dri-devel
and linux-tegra mailing lists. The firmware image for VIC is publicly
available as part of Linux For Tegra driver package [0].

[0] https://developer.nvidia.com/linux-tegra

(*) Currently Tegra DRM does not support mapping the host1x command buffers
into kernel address space in case IOMMU is enabled.


Arto Merilainen (4):
  host1x: Store device address to all bufs
  host1x: Pass register value in firewall
  drm/tegra: Add VIC support
  ARM: tegra: Add VIC for Tegra124

 arch/arm/boot/dts/tegra124.dtsi |  11 +
 drivers/gpu/drm/tegra/Makefile  |   3 +-
 drivers/gpu/drm/tegra/drm.c |   9 +-
 drivers/gpu/drm/tegra/drm.h |   5 +-
 drivers/gpu/drm/tegra/gr2d.c|   4 +-
 drivers/gpu/drm/tegra/gr3d.c|   4 +-
 drivers/gpu/drm/tegra/vic.c | 593 
 drivers/gpu/drm/tegra/vic.h | 116 
 drivers/gpu/host1x/job.c|  44 ++-
 include/linux/host1x.h  |   5 +-
 10 files changed, 769 insertions(+), 25 deletions(-)
 create mode 100644 drivers/gpu/drm/tegra/vic.c
 create mode 100644 drivers/gpu/drm/tegra/vic.h

-- 
1.8.1.5



[PATCH libdrm] tegra: Add VIC clear test

2015-05-21 Thread Arto Merilainen
This patch adds a simple test for testing Video-Image-Compositor
engine on Tegra124 SoC. The test case opens a channel and performs
a surface clear.

Signed-off-by: Arto Merilainen 
---
 tests/tegra/Makefile.am  |   3 +-
 tests/tegra/host1x.h |  52 ++
 tests/tegra/submit_vic.c | 315 +++
 tests/tegra/vic.h| 426 +++
 4 files changed, 795 insertions(+), 1 deletion(-)
 create mode 100644 tests/tegra/host1x.h
 create mode 100644 tests/tegra/submit_vic.c
 create mode 100644 tests/tegra/vic.h

diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am
index 8e625c8fedb8..e3ef60e42039 100644
--- a/tests/tegra/Makefile.am
+++ b/tests/tegra/Makefile.am
@@ -10,4 +10,5 @@ LDADD = \
../../libdrm.la

 noinst_PROGRAMS = \
-   openclose
+   openclose \
+   submit_vic
diff --git a/tests/tegra/host1x.h b/tests/tegra/host1x.h
new file mode 100644
index ..9a72c8e69f85
--- /dev/null
+++ b/tests/tegra/host1x.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright © 2015 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef HOST1X_H
+#define HOST1X_H
+
+#include 
+
+enum host1x_class {
+   HOST1X_CLASS_HOST1X = 0x1,
+   HOST1X_CLASS_GR2D = 0x51,
+   HOST1X_CLASS_GR2D_SB = 0x52,
+   HOST1X_CLASS_VIC = 0x5D,
+   HOST1X_CLASS_GR3D = 0x60,
+};
+
+static inline uint32_t host1x_opcode_setclass(
+   unsigned class_id, unsigned offset, unsigned mask)
+{
+   return (0 << 28) | (offset << 16) | (class_id << 6) | mask;
+}
+
+static inline uint32_t host1x_opcode_incr(unsigned offset, unsigned count)
+{
+   return (1 << 28) | (offset << 16) | count;
+}
+
+static inline uint32_t host1x_opcode_nonincr(unsigned offset, unsigned count)
+{
+   return (2 << 28) | (offset << 16) | count;
+}
+
+#endif
diff --git a/tests/tegra/submit_vic.c b/tests/tegra/submit_vic.c
new file mode 100644
index ..472fde93a528
--- /dev/null
+++ b/tests/tegra/submit_vic.c
@@ -0,0 +1,315 @@
+/*
+ * Copyright © 2015 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#  include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "host1x.h"
+#include "vic.h"
+#include "xf86drm.h"
+#include "tegra.h"
+
+static const char default_device[] = "/dev/dri/card0";
+
+int main(int argc, char *argv[])
+{
+   struct drm_tegra_get_syncpt get_syncpt_args;
+   struct drm_tegra_bo *cmdbuf_bo, *histbuf_bo, *outbuf_bo,
+   *configbuf_bo;
+   uint32_t cmdbuf_bo_handle, histbuf_bo_handle,
+   outbuf_bo_handle, configbuf_bo_handle;
+   struct drm_tegra_open_channel open_channel_args = {0};
+   struct drm_tegra_syncpt submit_syncpt_incr = {0};
+   struct drm_tegra_cmdbuf submit_cmdbuf = {0};
+   

[Intel-gfx] [PATCH] drm/plane-helper: Adapt cursor hack to transitional helpers

2015-05-21 Thread Mario Kleiner
On 05/20/2015 10:36 AM, Daniel Vetter wrote:
> In
>
> commit f02ad907cd9e7fe3a6405d2d005840912f1ed258
> Author: Daniel Vetter 
> Date:   Thu Jan 22 16:36:23 2015 +0100
>
>  drm/atomic-helpers: Recover full cursor plane behaviour
>
> we've added a hack to atomic helpers to never to vblank waits for
> cursor updates through the legacy apis since that's what X expects.
> Unfortunately we've (again) forgotten to adjust the transitional
> helpers. Do this now.
>
> This fixes regressions for drivers only partially converted over to
> atomic (like i915).
>
> Reported-by: Pekka Paalanen 
> Cc: Pekka Paalanen 
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/drm_plane_helper.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 40c1db9ad7c3..2f0ed11024eb 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -465,6 +465,9 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>   if (!crtc[i])
>   continue;
>
> + if (crtc[i]->cursor == plane)
> + continue;
> +
>   /* There's no other way to figure out whether the crtc is 
> running. */
>   ret = drm_crtc_vblank_get(crtc[i]);
>   if (ret == 0) {
>

This one is

Reviewed-and-tested-by: Mario Kleiner 

I was looking into Weston performance and the cursor problem, so had 
necessary tracing in place to test this. I can confirm that cursor 
related blocking in Westons drm-backend execution are gone with this 
patch applied, whereas they are still present when using hardware 
overlays on Intel, as expected.

So hardware cursors should be fine again, once the patch also ends in 
stable kernels.

thanks,
-mario


[PATCH libdrm] tegra: Add VIC clear test

2015-05-21 Thread Emil Velikov
Hi Arto,

On 21 May 2015 at 14:18, Arto Merilainen  wrote:
> This patch adds a simple test for testing Video-Image-Compositor
> engine on Tegra124 SoC. The test case opens a channel and performs
> a surface clear.
>
> Signed-off-by: Arto Merilainen 
> ---
>  tests/tegra/Makefile.am  |   3 +-
>  tests/tegra/host1x.h |  52 ++
>  tests/tegra/submit_vic.c | 315 +++
>  tests/tegra/vic.h| 426 
> +++
>  4 files changed, 795 insertions(+), 1 deletion(-)
>  create mode 100644 tests/tegra/host1x.h
>  create mode 100644 tests/tegra/submit_vic.c
>  create mode 100644 tests/tegra/vic.h
>

Please add the two new headers into the noinst_HEADERS list like
below. Otherwise they won''t end up in the tarball, thus the test will
fail to build.

diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am
index 8e625c8..a771b32 100644
--- a/tests/tegra/Makefile.am
+++ b/tests/tegra/Makefile.am
@@ -11,3 +11,7 @@ LDADD = \

 noinst_PROGRAMS = \
openclose \
submit_vic
+
+noinst_HEADERS = \
+   host1x.h \
+   vic.h


Thanks
Emil


[PATCH 1/2] drm/nouveau: add staging module option

2015-05-21 Thread Ben Skeggs
On 21 May 2015 at 15:49, Alexandre Courbot  wrote:
> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs  wrote:
>> On 20 May 2015 at 15:56, Alexandre Courbot  wrote:
>>> Add a module option allowing to enable staging/unstable APIs. This will
>>> allow us to experiment freely with experimental APIs for a while before
>>> setting them in stone.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> ---
>>>  drm/nouveau/nouveau_drm.c  | 18 ++
>>>  drm/nouveau/uapi/drm/nouveau_drm.h |  3 +++
>>>  2 files changed, 21 insertions(+)
>>>
>>> diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
>>> index 89049335b738..e4bd6ed51e73 100644
>>> --- a/drm/nouveau/nouveau_drm.c
>>> +++ b/drm/nouveau/nouveau_drm.c
>>> @@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), 
>>> optimus only default (-1
>>>  int nouveau_runtime_pm = -1;
>>>  module_param_named(runpm, nouveau_runtime_pm, int, 0400);
>>>
>>> +MODULE_PARM_DESC(staging, "enable staging APIs");
>>> +int nouveau_staging = 0;
>>> +module_param_named(staging, nouveau_staging, int, 0400);
>>> +
>>>  static struct drm_driver driver_stub;
>>>  static struct drm_driver driver_pci;
>>>  static struct drm_driver driver_platform;
>>> @@ -895,6 +899,7 @@ nouveau_ioctls[] = {
>>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
>>> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
>>> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
>>> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>>> +   /* Staging ioctls */
>>>  };
>>>
>>>  long
>>> @@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
>>> DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
>>> DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
>>> DRM_DEBUG_DRIVER("... pstate   : %d\n", nouveau_pstate);
>>> +   DRM_DEBUG_DRIVER("... staging  : %d\n", nouveau_staging);
>>>  }
>>>
>>>  static const struct dev_pm_ops nouveau_pm_ops = {
>>> @@ -1088,6 +1094,18 @@ err_free:
>>>  static int __init
>>>  nouveau_drm_init(void)
>>>  {
>>> +   /* Do not register staging ioctsl if option not specified */
>>> +   if (!nouveau_staging) {
>>> +   unsigned i;
>>> +
>>> +   /* This keeps us safe is no staging ioctls are defined */
>>> +   i = min(driver_stub.num_ioctls, DRM_NOUVEAU_STAGING_IOCTL);
>>> +   while (!nouveau_ioctls[i - 1].func)
>>> +   i--;
>>> +
>>> +   driver_stub.num_ioctls = i;
>>> +   }
>> Hey Alex,
>>
>> I've got no specific objection.  But I'm curious as to why you took
>> this approach as opposed to just adding "if (!nouveau_staging) return
>> -EINVAL;" directly in the experimental ioctls?
>
> Mainly because we will likely forget to add this check (or to remove
> it) in some of the staging ioctls. The current solution doesn't
> require us to think about that - and the less things to think about,
> the better.
>
>> I think, in line with
>> what's been done in other places, having module options per-api is
>> perhaps a better choice too.
>
> Do you mean that each experimental ioctl should have its own enable
> option? I don't mind going that way if you think it is preferable. And
> in that case my comment above is void.
That would be more preferable I think, and obvious as to what exactly
you're enabling.

>
> But actually I wonder if having these experimental ioctls enabled as
> compile options (either individually or as a whole) would not be
> better. Some experimental ioctls may require code in staging (like the
> PUSHBUF_2 ioctl that I would like to submit next), and I don't think
> it is desirable to force extra code or kernel options (in this case,
> CONFIG_STAGING) to Nouveau users who will not make use of them. I
> remember that we concluded in favor or module options on IRC, but in
> the light of this, wouldn't a config option be a less intrusive
> choice?
Right, but the whole point of this is to encourage the ioctls to not
live there for too long, and progress to fully supported interfaces.

Ben.


[PULL] drm-intel-fixes

2015-05-21 Thread Jani Nikula

Hi Dave, one fix for screen flickering.

There's a stable backport from Ander [1] that combines this and a few
other commits to fix the flickering on v4.0, reported in [2] among
others. Having this upstream is obviously a requirement for stable.


BR,
Jani.


[1] 
http://mid.gmane.org/1432128754-11840-1-git-send-email-ander.conselvan.de.oliveira
 at intel.com
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1218688


The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:

  Linux 4.1-rc4 (2015-05-18 10:13:47 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-05-21

for you to fetch changes up to 54da691deb123c045259ebf4f5c67381244f58f1:

  drm/i915: fix screen flickering (2015-05-19 10:28:34 +0300)


Thomas Gummerer (1):
  drm/i915: fix screen flickering

 drivers/gpu/drm/i915/intel_pm.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm/vgem: implement virtual GEM

2015-05-21 Thread Thomas Hellstrom
On 05/21/2015 11:13 AM, Daniel Vetter wrote:
> On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote:
>> On 11/25/2014 02:08 AM, Zachary Reizner wrote:
>>> After looking into removing platform_device, I found that using
>>> dma_buf_attach with a NULL device always returns an error, thereby
>>> preventing me from using VGEM for import and mmap. The solution seems
>>> to be to skip using dma_buf_attach, and instead use dma_buf_mmap when
>>> user-space tries to mmap a gem object that was imported into VGEM. The
>>> drawback to this approach is that most drivers stub their
>>> dma_buf_ops->mmap implementation. Presumably mmap could be implemented
>>> for the drivers that this would make sense for. Are there any
>>> comments, questions, or concerns for this proposed solution?
>> I see now that this driver has entered -next, and I'm sorry this comment
>> didn't arrive before. I simply missed this discussion :(
>>
>> My biggest concern, as stated many many times before, is that dma-buf
>> mmap is a horrible interface for incoherent drivers, and for drivers
>> that use odd format (tiled) dma-bufs, basically since it doesn't supply
>> a dirtied region. Therefore (correct me if I'm wrong) there has been an
>> agreement that for purposes outside of ARM SOC, we should simply not
>> implement dma-buf mmap for other uses than for internal driver use.
>>
>> So assume a real driver implements dma-buf mmap, but it is crawling due
>> to coherency- or untiling / tiling operations. How do you tell a generic
>> user of the vgem driver *NOT* to mmap for performance reasons? Or is
>> this driver only intended for ARM SOC systems?
> Seconded. Somehow I thought we've pulled in vgem to support software
> rendering like llvmpipe, and I remember that that's been the original
> justification. TIL that that's indeed not the case and google is
> splattering their cros tree with dma_buf->mmap implementations this is
> obviously not the case and the intention really seems to be to use
> dma_buf->mmap and vgem as the generic interface to expose buffer objects
> of real drivers to software rendering.
>
> Given that neither vgem nor dma_buf->mmap has any sane concept of handling
> coherency I'm really unhappy about this and tempted to just submit the
> revert for vgem before 4.1 ships. I'll chat with relevant people a bit
> more. Worse I chatted with Stephane today and he brushed this off as
> not-my-problem and if this hurts intel intel should fix this. That's not
> how a proper usptream interface is getting designd, and coherency handling
> is an even more serious problem on arm an virtual hw like vmwgfx.

So given how this has turned out, my opinion is that before a usable
generic mmap of accelerated buffer objects
goes upstream, there should be a proper interface to request regions
present and to dirty regions. It seems to me that so far
all use-cases are for one- or two-dimensional access so it should be
sufficient to start with that and add other access
modes later on. Now this is no guarantee that people won't request and
dirty the whole dma-buf on each access, but at least
that would make people think, and if things become slow it's pretty
clear where the problem is.

I'm all for delaying vgem until we have such an interface in place.

Thanks,
Thomas




>  On intel
> (well at least big core thanks to the huge coherent cache fabric) this is
> mostly a non-issue, except that the patch in the cros tree obviously gets
> things wrong.
>
> Decently pissed tbh.
>
> Cheers, Daniel



[Bug 89228] Regression with left for dead 2

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89228

--- Comment #4 from Daniel Scharrer  ---
Are you still experiencing lockups?

If so, can you
a) run the game with R600_DEBUG=switch_on_eop
and
b) compile LLVM with the patch from bug #90378 comment 2 and run without
R600_DEBUG

This should at least confirm if we are seeing the same issue.

-- 
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/20150521/8d23fd0f/attachment.html>


[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90378

--- Comment #4 from Daniel Scharrer  ---
Created attachment 115956
  --> https://bugs.freedesktop.org/attachment.cgi?id=115956=edit
R600_DEBUG=ps,vs,gs output with r233366 (lockups)

-- 
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/20150521/4fc73666/attachment.html>


[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90378

Daniel Scharrer  changed:

   What|Removed |Added

 Attachment #115952|text/plain  |application/x-xz
  mime type||

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


[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90378

--- Comment #3 from Daniel Scharrer  ---
Created attachment 115952
  --> https://bugs.freedesktop.org/attachment.cgi?id=115952=edit
R600_DEBUG=ps,vs,gs output with r233365 (no lockups)

-- 
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/20150521/cd3310da/attachment.html>


[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Gustavo Padovan
2015-05-21 Tobias Jakobi :

> Gustavo Padovan wrote:
> > 2015-05-21 Gustavo Padovan :
> > 
> >> 2015-05-21 Tobias Jakobi :
> >>
> >>> Hi,
> >>>
> >>> like I said before, this clashes with my commit 'drm/exynos: plane: honor
> >>> buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58),
> >>> which is currently sitting in airlied's drm-fixes.
> >>
> >> Inki has to merge his -fixes tree into exynos-drm-next to solve this.
> >> It is the only way I can rebase on top of your commit and solve the
> >> conflict.
> >> Anyway, I just figured that exynos-drm-next was updated from yesterday
> >> to today so this v5 doesn't apply on today's tree. I'll send a v6 once
> >> Inki merges "drm/exynos: plane: honor buffer offset for dma_addr" into
> >> exynos-drm-next.
> >>
> >> Inki, can you please do that? so we can proceed with atomic and
> >> hopefully have it ready for 4.2 merge window.
> > 
> > Actually the patch is on exynos-drm-next but with a different commit id.
> > I wonder why. Why did you applied it directly to your branch instead of
> > merging the -fixes tree? Now we have the same commit with the differents
> > hashes in the tree.
> I never do merges for my tree, I always rebase (either on stable/linux
> or torvalds/master). For submitting patches I cherry-pick stuff to the
> corresponding upstream branch (exynos-drm-next in this case) and then
> submit via git-send-email.

Actually I'm asking Inki. He pushed the same patch twice.

Gustavo


[PATCH] nouveau: add coherent BO attribute

2015-05-21 Thread Alexandre Courbot
On Wed, May 20, 2015 at 3:53 PM, Martin Peres  wrote:
> On 20/05/15 08:11, Alexandre Courbot wrote:
>>
>> On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
>>  wrote:
>>>
>>> Op 15-05-15 om 09:11 schreef Alexandre Courbot:

 Re-pinging Marteen on an email address that still exists :P

 On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot 
 wrote:
>
> On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot
>  wrote:
>>
>> On 03/14/2015 04:33 AM, Maarten Lankhorst wrote:
>>>
>>> Hey,
>>>
>>> Op 13-03-15 om 07:27 schreef Alexandre Courbot:

 Add a flag allowing Nouveau to specify that an object should be
 coherent
 at allocation time. This is required for some class of objects like
 fences which are randomly-accessed by both the CPU and GPU. This
 flag
 instructs the kernel driver to make sure the object remains coherent
 even on architectures for which coherency is not guaranteed by the
 bus.

 Signed-off-by: Alexandre Courbot 
>>>
>>> I don't see a problem with this patch, but similar patches to intel
>>> to
>>> libdrm have been shot down when the changes weren't in an official
>>> kernel
>>> yet, so I think this should wait until the change is at least in
>>> drm-next.
>>> ;-)
>>
>> Sounds good. I will ping you again once the kernel change reaches
>> -next.
>
> Hi Marteen,
>
> The kernel change required for this patch is now in -next. Do you
> think we can merge it now?
>>>
>>> I think it would be ok to merge now.
>>
>> Great - who could do this? :P
>
>
> I could do it. Please provide me with the patch with the necessary R-b and I
> can push it to our libdrm (and/or mesa).

Thanks, I just sent a v2 with you included. I have yet to receive
formal R-b and A-b for it though.


[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90378

Daniel Scharrer  changed:

   What|Removed |Added

Summary|GPU lockups in Left 4 Dead  |[radeonsi][bisected] GPU
   |2   |lockups in Left 4 Dead 2

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


[Bug 90378] GPU lockups in Left 4 Dead 2

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90378

--- Comment #2 from Daniel Scharrer  ---
Created attachment 115951
  --> https://bugs.freedesktop.org/attachment.cgi?id=115951=edit
patch to revert LLVM r233366 (fixes lockups)

This seems to be a regression in llvm:
Mesa git + LLVM svn is bad
Mesa 10.5.5 + LLVM svn is bad
Mesa git + LLVM 3.6.0 is good (no lockups, no glitches)

With Mesa git, the lockups in the L4D2 apitrace linked above bisect to LLVM
r233366:

commit 9217916725713c00f17cb64123e8dffdae843eb7
Author: Andrew Trick 
Date:   Fri Mar 27 06:10:13 2015 +

Complete the MachineScheduler fix made way back in r210390.

"Fix the MachineScheduler's logic for updating ready times for in-order.
 Now the scheduler updates a node's ready time as soon as it is
 scheduled, before releasing dependent nodes."

This fix was only made in one variant of the ScheduleDAGMI driver.
Francois de Ferriere reported the issue in the other bit of code where
it was also needed.
I never got around to coming up with a test case, but it's an
obvious fix that shouldn't be delayed any longer.
I'll try to refactor this code a little better.

I did verify performance on a wide variety of targets and saw no
negative impact with this fix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 233366
91177308-0d34-0410-b5e6-96231b3b80d8


I had to revert b8797a7 and a99a16a in Mesa for it to build against that LLVM
revision.

Besides the arch-specific test files, r233366 only moves one line of code
around. Reverting that on current LLVM (see attached patch) also fixes the
lockups.

As with bug #90510, R600_DEBUG=switch_on_eop gets rid of the glitches, and also
prevents the crashes as well. Not sure if that means it could be a bug in Mesa
or if that just hides the LLVM bug.

While bisecting for the lockup, I noticed the glitches were also introduced in
LLVM after 3.6.0, but not by the same revision - f74b5c6 (r231401) has no
lockups but does have glitches. I'll bisect that for bug #88561 as the glitches
in the latest Talos apitrace there also seem to come from that commit range.
(The GPU faults - bug #87278 - seem to have yet another cause, being present
even with LLVM 3.6.0.)

NB: I also noticed that with compositing enabled in KWin, the system is not
able to recover from the GPU lockups (and eventually does not even respond to
SSH or SysRq). With compositing disabled the GPU is almost always reset
successfully and the game / glretrace can continue as if nothing happened.

-- 
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/20150521/55d34ebc/attachment.html>


[PATCH v2] nouveau: add coherent BO attribute

2015-05-21 Thread Alexandre Courbot
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required for some class of objects like
fences which are randomly-accessed by both the CPU and GPU. This flag
instructs the kernel driver to make sure the object remains coherent
even on architectures for which coherency is not guaranteed by the bus.

Signed-off-by: Alexandre Courbot 
---
Changes since v1:
None, just added Martin so he can merge the patch. R-b and A-b wanted. :)

 include/drm/nouveau_drm.h | 1 +
 nouveau/abi16.c   | 3 +++
 nouveau/nouveau.h | 1 +
 3 files changed, 5 insertions(+)

diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index b18cad02419b..87aefc5e9d2f 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -96,6 +96,7 @@ struct drm_nouveau_setparam {
 #define NOUVEAU_GEM_DOMAIN_VRAM  (1 << 1)
 #define NOUVEAU_GEM_DOMAIN_GART  (1 << 2)
 #define NOUVEAU_GEM_DOMAIN_MAPPABLE  (1 << 3)
+#define NOUVEAU_GEM_DOMAIN_COHERENT  (1 << 4)

 #define NOUVEAU_GEM_TILE_LAYOUT_MASK 0xff00
 #define NOUVEAU_GEM_TILE_16BPP   0x0001
diff --git a/nouveau/abi16.c b/nouveau/abi16.c
index 538f3a730dbe..4ca0bfbaf592 100644
--- a/nouveau/abi16.c
+++ b/nouveau/abi16.c
@@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment,
if (bo->flags & NOUVEAU_BO_MAP)
info->domain |= NOUVEAU_GEM_DOMAIN_MAPPABLE;

+   if (bo->flags & NOUVEAU_BO_COHERENT)
+   info->domain |= NOUVEAU_GEM_DOMAIN_COHERENT;
+
if (!(bo->flags & NOUVEAU_BO_CONTIG))
info->tile_flags = NOUVEAU_GEM_TILE_NONCONTIG;

diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index a55e2b020778..4adda0e3594c 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -127,6 +127,7 @@ union nouveau_bo_config {
 #define NOUVEAU_BO_MAP 0x8000
 #define NOUVEAU_BO_CONTIG  0x4000
 #define NOUVEAU_BO_NOSNOOP 0x2000
+#define NOUVEAU_BO_COHERENT 0x1000

 struct nouveau_bo {
struct nouveau_device *device;
-- 
2.4.0



[PATCH 1/2] drm/nouveau: add staging module option

2015-05-21 Thread Alexandre Courbot
On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs  wrote:
> On 21 May 2015 at 15:49, Alexandre Courbot  wrote:
>> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs  wrote:
>>> On 20 May 2015 at 15:56, Alexandre Courbot  wrote:
 Add a module option allowing to enable staging/unstable APIs. This will
 allow us to experiment freely with experimental APIs for a while before
 setting them in stone.

 Signed-off-by: Alexandre Courbot 
 ---
  drm/nouveau/nouveau_drm.c  | 18 ++
  drm/nouveau/uapi/drm/nouveau_drm.h |  3 +++
  2 files changed, 21 insertions(+)

 diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
 index 89049335b738..e4bd6ed51e73 100644
 --- a/drm/nouveau/nouveau_drm.c
 +++ b/drm/nouveau/nouveau_drm.c
 @@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), 
 optimus only default (-1
  int nouveau_runtime_pm = -1;
  module_param_named(runpm, nouveau_runtime_pm, int, 0400);

 +MODULE_PARM_DESC(staging, "enable staging APIs");
 +int nouveau_staging = 0;
 +module_param_named(staging, nouveau_staging, int, 0400);
 +
  static struct drm_driver driver_stub;
  static struct drm_driver driver_pci;
  static struct drm_driver driver_platform;
 @@ -895,6 +899,7 @@ nouveau_ioctls[] = {
 DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, 
 nouveau_gem_ioctl_cpu_prep, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, 
 nouveau_gem_ioctl_cpu_fini, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
 DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
 +   /* Staging ioctls */
  };

  long
 @@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
 DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
 DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
 DRM_DEBUG_DRIVER("... pstate   : %d\n", nouveau_pstate);
 +   DRM_DEBUG_DRIVER("... staging  : %d\n", nouveau_staging);
  }

  static const struct dev_pm_ops nouveau_pm_ops = {
 @@ -1088,6 +1094,18 @@ err_free:
  static int __init
  nouveau_drm_init(void)
  {
 +   /* Do not register staging ioctsl if option not specified */
 +   if (!nouveau_staging) {
 +   unsigned i;
 +
 +   /* This keeps us safe is no staging ioctls are defined */
 +   i = min(driver_stub.num_ioctls, DRM_NOUVEAU_STAGING_IOCTL);
 +   while (!nouveau_ioctls[i - 1].func)
 +   i--;
 +
 +   driver_stub.num_ioctls = i;
 +   }
>>> Hey Alex,
>>>
>>> I've got no specific objection.  But I'm curious as to why you took
>>> this approach as opposed to just adding "if (!nouveau_staging) return
>>> -EINVAL;" directly in the experimental ioctls?
>>
>> Mainly because we will likely forget to add this check (or to remove
>> it) in some of the staging ioctls. The current solution doesn't
>> require us to think about that - and the less things to think about,
>> the better.
>>
>>> I think, in line with
>>> what's been done in other places, having module options per-api is
>>> perhaps a better choice too.
>>
>> Do you mean that each experimental ioctl should have its own enable
>> option? I don't mind going that way if you think it is preferable. And
>> in that case my comment above is void.
> That would be more preferable I think, and obvious as to what exactly
> you're enabling.
>
>>
>> But actually I wonder if having these experimental ioctls enabled as
>> compile options (either individually or as a whole) would not be
>> better. Some experimental ioctls may require code in staging (like the
>> PUSHBUF_2 ioctl that I would like to submit next), and I don't think
>> it is desirable to force extra code or kernel options (in this case,
>> CONFIG_STAGING) to Nouveau users who will not make use of them. I
>> remember that we concluded in favor or module options on IRC, but in
>> the light of this, wouldn't a config option be a less intrusive
>> choice?
> Right, but the whole point of this is to encourage the ioctls to not
> live there for too long, and progress to fully supported interfaces.

Definitely, but my concern is that doing this will make Nouveau depend
on STAGING for at least short periods of time. Do we really want this?


[PATCH 1/2] drm/nouveau: add staging module option

2015-05-21 Thread Alexandre Courbot
On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs  wrote:
> On 20 May 2015 at 15:56, Alexandre Courbot  wrote:
>> Add a module option allowing to enable staging/unstable APIs. This will
>> allow us to experiment freely with experimental APIs for a while before
>> setting them in stone.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drm/nouveau/nouveau_drm.c  | 18 ++
>>  drm/nouveau/uapi/drm/nouveau_drm.h |  3 +++
>>  2 files changed, 21 insertions(+)
>>
>> diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
>> index 89049335b738..e4bd6ed51e73 100644
>> --- a/drm/nouveau/nouveau_drm.c
>> +++ b/drm/nouveau/nouveau_drm.c
>> @@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), 
>> optimus only default (-1
>>  int nouveau_runtime_pm = -1;
>>  module_param_named(runpm, nouveau_runtime_pm, int, 0400);
>>
>> +MODULE_PARM_DESC(staging, "enable staging APIs");
>> +int nouveau_staging = 0;
>> +module_param_named(staging, nouveau_staging, int, 0400);
>> +
>>  static struct drm_driver driver_stub;
>>  static struct drm_driver driver_pci;
>>  static struct drm_driver driver_platform;
>> @@ -895,6 +899,7 @@ nouveau_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
>> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
>> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
>> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>> +   /* Staging ioctls */
>>  };
>>
>>  long
>> @@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
>> DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
>> DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
>> DRM_DEBUG_DRIVER("... pstate   : %d\n", nouveau_pstate);
>> +   DRM_DEBUG_DRIVER("... staging  : %d\n", nouveau_staging);
>>  }
>>
>>  static const struct dev_pm_ops nouveau_pm_ops = {
>> @@ -1088,6 +1094,18 @@ err_free:
>>  static int __init
>>  nouveau_drm_init(void)
>>  {
>> +   /* Do not register staging ioctsl if option not specified */
>> +   if (!nouveau_staging) {
>> +   unsigned i;
>> +
>> +   /* This keeps us safe is no staging ioctls are defined */
>> +   i = min(driver_stub.num_ioctls, DRM_NOUVEAU_STAGING_IOCTL);
>> +   while (!nouveau_ioctls[i - 1].func)
>> +   i--;
>> +
>> +   driver_stub.num_ioctls = i;
>> +   }
> Hey Alex,
>
> I've got no specific objection.  But I'm curious as to why you took
> this approach as opposed to just adding "if (!nouveau_staging) return
> -EINVAL;" directly in the experimental ioctls?

Mainly because we will likely forget to add this check (or to remove
it) in some of the staging ioctls. The current solution doesn't
require us to think about that - and the less things to think about,
the better.

> I think, in line with
> what's been done in other places, having module options per-api is
> perhaps a better choice too.

Do you mean that each experimental ioctl should have its own enable
option? I don't mind going that way if you think it is preferable. And
in that case my comment above is void.

But actually I wonder if having these experimental ioctls enabled as
compile options (either individually or as a whole) would not be
better. Some experimental ioctls may require code in staging (like the
PUSHBUF_2 ioctl that I would like to submit next), and I don't think
it is desirable to force extra code or kernel options (in this case,
CONFIG_STAGING) to Nouveau users who will not make use of them. I
remember that we concluded in favor or module options on IRC, but in
the light of this, wouldn't a config option be a less intrusive
choice?


[PATCH 1/2] drm/nouveau: add staging module option

2015-05-21 Thread Ben Skeggs
On 20 May 2015 at 15:56, Alexandre Courbot  wrote:
> Add a module option allowing to enable staging/unstable APIs. This will
> allow us to experiment freely with experimental APIs for a while before
> setting them in stone.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  drm/nouveau/nouveau_drm.c  | 18 ++
>  drm/nouveau/uapi/drm/nouveau_drm.h |  3 +++
>  2 files changed, 21 insertions(+)
>
> diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
> index 89049335b738..e4bd6ed51e73 100644
> --- a/drm/nouveau/nouveau_drm.c
> +++ b/drm/nouveau/nouveau_drm.c
> @@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), 
> optimus only default (-1
>  int nouveau_runtime_pm = -1;
>  module_param_named(runpm, nouveau_runtime_pm, int, 0400);
>
> +MODULE_PARM_DESC(staging, "enable staging APIs");
> +int nouveau_staging = 0;
> +module_param_named(staging, nouveau_staging, int, 0400);
> +
>  static struct drm_driver driver_stub;
>  static struct drm_driver driver_pci;
>  static struct drm_driver driver_platform;
> @@ -895,6 +899,7 @@ nouveau_ioctls[] = {
> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
> +   /* Staging ioctls */
>  };
>
>  long
> @@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
> DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
> DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
> DRM_DEBUG_DRIVER("... pstate   : %d\n", nouveau_pstate);
> +   DRM_DEBUG_DRIVER("... staging  : %d\n", nouveau_staging);
>  }
>
>  static const struct dev_pm_ops nouveau_pm_ops = {
> @@ -1088,6 +1094,18 @@ err_free:
>  static int __init
>  nouveau_drm_init(void)
>  {
> +   /* Do not register staging ioctsl if option not specified */
> +   if (!nouveau_staging) {
> +   unsigned i;
> +
> +   /* This keeps us safe is no staging ioctls are defined */
> +   i = min(driver_stub.num_ioctls, DRM_NOUVEAU_STAGING_IOCTL);
> +   while (!nouveau_ioctls[i - 1].func)
> +   i--;
> +
> +   driver_stub.num_ioctls = i;
> +   }
Hey Alex,

I've got no specific objection.  But I'm curious as to why you took
this approach as opposed to just adding "if (!nouveau_staging) return
-EINVAL;" directly in the experimental ioctls?  I think, in line with
what's been done in other places, having module options per-api is
perhaps a better choice too.

Ben.

> +
> driver_pci = driver_stub;
> driver_pci.set_busid = drm_pci_set_busid;
> driver_platform = driver_stub;
> diff --git a/drm/nouveau/uapi/drm/nouveau_drm.h 
> b/drm/nouveau/uapi/drm/nouveau_drm.h
> index 5507eead5863..4e7e21f41b5c 100644
> --- a/drm/nouveau/uapi/drm/nouveau_drm.h
> +++ b/drm/nouveau/uapi/drm/nouveau_drm.h
> @@ -140,11 +140,14 @@ struct drm_nouveau_gem_cpu_fini {
>  #define DRM_NOUVEAU_GEM_CPU_PREP   0x42
>  #define DRM_NOUVEAU_GEM_CPU_FINI   0x43
>  #define DRM_NOUVEAU_GEM_INFO   0x44
> +/* range 0x98..DRM_COMMAND_END (8 entries) is reserved for staging, unstable 
> ioctls */
> +#define DRM_NOUVEAU_STAGING_IOCTL  0x58
>
>  #define DRM_IOCTL_NOUVEAU_GEM_NEWDRM_IOWR(DRM_COMMAND_BASE + 
> DRM_NOUVEAU_GEM_NEW, struct drm_nouveau_gem_new)
>  #define DRM_IOCTL_NOUVEAU_GEM_PUSHBUFDRM_IOWR(DRM_COMMAND_BASE + 
> DRM_NOUVEAU_GEM_PUSHBUF, struct drm_nouveau_gem_pushbuf)
>  #define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP   DRM_IOW (DRM_COMMAND_BASE + 
> DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_prep)
>  #define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI   DRM_IOW (DRM_COMMAND_BASE + 
> DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_cpu_fini)
>  #define DRM_IOCTL_NOUVEAU_GEM_INFO   DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_NOUVEAU_GEM_INFO, struct drm_nouveau_gem_info)
> +/* staging ioctls */
>
>  #endif /* __NOUVEAU_DRM_H__ */
> --
> 2.4.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Nouveau] [PATCH] ram/gf100-: error out if a ridiculous amount of vram is detected

2015-05-21 Thread Ben Skeggs
On 21 May 2015 at 06:01, Ilia Mirkin  wrote:
> Some newer chips have trouble coming up, and we get bad MMIO reads from
> them, like 0xbadf100. This ends up translating into crazy amounts of
> VRAM, which destroys all sorts of other logic down the line. Instead,
> fail device init.
Hrm, I'm not sure what I think of doing something like this.  Where do
we draw the line at validating stuff we read from GPU registers?
Either way, we still have a bug, so I'm not sure what we gain from
working around it like this.

Ben.

>
> Signed-off-by: Ilia Mirkin 
> Cc: stable at kernel.org
> ---
>  drm/nouveau/nvkm/subdev/fb/ramgf100.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c 
> b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> index de9f395..9d4d196 100644
> --- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> +++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> @@ -545,6 +545,12 @@ gf100_ram_create_(struct nvkm_object *parent, struct 
> nvkm_object *engine,
> }
> }
>
> +   /* if over 1TB of VRAM is reported, something went very wrong, bail */
> +   if (ram->size > (1ULL << 40)) {
> +   nv_error(pfb, "invalid vram size: %llx\n", ram->size);
> +   return -EINVAL;
> +   }
> +
> /* if all controllers have the same amount attached, there's no holes 
> */
> if (uniform) {
> offset = rsvd_head;
> --
> 2.3.6
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau


[pull] radeon drm-fixes-4.1

2015-05-21 Thread Alex Deucher
Hi Dave,

Just two small DP fixes for 4.1

The following changes since commit 755c814a7d826257d5488cfaa801ec19377c472a:

  drm/msm/mdp5: fix incorrect parameter for msm_framebuffer_iova() (2015-05-21 
14:31:45 +1000)

are available in the git repository at:

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

for you to fetch changes up to 6ca121351bf65f9f3375d3b0d54c2aed3b3f47ad:

  drm/radeon: fix error flag checking in native aux path (2015-05-21 12:43:21 
-0400)


Alex Deucher (2):
  drm/radeon: retry dcpd fetch
  drm/radeon: fix error flag checking in native aux path

 drivers/gpu/drm/radeon/atombios_dp.c | 20 +++-
 drivers/gpu/drm/radeon/radeon_dp_auxch.c |  2 --
 2 files changed, 11 insertions(+), 11 deletions(-)


[PATCH] ARM: dts: exynos4412-trats2: set display clock correctly

2015-05-21 Thread Kukjin Kim
On 05/20/15 09:12, Krzysztof Kozlowski wrote:
> 2015-02-07 19:49 GMT+09:00 Inki Dae :
>> This patch sets display clock correctly.
>>
>> If Display clock isn't set correctly then you would find below messages
>> and Display controller doesn't work correctly since a patch[1]
>>
>>exynos-drm: No connectors reported connected with modes
>>[drm] Cannot find any crtc or sizes - going 1024x768
>>
>> [1] commit abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
> 
> Reviewed-by: Krzysztof Kozlowski 
> Tested-by: Krzysztof Kozlowski 
> 
> Tested on Trats2 board.
> 
> Dear Kukjin,
> 
> Could you pull it to current fixes branch (this RC cycle)? The patch
> fixes display on Trats2 board. Without it (since abc0b1447d49) it
> won't be properly set up and device boots with blank screen and
> mentioned error message in logs.
> 
> I think this actually is a candidate for stable backporting (4.0+)
> because it fixes important functionality of device:
> 
> Fixes: abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
> Cc: 
> 
Thanks, applied, and will be sent out in a day for v4.1-rc.

- Kukjin


[Intel-gfx] [PATCH] drm/edid: Fix DDC probe for passive DP dongles

2015-05-21 Thread Daniel Vetter
On Thu, May 21, 2015 at 11:28:48AM +0300, Jani Nikula wrote:
> On Thu, 21 May 2015, Todd Previte  wrote:
> > Passive DP->DVI/HDMI dongles show up to the system as HDMI devices, as they
> > do not have a sink device in them to respond to any AUX traffic. When
> > probing these dongles over the DDC, sometimes they will NAK the first 
> > attempt
> > even though the transaction is valid and they support the DDC protocol. The
> > retry loop inside of drm_do_probe_ddc_edid() would normally catch this case
> > and try the transaction again, resulting in success.
> >
> > That, however, was thwarted by the fix for fdo.org bug #41059. The patch is:
> > commit 9292f37e1f5c79400254dca46f83313488093825
> > Author: Eugeni Dodonov 
> > Date:   Thu Jan 5 09:34:28 2012 -0200
> >
> > drm: give up on edid retries when i2c bus is not responding
> 
> Some extra background:
> 
> That commit refers to the i2c bit banging code, while i915 now prefers
> gmbus, and only falls back to big banging on certain failures. (See
> gmbux_xfer() in i915/intel_i2c.c). This means that in most cases i915 is
> no longer susceptible to the 5*3 timeout loops, but it also means we
> don't have the i2c bit banging retry at all on -ENXIO, like Todd notes.
> 
> The questions are, is one retry after -ENXIO in drm_do_probe_ddc_edid
> enough now? Should we revert the original commit instead since the
> underlying algorithm has changed? Or should we return something other
> than -ENXIO from our gmbus code to not hit this exit with no retries
> path?

Jani dug around a bit on this on irc and it looks like a proper i2c
implementation should indeed retry on the first ENXIO, except when the
I2C_M_IGNORE_NAK flag is set. There's piles of examples how to do it, but
it's clear that we've never done this properly in our gmbus driver.

Can you please test whether fixing that in intel_i2c.c does resolve the
issue too? It would at least explain a lot of the fallback troubles we've
had with gmbus and i2c slaves not waking up in time, which all got
magically resolved by falling back to the bit-banging interface (which
does this retrying already).

Thanks, Daniel

> 
> > This added code to exit immediately if the return code from the
> > i2c_transfer function was -ENXIO in order to reduce the amount of time spent
> > in waiting for unresponsive or disconnected devices. For the DP dongles,
> > this means that the second retry never happens which results in a failed
> > EDID probe and a black screen.
> >
> > To work around this problem without undoing the fix for bug #41059, the
> > number of retries is checked along with the return code. This allows for a
> > device to NAK once and still continue operations. A second NAK will result
> > in breaking the loop as it would have before and stopping the DDC probe.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
> 
> Maybe throw this at other dongle bugs you can find too?
> 
> We're going to need Tested-bys though.
> 
> BR,
> Jani.
> 
> 
> > Signed-off-by: Todd Previte 
> > Cc: intel-gfx at lists.freedesktop.org
> > ---
> >  drivers/gpu/drm/drm_edid.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 7087da3..e8047bd 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -1238,7 +1238,10 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned 
> > int block, size_t len)
> >  */
> > ret = i2c_transfer(adapter, [3 - xfers], xfers);
> >  
> > -   if (ret == -ENXIO) {
> > +   /* Passive DP->DVI/HDMI dongles sometimes NAK the first probe
> > +* Try to probe again but if it NAKs, stop trying
> > +*/
> > +   if (ret == -ENXIO && retries < 5) {
> > DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> > adapter->name);
> > break;
> > -- 
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> 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 v4 2/2] drm/DocBook: Add more drm_bridge documentation

2015-05-21 Thread Daniel Vetter
On Thu, May 21, 2015 at 10:03:38AM +0200, Daniel Vetter wrote:
> On Thu, May 21, 2015 at 11:03:17AM +0530, Archit Taneja wrote:
> > Add DOC sections giving an overview of drm_bridge and how to fill up the
> > drm_bridge_funcs ops. Add these to drm.tpml in DocBook.
> > 
> > Add headerdocs for funcs in drm_bridge.c that don't have them yet.
> > 
> > Signed-off-by: Archit Taneja 
> > ---
> >  Documentation/DocBook/drm.tmpl | 12 ++
> >  drivers/gpu/drm/drm_bridge.c   | 94 
> > ++
> >  2 files changed, 106 insertions(+)
> > 
> > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> > index 9765a4c..1dc0f45 100644
> > --- a/Documentation/DocBook/drm.tmpl
> > +++ b/Documentation/DocBook/drm.tmpl
> > @@ -2439,6 +2439,18 @@ void intel_crt_init(struct drm_device *dev)
> >   Tile group
> >  !Pdrivers/gpu/drm/drm_crtc.c Tile group
> >  
> > +
> > +   Bridges
> > +  
> > +Overview
> > +!Pdrivers/gpu/drm/drm_bridge.c overview
> > +  
> > +  
> > +Default bridge callback sequence
> > +!Pdrivers/gpu/drm/drm_bridge.c bridge callbacks
> > +  
> > +!Edrivers/gpu/drm/drm_bridge.c
> > +
> >
> >  
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index c3a85ce..a7c4e10 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -28,9 +28,42 @@
> >  
> >  #include "drm/drmP.h"
> >  
> > +/**
> > + * DOC: overview
> > + *
> > + * drm_bridge represents a device that hangs on to an encoder. These are 
> > handy
> > + * when a regular drm_encoder entity isn't enough to represent the entire
> > + * encoder chain.
> > + *
> > + * A bridge is always associated to a single drm_encoder at a time, but 
> > can be
> > + * either connected to it directly, or through an intermediate bridge:
> > + *
> > + * encoder ---> bridge B ---> bridge A
> > + *
> > + * Here, the output of the encoder feeds to bridge B, and that furthers 
> > feeds to
> > + * bridge A.
> > + *
> > + * The driver using the bridge is responsible to make the associations 
> > between
> > + * the encoder and bridges. Once these links are made, the bridges will
> > + * participate along with encoder functions to perform 
> > mode_set/enable/disable
> > + * through the ops provided in drm_bridge_funcs.
> > + *
> > + * drm_bridge, like drm_panel, aren't drm_mode_object entities like planes,
> > + * crtcs, encoders or connectors. They just provide additional hooks to 
> > get the
> > + * desired output at the end of the encoder chain.
> > + */
> > +
> >  static DEFINE_MUTEX(bridge_lock);
> >  static LIST_HEAD(bridge_list);
> >  
> > +/**
> > + * drm_bridge_add - add the given bridge to the global bridge list
> > + *
> > + * @bridge: bridge control structure
> > + *
> > + * RETURNS:
> > + * Unconditionally returns Zero.
> > + */
> >  int drm_bridge_add(struct drm_bridge *bridge)
> >  {
> > mutex_lock(_lock);
> > @@ -41,6 +74,11 @@ int drm_bridge_add(struct drm_bridge *bridge)
> >  }
> >  EXPORT_SYMBOL(drm_bridge_add);
> >  
> > +/**
> > + * drm_bridge_remove - remove the given bridge from the global bridge list
> > + *
> > + * @bridge: bridge control structure
> > + */
> >  void drm_bridge_remove(struct drm_bridge *bridge)
> >  {
> > mutex_lock(_lock);
> > @@ -49,6 +87,21 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >  }
> >  EXPORT_SYMBOL(drm_bridge_remove);
> >  
> > +/**
> > + * drm_bridge_attach - associate given bridge to our DRM device
> > + *
> > + * @dev: DRM device
> > + * @bridge: bridge control structure
> > + *
> > + * called by a kms driver to link one of our encoder/bridge to the given
> > + * bridge.
> > + *
> > + * Note that setting up links between the bridge and our encoder/bridge
> > + * objects needs to be handled by the kms driver itself
> > + *
> > + * RETURNS:
> > + * Zero on success, error code on failure
> > + */
> >  int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
> >  {
> > if (!dev || !bridge)
> > @@ -67,6 +120,38 @@ int drm_bridge_attach(struct drm_device *dev, struct 
> > drm_bridge *bridge)
> >  EXPORT_SYMBOL(drm_bridge_attach);
> >  
> >  /**
> > + * DOC: bridge callbacks
> > + *
> > + * The drm_bridge_funcs ops are populated by the bridge driver. The drm
> > + * internals(atomic and crtc helpers) use the helpers defined in 
> > drm_bridge.c
> > + * These helpers call a specific drm_bridge_funcs op for all the bridges
> > + * during encoder configuration.
> > + *
> > + * When creating a bridge driver, one can implement drm_bridge_funcs op 
> > with
> > + * the help of these rough rules:
> > + *
> > + * pre_enable: this contains things needed to be done for the bridge before
> > + * its clock and timings are enabled by its source. For a bridge, its 
> > source
> > + * is generally the encoder or bridge just before it in the encoder chain.
> > + *
> > + * enable: this contains things needs to be done for the bridge once 

[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Gustavo Padovan
2015-05-21 Gustavo Padovan :

> 2015-05-21 Tobias Jakobi :
> 
> > Hi,
> > 
> > like I said before, this clashes with my commit 'drm/exynos: plane: honor
> > buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58),
> > which is currently sitting in airlied's drm-fixes.
> 
> Inki has to merge his -fixes tree into exynos-drm-next to solve this.
> It is the only way I can rebase on top of your commit and solve the
> conflict.
> Anyway, I just figured that exynos-drm-next was updated from yesterday
> to today so this v5 doesn't apply on today's tree. I'll send a v6 once
> Inki merges "drm/exynos: plane: honor buffer offset for dma_addr" into
> exynos-drm-next.
> 
> Inki, can you please do that? so we can proceed with atomic and
> hopefully have it ready for 4.2 merge window.

Actually the patch is on exynos-drm-next but with a different commit id.
I wonder why. Why did you applied it directly to your branch instead of
merging the -fixes tree? Now we have the same commit with the differents
hashes in the tree.

Gustavo


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

2015-05-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=87856

--- Comment #10 from Alex Deucher  ---
(In reply to kristof from comment #9)
> By checking my Xorg.0.log, I realized that "EXA" submodule is loaded instead
> "glamor" ... (noticed in my workaround firmware non-free installed + mesalib
> not patched)
> Since my gpu is a R300 (RV380-X600) family submodule should be "glamor",
> right or mistake from me due to misunderstanding something ?

All pre-SI cards use EXA by default.  I'm not even sure the r300 cards are
capable of using glamor anymore.

-- 
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/20150521/38872d93/attachment.html>


[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Gustavo Padovan
2015-05-21 Tobias Jakobi :

> Hi,
> 
> like I said before, this clashes with my commit 'drm/exynos: plane: honor
> buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58),
> which is currently sitting in airlied's drm-fixes.

Inki has to merge his -fixes tree into exynos-drm-next to solve this.
It is the only way I can rebase on top of your commit and solve the
conflict.
Anyway, I just figured that exynos-drm-next was updated from yesterday
to today so this v5 doesn't apply on today's tree. I'll send a v6 once
Inki merges "drm/exynos: plane: honor buffer offset for dma_addr" into
exynos-drm-next.

Inki, can you please do that? so we can proceed with atomic and
hopefully have it ready for 4.2 merge window.

Gustavo


[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

2015-05-21 Thread Rob Clark
On Thu, May 21, 2015 at 12:10 PM, Chris Wilson  
wrote:
> On Thu, May 21, 2015 at 06:07:30PM +0200, Daniel Vetter wrote:
>> On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote:
>> > For actual sharing of buffers with other drivers (ie. actual hardware)
>> > we'll need to pimp things out a bit better to deal w/ caching, multiple
>> > memory domains, etc.  See thread:
>> >
>> >   http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html
>> >
>> > But for the llvmpipe use-case this isn't a problem.  Nor do we really
>> > need prime/dri3 (dri2 is sufficient).  So until the other issues are
>> > sorted lets remove DRIVER_PRIME.
>> >
>> > v2: also drop the dead code
>> >
>> > Signed-off-by: Rob Clark 
>>
>> Yeah I'm ok with this too, but it pretty much means vgem is a thing for
>> llvmpipe only. And then abusing dumb buffers is imo ok too, since I don't
>> care too much what kind of horrors drivers pull of internally.
>
> Ugh. But llvmpipe + dumb buffer is much inferior to SHM.

it is using shmem for it's dumb buffers..  although I noticed it was
mapping writecombine which is probably not what is wanted..

BR,
-R

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre


[PATCH] drm/exynos: use drm_atomic_state directly

2015-05-21 Thread Gustavo Padovan
Just ignore this one. The patch file was by mistake in the same folder
as the atomic ones. It is part of a patchset that will come out later.

Gustavo

2015-05-21 Gustavo Padovan :

> From: Gustavo Padovan 
> 
> Instead of use duplicated information stored on struct exynos_drm_plane
> use the atomic state directly to have a more clear understanding and clean
> code.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c |  49 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|  51 -
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  47 ++--
>  drivers/gpu/drm/exynos/exynos_drm_plane.c  |  86 ++---
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 116 
> ++---
>  5 files changed, 131 insertions(+), 218 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index ed4461f..612ee29 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -281,16 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
> *crtc)
>   }
>  }
>  
> -static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
> +static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
> +  struct drm_framebuffer *fb)
>  {
> - struct exynos_drm_plane *plane = >planes[win];
>   unsigned long val;
>   int padding;
>  
>   val = readl(ctx->regs + WINCON(win));
>   val &= ~WINCONx_BPPMODE_MASK;
>  
> - switch (plane->pixel_format) {
> + switch (fb->pixel_format) {
>   case DRM_FORMAT_RGB565:
>   val |= WINCONx_BPPMODE_16BPP_565;
>   val |= WINCONx_BURSTLEN_16WORD;
> @@ -339,7 +339,7 @@ static void decon_win_set_pixfmt(struct decon_context 
> *ctx, unsigned int win)
>   break;
>   }
>  
> - DRM_DEBUG_KMS("bpp = %d\n", plane->bpp);
> + DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
>  
>   /*
>* In case of exynos, setting dma-burst to 16Word causes permanent
> @@ -349,8 +349,8 @@ static void decon_win_set_pixfmt(struct decon_context 
> *ctx, unsigned int win)
>* movement causes unstable DMA which results into iommu crash/tear.
>*/
>  
> - padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
> - if (plane->fb_width + padding < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> + padding = (fb->pitches[0] / (fb->bits_per_pixel >> 3)) - fb->width;
> + if (fb->width + padding < MIN_FB_WIDTH_FOR_16WORD_BURST) {
>   val &= ~WINCONx_BURSTLEN_MASK;
>   val |= WINCONx_BURSTLEN_8WORD;
>   }
> @@ -396,12 +396,15 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
>  struct exynos_drm_plane *plane)
>  {
>   struct decon_context *ctx = crtc->ctx;
> + struct drm_plane_state *state = plane->base.state;
>   struct drm_display_mode *mode = >base.mode;
>   int padding;
>   unsigned long val, alpha;
>   unsigned int last_x;
>   unsigned int last_y;
>   unsigned int win = plane->zpos;
> + unsigned int bpp = state->fb->bits_per_pixel >> 3;
> + unsigned int pitch = state->fb->pitches[0];
>  
>   /* If suspended, enable this on resume */
>   if (ctx->suspended) {
> @@ -426,38 +429,38 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
>   val = (unsigned long)plane->dma_addr[0];
>   writel(val, ctx->regs + VIDW_BUF_START(win));
>  
> - padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
> + padding = (pitch / bpp) - state->fb->width;
>  
>   /* buffer size */
> - writel(plane->fb_width + padding, ctx->regs + VIDW_WHOLE_X(win));
> - writel(plane->fb_height, ctx->regs + VIDW_WHOLE_Y(win));
> + writel(state->fb->width + padding, ctx->regs + VIDW_WHOLE_X(win));
> + writel(state->fb->height, ctx->regs + VIDW_WHOLE_Y(win));
>  
>   /* offset from the start of the buffer to read */
> - writel(plane->src_x, ctx->regs + VIDW_OFFSET_X(win));
> - writel(plane->src_y, ctx->regs + VIDW_OFFSET_Y(win));
> + writel(state->src_x, ctx->regs + VIDW_OFFSET_X(win));
> + writel(state->src_y, ctx->regs + VIDW_OFFSET_Y(win));
>  
>   DRM_DEBUG_KMS("start addr = 0x%lx\n",
>   (unsigned long)val);
> - DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
> - plane->crtc_width, plane->crtc_height);
> + DRM_DEBUG_KMS("crtc_w = %d, crtc_h = %d\n",
> + state->crtc_w, state->crtc_h);
>  
>   /*
>* OSD position.
>* In case the window layout goes of LCD layout, DECON fails.
>*/
> - if ((plane->crtc_x + plane->crtc_width) > mode->hdisplay)
> - plane->crtc_x = mode->hdisplay - plane->crtc_width;
> - if ((plane->crtc_y + plane->crtc_height) > mode->vdisplay)
> - 

[PATCH v5 12/12] drm/exynos: remove unnecessary calls to disable_plane()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

The planes are already disabled by the drm_atomic_helper_commit() code
so we don't need to disable the in these two places.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 ---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |  8 
 2 files changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 519c569..9bf25ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -47,8 +47,6 @@ static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_plane *plane;
-   int ret;

if (!exynos_crtc->enabled)
return;
@@ -64,15 +62,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_OFF);

exynos_crtc->enabled = false;
-
-   drm_for_each_legacy_plane(plane, >dev->mode_config.plane_list) {
-   if (plane->crtc != crtc)
-   continue;
-
-   ret = plane->funcs->disable_plane(plane);
-   if (ret)
-   DRM_ERROR("Failed to disable plane %d\n", ret);
-   }
 }

 static bool
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 0648ba4..7b89fd5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -81,17 +81,9 @@ static void exynos_drm_encoder_disable(struct drm_encoder 
*encoder)
 {
struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
struct exynos_drm_display *display = exynos_encoder->display;
-   struct drm_plane *plane;
-   struct drm_device *dev = encoder->dev;

if (display->ops->dpms)
display->ops->dpms(display, DRM_MODE_DPMS_OFF);
-
-   /* all planes connected to this encoder should be also disabled. */
-   drm_for_each_legacy_plane(plane, >mode_config.plane_list) {
-   if (plane->crtc && (plane->crtc == encoder->crtc))
-   plane->funcs->disable_plane(plane);
-   }
 }

 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
-- 
2.1.0



[PATCH v5 11/12] drm/exynos: atomic dpms support

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.

v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms()
- do not use WARN_ON on crtc enable/disable

v3: - Fix build failure after the hdmi change in v2
- Change dpms helper of ptn3460 bridge

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/bridge/ps8622.c |  2 +-
 drivers/gpu/drm/bridge/ptn3460.c|  2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 99 -
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  6 +-
 10 files changed, 71 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index b604326..d686235 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -499,7 +499,7 @@ static void ps8622_connector_destroy(struct drm_connector 
*connector)
 }

 static const struct drm_connector_funcs ps8622_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
.destroy = ps8622_connector_destroy,
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 8ed3617..260bc9f 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -260,7 +260,7 @@ static void ptn3460_connector_destroy(struct drm_connector 
*connector)
 }

 static struct drm_connector_funcs ptn3460_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 59f2ca5..d468637 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -955,7 +955,7 @@ static void exynos_dp_connector_destroy(struct 
drm_connector *connector)
 }

 static struct drm_connector_funcs exynos_dp_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0db7b91..519c569 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -22,51 +22,57 @@
 #include "exynos_drm_encoder.h"
 #include "exynos_drm_plane.h"

-static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
+static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(crtc->primary);

-   DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);
-
-   if (exynos_crtc->dpms == mode) {
-   DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
+   if (exynos_crtc->enabled)
return;
-   }
-
-   if (mode > DRM_MODE_DPMS_ON) {
-   /* wait for the completion of page flip. */
-   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
-   (exynos_crtc->event == NULL), HZ/20))
-   exynos_crtc->event = NULL;
-   drm_crtc_vblank_off(crtc);
-   }

if (exynos_crtc->ops->dpms)
-   exynos_crtc->ops->dpms(exynos_crtc, mode);
+   exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_ON);

-   exynos_crtc->dpms = mode;
+   exynos_crtc->enabled = true;

-   if (mode == DRM_MODE_DPMS_ON)
-   drm_crtc_vblank_on(crtc);
-}
+   drm_crtc_vblank_on(crtc);

-static void exynos_drm_crtc_prepare(struct drm_crtc *crtc)
-{
-   /* drm framework doesn't check NULL. */
+   if (exynos_crtc->ops->win_commit)
+   exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
+
+   if (exynos_crtc->ops->commit)
+   exynos_crtc->ops->commit(exynos_crtc);
 }

-static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
+static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- 

[PATCH v5 10/12] drm/exynos: don't disable unused functions at init

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Everything starts disabled so we don't really need to disable anything.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e71e331..e0b085b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -275,9 +275,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)

}

-   /* disable all the possible outputs/crtcs before entering KMS mode */
-   drm_helper_disable_unused_functions(dev);
-
ret = drm_fb_helper_initial_config(helper, PREFERRED_BPP);
if (ret < 0) {
DRM_ERROR("failed to set up hw configuration.\n");
-- 
2.1.0



[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Now that no one is using the functions exported by exynos_drm_plane due
to the atomic conversion we can make remove some of the them or make them
static.

v2: remove unused exynos_drm_crtc

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 90 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 
 2 files changed, 37 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index ab50bb7..b385fec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -62,35 +62,12 @@ static int exynos_plane_get_size(int start, unsigned 
length, unsigned last)
return size;
 }

-int exynos_check_plane(struct drm_plane *plane, struct drm_framebuffer *fb)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   int nr;
-   int i;
-
-   nr = exynos_drm_fb_get_buf_cnt(fb);
-   for (i = 0; i < nr; i++) {
-   struct exynos_drm_gem_buf *buffer = exynos_drm_fb_buffer(fb, i);
-
-   if (!buffer) {
-   DRM_DEBUG_KMS("buffer is null\n");
-   return -EFAULT;
-   }
-
-   exynos_plane->dma_addr[i] = buffer->dma_addr;
-
-   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
-   i, (unsigned long)exynos_plane->dma_addr[i]);
-   }
-
-   return 0;
-}
-
-void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+static void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc 
*crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
 {
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
unsigned int actual_w;
@@ -145,24 +122,6 @@ void exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
plane->crtc = crtc;
 }

-void
-exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
-{
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-
-   exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
- crtc_w, crtc_h, src_x >> 16, src_y >> 16,
- src_w >> 16, src_h >> 16);
-
-   if (exynos_crtc->ops->win_commit)
-   exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -175,22 +134,47 @@ static struct drm_plane_funcs exynos_plane_funcs = {
 static int exynos_plane_atomic_check(struct drm_plane *plane,
 struct drm_plane_state *state)
 {
-   return exynos_check_plane(plane, state->fb);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   int nr;
+   int i;
+
+   nr = exynos_drm_fb_get_buf_cnt(state->fb);
+   for (i = 0; i < nr; i++) {
+   struct exynos_drm_gem_buf *buffer =
+   exynos_drm_fb_buffer(state->fb, i);
+
+   if (!buffer) {
+   DRM_DEBUG_KMS("buffer is null\n");
+   return -EFAULT;
+   }
+
+   exynos_plane->dma_addr[i] = buffer->dma_addr;
+
+   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
+   i, (unsigned long)exynos_plane->dma_addr[i]);
+   }
+
+   return 0;
 }

 static void exynos_plane_atomic_update(struct drm_plane *plane,
   struct drm_plane_state *old_state)
 {
struct drm_plane_state *state = plane->state;
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(state->crtc);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);

if (!state->crtc)
return;

-   exynos_update_plane(plane, state->crtc, state->fb,
-   state->crtc_x, state->crtc_y,
-

[PATCH v5 08/12] drm/exynos: atomic phase 3: convert page flips

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

PageFlips now use the atomic helper to work through the atomic modesetting
API. Async page flips are not supported yet.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 +---
 drivers/gpu/drm/exynos/exynos_drm_fb.c   |  9 -
 2 files changed, 9 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b0888d4..0db7b91 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -123,67 +123,6 @@ static struct drm_crtc_helper_funcs 
exynos_crtc_helper_funcs = {
.disable= exynos_drm_crtc_disable,
 };

-static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_pending_vblank_event *event,
-uint32_t page_flip_flags)
-{
-   struct drm_device *dev = crtc->dev;
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   unsigned int crtc_w, crtc_h;
-   int ret;
-
-   /* when the page flip is requested, crtc's dpms should be on */
-   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
-   DRM_ERROR("failed page flip request.\n");
-   return -EINVAL;
-   }
-
-   if (!event)
-   return -EINVAL;
-
-   spin_lock_irq(>event_lock);
-   if (exynos_crtc->event) {
-   ret = -EBUSY;
-   goto out;
-   }
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret)
-   goto out;
-
-   ret = drm_vblank_get(dev, exynos_crtc->pipe);
-   if (ret) {
-   DRM_DEBUG("failed to acquire vblank counter\n");
-   goto out;
-   }
-
-   exynos_crtc->event = event;
-   spin_unlock_irq(>event_lock);
-
-   /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
-   event->pipe = exynos_crtc->pipe;
-
-   crtc->primary->fb = fb;
-   crtc_w = fb->width - crtc->x;
-   crtc_h = fb->height - crtc->y;
-   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-   crtc_w, crtc_h, crtc->x, crtc->y,
-   crtc_w, crtc_h);
-
-   if (crtc->primary->state)
-   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
-
-   return 0;
-
-out:
-   spin_unlock_irq(>event_lock);
-   return ret;
-}
-
 static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
@@ -197,7 +136,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)

 static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
-   .page_flip  = exynos_drm_crtc_page_flip,
+   .page_flip  = drm_atomic_helper_page_flip,
.destroy= exynos_drm_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index dcda496..d5141af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -303,11 +303,18 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
exynos_drm_fbdev_init(dev);
 }

+static int exynos_atomic_commit(struct drm_device *dev,
+   struct drm_atomic_state *state,
+   bool async)
+{
+   return drm_atomic_helper_commit(dev, state, false);
+}
+
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
+   .atomic_commit = exynos_atomic_commit,
 };

 void exynos_drm_mode_config_init(struct drm_device *dev)
-- 
2.1.0



[PATCH v5 07/12] drm/exynos: atomic phase 3: use atomic .set_config helper

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Now that phase 1 and 2 are complete switch .set_config helper to
use the atomic one.

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b080e83..b0888d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -196,7 +196,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
 }

 static struct drm_crtc_funcs exynos_crtc_funcs = {
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.page_flip  = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
-- 
2.1.0



[PATCH v5 06/12] drm/exynos: atomic phase 3: atomic updates of planes

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Now that phase 1 and 2 are complete we can switch the update/disable_plane
callbacks to their atomic version.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 8a38eb7..dcda496 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "exynos_drm_drv.h"
@@ -305,6 +306,8 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };

 void exynos_drm_mode_config_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 7811a29..ab50bb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -164,8 +164,8 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 }

 static struct drm_plane_funcs exynos_plane_funcs = {
-   .update_plane   = drm_plane_helper_update,
-   .disable_plane  = drm_plane_helper_disable,
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
-- 
2.1.0



[PATCH v5 05/12] drm/exynos: atomic phase 2: keep track of framebuffer pointer

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 44e73d0..b080e83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -174,6 +174,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc_w, crtc_h, crtc->x, crtc->y,
crtc_w, crtc_h);

+   if (crtc->primary->state)
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
+
return 0;

 out:
-- 
2.1.0



[PATCH v5 04/12] drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/bridge/ps8622.c   | 4 
 drivers/gpu/drm/bridge/ptn3460.c  | 4 
 drivers/gpu/drm/exynos/exynos_dp_core.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 6 ++
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 2 ++
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 4 
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 4 
 10 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index e895aa7..b604326 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -31,6 +31,7 @@
 #include "drmP.h"
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"

 /* Brightness scale on the Parade chip */
 #define PS8622_MAX_BRIGHTNESS 0xff
@@ -502,6 +503,9 @@ static const struct drm_connector_funcs 
ps8622_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
.destroy = ps8622_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int ps8622_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9d2f053..8ed3617 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -27,6 +27,7 @@

 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"
 #include "drm_edid.h"
 #include "drmP.h"

@@ -263,6 +264,9 @@ static struct drm_connector_funcs ptn3460_connector_funcs = 
{
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int ptn3460_bridge_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 1dbfba5..59f2ca5 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -958,6 +959,9 @@ static struct drm_connector_funcs exynos_dp_connector_funcs 
= {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int exynos_dp_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 35f101f..44e73d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -14,6 +14,8 @@

 #include 
 #include 
+#include 
+#include 

 #include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
@@ -194,8 +196,12 @@ static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.page_flip  = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };

+
 struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
   struct drm_plane *plane,
   int pipe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 37678cf..ced5c23 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -63,6 +64,9 @@ static struct drm_connector_funcs exynos_dpi_connector_funcs 
= {
.detect = exynos_dpi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = exynos_dpi_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   

[PATCH v5 03/12] drm/exynos: atomic phase 1: add .mode_set_nofb() callback

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +---
 1 file changed, 9 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 1c0d936..35f101f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -81,59 +81,16 @@ exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }

-static int
-exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode, int x, int y,
- struct drm_framebuffer *old_fb)
-{
-   struct drm_framebuffer *fb = crtc->primary->fb;
-   unsigned int crtc_w;
-   unsigned int crtc_h;
-   int ret;
-
-   /*
-* copy the mode data adjusted by mode_fixup() into crtc->mode
-* so that hardware can be seet to proper mode.
-*/
-   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret < 0)
-   return ret;
-
-   crtc_w = fb->width - x;
-   crtc_h = fb->height - y;
-   exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, x, y, crtc_w, crtc_h);
-
-   return 0;
-}
-
-static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
+static void
+exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_framebuffer *fb = crtc->primary->fb;
-   unsigned int crtc_w;
-   unsigned int crtc_h;
-   int ret;

-   /* when framebuffer changing is requested, crtc's dpms should be on */
-   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
-   DRM_ERROR("failed framebuffer changing request.\n");
-   return -EPERM;
-   }
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret)
-   return ret;
-
-   crtc_w = fb->width - x;
-   crtc_h = fb->height - y;
-   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+   if (WARN_ON(!crtc->state))
+   return;

-   return 0;
+   if (exynos_crtc->ops->commit)
+   exynos_crtc->ops->commit(exynos_crtc);
 }

 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -158,8 +115,9 @@ static struct drm_crtc_helper_funcs 
exynos_crtc_helper_funcs = {
.prepare= exynos_drm_crtc_prepare,
.commit = exynos_drm_crtc_commit,
.mode_fixup = exynos_drm_crtc_mode_fixup,
-   .mode_set   = exynos_drm_crtc_mode_set,
-   .mode_set_base  = exynos_drm_crtc_mode_set_base,
+   .mode_set   = drm_helper_crtc_mode_set,
+   .mode_set_nofb  = exynos_drm_crtc_mode_set_nofb,
+   .mode_set_base  = drm_helper_crtc_mode_set_base,
.disable= exynos_drm_crtc_disable,
 };

-- 
2.1.0



[PATCH v5 02/12] drm/exynos: atomic phase 1: use drm_plane_helper_disable()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()

exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 29 -
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 929cb03..8a38eb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -136,7 +136,7 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct 
drm_framebuffer *fb)

exynos_fb = to_exynos_fb(fb);

-   return exynos_fb->buf_cnt;
+   return exynos_fb ? exynos_fb->buf_cnt : 0;
 }

 struct drm_framebuffer *
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 5a938b1..b16be27 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -162,21 +162,9 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
 }

-static int exynos_disable_plane(struct drm_plane *plane)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc);
-
-   if (exynos_crtc && exynos_crtc->ops->win_disable)
-   exynos_crtc->ops->win_disable(exynos_crtc,
- exynos_plane->zpos);
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_plane_helper_update,
-   .disable_plane  = exynos_disable_plane,
+   .disable_plane  = drm_plane_helper_disable,
.destroy= drm_plane_cleanup,
 };

@@ -201,9 +189,24 @@ static void exynos_plane_atomic_update(struct drm_plane 
*plane,
state->src_w >> 16, state->src_h >> 16);
 }

+static void exynos_plane_atomic_disable(struct drm_plane *plane,
+   struct drm_plane_state *old_state)
+{
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(old_state->crtc);
+
+   if (!old_state->crtc)
+   return;
+
+   if (exynos_crtc->ops->win_disable)
+   exynos_crtc->ops->win_disable(exynos_crtc,
+ exynos_plane->zpos);
+}
+
 static const struct drm_plane_helper_funcs plane_helper_funcs = {
.atomic_check = exynos_plane_atomic_check,
.atomic_update = exynos_plane_atomic_update,
+   .atomic_disable = exynos_plane_atomic_disable,
 };

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



[PATCH] drm/exynos: use drm_atomic_state directly

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Instead of use duplicated information stored on struct exynos_drm_plane
use the atomic state directly to have a more clear understanding and clean
code.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |  49 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  51 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  47 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  86 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c  | 116 ++---
 5 files changed, 131 insertions(+), 218 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ed4461f..612ee29 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -281,16 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
}
 }

-static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
+static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
+struct drm_framebuffer *fb)
 {
-   struct exynos_drm_plane *plane = >planes[win];
unsigned long val;
int padding;

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

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

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

/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -349,8 +349,8 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win)
 * movement causes unstable DMA which results into iommu crash/tear.
 */

-   padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
-   if (plane->fb_width + padding < MIN_FB_WIDTH_FOR_16WORD_BURST) {
+   padding = (fb->pitches[0] / (fb->bits_per_pixel >> 3)) - fb->width;
+   if (fb->width + padding < MIN_FB_WIDTH_FOR_16WORD_BURST) {
val &= ~WINCONx_BURSTLEN_MASK;
val |= WINCONx_BURSTLEN_8WORD;
}
@@ -396,12 +396,15 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
   struct exynos_drm_plane *plane)
 {
struct decon_context *ctx = crtc->ctx;
+   struct drm_plane_state *state = plane->base.state;
struct drm_display_mode *mode = >base.mode;
int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
unsigned int win = plane->zpos;
+   unsigned int bpp = state->fb->bits_per_pixel >> 3;
+   unsigned int pitch = state->fb->pitches[0];

/* If suspended, enable this on resume */
if (ctx->suspended) {
@@ -426,38 +429,38 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
val = (unsigned long)plane->dma_addr[0];
writel(val, ctx->regs + VIDW_BUF_START(win));

-   padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
+   padding = (pitch / bpp) - state->fb->width;

/* buffer size */
-   writel(plane->fb_width + padding, ctx->regs + VIDW_WHOLE_X(win));
-   writel(plane->fb_height, ctx->regs + VIDW_WHOLE_Y(win));
+   writel(state->fb->width + padding, ctx->regs + VIDW_WHOLE_X(win));
+   writel(state->fb->height, ctx->regs + VIDW_WHOLE_Y(win));

/* offset from the start of the buffer to read */
-   writel(plane->src_x, ctx->regs + VIDW_OFFSET_X(win));
-   writel(plane->src_y, ctx->regs + VIDW_OFFSET_Y(win));
+   writel(state->src_x, ctx->regs + VIDW_OFFSET_X(win));
+   writel(state->src_y, ctx->regs + VIDW_OFFSET_Y(win));

DRM_DEBUG_KMS("start addr = 0x%lx\n",
(unsigned long)val);
-   DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
-   plane->crtc_width, plane->crtc_height);
+   DRM_DEBUG_KMS("crtc_w = %d, crtc_h = %d\n",
+   state->crtc_w, state->crtc_h);

/*
 * OSD position.
 * In case the window layout goes of LCD layout, DECON fails.
 */
-   if ((plane->crtc_x + plane->crtc_width) > mode->hdisplay)
-   plane->crtc_x = mode->hdisplay - plane->crtc_width;
-   if ((plane->crtc_y + plane->crtc_height) > mode->vdisplay)
-   plane->crtc_y = mode->vdisplay - plane->crtc_height;
+   if ((state->crtc_x + state->crtc_w) > mode->hdisplay)
+   state->crtc_x = mode->hdisplay - state->crtc_w;
+   if ((state->crtc_y + state->crtc_h) > mode->vdisplay)
+   

[PATCH v5 01/12] drm/exynos: atomic phase 1: use drm_plane_helper_update()

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.

Update all users of exynos_update_plane() accordingly to call
exynos_check_plane() before.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 29 +++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 40 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 +-
 3 files changed, 46 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index eb49195..1c0d936 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -116,6 +116,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
+   int ret;

/* when framebuffer changing is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -123,11 +124,16 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
return -EPERM;
}

+   ret = exynos_check_plane(crtc->primary, fb);
+   if (ret)
+   return ret;
+
crtc_w = fb->width - x;
crtc_h = fb->height - y;
+   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   crtc_w, crtc_h, x, y, crtc_w, crtc_h);

-   return exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-  crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+   return 0;
 }

 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -164,7 +170,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
int ret;

@@ -183,6 +188,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}

+   ret = exynos_check_plane(crtc->primary, fb);
+   if (ret)
+   goto out;
+
ret = drm_vblank_get(dev, exynos_crtc->pipe);
if (ret) {
DRM_DEBUG("failed to acquire vblank counter\n");
@@ -201,17 +210,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc->primary->fb = fb;
crtc_w = fb->width - crtc->x;
crtc_h = fb->height - crtc->y;
-   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
-   if (ret) {
-   crtc->primary->fb = old_fb;
-   spin_lock_irq(>event_lock);
-   exynos_crtc->event = NULL;
-   drm_vblank_put(dev, exynos_crtc->pipe);
-   spin_unlock_irq(>event_lock);
-   return ret;
-   }
+   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   crtc_w, crtc_h, crtc->x, crtc->y,
+   crtc_w, crtc_h);

return 0;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 13ea334..5a938b1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -144,21 +144,15 @@ void exynos_plane_mode_set(struct drm_plane *plane, 
struct drm_crtc *crtc,
plane->crtc = crtc;
 }

-int
+void
 exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
 struct drm_framebuffer *fb, int crtc_x, int crtc_y,
 unsigned int crtc_w, unsigned int crtc_h,
 uint32_t src_x, uint32_t src_y,
 uint32_t src_w, uint32_t src_h)
 {
-
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   int ret;
-
-   ret = exynos_check_plane(plane, fb);
-   if (ret < 0)
-   return ret;

exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
  crtc_w, crtc_h, src_x >> 16, src_y >> 16,
@@ -166,8 +160,6 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,

if (exynos_crtc->ops->win_commit)
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
-
-   return 0;
 }

 static int exynos_disable_plane(struct drm_plane *plane)
@@ -183,11 +175,37 @@ static int exynos_disable_plane(struct drm_plane *plane)
 }

 static struct drm_plane_funcs exynos_plane_funcs = {
-   .update_plane   = exynos_update_plane,
+   .update_plane   = drm_plane_helper_update,

[PATCH v5 00/12] drm/exynos: atomic modesetting support

2015-05-21 Thread Gustavo Padovan
From: Gustavo Padovan 

Hi,

Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.

v2: fixes comments by Joonyoung
- remove unused var in patch 09
- use ->disable instead of outdated ->dpms in hdmi code
- remove WARN_ON from crtc enable/disable

v3: fixes comment by Joonyoung
- move the removal of drm_helper_disable_unused_functions() to
separated patch

v4: add patches that remove unnecessary calls to disable_plane()

v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias)

Gustavo


Gustavo Padovan (12):
  drm/exynos: atomic phase 1: use drm_plane_helper_update()
  drm/exynos: atomic phase 1: use drm_plane_helper_disable()
  drm/exynos: atomic phase 1: add .mode_set_nofb() callback
  drm/exynos: atomic phase 2: wire up state reset(), duplicate() and
destroy()
  drm/exynos: atomic phase 2: keep track of framebuffer pointer
  drm/exynos: atomic phase 3: atomic updates of planes
  drm/exynos: atomic phase 3: use atomic .set_config helper
  drm/exynos: atomic phase 3: convert page flips
  drm/exynos: remove exported functions from exynos_drm_plane
  drm/exynos: don't disable unused functions at init
  drm/exynos: atomic dpms support
  drm/exynos: remove unnecessary calls to disable_plane()

 drivers/gpu/drm/bridge/ps8622.c |   6 +-
 drivers/gpu/drm/bridge/ptn3460.c|   6 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 215 
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |  35 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  12 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |   3 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c   | 119 ---
 drivers/gpu/drm/exynos/exynos_drm_plane.h   |  11 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   6 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  10 +-
 15 files changed, 183 insertions(+), 264 deletions(-)

-- 
2.1.0



[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

2015-05-21 Thread Rob Clark
For actual sharing of buffers with other drivers (ie. actual hardware)
we'll need to pimp things out a bit better to deal w/ caching, multiple
memory domains, etc.  See thread:

  http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html

But for the llvmpipe use-case this isn't a problem.  Nor do we really
need prime/dri3 (dri2 is sufficient).  So until the other issues are
sorted lets remove DRIVER_PRIME.

v2: also drop the dead code

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/vgem/Makefile   |  2 +-
 drivers/gpu/drm/vgem/vgem_dma_buf.c | 94 -
 drivers/gpu/drm/vgem/vgem_drv.c | 11 +
 drivers/gpu/drm/vgem/vgem_drv.h | 11 -
 4 files changed, 2 insertions(+), 116 deletions(-)
 delete mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c

diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
index 1055cb7..3f4c7b8 100644
--- a/drivers/gpu/drm/vgem/Makefile
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -1,4 +1,4 @@
 ccflags-y := -Iinclude/drm
-vgem-y := vgem_drv.o vgem_dma_buf.o
+vgem-y := vgem_drv.o

 obj-$(CONFIG_DRM_VGEM) += vgem.o
diff --git a/drivers/gpu/drm/vgem/vgem_dma_buf.c 
b/drivers/gpu/drm/vgem/vgem_dma_buf.c
deleted file mode 100644
index 0254438..000
--- a/drivers/gpu/drm/vgem/vgem_dma_buf.c
+++ /dev/null
@@ -1,94 +0,0 @@
-/*
- * Copyright © 2012 Intel Corporation
- * Copyright © 2014 The Chromium OS Authors
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- * Authors:
- *Ben Widawsky 
- *
- */
-
-#include 
-#include "vgem_drv.h"
-
-struct sg_table *vgem_gem_prime_get_sg_table(struct drm_gem_object *gobj)
-{
-   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
-   BUG_ON(obj->pages == NULL);
-
-   return drm_prime_pages_to_sg(obj->pages, obj->base.size / PAGE_SIZE);
-}
-
-int vgem_gem_prime_pin(struct drm_gem_object *gobj)
-{
-   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
-   return vgem_gem_get_pages(obj);
-}
-
-void vgem_gem_prime_unpin(struct drm_gem_object *gobj)
-{
-   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
-   vgem_gem_put_pages(obj);
-}
-
-void *vgem_gem_prime_vmap(struct drm_gem_object *gobj)
-{
-   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
-   BUG_ON(obj->pages == NULL);
-
-   return vmap(obj->pages, obj->base.size / PAGE_SIZE, 0, PAGE_KERNEL);
-}
-
-void vgem_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
-   vunmap(vaddr);
-}
-
-struct drm_gem_object *vgem_gem_prime_import(struct drm_device *dev,
-struct dma_buf *dma_buf)
-{
-   struct drm_vgem_gem_object *obj = NULL;
-   int ret;
-
-   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
-   if (obj == NULL) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   ret = drm_gem_object_init(dev, >base, dma_buf->size);
-   if (ret) {
-   ret = -ENOMEM;
-   goto fail_free;
-   }
-
-   get_dma_buf(dma_buf);
-
-   obj->base.dma_buf = dma_buf;
-   obj->use_dma_buf = true;
-
-   return >base;
-
-fail_free:
-   kfree(obj);
-fail:
-   return ERR_PTR(ret);
-}
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index cb3b435..7a207ca 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -302,22 +302,13 @@ static const struct file_operations vgem_driver_fops = {
 };

 static struct drm_driver vgem_driver = {
-   .driver_features= DRIVER_GEM | DRIVER_PRIME,
+   .driver_features= DRIVER_GEM,
.gem_free_object= vgem_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
.fops   = _driver_fops,
.dumb_create= vgem_gem_dumb_create,

[PATCH] dma-buf: Minor coding style fixes

2015-05-21 Thread Sumit Semwal
Hi Jagan,

On 21 May 2015 at 01:09, Jagan Teki  wrote:
> - WARNING: Missing a blank line after declarations
> - WARNING: line over 80 characters
> - WARNING: please, no space before tabs
>
> Signed-off-by: Jagan Teki 
> Cc: Sumit Semwal 

Thanks for the patch; I've queued it up in for-next.

Best regards,
~Sumit.




[Intel-gfx] [PATCH] drm/edid: Fix DDC probe for passive DP dongles

2015-05-21 Thread Jani Nikula
On Thu, 21 May 2015, Todd Previte  wrote:
> Passive DP->DVI/HDMI dongles show up to the system as HDMI devices, as they
> do not have a sink device in them to respond to any AUX traffic. When
> probing these dongles over the DDC, sometimes they will NAK the first attempt
> even though the transaction is valid and they support the DDC protocol. The
> retry loop inside of drm_do_probe_ddc_edid() would normally catch this case
> and try the transaction again, resulting in success.
>
> That, however, was thwarted by the fix for fdo.org bug #41059. The patch is:
>   commit 9292f37e1f5c79400254dca46f83313488093825
>   Author: Eugeni Dodonov 
>   Date:   Thu Jan 5 09:34:28 2012 -0200
>
>   drm: give up on edid retries when i2c bus is not responding

Some extra background:

That commit refers to the i2c bit banging code, while i915 now prefers
gmbus, and only falls back to big banging on certain failures. (See
gmbux_xfer() in i915/intel_i2c.c). This means that in most cases i915 is
no longer susceptible to the 5*3 timeout loops, but it also means we
don't have the i2c bit banging retry at all on -ENXIO, like Todd notes.

The questions are, is one retry after -ENXIO in drm_do_probe_ddc_edid
enough now? Should we revert the original commit instead since the
underlying algorithm has changed? Or should we return something other
than -ENXIO from our gmbus code to not hit this exit with no retries
path?

> This added code to exit immediately if the return code from the
> i2c_transfer function was -ENXIO in order to reduce the amount of time spent
> in waiting for unresponsive or disconnected devices. For the DP dongles,
> this means that the second retry never happens which results in a failed
> EDID probe and a black screen.
>
> To work around this problem without undoing the fix for bug #41059, the
> number of retries is checked along with the return code. This allows for a
> device to NAK once and still continue operations. A second NAK will result
> in breaking the loop as it would have before and stopping the DDC probe.

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

Maybe throw this at other dongle bugs you can find too?

We're going to need Tested-bys though.

BR,
Jani.


> Signed-off-by: Todd Previte 
> Cc: intel-gfx at lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_edid.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7087da3..e8047bd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1238,7 +1238,10 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned 
> int block, size_t len)
>*/
>   ret = i2c_transfer(adapter, [3 - xfers], xfers);
>  
> - if (ret == -ENXIO) {
> + /* Passive DP->DVI/HDMI dongles sometimes NAK the first probe
> +  * Try to probe again but if it NAKs, stop trying
> +  */
> + if (ret == -ENXIO && retries < 5) {
>   DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
>   adapter->name);
>   break;
> -- 
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm/vgem: drop DRIVER_PRIME

2015-05-21 Thread Rob Clark
On Thu, May 21, 2015 at 11:03 AM, Thomas Hellstrom
 wrote:
> Hi, Rob!
>
> On 05/21/2015 04:53 PM, Rob Clark wrote:
>> For actual sharing of buffers with other drivers (ie. actual hardware)
>> we'll need to pimp things out a bit better to deal w/ caching, multiple
>> memory domains, etc.  See thread:
>>
>>   
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=hZDsGjgypZF71rQfORpnkvT34UoNymdOdW0M3RyIIpQ=6QpYr_rF5y3fBjm48gY5zTJp6Fu87bv2HJYGGJ7VX7s=
>>
>> But for the llvmpipe use-case this isn't a problem.  Nor do we really
>> need prime/dri3 (dri2 is sufficient).  So until the other issues are
>> sorted lets remove DRIVER_PRIME.
>>
>> NOTE this ends up leaving some basically dead code for prime import/
>> export (mostly because I was rushing to send this before a meeting).
>
> What worries me a little is what Daniel brought up in his commit
> message, that let's say in the end people add a reasonable interface to
> dma_buf mmap, vgem also needs a corresponding interface... Makes me
> think that the best solution for now
> is perhaps to revert it.

Well, I think that is solvable..  ie. when vgem regains PRIME support,
disallow mmap'ing of imported buffers (and disallow export?), and do
all cpu-prep/fini stuff via dmabuf handle, for example.

Without prime, vgem is at least for now useful for allocating a dumb
buffer and sharing it between X and client (for llvmpipe rendering).

BR,
-R

> /Thomas
>
>
>>
>> Signed-off-by: Rob Clark 
>> ---
>> This is an alternative to removing vgem completely for 4.1, so that
>> llvmpipe work can get started in parallel with sorting out the other
>> issues for sw + hw access..
>>
>>  drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
>> b/drivers/gpu/drm/vgem/vgem_drv.c
>> index cb3b435..b0316f9 100644
>> --- a/drivers/gpu/drm/vgem/vgem_drv.c
>> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> @@ -302,7 +302,7 @@ static const struct file_operations vgem_driver_fops = {
>>  };
>>
>>  static struct drm_driver vgem_driver = {
>> - .driver_features= DRIVER_GEM | DRIVER_PRIME,
>> + .driver_features= DRIVER_GEM,
>>   .gem_free_object= vgem_gem_free_object,
>>   .gem_vm_ops = _gem_vm_ops,
>>   .ioctls = vgem_ioctls,
>


[PATCH] drm/vgem: implement virtual GEM

2015-05-21 Thread Daniel Vetter
On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote:
> On 11/25/2014 02:08 AM, Zachary Reizner wrote:
> > After looking into removing platform_device, I found that using
> > dma_buf_attach with a NULL device always returns an error, thereby
> > preventing me from using VGEM for import and mmap. The solution seems
> > to be to skip using dma_buf_attach, and instead use dma_buf_mmap when
> > user-space tries to mmap a gem object that was imported into VGEM. The
> > drawback to this approach is that most drivers stub their
> > dma_buf_ops->mmap implementation. Presumably mmap could be implemented
> > for the drivers that this would make sense for. Are there any
> > comments, questions, or concerns for this proposed solution?
> 
> I see now that this driver has entered -next, and I'm sorry this comment
> didn't arrive before. I simply missed this discussion :(
> 
> My biggest concern, as stated many many times before, is that dma-buf
> mmap is a horrible interface for incoherent drivers, and for drivers
> that use odd format (tiled) dma-bufs, basically since it doesn't supply
> a dirtied region. Therefore (correct me if I'm wrong) there has been an
> agreement that for purposes outside of ARM SOC, we should simply not
> implement dma-buf mmap for other uses than for internal driver use.
> 
> So assume a real driver implements dma-buf mmap, but it is crawling due
> to coherency- or untiling / tiling operations. How do you tell a generic
> user of the vgem driver *NOT* to mmap for performance reasons? Or is
> this driver only intended for ARM SOC systems?

Seconded. Somehow I thought we've pulled in vgem to support software
rendering like llvmpipe, and I remember that that's been the original
justification. TIL that that's indeed not the case and google is
splattering their cros tree with dma_buf->mmap implementations this is
obviously not the case and the intention really seems to be to use
dma_buf->mmap and vgem as the generic interface to expose buffer objects
of real drivers to software rendering.

Given that neither vgem nor dma_buf->mmap has any sane concept of handling
coherency I'm really unhappy about this and tempted to just submit the
revert for vgem before 4.1 ships. I'll chat with relevant people a bit
more. Worse I chatted with Stephane today and he brushed this off as
not-my-problem and if this hurts intel intel should fix this. That's not
how a proper usptream interface is getting designd, and coherency handling
is an even more serious problem on arm an virtual hw like vmwgfx. On intel
(well at least big core thanks to the huge coherent cache fabric) this is
mostly a non-issue, except that the patch in the cros tree obviously gets
things wrong.

Decently pissed tbh.

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


[PATCH] drm: atmel_hlcdc: Add support for get_timings

2015-05-21 Thread David Dueck
drm_panel supports querying timing ranges. If the supplied mode does
not work with the hlcdc we query the panel and try to find a suitable
mode.

Signed-off-by: David Dueck 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 118 +++
 1 file changed, 98 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 9c45130..ea36c24 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -20,6 +20,7 @@
  */

 #include 
+#include 

 #include 
 #include 
@@ -78,6 +79,8 @@ drm_encoder_to_atmel_hlcdc_rgb_output(struct drm_encoder 
*encoder)
 struct atmel_hlcdc_panel {
struct atmel_hlcdc_rgb_output base;
struct drm_panel *panel;
+   struct display_timing *timings;
+   unsigned int num_timings;
 };

 static inline struct atmel_hlcdc_panel *
@@ -104,14 +107,6 @@ static void atmel_hlcdc_panel_encoder_disable(struct 
drm_encoder *encoder)
drm_panel_disable(panel->panel);
 }

-static bool
-atmel_hlcdc_panel_encoder_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
-{
-   return true;
-}
-
 static void
 atmel_hlcdc_rgb_encoder_mode_set(struct drm_encoder *encoder,
 struct drm_display_mode *mode,
@@ -142,8 +137,86 @@ atmel_hlcdc_rgb_encoder_mode_set(struct drm_encoder 
*encoder,
   cfg);
 }

+/**
+ * atmel_hlcdc_choose_parameter - choose timing parameter
+ * @dc_min: minimum parameter value allowed by dc
+ * @dc_max: maximum parameter value allowed by dc
+ * @te: parameter range allowed by panel
+ * @result: chosen parameter
+ *
+ * DESCRIPTION:
+ * If there is overlap in the allowed ranges, we will pick a parameter
+ * minimizing the distance to te.typ. If not, we return te.min or te.max.
+ **/
+static u32 atmel_hlcdc_choose_parameter(u32 dc_min, u32 dc_max,
+   struct timing_entry te)
+{
+   if (te.typ <= dc_max && te.typ >= dc_min)
+   return te.typ;
+   else if (te.typ > dc_max)
+   return max(dc_max, te.min);
+   else
+   return min(dc_min, te.max);
+}
+
+static void atmel_hlcdc_calculate_mode(struct display_timing *timings,
+  struct drm_display_mode *adjusted_mode)
+{
+   u32 hsync_len, hfront_porch, hback_porch;
+   u32 vsync_len, vfront_porch, vback_porch;
+
+   hsync_len = atmel_hlcdc_choose_parameter(1, 0x40, timings->hsync_len);
+   vsync_len = atmel_hlcdc_choose_parameter(1, 0x40, timings->vsync_len);
+
+   hfront_porch = atmel_hlcdc_choose_parameter(1, 0x200,
+   timings->hfront_porch);
+   hback_porch = atmel_hlcdc_choose_parameter(1, 0x200,
+  timings->hback_porch);
+   vfront_porch = atmel_hlcdc_choose_parameter(1, 0x40,
+   timings->vfront_porch);
+   vback_porch = atmel_hlcdc_choose_parameter(0, 0x40,
+  timings->vback_porch);
+
+   adjusted_mode->hsync_start = adjusted_mode->hdisplay + hfront_porch;
+   adjusted_mode->hsync_end = adjusted_mode->hsync_start + hsync_len;
+   adjusted_mode->htotal = adjusted_mode->hsync_end + hback_porch;
+
+   adjusted_mode->vsync_start = adjusted_mode->vdisplay + vfront_porch;
+   adjusted_mode->vsync_end = adjusted_mode->vsync_start + vsync_len;
+   adjusted_mode->vtotal = adjusted_mode->vsync_end + vback_porch;
+}
+
+static int
+atmel_hlcdc_panel_encoder_atomic_check(struct drm_encoder *encoder,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state)
+{
+   struct atmel_hlcdc_rgb_output *rgb =
+   drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
+   struct atmel_hlcdc_panel *panel = atmel_hlcdc_rgb_output_to_panel(rgb);
+   struct drm_display_mode *mode = _state->mode;
+   struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
+   int i;
+
+   if (atmel_hlcdc_dc_mode_valid(rgb->dc, mode) == MODE_OK)
+   return 0;
+
+   for (i = 0; i < panel->num_timings; i++) {
+   if (panel->timings->hactive.typ != mode->hdisplay ||
+   panel->timings->vactive.typ != mode->vdisplay)
+   continue;
+
+   atmel_hlcdc_calculate_mode(panel->timings, adjusted_mode);
+   if (atmel_hlcdc_dc_mode_valid(rgb->dc, adjusted_mode) ==
+   MODE_OK)
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
 static struct drm_encoder_helper_funcs 

  1   2   >