[RFC 2/4] drm: exynos: add MDNIE post processor

[Sachin Kamat]

Hi Ajay,

On 19 March 2014 19:52, Ajay Kumar  wrote:
> Add post processor ops for MDNIE and their support functions.
> Expose an interface for the FIMD to register MDNIE PP.
>
> Signed-off-by: Ajay Kumar 
> Signed-off-by: Shirish S 
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/Makefile|   2 +-
>  drivers/gpu/drm/exynos/exynos_mdnie.c  | 707 
> +
>  drivers/gpu/drm/exynos/exynos_mdnie_regs.h | 154 +++
>  3 files changed, 862 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie.c
>  create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie_regs.h
>
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 02dde22..653eab5 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -10,7 +10,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
>
>  exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
> -exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
> +exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_DP)  += exynos_dp_core.o exynos_dp_reg.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
> diff --git a/drivers/gpu/drm/exynos/exynos_mdnie.c 
> b/drivers/gpu/drm/exynos/exynos_mdnie.c
> new file mode 100644
> index 000..a043853
> --- /dev/null
> +++ b/drivers/gpu/drm/exynos/exynos_mdnie.c
> @@ -0,0 +1,707 @@
> +/* drivers/gpu/drm/exynos/exynos_mdnie.c
> + *
> + * Samsung mDNIe driver
> + *
> + * Copyright (C) 2014 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> +*/
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include "exynos_drm_drv.h"
> +#include "exynos_fimd_pp.h"
> +#include "exynos_mdnie_regs.h"
> +
> +#define GAMMA_RAMP_LENGTH  17
> +#define COLOR_COMPONENTS   3
> +
> +#define MDNIE_ON   1
> +#define MDNIE_OFF  0
> +
> +#define PARAM_IN_RANGE(r, p, l, u) \
> +   do {\
> +   r = ((p >= l) && (p <= u)) ? 0 : 1; \
> +   if (r) \
> +   DRM_ERROR("Wrong param: %s:%llu\n", #p, (u64)p); \
> +   } while (0)
> +

[snip]

> +static int mdnie_set_color_saturation_params(
> +   struct mdnie_context *mdnie,
> +   const struct drm_mode_color_saturation *params)
> +{
> +   int ret;
> +
> +   PARAM_IN_RANGE(ret, params->hue_gain_red, HG_MIN, HG_MAX);
> +   PARAM_IN_RANGE(ret, params->hue_gain_green, HG_MIN, HG_MAX);
> +   PARAM_IN_RANGE(ret, params->hue_gain_blue, HG_MIN, HG_MAX);
> +   PARAM_IN_RANGE(ret, params->hue_gain_cyan, HG_MIN, HG_MAX);
> +   PARAM_IN_RANGE(ret, params->hue_gain_magenta, HG_MIN, HG_MAX);
> +   PARAM_IN_RANGE(ret, params->hue_gain_yellow, HG_MIN, HG_MAX);
> +   PARAM_IN_RANGE(ret, params->hue_gain_overall, HG_MIN, HG_MAX);
> +
> +   if (ret)
> +   return -EINVAL;

This would be applicable only for the last macro call as ret would get
overwritten after
each call.


> +   memcpy(&mdnie->params.cs_params, params, sizeof(*params));
> +
> +   return 0;
> +}
> +
> +static int mdnie_set_color_reproduction_params(
> +   struct mdnie_context *mdnie,
> +   const struct drm_mode_color_reproduction *params)
> +{
> +   int ret;
> +
> +   PARAM_IN_RANGE(ret, params->red_rgb[0], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->red_rgb[1], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->red_rgb[2], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->green_rgb[0], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->green_rgb[1], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->green_rgb[2], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->blue_rgb[0], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->blue_rgb[1], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->blue_rgb[2], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->cyan_rgb[0], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->cyan_rgb[1], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->cyan_rgb[2], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->magenta_rgb[0], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->magenta_rgb[1], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->magenta_rgb[2], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->yellow_rgb[0], CC_MIN, CC_MAX);
> +   PARAM_IN_RANGE(ret, params->yellow_r

[RFCv3 04/14] drm/exynos: Restrict plane loops to only operate on overlay planes

[Daniel Kurtz]

On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter  wrote:
> On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
>> Before we add additional types of planes to the DRM plane list, ensure
>> that existing loops over all planes continue to operate only on
>> "overlay" planes and ignore primary & cursor planes.
>>
>> Cc: Inki Dae 
>> Signed-off-by: Matt Roper 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> index 06f1b2a..2fa2685 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> @@ -127,6 +127,9 @@ static void disable_plane_to_crtc(struct drm_device *dev,
>>* (encoder->crtc)
>>*/
>>   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
>> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
>
> I think a drm_for_each_legacy_plane iteration helper would be neat for
> this one and the following i915 patch.
> -Daniel
>
>> + continue;
>> +
>>   if (plane->crtc == old_crtc) {
>>   /*
>>* do not change below call order.
>> @@ -247,6 +250,9 @@ static void exynos_drm_encoder_disable(struct 
>> drm_encoder *encoder)
>>
>>   /* all planes connected to this encoder should be also disabled. */
>>   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
>> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
>> + continue;
>> +
>>   if (plane->crtc == encoder->crtc)
>>   plane->funcs->disable_plane(plane);
>>   }

The original loop disables all planes attached to a crtc when
disabling an encoder attached to the same crtc.  It was added by:

commit bcf4cef94294992f7cd11d5a90fa58b0eae6c795
Author: Inki Dae 
Date:   Fri Aug 24 10:54:12 2012 -0700

drm/exynos: Disable plane when released

this patch ensures that each plane connected to encoder is disabled
when released, by adding disable callback function of encoder helper

we had faced with one issue that invalid memory is accessed by dma
once drm is released and then the dma is turned on again. actually,
in our case, page fault was incurred with iommu. the reason is that
a gem buffer accessed by the dma is also released once drm is released.

so this patch would fix this issue ensuring the dma is disabled
when released.


An encoder receives and encodes the mixed output of all of the
planes/overlays.  It would seem that whether the individual planes
themselves are enabled or not should be completely independent of the
status any encoder.  However, I find the code in exynos_drm_encoder.c
very difficult to follow, so perhaps there is some extra linkage
between encoder/crtc/plane that is exynos specific.

In any case, judging from the commit message, this disable loop should
probably still iterate over all of the planes, not just the
"DRM_PLANE_TYPE_OVERLAY" ones.  So, I think this new patch is
incorrect.


>> --
>> 1.8.5.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 72064] relocation truncated to fit: R_ARM_THM_JUMP11 mesa 10 rc2

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

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

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R100|Drivers/Gallium/r600

-- 
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/20140319/542bd7e7/attachment.html>

[PATCH 0/6] File Sealing & memfd_create()

[Linus Torvalds]

On Wed, Mar 19, 2014 at 12:06 PM, David Herrmann  
wrote:
>
> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting 
> seal
> modifications if you don't own an exclusive reference to the given file.

I like the concept, but I really hate that "exclusive reference"
approach. I see why you did it, but I also worry that it means that
people can open random shm files that are *not* expected to be sealed,
and screw up applications that don't expect it.

Is there really any use-case where the sealer isn't also the same
thing that *created* the file in the first place? Because I would be a
ton happier with the notion that you can only seal things that you
yourself created. At that point, the exclusive reference isn't such a
big deal any more, but more importantly, you can't play random
denial-of-service games on files that aren't really yours.

The fact that you bring up the races involved with the exclusive
reference approach also just makes me go "Is that really the correct
security model"?

   Linus

[RFCv3 04/14] drm/exynos: Restrict plane loops to only operate on overlay planes

[Daniel Vetter]

On Wed, Mar 19, 2014 at 10:26:13PM +0800, Daniel Kurtz wrote:
> On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter  wrote:
> > On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
> >> Before we add additional types of planes to the DRM plane list, ensure
> >> that existing loops over all planes continue to operate only on
> >> "overlay" planes and ignore primary & cursor planes.
> >>
> >> Cc: Inki Dae 
> >> Signed-off-by: Matt Roper 
> >> ---
> >>  drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
> >> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >> index 06f1b2a..2fa2685 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> >> @@ -127,6 +127,9 @@ static void disable_plane_to_crtc(struct drm_device 
> >> *dev,
> >>* (encoder->crtc)
> >>*/
> >>   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> >> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
> >
> > I think a drm_for_each_legacy_plane iteration helper would be neat for
> > this one and the following i915 patch.
> > -Daniel
> >
> >> + continue;
> >> +
> >>   if (plane->crtc == old_crtc) {
> >>   /*
> >>* do not change below call order.
> >> @@ -247,6 +250,9 @@ static void exynos_drm_encoder_disable(struct 
> >> drm_encoder *encoder)
> >>
> >>   /* all planes connected to this encoder should be also disabled. */
> >>   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> >> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
> >> + continue;
> >> +
> >>   if (plane->crtc == encoder->crtc)
> >>   plane->funcs->disable_plane(plane);
> >>   }
> 
> The original loop disables all planes attached to a crtc when
> disabling an encoder attached to the same crtc.  It was added by:
> 
> commit bcf4cef94294992f7cd11d5a90fa58b0eae6c795
> Author: Inki Dae 
> Date:   Fri Aug 24 10:54:12 2012 -0700
> 
> drm/exynos: Disable plane when released
> 
> this patch ensures that each plane connected to encoder is disabled
> when released, by adding disable callback function of encoder helper
> 
> we had faced with one issue that invalid memory is accessed by dma
> once drm is released and then the dma is turned on again. actually,
> in our case, page fault was incurred with iommu. the reason is that
> a gem buffer accessed by the dma is also released once drm is released.
> 
> so this patch would fix this issue ensuring the dma is disabled
> when released.
> 
> 
> An encoder receives and encodes the mixed output of all of the
> planes/overlays.  It would seem that whether the individual planes
> themselves are enabled or not should be completely independent of the
> status any encoder.  However, I find the code in exynos_drm_encoder.c
> very difficult to follow, so perhaps there is some extra linkage
> between encoder/crtc/plane that is exynos specific.
> 
> In any case, judging from the commit message, this disable loop should
> probably still iterate over all of the planes, not just the
> "DRM_PLANE_TYPE_OVERLAY" ones.  So, I think this new patch is
> incorrect.

It keeps full backwars compatibility with existing semantics, which is the
right thing to do in such a case. It could be that exynos simply has a
bug, but imo that should be a separate patch outside of this series.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFCv3 03/14] drm: Add primary plane helpers

[Daniel Vetter]

On Wed, Mar 19, 2014 at 11:15:36AM -0700, Matt Roper wrote:
> On Wed, Mar 19, 2014 at 12:28:43PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> ...
> > > +
> > > + /*
> > > +  * set_config() adjusts crtc->primary->fb; however the DRM setplane
> > > +  * code that called us expects to handle the framebuffer update and
> > > +  * reference counting; save and restore the current fb before
> > > +  * calling it.
> > > +  */
> > > + tmpfb = plane->fb;
> > > + ret = crtc->funcs->set_config(&set);
> > 
> > I wonder whether we should have an oppportunistic path using the page_flip
> > interface here. Otoh we must have a fallback to ->set_config anyway since
> > the drivers currently only allow pageflips on identical buffers. E.g. i915
> > rejects tiling changes and stride changes and position changes. So I think
> > having a pageflip fastpath isn't worth the trouble.
> > 
> > Also I think you need to use set_config_internal here to get the
> > refcounting right.
> 
> Hmm.  I specifically didn't use set_config_internal here because I
> thought drm_mode_setplane() (and presumably the future atomic ioctl
> which may also call into this) will already handle the refcounting for
> us.  Am I overlooking something?

Hm, I need to take a closer look again, but set_config has some really
funny rules about who updates which pointer and who grabs references for
which fb. Mostly since this has all grown rather add-hoc.

But you're right and the update_plane code already has some refcounting
and frobbing of its own, so I'm not sure what we really need to do here.
I think it at least needs a really big comment explaining what's going on.

Note that iirc the crtc helper code can still disable connectors in _any_
setcrtc call, so you might accidentally end up in a full modeset, with all
the fun this entails.

Definitely need to think more about this here. I hope we don't need to
rework the semantics of all drivers, since that would be major pain.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 73619] XServer frequently freezes for a few seconds

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

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

Benjamin Bellec  changed:

   What|Removed |Added

 CC||b.bellec at gmail.com

--- Comment #5 from Benjamin Bellec  ---
Does the freeze happens also with the stock openSUSE mesa (9.2.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/20140319/5e74aff3/attachment-0001.html>

Intel G41 doesn't see any screens connected after suspend/resume

[Nikolay Martynov]

Hi

>
> Perhaps you failed to install the modules that go with the kernel?
  I've built today's git version. The system boots but short after I
log into X session system freezes.

  I can login via ssh and see dmesg:

[   58.699131] general protection fault:  [#1] SMP
[   58.699173] Modules linked in: nls_utf8 udf crc_itu_t rfcomm bnep
bluetooth 6lowpan_iphc binfmt_misc snd_usb_audio snd_usbmidi_lib
gpio_ich ppdev gspca_zc3xx gspca_main videodev snd_hda_codec_realtek
dm_multipath snd_hda_codec_generic snd_hda_intel scsi_dh snd_hda_codec
snd_hwdep snd_pcm snd_seq_midi coretemp snd_seq_midi_event kvm_intel
snd_rawmidi snd_seq kvm snd_seq_device snd_timer snd lpc_ich soundcore
serio_raw parport_pc lp mac_hid asus_atk0110 parport raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq raid0 multipath linear hid_generic usbhid hid raid1 i915
atl1e video i2c_algo_bit drm_kms_helper drm
[   58.699510] CPU: 0 PID: 1638 Comm: Xorg Tainted: GW
3.14.0-rc7-custom #2
[   58.699537] Hardware name: System manufacturer System Product
Name/P5G41-M LE, BIOS 050606/11/2010
[   58.699578] task: 8800d0f498d0 ti: 8800cfcb8000 task.ti:
8800cfcb8000
[   58.699603] RIP: 0010:[]  []
i915_gem_object_set_cache_level+0x8a/0x310 [i915]
[   58.699677] RSP: 0018:8800cfcb9d60  EFLAGS: 00010246
[   58.699701] RAX: 880036444000 RBX: dead00100098 RCX: 8800cfcfd158
[   58.699725] RDX: 8800cfcfcfd8 RSI: 8800d086d0d0 RDI: 88011b401800
[   58.699749] RBP: 8800cfcb9d90 R08: 00017340 R09: 88011fc17340
[   58.699772] R10: ea0003421b40 R11: a00a1e33 R12: 8800cfcfcf00
[   58.699796] R13: 0001 R14: 8800cf36c800 R15: 8800cfcfcfc0
[   58.699821] FS:  7f3af20e1980() GS:88011fc0()
knlGS:
[   58.699856] CS:  0010 DS:  ES:  CR0: 80050033
[   58.699876] CR2: 7f52d8659000 CR3: d0fa2000 CR4: 000407f0
[   58.699899] Stack:
[   58.699910]  0001cfcb9d88 8800cf36c800 8800cfcfcf00
fffe
[   58.699945]  0001 8800cf36c800 8800cfcb9dc0
a00a5144
[   58.699978]  8800d0ea3000 006f fff2
8800cfcb9e20
[   58.700010] Call Trace:
[   58.700010]  [] i915_gem_set_caching_ioctl+0x84/0xf0 [i915]
[   58.700010]  [] drm_ioctl+0x4d2/0x600 [drm]
[   58.700010]  [] ? native_sched_clock+0x35/0x90
[   58.700010]  [] ? native_sched_clock+0x35/0x90
[   58.700010]  [] ? sched_clock+0x9/0x10
[   58.700010]  [] do_vfs_ioctl+0x2e0/0x4c0
[   58.700010]  [] ? vtime_account_user+0x54/0x60
[   58.700010]  [] SyS_ioctl+0x81/0xa0
[   58.700010]  [] tracesys+0xe1/0xe6
[   58.700010] Code: 90 f6 40 40 0f 0f 85 46 01 00 00 48 8b 42 68 49
39 c7 48 8d 50 98 75 e9 44 8b 6d d4 0f 1f 44 00 00 49 8b 46 30 f6 40
1c 20 75 25  43 20 20 74 1f 4c 89 ee 48 89 df e8 95 9e ff ff 84 c0
75 10
[   58.700010] RIP  []
i915_gem_object_set_cache_level+0x8a/0x310 [i915]
[   58.700010]  RSP 
[   58.725088] ---[ end trace c84dd3681cbb815b ]---

  Is this something expected on current git
(ec45c7550806d1373db6915a4031a7ae2542d61f)?
  Thanks!

-- 
Martynov Nikolay.
Email: mar.kolya at gmail.com

[PATCH man-pages 6/6] memfd_create.2: add memfd_create() man-page

[David Herrmann]

The memfd_create() syscall creates anonymous files similar to O_TMPFILE
but does not require an active mount-point.

Signed-off-by: David Herrmann 
---
 man2/memfd_create.2 | 110 
 1 file changed, 110 insertions(+)
 create mode 100644 man2/memfd_create.2

diff --git a/man2/memfd_create.2 b/man2/memfd_create.2
new file mode 100644
index 000..3e362e0
--- /dev/null
+++ b/man2/memfd_create.2
@@ -0,0 +1,110 @@
+.\" Copyright (C) 2014 David Herrmann 
+.\" starting from a version by Michael Kerrisk 
+.\"
+.\" %%%LICENSE_START(GPLv2+_SW_3_PARA)
+.\" This program is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation; either version 2 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This program is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public
+.\" License along with this manual; if not, see
+.\" .
+.\" %%%LICENSE_END
+.\"
+.TH MEMFD_CREATE 2 2014-03-18 Linux "Linux Programmer's Manual"
+.SH NAME
+memfd_create \- create an anonymous file
+.SH SYNOPSIS
+.B #include 
+.sp
+.BI "int memfd_create(const char *" name ", u64 " size ", u64 " flags ");"
+.SH DESCRIPTION
+.BR memfd_create ()
+creates an anonymous file and returns a file-descriptor to it. The file behaves
+like regular files, thus can be modified, truncated, memory-mapped and more.
+However, unlike regular files it lives in main memory and has no non-volatile
+backing storage. Once all references to the file are dropped, it is
+automatically released. Like all shmem-based files, memfd files support
+.BR SHMEM
+sealing parameters. See
+.BR SHMEM_SET_SEALS " with " fcntl (2)
+for more information.
+
+The initial size of the file is set to
+.IR size ". " name
+is used as internal file-name and will occur as such in
+.IR /proc/self/fd/ .
+The name is always prefixed with
+.BR memfd:
+and serves only debugging purposes.
+
+The following values may be bitwise ORed in
+.IR flags
+to change the behaviour of
+.BR memfd_create ():
+.TP
+.BR MFD_CLOEXEC
+Set the close-on-exec
+.RB ( FD_CLOEXEC )
+flag on the new file descriptor.
+See the description of the
+.B O_CLOEXEC
+flag in
+.BR open (2)
+for reasons why this may be useful.
+.PP
+Unused bits must be cleared to 0.
+
+As its return value,
+.BR memfd_create ()
+returns a new file descriptor that can be used to refer to the file.
+A copy of the file descriptor created by
+.BR memfd_create ()
+is inherited by the child produced by
+.BR fork (2).
+The duplicate file descriptor is associated with the same file.
+File descriptors created by
+.BR memfd_create ()
+are preserved across
+.BR execve (2),
+unless the close-on-exec flag has been set.
+.SH RETURN VALUE
+On success,
+.BR memfd_create ()
+returns a new file descriptor.
+On error, \-1 is returned and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EINVAL
+An unsupported value was specified in one of the arguments.
+.TP
+.B EMFILE
+The per-process limit on open file descriptors has been reached.
+.TP
+.B ENFILE
+The system-wide limit on the total number of open files has been
+reached.
+.TP
+.B EFAULT
+The name given in
+.IR name
+points to invalid memory.
+.TP
+.B ENOMEM
+There was insufficient memory to create a new anonymous file.
+.SH VERSIONS
+to-be-defined
+.SH CONFORMING TO
+.BR memfd_create ()
+is Linux-specific.
+.SH SEE ALSO
+.BR shmget (2),
+.BR fcntl (2),
-- 
1.9.0

[PATCH man-pages 5/6] fcntl.2: document SHMEM_SET/GET_SEALS commands

[David Herrmann]

The SHMEM_GET_SEALS and SHMEM_SET_SEALS commands allow retrieving and
modifying the active set of seals on a file. They're only supported on
selected file-systems (currently shmfs) and are linux-only.

Signed-off-by: David Herrmann 
---
 man2/fcntl.2 | 90 
 1 file changed, 90 insertions(+)

diff --git a/man2/fcntl.2 b/man2/fcntl.2
index c010a49..53d55a5 100644
--- a/man2/fcntl.2
+++ b/man2/fcntl.2
@@ -57,6 +57,8 @@
 .\" Document F_SETOWN_EX and F_GETOWN_EX
 .\" 2010-06-17, Michael Kerrisk
 .\"Document F_SETPIPE_SZ and F_GETPIPE_SZ.
+.\" 2014-03-19, David Herrmann 
+.\"Document SHMEM_SET_SEALS and SHMEM_GET_SEALS
 .\"
 .TH FCNTL 2 2014-02-20 "Linux" "Linux Programmer's Manual"
 .SH NAME
@@ -1064,6 +1066,94 @@ of buffer space currently used to store data produces 
the error
 .BR F_GETPIPE_SZ " (\fIvoid\fP; since Linux 2.6.35)"
 Return (as the function result) the capacity of the pipe referred to by
 .IR fd .
+.SS File Sealing
+Sealing files limits the set of allowed operations on a given file. For each
+seal that is set on a file, a specific set of operations will fail with
+.B EPERM
+on this file from now on. The file is said to be sealed. A file does not have
+any seals set by default. Moreover, most filesystems do not support sealing
+(only shmfs implements it right now). The following seals are available:
+.RS
+.TP
+.BR SHMEM_SEAL_SHRINK
+If this seal is set, the file in question cannot be reduced in size. This
+affects
+.BR open (2)
+with the
+.B O_TRUNC
+flag and
+.BR ftruncate (2).
+They will fail with
+.B EPERM
+if you try to shrink the file in question. Increasing the file size is still
+possible.
+.TP
+.BR SHMEM_SEAL_GROW
+If this seal is set, the size of the file in question cannot be increased. This
+affects
+.BR write (2)
+if you write across size boundaries,
+.BR ftruncate (2)
+and
+.BR fallocate (2).
+These calls will fail with
+.B EPERM
+if you use them to increase the file size or write beyond size boundaries. If
+you keep the size or shrink it, those calls still work as expected.
+.TP
+.BR SHMEM_SEAL_WRITE
+If this seal is set, you cannot modify data contents of the file. Note that
+shrinking or growing the size of the file is still possible and allowed. Thus,
+this seal is normally used in combination with one of the other seals. This 
seal
+affects
+.BR write (2)
+and
+.BR fallocate (2)
+(only in combination with the
+.B FALLOC_FL_PUNCH_HOLE
+flag). Those calls will fail with
+.B EPERM
+if this seal is set. Furthermore, trying to create new memory-mappings via
+.BR mmap (2)
+in combination with
+.B MAP_SHARED
+will also fail with
+.BR EPERM .
+.RE
+.TP
+.BR SHMEM_SET_SEALS " (\fIint\fP; since Linux TBD)"
+Change the set of seals of the file referred to by
+.I fd
+to
+.IR arg .
+You are required to own an exclusive reference to the file in question in order
+to modify the seals. Otherwise, this call will fail with
+.BR EPERM .
+There is one exception: If no seals are set, this restriction does not apply 
and
+you can set seals even if you don't own an exclusive reference. However, in any
+case there may not exist any shared writable mapping or this call will always
+fail with
+.BR EPERM .
+These semantics guarantee that once you verified a specific set of seals is set
+on a given file, nobody besides you (in case you own an exclusive reference) 
can
+modify the seals, anymore.
+
+You own an exclusive reference to a file if, and only if, the file-descriptor
+passed to
+.BR fcntl (2)
+is the only reference to the underlying inode. There must not be any duplicates
+of this file-descriptor, no other open files to the same underlying inode, no
+hard-links or any active memory mappings.
+.TP
+.BR SHMEM_GET_SEALS " (\fIvoid\fP; since Linux TBD)"
+Return (as the function result) the current set of seals of the file referred 
to
+by
+.IR fd .
+If no seals are set, 0 is returned. If the file does not support sealing, -1 is
+returned and
+.I errno
+is set to
+.BR EINVAL .
 .SH RETURN VALUE
 For a successful call, the return value depends on the operation:
 .TP 0.9i
-- 
1.9.0

[PATCH 4/6] selftests: add memfd_create() + sealing tests

[David Herrmann]

Some basic tests to verify sealing on memfds works as expected and
guarantees the advertised semantics.

Signed-off-by: David Herrmann 
---
 tools/testing/selftests/Makefile   |   1 +
 tools/testing/selftests/memfd/.gitignore   |   2 +
 tools/testing/selftests/memfd/Makefile |  29 +
 tools/testing/selftests/memfd/memfd_test.c | 972 +
 4 files changed, 1004 insertions(+)
 create mode 100644 tools/testing/selftests/memfd/.gitignore
 create mode 100644 tools/testing/selftests/memfd/Makefile
 create mode 100644 tools/testing/selftests/memfd/memfd_test.c

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 32487ed..c57325a 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -2,6 +2,7 @@ TARGETS = breakpoints
 TARGETS += cpu-hotplug
 TARGETS += efivarfs
 TARGETS += kcmp
+TARGETS += memfd
 TARGETS += memory-hotplug
 TARGETS += mqueue
 TARGETS += net
diff --git a/tools/testing/selftests/memfd/.gitignore 
b/tools/testing/selftests/memfd/.gitignore
new file mode 100644
index 000..bcc8ee2
--- /dev/null
+++ b/tools/testing/selftests/memfd/.gitignore
@@ -0,0 +1,2 @@
+memfd_test
+memfd-test-file
diff --git a/tools/testing/selftests/memfd/Makefile 
b/tools/testing/selftests/memfd/Makefile
new file mode 100644
index 000..36653b9
--- /dev/null
+++ b/tools/testing/selftests/memfd/Makefile
@@ -0,0 +1,29 @@
+uname_M := $(shell uname -m 2>/dev/null || echo not)
+ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
+ifeq ($(ARCH),i386)
+   ARCH := X86
+endif
+ifeq ($(ARCH),x86_64)
+   ARCH := X86
+endif
+
+CFLAGS += -I../../../../arch/x86/include/generated/uapi/
+CFLAGS += -I../../../../arch/x86/include/uapi/
+CFLAGS += -I../../../../include/uapi/
+CFLAGS += -I../../../../include/
+
+all:
+ifeq ($(ARCH),X86)
+   gcc $(CFLAGS) memfd_test.c -o memfd_test
+else
+   echo "Not an x86 target, can't build memfd selftest"
+endif
+
+run_tests: all
+ifeq ($(ARCH),X86)
+   gcc $(CFLAGS) memfd_test.c -o memfd_test
+endif
+   @./memfd_test || echo "memfd_test: [FAIL]"
+
+clean:
+   $(RM) memfd_test
diff --git a/tools/testing/selftests/memfd/memfd_test.c 
b/tools/testing/selftests/memfd/memfd_test.c
new file mode 100644
index 000..41bac6f
--- /dev/null
+++ b/tools/testing/selftests/memfd/memfd_test.c
@@ -0,0 +1,972 @@
+#define _GNU_SOURCE
+#define __EXPORTED_HEADERS__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MFD_DEF_SIZE 8192
+#define STACK_SIZE 65535
+
+static int sys_memfd_create(const char *name,
+   __u64 size,
+   __u64 flags)
+{
+   return syscall(__NR_memfd_create, name, size, flags);
+}
+
+static int mfd_assert_new(const char *name, __u64 sz, __u64 flags)
+{
+   int r;
+
+   r = sys_memfd_create(name, sz, flags);
+   if (r < 0) {
+   printf("memfd_create(\"%s\", %llu, %llu) failed: %m\n",
+  name, (unsigned long long)sz,
+  (unsigned long long)flags);
+   abort();
+   }
+
+   return r;
+}
+
+static void mfd_fail_new(const char *name, __u64 size, __u64 flags)
+{
+   int r;
+
+   r = sys_memfd_create(name, size, flags);
+   if (r >= 0) {
+   printf("memfd_create(\"%s\", %llu, %llu) succeeded, but failure 
expected\n",
+  name, (unsigned long long)size,
+  (unsigned long long)flags);
+   close(r);
+   abort();
+   }
+}
+
+static __u64 mfd_assert_get_seals(int fd)
+{
+   long r;
+
+   r = fcntl(fd, SHMEM_GET_SEALS);
+   if (r < 0) {
+   printf("GET_SEALS(%d) failed: %m\n", fd);
+   abort();
+   }
+
+   return r;
+}
+
+static void mfd_assert_has_seals(int fd, __u64 seals)
+{
+   __u64 s;
+
+   s = mfd_assert_get_seals(fd);
+   if (s != seals) {
+   printf("%llu != %llu = GET_SEALS(%d)\n",
+  (unsigned long long)seals, (unsigned long long)s, fd);
+   abort();
+   }
+}
+
+static void mfd_assert_set_seals(int fd, __u64 seals)
+{
+   long r;
+   __u64 s;
+
+   s = mfd_assert_get_seals(fd);
+   r = fcntl(fd, SHMEM_SET_SEALS, seals);
+   if (r < 0) {
+   printf("SET_SEALS(%d, %llu -> %llu) failed: %m\n",
+  fd, (unsigned long long)s, (unsigned long long)seals);
+   abort();
+   }
+}
+
+static void mfd_fail_set_seals(int fd, __u64 seals)
+{
+   long r;
+   __u64 s;
+
+   s = mfd_assert_get_seals(fd);
+   r = fcntl(fd, SHMEM_SET_SEALS, seals);
+   if (r >= 0) {
+   printf("SET_SEALS(%d, %llu -> %llu) didn't fail as expected\n",
+  fd, (unsigned long long)s, (unsigned long long)seals);
+   abort();
+   }

[PATCH 3/6] shm: add memfd_create() syscall

[David Herrmann]

memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
that you can pass to mmap(). It explicitly allows sealing and
avoids any connection to user-visible mount-points. Thus, it's not
subject to quotas on mounted file-systems, but can be used like
malloc()'ed memory, but with a file-descriptor to it.

memfd_create() does not create a front-FD, but instead returns the raw
shmem file, so calls like ftruncate() can be used. Also calls like fstat()
will return proper information and mark the file as regular file. Sealing
is explicitly supported on memfds.

Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not
subject to quotas and alike.

Signed-off-by: David Herrmann 
---
 arch/x86/syscalls/syscall_32.tbl |  1 +
 arch/x86/syscalls/syscall_64.tbl |  1 +
 include/linux/syscalls.h |  1 +
 include/uapi/linux/memfd.h   |  9 ++
 kernel/sys_ni.c  |  1 +
 mm/shmem.c   | 67 
 6 files changed, 80 insertions(+)
 create mode 100644 include/uapi/linux/memfd.h

diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index 96bc506..c943b8a 100644
--- a/arch/x86/syscalls/syscall_32.tbl
+++ b/arch/x86/syscalls/syscall_32.tbl
@@ -359,3 +359,4 @@
 350i386finit_modulesys_finit_module
 351i386sched_setattr   sys_sched_setattr
 352i386sched_getattr   sys_sched_getattr
+353i386memfd_createsys_memfd_create
diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index a12bddc..e9d56a8 100644
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@ -322,6 +322,7 @@
 313common  finit_modulesys_finit_module
 314common  sched_setattr   sys_sched_setattr
 315common  sched_getattr   sys_sched_getattr
+316common  memfd_createsys_memfd_create

 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a747a77..124b838 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -791,6 +791,7 @@ asmlinkage long sys_timerfd_settime(int ufd, int flags,
 asmlinkage long sys_timerfd_gettime(int ufd, struct itimerspec __user *otmr);
 asmlinkage long sys_eventfd(unsigned int count);
 asmlinkage long sys_eventfd2(unsigned int count, int flags);
+asmlinkage long sys_memfd_create(const char *uname_ptr, u64 size, u64 flags);
 asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len);
 asmlinkage long sys_old_readdir(unsigned int, struct old_linux_dirent __user 
*, unsigned int);
 asmlinkage long sys_pselect6(int, fd_set __user *, fd_set __user *,
diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h
new file mode 100644
index 000..d74cc89
--- /dev/null
+++ b/include/uapi/linux/memfd.h
@@ -0,0 +1,9 @@
+#ifndef _UAPI_LINUX_MEMFD_H
+#define _UAPI_LINUX_MEMFD_H
+
+#include 
+
+/* flags for memfd_create(2) */
+#define MFD_CLOEXEC0x0001
+
+#endif /* _UAPI_LINUX_MEMFD_H */
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 7078052..53e05af 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -193,6 +193,7 @@ cond_syscall(compat_sys_timerfd_settime);
 cond_syscall(compat_sys_timerfd_gettime);
 cond_syscall(sys_eventfd);
 cond_syscall(sys_eventfd2);
+cond_syscall(sys_memfd_create);

 /* performance counters: */
 cond_syscall(sys_perf_event_open);
diff --git a/mm/shmem.c b/mm/shmem.c
index 44d7f3b..48feb42 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -66,7 +66,9 @@ static struct vfsmount *shm_mnt;
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 

 #include 
 #include 
@@ -3039,6 +3041,71 @@ out4:
return error;
 }

+/* maximum length of memfd names */
+#define MFD_MAX_NAMELEN 256
+
+SYSCALL_DEFINE3(memfd_create,
+   const char*, uname,
+   u64, size,
+   u64, flags)
+{
+   struct file *shm;
+   char *name;
+   int fd, r;
+   long len;
+
+   if (flags & ~(u64)MFD_CLOEXEC)
+   return -EINVAL;
+   if ((u64)(loff_t)size != size || (loff_t)size < 0)
+   return -EINVAL;
+
+   /* length includes terminating zero */
+   len = strnlen_user(uname, MFD_MAX_NAMELEN);
+   if (len <= 0)
+   return -EFAULT;
+   else if (len > MFD_MAX_NAMELEN)
+   return -EINVAL;
+
+   name = kmalloc(len + 6, GFP_KERNEL);
+   if (!name)
+   return -ENOMEM;
+
+   strcpy(name, "memfd:");
+   if (copy_from_user(&name[6], uname, len)) {
+   r = -EFAULT;
+   goto err_name;
+   }
+
+   /* terminating-zero may have changed after strnlen_user() returned */
+   if (name[len + 6 - 1]) {
+   r = -EFAULT;
+   goto err_name;
+   }
+
+   fd = get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC :

[PATCH 2/6] shm: add sealing API

[David Herrmann]

If two processes share a common memory region, they usually want some
guarantees to allow safe access. This often includes:
  - one side cannot overwrite data while the other reads it
  - one side cannot shrink the buffer while the other accesses it
  - one side cannot grow the buffer beyond previously set boundaries

If there is a trust-relationship between both parties, there is no need
for policy enforcement. However, if there's no trust relationship (eg.,
for general-purpose IPC) sharing memory-regions is highly fragile and
often not possible without local copies. Look at the following two
use-cases:
  1) A graphics client wants to share its rendering-buffer with a
 graphics-server. The memory-region is allocated by the client for
 read/write access and a second FD is passed to the server. While
 scanning out from the memory region, the server has no guarantee that
 the client doesn't shrink the buffer at any time, requiring rather
 cumbersome SIGBUS handling.
  2) A process wants to perform an RPC on another process. To avoid huge
 bandwidth consumption, zero-copy is preferred. After a message is
 assembled in-memory and a FD is passed to the remote side, both sides
 want to be sure that neither modifies this shared copy, anymore. The
 source may have put sensible data into the message without a separate
 copy and the target may want to parse the message inline, to avoid a
 local copy.

While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide
ways to achieve most of this, the first one is unproportionally ugly to
use in libraries and the latter two are broken/racy or even disabled due
to denial of service attacks.

This patch introduces the concept of SEALING. If you seal a file, a
specific set of operations is blocked until this seal is removed again.
Unlike locks, seals can only be modified if you own an exclusive reference
to the file. Hence, if, and only if you hold a reference to a file, you
can be sure that no-one else can modify the seals besides you (and you can
only modify them, if you are the exclusive holder). This makes sealing
useful in situations where no trust-relationship is given.

An initial set of SEALS is introduced by this patch:
  - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced
in size. This currently affects only ftruncate().
  - GROW: If SEAL_GROW is set, the file in question cannot be increased
  in size. This affects ftruncate(), fallocate() and write().
  - WRITE: If SEAL_WRITE is set, no write operations (besides resizing)
   are possible. This affects fallocate(PUNCH_HOLE), mmap() and
   write().

The described use-cases can easily use these seals to provide safe use
without any trust-relationship:
  1) The graphics server can verify that a passed file-descriptor has
 SEAL_SHRINK set. This allows safe scanout, while the client is
 allowed to increase buffer size for window-resizing on-the-fly.
 Concurrent writes are explicitly allowed.
  2) Both processes can verify that SEAL_SHRINK, SEAL_GROW and SEAL_WRITE
 are set. This guarantees that neither process can modify the data
 while the other side parses it. Furthermore, it guarantees that even
 with writable FDs passed to the peer, it cannot increase the size to
 hit memory-limits of the source process (in case the file-storage is
 accounted to the source).

There is one exception to setting seals: Imagine a library makes use of
sealing. While creating a new memory object with an FD, another thread may
fork(), retaining a copy of the FD and thus also a reference. Sealing
wouldn't be possible anymore, until this process closes the FDs or
exec()s. To avoid this race initial seals can be set on non-exclusive FDs.
This is safe as both sides can, and always have to, verify that the
required set of seals is set. Once they are set, neither side can extend,
reduce or modify the set of seals as long as they have no exclusive
reference.
Note that this exception also allows keeping read-only mmaps() around
during initial sealing (mmaps() also own a reference to the file).

The new API is an extension to fcntl(), adding two new commands:
  SHMEM_GET_SEALS: Return a bitset describing the seals on the file. This
   can be called on any FD if the underlying file supports
   sealing.
  SHMEM_SET_SEALS: Change the seals of a given file. This requires WRITE
   access to the file. If at least one seal is already
   set, this also requires an exclusive reference. Note
   that this call will fail with EPERM if there is any
   active mapping with MAP_SHARED set.

The fcntl() handler is currently specific to shmem. There is no intention
to support this on other file-systems, that's why the bits are prefixed
with SHMEM_*. Furthermore, sealing is supported on all shmem-files.
Setting seals requires write-

[PATCH 1/6] fs: fix i_writecount on shmem and friends

[David Herrmann]

VM_DENYWRITE currently relies on i_writecount. Unless there's an active
writable reference to an inode, VM_DENYWRITE is not allowed.
Unfortunately, alloc_file() does not increase i_writecount, therefore,
does not prevent a following VM_DENYWRITE even though the new file might
have been opened with FMODE_WRITE. However, callers of alloc_file() expect
the file object to be fully instantiated so they can call fput() on it. We
could now either fix all callers to do an get_write_access() if opened
with FMODE_WRITE, or simply fix alloc_file() to do that. I chose the
latter.

Note that this bug allows some rather subtle misbehavior. The following
sequence of calls should work just fine, but currently fails:
int p[2], orig, ro, rw;
char buf[128];

pipe(p);
sprintf(buf, "/proc/self/fd/%d", p[1]);
ro = open(buf, O_RDONLY);
close(p[1]);
sprintf(buf, "/proc/self/fd/%d", ro);
rw = open(buf, O_RDWR);

The final open() cannot succeed as close(p[1]) caused an integer underflow
on i_writecount, effectively causing VM_DENYWRITE on the inode. The open
will fail with -ETXTBUSY.

It's a rather odd sequence of calls and given that open() doesn't use
alloc_file() (and thus not affected by this bug), it's rather unlikely
that this is a serious issue. But stuff like anon_inode shares a *single*
inode across a huge set of interfaces. If any of these is broken like
pipe(), it will affect all of these (ranging from dma-buf to epoll).

Signed-off-by: David Herrmann 
---
Hi

This patch is only included for reference. It was submitted to fs-devel
separately and is being worked on. However, this bug must be fixed in order to
make use of memfd_create(), so I decided to include it here.

David

 fs/file_table.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/fs/file_table.c b/fs/file_table.c
index 5b24008..8059d68 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -168,6 +168,7 @@ struct file *alloc_file(struct path *path, fmode_t mode,
const struct file_operations *fop)
 {
struct file *file;
+   int error;

file = get_empty_filp();
if (IS_ERR(file))
@@ -179,15 +180,23 @@ struct file *alloc_file(struct path *path, fmode_t mode,
file->f_mode = mode;
file->f_op = fop;

-   /*
-* These mounts don't really matter in practice
-* for r/o bind mounts.  They aren't userspace-
-* visible.  We do this for consistency, and so
-* that we can do debugging checks at __fput()
-*/
-   if ((mode & FMODE_WRITE) && 
!special_file(path->dentry->d_inode->i_mode)) {
-   file_take_write(file);
-   WARN_ON(mnt_clone_write(path->mnt));
+   if (mode & FMODE_WRITE) {
+   error = get_write_access(path->dentry->d_inode);
+   if (error) {
+   put_filp(file);
+   return ERR_PTR(error);
+   }
+
+   /*
+* These mounts don't really matter in practice
+* for r/o bind mounts.  They aren't userspace-
+* visible.  We do this for consistency, and so
+* that we can do debugging checks at __fput()
+*/
+   if (!special_file(path->dentry->d_inode->i_mode)) {
+   file_take_write(file);
+   WARN_ON(mnt_clone_write(path->mnt));
+   }
}
if ((mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
i_readcount_inc(path->dentry->d_inode);
-- 
1.9.0

[PATCH 0/6] File Sealing & memfd_create()

[David Herrmann]

Hi

This series introduces the concept of "file sealing". Sealing a file restricts
the set of allowed operations on the file in question. Multiple seals are
defined and each seal will cause a different set of operations to return EPERM
if it is set. The following seals are introduced:

 * SEAL_SHRINK: If set, the inode size cannot be reduced
 * SEAL_GROW: If set, the inode size cannot be increased
 * SEAL_WRITE: If set, the file content cannot be modified

Unlike existing techniques that provide similar protection, sealing allows
file-sharing without any trust-relationship. This is enforced by rejecting seal
modifications if you don't own an exclusive reference to the given file. So if
you own a file-descriptor, you can be sure that no-one besides you can modify
the seals on the given file. This allows mapping shared files from untrusted
parties without the fear of the file getting truncated or modified by an
attacker.

Several use-cases exist that could make great use of sealing:

  1) Graphics Compositors
 If a graphics client creates a memory-backed render-buffer and passes a
 file-decsriptor to it to the graphics server for display, the server
 _has_ to setup SIGBUS handlers whenever mapping the given file. Otherwise,
 the client might run ftruncate() or O_TRUNC on the on file in parallel,
 thus crashing the server.
 With sealing, a compositor can reject any incoming file-descriptor that
 does _not_ have SEAL_SHRINK set. This way, any memory-mappings are
 guaranteed to stay accessible. Furthermore, we still allow clients to
 increase the buffer-size in case they want to resize the render-buffer for
 the next frame. We also allow parallel writes so the client can render new
 frames into the same buffer (client is responsible of never rendering into
 a front-buffer if you want to avoid artifacts).

 Real use-case: Wayland wl_shm buffers can be transparently converted

  2) Geneal-purpose IPC
 IPC mechanisms that do not require a mutual trust-relationship (like dbus)
 cannot do zero-copy so far. With sealing, zero-copy can be easily done by
 sharing a file-descriptor that has SEAL_SHRINK | SEAL_GROW | SEAL_WRITE
 set. This way, the source can store sensible data in the file, seal the
 file and then pass it to the destination. The destination verifies these
 seals are set and then can parse the message in-line.
 Note that these files are usually one-shot files. Without any
 trust-relationship, a destination can notify the source that it released a
 file again, but a source can never rely on it. So unless the destination
 releases the file, a source cannot clear the seals for modification again.
 However, this is inherent to situations without any trust-relationship.

 Real use-case: kdbus messages already use a similar interface and can be
transparently converted to use these seals

Other similar use-cases exist (eg., audio), but these two I am personally
working on. Interest in this interface has been raised from several other camps
and I've put respective maintainers into CC. If more information on these
use-cases is needed, I think they can give some insights.

The API introduced by this patchset is:

 * fcntl() extension:
   Two new fcntl() commands are added that allow retrieveing (SHMEM_GET_SEALS)
   and setting (SHMEM_SET_SEALS) seals on a file. Only shmfs implements them so
   far and there is no intention to implement them on other file-systems.
   All shmfs based files support sealing.

   Patch 2/6

 * memfd_create() syscall:
   The new memfd_create() syscall is a public frontend to the shmem_file_new()
   interface in the kernel. It avoids the need of a local shmfs mount-point (as
   requested by android people) and acts more like MAP_ANON than O_TMPFILE.

   Patch 3/6

The other 4 patches are cleanups, self-tests and docs.

The commit-messages explain the API extensions in detail. Man-page proposals
are also provided. Last but not least, the extensive self-tests document the
intended behavior, in case it is still not clear.

Technically, sealing and memfd_create() are independent, but the described
use-cases would greatly benefit from the combination of both. Hence, I merged
them into the same series. Please also note that this series is based on earlier
works (ashmem, memfd, shmgetfd, ..) and unifies these attempts.

Comments welcome!

Thanks
David

David Herrmann (4):
  fs: fix i_writecount on shmem and friends
  shm: add sealing API
  shm: add memfd_create() syscall
  selftests: add memfd_create() + sealing tests

David Herrmann (2): (man-pages)
  fcntl.2: document SHMEM_SET/GET_SEALS commands
  memfd_create.2: add memfd_create() man-page

 arch/x86/syscalls/syscall_32.tbl   |   1 +
 arch/x86/syscalls/syscall_64.tbl   |   1 +
 fs/fcntl.c |  12 +-
 fs/file_table.c|  27 +-
 include/linux/shmem_fs.h  

[PATCH 0/6] File Sealing & memfd_create()

[Greg Kroah-Hartman]

On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote:
> Hi
> 
> This series introduces the concept of "file sealing". Sealing a file restricts
> the set of allowed operations on the file in question. Multiple seals are
> defined and each seal will cause a different set of operations to return EPERM
> if it is set. The following seals are introduced:
> 
>  * SEAL_SHRINK: If set, the inode size cannot be reduced
>  * SEAL_GROW: If set, the inode size cannot be increased
>  * SEAL_WRITE: If set, the file content cannot be modified
> 
> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting 
> seal
> modifications if you don't own an exclusive reference to the given file. So if
> you own a file-descriptor, you can be sure that no-one besides you can modify
> the seals on the given file. This allows mapping shared files from untrusted
> parties without the fear of the file getting truncated or modified by an
> attacker.
> 
> Several use-cases exist that could make great use of sealing:
> 
>   1) Graphics Compositors
>  If a graphics client creates a memory-backed render-buffer and passes a
>  file-decsriptor to it to the graphics server for display, the server
>  _has_ to setup SIGBUS handlers whenever mapping the given file. 
> Otherwise,
>  the client might run ftruncate() or O_TRUNC on the on file in parallel,
>  thus crashing the server.
>  With sealing, a compositor can reject any incoming file-descriptor that
>  does _not_ have SEAL_SHRINK set. This way, any memory-mappings are
>  guaranteed to stay accessible. Furthermore, we still allow clients to
>  increase the buffer-size in case they want to resize the render-buffer 
> for
>  the next frame. We also allow parallel writes so the client can render 
> new
>  frames into the same buffer (client is responsible of never rendering 
> into
>  a front-buffer if you want to avoid artifacts).
> 
>  Real use-case: Wayland wl_shm buffers can be transparently converted

Very nice, the Enlightenment developers have been asking for something
like this for a while, it should help them out a lot as well.

And thanks for the man pages and test code, if only all new apis came
with that already...

greg k-h

[RFC 4/4] drm: exynos: add MDNIE and IELCD to FIMD pp list

[Ajay Kumar]

This patch adds code to add MDNIE and IELCD onto the
list of FIMD PP.

Signed-off-by: Ajay Kumar 
Signed-off-by: Shirish S 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
 drivers/gpu/drm/exynos/exynos_fimd_pp.h  |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a584d8e..d5a32fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -160,8 +160,25 @@ static int fimd_mgr_initialize(struct exynos_drm_manager 
*mgr,
 {
struct fimd_context *ctx = mgr->ctx;
struct exynos_drm_private *priv;
+   struct exynos_fimd_pp *mdnie_pp = NULL, *ielcd_pp = NULL;
+   int ret;
+
priv = drm_dev->dev_private;

+   ret = exynos_mdnie_init(ctx->dev, &mdnie_pp);
+   if (!ret && mdnie_pp) {
+   ret = exynos_ielcd_init(ctx->dev, &ielcd_pp);
+   if (!ret && ielcd_pp) {
+   fimd_add_pp_to_list(ctx, mdnie_pp);
+   fimd_add_pp_to_list(ctx, ielcd_pp);
+   ctx->enable_pp = true;
+   ctx->pp_running = false;
+   } else {
+   DRM_INFO("No ielcd node present, "
+   "MDNIE feature will be disabled\n");
+   }
+   }
+
mgr->drm_dev = ctx->drm_dev = drm_dev;
mgr->pipe = ctx->pipe = priv->pipe++;

diff --git a/drivers/gpu/drm/exynos/exynos_fimd_pp.h 
b/drivers/gpu/drm/exynos/exynos_fimd_pp.h
index 528d3cb..b980742 100644
--- a/drivers/gpu/drm/exynos/exynos_fimd_pp.h
+++ b/drivers/gpu/drm/exynos/exynos_fimd_pp.h
@@ -49,4 +49,6 @@ struct exynos_fimd_pp {
void *ctx;
 };

+extern int exynos_mdnie_init(struct device *dev, struct exynos_fimd_pp **pp);
+extern int exynos_ielcd_init(struct device *dev, struct exynos_fimd_pp **pp);
 #endif
-- 
1.8.1.2

[RFC 3/4] drm: exynos: add IELCD post processor

[Ajay Kumar]

Add post processor ops for IELCD and their support functions.
Expose an interface for the FIMD to register IELCD PP.

Signed-off-by: Ajay Kumar 
Signed-off-by: Shirish S 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/Makefile   |   3 +-
 drivers/gpu/drm/exynos/exynos_ielcd.c | 295 ++
 include/video/samsung_fimd.h  |  43 +
 3 files changed, 340 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_ielcd.c

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 653eab5..f3d7314 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -10,7 +10,8 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \

 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o \
+   exynos_ielcd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DP)  += exynos_dp_core.o exynos_dp_reg.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
diff --git a/drivers/gpu/drm/exynos/exynos_ielcd.c 
b/drivers/gpu/drm/exynos/exynos_ielcd.c
new file mode 100644
index 000..33d0d34
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_ielcd.c
@@ -0,0 +1,295 @@
+/* drivers/gpu/drm/exynos/exynos_ielcd.c
+ *
+ * Samsung IELCD driver
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+*/
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "exynos_drm_drv.h"
+#include "exynos_fimd_pp.h"
+
+#define exynos_ielcd_readl(addr)   readl(ielcd->exynos_ielcd_base + addr)
+#define exynos_ielcd_writel(addr, val) \
+   writel(val, ielcd->exynos_ielcd_base + addr)
+#define IELCD_TIMEOUT_CNT  1000
+
+struct ielcd_context {
+   void __iomem*exynos_ielcd_base;
+   unsignedvdisplay;
+   unsignedvsync_len;
+   unsignedvbpd;
+   unsignedvfpd;
+   unsignedhdisplay;
+   unsignedhsync_len;
+   unsignedhbpd;
+   unsignedhfpd;
+   unsignedvidcon0;
+   unsignedvidcon1;
+};
+
+static int ielcd_logic_start(struct ielcd_context *ielcd)
+{
+   exynos_ielcd_writel(IELCD_AUXCON, IELCD_MAGIC_KEY);
+
+   return 0;
+}
+
+static void ielcd_set_polarity(struct ielcd_context *ielcd)
+{
+   unsigned int cfg;
+
+   cfg = exynos_ielcd_readl(IELCD_VIDCON1);
+
+   cfg &= ~(VIDCON1_INV_VCLK | VIDCON1_INV_HSYNC
+   | VIDCON1_INV_VSYNC | VIDCON1_INV_VDEN);
+   cfg |= ielcd->vidcon1;
+   exynos_ielcd_writel(IELCD_VIDCON1, cfg);
+}
+
+static void ielcd_set_timing(struct ielcd_context *ielcd)
+{
+   unsigned int cfg;
+
+   /*LCD verical porch setting*/
+   cfg = VIDTCON0_VBPD(ielcd->vbpd - 1) |
+   VIDTCON0_VFPD(ielcd->vfpd - 1) |
+   VIDTCON0_VSPW(ielcd->vsync_len - 1);
+
+   exynos_ielcd_writel(IELCD_VIDTCON0, cfg);
+   /*LCD horizontal porch setting*/
+   cfg = VIDTCON1_HBPD(ielcd->hbpd - 1) |
+   VIDTCON1_HFPD(ielcd->hfpd - 1) |
+   VIDTCON1_HSPW(ielcd->hsync_len - 1);
+
+   exynos_ielcd_writel(IELCD_VIDTCON1, cfg);
+}
+
+static void ielcd_set_lcd_size(struct ielcd_context *ielcd)
+{
+   unsigned int cfg;
+
+   cfg = (IELCD_VIDTCON2_LINEVAL(ielcd->vdisplay - 1) |
+   IELCD_VIDTCON2_HOZVAL(ielcd->hdisplay - 1));
+   exynos_ielcd_writel(IELCD_VIDTCON2, cfg);
+
+   /* window0 position setting */
+   exynos_ielcd_writel(IELCD_VIDOSD0A, 0);
+   cfg = (IELCD_VIDOSDB_XPOS_END(ielcd->hdisplay - 1)) |
+   (IELCD_VIDOSDB_YPOS_END(ielcd->vdisplay - 1));
+   exynos_ielcd_writel(IELCD_VIDOSD0B, cfg);
+
+   /* window0 osd size setting */
+   exynos_ielcd_writel(IELCD_VIDOSD0C, ielcd->hdisplay *
+   ielcd->vdisplay);
+
+   /* window0 page size(bytes) */
+   exynos_ielcd_writel(IELCD_VIDW00ADD2, ielcd->hdisplay * 4);
+}
+
+static int exynos_ielcd_hw_trigger_check(struct ielcd_context *ielcd)
+{
+   unsigned int cfg;
+   unsigned int count = 0;
+
+   cfg = exynos_ielcd_readl(IELCD_TRIGCON);
+   cfg &= ~(SWTRGCMD_W0BUF | TRGMODE_W0BUF);
+   cfg |= (SWTRGCMD_W0BUF | TRGMODE_W0BUF);
+   exynos_ielcd_writel(IELCD_TRIGC

[RFC 2/4] drm: exynos: add MDNIE post processor

[Ajay Kumar]

Add post processor ops for MDNIE and their support functions.
Expose an interface for the FIMD to register MDNIE PP.

Signed-off-by: Ajay Kumar 
Signed-off-by: Shirish S 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/Makefile|   2 +-
 drivers/gpu/drm/exynos/exynos_mdnie.c  | 707 +
 drivers/gpu/drm/exynos/exynos_mdnie_regs.h | 154 +++
 3 files changed, 862 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie_regs.h

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 02dde22..653eab5 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -10,7 +10,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \

 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DP)  += exynos_dp_core.o exynos_dp_reg.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
diff --git a/drivers/gpu/drm/exynos/exynos_mdnie.c 
b/drivers/gpu/drm/exynos/exynos_mdnie.c
new file mode 100644
index 000..a043853
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_mdnie.c
@@ -0,0 +1,707 @@
+/* drivers/gpu/drm/exynos/exynos_mdnie.c
+ *
+ * Samsung mDNIe driver
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+*/
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "exynos_drm_drv.h"
+#include "exynos_fimd_pp.h"
+#include "exynos_mdnie_regs.h"
+
+#define GAMMA_RAMP_LENGTH  17
+#define COLOR_COMPONENTS   3
+
+#define MDNIE_ON   1
+#define MDNIE_OFF  0
+
+#define PARAM_IN_RANGE(r, p, l, u) \
+   do {\
+   r = ((p >= l) && (p <= u)) ? 0 : 1; \
+   if (r) \
+   DRM_ERROR("Wrong param: %s:%llu\n", #p, (u64)p); \
+   } while (0)
+
+struct exynos_mdnie_drm_gamma {
+   u8 gamma_r[GAMMA_RAMP_LENGTH];
+   u8 gamma_g[GAMMA_RAMP_LENGTH];
+   u8 gamma_b[GAMMA_RAMP_LENGTH];
+};
+
+struct mdnie_conf_params {
+   u32 modules_enabled;
+   struct exynos_mdnie_drm_gamma   gamma_params;
+   struct drm_exynos_mdnie_window  win;
+   struct drm_mode_color_reproduction  cr_params;
+   struct drm_mode_color_saturationcs_params;
+   struct drm_mode_edge_enhancementde_params;
+};
+
+struct mdnie_context {
+   struct mdnie_conf_paramsparams;
+   struct clk  *mdnie_mux_clk;
+   struct clk  *mdnie_bus_clk;
+   struct clk  *mdnie_src_clk;
+   struct clk  *sclk_mout_fimd;
+   void __iomem*exynos_mdnie_base;
+   void __iomem*sysreg_disp1blk;
+   struct drm_display_mode mode;
+};
+
+static void exynos_mdnie_unmask(struct mdnie_context *mdnie)
+{
+   writel(!MDNIE_RELEASE_RFF_MASK_REGISTERS,
+   mdnie->exynos_mdnie_base +
+   MDNIE_RELEASE_RFF * sizeof(u32));
+}
+
+static u32 mdnie_read(struct mdnie_context *mdnie, u32 reg)
+{
+   return readl(mdnie->exynos_mdnie_base + reg * sizeof(u32)) &
+   MDNIE_REG_WIDTH;
+}
+
+static void mdnie_write(struct mdnie_context *mdnie, u32 reg, u32 val)
+{
+   writel(val & MDNIE_REG_WIDTH, mdnie->exynos_mdnie_base +
+   (reg & MDNIE_REG_OFFSET_LIMIT) * sizeof(u32));
+
+   exynos_mdnie_unmask(mdnie);
+}
+
+static void exynos_mdnie_bank_sel(struct mdnie_context *mdnie, int bank)
+{
+   if (bank)
+   writel(MDNIE_TOP_R0_BANK1_SEL |
+   MDNIE_TOP_R0_SHADOW_SEL ,
+   mdnie->exynos_mdnie_base);
+   else
+   writel(MDNIE_TOP_R0_BANK0_SEL |
+   MDNIE_TOP_R0_SHADOW_SEL ,
+   mdnie->exynos_mdnie_base);
+
+   exynos_mdnie_unmask(mdnie);
+}
+
+static int exynos_mdnie_set_size(struct mdnie_context *mdnie)
+{
+   unsigned int cfg;
+
+   if ((mdnie->mode.crtc_hdisplay > MDNIE_TOP_RSIZE_MAX) ||
+   (mdnie->mode.crtc_vdisplay > MDNIE_TOP_RSIZE_MAX))
+   return -EINVAL;
+
+   exynos_mdnie_bank_sel(mdnie,

[RFC 1/4] drm: exynos: Add infrastructure to support FIMD post processors

[Ajay Kumar]

Exynos variants support post pocessors(PP) for FIMD (MDNIE and IELCD)
which work closely with fimd. These post processors have strict
dependency on FIMD for poweron/poweroff. This patch adds an
infrastructure in FIMD driver to accomodate such devices.

Added structure definition for FIMD PP and interfaces from FIMD
driver to control FIMD PP.

Signed-off-by: Ajay Kumar 
Signed-off-by: Shirish S 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 162 +++
 drivers/gpu/drm/exynos/exynos_fimd_pp.h  |  52 ++
 include/video/samsung_fimd.h |   6 +-
 3 files changed, 219 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_fimd_pp.h

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a5511be..a584d8e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -30,6 +30,7 @@
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_iommu.h"
+#include "exynos_fimd_pp.h"

 /*
  * FIMD stands for Fully Interactive Mobile Display and
@@ -113,11 +114,14 @@ struct fimd_context {
void __iomem*regs;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
+   struct list_headfimd_pp_list;
unsigned intdefault_win;
unsigned long   irq_flags;
u32 vidcon0;
u32 vidcon1;
boolsuspended;
+   boolenable_pp;
+   boolpp_running;
int pipe;
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
@@ -145,6 +149,12 @@ static inline struct fimd_driver_data 
*drm_fimd_get_driver_data(
return (struct fimd_driver_data *)of_id->data;
 }

+void fimd_add_pp_to_list(struct fimd_context *ctx,
+   struct exynos_fimd_pp *pp)
+{
+   list_add_tail(&pp->list, &ctx->fimd_pp_list);
+}
+
 static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
struct drm_device *drm_dev)
 {
@@ -214,17 +224,49 @@ static void fimd_mode_set(struct exynos_drm_manager *mgr,
const struct drm_display_mode *in_mode)
 {
struct fimd_context *ctx = mgr->ctx;
+   struct exynos_fimd_pp *pp_display;

drm_mode_copy(&ctx->mode, in_mode);
+
+   /* mode_set for the post processors*/
+   list_for_each_entry(pp_display, &ctx->fimd_pp_list, list)
+   if (pp_display->ops->mode_set)
+   pp_display->ops->mode_set(pp_display->ctx, in_mode);
+}
+
+static int fimd_wait_till_per_frame_off(struct fimd_context *ctx)
+{
+   unsigned int val = readl(ctx->regs + VIDCON0);
+   int count = 10;
+
+   val &= ~(VIDCON0_ENVID_F);
+   writel(val, ctx->regs + VIDCON0);
+
+   while (count) {
+   val = readl(ctx->regs + VIDCON0);
+   if ((val & VIDCON0_ENVID_F) == 0)
+   break;
+   mdelay(17);
+   count--;
+   }
+
+   if (count == 0) {
+   DRM_ERROR("FIMD per frame switch off TIMEDOUT\n");
+   return -ETIMEDOUT;
+   }
+
+   return 0;
 }

 static void fimd_commit(struct exynos_drm_manager *mgr)
 {
struct fimd_context *ctx = mgr->ctx;
struct drm_display_mode *mode = &ctx->mode;
+   struct exynos_fimd_pp *pp_display;
struct fimd_driver_data *driver_data;
u32 val, clkdiv, vidcon1;
int hblank, vblank, vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+   int ret = 0;

driver_data = ctx->driver_data;
if (ctx->suspended)
@@ -234,6 +276,30 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (mode->htotal == 0 || mode->vtotal == 0)
return;

+   /* The FIMD and the post processor(PP) poweroff calls below are needed
+* here to make sure that fimd_commit doesn't switch on the PPs twice
+* in a row. For proper working we need to keep fimd, and the PPs
+* off, before we start again. This flag "pp_running" will also help
+* in syncing any of the clock enable/disable calls in PP routines.
+*/
+   if (ctx->enable_pp && ctx->pp_running) {
+   if (fimd_wait_till_per_frame_off(ctx))
+   DRM_ERROR("failed to switch off fimd per frame\n");
+   list_for_each_entry_reverse(pp_display, &ctx->fimd_pp_list,
+   list) {
+   if (pp_display->ops->power_off) {
+   ret = pp_display->ops->
+   power_off(pp_display->c

[RFC 0/4] drm: exynos: Add drivers for MDNIE and IELCD

[Ajay Kumar]

This series is based on exynos-drm-next-todo branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

On Exynos SOC, FIMD supports various post processors
like MIE, MDNIE and IELCD for image enhancement purposes.
This patchset adds an infrastructure in exynos FIMD to support such
post procerssors and also adds support routines for MDNIE, and IELCD.

(1) For basic display output,
-- MDNIE and IELCD should have same video timings as FIMD (mode_set)
-- strict power_up/down sequence need to be followed between FIMD,
   MDNIE, and IELCD (power_on, power_off)

(2) For enhanced display output,
-- MDNIE needs image enhancement data from userspace
   (set_property and set_gamma)

Rahul Sharma's patchset at:
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/27642
The above patchset is needed to support the enhanced display output.

MDNIE and IELCD DT nodes are given as phandles to FIMD DT node.
SOC specific information like base address, clocks and other
configuration information are extracted via FIMD DT node.

Ajay Kumar, Shirish, Rahul Sharma (4):
  drm: exynos: Add infrastructure to support FIMD post processors
  drm: exynos: add MDNIE post processor
  drm: exynos: add IELCD post processor
  drm: exynos: add MDNIE and IELCD to FIMD pp list

 drivers/gpu/drm/exynos/Makefile|   3 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 179 
 drivers/gpu/drm/exynos/exynos_fimd_pp.h|  54 +++
 drivers/gpu/drm/exynos/exynos_ielcd.c  | 295 
 drivers/gpu/drm/exynos/exynos_mdnie.c  | 707 +
 drivers/gpu/drm/exynos/exynos_mdnie_regs.h | 154 +++
 include/video/samsung_fimd.h   |  49 +-
 7 files changed, 1439 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_fimd_pp.h
 create mode 100644 drivers/gpu/drm/exynos/exynos_ielcd.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie_regs.h

-- 
1.8.1.2

[PATCH 4/4] output: Drop display output class support

[Jean Delvare]

On Mon, 17 Mar 2014 15:49:10 +0100, Jean Delvare wrote:
> It was only ever used by the ACPI video driver, and that only use case
> vanished over 3 years ago (see commit 677bd810, "ACPI video: remove
> output switching control".) So this is dead code and I guess we can
> remove it now.
> 
> Signed-off-by: Jean Delvare 
> Cc: Zhang Rui 
> Cc: Len Brown 
> Cc: "Rafael J. Wysocki" 
> ---
>  drivers/video/Kconfig|6 -
>  drivers/video/Makefile   |2 
>  drivers/video/output.c   |  133 
> ---
>  include/linux/video_output.h |   57 --
>  4 files changed, 198 deletions(-)
> (...)

Rafael, wait a minute. I just remembered that this last patch depends
on another clean-up patch of mine which is not upstream yet:
[PATCH 1/2] fujitsu-laptop: Drop unneeded include

List platform-driver-x86 doesn't seem to be archived anywhere so I
can't point you to it. I will resend the patch with you in Cc so that
you can include it in the series.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

[Laurent Pinchart]

Hi Russell,

(CC'ing Philipp Zabel who might be able to provide feedback as a user of the 
component framework)

Could you please have a look at the questions below and provide an answer when 
you'll have time ? I'd like to bridge the gap between the component and the 
V4L2 asynchronous registration implementations.

On Friday 07 March 2014 00:24:33 Laurent Pinchart wrote:
> On Wednesday 26 February 2014 22:19:39 Russell King - ARM Linux wrote:
> > On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> > > Hi Russell
> > > 
> > > (I suspect this my email will be rejected by ALKML too like other my
> > > recent emails, but at least other MLs will pick it up and individual CCs
> > > too, so, if replying, maybe it would be good to keep my entire reply,
> > > all the more that it's going to be very short)
> > > 
> > > On Thu, 2 Jan 2014, Russell King wrote:
> > > > Subsystems such as ALSA, DRM and others require a single card-level
> > > > device structure to represent a subsystem.  However, firmware tends to
> > > > describe the individual devices and the connections between them.
> > > > 
> > > > Therefore, we need a way to gather up the individual component devices
> > > > together, and indicate when we have all the component devices.
> > > > 
> > > > We do this in DT by providing a "superdevice" node which specifies
> > > > 
> > > > the components, eg:
> > > > imx-drm {
> > > > compatible = "fsl,drm";
> > > > crtcs = <&ipu1>;
> > > > connectors = <&hdmi>;
> > > > };
> > > 
> > > It is a pity linux-media wasn't CC'ed and apparently V4L developers
> > > didn't notice this and other related patches in a "clean up" series, and
> > > now this patch is already in the mainline. But at least I'd like to ask
> > > whether the bindings, defined in
> > > Documentation/devicetree/bindings/media/video-interfaces.txt and
> > > implemented in drivers/media/v4l2-core/v4l2-of.c have been considered
> > > for this job, and - if so - why have they been found unsuitable?
> > > Wouldn't it have been better to use and - if needed - extend them to
> > > cover any deficiencies? Even though the implementation is currently
> > > located under drivers/media/v4l2-code/ it's pretty generic and should be
> > > easily transferable to a more generic location.
> > 
> > The component helpers have nothing to do with DT apart from solving
> > the problem of how to deal with subsystems which expect a single device,
> > but we have a group of devices and their individual drivers to cope with.
> > Subsystems like DRM and ALSA.
> 
> (and V4L2)
> 
> Point duly taken. First of all I want to mention that your proposal is
> greatly appreciated. This is a problem that crosses subsystem boundaries,
> and should thus be addressed centrally.
> 
> However, we (as in the V4L2 community, and me personally) would have
> appreciated to be CC'ed on the proposal. As you might know we already had a
> solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
> core/v4l2-async.c. Whether or not this solution should have been made
> generic instead of coming up with a new separate implementation would of
> course have been debatable, but the most important point would have been to
> make sure that v4l2-async could easily be implemented on top of the common
> component architecture.
> 
> The topic is particularly hot given that a similar solution was also
> proposed as part of the now defunct (or at least hibernating) common
> display framework. If I had replied to this mail thread without sleeping on
> it first I might not have known better and have got half-paranoid,
> wondereding whether there had been a deliberate attempt to fast-track this
> API before the V4L2 developers noticed. To be perfectly clear, there is
> *NO* implicit or explicit such accusation here, as I know better.
> 
> Let's all take this as a positive opportunity to cooperate more closely,
> media devices still need a huge effort to be cleanly supported on modern
> hardware, and we'll need all the development power we can get.
> 
> Accordingly, I would like to comment on the component API, despite the fact
> that it has been merged in mainline already. The first thing that I believe
> is missing is documentation. Do you have any pending patch for that, either
> as kerneldoc or as a text file for Documentation/ ? As I've read the code
> to understand it I might have missed so design goals, so please bear with
> the stupid questions that may follow.
> 
> I'll first provide a brief comparison of the two models to make the rest of
> the comments easier to understand.
> 
> v4l2-async calls the component master object v4l2_async_notifier. The base
> component child object is a v4l2_subdev instance instead of being a plain
> device. v4l2_subdev instances are stored in v4l2-async lists similarly to
> how the component framework stores objects, except that the list head is
> directly embedded inside the v4l2_

[PATCH] drm/mm: Fix search for smallest hole satisfying constraints

[Michel Dänzer]

On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 09:58:14AM +0900, Michel D?nzer wrote:
> > From: Michel D?nzer 
> > 
> > entry->size is the size of the node, not the size of the hole after it.
> > So the code would actually find the hole which can satisfy the
> > constraints and which is preceded by the smallest node, not the smallest
> > hole satisfying the constraints.
> > 
> > Reported-by: "Huang, FrankR" 
> > Signed-off-by: Michel D?nzer 
> 
> But drm-next just gained my kerneldoc patch for drm_mm, so can you please
> respin your patch and update the docs too?

What kind of update are you thinking of?


> While at it ... could you perhaps smash a bit of kerneldoc on top of
> enum drm_mm_search_flags, I seem to have missed it. With that this is
> 
> Reviewed-by: Daniel Vetter 

Thanks, but I'm afraid I'll have to pass on that. I'm just submitting a
fix for a problem Frank stumbled upon. I don't have the time right now,
nor the particular inclination to clean up the surrounding code.

Meanwhile, I've submitted a less invasive v2 fix.


BTW, do you think the fix would interact properly with coloring?


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

[PATCH v2] drm/mm: Fix search for smallest hole satisfying constraints

[Michel Dänzer]

From: Michel D?nzer 

entry->size is the size of the node, not the size of the hole after it.
So the code would actually find the hole which can satisfy the
constraints and which is preceded by the smallest node, not the smallest
hole satisfying the constraints.

Reported-by: "Huang, FrankR" 
Signed-off-by: Michel D?nzer 
---

v2: Less invasive fix.

 drivers/gpu/drm/drm_mm.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index a2d45b74..8b16a10 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -392,6 +392,8 @@ static struct drm_mm_node *drm_mm_search_free_generic(const 
struct drm_mm *mm,
best_size = ~0UL;

drm_mm_for_each_hole(entry, mm, adj_start, adj_end) {
+   unsigned long hole_size = adj_end - adj_start;
+
if (mm->color_adjust) {
mm->color_adjust(entry, color, &adj_start, &adj_end);
if (adj_end <= adj_start)
@@ -404,9 +406,9 @@ static struct drm_mm_node *drm_mm_search_free_generic(const 
struct drm_mm *mm,
if (!(flags & DRM_MM_SEARCH_BEST))
return entry;

-   if (entry->size < best_size) {
+   if (hole_size < best_size) {
best = entry;
-   best_size = entry->size;
+   best_size = hole_size;
}
}

@@ -433,6 +435,8 @@ static struct drm_mm_node 
*drm_mm_search_free_in_range_generic(const struct drm_
best_size = ~0UL;

drm_mm_for_each_hole(entry, mm, adj_start, adj_end) {
+   unsigned long hole_size = adj_end - adj_start;
+
if (adj_start < start)
adj_start = start;
if (adj_end > end)
@@ -450,9 +454,9 @@ static struct drm_mm_node 
*drm_mm_search_free_in_range_generic(const struct drm_
if (!(flags & DRM_MM_SEARCH_BEST))
return entry;

-   if (entry->size < best_size) {
+   if (hole_size < best_size) {
best = entry;
-   best_size = entry->size;
+   best_size = hole_size;
}
}

-- 
1.9.0

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

[Russell King - ARM Linux]

On Wed, Mar 19, 2014 at 06:22:14PM +0100, Laurent Pinchart wrote:
> Hi Russell,
> 
> (CC'ing Philipp Zabel who might be able to provide feedback as a user of the 
> component framework)
> 
> Could you please have a look at the questions below and provide an answer 
> when 
> you'll have time ? I'd like to bridge the gap between the component and the 
> V4L2 asynchronous registration implementations.

I have a reply partly prepared, but I'm snowed under by the L2 cache stuff
at the moment, sorry.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH] drm/exynos: add phy settings for RB resolutions

[Inki Dae]

Applied.

Thanks,
Inki Dae

2014-03-13 14:28 GMT+09:00 Shirish S :
> This patch adds support for the below mentioned
> pixel clocks in Exynos5250.
> Without them, following display modes won't
> be supported:
>
> 71 MHz  - 1280x800 at 60Hz RB
> 73.25 MHz   - 800x600 at 120Hz RB
> 88.75 MHz   - 1440x900 at 60Hz RB
> 115.5 MHz   - 1024x768 at 120Hz RB
> 119 MHz - 1680x1050 at 60Hz RB
>
> Signed-off-by: Shirish S 
> ---
> V2: Incorporated review comments
>
>  drivers/gpu/drm/exynos/exynos_hdmi.c |   45 
> ++
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 12fdf55..406d89d 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -304,6 +304,24 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] 
> = {
> },
> },
> {
> +   .pixel_clock = 7100,
> +   .conf = {
> +   0x01, 0x91, 0x1e, 0x15, 0x40, 0x3c, 0xce, 0x08,
> +   0x04, 0x20, 0xb2, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0xad, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> +   .pixel_clock = 7325,
> +   .conf = {
> +   0x01, 0xd1, 0x1f, 0x15, 0x40, 0x18, 0xe9, 0x08,
> +   0x02, 0xa0, 0xb7, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0xa8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> .pixel_clock = 74176000,
> .conf = {
> 0x01, 0xd1, 0x3e, 0x35, 0x40, 0x5b, 0xde, 0x08,
> @@ -331,6 +349,15 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] 
> = {
> },
> },
> {
> +   .pixel_clock = 8875,
> +   .conf = {
> +   0x01, 0x91, 0x25, 0x17, 0x40, 0x30, 0xfe, 0x08,
> +   0x06, 0x20, 0xde, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0x8a, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> .pixel_clock = 10650,
> .conf = {
> 0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08,
> @@ -349,6 +376,24 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] 
> = {
> },
> },
> {
> +   .pixel_clock = 11550,
> +   .conf = {
> +   0x01, 0xd1, 0x30, 0x1a, 0x40, 0x40, 0x10, 0x04,
> +   0x04, 0xa0, 0x21, 0xd9, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0xaa, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> +   .pixel_clock = 11900,
> +   .conf = {
> +   0x01, 0x91, 0x32, 0x14, 0x40, 0x60, 0xd8, 0x08,
> +   0x06, 0x20, 0x2a, 0xd9, 0x45, 0xa0, 0xac, 0x80,
> +   0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> +   0x54, 0x9d, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
> +   },
> +   },
> +   {
> .pixel_clock = 14625,
> .conf = {
> 0x01, 0xd1, 0x3d, 0x15, 0x40, 0x18, 0xfd, 0x08,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: set the active aspect ratio as per mode

[Inki Dae]

2014-03-18 22:04 GMT+09:00 Tomasz Figa :
> Hi Shirish,
>
>
> On 13.03.2014 06:28, Shirish S wrote:
>>
>> Now that the drm_display_mode also provides aspect
>> ratio for all resolutions, this patch adds its usage
>> to set the active aspect ratio of AVI info frame
>> packets as per CEA-861-D standard's Table 9.
>>
>> This is also needed to abide by the 7-27
>> compliance test of HDMI.
>>
>> Signed-off-by: Shirish S 
>> ---
>> V2: rebased on new branch
>> V3: Incorporated review comments
>>
>>   drivers/gpu/drm/exynos/exynos_hdmi.c |   35
>> +++---
>>   1 file changed, 28 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 12fdf55..9b0b617 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -53,12 +53,13 @@
>>   /* AVI header and aspect ratio */
>>   #define HDMI_AVI_VERSION  0x02
>>   #define HDMI_AVI_LENGTH   0x0D
>> -#define AVI_PIC_ASPECT_RATIO_16_9  (2 << 4)
>> -#define AVI_SAME_AS_PIC_ASPECT_RATIO   8
>>
>>   /* AUI header info */
>>   #define HDMI_AUI_VERSION  0x01
>>   #define HDMI_AUI_LENGTH   0x0A
>> +#defineAVI_SAME_AS_PIC_ASPECT_RATIO 0x8
>> +#defineAVI_4_3_CENTER_RATIO0x9
>> +#defineAVI_16_9_CENTER_RATIO   0xa
>
>
> One minor nitpick: Please don't use tabs between #define and macro name.
>

Fixed and applied.

Thanks,
Inki Dae

> After fixing this issue feel free to add my:
>
> Reviewed-by: Tomasz Figa 
>
> Best regards,
> Tomasz
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2] drm: improve various bridge devices support

[Inki Dae]

This patch integrates existing drm_panel and drm_bridge frameworks
to one integrated framework, drm_hw_block.

For this, I had already sent a email to make a discussion[1] about
how we could support all bridges, one bridge between crtc and encoder,
and another bridge between encoder and panel.

Now existing drm_panel could be used only for real panel, and
drm_bridge only for lvds bridge devices between encoder and panel.
However, some embedded SoC have bridge devices of other type
between crtc and encoder, i.e. Image Enhancer chip.

So the existing encoder driver couldn't control such bridge commonly
using existing drm_bridge because only drm_encoder has drm_bridge.

Below shows how encoder driver could control bridge device using existing
drm_bridge.

display controller - bridge1 - mipi dsi - bridge2 - panel
  |  /|\ /|\
  |---|   |
  controlled by drm_bridge|
  |   |
  |---|
 controlled by drm_panel

In the other hands, drm_panel has no any dependency of drm_encoder, and
its infrastructure could be used by crtc driver with a little change.
So this integrated framework basically uses existing infrastructure of
drm_panel, and just adds drm_lvds structure to it for backward compatibility.

And then, we could add a new bridge type, i.e. drm_enhancer in the near future.
So this patch is just ready for that.

As a result, if we add drm_enhancer, crtc driver could control a bridge device
between crtc and encoder like below.

display controller - bridge1 - mipi dsi - bridge2 - panel
   |   /|\|  /|\/|\
   || |---|  |
 controlled by drm_enhancer controlled by drm_lvds   |
  |  |
  |--|
controlled by drm_panel

Changelog v2:
- Call enable and disable callback according to bridge type.
- Correct module description.

[1] http://www.spinics.net/lists/dri-devel/msg5.html

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/Kconfig  |4 ++
 drivers/gpu/drm/Makefile |2 +-
 drivers/gpu/drm/drm_hw_block.c   |  104 
 drivers/gpu/drm/drm_panel.c  |  100 --
 drivers/gpu/drm/exynos/Kconfig   |1 +
 drivers/gpu/drm/panel/Kconfig|1 +
 drivers/gpu/drm/panel/panel-simple.c |   37 +-
 drivers/gpu/drm/tegra/drm.h  |2 +-
 drivers/gpu/drm/tegra/dsi.c  |   10 +--
 drivers/gpu/drm/tegra/output.c   |   22 +++---
 include/drm/drm_hw_block.h   |  127 ++
 include/drm/drm_panel.h  |   82 --
 12 files changed, 274 insertions(+), 218 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_hw_block.c
 delete mode 100644 drivers/gpu/drm/drm_panel.c
 create mode 100644 include/drm/drm_hw_block.h
 delete mode 100644 include/drm/drm_panel.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8e7fa4d..020a0f2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -24,6 +24,10 @@ config DRM_MIPI_DSI
bool
depends on DRM

+config DRM_HW_BLOCK
+   bool
+   depends on DRM
+
 config DRM_USB
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 292a79d..a943663 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
-drm-$(CONFIG_DRM_PANEL) += drm_panel.o
+drm-$(CONFIG_DRM_HW_BLOCK) += drm_hw_block.o

 drm-usb-y   := drm_usb.o

diff --git a/drivers/gpu/drm/drm_hw_block.c b/drivers/gpu/drm/drm_hw_block.c
new file mode 100644
index 000..9ba73a8
--- /dev/null
+++ b/drivers/gpu/drm/drm_hw_block.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

Two additional fixes on top of my last pull as promised, one for a 3.14
specific regression, one cc: stable.

This clears up my backlog, at least of anything non-controversial.

BR,
Jani.


The following changes since commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b:

  drm/i915: Don't enable display error interrupts from the start (2014-03-12 
17:20:34 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-03-19

for you to fetch changes up to 0f4706d2740f2a221cd502922b22e522009041d9:

  drm/i915: Disable stolen memory when DMAR is active (2014-03-19 10:05:38 
+0200)


Chris Wilson (1):
  drm/i915: Disable stolen memory when DMAR is active

Jani Nikula (1):
  Revert "drm/i915: don't touch the VDD when disabling the panel"

 drivers/gpu/drm/i915/i915_gem_stolen.c |7 +++
 drivers/gpu/drm/i915/intel_ddi.c   |1 +
 drivers/gpu/drm/i915/intel_dp.c|   10 +-
 3 files changed, 17 insertions(+), 1 deletion(-)

-- 
Jani Nikula, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/24001900/attachment.sig>

[RFC PATCH] drm: improve various bridge devices support

[Inki Dae]

This patch integrates existing drm_panel and drm_bridge frameworks
to one integrated framework, drm_hw_block.

For this, I had already sent a email to make a discussion[1] about
how we could support all bridges, one bridge between crtc and encoder,
and another bridge between encoder and panel.

Now existing drm_panel could be used only for real panel, and
drm_bridge only for lvds bridge devices between encoder and panel.
However, some embedded SoC have bridge devices of other type
between crtc and encoder, i.e. Image Enhancer chip.

So the existing encoder driver couldn't control such bridge commonly
using existing drm_bridge because only drm_encoder has drm_bridge.

Below shows how encoder driver could control bridge device using existing
drm_bridge.

display controller - bridge1 - mipi dsi - bridge2 - panel
  |  /|\ /|\
  |---|   |
  controlled by drm_bridge|
  |   |
  |---|
 controlled by drm_panel

In the other hands, drm_panel has no any dependency of drm_encoder, and
its infrastructure could be used by crtc driver with a little change.
So this integrated framework basically uses existing infrastructure of
drm_panel, and just adds drm_lvds structure to it for backward compatibility.

And then, we could add a new bridge type, i.e. drm_enhancer in the near future.
So this patch is just ready for that.

As a result, if we add drm_enhancer, crtc driver could control a bridge device
between crtc and encoder like below.

display controller - bridge1 - mipi dsi - bridge2 - panel
   |   /|\|  /|\/|\
   || |---|  |
 controlled by drm_enhancer controlled by drm_lvds   |
  |  |
  |--|
controlled by drm_panel

[1] http://www.spinics.net/lists/dri-devel/msg5.html

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/Kconfig  |4 ++
 drivers/gpu/drm/Makefile |2 +-
 drivers/gpu/drm/drm_hw_block.c   |  104 +
 drivers/gpu/drm/drm_panel.c  |  100 ---
 drivers/gpu/drm/exynos/Kconfig   |1 +
 drivers/gpu/drm/panel/Kconfig|1 +
 drivers/gpu/drm/panel/panel-simple.c |   37 ++--
 drivers/gpu/drm/tegra/drm.h  |2 +-
 drivers/gpu/drm/tegra/dsi.c  |   10 ++--
 drivers/gpu/drm/tegra/output.c   |   22 +++
 include/drm/drm_hw_block.h   |  107 ++
 include/drm/drm_panel.h  |   82 --
 12 files changed, 254 insertions(+), 218 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_hw_block.c
 delete mode 100644 drivers/gpu/drm/drm_panel.c
 create mode 100644 include/drm/drm_hw_block.h
 delete mode 100644 include/drm/drm_panel.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8e7fa4d..020a0f2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -24,6 +24,10 @@ config DRM_MIPI_DSI
bool
depends on DRM

+config DRM_HW_BLOCK
+   bool
+   depends on DRM
+
 config DRM_USB
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 292a79d..a943663 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
-drm-$(CONFIG_DRM_PANEL) += drm_panel.o
+drm-$(CONFIG_DRM_HW_BLOCK) += drm_hw_block.o

 drm-usb-y   := drm_usb.o

diff --git a/drivers/gpu/drm/drm_hw_block.c b/drivers/gpu/drm/drm_hw_block.c
new file mode 100644
index 000..e7bb1fc
--- /dev/null
+++ b/drivers/gpu/drm/drm_hw_block.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 

[PATCH 1/3] drm/dp: make aux retries less chatty

[Jani Nikula]

On Wed, 19 Mar 2014, Alex Deucher  wrote:
> On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula
>  wrote:
>> On Tue, 18 Mar 2014, Alex Deucher  wrote:
>>> Switch to debug only to avoid flooding the logs.
>>> This mirrors the behavior in some other drivers.
>>
>> I'd rather think we should find out why the DP devices are replying with
>> repeated native or i2c-over-aux defers. This doesn't help; I'm not in
>> favour.
>
> While I agree with you in theory, in practice this will generate a ton
> of regression bug reports since there will be new error messages in
> the kernel log on some systems even though the displays are working
> fine.  I'm only seeing this on certain cards, others are perfectly
> fine even with the same monitors and I don't have the bandwidth right
> now to debug this further.  In all cases the monitors are working
> correctly.

I'd argue we *want* the regression reports even when everything seems to
be working fine. Otherwise we'll never fix the stuff up.

Just a while back we used to have an infinite retry loop there in i915,
until a buggy dock firmware actually deferred indefinitely. Clearly most
devices out there eventually replied with something other than
defer. We'd like to find out whether and how much the retry and/or delay
should be increased to not hit the error condition at all.

That's how I feel anyway. I'd like to see others chime in as well, and I
won't insist if y'all think the error message must go.


BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

[RFCv3 03/14] drm: Add primary plane helpers

[Matt Roper]

On Wed, Mar 19, 2014 at 01:24:23PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> > When we expose non-overlay planes to userspace, they will become
> > accessible via standard userspace plane API's.  We should be able to
> > handle the standard plane operations against primary planes in a generic
> > way via the page flip handler and modeset handler.
> > 
> > Drivers that can program primary planes more efficiently, that want to
> > use their own primary plane structure to track additional information,
> > or that don't have the limitations assumed by the helpers are free to
> > provide their own implementation of some or all of these handlers.
> > 
> > Signed-off-by: Matt Roper 
> 
> One thing I've noticed with planes is that we don't have any per-plane
> size limits. Which will be annoying for cursors at least, but looking at
> intel's hw history there are other planes with limits smaller than
> dev->mode_config.max_widht/height.
> 
> I think as part of the universal plane work here we should add this to the
> getplane ioctl (we can extend at the end with full backwards compat) and
> use the max_width/height as default for primary/overlay planes and
> cursor_width/height for cursor planes.

I'm not sure I understand how to (cleanly) extend the existing ioctl
safely.  Userspace (libdrm) allocates a drm_mode_get_plane structure on
the stack with a specific size.  If we try to extend this structure to
return more information, and have the kernel write into the new fields,
aren't we just going to be spilling over into other userspace stack
variables if we run an old libdrm on the new kernel?  The only
approaches I see that could make this work would be huge ugly hacks:
 * Reclaiming the top few bits of plane_id to use as "I sent you the
   new, larger structure" capability flags (which assumes plane ID's are
   always small enough to leave those bits 0 on current kernels; this
   would effectively reduce our plane ID address space).
 * Figure out a way to encode extra information as bogus pixel formats
   and shove it into the format list returned to userspace.  Presumably
   userspace would just ignore/skip the bogus formats.

I suppose we could add a new GetPlane2 ioctl or something that returned
more info, but I figured it was probably easier to just shove max plane
size (and a bunch of other plane capabilities / limitations) into some
new read-only plane properties.  Read-only properties are easy to extend
if we find other pieces of information we want to return in the future,
so that seems like the most natural interface to me.


Matt

> 
> Probably there's more stuff userspace might be interested in (like stride
> limits and alignment maybe), but that'd be a start at least.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 288 
> > +++--
> >  include/drm/drm_crtc.h |  81 +
> >  2 files changed, 330 insertions(+), 39 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 0983996..db54ae9 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1118,6 +1118,255 @@ void drm_plane_force_disable(struct drm_plane 
> > *plane)
> >  }
> >  EXPORT_SYMBOL(drm_plane_force_disable);
> >  
> > +/*
> > + * Checks that the framebuffer is big enough for the CRTC viewport
> > + * (x, y, hdisplay, vdisplay)
> > + */
> > +static int drm_crtc_check_viewport(const struct drm_crtc *crtc,
> > +  int x, int y,
> > +  const struct drm_display_mode *mode,
> > +  const struct drm_framebuffer *fb)
> > +
> > +{
> > +   int hdisplay, vdisplay;
> > +
> > +   hdisplay = mode->hdisplay;
> > +   vdisplay = mode->vdisplay;
> > +
> > +   if (drm_mode_is_stereo(mode)) {
> > +   struct drm_display_mode adjusted = *mode;
> > +
> > +   drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
> > +   hdisplay = adjusted.crtc_hdisplay;
> > +   vdisplay = adjusted.crtc_vdisplay;
> > +   }
> > +
> > +   if (crtc->invert_dimensions)
> > +   swap(hdisplay, vdisplay);
> > +
> > +   if (hdisplay > fb->width ||
> > +   vdisplay > fb->height ||
> > +   x > fb->width - hdisplay ||
> > +   y > fb->height - vdisplay) {
> > +   DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport 
> > %ux%u+%d+%d%s.\n",
> > + fb->width, fb->height, hdisplay, vdisplay, x, y,
> > + crtc->invert_dimensions ? " (inverted)" : "");
> > +   return -ENOSPC;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +/*
> > + * Returns the connectors currently associated with a CRTC.  This function
> > + * should be called twice:  once with a NULL connector list to retrieve
> > + * the list size, and once with the properly allocated list to be filled 
> > in.
> > + */
> > +static int get_connectors_for_crtc(stru

[Intel-gfx] [RFCv3 11/14] drm/i915: Intel-specific primary plane handling

[Daniel Vetter]

On Wed, Mar 19, 2014 at 01:11:26PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote:
> > Intel hardware allows the primary plane to be disabled independently of
> > the CRTC.  Provide custom primary plane handling to allow this.
> > 
> > Cc: Intel Graphics Development 
> > Signed-off-by: Matt Roper 
> 
> Overall this is imo a new feature since it exposes primary plane disabling
> to userspace. Which means I want a crc based igt for this. Two interesting
> cases imo:
> 
> 1) Partially visible primary plane behind an overlay plane. Disabling it
> should change those areas from the primary plane to grey or something, so
> easy to check with CRCs.
> 
> 2) Primary plane + cursor, disable primary plane. Then check that the
> cursor is still working. Same for overlay sprites.
> 
> At least on all currently supported platforms we don't have unified planes
> in the hardware, so imo it's worth to check that this works properly.

One big reason I've forgotten why I really want testcase for this is that
historically our code has fallen over in _really_ bad ways without a
primary fb. fastboot has brought a lot of these issues to light (since we
occasionally fail to wrap up the firmware's fb properly). So having a bit
of a baseline testcase so that we can easily add regression tests for
specific bugs once we inevitably run into them is good prep work, too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFCv3 09/14] drm: Allow userspace to ask for full plane list (universal planes)

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:54PM -0700, Matt Roper wrote:
> Userspace clients which wish to receive all DRM planes (primary and
> cursor planes in addition to the traditional overlay planes) may set the
> DRM_CLIENT_CAP_UNIVERSAL_PLANES capability.
> 
> Signed-off-by: Matt Roper 

I don't see any issues with merging the primary plane stuff early, but I
think we should hold off a bit with exposing all this to userspace, at
least by default. I think we should have the cursor plane issues all
resolved and at least the userspace tests in decent shape before we throw
the big switch here.
-Daniel


> ---
>  drivers/gpu/drm/drm_crtc.c  | 20 +++-
>  drivers/gpu/drm/drm_ioctl.c |  5 +
>  include/drm/drmP.h  |  5 +
>  include/uapi/drm/drm.h  |  8 
>  4 files changed, 33 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0c395e8..fb8e493 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2160,6 +2160,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
> *data,
>   struct drm_plane *plane;
>   uint32_t __user *plane_ptr;
>   int copied = 0, ret = 0;
> + unsigned num_planes;
>  
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
> @@ -2167,17 +2168,26 @@ int drm_mode_getplane_res(struct drm_device *dev, 
> void *data,
>   drm_modeset_lock_all(dev);
>   config = &dev->mode_config;
>  
> + if (file_priv->universal_planes)
> + num_planes = config->num_total_plane;
> + else
> + num_planes = config->num_overlay_plane;
> +
>   /*
>* This ioctl is called twice, once to determine how much space is
>* needed, and the 2nd time to fill it.
>*/
> - if (config->num_overlay_plane &&
> - (plane_resp->count_planes >= config->num_overlay_plane)) {
> + if (num_planes &&
> + (plane_resp->count_planes >= num_planes)) {
>   plane_ptr = (uint32_t __user *)(unsigned 
> long)plane_resp->plane_id_ptr;
>  
>   list_for_each_entry(plane, &config->plane_list, head) {
> - /* Only advertise overlays to userspace for now. */
> - if (plane->type != DRM_PLANE_TYPE_OVERLAY)
> + /*
> +  * Unless userspace set the 'universal planes'
> +  * capability bit, only advertise overlays.
> +  */
> + if (plane->type != DRM_PLANE_TYPE_OVERLAY &&
> + !file_priv->universal_planes)
>   continue;
>  
>   if (put_user(plane->base.id, plane_ptr + copied)) {
> @@ -2187,7 +2197,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
> *data,
>   copied++;
>   }
>   }
> - plane_resp->count_planes = config->num_overlay_plane;
> + plane_resp->count_planes = num_planes;
>  
>  out:
>   drm_modeset_unlock_all(dev);
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index f4dc9b7..5eb92b6 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -328,6 +328,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>   return -EINVAL;
>   file_priv->stereo_allowed = req->value;
>   break;
> + case DRM_CLIENT_CAP_UNIVERSAL_PLANES:
> + if (req->value > 1)
> + return -EINVAL;
> + file_priv->universal_planes = req->value;
> + break;
>   default:
>   return -EINVAL;
>   }
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 3857450..1106297 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -438,6 +438,11 @@ struct drm_file {
>   unsigned is_master :1; /* this file private is a master for a minor */
>   /* true when the client has asked us to expose stereo 3D mode flags */
>   unsigned stereo_allowed :1;
> + /*
> +  * true if client understands CRTC primary planes and cursor planes
> +  * in the plane list
> +  */
> + unsigned universal_planes:1;
>  
>   struct pid *pid;
>   kuid_t uid;
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b06c8ed..6e4952b 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -637,6 +637,14 @@ struct drm_get_cap {
>   */
>  #define DRM_CLIENT_CAP_STEREO_3D 1
>  
> +/**
> + * DRM_CLIENT_CAP_UNIVERSAL_PLANES
> + *
> + * If set to 1, the DRM core will expose all planes (overlay, primary, and
> + * cursor) to userspace.
> + */
> +#define DRM_CLIENT_CAP_UNIVERSAL_PLANES  2
> +
>  /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
>  struct drm_set_client_cap {
>   __u64 capability;
> -- 
> 1.8.5.1
> 
> ___
> dri-devel mailing li

[PATCH] drm: Prefer noninterlace cmdline mode unless explicitly specified

[Takashi Iwai]

At Wed, 19 Mar 2014 15:17:50 +0100,
Daniel Vetter wrote:
> 
> On Wed, Mar 19, 2014 at 02:53:13PM +0100, Takashi Iwai wrote:
> > Currently drm_pick_cmdline_mode() doesn't care about the interlace
> > when the given mode line has no "i" suffix.  That is, when there are
> > multiple entries for the same resolution, an interlace mode might be
> > picked up just depending on the assigned order, and there is no way to
> > exclude it.
> > 
> > This patch changes the logic for the mode selection, to prefer the
> > noninterlace mode unless the interlace mode is explicitly given.
> > When no matching mode is found, it still tries the interlace mode as
> > fallback.
> > 
> > Signed-off-by: Takashi Iwai 
> 
> Yeah, makes sense. Do you have some bz or something for reference?

https://bugzilla.novell.com/show_bug.cgi?id=853350

A reporter hits a problem with an LCD monitor connected to VGA.
1024x768i is broken but other modes couldn't be chosen.


Takashi

> 
> Reviewed-by: Daniel Vetter 
> 
> Cheers, Daniel
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 98a03639b413..0a4b0a24359f 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1162,6 +1162,7 @@ static struct drm_display_mode 
> > *drm_pick_cmdline_mode(struct drm_fb_helper_conne
> >  {
> > struct drm_cmdline_mode *cmdline_mode;
> > struct drm_display_mode *mode = NULL;
> > +   bool prefer_non_interlace;
> >  
> > cmdline_mode = &fb_helper_conn->cmdline_mode;
> > if (cmdline_mode->specified == false)
> > @@ -1173,6 +1174,8 @@ static struct drm_display_mode 
> > *drm_pick_cmdline_mode(struct drm_fb_helper_conne
> > if (cmdline_mode->rb || cmdline_mode->margins)
> > goto create_mode;
> >  
> > +   prefer_non_interlace = !cmdline_mode->interlace;
> > + again:
> > list_for_each_entry(mode, &fb_helper_conn->connector->modes, head) {
> > /* check width/height */
> > if (mode->hdisplay != cmdline_mode->xres ||
> > @@ -1187,10 +1190,18 @@ static struct drm_display_mode 
> > *drm_pick_cmdline_mode(struct drm_fb_helper_conne
> > if (cmdline_mode->interlace) {
> > if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
> > continue;
> > +   } else if (prefer_non_interlace) {
> > +   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > +   continue;
> > }
> > return mode;
> > }
> >  
> > +   if (prefer_non_interlace) {
> > +   prefer_non_interlace = false;
> > +   goto again;
> > +   }
> > +
> >  create_mode:
> > mode = drm_mode_create_from_cmdline_mode(fb_helper_conn->connector->dev,
> >  cmdline_mode);
> > -- 
> > 1.9.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 

[PATCH] drm: Prefer noninterlace cmdline mode unless explicitly specified

[Daniel Vetter]

On Wed, Mar 19, 2014 at 02:53:13PM +0100, Takashi Iwai wrote:
> Currently drm_pick_cmdline_mode() doesn't care about the interlace
> when the given mode line has no "i" suffix.  That is, when there are
> multiple entries for the same resolution, an interlace mode might be
> picked up just depending on the assigned order, and there is no way to
> exclude it.
> 
> This patch changes the logic for the mode selection, to prefer the
> noninterlace mode unless the interlace mode is explicitly given.
> When no matching mode is found, it still tries the interlace mode as
> fallback.
> 
> Signed-off-by: Takashi Iwai 

Yeah, makes sense. Do you have some bz or something for reference?

Reviewed-by: Daniel Vetter 

Cheers, Daniel
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 98a03639b413..0a4b0a24359f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1162,6 +1162,7 @@ static struct drm_display_mode 
> *drm_pick_cmdline_mode(struct drm_fb_helper_conne
>  {
>   struct drm_cmdline_mode *cmdline_mode;
>   struct drm_display_mode *mode = NULL;
> + bool prefer_non_interlace;
>  
>   cmdline_mode = &fb_helper_conn->cmdline_mode;
>   if (cmdline_mode->specified == false)
> @@ -1173,6 +1174,8 @@ static struct drm_display_mode 
> *drm_pick_cmdline_mode(struct drm_fb_helper_conne
>   if (cmdline_mode->rb || cmdline_mode->margins)
>   goto create_mode;
>  
> + prefer_non_interlace = !cmdline_mode->interlace;
> + again:
>   list_for_each_entry(mode, &fb_helper_conn->connector->modes, head) {
>   /* check width/height */
>   if (mode->hdisplay != cmdline_mode->xres ||
> @@ -1187,10 +1190,18 @@ static struct drm_display_mode 
> *drm_pick_cmdline_mode(struct drm_fb_helper_conne
>   if (cmdline_mode->interlace) {
>   if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
>   continue;
> + } else if (prefer_non_interlace) {
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + continue;
>   }
>   return mode;
>   }
>  
> + if (prefer_non_interlace) {
> + prefer_non_interlace = false;
> + goto again;
> + }
> +
>  create_mode:
>   mode = drm_mode_create_from_cmdline_mode(fb_helper_conn->connector->dev,
>cmdline_mode);
> -- 
> 1.9.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/3] drm/dp: make aux retries less chatty

[Daniel Vetter]

On Wed, Mar 19, 2014 at 09:42:44AM -0400, Alex Deucher wrote:
> On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula
>  wrote:
> > On Tue, 18 Mar 2014, Alex Deucher  wrote:
> >> Switch to debug only to avoid flooding the logs.
> >> This mirrors the behavior in some other drivers.
> >
> > I'd rather think we should find out why the DP devices are replying with
> > repeated native or i2c-over-aux defers. This doesn't help; I'm not in
> > favour.
> 
> While I agree with you in theory, in practice this will generate a ton
> of regression bug reports since there will be new error messages in
> the kernel log on some systems even though the displays are working
> fine.  I'm only seeing this on certain cards, others are perfectly
> fine even with the same monitors and I don't have the bandwidth right
> now to debug this further.  In all cases the monitors are working
> correctly.

Yeah, as a stopgap I'm ok with this. I guess longer-term we might want to
cache parts of the DPCD in the helper and provide an invalidate function
which drivers can call on hotplug. With that the dp aux helper could be a
bit more intelligent with non-native syncs.

One of the things I want to push down a bit into helpers is the
branch/sink decoding and figuring out whether we have some legacy thing
where hotplug pins might be busted or which need massively longer delays.

Anyway Reviewed-by: Daniel Vetter  Btw I've just
pulled in Jani's conversion for i915, so we should have a few big drivers
using all this with 3.15. I hope all the increased test coverage pays off
;-)

Cheers, Daniel

> 
> Alex
> 
> >
> > BR,
> > Jani.
> >
> >
> >>
> >> Signed-off-by: Alex Deucher 
> >> ---
> >>  drivers/gpu/drm/drm_dp_helper.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> >> b/drivers/gpu/drm/drm_dp_helper.c
> >> index 35251af..74724aa 100644
> >> --- a/drivers/gpu/drm/drm_dp_helper.c
> >> +++ b/drivers/gpu/drm/drm_dp_helper.c
> >> @@ -402,7 +402,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, 
> >> u8 request,
> >>   }
> >>   }
> >>
> >> - DRM_ERROR("too many retries, giving up\n");
> >> + DRM_DEBUG_KMS("too many retries, giving up\n");
> >>   return -EIO;
> >>  }
> >>
> >> @@ -656,7 +656,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> >> struct drm_dp_aux_msg *msg)
> >>   }
> >>   }
> >>
> >> - DRM_ERROR("too many retries, giving up\n");
> >> + DRM_DEBUG_KMS("too many retries, giving up\n");
> >>   return -EREMOTEIO;
> >>  }
> >>
> >> --
> >> 1.8.3.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Prefer noninterlace cmdline mode unless explicitly specified

[Takashi Iwai]

Currently drm_pick_cmdline_mode() doesn't care about the interlace
when the given mode line has no "i" suffix.  That is, when there are
multiple entries for the same resolution, an interlace mode might be
picked up just depending on the assigned order, and there is no way to
exclude it.

This patch changes the logic for the mode selection, to prefer the
noninterlace mode unless the interlace mode is explicitly given.
When no matching mode is found, it still tries the interlace mode as
fallback.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/drm_fb_helper.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 98a03639b413..0a4b0a24359f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1162,6 +1162,7 @@ static struct drm_display_mode 
*drm_pick_cmdline_mode(struct drm_fb_helper_conne
 {
struct drm_cmdline_mode *cmdline_mode;
struct drm_display_mode *mode = NULL;
+   bool prefer_non_interlace;

cmdline_mode = &fb_helper_conn->cmdline_mode;
if (cmdline_mode->specified == false)
@@ -1173,6 +1174,8 @@ static struct drm_display_mode 
*drm_pick_cmdline_mode(struct drm_fb_helper_conne
if (cmdline_mode->rb || cmdline_mode->margins)
goto create_mode;

+   prefer_non_interlace = !cmdline_mode->interlace;
+ again:
list_for_each_entry(mode, &fb_helper_conn->connector->modes, head) {
/* check width/height */
if (mode->hdisplay != cmdline_mode->xres ||
@@ -1187,10 +1190,18 @@ static struct drm_display_mode 
*drm_pick_cmdline_mode(struct drm_fb_helper_conne
if (cmdline_mode->interlace) {
if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
continue;
+   } else if (prefer_non_interlace) {
+   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+   continue;
}
return mode;
}

+   if (prefer_non_interlace) {
+   prefer_non_interlace = false;
+   goto again;
+   }
+
 create_mode:
mode = drm_mode_create_from_cmdline_mode(fb_helper_conn->connector->dev,
 cmdline_mode);
-- 
1.9.0

[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Daniel Vetter]

On Wed, Mar 19, 2014 at 08:23:31AM -0400, Rob Clark wrote:
> On Wed, Mar 19, 2014 at 7:07 AM, Daniel Vetter  wrote:
> > On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
> > On the i915 side I think all the various pieces we need are finally coming
> > together, and I hope a lot of that goes in for 3.16. So I think we can
> > soonish jump on board with providing real proof-of-concepts based on your
> > ioctl.
> >
> > For merging the core stuff I think we should concentrate first on getting
> > Matt's universal planes stuff in asap. I've scanned through his series
> > with a cursory look and atm it has a few change-the-world flag days. I'll
> > try to do an in-depth review later on looking for ways to make the
> > transition smoother. cursor planes seem to be the main culprit in this ...
> 
> it would be nice if there was a way to get things merged sooner than
> 3.18 or so.. but we do need at least the *initial* primary plane work
> first.
> 
> Some of the stuff like cursor planes should really happen
> independently from atomic.  And maybe at the same time we want to
> expose cursor properties, or at least somehow property-ify cursors.
> The part that really needs to be in before atomic is the
> crtc->primary->fb bit.

Hm, just wanted to dump a comment on Matt's series that imo cursor planes
should happen first before we enable universal planes. And the resulting
unification is really kinda neat for atomic imo.

Still pondering the details but I don't think there's too much fuzz
involved in exposing cursor planes. We can't do it without any driver
changes at all since there's no generic way to go from cursor fb to buffer
manager object id. But beyond that there's shouldn't be anything needed.

I'm hashing out a slightly more detailed plan atm.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/4] ACPI: fix ACPI_VIDEO dependencies

[Jean Delvare]

On Wed, 19 Mar 2014 14:10:53 +0100, Rafael J. Wysocki wrote:
> On Wednesday, March 19, 2014 07:51:45 AM Jean Delvare wrote:
> > Hi Rafael,
> > 
> > On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> > > On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > > > From: Jean Delvare 
> > > > Subject: ACPI: fix ACPI_VIDEO dependencies
> > > > 
> > > > ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago
> > > > (see commit 677bd810, "ACPI video: remove output switching control".)
> > > > So it's about time to remove the Kconfig dependency between these two
> > > > options.
> > > > 
> > > > Signed-off-by: Jean Delvare 
> > > > Cc: Zhang Rui 
> > > > Cc: Len Brown 
> > > > Cc: "Rafael J. Wysocki" 
> > > 
> > > Do you want me to take this series?
> > 
> > If other maintainers are OK with it, yes, I think that would be the
> > easiest way. Thanks for proposing. All these patches depend on each
> > other and must be applied in the right order, so pushing them through
> > different trees would be slow at best, and risky.
> 
> OK, I'll queue them up for 3.15 then, as I haven't seen any objections.

Thank you :-)

> > Also, thinking about it, I wonder if the first 3 patches of the series
> > could go to longterm kernel series? While they do not fix any build
> > breakage nor run-time bug, without them everyone (on x86 at least) is
> > forced to build dead code. This is kind of frustrating. They are simple
> > and obvious enough that hopefully there won't be any objection.
> 
> I think it'll be best if you request the -stable people to pick
> up those commits once they have reached the Linus' tree.

Sure, I can do that.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

[PATCH 1/4] ACPI: fix ACPI_VIDEO dependencies

[Rafael J. Wysocki]

On Wednesday, March 19, 2014 07:51:45 AM Jean Delvare wrote:
> Hi Rafael,
> 
> On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> > On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > > From: Jean Delvare 
> > > Subject: ACPI: fix ACPI_VIDEO dependencies
> > > 
> > > ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago
> > > (see commit 677bd810, "ACPI video: remove output switching control".)
> > > So it's about time to remove the Kconfig dependency between these two
> > > options.
> > > 
> > > Signed-off-by: Jean Delvare 
> > > Cc: Zhang Rui 
> > > Cc: Len Brown 
> > > Cc: "Rafael J. Wysocki" 
> > 
> > Do you want me to take this series?
> 
> If other maintainers are OK with it, yes, I think that would be the
> easiest way. Thanks for proposing. All these patches depend on each
> other and must be applied in the right order, so pushing them through
> different trees would be slow at best, and risky.

OK, I'll queue them up for 3.15 then, as I haven't seen any objections.

> Also, thinking about it, I wonder if the first 3 patches of the series
> could go to longterm kernel series? While they do not fix any build
> breakage nor run-time bug, without them everyone (on x86 at least) is
> forced to build dead code. This is kind of frustrating. They are simple
> and obvious enough that hopefully there won't be any objection.

I think it'll be best if you request the -stable people to pick
up those commits once they have reached the Linus' tree.

Thanks,
Rafael

[PATCH RFC] drm: Make the drm_vma_manager authentication mechanism a bit more versatile

[Thomas Hellstrom]

On 03/19/2014 12:45 PM, David Herrmann wrote:
> Hi
>
> On Wed, Mar 19, 2014 at 12:33 PM, Thomas Hellstrom
>  wrote:
>> By handing the authentication mechanism tokens in the form of const void
>> pointers instead of struct file pointers, drivers are free to provide 
>> whatever
>> file pointers they find appropriate. The pointers are never dereferenced in
>> the drm_vma_manager so that shouldn't be a problem.
>>
>> As an example, the vmwgfx driver would like to provide struct ttm_object_file
>> pointers.
> I guess a "struct file*" pointer in tmm_object_file would be easier,
> but if that reverse dependency is not wanted, I'm fine with that. Just
> make sure you don't use drm_vma_node_verify_access for TTM directly as
> TTM passes in a file pointer.
>
> Reviewed-by: David Herrmann 
>
> Thanks
> David

Thanks for reviewing, David.

Although it turned out that I won't be needing this, ATM
since the TTM object mechanism already has a per file object-to-handle
mapping that I could reuse for this.

Thanks,
Thomas

[RFCv3 03/14] drm: Add primary plane helpers

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> When we expose non-overlay planes to userspace, they will become
> accessible via standard userspace plane API's.  We should be able to
> handle the standard plane operations against primary planes in a generic
> way via the page flip handler and modeset handler.
> 
> Drivers that can program primary planes more efficiently, that want to
> use their own primary plane structure to track additional information,
> or that don't have the limitations assumed by the helpers are free to
> provide their own implementation of some or all of these handlers.
> 
> Signed-off-by: Matt Roper 

One thing I've noticed with planes is that we don't have any per-plane
size limits. Which will be annoying for cursors at least, but looking at
intel's hw history there are other planes with limits smaller than
dev->mode_config.max_widht/height.

I think as part of the universal plane work here we should add this to the
getplane ioctl (we can extend at the end with full backwards compat) and
use the max_width/height as default for primary/overlay planes and
cursor_width/height for cursor planes.

Probably there's more stuff userspace might be interested in (like stride
limits and alignment maybe), but that'd be a start at least.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 288 
> +++--
>  include/drm/drm_crtc.h |  81 +
>  2 files changed, 330 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0983996..db54ae9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1118,6 +1118,255 @@ void drm_plane_force_disable(struct drm_plane *plane)
>  }
>  EXPORT_SYMBOL(drm_plane_force_disable);
>  
> +/*
> + * Checks that the framebuffer is big enough for the CRTC viewport
> + * (x, y, hdisplay, vdisplay)
> + */
> +static int drm_crtc_check_viewport(const struct drm_crtc *crtc,
> +int x, int y,
> +const struct drm_display_mode *mode,
> +const struct drm_framebuffer *fb)
> +
> +{
> + int hdisplay, vdisplay;
> +
> + hdisplay = mode->hdisplay;
> + vdisplay = mode->vdisplay;
> +
> + if (drm_mode_is_stereo(mode)) {
> + struct drm_display_mode adjusted = *mode;
> +
> + drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
> + hdisplay = adjusted.crtc_hdisplay;
> + vdisplay = adjusted.crtc_vdisplay;
> + }
> +
> + if (crtc->invert_dimensions)
> + swap(hdisplay, vdisplay);
> +
> + if (hdisplay > fb->width ||
> + vdisplay > fb->height ||
> + x > fb->width - hdisplay ||
> + y > fb->height - vdisplay) {
> + DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport 
> %ux%u+%d+%d%s.\n",
> +   fb->width, fb->height, hdisplay, vdisplay, x, y,
> +   crtc->invert_dimensions ? " (inverted)" : "");
> + return -ENOSPC;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Returns the connectors currently associated with a CRTC.  This function
> + * should be called twice:  once with a NULL connector list to retrieve
> + * the list size, and once with the properly allocated list to be filled in.
> + */
> +static int get_connectors_for_crtc(struct drm_crtc *crtc,
> +struct drm_connector **connector_list,
> +int num_connectors)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_connector *connector;
> + int count = 0;
> +
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head)
> + if (connector->encoder && connector->encoder->crtc == crtc) {
> + if (connector_list != NULL && count < num_connectors)
> + *(connector_list++) = connector;
> +
> + count++;
> + }
> +
> + return count;
> +}
> +
> +/**
> + * drm_primary_helper_update() - Helper for primary plane update
> + * @plane: plane object to update
> + * @crtc: owning CRTC of owning plane
> + * @fb: framebuffer to flip onto plane
> + * @crtc_x: x offset of primary plane on crtc
> + * @crtc_y: y offset of primary plane on crtc
> + * @crtc_w: width of primary plane rectangle on crtc
> + * @crtc_h: height of primary plane rectangle on crtc
> + * @src_x: x offset of @fb for panning
> + * @src_y: y offset of @fb for panning
> + * @src_w: width of source rectangle in @fb
> + * @src_h: height of source rectangle in @fb
> + *
> + * Provides a default plane update handler for primary planes.  This is 
> handler
> + * is called in response to a userspace SetPlane operation on the plane with 
> a
> + * non-NULL framebuffer.  We call the driver's pageflip handler to update the
> + * framebuffer.
> + *
> + * SetPlane() on a primary plane of a disabled 

How to support various hardware blocks in drm driver

[Inki Dae]

2014-03-19 6:23 GMT+09:00 Dave Airlie :
> On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter  wrote:
>> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae  wrote:
>>> >> I think now drm_bridge couldn't do what we want for embedded systems
>>> >> as long as drm_encoder has drm_bridge.
>>> >> See the blow hardware pipeline,
>>> >> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>>> >> LVDS Bridge-LCD Panel
>>> >>
>>> >> In above hardware pipeline, Display controller is controlled by crtc,
>>> >> and Image Enhancement chip receives output from display controller.
>>> >> So the use of existing drm_bridge would be suitable to only bridge
>>> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement
>>> >> chip.
>>> >>
>>> >> For such hardware, drm_panel infrastructure is more reasonable to me,
>>> >> and that is why I try to integrate drm_panel and drm_bridge to one
>>> >> integrated framework which has infrastructure same as existing
>>> >> drm_panel.
>>> >> The important thing is to free this integrated framework from
>>> >> drm_encoder so that crtc device can also use this framework.
>>> >
>>> > Hm, what is this image enhancement chip? Is that some IP block on the
>>> > SoC? Is it optional? Can it be attached to different crtcs?
>>>
>>> In case of Exynos, this chip is in SoC, and can be only attached to
>>> one crtc, display controller. But I'm not sure other SoC have similar
>>> chip.
>>>
>>> >
>>> > I think we have similar things on intel hardware, but without details
>>> > on what it does and how it works I can't really say how to best expose
>>> > it to userspace and how to best handle it internally in the driver.
>>> > -Daniel
>>>
>>> Simply saying, the image enhancement chip can enhance image data from
>>> display controller, i.e. saturation enhancement, color reproduction,
>>> dithering, and so on.
>>> And this chip receives image data through hardware wired lines
>>> connected internally between display controller and this chip.
>>
>> To me this sounds like you simply need to expose all these capabilities to
>> userspace as crtc properties. Which addresses one part of this issue.
>>
>> The other side is how you are going to track this in the driver, and there
>> you can do whatever you want - just add a pointer/structure to the exynos
>> crtc structure for the display enhancement block.
>>
>> The MIPI DSI block would then be treated as a drm_encoder, and all the
>> later stages as drm_bridges up to the very last (the actual lvds panel)
>> which would be a simple drm_panel.
>>
>> I don't really see what additional complexity you need here. Especially
>> since this image enhancer is on your SoC (and I guess a samgsung IP block
>> not shared with any other SoC manufacture) you can easily keep the driver
>> code for it in the exynos driver. So really no need to have a generic
>> interface here.
>
> I'm with Daniel, this does sound like its just part of the "crtc"
> object, just write code in the driver
> to support it and tie it into the crtc.
>

That is really what I try to do just using generic framework, the
integrated drm_bridge framework. We have really been using drm_panel,
drm_bridge and maybe encoder_slave for this. But they are not perfect
yet so I am trying to enhance these frameworks.

Thanks,
Inki Dae

> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

How to support various hardware blocks in drm driver

[Inki Dae]

2014-03-19 13:07 GMT+09:00 Inki Dae :
> 2014-03-19 2:37 GMT+09:00 Daniel Vetter :
>> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae  wrote:
>>> >> I think now drm_bridge couldn't do what we want for embedded systems
>>> >> as long as drm_encoder has drm_bridge.
>>> >> See the blow hardware pipeline,
>>> >> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>>> >> LVDS Bridge-LCD Panel
>>> >>
>>> >> In above hardware pipeline, Display controller is controlled by crtc,
>>> >> and Image Enhancement chip receives output from display controller.
>>> >> So the use of existing drm_bridge would be suitable to only bridge
>>> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement
>>> >> chip.
>>> >>
>>> >> For such hardware, drm_panel infrastructure is more reasonable to me,
>>> >> and that is why I try to integrate drm_panel and drm_bridge to one
>>> >> integrated framework which has infrastructure same as existing
>>> >> drm_panel.
>>> >> The important thing is to free this integrated framework from
>>> >> drm_encoder so that crtc device can also use this framework.
>>> >
>>> > Hm, what is this image enhancement chip? Is that some IP block on the
>>> > SoC? Is it optional? Can it be attached to different crtcs?
>>>
>>> In case of Exynos, this chip is in SoC, and can be only attached to
>>> one crtc, display controller. But I'm not sure other SoC have similar
>>> chip.
>>>
>>> >
>>> > I think we have similar things on intel hardware, but without details
>>> > on what it does and how it works I can't really say how to best expose
>>> > it to userspace and how to best handle it internally in the driver.
>>> > -Daniel
>>>
>>> Simply saying, the image enhancement chip can enhance image data from
>>> display controller, i.e. saturation enhancement, color reproduction,
>>> dithering, and so on.
>>> And this chip receives image data through hardware wired lines
>>> connected internally between display controller and this chip.
>>
>> To me this sounds like you simply need to expose all these capabilities to
>> userspace as crtc properties. Which addresses one part of this issue.
>
> No, what I want is really not to expose some capabilities to
> suerspace. If you think so, there might be your missing point.
>
>>
>> The other side is how you are going to track this in the driver, and there
>> you can do whatever you want - just add a pointer/structure to the exynos
>> crtc structure for the display enhancement block.
>
> Hm.. that is what I try to do extending existing drm_panel and
> drm_bridge frameworks. As you may know, now existing drm_bridge could
> support only bridge device of encoder side.
> So now I am trying for this drm_bridge can support both sides of crtc
> and encoder.
>
>>
>> The MIPI DSI block would then be treated as a drm_encoder, and all the
>> later stages as drm_bridges up to the very last (the actual lvds panel)
>> which would be a simple drm_panel.
>>
>
> Existing drm_panel only supports real panel device, and existing
> drm_bridge only supports bridge device between encoder and panel.
> In here, the problem is that there can be other bridge devices between
> crtc and encoder. So crtc driver would want to control such bridge
> device in timely manner.
> How the crtc driver could control this bridge between crtc and encoder?
>
> See the below a example that is what I try to do for this,
>
> struct drm_bridge {   <- just change name from drm_hw_block to drm_bridge
> ...
> struct drm_panel *panel;<- existing drm_panel
> struct drm_lvds *lvds;<- existing drm_bridge
> struct drm_enhancer *enhander; < - new one
> ...
> };
>
> Or,
>
> struct drm_panel {<- existing drm_panel
>...
> };
>
> No change for drm_panel.
>
> struct drm_bridge {
> ...
> struct drm_lvds *lvds;   <- existing drm_bridge
> struct drm_enhancer *enhancer;   <- new one
> };
>
> My idea is to extend existing drm_bridge so that this drm_bridge could
> support both of them, one between crtc and encoder, and another one
> between encoder and panel.
>
> Display controller - bridge1 - mipi dsi - bridge2 - panel
>   /|\
>   /|\/|\
>|
>|  |
>   drm_enhancer   drm_lvds
>   drm_panel
>

Oops, sorry for broken diagram.

bridge1 -> drm_enhancer
bridge2 -> drm_lvds
panel -> drm_panel


> And now is just ready for supporting such bridge later. So this
> integrated drm_bridge would have drm_panel and drm_lvds. For Image
> Enhancer, later.
>
>> I don't really see what additional complexity you need here. Especially
>> since this image enhancer is on your SoC (and I guess a samgsung IP block
>> not shared with any other SoC manufacture

[Intel-gfx] [RFCv3 11/14] drm/i915: Intel-specific primary plane handling

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote:
> Intel hardware allows the primary plane to be disabled independently of
> the CRTC.  Provide custom primary plane handling to allow this.
> 
> Cc: Intel Graphics Development 
> Signed-off-by: Matt Roper 

Overall this is imo a new feature since it exposes primary plane disabling
to userspace. Which means I want a crc based igt for this. Two interesting
cases imo:

1) Partially visible primary plane behind an overlay plane. Disabling it
should change those areas from the primary plane to grey or something, so
easy to check with CRCs.

2) Primary plane + cursor, disable primary plane. Then check that the
cursor is still working. Same for overlay sprites.

At least on all currently supported platforms we don't have unified planes
in the hardware, so imo it's worth to check that this works properly.

> ---
>  drivers/gpu/drm/i915/intel_display.c | 132 
> ++-
>  drivers/gpu/drm/i915/intel_drv.h |   1 +
>  2 files changed, 130 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 849a241..7d6878b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -39,6 +39,7 @@
>  #include "i915_trace.h"
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  static void intel_increase_pllclock(struct drm_crtc *crtc);
> @@ -10589,19 +10590,144 @@ static void intel_shared_dpll_init(struct 
> drm_device *dev)
>   BUG_ON(dev_priv->num_shared_dpll > I915_NUM_PLLS);
>  }
>  
> +static int
> +intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
> +  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> +  unsigned int crtc_w, unsigned int crtc_h,
> +  uint32_t src_x, uint32_t src_y,
> +  uint32_t src_w, uint32_t src_h)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct drm_framebuffer *tmpfb;
> + struct drm_rect dest = {
> + .x1 = crtc_x,
> + .y1 = crtc_y,
> + .x2 = crtc_x + crtc_w,
> + .y2 = crtc_y + crtc_h,
> + };
> + struct drm_rect clip = {
> + .x2 = crtc->mode.hdisplay,
> + .y2 = crtc->mode.vdisplay,
> + };
> + int ret;
> +
> + /* setplane API takes shifted source rectangle values; unshift them */
> + src_x >>= 16;
> + src_y >>= 16;
> + src_w >>= 16;
> + src_h >>= 16;

Similar comments as with the generic helper: We need to check the scaling
constraints here better. Looks like a good opportunity to extract the
logic into some drm_rect helpers maybe?

> +
> + /*
> +  * Current hardware can't reposition the primary plane or scale it
> +  * (although this could change in the future).
> +  */
> + drm_rect_intersect(&dest, &clip);
> + if (dest.x1 != 0 || dest.y1 != 0 ||
> + dest.x2 != crtc->mode.hdisplay || dest.y2 != crtc->mode.vdisplay) {
> + DRM_DEBUG_KMS("Primary plane must cover entire CRTC\n");
> + return -EINVAL;
> + }
> +
> + if (crtc_w != src_w || crtc_h != src_h) {
> + DRM_DEBUG_KMS("Can't scale primary plane\n");
> + return -EINVAL;
> + }
> +
> + /*
> +  * pipe_set_base() adjusts crtc->primary->fb; however the DRM setplane
> +  * code that called us expects to handle the framebuffer update and
> +  * reference counting; save and restore the current fb before
> +  * calling it.
> +  */
> + tmpfb = plane->fb;
> + ret = intel_pipe_set_base(crtc, src_x, src_y, fb);
> + if (ret)
> + return ret;
> + plane->fb = tmpfb;
> +
> + if (!intel_crtc->primary_enabled)
> + intel_enable_primary_hw_plane(dev_priv, intel_crtc->plane,
> +   intel_crtc->pipe);
> +
> + return 0;
> +}
> +
> +static int
> +intel_primary_plane_disable(struct drm_plane *plane)
> +{
> + struct drm_device *dev = plane->dev;
> + drm_i915_private_t *dev_priv = dev->dev_private;
> + struct intel_plane *intel_plane = to_intel_plane(plane);
> + struct intel_crtc *intel_crtc;
> +
> + if (!plane->fb)
> + return 0;
> +
> + if (WARN_ON(!plane->crtc))
> + return -EINVAL;
> +
> + intel_crtc = to_intel_crtc(plane->crtc);
> + if (intel_crtc->primary_enabled)
> + intel_disable_primary_hw_plane(dev_priv, intel_plane->plane,
> +intel_plane->pipe);
> +
> + return 0;
> +}
> +
> +static void intel_primary_plane_destroy(struct drm_plane *plane)
> +{
> + struct intel_plane *intel_plane = to_intel_plane(plane);
> + intel_primary_plane_disable(plane);
> + drm_plane_cleanu

How to support various hardware blocks in drm driver

[Inki Dae]

2014-03-19 2:37 GMT+09:00 Daniel Vetter :
> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae  wrote:
>> >> I think now drm_bridge couldn't do what we want for embedded systems
>> >> as long as drm_encoder has drm_bridge.
>> >> See the blow hardware pipeline,
>> >> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>> >> LVDS Bridge-LCD Panel
>> >>
>> >> In above hardware pipeline, Display controller is controlled by crtc,
>> >> and Image Enhancement chip receives output from display controller.
>> >> So the use of existing drm_bridge would be suitable to only bridge
>> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement
>> >> chip.
>> >>
>> >> For such hardware, drm_panel infrastructure is more reasonable to me,
>> >> and that is why I try to integrate drm_panel and drm_bridge to one
>> >> integrated framework which has infrastructure same as existing
>> >> drm_panel.
>> >> The important thing is to free this integrated framework from
>> >> drm_encoder so that crtc device can also use this framework.
>> >
>> > Hm, what is this image enhancement chip? Is that some IP block on the
>> > SoC? Is it optional? Can it be attached to different crtcs?
>>
>> In case of Exynos, this chip is in SoC, and can be only attached to
>> one crtc, display controller. But I'm not sure other SoC have similar
>> chip.
>>
>> >
>> > I think we have similar things on intel hardware, but without details
>> > on what it does and how it works I can't really say how to best expose
>> > it to userspace and how to best handle it internally in the driver.
>> > -Daniel
>>
>> Simply saying, the image enhancement chip can enhance image data from
>> display controller, i.e. saturation enhancement, color reproduction,
>> dithering, and so on.
>> And this chip receives image data through hardware wired lines
>> connected internally between display controller and this chip.
>
> To me this sounds like you simply need to expose all these capabilities to
> userspace as crtc properties. Which addresses one part of this issue.

No, what I want is really not to expose some capabilities to
suerspace. If you think so, there might be your missing point.

>
> The other side is how you are going to track this in the driver, and there
> you can do whatever you want - just add a pointer/structure to the exynos
> crtc structure for the display enhancement block.

Hm.. that is what I try to do extending existing drm_panel and
drm_bridge frameworks. As you may know, now existing drm_bridge could
support only bridge device of encoder side.
So now I am trying for this drm_bridge can support both sides of crtc
and encoder.

>
> The MIPI DSI block would then be treated as a drm_encoder, and all the
> later stages as drm_bridges up to the very last (the actual lvds panel)
> which would be a simple drm_panel.
>

Existing drm_panel only supports real panel device, and existing
drm_bridge only supports bridge device between encoder and panel.
In here, the problem is that there can be other bridge devices between
crtc and encoder. So crtc driver would want to control such bridge
device in timely manner.
How the crtc driver could control this bridge between crtc and encoder?

See the below a example that is what I try to do for this,

struct drm_bridge {   <- just change name from drm_hw_block to drm_bridge
...
struct drm_panel *panel;<- existing drm_panel
struct drm_lvds *lvds;<- existing drm_bridge
struct drm_enhancer *enhander; < - new one
...
};

Or,

struct drm_panel {<- existing drm_panel
   ...
};

No change for drm_panel.

struct drm_bridge {
...
struct drm_lvds *lvds;   <- existing drm_bridge
struct drm_enhancer *enhancer;   <- new one
};

My idea is to extend existing drm_bridge so that this drm_bridge could
support both of them, one between crtc and encoder, and another one
between encoder and panel.

Display controller - bridge - mipi dsi - bridge - panel
  /|\
  /|\/|\
   |
   |  |
  drm_enhancer   drm_lvds
  drm_panel

And now is just ready for supporting such bridge later. So this
integrated drm_bridge would have drm_panel and drm_lvds. For Image
Enhancer, later.

> I don't really see what additional complexity you need here. Especially
> since this image enhancer is on your SoC (and I guess a samgsung IP block
> not shared with any other SoC manufacture) you can easily keep the driver
> code for it in the exynos driver. So really no need to have a generic
> interface here.

Yes, that might be the point. As I already mentioned, I'm not sure
this device exists only on Exynos SoC. But I guess there could be
other SoC with image enhancer now or later.

To other 

[Bug 76297] open source radeon drivers for old graphics cards crash the system while booting kernels 3.12+

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

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

--- Comment #5 from Alex Deucher  ---
Can you use git to bisect and identify what commit broke your system?

-- 
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/20140319/34930438/attachment.html>

[Intel-gfx] [RFCv3 10/14] drm/i915: Rename similar plane functions to avoid confusion

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:55PM -0700, Matt Roper wrote:
> The name 'update_plane' was used both for the primary plane functions in
> intel_display.c and the sprite/overlay functions in intel_sprite.c.
> Rename the primary plane functions to 'update_primary_plane' to avoid
> confusion.
> 
> On a similar note, intel_display.c already had a function called
> intel_disable_primary_plane() that programs the hardware to disable a
> pipe's primary plane.  When we hook up primary planes through the DRM
> plane interface, one of the natural handler names will be
> intel_primary_plane_disable(), which is very similar.  To avoid
> confusion, rename the existing intel_disable_primary_plane() to
> intel_disable_primary_hw_plane() to make the two names a little more
> distinct.
> 
> Cc: Intel Graphics Development 
> Signed-off-by: Matt Roper 

Hah, here's the reason why doing a crtc->fb -> crtc->primary->fb flagday
isn't good ;-) Wanted to pull this in since I like it, and it conflicted.

Fixed up and merged to dinq, thanks.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  5 +--
>  drivers/gpu/drm/i915/intel_display.c | 60 
> 
>  2 files changed, 36 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 70fbe90..a937711 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -462,8 +462,9 @@ struct drm_i915_display_funcs {
> struct drm_framebuffer *fb,
> struct drm_i915_gem_object *obj,
> uint32_t flags);
> - int (*update_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
> - int x, int y);
> + int (*update_primary_plane)(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + int x, int y);
>   void (*hpd_irq_setup)(struct drm_device *dev);
>   /* clock updates for mode set */
>   /* cursor updates */
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c2f3730..849a241 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1872,15 +1872,15 @@ void intel_flush_primary_plane(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * intel_enable_primary_plane - enable the primary plane on a given pipe
> + * intel_enable_primary_hw_plane - enable the primary plane on a given pipe
>   * @dev_priv: i915 private structure
>   * @plane: plane to enable
>   * @pipe: pipe being fed
>   *
>   * Enable @plane on @pipe, making sure that @pipe is running first.
>   */
> -static void intel_enable_primary_plane(struct drm_i915_private *dev_priv,
> -enum plane plane, enum pipe pipe)
> +static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
> +   enum plane plane, enum pipe pipe)
>  {
>   struct intel_crtc *intel_crtc =
>   to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> @@ -1905,15 +1905,15 @@ static void intel_enable_primary_plane(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * intel_disable_primary_plane - disable the primary plane
> + * intel_disable_primary_hw_plane - disable the primary hardware plane
>   * @dev_priv: i915 private structure
>   * @plane: plane to disable
>   * @pipe: pipe consuming the data
>   *
>   * Disable @plane; should be an independent operation.
>   */
> -static void intel_disable_primary_plane(struct drm_i915_private *dev_priv,
> - enum plane plane, enum pipe pipe)
> +static void intel_disable_primary_hw_plane(struct drm_i915_private *dev_priv,
> +enum plane plane, enum pipe pipe)
>  {
>   struct intel_crtc *intel_crtc =
>   to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> @@ -2153,8 +2153,9 @@ static void intel_find_plane_obj(struct intel_crtc 
> *intel_crtc,
>   }
>  }
>  
> -static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer 
> *fb,
> -  int x, int y)
> +static int i9xx_update_primary_plane(struct drm_crtc *crtc,
> +  struct drm_framebuffer *fb,
> +  int x, int y)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -2253,8 +2254,9 @@ static int i9xx_update_plane(struct drm_crtc *crtc, 
> struct drm_framebuffer *fb,
>   return 0;
>  }
>  
> -static int ironlake_update_plane(struct drm_crtc *crtc,
> -  struct drm_framebuffer *fb, int x, int y)
> +static int ironlake_update_primary_plane(struct drm_crtc *crtc,
> +  struct drm_framebuffer *fb,
> +  int x, int y)
>  {
>   

[RFCv3 08/14] drm: Replace crtc fb with primary plane fb (v2)

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:53PM -0700, Matt Roper wrote:
> Now that CRTC's have a primary plane, there's no need to track the
> framebuffer in the CRTC.  Replace all references to the CRTC fb
> with the primary plane's fb.
> 
> Also note that this simplifies framebuffer removal slightly; we no
> longer need to scan all CRTC's and disable the ones that were using the
> framebuffer since the existing loop over all planes will take care
> of disabling the primary plane (and on most hardware, the CRTC by
> extension).
> 
> v2: Fixup several lingering crtc->fb instances that were missed in the
> first patch iteration.
> 
> Tested-by: Rob Clark 
> Signed-off-by: Matt Roper 

Giant patch again, and I don't think there's any sane way we can avoid
this big sed job. Put I think we can make it less intrusive.

First: Have you looked into cocinelle to do this? I'm not sure whether
cocinelle is sufficiently type aware, but the upside of using it is that
it's much easier to regenerate the patch.

In any case I think we need to split this into the usual 3 phases to avoid
flag days:

1) Switch to crtc->primary->fb all over the core, but keep crtc->fb fully
functional. I.e. update it before calling into drivers and use that to
update crtc->primary->fb on return (e.g. in the pageflip ioctl).

2) Switch drivers over to look at crtc->primary->fb. This way we can even
split up the patch into per-driver patches which gives driver maintainers
more wiggle room.

3) Kill crtc->fb.

Steps 2&3 don't block merging of the universal planes support at all. So
we could get the core support in all early for 3.16, then let driver
maintainers pick up patche for 2 and shortly before the 3.16 merge window
opens send a pull request with all the stragglers and step 3.

No comments on the actual patch, the few functional changes hidden in the
massive diff looked ok. But hard to review properly ;-)

Cheers, Daniel

> ---
>  drivers/gpu/drm/ast/ast_mode.c   |  12 +--
>  drivers/gpu/drm/bochs/bochs_kms.c|   4 +-
>  drivers/gpu/drm/cirrus/cirrus_mode.c |  10 +-
>  drivers/gpu/drm/drm_crtc.c   |  56 --
>  drivers/gpu/drm/drm_crtc_helper.c|  21 ++--
>  drivers/gpu/drm/drm_fb_helper.c  |   6 +-
>  drivers/gpu/drm/gma500/cdv_intel_display.c   |   2 +-
>  drivers/gpu/drm/gma500/cdv_intel_dp.c|   2 +-
>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c  |   3 +-
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c  |   2 +-
>  drivers/gpu/drm/gma500/gma_display.c |  17 ++--
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c|   2 +-
>  drivers/gpu/drm/gma500/mdfld_intel_display.c |  17 ++--
>  drivers/gpu/drm/gma500/oaktrail_crtc.c   |  13 +--
>  drivers/gpu/drm/gma500/psb_intel_display.c   |   2 +-
>  drivers/gpu/drm/gma500/psb_intel_lvds.c  |   2 +-
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c  |   2 +-
>  drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
>  drivers/gpu/drm/i915/i915_irq.c  |   4 +-
>  drivers/gpu/drm/i915/intel_display.c | 147 
> ++-
>  drivers/gpu/drm/i915/intel_dp.c  |   5 +-
>  drivers/gpu/drm/i915/intel_fbdev.c   |   6 +-
>  drivers/gpu/drm/i915/intel_overlay.c |   4 +-
>  drivers/gpu/drm/i915/intel_pm.c  |  36 +++
>  drivers/gpu/drm/mgag200/mgag200_mode.c   |  28 ++---
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c |  28 ++---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c |  22 ++--
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c  |  20 ++--
>  drivers/gpu/drm/nouveau/dispnv04/dfp.c   |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_display.c|   8 +-
>  drivers/gpu/drm/nouveau/nv50_display.c   |  17 ++--
>  drivers/gpu/drm/qxl/qxl_display.c|  11 +-
>  drivers/gpu/drm/radeon/atombios_crtc.c   |  20 ++--
>  drivers/gpu/drm/radeon/r100.c|   4 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c   |   2 +-
>  drivers/gpu/drm/radeon/radeon_device.c   |   3 +-
>  drivers/gpu/drm/radeon/radeon_display.c  |   4 +-
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c  |  16 +--
>  drivers/gpu/drm/udl/udl_modeset.c|   2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  14 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |   8 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |   8 +-
>  include/drm/drm_crtc.h   |   3 -
>  43 files changed, 300 insertions(+), 299 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 44f0d32..bd1e156 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -81,7 +81,7 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc, 
> struct drm_display_mo
>   u32 refresh_rate_index = 0, mode_id, color_index, refresh_rate;
>   u32 hborder, vborder;
>  
> - switch (crtc->fb->bits_per_pixel) {
> + switch (crtc->primary->fb->bits_per_pixel) {
>  

[RFCv3 04/14] drm/exynos: Restrict plane loops to only operate on overlay planes

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
> Before we add additional types of planes to the DRM plane list, ensure
> that existing loops over all planes continue to operate only on
> "overlay" planes and ignore primary & cursor planes.
> 
> Cc: Inki Dae 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> index 06f1b2a..2fa2685 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> @@ -127,6 +127,9 @@ static void disable_plane_to_crtc(struct drm_device *dev,
>* (encoder->crtc)
>*/
>   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)

I think a drm_for_each_legacy_plane iteration helper would be neat for
this one and the following i915 patch.
-Daniel

> + continue;
> +
>   if (plane->crtc == old_crtc) {
>   /*
>* do not change below call order.
> @@ -247,6 +250,9 @@ static void exynos_drm_encoder_disable(struct drm_encoder 
> *encoder)
>  
>   /* all planes connected to this encoder should be also disabled. */
>   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> + if (plane->type != DRM_PLANE_TYPE_OVERLAY)
> + continue;
> +
>   if (plane->crtc == encoder->crtc)
>   plane->funcs->disable_plane(plane);
>   }
> -- 
> 1.8.5.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFCv3 03/14] drm: Add primary plane helpers

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> When we expose non-overlay planes to userspace, they will become
> accessible via standard userspace plane API's.  We should be able to
> handle the standard plane operations against primary planes in a generic
> way via the page flip handler and modeset handler.
> 
> Drivers that can program primary planes more efficiently, that want to
> use their own primary plane structure to track additional information,
> or that don't have the limitations assumed by the helpers are free to
> provide their own implementation of some or all of these handlers.
> 
> Signed-off-by: Matt Roper 
> ---

One more below ...

> +/**
> + * drm_primary_helper_disable() - Helper for primary plane disable
> + * @plane: plane to disable
> + *
> + * Provides a default plane disable handler for primary planes.  This is 
> handler
> + * is called in response to a userspace SetPlane operation on the plane with 
> a
> + * NULL framebuffer parameter.  We call the driver's modeset handler with a 
> NULL
> + * framebuffer to disable the CRTC.
> + *
> + * Note that some hardware may be able to disable the primary plane without
> + * disabling the whole CRTC.  Drivers for such hardware should provide their
> + * own disable handler that disables just the primary plane (and they'll 
> likely
> + * need to provide their own update handler as well to properly re-enable a
> + * disabled primary plane).
> + *
> + * RETURNS:
> + * Zero on success, error code on failure
> + */
> +int drm_primary_helper_disable(struct drm_plane *plane)
> +{
> + struct drm_mode_set set = {
> + .crtc = plane->crtc,
> + .fb = NULL,
> + };
> +
> + if (plane->crtc == NULL || plane->fb == NULL)
> + /* Already disabled */
> + return 0;

I think we should have a check here if any other plane is enabled
(including the cursor plane), and fail the plane disabling with -EBUSY.
Otherwise new userspace has no way to figure out whether the driver is
updated already or not.

> +
> + return plane->crtc->funcs->set_config(&set);

Again I think you need to use set_config_internal to have correct fb
refcounting.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH RFC] drm: Make the drm_vma_manager authentication mechanism a bit more versatile

[David Herrmann]

Hi

On Wed, Mar 19, 2014 at 12:33 PM, Thomas Hellstrom
 wrote:
> By handing the authentication mechanism tokens in the form of const void
> pointers instead of struct file pointers, drivers are free to provide whatever
> file pointers they find appropriate. The pointers are never dereferenced in
> the drm_vma_manager so that shouldn't be a problem.
>
> As an example, the vmwgfx driver would like to provide struct ttm_object_file
> pointers.

I guess a "struct file*" pointer in tmm_object_file would be easier,
but if that reverse dependency is not wanted, I'm fine with that. Just
make sure you don't use drm_vma_node_verify_access for TTM directly as
TTM passes in a file pointer.

Reviewed-by: David Herrmann 

Thanks
David

> Signed-off-by: Thomas Hellstrom 
> ---
>  drivers/gpu/drm/drm_vma_manager.c |   22 +++---
>  include/drm/drm_vma_manager.h |   12 ++--
>  2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vma_manager.c 
> b/drivers/gpu/drm/drm_vma_manager.c
> index 63b4712..93676c1 100644
> --- a/drivers/gpu/drm/drm_vma_manager.c
> +++ b/drivers/gpu/drm/drm_vma_manager.c
> @@ -291,24 +291,24 @@ EXPORT_SYMBOL(drm_vma_offset_remove);
>  /**
>   * drm_vma_node_allow - Add open-file to list of allowed users
>   * @node: Node to modify
> - * @filp: Open file to add
> + * @filp: Authentication token (typically pointer to open file) to add
>   *
> - * Add @filp to the list of allowed open-files for this node. If @filp is
> - * already on this list, the ref-count is incremented.
> + * Add @filp to the list of allowed authentication tokens for this node.
> + * If @filp is already on this list, the ref-count is incremented.
>   *
>   * The list of allowed-users is preserved across drm_vma_offset_add() and
>   * drm_vma_offset_remove() calls. You may even call it if the node is 
> currently
>   * not added to any offset-manager.
>   *
> - * You must remove all open-files the same number of times as you added them
> - * before destroying the node. Otherwise, you will leak memory.
> + * You must remove all authentication tokens the same number of times as you
> + * added them before destroying the node. Otherwise, you will leak memory.
>   *
>   * This is locked against concurrent access internally.
>   *
>   * RETURNS:
>   * 0 on success, negative error code on internal failure (out-of-mem)
>   */
> -int drm_vma_node_allow(struct drm_vma_offset_node *node, struct file *filp)
> +int drm_vma_node_allow(struct drm_vma_offset_node *node, const void *filp)
>  {
> struct rb_node **iter;
> struct rb_node *parent = NULL;
> @@ -360,7 +360,7 @@ EXPORT_SYMBOL(drm_vma_node_allow);
>  /**
>   * drm_vma_node_revoke - Remove open-file from list of allowed users
>   * @node: Node to modify
> - * @filp: Open file to remove
> + * @filp: Authentication token to remove
>   *
>   * Decrement the ref-count of @filp in the list of allowed open-files on 
> @node.
>   * If the ref-count drops to zero, remove @filp from the list. You must call
> @@ -370,7 +370,7 @@ EXPORT_SYMBOL(drm_vma_node_allow);
>   *
>   * If @filp is not on the list, nothing is done.
>   */
> -void drm_vma_node_revoke(struct drm_vma_offset_node *node, struct file *filp)
> +void drm_vma_node_revoke(struct drm_vma_offset_node *node, const void *filp)
>  {
> struct drm_vma_offset_file *entry;
> struct rb_node *iter;
> @@ -400,10 +400,10 @@ EXPORT_SYMBOL(drm_vma_node_revoke);
>  /**
>   * drm_vma_node_is_allowed - Check whether an open-file is granted access
>   * @node: Node to check
> - * @filp: Open-file to check for
> + * @filp: Authentication token to check for
>   *
>   * Search the list in @node whether @filp is currently on the list of allowed
> - * open-files (see drm_vma_node_allow()).
> + * authentication tokens (see drm_vma_node_allow()).
>   *
>   * This is locked against concurrent access internally.
>   *
> @@ -411,7 +411,7 @@ EXPORT_SYMBOL(drm_vma_node_revoke);
>   * true iff @filp is on the list
>   */
>  bool drm_vma_node_is_allowed(struct drm_vma_offset_node *node,
> -struct file *filp)
> +const void *filp)
>  {
> struct drm_vma_offset_file *entry;
> struct rb_node *iter;
> diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
> index c18a593..d7ff1e5 100644
> --- a/include/drm/drm_vma_manager.h
> +++ b/include/drm/drm_vma_manager.h
> @@ -33,7 +33,7 @@
>
>  struct drm_vma_offset_file {
> struct rb_node vm_rb;
> -   struct file *vm_filp;
> +   const void *vm_filp;
> unsigned long vm_count;
>  };
>
> @@ -65,10 +65,10 @@ int drm_vma_offset_add(struct drm_vma_offset_manager *mgr,
>  void drm_vma_offset_remove(struct drm_vma_offset_manager *mgr,
>struct drm_vma_offset_node *node);
>
> -int drm_vma_node_allow(struct drm_vma_offset_node *node, struct file *filp);
> -void drm_vma_node_revoke(struct drm_vma_offset_node *nod

[RFCv3 07/14] drm: Specify primary plane at CRTC initialization (v2)

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:52PM -0700, Matt Roper wrote:
> Add primary plane as a parameter to drm_crtc_init() and update all
> existing DRM drivers to use a helper-provided primary plane.
> 
> v2: Update msm & omap drivers to use existing "private" planes as primary
> planes instead of helper  [Rob Clark]
> 
> Tested-by: Rob Clark 
> Signed-off-by: Matt Roper 

Again massive pile of changes all over drivers. I think we need to have
again two functions to pull this off and let drivers transition at their
own pace. For this I'd suggest

1) Do a s/drm_crtc_init/drm_legacy_crtc_init/ sed job over the entire
tree, get this patch merged into drm-next this week for 3.15. This will
cause some major havoc with the imx staging changes, so maybe do that
patch on top of linux-next and merge it shortly before -rc1. We need to
coordinate with Dave Airlie about this.

Plan be would be to add a new drm_brave_new_world_crtc_init, and I just
can't come up with a good name. Maybe drm_universal_planes_crtc_init or
something like that. Ugly in any case.

I think good naming suggestings here would be awesome, since it would
allow us to avoid the big flag-day patch above.

2) Add sensible default behaviour to drm_crtc_init/drm_legacy_crtc_init,
which allows drivers to transition to explicit primary planes at easy.

3) Transition drivers, but only where needed.

I didn't really spot anything in the patch itself.

Cheers, Daniel

> ---
>  drivers/gpu/drm/armada/armada_crtc.c   | 4 +++-
>  drivers/gpu/drm/ast/ast_mode.c | 4 +++-
>  drivers/gpu/drm/bochs/bochs_kms.c  | 4 +++-
>  drivers/gpu/drm/cirrus/cirrus_mode.c   | 4 +++-
>  drivers/gpu/drm/drm_crtc.c | 9 -
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 4 +++-
>  drivers/gpu/drm/gma500/psb_intel_display.c | 4 +++-
>  drivers/gpu/drm/i915/intel_display.c   | 4 +++-
>  drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +++-
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   | 5 -
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c   | 5 -
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c| 4 +++-
>  drivers/gpu/drm/nouveau/nv50_display.c | 4 +++-
>  drivers/gpu/drm/omapdrm/omap_crtc.c| 2 +-
>  drivers/gpu/drm/qxl/qxl_display.c  | 4 +++-
>  drivers/gpu/drm/radeon/radeon_display.c| 4 +++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +++-
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  | 3 ++-
>  drivers/gpu/drm/tegra/dc.c | 4 +++-
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 4 +++-
>  drivers/gpu/drm/udl/udl_modeset.c  | 4 +++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 4 +++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   | 4 +++-
>  drivers/staging/imx-drm/imx-drm-core.c | 4 +++-
>  include/drm/drm_crtc.h | 5 +
>  25 files changed, 81 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index d8e3982..0a14d24 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -1030,6 +1030,7 @@ int armada_drm_crtc_create(struct drm_device *dev, 
> unsigned num,
>  {
>   struct armada_private *priv = dev->dev_private;
>   struct armada_crtc *dcrtc;
> + struct drm_plane *primary;
>   void __iomem *base;
>   int ret;
>  
> @@ -1086,7 +1087,8 @@ int armada_drm_crtc_create(struct drm_device *dev, 
> unsigned num,
>  
>   priv->dcrtc[dcrtc->num] = dcrtc;
>  
> - drm_crtc_init(dev, &dcrtc->crtc, &armada_crtc_funcs);
> + primary = drm_primary_helper_create_plane(dev);
> + drm_crtc_init(dev, &dcrtc->crtc, primary, &armada_crtc_funcs);
>   drm_crtc_helper_add(&dcrtc->crtc, &armada_crtc_helper_funcs);
>  
>   drm_object_attach_property(&dcrtc->crtc.base, priv->csc_yuv_prop,
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index cca063b..44f0d32 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -626,13 +626,15 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
>  static int ast_crtc_init(struct drm_device *dev)
>  {
>   struct ast_crtc *crtc;
> + struct drm_plane *primary;
>   int i;
>  
>   crtc = kzalloc(sizeof(struct ast_crtc), GFP_KERNEL);
>   if (!crtc)
>   return -ENOMEM;
>  
> - drm_crtc_init(dev, &crtc->base, &ast_crtc_funcs);
> + primary = drm_primary_helper_create_plane(dev);
> + drm_crtc_init(dev, &crtc->base, primary, &ast_crtc_funcs);
>   drm_mode_crtc_set_gamma_size(&crtc->base, 256);
>   drm_crtc_helper_add(&crtc->base, &ast_crtc_helper_funcs);
>  
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 62ec7d4..182f5c9 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -129,8 +129,10 @@ static void bochs_crtc_init(struct drm_device *dev)
>  {
>   struct bochs_device *bochs =

[PATCH RFC] drm: Make the drm_vma_manager authentication mechanism a bit more versatile

[Thomas Hellstrom]

By handing the authentication mechanism tokens in the form of const void
pointers instead of struct file pointers, drivers are free to provide whatever
file pointers they find appropriate. The pointers are never dereferenced in
the drm_vma_manager so that shouldn't be a problem.

As an example, the vmwgfx driver would like to provide struct ttm_object_file
pointers.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/drm_vma_manager.c |   22 +++---
 include/drm/drm_vma_manager.h |   12 ++--
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_vma_manager.c 
b/drivers/gpu/drm/drm_vma_manager.c
index 63b4712..93676c1 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -291,24 +291,24 @@ EXPORT_SYMBOL(drm_vma_offset_remove);
 /**
  * drm_vma_node_allow - Add open-file to list of allowed users
  * @node: Node to modify
- * @filp: Open file to add
+ * @filp: Authentication token (typically pointer to open file) to add
  *
- * Add @filp to the list of allowed open-files for this node. If @filp is
- * already on this list, the ref-count is incremented.
+ * Add @filp to the list of allowed authentication tokens for this node.
+ * If @filp is already on this list, the ref-count is incremented.
  *
  * The list of allowed-users is preserved across drm_vma_offset_add() and
  * drm_vma_offset_remove() calls. You may even call it if the node is currently
  * not added to any offset-manager.
  *
- * You must remove all open-files the same number of times as you added them
- * before destroying the node. Otherwise, you will leak memory.
+ * You must remove all authentication tokens the same number of times as you
+ * added them before destroying the node. Otherwise, you will leak memory.
  *
  * This is locked against concurrent access internally.
  *
  * RETURNS:
  * 0 on success, negative error code on internal failure (out-of-mem)
  */
-int drm_vma_node_allow(struct drm_vma_offset_node *node, struct file *filp)
+int drm_vma_node_allow(struct drm_vma_offset_node *node, const void *filp)
 {
struct rb_node **iter;
struct rb_node *parent = NULL;
@@ -360,7 +360,7 @@ EXPORT_SYMBOL(drm_vma_node_allow);
 /**
  * drm_vma_node_revoke - Remove open-file from list of allowed users
  * @node: Node to modify
- * @filp: Open file to remove
+ * @filp: Authentication token to remove
  *
  * Decrement the ref-count of @filp in the list of allowed open-files on @node.
  * If the ref-count drops to zero, remove @filp from the list. You must call
@@ -370,7 +370,7 @@ EXPORT_SYMBOL(drm_vma_node_allow);
  *
  * If @filp is not on the list, nothing is done.
  */
-void drm_vma_node_revoke(struct drm_vma_offset_node *node, struct file *filp)
+void drm_vma_node_revoke(struct drm_vma_offset_node *node, const void *filp)
 {
struct drm_vma_offset_file *entry;
struct rb_node *iter;
@@ -400,10 +400,10 @@ EXPORT_SYMBOL(drm_vma_node_revoke);
 /**
  * drm_vma_node_is_allowed - Check whether an open-file is granted access
  * @node: Node to check
- * @filp: Open-file to check for
+ * @filp: Authentication token to check for
  *
  * Search the list in @node whether @filp is currently on the list of allowed
- * open-files (see drm_vma_node_allow()).
+ * authentication tokens (see drm_vma_node_allow()).
  *
  * This is locked against concurrent access internally.
  *
@@ -411,7 +411,7 @@ EXPORT_SYMBOL(drm_vma_node_revoke);
  * true iff @filp is on the list
  */
 bool drm_vma_node_is_allowed(struct drm_vma_offset_node *node,
-struct file *filp)
+const void *filp)
 {
struct drm_vma_offset_file *entry;
struct rb_node *iter;
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index c18a593..d7ff1e5 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -33,7 +33,7 @@

 struct drm_vma_offset_file {
struct rb_node vm_rb;
-   struct file *vm_filp;
+   const void *vm_filp;
unsigned long vm_count;
 };

@@ -65,10 +65,10 @@ int drm_vma_offset_add(struct drm_vma_offset_manager *mgr,
 void drm_vma_offset_remove(struct drm_vma_offset_manager *mgr,
   struct drm_vma_offset_node *node);

-int drm_vma_node_allow(struct drm_vma_offset_node *node, struct file *filp);
-void drm_vma_node_revoke(struct drm_vma_offset_node *node, struct file *filp);
+int drm_vma_node_allow(struct drm_vma_offset_node *node, const void *filp);
+void drm_vma_node_revoke(struct drm_vma_offset_node *node, const void *filp);
 bool drm_vma_node_is_allowed(struct drm_vma_offset_node *node,
-struct file *filp);
+const void *filp);

 /**
  * drm_vma_offset_exact_lookup() - Look up node by exact address
@@ -239,7 +239,7 @@ static inline void drm_vma_node_unmap(struct 
drm_vma_offset_node *node,
 /**
  * drm_vma_node_verify_access() - Access verification h

[RFCv3 06/14] drm: Add plane type property

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:51PM -0700, Matt Roper wrote:
> Add a plane type property to allow userspace to distinguish plane types.
> The type of the plane will now be established at drm_plane_init() time
> (replacing the 'priv' parameter previously used).
> 
> Signed-off-by: Matt Roper 

Lots of churn here over all drivers. Can't we just do a sane default
behaviour for drm_plane_init (i.e. overlay planes) and add a new
drm_universal_plane_init with the full powers?

That way the transition is easier to handle and drivers can opt-in at
their own pace and as needed.
-Daniel

> ---
>  drivers/gpu/drm/armada/armada_overlay.c|  3 +-
>  drivers/gpu/drm/drm_crtc.c | 65 
> --
>  drivers/gpu/drm/exynos/exynos_drm_plane.c  |  4 +-
>  drivers/gpu/drm/i915/intel_sprite.c|  2 +-
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c  |  4 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c  |  4 +-
>  drivers/gpu/drm/nouveau/dispnv04/overlay.c |  4 +-
>  drivers/gpu/drm/omapdrm/omap_plane.c   |  4 +-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c|  3 +-
>  drivers/gpu/drm/shmobile/shmob_drm_plane.c |  2 +-
>  drivers/gpu/drm/tegra/dc.c |  3 +-
>  drivers/staging/imx-drm/ipuv3-plane.c  |  4 +-
>  include/drm/drm_crtc.h |  3 +-
>  13 files changed, 70 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index c5b06fd..ef68c42 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -444,7 +444,8 @@ int armada_overlay_plane_create(struct drm_device *dev, 
> unsigned long crtcs)
> dplane);
>  
>   drm_plane_init(dev, &dplane->base, crtcs, &armada_plane_funcs,
> -armada_formats, ARRAY_SIZE(armada_formats), false);
> +armada_formats, ARRAY_SIZE(armada_formats),
> +DRM_PLANE_TYPE_OVERLAY);
>  
>   dplane->prop.colorkey_yr = 0xfefefe00;
>   dplane->prop.colorkey_ug = 0x01010100;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index db54ae9..8e869d6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -121,6 +121,15 @@ static const struct drm_prop_enum_list 
> drm_dpms_enum_list[] =
>  
>  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>  
> +static const struct drm_prop_enum_list drm_plane_type_enum_list[] =
> +{
> + { DRM_PLANE_TYPE_OVERLAY, "Overlay" },
> + { DRM_PLANE_TYPE_PRIMARY, "Primary" },
> + { DRM_PLANE_TYPE_CURSOR, "Cursor" },
> +};
> +
> +DRM_ENUM_NAME_FN(drm_get_plane_type, drm_plane_type_enum_list)
> +
>  /*
>   * Optional properties
>   */
> @@ -1007,7 +1016,7 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
>   * @funcs: callbacks for the new plane
>   * @formats: array of supported formats (%DRM_FORMAT_*)
>   * @format_count: number of elements in @formats
> - * @priv: plane is private (hidden from userspace)?
> + * @type: type of plane (overlay, primary, cursor)
>   *
>   * Inits a preallocate plane object created as base part of a driver plane
>   * object.
> @@ -1019,7 +1028,7 @@ int drm_plane_init(struct drm_device *dev, struct 
> drm_plane *plane,
>  unsigned long possible_crtcs,
>  const struct drm_plane_funcs *funcs,
>  const uint32_t *formats, uint32_t format_count,
> -bool priv)
> +enum drm_plane_type type)
>  {
>   int ret;
>  
> @@ -1044,20 +1053,16 @@ int drm_plane_init(struct drm_device *dev, struct 
> drm_plane *plane,
>   memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
>   plane->format_count = format_count;
>   plane->possible_crtcs = possible_crtcs;
> - plane->type = DRM_PLANE_TYPE_OVERLAY;
> + plane->type = type;
>  
> - /* private planes are not exposed to userspace, but depending on
> -  * display hardware, might be convenient to allow sharing programming
> -  * for the scanout engine with the crtc implementation.
> -  */
> - if (!priv) {
> - list_add_tail(&plane->head, &dev->mode_config.plane_list);
> - dev->mode_config.num_total_plane++;
> - if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> - dev->mode_config.num_overlay_plane++;
> - } else {
> - INIT_LIST_HEAD(&plane->head);
> - }
> + list_add_tail(&plane->head, &dev->mode_config.plane_list);
> + dev->mode_config.num_total_plane++;
> + if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> + dev->mode_config.num_overlay_plane++;
> +
> + drm_object_attach_property(&plane->base,
> +dev->mode_config.plane_type_property,
> +plane->type);
>  
>   out:
>   drm_modeset_unlock_all(dev);
> @@ -1081,13 +1086,13 @@ void drm_plane_cleanup(struct drm_plane *plane)
> 

[RFCv3 03/14] drm: Add primary plane helpers

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> When we expose non-overlay planes to userspace, they will become
> accessible via standard userspace plane API's.  We should be able to
> handle the standard plane operations against primary planes in a generic
> way via the page flip handler and modeset handler.
> 
> Drivers that can program primary planes more efficiently, that want to
> use their own primary plane structure to track additional information,
> or that don't have the limitations assumed by the helpers are free to
> provide their own implementation of some or all of these handlers.
> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_crtc.c | 288 
> +++--

Given that this is helper code to transition from the current interfaces
to universal planes I think we should shovel this into a new
drm_planes_helper.c library or something.

drm_crtc.c is reserved for core interface code between drm ioctl and the
main driver entry points.

Note that the legacy ioctl -> new universal plane code should probably
live here since long-term we want to phase out the legacy drm core ->
driver interfaces for cursors and primary planes.

>  include/drm/drm_crtc.h |  81 +
>  2 files changed, 330 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0983996..db54ae9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1118,6 +1118,255 @@ void drm_plane_force_disable(struct drm_plane *plane)
>  }
>  EXPORT_SYMBOL(drm_plane_force_disable);
>  
> +/*
> + * Checks that the framebuffer is big enough for the CRTC viewport
> + * (x, y, hdisplay, vdisplay)
> + */
> +static int drm_crtc_check_viewport(const struct drm_crtc *crtc,
> +int x, int y,
> +const struct drm_display_mode *mode,
> +const struct drm_framebuffer *fb)
> +
> +{
> + int hdisplay, vdisplay;
> +
> + hdisplay = mode->hdisplay;
> + vdisplay = mode->vdisplay;
> +
> + if (drm_mode_is_stereo(mode)) {
> + struct drm_display_mode adjusted = *mode;
> +
> + drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
> + hdisplay = adjusted.crtc_hdisplay;
> + vdisplay = adjusted.crtc_vdisplay;
> + }
> +
> + if (crtc->invert_dimensions)
> + swap(hdisplay, vdisplay);
> +
> + if (hdisplay > fb->width ||
> + vdisplay > fb->height ||
> + x > fb->width - hdisplay ||
> + y > fb->height - vdisplay) {
> + DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport 
> %ux%u+%d+%d%s.\n",
> +   fb->width, fb->height, hdisplay, vdisplay, x, y,
> +   crtc->invert_dimensions ? " (inverted)" : "");
> + return -ENOSPC;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Returns the connectors currently associated with a CRTC.  This function
> + * should be called twice:  once with a NULL connector list to retrieve
> + * the list size, and once with the properly allocated list to be filled in.
> + */
> +static int get_connectors_for_crtc(struct drm_crtc *crtc,
> +struct drm_connector **connector_list,
> +int num_connectors)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_connector *connector;
> + int count = 0;
> +
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head)
> + if (connector->encoder && connector->encoder->crtc == crtc) {
> + if (connector_list != NULL && count < num_connectors)
> + *(connector_list++) = connector;
> +
> + count++;
> + }
> +
> + return count;
> +}
> +
> +/**
> + * drm_primary_helper_update() - Helper for primary plane update
> + * @plane: plane object to update
> + * @crtc: owning CRTC of owning plane
> + * @fb: framebuffer to flip onto plane
> + * @crtc_x: x offset of primary plane on crtc
> + * @crtc_y: y offset of primary plane on crtc
> + * @crtc_w: width of primary plane rectangle on crtc
> + * @crtc_h: height of primary plane rectangle on crtc
> + * @src_x: x offset of @fb for panning
> + * @src_y: y offset of @fb for panning
> + * @src_w: width of source rectangle in @fb
> + * @src_h: height of source rectangle in @fb
> + *
> + * Provides a default plane update handler for primary planes.  This is 
> handler
> + * is called in response to a userspace SetPlane operation on the plane with 
> a
> + * non-NULL framebuffer.  We call the driver's pageflip handler to update the
> + * framebuffer.
> + *
> + * SetPlane() on a primary plane of a disabled CRTC is not supported, and 
> will
> + * return an error.
> + *
> + * Note that we assume most hardware can't reposition or scale the primary
> + * plane, so we require that crt

[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
> Previous revision of series:
> http://lists.freedesktop.org/archives/dri-devel/2013-November/049594.html
> 
> And if you prefer, in git form:
> http://cgit.freedesktop.org/~robclark/linux/log/?h=cold-fusion
> git://people.freedesktop.org/~robclark/linux cold-fusion
> 
> Compared to previous revision:
>  * rebased on primary-plane RFC series.  As a result, nearly none of the
>drivers actually compile at the moment :-P
> 
>But it is in the end a good thing... it reduces some code paths (now
>only having to care about fbs on planes, and it avoids exposing an 
>intermediate ABI state to userspace so avoids the need for some
>compat glue later).
> 
>  * state objects now carry their own ref to fbs.  This cleaned up most of
>the refcnt'ing issues, so I'm pretty happy how that turned out.  With
>that plus all the other major hacks cleaned up, I'm happy enough to
>drop the "RFC" tag.
> 
> There are, I think, two remaining issues to solve:
>  * we either need to add an event ptr param to plane->update_plane() or
>come up with another way to handle events on planes.
> 
>  * I kinda would still like to add to the atomic ioctl some way to indicate
>ok/error on a bit finer granularity than per-ioctl.  Ie. perhaps an
>array where userspace can ask for results per KMS object (crtc/plane)?
>Something along these lines would give the kernel a bit more flexibility
>to deal with some of the edge cases which come up when you gang crtcs
>for ultra high resolution displays.  In short, it would let the driver
>"steal" some of the planes if needed from userspace.
> 
>This would also, conveniently, be pretty similar to how (AFAIU) hw
>compositor and ADF work on android.  Which seems like it would be useful
>to eventually enable android devices to use an upstream display driver.
> 
>For this we could pretty easily just throw in a placeholder that we
>could replace later with an optional ptr to __user array.  I think
>that would be fine for an initial version, but I just wanted to throw
>this idea out there, because I think it will become important.

Hm, do you have some pointers to read up on this? I still think a more
elaborate fail scheme is overkill, but maybe reading a bit of android code
convinces me differently ;-)

> Note that this series is really only the beginning of atomic.  Once this
> is merged, there are some various vague thoughts about next steps:
>  * finish converting remaining callers of drm_mode_set_config_internal()
>to use atomic
> 
>  * replace driver usage of plane->fb with plane->state->fb.. drop plane->fb,
>somewhere along the way deprecate/drop ->page_flip() and possibly
>current incarnation of ->update_plane()..
> 
>  * perhaps some more fine grained event notification or other such
>extensions.
> 
>  * I know there are a few things I plan on ripping out / simplifying in
>drm/msm as a result of atomic, but just waiting until this is merge
>to avoid carrying such
> 
> ...
> 
> So, that all said, I am a bit curious about how we might eventually land
> this series some day.  Especially once we include changes to update all
> points in various drivers that access crtc->fb to crtc->primary->fb it
> will be one big hairy merge-conflict-prone branch.  Not the sort of thing
> that I'd really like to have to rebase for the next five kernel cycles if
> at all avoidable.
> 
> We certainly could merge everything but the new ioctl, or hide the ioctl
> behind an experimental module param for now.  I'm less concerned about
> that (either option would be pretty easy), and more about merging the
> infrastructure changes.

On the i915 side I think all the various pieces we need are finally coming
together, and I hope a lot of that goes in for 3.16. So I think we can
soonish jump on board with providing real proof-of-concepts based on your
ioctl.

For merging the core stuff I think we should concentrate first on getting
Matt's universal planes stuff in asap. I've scanned through his series
with a cursory look and atm it has a few change-the-world flag days. I'll
try to do an in-depth review later on looking for ways to make the
transition smoother. cursor planes seem to be the main culprit in this ...

Everything else should be doable by shoveling helper code into the
existing drm functions to handle primary and cursor planes without any
invasive driver changes. With the exception of the crtc->fb to
crtc->primary->fb transition maybe. But since that's a pure sed job it
should be doable (cocinelle job maybe).

For merging the actual atomic stuff I wonder a bit whether we shouldn't
make this fully opt-in. Atomic without driver support is a bit pointless
after all ;-) Of course we need to hide the thing behind a module option
and maybe do a add_tain(TAINT_CRAP); in the ioctl. Then we can throw the
switch once we have a few drivers ported and userspace 

linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/trace/define_trace.h:90:0,
 from drivers/gpu/drm/i915/i915_trace.h:520,
 from drivers/gpu/drm/i915/i915_trace_points.c:12:
drivers/gpu/drm/i915/./i915_trace.h: In function 
'ftrace_raw_event_i915_gem_evict_vm':
drivers/gpu/drm/i915/./i915_trace.h:246:22: error: 'dev' undeclared (first use 
in this function)
   __entry->dev = dev->primary->index;
  ^
include/trace/ftrace.h:574:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }   \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(i915_gem_evict_vm,
 ^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^
drivers/gpu/drm/i915/./i915_trace.h:246:22: note: each undeclared identifier is 
reported only once for each function it appears in
   __entry->dev = dev->primary->index;
  ^
include/trace/ftrace.h:574:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }   \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(i915_gem_evict_vm,
 ^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^
In file included from include/trace/define_trace.h:90:0,
 from drivers/gpu/drm/i915/i915_trace.h:520,
 from drivers/gpu/drm/i915/i915_trace_points.c:12:
drivers/gpu/drm/i915/./i915_trace.h: In function 'perf_trace_i915_gem_evict_vm':
drivers/gpu/drm/i915/./i915_trace.h:246:22: error: 'dev' undeclared (first use 
in this function)
   __entry->dev = dev->primary->index;
  ^
include/trace/ftrace.h:708:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }   \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(i915_gem_evict_vm,
 ^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^

Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers
from ring buffer in evict event").

I have used the drm-intel tree from next-20140318 for today.

-- 
Cheers,
Stephen Rothwell 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/fe11e2c7/attachment.sig>

[PATCH] drm/mm: Fix search for smallest hole satisfying constraints

[Daniel Vetter]

On Wed, Mar 19, 2014 at 05:42:27PM +0900, Michel D?nzer wrote:
> On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote:
> > On Tue, Mar 18, 2014 at 09:58:14AM +0900, Michel D?nzer wrote:
> > > From: Michel D?nzer 
> > > 
> > > entry->size is the size of the node, not the size of the hole after it.
> > > So the code would actually find the hole which can satisfy the
> > > constraints and which is preceded by the smallest node, not the smallest
> > > hole satisfying the constraints.
> > > 
> > > Reported-by: "Huang, FrankR" 
> > > Signed-off-by: Michel D?nzer 
> > 
> > But drm-next just gained my kerneldoc patch for drm_mm, so can you please
> > respin your patch and update the docs too?
> 
> What kind of update are you thinking of?

you've changed the function parameters, which breaks the kerneldoc. v2 is
ok in that regard.

> > While at it ... could you perhaps smash a bit of kerneldoc on top of
> > enum drm_mm_search_flags, I seem to have missed it. With that this is
> > 
> > Reviewed-by: Daniel Vetter 
> 
> Thanks, but I'm afraid I'll have to pass on that. I'm just submitting a
> fix for a problem Frank stumbled upon. I don't have the time right now,
> nor the particular inclination to clean up the surrounding code.

I've made a note to add the missing kerneldoc, still some patches left
over.

> Meanwhile, I've submitted a less invasive v2 fix.

Reviewed-by: Daniel Vetter  on that one.

> BTW, do you think the fix would interact properly with coloring?

Coloring only adjusts start/end so won't affect the size of the hole. If
you really see benefits from best_match then I guess you could look into
pessimising holes which need to be split, presuming radeon has a pile of
alignment or otherwise constrained buffers.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: add FOURCC formats for compute dma_buf interop.

[Daniel Vetter]

On Wed, Mar 19, 2014 at 7:30 AM, Gwenole Beauchesne  
wrote:
> 2014-03-15 12:28 GMT+01:00 Daniel Vetter :
>> On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
>>> Hi,
>>>
>>> 2014-03-14 22:52 GMT+01:00 Daniel Vetter :
>>> > On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauchesne wrote:
>>> >> This is a follow-up to:
>>> >> http://lists.freedesktop.org/archives/mesa-dev/2014-March/055742.html
>>> >>
>>> >> Add formats meant to convey a "compute" dimension when a DRM fourcc
>>> >> format is needed for dma_buf interop (EGL, OpenCL).
>>> >>
>>> >> Intended FOURCC format: ('T',,,).
>>> >> - : number of elements in the tuple. Range: [0..3].
>>> >> - : type of each element. Values: {'_','I','U','F'},
>>> >>   respectively for normalized to [0..1] range, signed integers,
>>> >>   unsigned integers, floating-point.
>>> >> - : size of the element. Values: {1, 2, 4, 8}.
>>> >>
>>> >> All entities are represented in native-endian byte-order in memory.
>>> >> For example, 'T2F4' format would represent the (float, float) tuple
>>> >> where elements are stored in little-endian byte-order on x86.
>>> >>
>>> >> Signed-off-by: Gwenole Beauchesne 
>>> >
>>> > So this fourcc stuff started out as pixel formats for the ADDFB2 ioctl,
>>> > i.e. stuff that can be displayed. Hence my first question: How can we
>>> > display these bastards here?
>>>
>>> It's not meant to be displayed. The idea was maybe we could detect the
>>> fourcc (e.g. (fourcc & 0xff) == 'T') and reject the buffer accordingly
>>> when submitted to one of the display ioctl?
>>
>> Well we already have explicit lists for all that, so no need to add a pile
>> of formats just to be able to reject them ;-)
>>
>>> > So given all this: Why do we need this in the kernel's header? It sounds
>>> > like purely a userspace business with no need at all the enshrine this
>>> > into kernel ABI headers. Note that e.g. the mesa import/export interface
>>> > have their own fourcc #defines for exactly this reason.
>>>
>>> I could have stuffed everything in gbm.h for instance, or another new
>>> header, but the EXT_dma_buf_import extension actually mentions
>>> drm_fourcc.h. So, that's why I finally moved the definitions to there.
>>> :)
>>
>> That's a bit unfortunate ... But the spec also clearly states "as used by
>> the drm_mode_fb_cmd2 ioctl". And imo we can't make a case that this is
>> true.
>>
>>> What would be the better place? Can we make the userspace libdrm
>>> version of the file live totally unsynchronized from the kernel
>>> headers then?
>>
>> I think the right approach would be to ref the specification and also
>> allow other fourcc codes for non-display related buffer layaouts, maybe in
>> a different namespace. This entire fourcc stuff was only done since it was
>> a somewhat ill-defined "standard" for all kinds of YUV buffers. We've
>> already had to massivel pimp it to make it work properly with RGB.
>>
>> Pimping this even further to support all kinds of random compute/gl
>> buffers sounds ill-advised. I think we need to steal a new namespace from
>> some existing standard for all this, maybe ogl or ocl has something? Ofc
>> that means creating a new dma_buf_import atttribute for eglCreateImageKHR
>> which could be used instead of DRM_FOURCC_EXT.
>
> Thinking further about it, the patch is totally useless. It should be
> enough to amend the EXT_image_dma_buf_import spec to allow for using
> the GL format/type enums instead... Now, what are the chances to have
> the required changes to appear in a new revision of the spec? :)
>
> I'd suggest the following formalism:
> - If EGL_LINUX_DRM_FOURCC_EXT attribute is 0 (zero), then a GL
> format/type pair needs to be supplied to the 
> - Accepted as an attribute to  would be EGL_GL_FORMAT_EXT
> / EGL_GL_TYPE_EXT, where EGL_GL_FORMAT_EXT attribute value would be
> GL_{RED,RG,RGB,RGBA} as usual, and EGL_GL_TYPE_EXT value would be
> GL_{{UNSIGNED_,}{BYTE,SHORT,INT},{HALF_,}FLOAT}.
>
> Alternative would be to provide a unique "internal format", but this
> would complicate implementations, for sanity checks (too large switch
> cases).
>
> WDYT?

Sounds imo sane, but my useful knowledge sharply drops off a steep
cliff as soon as we leave the kernel. Pulling in the original authors
of the spec. Maybe we can just add this as a revision/clarification
... Iirc Jesse Barker isn't at linaro any more, but I don't have his
latest mail.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[GIT PULL] PCI updates for v3.14

[Bjorn Helgaas]

Hi Linus,

This is a fix for an AGP regression exposed by e501b3d87f00 ("agp: Support
64-bit APBASE"), which we merged in v3.14-rc1.  We've warned about the
conflict between the GART and PCI resources and cleared out the PCI
resource for a long time, but after e501b3d87f00, we still *use* that
cleared-out PCI resource.  I think the GART resource is incorrect, so this
patch removes it.


The following changes since commit ac93ac7403493f8707b7734de9f40d5cb5db9045:

  PCI: Don't check resource_size() in pci_bus_alloc_resource() (2014-03-12 
11:19:20 -0600)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v3.14-fixes-3

for you to fetch changes up to 707d4eefbdb31f8e588277157056b0ce637d6c68:

  Revert "[PATCH] Insert GART region into resource map" (2014-03-18 14:26:12 
-0600)


PCI updates for v3.14:

  Resource management
- Revert "Insert GART region into resource map"


Bjorn Helgaas (1):
  Revert "[PATCH] Insert GART region into resource map"

 arch/x86/kernel/aperture_64.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

[RFCv3 03/14] drm: Add primary plane helpers

[Matt Roper]

On Wed, Mar 19, 2014 at 12:28:43PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
...
> > +
> > +   /*
> > +* set_config() adjusts crtc->primary->fb; however the DRM setplane
> > +* code that called us expects to handle the framebuffer update and
> > +* reference counting; save and restore the current fb before
> > +* calling it.
> > +*/
> > +   tmpfb = plane->fb;
> > +   ret = crtc->funcs->set_config(&set);
> 
> I wonder whether we should have an oppportunistic path using the page_flip
> interface here. Otoh we must have a fallback to ->set_config anyway since
> the drivers currently only allow pageflips on identical buffers. E.g. i915
> rejects tiling changes and stride changes and position changes. So I think
> having a pageflip fastpath isn't worth the trouble.
> 
> Also I think you need to use set_config_internal here to get the
> refcounting right.

Hmm.  I specifically didn't use set_config_internal here because I
thought drm_mode_setplane() (and presumably the future atomic ioctl
which may also call into this) will already handle the refcounting for
us.  Am I overlooking something?


Matt

-- 
Matt Roper
Graphics Software Engineer
ISG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

[Tomi Valkeinen]

On 19/03/14 10:22, Philipp Zabel wrote:

> I don't disagree, either. I have no objection against the bindings
> themselves.
> 
> Acked-by: Philipp Zabel 

Thanks. Is the ack for this particular binding, or for the whole series?

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/5f666d38/attachment-0001.sig>

How to support various hardware blocks in drm driver

[Andrzej Hajda]

Hi,

I have already proposed to reuse drm_panel infrastructure to
implement bridges in my RFC [1] and I have implemented DSI/LVDS bridge
in this way [2]. I guess this discussion is a result of my discussion
with Inki in thread [1]. More comments below.

[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/27044
[2]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559

On 03/18/2014 06:37 PM, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>>> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae  wrote:
 I think now drm_bridge couldn't do what we want for embedded systems
 as long as drm_encoder has drm_bridge.
 See the blow hardware pipeline,
 Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
 LVDS Bridge-LCD Panel

 In above hardware pipeline, Display controller is controlled by crtc,
 and Image Enhancement chip receives output from display controller.
 So the use of existing drm_bridge would be suitable to only bridge
 devices between MIPI DSI and LCD Panel, but not to Image Enhancement
 chip.

 For such hardware, drm_panel infrastructure is more reasonable to me,
 and that is why I try to integrate drm_panel and drm_bridge to one
 integrated framework which has infrastructure same as existing
 drm_panel.
 The important thing is to free this integrated framework from
 drm_encoder so that crtc device can also use this framework.
>>>
>>> Hm, what is this image enhancement chip? Is that some IP block on the
>>> SoC? Is it optional? Can it be attached to different crtcs?
>>
>> In case of Exynos, this chip is in SoC, and can be only attached to
>> one crtc, display controller. But I'm not sure other SoC have similar
>> chip.
>>
>>>
>>> I think we have similar things on intel hardware, but without details
>>> on what it does and how it works I can't really say how to best expose
>>> it to userspace and how to best handle it internally in the driver.
>>> -Daniel
>>
>> Simply saying, the image enhancement chip can enhance image data from
>> display controller, i.e. saturation enhancement, color reproduction,
>> dithering, and so on.
>> And this chip receives image data through hardware wired lines
>> connected internally between display controller and this chip.
> 
> To me this sounds like you simply need to expose all these capabilities to
> userspace as crtc properties. Which addresses one part of this issue.
> 
> The other side is how you are going to track this in the driver, and there
> you can do whatever you want - just add a pointer/structure to the exynos
> crtc structure for the display enhancement block.
> 
> The MIPI DSI block would then be treated as a drm_encoder, and all the
> later stages as drm_bridges up to the very last (the actual lvds panel)
> which would be a simple drm_panel.
> 
> I don't really see what additional complexity you need here. Especially
> since this image enhancer is on your SoC (and I guess a samgsung IP block
> not shared with any other SoC manufacture) you can easily keep the driver
> code for it in the exynos driver. So really no need to have a generic
> interface here.
> -Daniel
> 

But what you proposes is complex. Blocks will be implemented as:
1. drm_encoder,
2. drm_bridge,
3. drm_panel,
4. another 'framework' to implement image enhancers, which are after crtc.

But these blocks are just 'video consumers' which can be implemented
using drm_panel framework and 'video producers' (except real panels)
which can be implemented as drm_panel clients. Of course drm_panel
should be renamed to sth like drm_video_input and its ops should be
extended.

Anyway instead of 4 or more different frameworks we will have only one
framework.

In general I think it would be better to model just device interfaces
instead of modeling whole devices. Btw this approach will allow to model
such monsters as TC358710XBG hub [3].

[3]: http://www.toshiba-components.com/prpdf/5992e.pdf

Regards
Andrzej

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

[Philipp Zabel]

Hi Tomi,

Am Mittwoch, den 19.03.2014, 11:08 +0200 schrieb Tomi Valkeinen:
> On 19/03/14 10:22, Philipp Zabel wrote:
> 
> > I don't disagree, either. I have no objection against the bindings
> > themselves.
> > 
> > Acked-by: Philipp Zabel 
> 
> Thanks. Is the ack for this particular binding, or for the whole series?

Thanks for asking, I haven't really looked at the TPD12S015 binding.
The rest of the series, yes.

regards
Philipp

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

[Tomi Valkeinen]

On 19/03/14 10:03, Philipp Zabel wrote:

>>> Geert's comment also applies to all other connector types. These can be
>>> input connectors, too.
>>
>> We might not need to define all the properties required by input connectors 
>> now, but we need to make sure that future extensions will be backward-
>> compatible. I don't see a problem in making the connector DT bindings depend 
>> on the direction as long as the direction is specified in the DT node, 
>> either 
>> explicitly or implicitly.
>>
>> An obvious solution would be to have separate "hdmi-input-connector" and 
>> "hdmi-output-connector" compatible strings but I don't like that, as there's 
>> no difference in the HDMI connector itself, only in the usage.
> 
> I don't think this is necessary, either. I just meant the wording for
> the video port should leave the direction unspecified. I imagine
> somebody somewhere will connect a HDMI connector to a mux so that it can
> be either input or output.

I don't disagree, but I think it's better to change the wording when
someone has a working setup and can try it. These bindings have been
designed only with video output in mind, and I'd rather have them
constrained to that purpose for now.

One reason for keeping them output only is that when someone wants to
use these for capture, he needs to change the binding docs, and it'll
gather more attention than just using the bindings in a board's dts.

That said, we should take care to make the bindings so that nothing
prevents their use for capture (which I think they allow in their
current form).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/d4352c4b/attachment.sig>

[PATCH 3/4] acer-wmi: Stop selecting VIDEO_OUTPUT_CONTROL

[joeyli]

On Mon, Mar 17, 2014 at 03:48:23PM +0100, Jean Delvare wrote:
> ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which
> want to select ACPI_VIDEO no longer have to select
> VIDEO_OUTPUT_CONTROL.
> 
> Signed-off-by: Jean Delvare 
> Cc: "Lee, Chun-Yi" 
> Cc: Matthew Garrett 
> ---
>  drivers/platform/x86/Kconfig |2 --
>  1 file changed, 2 deletions(-)
> 
> --- linux-3.14-rc7.orig/drivers/platform/x86/Kconfig  2014-03-17 
> 14:23:31.511815259 +0100
> +++ linux-3.14-rc7/drivers/platform/x86/Kconfig   2014-03-17 
> 14:24:32.100155709 +0100
> @@ -27,8 +27,6 @@ config ACER_WMI
>   depends on ACPI_WMI
>   select INPUT_SPARSEKMAP
>   # Acer WMI depends on ACPI_VIDEO when ACPI is enabled
> - # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> -select VIDEO_OUTPUT_CONTROL if ACPI
>  select ACPI_VIDEO if ACPI
>   ---help---
> This is a driver for newer Acer (and Wistron) laptops. It adds
> 
> 
> -- 
> Jean Delvare
> SUSE L3 Support

Acked-by: "Lee, Chun-Yi" 


Thanks a lot!
Joey Lee

[PATCH 1/3] drm/dp: make aux retries less chatty

[Alex Deucher]

On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula
 wrote:
> On Tue, 18 Mar 2014, Alex Deucher  wrote:
>> Switch to debug only to avoid flooding the logs.
>> This mirrors the behavior in some other drivers.
>
> I'd rather think we should find out why the DP devices are replying with
> repeated native or i2c-over-aux defers. This doesn't help; I'm not in
> favour.

While I agree with you in theory, in practice this will generate a ton
of regression bug reports since there will be new error messages in
the kernel log on some systems even though the displays are working
fine.  I'm only seeing this on certain cards, others are perfectly
fine even with the same monitors and I don't have the bandwidth right
now to debug this further.  In all cases the monitors are working
correctly.

Alex

>
> BR,
> Jani.
>
>
>>
>> Signed-off-by: Alex Deucher 
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 35251af..74724aa 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -402,7 +402,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
>> request,
>>   }
>>   }
>>
>> - DRM_ERROR("too many retries, giving up\n");
>> + DRM_DEBUG_KMS("too many retries, giving up\n");
>>   return -EIO;
>>  }
>>
>> @@ -656,7 +656,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
>> struct drm_dp_aux_msg *msg)
>>   }
>>   }
>>
>> - DRM_ERROR("too many retries, giving up\n");
>> + DRM_DEBUG_KMS("too many retries, giving up\n");
>>   return -EREMOTEIO;
>>  }
>>
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Technology Center

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

[Philipp Zabel]

Am Mittwoch, den 19.03.2014, 10:11 +0200 schrieb Tomi Valkeinen:
> On 19/03/14 10:03, Philipp Zabel wrote:
> 
> >>> Geert's comment also applies to all other connector types. These can be
> >>> input connectors, too.
> >>
> >> We might not need to define all the properties required by input 
> >> connectors 
> >> now, but we need to make sure that future extensions will be backward-
> >> compatible. I don't see a problem in making the connector DT bindings 
> >> depend 
> >> on the direction as long as the direction is specified in the DT node, 
> >> either 
> >> explicitly or implicitly.
> >>
> >> An obvious solution would be to have separate "hdmi-input-connector" and 
> >> "hdmi-output-connector" compatible strings but I don't like that, as 
> >> there's 
> >> no difference in the HDMI connector itself, only in the usage.
> > 
> > I don't think this is necessary, either. I just meant the wording for
> > the video port should leave the direction unspecified. I imagine
> > somebody somewhere will connect a HDMI connector to a mux so that it can
> > be either input or output.
> 
> I don't disagree, but I think it's better to change the wording when
> someone has a working setup and can try it. These bindings have been
> designed only with video output in mind, and I'd rather have them
> constrained to that purpose for now.
> 
> One reason for keeping them output only is that when someone wants to
> use these for capture, he needs to change the binding docs, and it'll
> gather more attention than just using the bindings in a board's dts.
> 
> That said, we should take care to make the bindings so that nothing
> prevents their use for capture (which I think they allow in their
> current form).

I don't disagree, either. I have no objection against the bindings
themselves.

Acked-by: Philipp Zabel 

regards
Philipp

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

[Philipp Zabel]

Hi Laurent,

Am Mittwoch, den 19.03.2014, 00:43 +0100 schrieb Laurent Pinchart:
> Hello,
> 
> On Tuesday 18 March 2014 09:43:54 Philipp Zabel wrote:
> > Am Dienstag, den 18.03.2014, 10:15 +0200 schrieb Tomi Valkeinen:
> > > Add DT binding documentation for HDMI Connector.
> > > 
> > > Signed-off-by: Tomi Valkeinen 
> > > Reviewed-by: Archit Taneja 
> > > ---
> > > 
> > >  .../devicetree/bindings/video/hdmi-connector.txt   | 28 +
> > >  1 file changed, 28 insertions(+)
> > >  create mode 100644
> > >  Documentation/devicetree/bindings/video/hdmi-connector.txt> 
> > > diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt
> > > b/Documentation/devicetree/bindings/video/hdmi-connector.txt new file
> > > mode 100644
> > > index ..c19e2573
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
> > > @@ -0,0 +1,28 @@
> > > +HDMI Connector
> > > +==
> > > +
> > > +Required properties:
> > > +- compatible: "hdmi-connector"
> > > +- type: the HDMI connector type: "a", "b", "c", "d" or "e"
> > > +
> > > +Optional properties:
> > > +- label: a symbolic name for the connector
> > > +
> > > +Required nodes:
> > > +- Video port for HDMI input
> > 
> > Geert's comment also applies to all other connector types. These can be
> > input connectors, too.
> 
> We might not need to define all the properties required by input connectors 
> now, but we need to make sure that future extensions will be backward-
> compatible. I don't see a problem in making the connector DT bindings depend 
> on the direction as long as the direction is specified in the DT node, either 
> explicitly or implicitly.
>
> An obvious solution would be to have separate "hdmi-input-connector" and 
> "hdmi-output-connector" compatible strings but I don't like that, as there's 
> no difference in the HDMI connector itself, only in the usage.

I don't think this is necessary, either. I just meant the wording for
the video port should leave the direction unspecified. I imagine
somebody somewhere will connect a HDMI connector to a mux so that it can
be either input or output.

> We could also add a "direction" property (possibly later, with a default 
> value 
> of "output" in that case), or rely on the link direction, but in the latter 
> case that would require reaching an agreement in the current link directions 
> debate.

If we add a direction property, I think it should be on the ports.

regards
Philipp

[RFCv3 03/14] drm: Add primary plane helpers

[Rob Clark]

On Wed, Mar 19, 2014 at 7:28 AM, Daniel Vetter  wrote:
>> + /*
>> +  * set_config() adjusts crtc->primary->fb; however the DRM setplane
>> +  * code that called us expects to handle the framebuffer update and
>> +  * reference counting; save and restore the current fb before
>> +  * calling it.
>> +  */
>> + tmpfb = plane->fb;
>> + ret = crtc->funcs->set_config(&set);
>
> I wonder whether we should have an oppportunistic path using the page_flip
> interface here. Otoh we must have a fallback to ->set_config anyway since
> the drivers currently only allow pageflips on identical buffers. E.g. i915
> rejects tiling changes and stride changes and position changes. So I think
> having a pageflip fastpath isn't worth the trouble.


note that you'd get that opportunistic page_flip() path w/ the
addition of atomic series.  Although depending on when the two
different series are merged, the .page_flip() fast path might be a
good idea

[Bug 76297] open source radeon drivers for old graphics cards crash the system while booting kernels 3.12+

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

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

--- Comment #4 from epp942 at gmail.com ---
(In reply to comment #2)
> Does the driver work ok if you remove the UVD firmware?

Removing the UVD firmware kinda works.
What i mean is with ONLY kernel 3.14 i get a successful boot but i end up in
mouse pointer and black screen trying to force some graphics again and again
with no success , in kernels 3.12 and 3.13 same issue hang on boot , i found a
workaround as i was searching that is to remove the DM and start without
graphics then enter my creds and startx only then and only in kernel 3.14 i get
a successful boot with correct graphics running.
I dont know until when this is going to work or after the update of 3.14 etc
etc.
So issue still exists

-- 
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/20140319/66d8b137/attachment-0001.html>

[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Rob Clark]

On Wed, Mar 19, 2014 at 7:07 AM, Daniel Vetter  wrote:
> On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
>> Previous revision of series:
>> http://lists.freedesktop.org/archives/dri-devel/2013-November/049594.html
>>
>> And if you prefer, in git form:
>> http://cgit.freedesktop.org/~robclark/linux/log/?h=cold-fusion
>> git://people.freedesktop.org/~robclark/linux cold-fusion
>>
>> Compared to previous revision:
>>  * rebased on primary-plane RFC series.  As a result, nearly none of the
>>drivers actually compile at the moment :-P
>>
>>But it is in the end a good thing... it reduces some code paths (now
>>only having to care about fbs on planes, and it avoids exposing an
>>intermediate ABI state to userspace so avoids the need for some
>>compat glue later).
>>
>>  * state objects now carry their own ref to fbs.  This cleaned up most of
>>the refcnt'ing issues, so I'm pretty happy how that turned out.  With
>>that plus all the other major hacks cleaned up, I'm happy enough to
>>drop the "RFC" tag.
>>
>> There are, I think, two remaining issues to solve:
>>  * we either need to add an event ptr param to plane->update_plane() or
>>come up with another way to handle events on planes.
>>
>>  * I kinda would still like to add to the atomic ioctl some way to indicate
>>ok/error on a bit finer granularity than per-ioctl.  Ie. perhaps an
>>array where userspace can ask for results per KMS object (crtc/plane)?
>>Something along these lines would give the kernel a bit more flexibility
>>to deal with some of the edge cases which come up when you gang crtcs
>>for ultra high resolution displays.  In short, it would let the driver
>>"steal" some of the planes if needed from userspace.
>>
>>This would also, conveniently, be pretty similar to how (AFAIU) hw
>>compositor and ADF work on android.  Which seems like it would be useful
>>to eventually enable android devices to use an upstream display driver.
>>
>>For this we could pretty easily just throw in a placeholder that we
>>could replace later with an optional ptr to __user array.  I think
>>that would be fine for an initial version, but I just wanted to throw
>>this idea out there, because I think it will become important.
>
> Hm, do you have some pointers to read up on this? I still think a more
> elaborate fail scheme is overkill, but maybe reading a bit of android code
> convinces me differently ;-)

sadly no pointers to anything to read (but ofc would be interested if
anyone else does)..

Mostly it comes out of thinking through what I'll need to support
ultra-wide displays.. the hw seems to have support for doubling up
pipes into blenders (planes into crtcs) as well as blenders into
encoders.  And afaiu, I get to deal with one hw generation which needs
me to use two pipes if an overlay spans the middle of the screen,
while a later generation only needs double-wide pipes for overlays
beyond a certain width.

The sanest way I can think to deal with this is if the kernel has a
way to tell userspace that it can do certain layers in the requested
overlay config but needs other layers to fall back to gpu compositing.
 Without something like this, every frame will just fall back to 100%
gpu composition, which really isn't the desired result.

>> Note that this series is really only the beginning of atomic.  Once this
>> is merged, there are some various vague thoughts about next steps:
>>  * finish converting remaining callers of drm_mode_set_config_internal()
>>to use atomic
>>
>>  * replace driver usage of plane->fb with plane->state->fb.. drop plane->fb,
>>somewhere along the way deprecate/drop ->page_flip() and possibly
>>current incarnation of ->update_plane()..
>>
>>  * perhaps some more fine grained event notification or other such
>>extensions.
>>
>>  * I know there are a few things I plan on ripping out / simplifying in
>>drm/msm as a result of atomic, but just waiting until this is merge
>>to avoid carrying such
>>
>> ...
>>
>> So, that all said, I am a bit curious about how we might eventually land
>> this series some day.  Especially once we include changes to update all
>> points in various drivers that access crtc->fb to crtc->primary->fb it
>> will be one big hairy merge-conflict-prone branch.  Not the sort of thing
>> that I'd really like to have to rebase for the next five kernel cycles if
>> at all avoidable.
>>
>> We certainly could merge everything but the new ioctl, or hide the ioctl
>> behind an experimental module param for now.  I'm less concerned about
>> that (either option would be pretty easy), and more about merging the
>> infrastructure changes.
>
> On the i915 side I think all the various pieces we need are finally coming
> together, and I hope a lot of that goes in for 3.16. So I think we can
> soonish jump on board with providing real proof-of-concepts based on your
> ioctl.
>
> For merging the core stuff I think we

[Intel-gfx] linux-next: build failure after merge of the drm-intel tree

[Daniel Vetter]

On Wed, Mar 19, 2014 at 2:54 AM, Ben Widawsky  wrote:
> On Tue, Mar 18, 2014 at 09:18:42PM -0400, Steven Rostedt wrote:
>> On Wed, 19 Mar 2014 11:53:50 +1100
>> Stephen Rothwell  wrote:
>>
>>
>> > Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers
>> > from ring buffer in evict event").
>> >
>> > I have used the drm-intel tree from next-20140318 for today.
>> >
>>
>> Bah! I'm still suffering from jet lag (just came back from Linux-Tage
>> in Chemnitz).
>>
>> The next time I compile test a patch for a module, I'll make sure I have
>> that module's config option set :-(  The woe of using localmodconfig. I
>> should have picked the box with the i915. :-/
>>
>> Below is the fix. I'll repost a v2 of the original patch.
>>
>> Sorry about that.
>>
>
> I was about to send out the same fix when I saw this.
>
> Reviewed-by: Ben Widawsky 

Just fixed this this morning before starting to read mail - my
apologies the mess me pushing out a patch yesterday right before
rushing out caused, really shouldn't be doing that ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [RFCv3 13/14] drm/i915: Split cursor update code from cursor ioctl handling

[Chris Wilson]

On Tue, Mar 18, 2014 at 05:22:58PM -0700, Matt Roper wrote:
> Legacy cursor ioctls took GEM buffer handles from userspace directly
> whereas the new unified plane handling assigns drm_framebuffer's to
> cursor planes.  Splitting the code that actually updates the cursor
> plane from the code that handles object lookup and reference counting
> allows us to share common code between both interfaces.

This exposes an internal fb, a bo that was private is now public.

So maybe drm_framebuffer_init_private() and
intel_private_framebuffer_create().
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/4] ACPI: fix ACPI_VIDEO dependencies

[Jean Delvare]

Hi Rafael,

On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > From: Jean Delvare 
> > Subject: ACPI: fix ACPI_VIDEO dependencies
> > 
> > ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago
> > (see commit 677bd810, "ACPI video: remove output switching control".)
> > So it's about time to remove the Kconfig dependency between these two
> > options.
> > 
> > Signed-off-by: Jean Delvare 
> > Cc: Zhang Rui 
> > Cc: Len Brown 
> > Cc: "Rafael J. Wysocki" 
> 
> Do you want me to take this series?

If other maintainers are OK with it, yes, I think that would be the
easiest way. Thanks for proposing. All these patches depend on each
other and must be applied in the right order, so pushing them through
different trees would be slow at best, and risky.

Also, thinking about it, I wonder if the first 3 patches of the series
could go to longterm kernel series? While they do not fix any build
breakage nor run-time bug, without them everyone (on x86 at least) is
forced to build dead code. This is kind of frustrating. They are simple
and obvious enough that hopefully there won't be any objection.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

[PATCH] drm: add FOURCC formats for compute dma_buf interop.

[Gwenole Beauchesne]

Hi,

2014-03-15 12:28 GMT+01:00 Daniel Vetter :
> On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
>> Hi,
>>
>> 2014-03-14 22:52 GMT+01:00 Daniel Vetter :
>> > On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauchesne wrote:
>> >> This is a follow-up to:
>> >> http://lists.freedesktop.org/archives/mesa-dev/2014-March/055742.html
>> >>
>> >> Add formats meant to convey a "compute" dimension when a DRM fourcc
>> >> format is needed for dma_buf interop (EGL, OpenCL).
>> >>
>> >> Intended FOURCC format: ('T',,,).
>> >> - : number of elements in the tuple. Range: [0..3].
>> >> - : type of each element. Values: {'_','I','U','F'},
>> >>   respectively for normalized to [0..1] range, signed integers,
>> >>   unsigned integers, floating-point.
>> >> - : size of the element. Values: {1, 2, 4, 8}.
>> >>
>> >> All entities are represented in native-endian byte-order in memory.
>> >> For example, 'T2F4' format would represent the (float, float) tuple
>> >> where elements are stored in little-endian byte-order on x86.
>> >>
>> >> Signed-off-by: Gwenole Beauchesne 
>> >
>> > So this fourcc stuff started out as pixel formats for the ADDFB2 ioctl,
>> > i.e. stuff that can be displayed. Hence my first question: How can we
>> > display these bastards here?
>>
>> It's not meant to be displayed. The idea was maybe we could detect the
>> fourcc (e.g. (fourcc & 0xff) == 'T') and reject the buffer accordingly
>> when submitted to one of the display ioctl?
>
> Well we already have explicit lists for all that, so no need to add a pile
> of formats just to be able to reject them ;-)
>
>> > So given all this: Why do we need this in the kernel's header? It sounds
>> > like purely a userspace business with no need at all the enshrine this
>> > into kernel ABI headers. Note that e.g. the mesa import/export interface
>> > have their own fourcc #defines for exactly this reason.
>>
>> I could have stuffed everything in gbm.h for instance, or another new
>> header, but the EXT_dma_buf_import extension actually mentions
>> drm_fourcc.h. So, that's why I finally moved the definitions to there.
>> :)
>
> That's a bit unfortunate ... But the spec also clearly states "as used by
> the drm_mode_fb_cmd2 ioctl". And imo we can't make a case that this is
> true.
>
>> What would be the better place? Can we make the userspace libdrm
>> version of the file live totally unsynchronized from the kernel
>> headers then?
>
> I think the right approach would be to ref the specification and also
> allow other fourcc codes for non-display related buffer layaouts, maybe in
> a different namespace. This entire fourcc stuff was only done since it was
> a somewhat ill-defined "standard" for all kinds of YUV buffers. We've
> already had to massivel pimp it to make it work properly with RGB.
>
> Pimping this even further to support all kinds of random compute/gl
> buffers sounds ill-advised. I think we need to steal a new namespace from
> some existing standard for all this, maybe ogl or ocl has something? Ofc
> that means creating a new dma_buf_import atttribute for eglCreateImageKHR
> which could be used instead of DRM_FOURCC_EXT.

Thinking further about it, the patch is totally useless. It should be
enough to amend the EXT_image_dma_buf_import spec to allow for using
the GL format/type enums instead... Now, what are the chances to have
the required changes to appear in a new revision of the spec? :)

I'd suggest the following formalism:
- If EGL_LINUX_DRM_FOURCC_EXT attribute is 0 (zero), then a GL
format/type pair needs to be supplied to the 
- Accepted as an attribute to  would be EGL_GL_FORMAT_EXT
/ EGL_GL_TYPE_EXT, where EGL_GL_FORMAT_EXT attribute value would be
GL_{RED,RG,RGB,RGBA} as usual, and EGL_GL_TYPE_EXT value would be
GL_{{UNSIGNED_,}{BYTE,SHORT,INT},{HALF_,}FLOAT}.

Alternative would be to provide a unique "internal format", but this
would complicate implementations, for sanity checks (too large switch
cases).

WDYT?

How to support various hardware blocks in drm driver

[Dave Airlie]

On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter  wrote:
> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae  wrote:
>> >> I think now drm_bridge couldn't do what we want for embedded systems
>> >> as long as drm_encoder has drm_bridge.
>> >> See the blow hardware pipeline,
>> >> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>> >> LVDS Bridge-LCD Panel
>> >>
>> >> In above hardware pipeline, Display controller is controlled by crtc,
>> >> and Image Enhancement chip receives output from display controller.
>> >> So the use of existing drm_bridge would be suitable to only bridge
>> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement
>> >> chip.
>> >>
>> >> For such hardware, drm_panel infrastructure is more reasonable to me,
>> >> and that is why I try to integrate drm_panel and drm_bridge to one
>> >> integrated framework which has infrastructure same as existing
>> >> drm_panel.
>> >> The important thing is to free this integrated framework from
>> >> drm_encoder so that crtc device can also use this framework.
>> >
>> > Hm, what is this image enhancement chip? Is that some IP block on the
>> > SoC? Is it optional? Can it be attached to different crtcs?
>>
>> In case of Exynos, this chip is in SoC, and can be only attached to
>> one crtc, display controller. But I'm not sure other SoC have similar
>> chip.
>>
>> >
>> > I think we have similar things on intel hardware, but without details
>> > on what it does and how it works I can't really say how to best expose
>> > it to userspace and how to best handle it internally in the driver.
>> > -Daniel
>>
>> Simply saying, the image enhancement chip can enhance image data from
>> display controller, i.e. saturation enhancement, color reproduction,
>> dithering, and so on.
>> And this chip receives image data through hardware wired lines
>> connected internally between display controller and this chip.
>
> To me this sounds like you simply need to expose all these capabilities to
> userspace as crtc properties. Which addresses one part of this issue.
>
> The other side is how you are going to track this in the driver, and there
> you can do whatever you want - just add a pointer/structure to the exynos
> crtc structure for the display enhancement block.
>
> The MIPI DSI block would then be treated as a drm_encoder, and all the
> later stages as drm_bridges up to the very last (the actual lvds panel)
> which would be a simple drm_panel.
>
> I don't really see what additional complexity you need here. Especially
> since this image enhancer is on your SoC (and I guess a samgsung IP block
> not shared with any other SoC manufacture) you can easily keep the driver
> code for it in the exynos driver. So really no need to have a generic
> interface here.

I'm with Daniel, this does sound like its just part of the "crtc"
object, just write code in the driver
to support it and tie it into the crtc.

Dave.

[Bug 71753] Radeon Audio clock running wrong speed

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

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

--- Comment #4 from Rainer Hochecker  ---
Display also runs wrong speed. For a 23.976 mode we measure a average refresh
rate of 23.95

-- 
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/20140319/7b7ea19a/attachment.html>

[PATCH 1/4] ACPI: fix ACPI_VIDEO dependencies

[Rafael J. Wysocki]

Hi,

On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> From: Jean Delvare 
> Subject: ACPI: fix ACPI_VIDEO dependencies
> 
> ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago
> (see commit 677bd810, "ACPI video: remove output switching control".)
> So it's about time to remove the Kconfig dependency between these two
> options.
> 
> Signed-off-by: Jean Delvare 
> Cc: Zhang Rui 
> Cc: Len Brown 
> Cc: "Rafael J. Wysocki" 

Do you want me to take this series?

> ---
> It would be great if this patch could go upstream quickly, as
> system-wide cleanups depend on it.
> 
>  drivers/acpi/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-3.14-rc7.orig/drivers/acpi/Kconfig  2014-01-20 03:40:07.0 
> +0100
> +++ linux-3.14-rc7/drivers/acpi/Kconfig   2014-03-17 14:13:33.312716554 
> +0100
> @@ -115,7 +115,7 @@ config ACPI_BUTTON
>  
>  config ACPI_VIDEO
>   tristate "Video"
> - depends on X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL
> + depends on X86 && BACKLIGHT_CLASS_DEVICE
>   depends on INPUT
>   select THERMAL
>   help
> 
> 
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

[Laurent Pinchart]

Hello,

On Tuesday 18 March 2014 09:43:54 Philipp Zabel wrote:
> Am Dienstag, den 18.03.2014, 10:15 +0200 schrieb Tomi Valkeinen:
> > Add DT binding documentation for HDMI Connector.
> > 
> > Signed-off-by: Tomi Valkeinen 
> > Reviewed-by: Archit Taneja 
> > ---
> > 
> >  .../devicetree/bindings/video/hdmi-connector.txt   | 28 +
> >  1 file changed, 28 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/video/hdmi-connector.txt> 
> > diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt
> > b/Documentation/devicetree/bindings/video/hdmi-connector.txt new file
> > mode 100644
> > index ..c19e2573
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
> > @@ -0,0 +1,28 @@
> > +HDMI Connector
> > +==
> > +
> > +Required properties:
> > +- compatible: "hdmi-connector"
> > +- type: the HDMI connector type: "a", "b", "c", "d" or "e"
> > +
> > +Optional properties:
> > +- label: a symbolic name for the connector
> > +
> > +Required nodes:
> > +- Video port for HDMI input
> 
> Geert's comment also applies to all other connector types. These can be
> input connectors, too.

We might not need to define all the properties required by input connectors 
now, but we need to make sure that future extensions will be backward-
compatible. I don't see a problem in making the connector DT bindings depend 
on the direction as long as the direction is specified in the DT node, either 
explicitly or implicitly.

An obvious solution would be to have separate "hdmi-input-connector" and 
"hdmi-output-connector" compatible strings but I don't like that, as there's 
no difference in the HDMI connector itself, only in the usage.

We could also add a "direction" property (possibly later, with a default value 
of "output" in that case), or rely on the link direction, but in the latter 
case that would require reaching an agreement in the current link directions 
debate.

-- 
Regards,

Laurent Pinchart

How to support various hardware blocks in drm driver

[Inki Dae]

2014-03-18 22:29 GMT+09:00 Rob Clark :
> On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae  wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>>> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae  wrote:
 I think now drm_bridge couldn't do what we want for embedded systems
 as long as drm_encoder has drm_bridge.
 See the blow hardware pipeline,
 Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
 LVDS Bridge-LCD Panel

 In above hardware pipeline, Display controller is controlled by crtc,
 and Image Enhancement chip receives output from display controller.
 So the use of existing drm_bridge would be suitable to only bridge
 devices between MIPI DSI and LCD Panel, but not to Image Enhancement
 chip.

 For such hardware, drm_panel infrastructure is more reasonable to me,
 and that is why I try to integrate drm_panel and drm_bridge to one
 integrated framework which has infrastructure same as existing
 drm_panel.
 The important thing is to free this integrated framework from
 drm_encoder so that crtc device can also use this framework.
>>>
>>> Hm, what is this image enhancement chip? Is that some IP block on the
>>> SoC? Is it optional? Can it be attached to different crtcs?
>>
>> In case of Exynos, this chip is in SoC, and can be only attached to
>> one crtc, display controller. But I'm not sure other SoC have similar
>> chip.
>>
>>>
>>> I think we have similar things on intel hardware, but without details
>>> on what it does and how it works I can't really say how to best expose
>>> it to userspace and how to best handle it internally in the driver.
>>> -Daniel
>>
>> Simply saying, the image enhancement chip can enhance image data from
>> display controller, i.e. saturation enhancement, color reproduction,
>> dithering, and so on.
>> And this chip receives image data through hardware wired lines
>> connected internally between display controller and this chip.
>
> I suppose in some sense it doesn't really matter if it is internal
> block or external chip..
>
> but I'm still a bit confused about why you think drm_panel is a better
> fit.. could you explain that part?
>

As I already mentioned, see the below hardware pipeline,
Display Controller-Image Enhancement chip-MIPI DSI-MIPI TO
LVDS Bridge-LCD Panel

In above pipeline, the only place drm_bridge can exist is in MIPI DSI
driver because drm_encoder and drm_connector should be implemented in
MIPI DSI driver like we did using super node, at least in case of
exynos - it seems that this way is reasonable to me according to super
device and video-interface document.

However, there could be Image Enhancement chip between display
controller and MIPI DSI, and that means we need other thing for
controlling this chip because existing drm_bridge cannot be used for
this.
In the other hands, drm_panel infrastructure could be used by all
device types, crtc or encoder/connector because drm_panel could belong
to any device types.
So I thought it'd better to use existing framework with a little
change than using new one, and we could integrate these two
frameworks, drm_bridge and drm_panel to one framework.

I am planning to integrate them to one framework, and remove existing
drm_bridge. As a result, it would exist only one integrated
drm_bridge.

Is there any way that can control such chip using existing drm_bridge
contained in drm_encoder? if other better way, please give me your
idea.

Thanks,
Inki Dae

> BR,
> -R
>
>> Thanks,
>> Inki Dae
>>
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel