[PATCH v4 1/1] Documentation: drm: describing plane alpha and color blending property

[sagar.a.kam...@intel.com]

From: Sagar Kamble 

v2: Added description for "src-color" and "constant-alpha" property.
[Review by Laurent Pinchart]

v3: Fixed typos. [Review by David Herrmann]

v4: Additional formatting and modified description. [Review by David Herrmann]

Cc: rob at landley.net
Cc: airlied at redhat.com
Cc: daniel.vetter at ffwll.ch
Cc: laurent.pinchart at ideasonboard.com
Cc: dh.herrmann at gmail.com
Cc: alexander.deucher at amd.com
Cc: ville.syrjala at linux.intel.com
Cc: sagar.a.kamble at intel.com
Cc: vijay.a.purushothaman at intel.com
Cc: linux-doc at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Sagar Kamble 
---
 Documentation/DocBook/drm.tmpl | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 104402a..dd2ae67 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2264,6 +2264,20 @@ void intel_crt_init(struct drm_device *dev)
   
 
 
+  In addition to above types, properties can be constrained by supplying 
additional
+  flags while creating the property. Supported flags are
+  
+
+  DRM_MODE_PROP_32BIT_PAIR
+  This flag is applicable to Bitmask enum properties. 
It creates
+   Pair-properties that store two packed 32 bit values as 64bit 
unsigned integer
+   (often used as key-value pair). The lower 32 bits contain the first 
value (also: key),
+   while the upper 32 bits contain the second value.
+   Written as: ({key (LSB 32 bits), value (MSB 32 
bits)}).
+
+  
+
+
   To create a property drivers call one of the following functions 
depending
   on the property type. All property creation functions take property flags
   and name, as well as type-specific arguments.
@@ -2336,7 +2350,7 @@ void intel_crt_init(struct drm_device *dev)


DRM
-   Generic
+   Generic
???EDID???
BLOB | IMMUTABLE
0
@@ -2351,6 +2365,22 @@ void intel_crt_init(struct drm_device *dev)
Contains DPMS operation mode value.


+   ???blend???
+   BITMASK | 32BIT_PAIR
+   { "zero" = 0, "one" = 1, "src-color" = 2, 
"one-minus-src-color" = 3
+   , "dst-color" = 4, "one-minus-dst-color" = 5, "src-alpha"= 6, 
"one-minus-src-alpha" = 7, "dst-alpha" = 8
+   , "one-minus-dst-alpha" = 9, "constant-color" = 10, 
"one-minus-constant-color" = 11, "constant-alpha" = 12
+   , "one-minus-constant-alpha" = 13, "alpha-saturate" = 14 }
+   Plane
+   Contains plane alpha/color blending operation values. 
These are modeled after the glBlendFunc API
+   in OpenGL. Not all modes are supported by all drivers. The first value 
of the 32BIT_PAIR describes the blending mode
+   of the source plane, the second value describes the blending factors of 
the source plane.
+   
+   For e.g. to apply constant alpha of 0xFF on source plane, the first 
value of this property for source plane should
+   be set to 2^10 and second value to value of alpha(0xFF).
+   
+   
+   
DVI-I
???subconnector???
ENUM
-- 
1.8.5

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

[David Herrmann]

Hi

On Wed, Mar 26, 2014 at 9:40 PM, Thomas Hellstrom  
wrote:
>>  - Why don't add a spin-lock to "drm_file" instead? Use that one to
>> manage master contexts, but keep "struct_mutex" whenever calling into
>> driver callbacks (set_master/drop_master)
>
> See above. We can't have a lock in the drm_file structure since it
> protects drm_minor data. Also, while it might be possible to restructure
> some code to be able to use spinlocks instead of mutexes I see no reason
> to. The established locking order now is master_mutex -> ttm_lock ->
> struct_mutex which means master_mutex must be a mutex.

Thanks, that order really helps understanding what these locks do.
More, actually, than the commit message ;) It also shows how awful
struct_mutex is.. Using it as data-protection and execution-sync is
really weird. So I'm all for doing more fine-grained locking if it's
as simple as with the master-stuff.

>>  - why is master_mutex per device and not per-minor? I thought masters
>> on minors are _entirely_ independent?How do multiple keysyms
>
> Because currently there is only one master capable minor per device, so
> it would be equivalent. And even if there were more, there is no reason
> to expect any contention and thus a single master_mutex would be fine.

Fair enough.

>>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>>> index e6cdd0f..dad571f 100644
>>> --- a/drivers/gpu/drm/drm_fops.c
>>> +++ b/drivers/gpu/drm/drm_fops.c
>>> @@ -231,12 +231,13 @@ static int drm_open_helper(struct inode *inode, 
>>> struct file *filp,
>>>
>>> /* if there is no current master make this fd it, but do not create
>>>  * any master object for render clients */
>>> -   mutex_lock(>struct_mutex);
>>> +   mutex_lock(>master_mutex);
>>> if (drm_is_legacy_client(priv) && !priv->minor->master) {
>>> /* create a new master */
>>> +   mutex_lock(>struct_mutex);
>>> priv->minor->master = drm_master_create(priv->minor);
>>> +   mutex_unlock(>struct_mutex);
>>> if (!priv->minor->master) {
>>> -   mutex_unlock(>struct_mutex);
>>> ret = -ENOMEM;
>>> goto out_close;
>>> }
>>> @@ -245,28 +246,25 @@ static int drm_open_helper(struct inode *inode, 
>>> struct file *filp,
>>> /* take another reference for the copy in the local file 
>>> priv */
>>> priv->master = drm_master_get(priv->minor->master);
>>>
>>> +   mutex_lock(>struct_mutex);
>>> priv->authenticated = 1;
>>>
>>> mutex_unlock(>struct_mutex);
>> What's that struct_mutex doing here? We're in ->open(), there is
>> no-one racing against us.
>
> Well, it was held at that point before, and the purpose of this patch is
> not to generally clean up struct_mutex usage.

Well, it now looks like this:

mutex_lock(>struct_mutex);
priv->authenticated = 1;
mutex_unlock(>struct_mutex);

Which looks so _wrong_ that I thought we should fix it right away. But
ok, I'm not going to force you to do so.

Quick lock-review:
* drm_authmagic() uses drm_global_mutex to protect setting
priv->authenticated (racing against us..)
* current context is ->open() so no-one has access to "priv". We
haven't even linked it to dev->filelist, but we called into the driver
which might have done anything..
* drm-fops read ->authenticated _unlocked_, so no reason at all to do
an explicit locking around a _single_ write (which is only needed in
very rare cases, anyway)
* it is never set to anything else but 1; a _single_ barrier after
setting it should be enough

In case you don't want to incorporate that, I will send a cleanup.

Would be nice to have the mutex-locking in drm-next to get some
testing. v2 looks good, I haven't done a thorough locking review,
though. But I guess you did, so feel free to include it in your pull.
Thanks
David

[Bug 76659] Display does not return from DPMS off using ATI drivers

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

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

Tyler Brock  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NOTABUG |---

--- Comment #3 from Tyler Brock  ---
It seems it's doing the same thing with the new monitor... there is definitely
something wrong. Is there another place I can look besides the dmesg output
from the systemd journal?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 76659] Display does not return from DPMS off using ATI drivers

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

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

--- Comment #4 from Tyler Brock  ---
Created attachment 96502
  --> https://bugs.freedesktop.org/attachment.cgi?id=96502=edit
Kernel messages in systemd journal since last boot

-- 
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/20140328/1813dda0/attachment.html>

[Bug 76659] Display does not return from DPMS off using ATI drivers

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

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

--- Comment #5 from Tyler Brock  ---
Comment on attachment 96502
  --> https://bugs.freedesktop.org/attachment.cgi?id=96502
Kernel messages in systemd journal since last boot

This was me just running "journalctl --boot -1 -k > dmesg.log"

-- 
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/20140328/96179c6f/attachment.html>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

[David Herrmann]

Hi

On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom  
wrote:
> The master management was previously protected by the 
> drm_device::struct_mutex.
> In order to avoid locking order violations in a reworked dropped master
> security check in the vmwgfx driver, break it out into a separate 
> master_mutex.
>
> Also remove drm_master::blocked since it's not used.
>
> v2: Add an inline comment about what drm_device::master_mutex is protecting.
>
> Signed-off-by: Thomas Hellstrom 
> Reviewed-by: Brian Paul 
> ---
>  drivers/gpu/drm/drm_fops.c |   23 +-
>  drivers/gpu/drm/drm_stub.c |   38 ++--
>  include/drm/drmP.h |   46 
> 
>  3 files changed, 63 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index c7792b1..af55e2b 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -231,12 +231,13 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
>
> /* if there is no current master make this fd it, but do not create
>  * any master object for render clients */
> -   mutex_lock(>struct_mutex);
> +   mutex_lock(>master_mutex);
> if (drm_is_primary_client(priv) && !priv->minor->master) {
> /* create a new master */
> +   mutex_lock(>struct_mutex);
> priv->minor->master = drm_master_create(priv->minor);
> +   mutex_unlock(>struct_mutex);

drm_master_create() doesn't need any locking (considering your removal
of master_list), so this locking is exclusively to set ->master? See
below.

> if (!priv->minor->master) {
> -   mutex_unlock(>struct_mutex);
> ret = -ENOMEM;
> goto out_close;
> }
> @@ -245,28 +246,25 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> /* take another reference for the copy in the local file priv 
> */
> priv->master = drm_master_get(priv->minor->master);
>
> +   mutex_lock(>struct_mutex);
> priv->authenticated = 1;
>
> mutex_unlock(>struct_mutex);
> if (dev->driver->master_create) {
> ret = dev->driver->master_create(dev, priv->master);
> if (ret) {
> -   mutex_lock(>struct_mutex);
> /* drop both references if this fails */
> drm_master_put(>minor->master);
> drm_master_put(>master);
> -   mutex_unlock(>struct_mutex);

drm_master_put() resets the pointers to NULL. So _if_ the locking
above is needed, then this one _must_ stay, too.

I also don't quite understand why you move the struct_mutex locking
into drm_master_destroy() instead of requiring callers to lock it as
before? I mean, the whole function is protected by the lock..

> goto out_close;
> }
> }
> -   mutex_lock(>struct_mutex);
> if (dev->driver->master_set) {
> ret = dev->driver->master_set(dev, priv, true);

vmwgfx is the only driver using that, so I guess you reviewed this lock-change.

> if (ret) {
> /* drop both references if this fails */
> drm_master_put(>minor->master);
> drm_master_put(>master);

same as above

> -   mutex_unlock(>struct_mutex);
> goto out_close;
> }
> }
> @@ -274,8 +272,8 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> /* get a reference to the master */
> priv->master = drm_master_get(priv->minor->master);
> }
> -   mutex_unlock(>struct_mutex);
>
> +   mutex_unlock(>master_mutex);

Weird white-space change..

> mutex_lock(>struct_mutex);
> list_add(>lhead, >filelist);
> mutex_unlock(>struct_mutex);
> @@ -302,6 +300,7 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> return 0;
>
>  out_close:
> +   mutex_unlock(>master_mutex);
> if (dev->driver->postclose)
> dev->driver->postclose(dev, priv);
>  out_prime_destroy:
> @@ -489,11 +488,13 @@ int drm_release(struct inode *inode, struct file *filp)
> }
> mutex_unlock(>ctxlist_mutex);
>
> -   mutex_lock(>struct_mutex);
> +   mutex_lock(>master_mutex);
>
> if (file_priv->is_master) {
> struct drm_master *master = file_priv->master;
> struct drm_file *temp;
> +
> +   mutex_lock(>struct_mutex);
> 

[PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length

[Dave Airlie]

On Fri, Mar 28, 2014 at 10:45 AM, Christopher Friedt
 wrote:
> Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but 
> it would not adjust
> the FINFO properly, resulting in distorted screen rendering. The patch 
> corrects that behaviour.
>
> See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples.
>

Just adding cc's of maintainer list.

> Signed-off-by: Christopher Friedt 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index ed5ce2a..021b522 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -147,7 +147,7 @@ static int vmw_fb_check_var(struct fb_var_screeninfo *var,
> }
>
> if (!vmw_kms_validate_mode_vram(vmw_priv,
> -   info->fix.line_length,
> +   var->xres * var->bits_per_pixel/8,
> var->yoffset + var->yres)) {
> DRM_ERROR("Requested geom can not fit in framebuffer\n");
> return -EINVAL;
> @@ -162,6 +162,8 @@ static int vmw_fb_set_par(struct fb_info *info)
> struct vmw_private *vmw_priv = par->vmw_priv;
> int ret;
>
> +   info->fix.line_length = info->var.xres * info->var.bits_per_pixel/8;
> +
> ret = vmw_kms_write_svga(vmw_priv, info->var.xres, info->var.yres,
>  info->fix.line_length,
>  par->bpp, par->depth);
> @@ -177,6 +179,7 @@ static int vmw_fb_set_par(struct fb_info *info)
> vmw_write(vmw_priv, SVGA_REG_DISPLAY_POSITION_Y, 
> info->var.yoffset);
> vmw_write(vmw_priv, SVGA_REG_DISPLAY_WIDTH, info->var.xres);
> vmw_write(vmw_priv, SVGA_REG_DISPLAY_HEIGHT, info->var.yres);
> +   vmw_write(vmw_priv, SVGA_REG_BYTES_PER_LINE, 
> info->fix.line_length);
> vmw_write(vmw_priv, SVGA_REG_DISPLAY_ID, SVGA_ID_INVALID);
> }
>
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

didn't want these to wait for stable cycle, the nouveau and radeon ones
are the same problem, where the runtime pm stuff broke non-runtime pm 
managed secondary GPUs, udl is an oops on unplug, and i915 is a regression 
fix on Sandybridge even though it may break haswell (regression wins).

Dave.

The following changes since commit b098d6726bbfb94c06d6e1097466187afddae61f:

  Linux 3.14-rc8 (2014-03-24 19:31:17 -0700)

are available in the git repository at:

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

for you to fetch changes up to 8ee661b505613ef2747b350ca2871a31b3781bee:

  drm/i915: Undo gtt scratch pte unmapping again (2014-03-28 12:33:50 +1000)


Daniel Vetter (1):
  drm/i915: Undo gtt scratch pte unmapping again

Dave Airlie (3):
  drm/udl: take reference to device struct for dma-bufs
  drm/nouveau: fail runtime pm properly.
  drm/radeon: fix runtime suspend breaking secondary GPUs

 drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c | 14 ++
 drivers/gpu/drm/radeon/radeon_drv.c   | 17 -
 drivers/gpu/drm/udl/udl_gem.c | 11 ---
 4 files changed, 31 insertions(+), 13 deletions(-)

[Bug 42960] Display does not work when resuming from suspend

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

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

--- Comment #13 from Sandeep  ---
Is there any other information I can provide to help solve this problem?

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

[PATCH 00/11] A few patches around DRM logging

[Dave Airlie]

On Tue, Mar 25, 2014 at 4:35 PM, Inki Dae  wrote:
> 2014-03-25 0:53 GMT+09:00 Damien Lespiau :
>> As patch 8/11 explains, I noticed that we where evaluating the arguments to
>> drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good
>> reason. By pulling the test on drm_debug before calling 
>> drm_ut_debug_printk(),
>> we skip those instructions that only need to be executed when logging is on.
>>
>> The remaining patches are bonus clean-ups, with the main goal of removing
>> DRM_LOG* macros that are not really used throughout the code base. After 
>> that,
>> it's possible to simplify a bit drm_ut_debug_printk(). All pretty
>> straightforward cleanups, but still worthwhile IMHO.
>>
>> For driver-specific patches (why some of you are Cced in that series), I'd 
>> love
>> if you could take the time to throw a Acked-by/Reviewed-by tag. Also, do you
>> have any objection if the driver specific patch go through the DRM tree?
>> should people judge that series worthwhile, of course.
>
All pulled into -next, thanks,

Dave.

[Bug 76382] Mesa Gallium egllog _eglLog

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

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

Chris  changed:

   What|Removed |Added

Version|9.0 |unspecified

--- Comment #6 from Chris  ---
Same problem exists in latest stable branch 10.0.4

-- 
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/20140328/4bfbfd1d/attachment.html>

[PATCH] drm/i915: use __func__ instead of __FUNCTION__

[Jani Nikula]

On Fri, 28 Mar 2014, Christoph Jaeger  wrote:
> __FUNCTION__ is gcc specific; use __func__ instead.

I acknowledge the patch is correct and functionally the same as
before. However the correct fix would be to drop __FUNCTION__ and the
corresponding "%s: " altogether as DRM_DEBUG_KMS includes printing the
function name.

BR,
Jani.


>
> Signed-off-by: Christoph Jaeger 
> ---
>  drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
> b/drivers/gpu/drm/i915/dvo_ns2501.c
> index 954acb2..e40cd26 100644
> --- a/drivers/gpu/drm/i915/dvo_ns2501.c
> +++ b/drivers/gpu/drm/i915/dvo_ns2501.c
> @@ -234,7 +234,7 @@ static enum drm_mode_status ns2501_mode_valid(struct 
> intel_dvo_device *dvo,
>  {
>   DRM_DEBUG_KMS
>   ("%s: is mode valid 
> (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
> -  __FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
> +  __func__, mode->hdisplay, mode->htotal, mode->vdisplay,
>mode->vtotal);
>  
>   /*
> @@ -262,7 +262,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>  
>   DRM_DEBUG_KMS
>   ("%s: set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
> -  __FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
> +  __func__, mode->hdisplay, mode->htotal, mode->vdisplay,
>mode->vtotal);
>  
>   /*
> @@ -277,8 +277,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>   if (mode->hdisplay == 800 && mode->vdisplay == 600) {
>   /* mode 277 */
>   ns->reg_8_shadow &= ~NS2501_8_BPAS;
> - DRM_DEBUG_KMS("%s: switching to 800x600\n",
> -   __FUNCTION__);
> + DRM_DEBUG_KMS("%s: switching to 800x600\n", __func__);
>  
>   /*
>* No, I do not know where this data comes from.
> @@ -341,8 +340,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>  
>   } else if (mode->hdisplay == 640 && mode->vdisplay == 480) {
>   /* mode 274 */
> - DRM_DEBUG_KMS("%s: switching to 640x480\n",
> -   __FUNCTION__);
> + DRM_DEBUG_KMS("%s: switching to 640x480\n", __func__);
>   /*
>* No, I do not know where this data comes from.
>* It is just what the video bios left in the DVO, so
> @@ -406,8 +404,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>  
>   } else if (mode->hdisplay == 1024 && mode->vdisplay == 768) {
>   /* mode 280 */
> - DRM_DEBUG_KMS("%s: switching to 1024x768\n",
> -   __FUNCTION__);
> + DRM_DEBUG_KMS("%s: switching to 1024x768\n", __func__);
>   /*
>* This might or might not work, actually. I'm silently
>* assuming here that the native panel resolution is
> @@ -459,7 +456,7 @@ static void ns2501_dpms(struct intel_dvo_device *dvo, 
> bool enable)
>   unsigned char ch;
>  
>   DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %i\n",
> -   __FUNCTION__, enable);
> +   __func__, enable);
>  
>   ch = ns->reg_8_shadow;
>  
> -- 
> 1.8.5.3
>

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

[Thomas Hellstrom]

Hi, David.

Thanks for reviewing.
I'll try to address all your concerns and resend.

/Thomas


On 03/28/2014 01:19 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom  
> wrote:
>> The master management was previously protected by the 
>> drm_device::struct_mutex.
>> In order to avoid locking order violations in a reworked dropped master
>> security check in the vmwgfx driver, break it out into a separate 
>> master_mutex.
>>
>> Also remove drm_master::blocked since it's not used.
>>
>> v2: Add an inline comment about what drm_device::master_mutex is protecting.
>>
>> Signed-off-by: Thomas Hellstrom 
>> Reviewed-by: Brian Paul 
>> ---
>>  drivers/gpu/drm/drm_fops.c |   23 +-
>>  drivers/gpu/drm/drm_stub.c |   38 ++--
>>  include/drm/drmP.h |   46 
>> 
>>  3 files changed, 63 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index c7792b1..af55e2b 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -231,12 +231,13 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>>
>> /* if there is no current master make this fd it, but do not create
>>  * any master object for render clients */
>> -   mutex_lock(>struct_mutex);
>> +   mutex_lock(>master_mutex);
>> if (drm_is_primary_client(priv) && !priv->minor->master) {
>> /* create a new master */
>> +   mutex_lock(>struct_mutex);
>> priv->minor->master = drm_master_create(priv->minor);
>> +   mutex_unlock(>struct_mutex);
> drm_master_create() doesn't need any locking (considering your removal
> of master_list), so this locking is exclusively to set ->master? See
> below.
>
>> if (!priv->minor->master) {
>> -   mutex_unlock(>struct_mutex);
>> ret = -ENOMEM;
>> goto out_close;
>> }
>> @@ -245,28 +246,25 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>> /* take another reference for the copy in the local file 
>> priv */
>> priv->master = drm_master_get(priv->minor->master);
>>
>> +   mutex_lock(>struct_mutex);
>> priv->authenticated = 1;
>>
>> mutex_unlock(>struct_mutex);
>> if (dev->driver->master_create) {
>> ret = dev->driver->master_create(dev, priv->master);
>> if (ret) {
>> -   mutex_lock(>struct_mutex);
>> /* drop both references if this fails */
>> drm_master_put(>minor->master);
>> drm_master_put(>master);
>> -   mutex_unlock(>struct_mutex);
> drm_master_put() resets the pointers to NULL. So _if_ the locking
> above is needed, then this one _must_ stay, too.
>
> I also don't quite understand why you move the struct_mutex locking
> into drm_master_destroy() instead of requiring callers to lock it as
> before? I mean, the whole function is protected by the lock..
>
>> goto out_close;
>> }
>> }
>> -   mutex_lock(>struct_mutex);
>> if (dev->driver->master_set) {
>> ret = dev->driver->master_set(dev, priv, true);
> vmwgfx is the only driver using that, so I guess you reviewed this 
> lock-change.
>
>> if (ret) {
>> /* drop both references if this fails */
>> drm_master_put(>minor->master);
>> drm_master_put(>master);
> same as above
>
>> -   mutex_unlock(>struct_mutex);
>> goto out_close;
>> }
>> }
>> @@ -274,8 +272,8 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>> /* get a reference to the master */
>> priv->master = drm_master_get(priv->minor->master);
>> }
>> -   mutex_unlock(>struct_mutex);
>>
>> +   mutex_unlock(>master_mutex);
> Weird white-space change..
>
>> mutex_lock(>struct_mutex);
>> list_add(>lhead, >filelist);
>> mutex_unlock(>struct_mutex);
>> @@ -302,6 +300,7 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>> return 0;
>>
>>  out_close:
>> +   mutex_unlock(>master_mutex);
>> if (dev->driver->postclose)
>> dev->driver->postclose(dev, priv);
>>  out_prime_destroy:
>> @@ -489,11 +488,13 @@ int drm_release(struct inode *inode, struct file *filp)
>> }
>> mutex_unlock(>ctxlist_mutex);
>>
>> - 

[Intel-gfx] [PATCHv4 00/13] Universal plane preparation patches

[Daniel Vetter]

On Thu, Mar 27, 2014 at 05:44:25PM -0700, Matt Roper wrote:
> Previous series revisions & explanation at [1], [2], and [3]
> 
> This version of the patch series focuses on isolating the DRM core changes 
> from
> individual driver changes to (hopefully) make this a bit easier to merge.  New
> plane and crtc initialization functions have been added to allow drivers to
> migrate to the new infrastructure at their own pace; existing drivers that do
> not update should continue to function as expected.  The one remaining painful
> patch here is patch #12, which replaces crtc->fb with crtc->primary->fb.  That
> patch is now auto-generated via a Coccinelle semantic patch with the rules
> described in the commit message; hopefully that will make life slightly easier
> for tree maintainers who want to pull it in.
> 
> Daniel mentioned that we should try to merge the underlying infrastructure 
> here
> without the actual userspace-facing capability bit to make sure things 
> continue
> to run as expected without breaking; I've dropped the capability bit patch for
> now, but the previous version from [4] should work on top of this patch set.
> I've also dropped the i915 cursor support for the moment to keep the patch set
> simple.

The usual way to expose experimental feature is to hide them by default,
but have a moduel option for developers like drm.universal_planes=1. So
for the next round I think you can add the capability again with that drm
module option added.
-Daniel

> I believe the only userspace-visible changes in this series are the plane type
> property (which will always return "overlay" since there's no switch to turn 
> on
> the other plane types) and max width/height plane properties.  I figured
> properties were a little bit cleaner than extending GetPlane() to return
> additional information, although I can change that if people feel differently.
> Presumably we're still going to need a lot more properties that describe the
> limits and capabilities of planes as we go forward (stride, scaling, tiling,
> etc.)
> 
> [1] http://lists.freedesktop.org/archives/dri-devel/2014-March/055855.html
> [2] http://lists.freedesktop.org/archives/dri-devel/2014-March/055222.html
> [3] http://lists.freedesktop.org/archives/dri-devel/2014-February/054719.html
> [4] http://lists.freedesktop.org/archives/dri-devel/2014-March/055216.html
> 
> Matt Roper (13):
>   drm: Add support for multiple plane types (v2)
>   drm/exynos: Restrict plane loops to only operate on overlay planes
> (v2)
>   drm/i915: Restrict plane loops to only operate on overlay planes (v2)
>   drm/shmobile: Restrict plane loops to only operate on legacy planes
>   drm: Make drm_crtc_check_viewport non-static
>   drm: Add primary plane helpers (v2)
>   drm: Add drm_universal_plane_init()
>   drm: Add plane type property (v2)
>   drm: Add plane max width/height properties
>   drm: Add drm_crtc_init_with_planes()
>   drm/msm: Switch to universal plane API's
>   drm: Replace crtc fb with primary plane fb (v3)
>   drm: Remove unused drm_crtc->fb
> 
>  drivers/gpu/drm/Makefile |   3 +-
>  drivers/gpu/drm/armada/armada_crtc.c |  23 +-
>  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   | 228 
>  drivers/gpu/drm/drm_crtc_helper.c|  20 +-
>  drivers/gpu/drm/drm_fb_helper.c  |   9 +-
>  drivers/gpu/drm/drm_plane_helper.c   | 312 
> +++
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  22 +-
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c  |   2 +-
>  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  |   2 +-
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c  |   2 +-
>  drivers/gpu/drm/gma500/gma_display.c |  16 +-
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c|   2 +-
>  drivers/gpu/drm/gma500/mdfld_intel_display.c |  16 +-
>  drivers/gpu/drm/gma500/oaktrail_crtc.c   |  12 +-
>  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 | 148 +++--
>  drivers/gpu/drm/i915/intel_dp.c  |   4 +-
>  drivers/gpu/drm/i915/intel_fbdev.c   |   6 +-
>  drivers/gpu/drm/i915/intel_overlay.c |   4 +-
>  drivers/gpu/drm/i915/intel_pm.c  |  38 ++--
>  drivers/gpu/drm/mgag200/mgag200_mode.c   |  26 +--
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c |  33 +--
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c|   8 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c |  27 

[PATCHv4 09/13] drm: Add plane max width/height properties

[Daniel Vetter]

On Thu, Mar 27, 2014 at 05:44:34PM -0700, Matt Roper wrote:
> Some hardware has different size limits for different planes (e.g.,
> sprites/overlays can't always be as large as the upper bound for the
> primary plane).  Adding read-only plane properties allows userspace
> to check these limits.  By default, mode_config.max_{width,height} are
> used for non-cursor planes and mode_config.cursor_{width,height} are
> used for cursors; drivers should override these defaults after calling
> plane_init, if necessary.
> 
> Signed-off-by: Matt Roper 

Hm, I think we should wait with exposing this to userspace. In some other
thread which I've dragged onto dri-devel we've discussed this and we might
actually need per pixel format limits. And a lot more limits than just max
width/height.

So for now I think we should just leave the current mess which presumes
that userspace knows, and tackle it later. Also this avoids that universal
planes get bogged down in some minute detail bikeshed discusssion which is
really just auxilliary to the main concept. And I don't want this to
happen.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 30 ++
>  include/drm/drm_crtc.h |  2 ++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0c70101..24226de 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1028,6 +1028,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>enum drm_plane_type type)
>  {
>   int ret;
> + uint32_t maxwidth, maxheight;
>  
>   drm_modeset_lock_all(dev);
>  
> @@ -1061,6 +1062,28 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>  dev->mode_config.plane_type_property,
>  plane->type);
>  
> + /*
> +  * Drivers may override default max width/height after calling
> +  * plane_init.
> +  */
> + if (plane->type == DRM_PLANE_TYPE_CURSOR) {
> + maxwidth = dev->mode_config.cursor_width;
> + if (!maxwidth)
> + maxwidth = 64;
> + maxheight = dev->mode_config.cursor_height;
> + if (!maxheight)
> + maxheight = 64;
> + } else {
> + maxwidth = dev->mode_config.max_width;
> + maxheight = dev->mode_config.max_height;
> + }
> + drm_object_attach_property(>base,
> +dev->mode_config.plane_maxwidth_property,
> +maxwidth);
> + drm_object_attach_property(>base,
> +dev->mode_config.plane_maxheight_property,
> +maxheight);
> +
>   out:
>   drm_modeset_unlock_all(dev);
>  
> @@ -1175,6 +1198,7 @@ static int 
> drm_mode_create_standard_connector_properties(struct drm_device *dev)
>  static int drm_mode_create_standard_plane_properties(struct drm_device *dev)
>  {
>   struct drm_property *type;
> + struct drm_property *maxwidth, *maxheight;
>  
>   /*
>* Standard properties (apply to all planes)
> @@ -1182,7 +1206,13 @@ static int 
> drm_mode_create_standard_plane_properties(struct drm_device *dev)
>   type = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
>   "type", drm_plane_type_enum_list,
>   ARRAY_SIZE(drm_plane_type_enum_list));
> + maxwidth = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
> +  "max width", 1, INT_MAX);
> + maxheight = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
> +   "max height", 1, INT_MAX);
>   dev->mode_config.plane_type_property = type;
> + dev->mode_config.plane_maxwidth_property = maxwidth;
> + dev->mode_config.plane_maxheight_property = maxheight;
>  
>   return 0;
>  }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 4c4f792..78cf825 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -772,6 +772,8 @@ struct drm_mode_config {
>   struct drm_property *edid_property;
>   struct drm_property *dpms_property;
>   struct drm_property *plane_type_property;
> + struct drm_property *plane_maxwidth_property;
> + struct drm_property *plane_maxheight_property;
>  
>   /* DVI-I properties */
>   struct drm_property *dvi_i_subconnector_property;
> -- 
> 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

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

[Daniel Vetter]

On Thu, Mar 27, 2014 at 05:44:31PM -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 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.
> 
> v2:
>  - Move plane helpers to a new file (drm_plane_helper.c)
>  - Tighten checks on update handler (check for scaling, CRTC coverage,
>subpixel positioning)
>  - Pass proper panning parameters to modeset interface
>  - Disallow disabling primary plane (and thus CRTC) if other planes are
>still active on the CRTC.
>  - Use a minimal format list that should work on all hardware/drivers.
>Drivers may call this function with a more accurate plane list to
>enable additional formats they can support.
> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/Makefile   |   3 +-
>  drivers/gpu/drm/drm_plane_helper.c | 312 
> +
>  include/drm/drm_plane_helper.h |  49 ++

DocBook integration is missing for all the great kerneldoc you've written.
That boils down to adding a new section next to the other helper libraries
in the drm docbook to pull the kerneldoc in and running make htmldocs to
make sure the kerneldoc checks out.

If you want you can add a DOC: overview section and pull that into the
docbook too, see e.g. how the drm prime helpers are integrated.

>  3 files changed, 363 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_plane_helper.c
>  create mode 100644 include/drm/drm_plane_helper.h
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 5e792b0..9d25dbb 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -13,7 +13,8 @@ drm-y   :=  drm_auth.o drm_buffer.o drm_bufs.o 
> drm_cache.o \
>   drm_crtc.o drm_modes.o drm_edid.o \
>   drm_info.o drm_debugfs.o drm_encoder_slave.o \
>   drm_trace_points.o drm_global.o drm_prime.o \
> - drm_rect.o drm_vma_manager.o drm_flip_work.o
> + drm_rect.o drm_vma_manager.o drm_flip_work.o \
> + drm_plane_helper.o
>  
>  drm-$(CONFIG_COMPAT) += drm_ioc32.o
>  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> new file mode 100644
> index 000..374a98d
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -0,0 +1,312 @@
> +/*
> + * Copyright (C) 2014 Intel Corporation
> + *
> + * DRM universal plane helper functions
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
> + * SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define SUBPIXEL_MASK 0x
> +
> +/*
> + * This is the minimal list of formats that seem to be safe for modeset use
> + * with all current DRM drivers.  Most hardware can actually support more
> + * formats than this and drivers may specify a more accurate list when
> + * creating the primary plane.  However drivers that still call
> + * drm_plane_init() will use this minimal format list as the default.
> + */
> +const static uint32_t safe_modeset_formats[] = {
> +   DRM_FORMAT_XRGB,
> +   DRM_FORMAT_ARGB,
> +};

Yeah, I think this is safe enough ;-) And it's really not a big change for
drivers to enable primary planes properly with these helpers here. So even
if we decide to switch to them fully (e.g. to make the fbdev helpers a
test-vehicle for atomic modesets) it shouldn't be a lot of fuzz to get
this going. Since for fbdev 

[PATCHv4 12/13] drm: Replace crtc fb with primary plane fb (v3)

[Daniel Vetter]

On Thu, Mar 27, 2014 at 05:44:37PM -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.
> 
> This patch was generated by the Coccinelle semantic patching tool using
> the following rules:
> 
> @@ struct drm_crtc C; @@
> -   (C).fb
> +   C.primary->fb
> 
> @@ struct drm_crtc *C; @@
> -   (C)->fb
> +   C->primary->fb
> 
> v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
> moved to a subsequent patch.
> 
> v2: Fixup several lingering crtc->fb instances that were missed in the
> first patch iteration.  [Rob Clark]
> 
> Signed-off-by: Matt Roper 
> ---
> 
> This patch will cause some heartache for tree maintainers since it's pretty
> much a point of no return and touches so many drivers.  There's been some
> discussion on the mailing list about how this might be split into a multi-step
> process, although it's still pretty painful.  The hope is that since this can
> be auto-generated via Coccinelle (spatch), the pain should be reduced a bit.

Yeah I agree that there doesn't seem to be an easy solution at hand. All
the approaches we've discussed bring a good amount of subtle fail risk in
the fb refcounting with them, and historically we've not been good at
catching that. With this approach we can enlist the help of some solid
tools at least (cocinelle + gcc catching fallout).
> 
> Note that if you're using Coccinelle by hand, you need to be careful to get 
> the
> command line right and make sure all of the headers are found and processed;
> failure to do so may result in some forms of {foo}->crtc->fb not being 
> properly
> expanded.

The exact cocinelle cmdline you're using might be useful here ;-)

Cheers, Daniel

> 
>  drivers/gpu/drm/armada/armada_crtc.c |  23 ++---
>  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   |  26 ++---
>  drivers/gpu/drm/drm_crtc_helper.c|  20 ++--
>  drivers/gpu/drm/drm_fb_helper.c  |   6 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  20 ++--
>  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  |   2 +-
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c  |   2 +-
>  drivers/gpu/drm/gma500/gma_display.c |  16 ++--
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c|   2 +-
>  drivers/gpu/drm/gma500/mdfld_intel_display.c |  16 ++--
>  drivers/gpu/drm/gma500/oaktrail_crtc.c   |  12 +--
>  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 | 138 
> +--
>  drivers/gpu/drm/i915/intel_dp.c  |   4 +-
>  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   |  26 ++---
>  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/omapdrm/omap_crtc.c  |  10 +-
>  drivers/gpu/drm/omapdrm/omap_fb.c|   2 +-
>  drivers/gpu/drm/qxl/qxl_display.c|  10 +-
>  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   |   2 +-
>  drivers/gpu/drm/radeon/radeon_display.c  |   4 +-
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c  |  16 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c   |  10 +-
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c|  14 +--
>  drivers/gpu/drm/tegra/dc.c   |  16 ++--
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   8 +-
>  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 +-
>  drivers/staging/imx-drm/ipuv3-crtc.c |   6 +-
>  51 files changed, 329 insertions(+), 327 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 

[git pull] drm fixes

[Daniel Vetter]

On Fri, Mar 28, 2014 at 02:46:11AM +, Dave Airlie wrote:
> 
> Hi Linus,
> 
> didn't want these to wait for stable cycle, the nouveau and radeon ones
> are the same problem, where the runtime pm stuff broke non-runtime pm 
> managed secondary GPUs, udl is an oops on unplug, and i915 is a regression 
> fix on Sandybridge even though it may break haswell (regression wins).

My apologies for the i915 regression fumble, that thing somehow fell
through the cracks here for almost half a year :( Imo that's more than
enough flailing to just go ahead with the revert, and the re-broken hsw
should get peoples attention ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

[Thomas Hellstrom]

Hi, again!

I've looked through the code again and have some answers to your
questions. Will post an updated patch soon.

On 03/28/2014 01:19 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom  
> wrote:
>> The master management was previously protected by the 
>> drm_device::struct_mutex.
>> In order to avoid locking order violations in a reworked dropped master
>> security check in the vmwgfx driver, break it out into a separate 
>> master_mutex.
>>
>> Also remove drm_master::blocked since it's not used.
>>
>> v2: Add an inline comment about what drm_device::master_mutex is protecting.
>>
>> Signed-off-by: Thomas Hellstrom 
>> Reviewed-by: Brian Paul 
>> ---
>>  drivers/gpu/drm/drm_fops.c |   23 +-
>>  drivers/gpu/drm/drm_stub.c |   38 ++--
>>  include/drm/drmP.h |   46 
>> 
>>  3 files changed, 63 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index c7792b1..af55e2b 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -231,12 +231,13 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>>
>> /* if there is no current master make this fd it, but do not create
>>  * any master object for render clients */
>> -   mutex_lock(>struct_mutex);
>> +   mutex_lock(>master_mutex);
>> if (drm_is_primary_client(priv) && !priv->minor->master) {
>> /* create a new master */
>> +   mutex_lock(>struct_mutex);
>> priv->minor->master = drm_master_create(priv->minor);
>> +   mutex_unlock(>struct_mutex);
> drm_master_create() doesn't need any locking (considering your removal
> of master_list), so this locking is exclusively to set ->master? See
> below.

No. The locking here is, as you say, unneeded. drm_minor::master is
protected by master_mutex.
I'll remove, and while doing that, I'll also remove the unneeded locking
around
priv->authenticated = 1.


>> if (!priv->minor->master) {
>> -   mutex_unlock(>struct_mutex);
>> ret = -ENOMEM;
>> goto out_close;
>> }
>> @@ -245,28 +246,25 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>> /* take another reference for the copy in the local file 
>> priv */
>> priv->master = drm_master_get(priv->minor->master);
>>
>> +   mutex_lock(>struct_mutex);
>> priv->authenticated = 1;
>>
>> mutex_unlock(>struct_mutex);
>> if (dev->driver->master_create) {
>> ret = dev->driver->master_create(dev, priv->master);
>> if (ret) {
>> -   mutex_lock(>struct_mutex);
>> /* drop both references if this fails */
>> drm_master_put(>minor->master);
>> drm_master_put(>master);
>> -   mutex_unlock(>struct_mutex);
> drm_master_put() resets the pointers to NULL. So _if_ the locking
> above is needed, then this one _must_ stay, too.

It's unneeded, so this should be OK. As for drm_file::master, it should
be considered immutable, except for
drm_file open() and release() where nobody is racing us.

>
> I also don't quite understand why you move the struct_mutex locking
> into drm_master_destroy() instead of requiring callers to lock it as
> before? I mean, the whole function is protected by the lock..
>
>> goto out_close;
>> }
>> }
>> -   mutex_lock(>struct_mutex);
>> if (dev->driver->master_set) {
>> ret = dev->driver->master_set(dev, priv, true);
> vmwgfx is the only driver using that, so I guess you reviewed this 
> lock-change.

Yes.

>
>> if (ret) {
>> /* drop both references if this fails */
>> drm_master_put(>minor->master);
>> drm_master_put(>master);
> same as above

No change needed.

>
>> -   mutex_unlock(>struct_mutex);
>> goto out_close;
>> }
>> }
>> @@ -274,8 +272,8 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>> /* get a reference to the master */
>> priv->master = drm_master_get(priv->minor->master);
>> }
>> -   mutex_unlock(>struct_mutex);
>>
>> +   mutex_unlock(>master_mutex);
> Weird white-space change..

Will fix.

>
>> mutex_lock(>struct_mutex);
>> list_add(>lhead, >filelist);
>> mutex_unlock(>struct_mutex);

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2014-03-21:
- Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
  flicker for fastbooting.
- More flexible cloning for hdmi (Ville).
- Some PPGTT fixes from Ben.
- Ring init fixes from Naresh Kumar.
- set_cache_level regression fixes for the vma conversion from Ville
- Conversion to the new dp aux helpers (Jani).
- Unification of runtime pm with pc8 support from Paulo, prep work for runtime
  pm on other platforms than HSW.
- Larger cursor sizes (Sagar Kamble).
- Piles of improvements and fixes all over, as usual.

Final feature pull request for 3.15!

Note that the runtime pm stuff here is still a bit wobbly and occasionally
spews a warn on hsw (not enabled anywhere else yet). But it doesn't kill
the driver and we have patches for them. But since it's tricky business
and I wanted to make sure we're fully covered with igts they're not yet
included here.

Cheers, Daniel


The following changes since commit 5a08c07526e9586318c5b57fd90af4350f83e26e:

  Merge branch 'topic/core-stuff' of git://git.freedesktop.org/git/drm-intel 
into drm-next (2014-03-18 19:23:22 +1000)

are available in the git repository at:


  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-03-21

for you to fetch changes up to 698b3135acb94e838a33a69f1a7a684fe0d90734:

  drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64 
(2014-03-21 16:13:14 +0100)


- Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
  flicker for fastbooting.
- More flexible cloning for hdmi (Ville).
- Some PPGTT fixes from Ben.
- Ring init fixes from Naresh Kumar.
- set_cache_level regression fixes for the vma conversion from Ville
- Conversion to the new dp aux helpers (Jani).
- Unification of runtime pm with pc8 support from Paulo, prep work for runtime
  pm on other platforms than HSW.
- Larger cursor sizes (Sagar Kamble).
- Piles of improvements and fixes all over, as usual.


Ben Widawsky (10):
  drm/i915/bdw: Use scratch page table for GEN8 PPGTT
  drm/i915: Correct PPGTT total size
  drm/i915: Actually capture PP_DIR_BASE on error
  drm/i915/bdw: Restore PPAT on thaw
  drm/i915: Reorganize the overclock code
  drm/i915: Fix coding style for RPS
  drm/i915: Store the HW min frequency as min_freq
  drm/i915: Rename and comment all the RPS *stuff*
  drm/i915: Remove extraneous MMIO for RPS
  drm/i915: remove rps local variables

Chris Wilson (11):
  drm/i915: Process page flags once rather than per pwrite/pread
  drm/i915: Do not force non-caching copies for pwrite along shmem path
  drm/i915: Prevent use-after-free of inherited framebuffer
  drm/i915: Avoid requesting a zero-sized stolen object
  drm/i915: Show cursor status in debugfs/i915_display_info
  drm/i915: Reset forcewake before suspend
  drm/i915: Consolidate forcewake resetting to a single function
  drm/i915: Per-process stats work better when evaluated per-process
  drm/i915: Print how many objects are shared in per-process stats
  drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
  drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64

Damien Lespiau (4):
  drm/i915/bdw: The TLB invalidation mechanism has been removed from INSTPM
  drm/i915: Remove spurious '()' in WARN macros
  drm/i915: Rename intel_setup_wm_latency() to ilk_setup_wm_latency()
  drm/i915: Use the correct format string modifier for ptrdiff_t

Daniel Vetter (6):
  drm/i915: move dev_priv->suspend around
  Merge tag 'v3.14-rc6' into drm-intel-next-queued
  drm/i915: Remove erronous WARN in the vlv pipe crc code
  drm/i915: Fix up the forcewake timer initialization
  drm/i915: catch forcewake reference underruns
  Merge branch 'topic/dp-aux-rework' into drm-intel-next-queued

Imre Deak (1):
  drm/i915: fix typo in display IRQ mask when disabling IRQs

Jani Nikula (8):
  drm/dp: let drivers specify the name of the I2C-over-AUX adapter
  drm/i915/dp: split edp_panel_vdd_on() for reuse
  drm/i915/dp: move edp vdd enable/disable at a lower level in i2c-over-aux
  drm/i915/dp: use the new drm helpers for dp aux
  drm/i915/dp: move dp aux ch register init to aux init
  drm/i915/dp: use the new drm helpers for dp i2c-over-aux
  drm/i915: finish off reverting eDP VDD changes
  drm/i915/sdvo: fix questionable return value check

Jesse Barnes (6):
  drm/i915: add plane_config fetching infrastructure v2
  drm/i915: get_plane_config for i9xx v13
  drm/i915: get_plane_config support for ILK+ v3
  drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS 
fbcon v12
  drm/i915: remove early fb allocation dependency on CONFIG_FB v2
  drm/i915/vlv: no MCHBAR on VLV

Matt Roper (1):
  

[PATCHv4 10/13] drm: Add drm_crtc_init_with_planes()

[Daniel Vetter]

On Fri, Mar 28, 2014 at 1:44 AM, Matt Roper  
wrote:
> Add a new drm_crtc_init_with_planes() to allow drivers to provide
> specific primary and cursor planes at CRTC initialization.  The existing
> drm_crtc_init() interface remains to avoid driver churn in existing
> drivers; it will initialize the CRTC with a plane helper-created primary
> plane and no cursor plane.
>
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_crtc.c | 44 +---
>  include/drm/drm_crtc.h | 11 +++
>  2 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 24226de..a983311 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "drm_crtc_internal.h"
>
> @@ -692,9 +693,12 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
>  EXPORT_SYMBOL(drm_framebuffer_remove);
>
>  /**
> - * drm_crtc_init - Initialise a new CRTC object
> + * drm_crtc_init_with_planes - Initialise a new CRTC object with
> + *specified primary and cursor planes.
>   * @dev: DRM device
>   * @crtc: CRTC object to init
> + * @primary: Primary plane for CRTC
> + * @cursor: Cursor plane for CRTC
>   * @funcs: callbacks for the new CRTC
>   *
>   * Inits a new object created as base part of a driver crtc object.
> @@ -702,8 +706,10 @@ EXPORT_SYMBOL(drm_framebuffer_remove);
>   * Returns:
>   * Zero on success, error code on failure.
>   */
> -int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> -  const struct drm_crtc_funcs *funcs)
> +int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
> + struct drm_plane *primary,
> + struct drm_plane *cursor,
> + const struct drm_crtc_funcs *funcs)
>  {

I'm not sure we should add a spare parameter for the cursor planes
just yet. Or at least not quite with this type, just a void * to avoid
driver changes once we do add cursor plane support. I'll explain my
reasoning in a mail to your rfc re the cursor patches.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

[Thomas Hellstrom]

The master management was previously protected by the drm_device::struct_mutex.
In order to avoid locking order violations in a reworked dropped master
security check in the vmwgfx driver, break it out into a separate master_mutex.
Locking order is master_mutex -> struct_mutex.

Also remove drm_master::blocked since it's not used.

v2: Add an inline comment about what drm_device::master_mutex is protecting.
v3: Remove unneeded struct_mutex locks. Fix error returns in
drm_setmaster_ioctl().

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
---
 drivers/gpu/drm/drm_fops.c |   22 ++---
 drivers/gpu/drm/drm_stub.c |   43 ++---
 include/drm/drmP.h |   46 
 3 files changed, 64 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index c7792b1..a0ce39c 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -231,12 +231,11 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,

/* if there is no current master make this fd it, but do not create
 * any master object for render clients */
-   mutex_lock(>struct_mutex);
+   mutex_lock(>master_mutex);
if (drm_is_primary_client(priv) && !priv->minor->master) {
/* create a new master */
priv->minor->master = drm_master_create(priv->minor);
if (!priv->minor->master) {
-   mutex_unlock(>struct_mutex);
ret = -ENOMEM;
goto out_close;
}
@@ -244,29 +243,23 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
priv->is_master = 1;
/* take another reference for the copy in the local file priv */
priv->master = drm_master_get(priv->minor->master);
-
priv->authenticated = 1;

-   mutex_unlock(>struct_mutex);
if (dev->driver->master_create) {
ret = dev->driver->master_create(dev, priv->master);
if (ret) {
-   mutex_lock(>struct_mutex);
/* drop both references if this fails */
drm_master_put(>minor->master);
drm_master_put(>master);
-   mutex_unlock(>struct_mutex);
goto out_close;
}
}
-   mutex_lock(>struct_mutex);
if (dev->driver->master_set) {
ret = dev->driver->master_set(dev, priv, true);
if (ret) {
/* drop both references if this fails */
drm_master_put(>minor->master);
drm_master_put(>master);
-   mutex_unlock(>struct_mutex);
goto out_close;
}
}
@@ -274,7 +267,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
/* get a reference to the master */
priv->master = drm_master_get(priv->minor->master);
}
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>master_mutex);

mutex_lock(>struct_mutex);
list_add(>lhead, >filelist);
@@ -302,6 +295,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
return 0;

 out_close:
+   mutex_unlock(>master_mutex);
if (dev->driver->postclose)
dev->driver->postclose(dev, priv);
 out_prime_destroy:
@@ -489,11 +483,13 @@ int drm_release(struct inode *inode, struct file *filp)
}
mutex_unlock(>ctxlist_mutex);

-   mutex_lock(>struct_mutex);
+   mutex_lock(>master_mutex);

if (file_priv->is_master) {
struct drm_master *master = file_priv->master;
struct drm_file *temp;
+
+   mutex_lock(>struct_mutex);
list_for_each_entry(temp, >filelist, lhead) {
if ((temp->master == file_priv->master) &&
(temp != file_priv))
@@ -512,6 +508,7 @@ int drm_release(struct inode *inode, struct file *filp)
master->lock.file_priv = NULL;
wake_up_interruptible_all(>lock.lock_queue);
}
+   mutex_unlock(>struct_mutex);

if (file_priv->minor->master == file_priv->master) {
/* drop the reference held my the minor */
@@ -521,10 +518,13 @@ int drm_release(struct inode *inode, struct file *filp)
}
}

-   /* drop the reference held my the file priv */
+   /* drop the master reference held by the file priv */
if (file_priv->master)

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

[Thomas Hellstrom]

On 03/28/2014 01:19 AM, David Herrmann wrote:
> Hi
>
>
>
> I also don't quite understand why you move the struct_mutex locking
> into drm_master_destroy() instead of requiring callers to lock it as
> before? I mean, the whole function is protected by the lock..

Before, struct_mutex was required outside of drm_master_put(), because
the argument to drm_master_put was
also protected by struct_mutex. Now that's no longer the case and I
chose to move the locking into the destructor, avoiding a
number of unnecessary struct_mutex locks (the master destructor is
called more seldom than master_put()).
Also in general I believe one should avoid locking around unreferencing
if possible, because it leads to ugly constructs (and even static code
analyzers complaining) if the lock has to be temporarily released in the
destructor to avoid locking order violations.
But in the end I guess that's really a matter of taste.

/Thomas

[PATCH] modetest: consider supported formats before selecting a DRM plane

[Fabien DESSENNE]

This fixes an issue where the DRM planes do not support the same pixel
formats.
The current implementation selects a DRM plane without checking whether
the pixel format is supported or not. As a consequence modetest may try
to set up a plane not supporting the user request-format, which fails.
Modetest has to check the supported formats accross the plane list before
selecting a candidate.

Signed-off-by: Fabien Dessenne 
---
 tests/modetest/modetest.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 4761c60..866ea82 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -951,7 +951,7 @@ static int set_plane(struct device *dev, struct plane_arg 
*p)
int crtc_x, crtc_y, crtc_w, crtc_h;
struct crtc *crtc = NULL;
unsigned int pipe;
-   unsigned int i;
+   unsigned int i, j;

/* Find an unused plane which can be connected to our CRTC. Find the
 * CRTC index first, then iterate over available planes.
@@ -974,8 +974,11 @@ static int set_plane(struct device *dev, struct plane_arg 
*p)
if (!ovr)
continue;

-   if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id)
-   plane_id = ovr->plane_id;
+   if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id) {
+   for (j = 0; j < ovr->count_formats; j++)
+   if (!strncmp(p->format_str, (char *) 
>formats[j], 4))
+   plane_id = ovr->plane_id;
+   }
}

if (!plane_id) {
-- 
1.9.0

[PATCH 1/3] drm/exynos: add super device support

[Inki Dae]

Hi Philipp,


2014-03-27 23:46 GMT+09:00 Philipp Zabel :
> Hi Inki,
>
> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae:
>> This patch adds super device support to bind sub drivers
>> using device tree.
>>
>> For this, you should add a super device node to each machine dt files
>> like belows,
>>
>> In case of using MIPI-DSI,
>>   exynos-drm {
>>   compatible = "samsung,exynos-drm";
>>   crtcs = <>;
>>   connectors = <>;
>>   };
>
> Russell had suggested a similar binding for i.MX, but we have since
> changed it to look like this instead:
>
> -   imx-drm {
> -   compatible = "fsl,imx-drm";
> -   crtcs = < 0>, < 1>;
> -   connectors = <>, <>;
> -   };
> +   display-subsystem {
> +   compatible = "fsl,imx-display-subsystem";
> +   ports = <_di0>, <_di1>;
> +   };
>
> The ports are the two display output port nodes of the image processing
> unit (corresponding to a drm_crtc each), and the imx-drm driver that
> binds to the compatible value "fsl,imx-display-subsystem" automatically
> collects all encoders that hang off of those via the OF graph bindings
> (as documented in Documentation/devicetree/bindings/graph.txt in the
> staging tree). I don't know how well those bindings would fit on Exynos,
> maybe you could consider aligning your bindings with those.
>
> Either way, the generic term 'display-subsystem' is preferable to 'drm',
> as the latter is Linux specific, which the device tree bindings
> shouldn't be. The same goes for the 'crtcs' property. I'd prefer to
> avoid Linux specific legacy names in new device tree bindings.

Agree. I also thought that using property names, drm, crtcs and
connectors,  specific to Linux is not reasonable. It looks good to use
'display-subsystem' instead of 'drm'.
But only using 'ports' property for only crtc device is not clear to me.

In case of Exynos SoC, there are various types of bridge device, image
enhancer between crtc and encoder device, and lvds device between
encoder and panel device.
So I think Exynos drm core would be complicated with some binding
codes if we use only 'ports' property.
I guess 'imx_drm_components' list specific to imx drm would be among
them, and that would be because you could resolve the probe order
issue only using existing component framework.

Below link shows how we are trying to handle such various bridge devices in drm,
http://www.spinics.net/lists/dri-devel/msg5.html

And this patch series is first step for it.

I'd like to use only component framework without specific list somehow
but we should find generic property names for encoder/connector and
bridge devices.

Thanks,
Inki Dae

>
> Also, since this adds new bindings, it should probably be sent to the
> devicetree mailing list and include some documentation.
>
> If you are interested in the previous discussion on the imx-drm
> supernode, here is the thread history:
> "[PATCH v5 00/11] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg313112.html
> "[PATCH v4 00/11] imx-drm dt bindings"
> http://www.spinics.net/lists/dri-devel/msg54353.html
> "[RFC PATCH v3 0/9] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg308529.html
> "[RFC PATCH v2 0/4] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg306649.html
> "[RFC PATCH 0/3] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg298290.html
>
> regards
> Philipp
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS

[Jani Nikula]

On Fri, 28 Mar 2014, Christoph Jaeger  wrote:
> DRM_DEBUG_KMS includes printing the function name.
>
> Signed-off-by: Christoph Jaeger 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/dvo_ns2501.c | 22 --
>  1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
> b/drivers/gpu/drm/i915/dvo_ns2501.c
> index 954acb2..ce5242f 100644
> --- a/drivers/gpu/drm/i915/dvo_ns2501.c
> +++ b/drivers/gpu/drm/i915/dvo_ns2501.c
> @@ -233,9 +233,8 @@ static enum drm_mode_status ns2501_mode_valid(struct 
> intel_dvo_device *dvo,
> struct drm_display_mode *mode)
>  {
>   DRM_DEBUG_KMS
> - ("%s: is mode valid 
> (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
> -  __FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
> -  mode->vtotal);
> + ("is mode valid (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
> +  mode->hdisplay, mode->htotal, mode->vdisplay, mode->vtotal);
>  
>   /*
>* Currently, these are all the modes I have data from.
> @@ -261,9 +260,8 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>   struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
>  
>   DRM_DEBUG_KMS
> - ("%s: set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
> -  __FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
> -  mode->vtotal);
> + ("set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
> +  mode->hdisplay, mode->htotal, mode->vdisplay, mode->vtotal);
>  
>   /*
>* Where do I find the native resolution for which scaling is not 
> required???
> @@ -277,8 +275,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>   if (mode->hdisplay == 800 && mode->vdisplay == 600) {
>   /* mode 277 */
>   ns->reg_8_shadow &= ~NS2501_8_BPAS;
> - DRM_DEBUG_KMS("%s: switching to 800x600\n",
> -   __FUNCTION__);
> + DRM_DEBUG_KMS("switching to 800x600\n");
>  
>   /*
>* No, I do not know where this data comes from.
> @@ -341,8 +338,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>  
>   } else if (mode->hdisplay == 640 && mode->vdisplay == 480) {
>   /* mode 274 */
> - DRM_DEBUG_KMS("%s: switching to 640x480\n",
> -   __FUNCTION__);
> + DRM_DEBUG_KMS("switching to 640x480\n");
>   /*
>* No, I do not know where this data comes from.
>* It is just what the video bios left in the DVO, so
> @@ -406,8 +402,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
>  
>   } else if (mode->hdisplay == 1024 && mode->vdisplay == 768) {
>   /* mode 280 */
> - DRM_DEBUG_KMS("%s: switching to 1024x768\n",
> -   __FUNCTION__);
> + DRM_DEBUG_KMS("switching to 1024x768\n");
>   /*
>* This might or might not work, actually. I'm silently
>* assuming here that the native panel resolution is
> @@ -458,8 +453,7 @@ static void ns2501_dpms(struct intel_dvo_device *dvo, 
> bool enable)
>   struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
>   unsigned char ch;
>  
> - DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %i\n",
> -   __FUNCTION__, enable);
> + DRM_DEBUG_KMS("Trying set the dpms of the DVO to %i\n", enable);
>  
>   ch = ns->reg_8_shadow;
>  
> -- 
> 1.8.5.3
>

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/3] drm/exynos: add super device support

[Inki Dae]

Sorry for typo.

2014-03-28 19:46 GMT+09:00 Inki Dae :
> Hi Philipp,
>
>
> 2014-03-27 23:46 GMT+09:00 Philipp Zabel :
>> Hi Inki,
>>
>> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae:
>>> This patch adds super device support to bind sub drivers
>>> using device tree.
>>>
>>> For this, you should add a super device node to each machine dt files
>>> like belows,
>>>
>>> In case of using MIPI-DSI,
>>>   exynos-drm {
>>>   compatible = "samsung,exynos-drm";
>>>   crtcs = <>;
>>>   connectors = <>;
>>>   };
>>
>> Russell had suggested a similar binding for i.MX, but we have since
>> changed it to look like this instead:
>>
>> -   imx-drm {
>> -   compatible = "fsl,imx-drm";
>> -   crtcs = < 0>, < 1>;
>> -   connectors = <>, <>;
>> -   };
>> +   display-subsystem {
>> +   compatible = "fsl,imx-display-subsystem";
>> +   ports = <_di0>, <_di1>;
>> +   };
>>
>> The ports are the two display output port nodes of the image processing
>> unit (corresponding to a drm_crtc each), and the imx-drm driver that
>> binds to the compatible value "fsl,imx-display-subsystem" automatically
>> collects all encoders that hang off of those via the OF graph bindings
>> (as documented in Documentation/devicetree/bindings/graph.txt in the
>> staging tree). I don't know how well those bindings would fit on Exynos,
>> maybe you could consider aligning your bindings with those.
>>
>> Either way, the generic term 'display-subsystem' is preferable to 'drm',
>> as the latter is Linux specific, which the device tree bindings
>> shouldn't be. The same goes for the 'crtcs' property. I'd prefer to
>> avoid Linux specific legacy names in new device tree bindings.
>
> Agree. I also thought that using property names, drm, crtcs and
> connectors,  specific to Linux is not reasonable. It looks good to use
> 'display-subsystem' instead of 'drm'.
> But only using 'ports' property for only crtc device is not clear to me.
>
> In case of Exynos SoC, there are various types of bridge device, image
> enhancer between crtc and encoder device, and lvds device between
> encoder and panel device.
> So I think Exynos drm core would be complicated with some binding
> codes if we use only 'ports' property.
> I guess 'imx_drm_components' list specific to imx drm would be among
> them, and that would be because you could resolve the probe order

s/could/couldn't

> issue only using existing component framework.
>
> Below link shows how we are trying to handle such various bridge devices in 
> drm,
> http://www.spinics.net/lists/dri-devel/msg5.html
>
> And this patch series is first step for it.
>
> I'd like to use only component framework without specific list somehow
> but we should find generic property names for encoder/connector and
> bridge devices.
>
> Thanks,
> Inki Dae
>
>>
>> Also, since this adds new bindings, it should probably be sent to the
>> devicetree mailing list and include some documentation.
>>
>> If you are interested in the previous discussion on the imx-drm
>> supernode, here is the thread history:
>> "[PATCH v5 00/11] imx-drm dt bindings"
>> http://www.spinics.net/lists/arm-kernel/msg313112.html
>> "[PATCH v4 00/11] imx-drm dt bindings"
>> http://www.spinics.net/lists/dri-devel/msg54353.html
>> "[RFC PATCH v3 0/9] imx-drm dt bindings"
>> http://www.spinics.net/lists/arm-kernel/msg308529.html
>> "[RFC PATCH v2 0/4] imx-drm dt bindings"
>> http://www.spinics.net/lists/arm-kernel/msg306649.html
>> "[RFC PATCH 0/3] imx-drm dt bindings"
>> http://www.spinics.net/lists/arm-kernel/msg298290.html
>>
>> regards
>> Philipp
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

[David Herrmann]

Hi

On Fri, Mar 28, 2014 at 10:34 AM, Thomas Hellstrom
 wrote:
> The master management was previously protected by the 
> drm_device::struct_mutex.
> In order to avoid locking order violations in a reworked dropped master
> security check in the vmwgfx driver, break it out into a separate 
> master_mutex.
> Locking order is master_mutex -> struct_mutex.
>
> Also remove drm_master::blocked since it's not used.
>
> v2: Add an inline comment about what drm_device::master_mutex is protecting.
> v3: Remove unneeded struct_mutex locks. Fix error returns in
> drm_setmaster_ioctl().

Thanks, looks much better now. Tested on hsw, so I'm fine with pushing
this into 3.15.

Thanks
David

[PATCH 1/3] drm/exynos: add super device support

[Inki Dae]

2014-03-27 23:46 GMT+09:00 Philipp Zabel :
> Hi Inki,
>
> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae:
>> This patch adds super device support to bind sub drivers
>> using device tree.
>>
>> For this, you should add a super device node to each machine dt files
>> like belows,
>>
>> In case of using MIPI-DSI,
>>   exynos-drm {
>>   compatible = "samsung,exynos-drm";
>>   crtcs = <>;
>>   connectors = <>;
>>   };
>
> Russell had suggested a similar binding for i.MX, but we have since
> changed it to look like this instead:
>
> -   imx-drm {
> -   compatible = "fsl,imx-drm";
> -   crtcs = < 0>, < 1>;
> -   connectors = <>, <>;
> -   };
> +   display-subsystem {
> +   compatible = "fsl,imx-display-subsystem";
> +   ports = <_di0>, <_di1>;

Is there any reason that ports property should have only crtc device
nodes?  I mean that if all device nodes for crtc and encoder/connector
devices are added to ports property, I think you could remove
imx_drm_components list and relevant codes.

I think this way we could use component framework and super device
node to resolve the probe order issue, and video interfaces nodes to
compose display pipelines.

Thanks,
Inki Dae

> +   };
>
> The ports are the two display output port nodes of the image processing
> unit (corresponding to a drm_crtc each), and the imx-drm driver that
> binds to the compatible value "fsl,imx-display-subsystem" automatically
> collects all encoders that hang off of those via the OF graph bindings
> (as documented in Documentation/devicetree/bindings/graph.txt in the
> staging tree). I don't know how well those bindings would fit on Exynos,
> maybe you could consider aligning your bindings with those.
>
> Either way, the generic term 'display-subsystem' is preferable to 'drm',
> as the latter is Linux specific, which the device tree bindings
> shouldn't be. The same goes for the 'crtcs' property. I'd prefer to
> avoid Linux specific legacy names in new device tree bindings.
>
> Also, since this adds new bindings, it should probably be sent to the
> devicetree mailing list and include some documentation.
>
> If you are interested in the previous discussion on the imx-drm
> supernode, here is the thread history:
> "[PATCH v5 00/11] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg313112.html
> "[PATCH v4 00/11] imx-drm dt bindings"
> http://www.spinics.net/lists/dri-devel/msg54353.html
> "[RFC PATCH v3 0/9] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg308529.html
> "[RFC PATCH v2 0/4] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg306649.html
> "[RFC PATCH 0/3] imx-drm dt bindings"
> http://www.spinics.net/lists/arm-kernel/msg298290.html
>
> regards
> Philipp
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

[Thomas Hellstrom]

On 03/28/2014 12:23 PM, David Herrmann wrote:
> Hi
>
> On Fri, Mar 28, 2014 at 10:34 AM, Thomas Hellstrom
>  wrote:
>> The master management was previously protected by the 
>> drm_device::struct_mutex.
>> In order to avoid locking order violations in a reworked dropped master
>> security check in the vmwgfx driver, break it out into a separate 
>> master_mutex.
>> Locking order is master_mutex -> struct_mutex.
>>
>> Also remove drm_master::blocked since it's not used.
>>
>> v2: Add an inline comment about what drm_device::master_mutex is protecting.
>> v3: Remove unneeded struct_mutex locks. Fix error returns in
>> drm_setmaster_ioctl().
> Thanks, looks much better now. Tested on hsw, so I'm fine with pushing
> this into 3.15.
>
> Thanks
> David
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Thanks. Want a Reviewed-By: or Acked-By: added?

/Thomas

[PATCH v3 00/12] Add DSI display support for Exynos based boards

[Andrzej Hajda]

Hi,

This patchset adds drivers and bindings to the following devices:
- Exynos DSI master,
- S6E8AA0 DSI panel,

It adds also display support in DTS files for the following boards:
- Exynos4210/Trats,
- Exynos4412/Trats2.

The patchset is based on exynos_drm_next branch.

It is the 3rd iteration of the patches, main changes:
- based on exynos_drm_next branch,
- added video interface bindings between DSI host and slave,
  it seems to me to be redundand, and I hope when video interface bindings
  will be stabilized it can become optional,
- GPIOs implemented using gpiod framework,
- removed controversial stuff (toshiba bridge implementation and arndale 
support),
  it will be send in another set of patches

Other changes are described in individual patches.

Regards
Andrzej


Andrzej Hajda (12):
  drm/mipi_dsi: add flags to DSI messages
  drm/mipi_dsi: create dsi devices only for nodes with reg property
  drm/exynos: disallow fbdev initialization if no device is connected
  exynos/dsim: add DT bindings
  drm/exynos: add DSIM driver
  panel/s6e8aa0: add DT bindings
  drm/panel: add S6E8AA0 driver
  ARM: dts: exynos4: add MIPI DSI Master node
  ARM: dts: exynos4210-trats: add panel node
  ARM: dts: exynos4412-trats2: add panel node
  ARM: dts: exynos4210-trats: enable exynos/fimd node
  ARM: dts: exynos4412-trats2: enable exynos/fimd node

 .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   56 +
 .../devicetree/bindings/video/exynos_dsim.txt  |   80 +
 arch/arm/boot/dts/exynos4.dtsi |   14 +
 arch/arm/boot/dts/exynos4210-trats.dts |   61 +
 arch/arm/boot/dts/exynos4412-trats2.dts|   70 +
 drivers/gpu/drm/drm_mipi_dsi.c |6 +-
 drivers/gpu/drm/exynos/Kconfig |9 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1525 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   21 +
 drivers/gpu/drm/panel/Kconfig  |7 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1069 ++
 include/drm/drm_mipi_dsi.h |6 +
 16 files changed, 2941 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

-- 
1.8.3.2

[PATCH v3 01/12] drm/mipi_dsi: add flags to DSI messages

[Andrzej Hajda]

This patch adds flags field to mipi_dsi_msg structure and two flags:
- MIPI_DSI_MSG_REQ_ACK - request ACK from peripheral for given message,
- MIPI_DSI_MSG_USE_LPM - use Low Power Mode to transmit message.
The first flag is usually helpful during DSI diagnostic, the second
flag is required by some peripherals during configuration phase.

Signed-off-by: Andrzej Hajda 
---
 include/drm/drm_mipi_dsi.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index d32628a..7209df1 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -17,6 +17,11 @@
 struct mipi_dsi_host;
 struct mipi_dsi_device;

+/* request ACK from peripheral */
+#define MIPI_DSI_MSG_REQ_ACK   BIT(0)
+/* use Low Power Mode to transmit message */
+#define MIPI_DSI_MSG_USE_LPM   BIT(1)
+
 /**
  * struct mipi_dsi_msg - read/write DSI buffer
  * @channel: virtual channel id
@@ -29,6 +34,7 @@ struct mipi_dsi_device;
 struct mipi_dsi_msg {
u8 channel;
u8 type;
+   u16 flags;

size_t tx_len;
const void *tx_buf;
-- 
1.8.3.2

[PATCH v3 03/12] drm/exynos: disallow fbdev initialization if no device is connected

[Andrzej Hajda]

This patch adds explicit check if there is a connector with
connected status before fbdev initialization. It prevents creation
of default fbdev 1024x768 which is unusable on panels with bigger resolutions.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e7c2f2d..e09449a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -237,6 +237,24 @@ static struct drm_fb_helper_funcs 
exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
 };

+bool exynos_drm_fbdev_is_anything_connected(struct drm_device *dev)
+{
+   struct drm_connector *connector;
+   bool ret = false;
+
+   mutex_lock(>mode_config.mutex);
+   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   if (connector->status != connector_status_connected)
+   continue;
+
+   ret = true;
+   break;
+   }
+   mutex_unlock(>mode_config.mutex);
+
+   return ret;
+}
+
 int exynos_drm_fbdev_init(struct drm_device *dev)
 {
struct exynos_drm_fbdev *fbdev;
@@ -248,6 +266,9 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
if (!dev->mode_config.num_crtc || !dev->mode_config.num_connector)
return 0;

+   if (!exynos_drm_fbdev_is_anything_connected(dev))
+   return 0;
+
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev)
return -ENOMEM;
-- 
1.8.3.2

[PATCH v3 02/12] drm/mipi_dsi: create dsi devices only for nodes with reg property

[Andrzej Hajda]

MIPI DSI host node can contain child nodes which are not DSI devices.
Checking for existence of reg property can be used to distinguish such nodes.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index b155ee2..09821f4 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -142,8 +142,12 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
 {
struct device_node *node;

-   for_each_available_child_of_node(host->dev->of_node, node)
+   for_each_available_child_of_node(host->dev->of_node, node) {
+   /* skip nodes without reg property */
+   if (!of_find_property(node, "reg", NULL))
+   continue;
of_mipi_dsi_device_add(host, node);
+   }

return 0;
 }
-- 
1.8.3.2

[PATCH v3 04/12] exynos/dsim: add DT bindings

[Andrzej Hajda]

The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
for DSI bus host bindings [1].
Properties describes its resources: memory, interrupt, clocks,
phy, regulators, frequencies of clocks and video interfaces.

[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt

Signed-off-by: Andrzej Hajda 
---
v2
- added burst and esc clock frequency properties
- add samsung prefix to all frequency props

v3
- reset-gpio changed to reset-gpios property
- added video interface bindings
- properties related to video interface moved to endpoint node

dsim bindings
---
 .../devicetree/bindings/video/exynos_dsim.txt  | 80 ++
 1 file changed, 80 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
new file mode 100644
index 000..33b5730
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -0,0 +1,80 @@
+Exynos MIPI DSI Master
+
+Required properties:
+  - compatible: "samsung,exynos4210-mipi-dsi"
+  - reg: physical base address and length of the registers set for the device
+  - interrupts: should contain DSI interrupt
+  - clocks: list of clock specifiers, must contain an entry for each required
+entry in clock-names
+  - clock-names: should include "bus_clk"and "pll_clk" entries
+  - phys: list of phy specifiers, must contain an entry for each required
+entry in phy-names
+  - phy-names: should include "dsim" entry
+  - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
+  - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
+  - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
+  - #address-cells, #size-cells: should be set respectively to <1> and <0>
+according to DSI host bindings (see MIPI DSI bindings [1])
+
+Optional properties:
+  - samsung,power-domain: a phandle to DSIM power domain node
+
+Child nodes:
+  Should contain DSI peripheral nodes (see MIPI DSI bindings [1]).
+
+Video interfaces:
+  Device node can contain video interface port nodes according to [2].
+  The following are properties specific to those nodes:
+
+  port node:
+- reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port;
+
+  endpoint node of DSI port (reg = 1):
+- samsung,burst-clock-frequency: specifies DSI frequency in high-speed 
burst
+  mode
+- samsung,esc-clock-frequency: specifies DSI frequency in escape mode
+
+[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   dsi at 11C8 {
+   compatible = "samsung,exynos4210-mipi-dsi";
+   reg = <0x11C8 0x1>;
+   interrupts = <0 79 0>;
+   clocks = < 286>, < 143>;
+   clock-names = "bus_clk", "pll_clk";
+   phys = <_phy 1>;
+   phy-names = "dsim";
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,power-domain = <_lcd0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   samsung,pll-clock-frequency = <2400>;
+
+   panel at 1 {
+   reg = <0>;
+   ...
+   port {
+   panel_ep: endpoint {
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 1 {
+   dsi_ep: endpoint {
+   reg = <0>;
+   samsung,burst-clock-frequency = 
<5>;
+   samsung,esc-clock-frequency = 
<2000>;
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+   };
-- 
1.8.3.2

[PATCH v3 06/12] panel/s6e8aa0: add DT bindings

[Andrzej Hajda]

The patch adds bindings for s6e8aa0 panel.
Bindings describes panel resources, boot delays,
display timings, orientation and physical size.

Signed-off-by: Andrzej Hajda 
---
v2
- removed samsung prefix from panel physical size props,
- renamed file to follow convention of panel bindings

v3
- reset-gpio renamed to reset-gpios
- added video interfaces bindings
---
 .../devicetree/bindings/panel/samsung,s6e8aa0.txt  | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt 
b/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
new file mode 100644
index 000..e7ee988
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
@@ -0,0 +1,56 @@
+Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e8aa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin
+  - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+  - power-on-delay: delay after turning regulators on [ms]
+  - reset-delay: delay after reset sequence [ms]
+  - init-delay: delay after initialization sequence [ms]
+  - panel-width-mm: physical panel width [mm]
+  - panel-height-mm: physical panel height [mm]
+  - flip-horizontal: boolean to flip image horizontally
+  - flip-vertical: boolean to flip image vertically
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   panel {
+   compatible = "samsung,s6e8aa0";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   panel-width-mm = <58>;
+   panel-height-mm = <103>;
+   flip-horizontal;
+   flip-vertical;
+
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <57153600>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+   };
-- 
1.8.3.2

[PATCH v3 07/12] drm/panel: add S6E8AA0 driver

[Andrzej Hajda]

The patch adds MIPI-DSI based S6E8AA0 AMOLED LCD panel driver.
Driver uses mipi_dsi bus to communicate with panel and exposes drm_panel
interface.

Signed-off-by: Andrzej Hajda 
---
v2
- added bus error handling,
- set maxmimum DSI packet size on init,
- removed unsupported brightness drm_panel callbacks,
- minor improvements

v3
- switched to gpiod framework,
- minor fixes in error handling
---
 drivers/gpu/drm/panel/Kconfig |7 +
 drivers/gpu/drm/panel/Makefile|1 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c | 1069 +
 3 files changed, 1077 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f0fcb62..4ec874d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -23,4 +23,11 @@ config DRM_PANEL_LD9040
select SPI
select VIDEOMODE_HELPERS

+config DRM_PANEL_S6E8AA0
+   tristate "S6E8AA0 DSI video mode panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4f7dfce..8b92921 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
+obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-s6e8aa0.c
new file mode 100644
index 000..35941d2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -0,0 +1,1069 @@
+/*
+ * MIPI-DSI based s6e8aa0 AMOLED LCD 5.3 inch panel driver.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae, 
+ * Donghwa Lee, 
+ * Joongmock Shin 
+ * Eunchul Kim 
+ * Tomasz Figa 
+ * Andrzej Hajda 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define LDI_MTP_LENGTH 24
+#define GAMMA_LEVEL_NUM25
+#define GAMMA_TABLE_LEN26
+
+#define PANELCTL_SS_MASK   (1 << 5)
+#define PANELCTL_SS_1_800  (0 << 5)
+#define PANELCTL_SS_800_1  (1 << 5)
+#define PANELCTL_GTCON_MASK(7 << 2)
+#define PANELCTL_GTCON_110 (6 << 2)
+#define PANELCTL_GTCON_111 (7 << 2)
+
+#define PANELCTL_CLK1_CON_MASK (7 << 3)
+#define PANELCTL_CLK1_000  (0 << 3)
+#define PANELCTL_CLK1_001  (1 << 3)
+#define PANELCTL_CLK2_CON_MASK (7 << 0)
+#define PANELCTL_CLK2_000  (0 << 0)
+#define PANELCTL_CLK2_001  (1 << 0)
+
+#define PANELCTL_INT1_CON_MASK (7 << 3)
+#define PANELCTL_INT1_000  (0 << 3)
+#define PANELCTL_INT1_001  (1 << 3)
+#define PANELCTL_INT2_CON_MASK (7 << 0)
+#define PANELCTL_INT2_000  (0 << 0)
+#define PANELCTL_INT2_001  (1 << 0)
+
+#define PANELCTL_BICTL_CON_MASK(7 << 3)
+#define PANELCTL_BICTL_000 (0 << 3)
+#define PANELCTL_BICTL_001 (1 << 3)
+#define PANELCTL_BICTLB_CON_MASK   (7 << 0)
+#define PANELCTL_BICTLB_000(0 << 0)
+#define PANELCTL_BICTLB_001(1 << 0)
+
+#define PANELCTL_EM_CLK1_CON_MASK  (7 << 3)
+#define PANELCTL_EM_CLK1_110   (6 << 3)
+#define PANELCTL_EM_CLK1_111   (7 << 3)
+#define PANELCTL_EM_CLK1B_CON_MASK (7 << 0)
+#define PANELCTL_EM_CLK1B_110  (6 << 0)
+#define PANELCTL_EM_CLK1B_111  (7 << 0)
+
+#define PANELCTL_EM_CLK2_CON_MASK  (7 << 3)
+#define PANELCTL_EM_CLK2_110   (6 << 3)
+#define PANELCTL_EM_CLK2_111   (7 << 3)
+#define PANELCTL_EM_CLK2B_CON_MASK (7 << 0)
+#define PANELCTL_EM_CLK2B_110  (6 << 0)
+#define PANELCTL_EM_CLK2B_111  (7 << 0)
+
+#define PANELCTL_EM_INT1_CON_MASK  (7 << 3)
+#define PANELCTL_EM_INT1_000   (0 << 3)
+#define PANELCTL_EM_INT1_001   (1 << 3)
+#define PANELCTL_EM_INT2_CON_MASK  (7 << 0)
+#define PANELCTL_EM_INT2_000   (0 << 0)
+#define PANELCTL_EM_INT2_001   (1 << 0)
+
+#define AID_DISABLE(0x4)
+#define AID_1  (0x5)
+#define AID_2  (0x6)
+#define AID_3  (0x7)
+
+typedef u8 s6e8aa0_gamma_table[GAMMA_TABLE_LEN];
+
+struct s6e8aa0_variant {
+   u8 version;
+   const s6e8aa0_gamma_table *gamma_tables;
+};
+
+struct s6e8aa0 {
+   struct device *dev;
+   struct drm_panel panel;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+   u32 power_on_delay;
+   

[PATCH v3 08/12] ARM: dts: exynos4: add MIPI DSI Master node

[Andrzej Hajda]

This is a common part of DSI node for all Exynos4 boards.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 08452e1..3d14cdb 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -104,6 +104,20 @@
reg = <0x1001 0x400>;
};

+   dsi_0: dsi at 11C8 {
+   compatible = "samsung,exynos4210-mipi-dsi";
+   reg = <0x11C8 0x1>;
+   interrupts = <0 79 0>;
+   samsung,power-domain = <_lcd0>;
+   phys = <_phy 1>;
+   phy-names = "dsim";
+   clocks = < 286>, < 143>;
+   clock-names = "bus_clk", "pll_clk";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
camera {
compatible = "samsung,fimc", "simple-bus";
status = "disabled";
-- 
1.8.3.2

[PATCH v3 05/12] drm/exynos: add DSIM driver

[Andrzej Hajda]

The patch adds driver for Exynos DSI master (DSIM). It is a platform driver
which is registered as exynos_drm_display sub-driver of exynos_drm framework
and implements DRM encoder/connector pair.
It is also MIPI-DSI host driver and provides DSI bus for panels.
It interacts with its panel(s) using drm_panel framework.

Signed-off-by: Andrzej Hajda 
---
v2:
- add support for DSI message flags,
- add support for new DT properties,
- remove brightness DRM property,
- corrected PM handlers,
- minor fixes/improvements

v3:
- panel attach/detach moved to connector detect callback,
- improved error handling,
- removed exynos_drm_initialize callback,
- added video interface handling,
- moved dsi clock properties to dsi endpoint
---
 drivers/gpu/drm/exynos/Kconfig  |9 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1525 +++
 5 files changed, 1551 insertions(+)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 56f9581..5bf5bca 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -39,6 +39,15 @@ config DRM_EXYNOS_DPI
help
  This enables support for Exynos parallel output.

+config DRM_EXYNOS_DSI
+   bool "EXYNOS DRM MIPI-DSI driver support"
+   depends on DRM_EXYNOS
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   default n
+   help
+ This enables support for Exynos MIPI-DSI device.
+
 config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
depends on DRM_EXYNOS && ARCH_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index babcd52..33ae365 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -12,6 +12,7 @@ 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_DPI) += exynos_drm_dpi.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
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 771c87e..2d27ba2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -450,6 +450,12 @@ static int __init exynos_drm_init(void)
goto out_dp;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_DSI
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_dsi;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -566,6 +572,11 @@ out_hdmi:
 out_fimd:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_DSI
+   platform_driver_unregister(_driver);
+out_dsi:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_DP
platform_driver_unregister(_driver);
 out_dp:
@@ -613,6 +624,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_DSI
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_DP
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 2d892f3..4c5cf68 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -370,6 +370,7 @@ static inline int exynos_dpi_remove(struct device *dev) { 
return 0; }
 #endif

 extern struct platform_driver dp_driver;
+extern struct platform_driver dsi_driver;
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
new file mode 100644
index 000..697228e
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -0,0 +1,1525 @@
+/*
+ * Samsung SoC MIPI DSI Master driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Contacts: Tomasz Figa 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "exynos_drm_drv.h"
+
+/* returns true iff both arguments logically differs */
+#define NEQV(a, b) (!(a) ^ !(b))
+
+#define DSIM_STATUS_REG0x0 /* Status register */
+#define DSIM_SWRST_REG 0x4 /* Software 

[PATCH v3 11/12] ARM: dts: exynos4210-trats: enable exynos/fimd node

[Andrzej Hajda]

The patch changes fimd node status to OK.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4210-trats.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 996c7e3..02c6768 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -410,6 +410,10 @@
};
};

+   fimd at 11c0 {
+   status = "okay";
+   };
+
camera {
pinctrl-names = "default";
pinctrl-0 = <>;
-- 
1.8.3.2

[PATCH v3 10/12] ARM: dts: exynos4412-trats2: add panel node

[Andrzej Hajda]

The patch adds s6e8aa0 panel node for trats2.
It adds also trats2 specific properties for DSI
and regulator required by panel.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 66 +
 1 file changed, 66 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..f7070e9 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -71,6 +71,15 @@
enable-active-high;
};

+   lcd_vdd3_reg: voltage-regulator-2 {
+   compatible = "regulator-fixed";
+   regulator-name = "LCD_VDD_2.2V";
+   regulator-min-microvolt = <220>;
+   regulator-max-microvolt = <220>;
+   gpio = < 1 0>;
+   enable-active-high;
+   };
+
/* More to come */
};

@@ -511,6 +520,63 @@
};
};

+   dsi_0: dsi at 11C8 {
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,pll-clock-frequency = <2400>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 1 {
+   reg = <1>;
+
+   dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   samsung,burst-clock-frequency = 
<5>;
+   samsung,esc-clock-frequency = 
<2000>;
+   };
+   };
+   };
+
+   panel at 0 {
+   compatible = "samsung,s6e8aa0";
+   reg = <0>;
+   vdd3-supply = <_vdd3_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   flip-horizontal;
+   flip-vertical;
+   panel-width-mm = <58>;
+   panel-height-mm = <103>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+
+   port {
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+
camera {
pinctrl-0 = <_port_b_clk_active>;
pinctrl-names = "default";
-- 
1.8.3.2

[PATCH v3 12/12] ARM: dts: exynos4412-trats2: enable exynos/fimd node

[Andrzej Hajda]

The patch changes fimd node status to OK.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index f7070e9..53c717b 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -577,6 +577,10 @@
};
};

+   fimd at 11c0 {
+   status = "okay";
+   };
+
camera {
pinctrl-0 = <_port_b_clk_active>;
pinctrl-names = "default";
-- 
1.8.3.2

[PATCH v3 09/12] ARM: dts: exynos4210-trats: add panel node

[Andrzej Hajda]

The patch adds s6e8aa0 panel node for trats.
It adds also trats specific properties for DSI.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4210-trats.dts | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 63cc571..996c7e3 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -353,6 +353,63 @@
};
};

+   dsi_0: dsi at 11C8 {
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,pll-clock-frequency = <2400>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 1 {
+   reg = <1>;
+
+   dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   samsung,burst-clock-frequency = 
<5>;
+   samsung,esc-clock-frequency = 
<2000>;
+   };
+   };
+   };
+
+   panel at 0 {
+   reg = <0>;
+   compatible = "samsung,s6e8aa0";
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   flip-horizontal;
+   flip-vertical;
+   panel-width-mm = <58>;
+   panel-height-mm = <103>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <57153600>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+
+   port {
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+
camera {
pinctrl-names = "default";
pinctrl-0 = <>;
-- 
1.8.3.2

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #11 from Ed Tomlinson  ---
Yes.

-- 
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/20140328/4c126adb/attachment.html>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

[David Herrmann]

Hi

On Fri, Mar 28, 2014 at 12:52 PM, Thomas Hellstrom
 wrote:
> Thanks. Want a Reviewed-By: or Acked-By: added?

Oh, sure:

Reviewed-by: David Herrmann 

Thanks
David

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #12 from Ed Tomlinson  ---
On Thursday 27 March 2014 22:08:20 you wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=75992
> 
> --- Comment #10 from Alex Deucher  ---
> (In reply to comment #9)
> > With thest testing patch removed and the possible fix added I am not seeing
> > corruptions; however the tests are running a 6-7fps vs 30...  It is progress
> > though.
> 
> Are you seeing performance issues with pi->mclk_dpm_key_disabled = 1; as well?

Yes.

Ed

-- 
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/20140328/e851ec36/attachment.html>

[PATCH] drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH, HEIGHT} caps

[Damien Lespiau]

Earlier this week, there was a bit of confusion about those new
capabilities, to the point I think it's better to document the intention
and API contract.

The comment documents the current situation:
 - the radeon driver returns the only valid size for the hw
 - i915 returns the maximun cursor size
 - other drivers fall back to returning 64x64

The common contract is to return a valid cursor size.

Cc: Sagar Kamble 
Cc: Chris Wilson 
Cc: Alex Deucher 
Cc: Imre Deak 
Signed-off-by: Damien Lespiau 
---
 include/uapi/drm/drm.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b06c8ed..ec6b259 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -619,6 +619,15 @@ struct drm_gem_open {
 #define  DRM_PRIME_CAP_EXPORT  0x2
 #define DRM_CAP_TIMESTAMP_MONOTONIC0x6
 #define DRM_CAP_ASYNC_PAGE_FLIP0x7
+/*
+ * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid widthxheight
+ * combination for the hardware cursor. The intention is that a hardware
+ * agnostic userspace can query a cursor plane size to use.
+ *
+ * Note that the cross-driver contract is to merely return a valid size;
+ * drivers are free to attach another meaning on top, eg. i915 returns the
+ * maximum plane size.
+ */
 #define DRM_CAP_CURSOR_WIDTH   0x8
 #define DRM_CAP_CURSOR_HEIGHT  0x9

-- 
1.8.3.1

[PATCH] drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH,HEIGHT} caps

[Chris Wilson]

On Fri, Mar 28, 2014 at 12:31:05PM +, Damien Lespiau wrote:
> Earlier this week, there was a bit of confusion about those new
> capabilities, to the point I think it's better to document the intention
> and API contract.
> 
> The comment documents the current situation:
>  - the radeon driver returns the only valid size for the hw
>  - i915 returns the maximun cursor size
>  - other drivers fall back to returning 64x64
> 
> The common contract is to return a valid cursor size.
> 
> Cc: Sagar Kamble 
> Cc: Chris Wilson 
> Cc: Alex Deucher 
> Cc: Imre Deak 
> Signed-off-by: Damien Lespiau 

Agreed. Imho, it suits us to return the maximum possible size for
-modesetting as it enables a broader range of userspace to use hw
cursors with the only overhead of enlarged WMs.
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH,HEIGHT} caps

[Deucher, Alexander]

> -Original Message-
> From: Damien Lespiau [mailto:damien.lespiau at intel.com]
> Sent: Friday, March 28, 2014 8:31 AM
> To: dri-devel at lists.freedesktop.org
> Cc: intel-gfx at lists.freedesktop.org; Sagar Kamble; Chris Wilson; Deucher,
> Alexander; Imre Deak
> Subject: [PATCH] drm: Specify a bit more the
> DRM_CAP_CURSOR_{WIDTH,HEIGHT} caps
> 
> Earlier this week, there was a bit of confusion about those new
> capabilities, to the point I think it's better to document the intention
> and API contract.
> 
> The comment documents the current situation:
>  - the radeon driver returns the only valid size for the hw
>  - i915 returns the maximun cursor size
>  - other drivers fall back to returning 64x64
> 
> The common contract is to return a valid cursor size.
> 
> Cc: Sagar Kamble 
> Cc: Chris Wilson 
> Cc: Alex Deucher 
> Cc: Imre Deak 
> Signed-off-by: Damien Lespiau 

Reviewed-by: Alex Deucher 

> ---
>  include/uapi/drm/drm.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b06c8ed..ec6b259 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -619,6 +619,15 @@ struct drm_gem_open {
>  #define  DRM_PRIME_CAP_EXPORT0x2
>  #define DRM_CAP_TIMESTAMP_MONOTONIC  0x6
>  #define DRM_CAP_ASYNC_PAGE_FLIP  0x7
> +/*
> + * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid
> widthxheight
> + * combination for the hardware cursor. The intention is that a hardware
> + * agnostic userspace can query a cursor plane size to use.
> + *
> + * Note that the cross-driver contract is to merely return a valid size;
> + * drivers are free to attach another meaning on top, eg. i915 returns the
> + * maximum plane size.
> + */
>  #define DRM_CAP_CURSOR_WIDTH 0x8
>  #define DRM_CAP_CURSOR_HEIGHT0x9
> 
> --
> 1.8.3.1
> 

[PULL] vmwgfx-next

[Thomas Hellstrom]

Dave,
vmwgfx render-node support and drm + ttm changes it depends upon.


The following changes since commit 60f2b4af1258c05e6b037af866be81abc24438f7:

  drm/i915: fix build warning on 32-bit (v2) (2014-03-28 13:40:48 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux tags/vmwgfx-next-2014-03-28

for you to fetch changes up to 03c5b8f077218bec50f1355b76dea405a7112878:

  drm/vmwgfx: Bump driver minor and date (2014-03-28 14:19:05 +0100)


Pull request of 2014-03-28


Thomas Hellstrom (16):
  drm: Have the crtc code only reference master from legacy nodes v2
  drm: Break out ioctl permission check to a separate function v2
  drm: Make control nodes master-less v3
  drm: Improve on minor type helpers v3
  drm: Remove the minor master list
  drm: Protect the master management with a drm_device::master_mutex v3
  drm: Add a function to get the ioctl flags
  drm/vmwgfx: Use a per-device semaphore for reservation protection
  drm/vmwgfx: Reinstate and tighten security around legacy master model
  drm/vmwgfx: Drop authentication requirement on UNREF ioctls
  drm/vmwgfx: Allow prime fds in the surface reference ioctls
  drm/vmwgfx: Tighten security around surface sharing v2
  drm/ttm: Add a ttm_ref_object_exists function
  drm/vmwgfx: Tighten the security around buffer maps
  drm/vmwgfx: Enable render nodes
  drm/vmwgfx: Bump driver minor and date

 drivers/gpu/drm/drm_crtc.c   |   14 +--
 drivers/gpu/drm/drm_drv.c|  132 +++
 drivers/gpu/drm/drm_fops.c   |   26 +++---
 drivers/gpu/drm/drm_stub.c   |   48 +-
 drivers/gpu/drm/ttm/ttm_object.c |   46 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c  |5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c   |   15 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  143 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |9 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c   |9 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|   10 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |   15 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   24 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |  143 +-
 include/drm/drmP.h   |   61 -
 include/drm/ttm/ttm_object.h |4 +
 include/uapi/drm/vmwgfx_drm.h|   12 ++-
 19 files changed, 500 insertions(+), 226 deletions(-)

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #21 from Alex Deucher  ---
(In reply to comment #20)
>  
> When I look at the xrandr output I wonder if the reference frequency is not
> 75MHz for fgrlx? Can the reference even change is this not fixed by the
> hardware?

As far as I know, it's fixed.  I'm not really sure what fglrx is doing. 
Anyway, it's probably easier to just fix the open source driver.

the modes are:
  1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
h: width  1920 start 2448 end 2492 total 2640 skew0 clock   56.2KHz
v: height 1080 start 1084 end 1089 total 1125   clock   50.0Hz

  1920x1080 (0x5a)   74.2MHz +HSync +VSync
h: width  1920 start 2558 end 2602 total 2750 skew0 clock   27.0KHz
v: height 1080 start 1084 end 1089 total 1125   clock   24.0Hz

and the driver ends up calculating the dividers as such:

for 148.5MHz target clock:
(100Mhz * 23.8) / (2 * 8) = 148.75Mhz

for 74.2MHz target clock:
(100Mhz * 23.7) / (2 * 16) = 74.0625Mhz

One would need to tweak radeon_compute_pll_avivo() in radeon_display.c to try
and get dividers that are closer to the target clock.

-- 
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/20140328/54a1fde8/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #13 from Alex Deucher  ---
Created attachment 96532
  --> https://bugs.freedesktop.org/attachment.cgi?id=96532=edit
workaround

Does this patch fix the stability and performance issues?

-- 
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/20140328/e0b7d2b9/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #22 from Christian K?nig  ---
(In reply to comment #21)
> One would need to tweak radeon_compute_pll_avivo() in radeon_display.c to
> try and get dividers that are closer to the target clock.

That was some kind of calculus or rather functional analyesis of finding the
sweet spot for getting the frequency exact without toasting the hardware wasn't
it?

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

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #23 from jeroen  ---
(In reply to comment #21)
> (In reply to comment #20)
> >  
> > When I look at the xrandr output I wonder if the reference frequency is not
> > 75MHz for fgrlx? Can the reference even change is this not fixed by the
> > hardware?
> 
> As far as I know, it's fixed.  I'm not really sure what fglrx is doing. 
> Anyway, it's probably easier to just fix the open source driver.
> 
> the modes are:
>   1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
> h: width  1920 start 2448 end 2492 total 2640 skew0 clock  
> 56.2KHz
> v: height 1080 start 1084 end 1089 total 1125   clock  
> 50.0Hz
> 
>   1920x1080 (0x5a)   74.2MHz +HSync +VSync
> h: width  1920 start 2558 end 2602 total 2750 skew0 clock  
> 27.0KHz
> v: height 1080 start 1084 end 1089 total 1125   clock  
> 24.0Hz
> 
> and the driver ends up calculating the dividers as such:
> 
> for 148.5MHz target clock:
> (100Mhz * 23.8) / (2 * 8) = 148.75Mhz
> 
> for 74.2MHz target clock:
> (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz
> 
> One would need to tweak radeon_compute_pll_avivo() in radeon_display.c to
> try and get dividers that are closer to the target clock.

Isn't that what the OSS driver is currently doing? If you look in the post
history those are the exact values that are currently being used

-- 
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/20140328/423b2042/attachment-0001.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #24 from Christian K?nig  ---
(In reply to comment #23)
> (In reply to comment #21)
> > (In reply to comment #20)
> > >  
> > > When I look at the xrandr output I wonder if the reference frequency is 
> > > not
> > > 75MHz for fgrlx? Can the reference even change is this not fixed by the
> > > hardware?
> > 
> > As far as I know, it's fixed.  I'm not really sure what fglrx is doing. 
> > Anyway, it's probably easier to just fix the open source driver.
> > 
> > the modes are:
> >   1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
> > h: width  1920 start 2448 end 2492 total 2640 skew0 clock  
> > 56.2KHz
> > v: height 1080 start 1084 end 1089 total 1125   clock  
> > 50.0Hz
> > 
> >   1920x1080 (0x5a)   74.2MHz +HSync +VSync
> > h: width  1920 start 2558 end 2602 total 2750 skew0 clock  
> > 27.0KHz
> > v: height 1080 start 1084 end 1089 total 1125   clock  
> > 24.0Hz
> > 
> > and the driver ends up calculating the dividers as such:
> > 
> > for 148.5MHz target clock:
> > (100Mhz * 23.8) / (2 * 8) = 148.75Mhz
> > 
> > for 74.2MHz target clock:
> > (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz
> > 
> > One would need to tweak radeon_compute_pll_avivo() in radeon_display.c to
> > try and get dividers that are closer to the target clock.
> 
> Isn't that what the OSS driver is currently doing? If you look in the post
> history those are the exact values that are currently being used

The problem is that the frequencys are exact enough so that the display device
(Monitor/TV/Whatever) accepts them, but not 100% precise.

E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz
instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz instead.

So as Alex said somebody would need to dig into that and try to improve the
numbers without toasting the hardware.

-- 
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/20140328/3f397ae9/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #25 from jeroen  ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #21)
> > > (In reply to comment #20)
> > > >  
> > > > When I look at the xrandr output I wonder if the reference frequency is 
> > > > not
> > > > 75MHz for fgrlx? Can the reference even change is this not fixed by the
> > > > hardware?
> > > 
> > > As far as I know, it's fixed.  I'm not really sure what fglrx is doing. 
> > > Anyway, it's probably easier to just fix the open source driver.
> > > 
> > > the modes are:
> > >   1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
> > > h: width  1920 start 2448 end 2492 total 2640 skew0 clock  
> > > 56.2KHz
> > > v: height 1080 start 1084 end 1089 total 1125   clock  
> > > 50.0Hz
> > > 
> > >   1920x1080 (0x5a)   74.2MHz +HSync +VSync
> > > h: width  1920 start 2558 end 2602 total 2750 skew0 clock  
> > > 27.0KHz
> > > v: height 1080 start 1084 end 1089 total 1125   clock  
> > > 24.0Hz
> > > 
> > > and the driver ends up calculating the dividers as such:
> > > 
> > > for 148.5MHz target clock:
> > > (100Mhz * 23.8) / (2 * 8) = 148.75Mhz
> > > 
> > > for 74.2MHz target clock:
> > > (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz
> > > 
> > > One would need to tweak radeon_compute_pll_avivo() in radeon_display.c to
> > > try and get dividers that are closer to the target clock.
> > 
> > Isn't that what the OSS driver is currently doing? If you look in the post
> > history those are the exact values that are currently being used
> 
> The problem is that the frequencys are exact enough so that the display
> device (Monitor/TV/Whatever) accepts them, but not 100% precise.
> 
> E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz
> instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz instead.
> 
> So as Alex said somebody would need to dig into that and try to improve the
> numbers without toasting the hardware.

So that would mean for example using fb=29.7   Ref=2   post=10?

Or would that fry the hardware?
Why must it exactly match? Because for fgrlx it seems roughly 30% higher than
needed

-- 
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/20140328/ab29126a/attachment.html>

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

[Laurent Pinchart]

On Friday 28 March 2014 09:32:06 Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 05:44:31PM -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 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.
> > 
> > v2:
> >  - Move plane helpers to a new file (drm_plane_helper.c)
> >  - Tighten checks on update handler (check for scaling, CRTC coverage,
> >subpixel positioning)
> >  - Pass proper panning parameters to modeset interface
> >  - Disallow disabling primary plane (and thus CRTC) if other planes are
> >still active on the CRTC.
> >  - Use a minimal format list that should work on all hardware/drivers.
> >Drivers may call this function with a more accurate plane list to
> >enable additional formats they can support.
> > 
> > Signed-off-by: Matt Roper 
> > ---
> > 
> >  drivers/gpu/drm/Makefile   |   3 +-
> >  drivers/gpu/drm/drm_plane_helper.c | 312 
> >  include/drm/drm_plane_helper.h |  49 ++
> 
> DocBook integration is missing for all the great kerneldoc you've written.

I'd go a bit further than that, there's a chapter on planes in the DocBook 
documentation that should also be updated, otherwise it would get outdated.

> That boils down to adding a new section next to the other helper libraries
> in the drm docbook to pull the kerneldoc in and running make htmldocs to
> make sure the kerneldoc checks out.
> 
> If you want you can add a DOC: overview section and pull that into the
> docbook too, see e.g. how the drm prime helpers are integrated.
> 
> >  3 files changed, 363 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_plane_helper.c
> >  create mode 100644 include/drm/drm_plane_helper.h

-- 
Regards,

Laurent Pinchart

[PATCHv4 04/13] drm/shmobile: Restrict plane loops to only operate on legacy planes

[Laurent Pinchart]

Hi Matt,

Thank you for the patch.

On Thursday 27 March 2014 17:44:29 Matt Roper wrote:
> Ensure that existing driver loops over all planes do not change behavior
> when we begin adding new types of planes (primary and cursor) to the DRM
> plane list in future patches.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Matt Roper 

Acked-by: Laurent Pinchart 

I have a question though. The patch set introduces three plane types, OVERLAY, 
PRIMARY and CURSOR. What should a driver that has no concept of primary plane 
do ? Expose all planes as OVERLAY planes only ?

> ---
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c index 0428076..ea543b4 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> @@ -247,7 +247,7 @@ static void shmob_drm_crtc_start(struct shmob_drm_crtc
> *scrtc) lcdc_write(sdev, LDDDSR, value);
> 
>   /* Setup planes. */
> - list_for_each_entry(plane, >mode_config.plane_list, head) {
> + drm_for_each_legacy_plane(plane, >mode_config.plane_list) {
>   if (plane->crtc == crtc)
>   shmob_drm_plane_setup(plane);
>   }

-- 
Regards,

Laurent Pinchart

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #26 from Alex Deucher  ---
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #23)
> > > (In reply to comment #21)
> > > > (In reply to comment #20)
> > > > >  
> > > > > When I look at the xrandr output I wonder if the reference frequency 
> > > > > is not
> > > > > 75MHz for fgrlx? Can the reference even change is this not fixed by 
> > > > > the
> > > > > hardware?
> > > > 
> > > > As far as I know, it's fixed.  I'm not really sure what fglrx is doing. 
> > > > Anyway, it's probably easier to just fix the open source driver.
> > > > 
> > > > the modes are:
> > > >   1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
> > > > h: width  1920 start 2448 end 2492 total 2640 skew0 clock  
> > > > 56.2KHz
> > > > v: height 1080 start 1084 end 1089 total 1125   clock  
> > > > 50.0Hz
> > > > 
> > > >   1920x1080 (0x5a)   74.2MHz +HSync +VSync
> > > > h: width  1920 start 2558 end 2602 total 2750 skew0 clock  
> > > > 27.0KHz
> > > > v: height 1080 start 1084 end 1089 total 1125   clock  
> > > > 24.0Hz
> > > > 
> > > > and the driver ends up calculating the dividers as such:
> > > > 
> > > > for 148.5MHz target clock:
> > > > (100Mhz * 23.8) / (2 * 8) = 148.75Mhz
> > > > 
> > > > for 74.2MHz target clock:
> > > > (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz
> > > > 
> > > > One would need to tweak radeon_compute_pll_avivo() in radeon_display.c 
> > > > to
> > > > try and get dividers that are closer to the target clock.
> > > 
> > > Isn't that what the OSS driver is currently doing? If you look in the post
> > > history those are the exact values that are currently being used
> > 
> > The problem is that the frequencys are exact enough so that the display
> > device (Monitor/TV/Whatever) accepts them, but not 100% precise.
> > 
> > E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz
> > instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz instead.
> > 
> > So as Alex said somebody would need to dig into that and try to improve the
> > numbers without toasting the hardware.
> 
> So that would mean for example using fb=29.7   Ref=2   post=10?
> 
> Or would that fry the hardware?

That should work.  You aren't likely to fry the hw.  You just don't want to set
a 400 Mhz clock as you monitor properly won't like it.  The hard part is
adjusting the algorithm to reliably calculate a good value for a wide range of
clocks.

> Why must it exactly match?

You want to the clock to accurately match what userspace expects.  So if
userspace expects 148.5MHz and the clock is actually 148.75MHz the actual and
expected frame rate will be slightly off.

-- 
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/20140328/23e767b3/attachment-0001.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #27 from Christian K?nig  ---
(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > (In reply to comment #23)
> > > The problem is that the frequencys are exact enough so that the display
> > > device (Monitor/TV/Whatever) accepts them, but not 100% precise.
> > > 
> > > E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz
> > > instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz 
> > > instead.
> > > 
> > > So as Alex said somebody would need to dig into that and try to improve 
> > > the
> > > numbers without toasting the hardware.
> > 
> > So that would mean for example using fb=29.7   Ref=2   post=10?
> > 
> > Or would that fry the hardware?
> 
> That should work.  You aren't likely to fry the hw.  You just don't want to
> set a 400 Mhz clock as you monitor properly won't like it.  The hard part is
> adjusting the algorithm to reliably calculate a good value for a wide range
> of clocks.

I'm not sure if those values would work. A post divider of 10 might result in a
to high VCO and that could indeed damage the hardware (even if that's rather
unlikely).

Essentially the target clock multiplied with the post divider must be in a
certain range. I think between pll->pll_out_max and pll->pll_out_min.

I think the problem is that we don't try to choose a good value to match the
target frequency as close as possible in avivo_get_post_div, but just a value
that either matches the maximum or minimum VCO frequency.

-- 
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/20140328/1f5e5489/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #28 from jeroen  ---
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > (In reply to comment #24)
> > > > (In reply to comment #23)
> > > > The problem is that the frequencys are exact enough so that the display
> > > > device (Monitor/TV/Whatever) accepts them, but not 100% precise.
> > > > 
> > > > E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz
> > > > instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz 
> > > > instead.
> > > > 
> > > > So as Alex said somebody would need to dig into that and try to improve 
> > > > the
> > > > numbers without toasting the hardware.
> > > 
> > > So that would mean for example using fb=29.7   Ref=2   post=10?
> > > 
> > > Or would that fry the hardware?
> > 
> > That should work.  You aren't likely to fry the hw.  You just don't want to
> > set a 400 Mhz clock as you monitor properly won't like it.  The hard part is
> > adjusting the algorithm to reliably calculate a good value for a wide range
> > of clocks.
> 
> I'm not sure if those values would work. A post divider of 10 might result
> in a to high VCO and that could indeed damage the hardware (even if that's
> rather unlikely).
> 
> Essentially the target clock multiplied with the post divider must be in a
> certain range. I think between pll->pll_out_max and pll->pll_out_min.
> 
> I think the problem is that we don't try to choose a good value to match the
> target frequency as close as possible in avivo_get_post_div, but just a
> value that either matches the maximum or minimum VCO frequency.

Perhaps before somebody is going to modify the algorithm, it is a good idea to
verify that this is indeed the problem.
If this is the problem why don't more people have these problems?

If I know which values for fb,ref and post to use for 23.976fps I can hard code
these In a patch and test if it indeed works.

So which values are save to get a clock of 74.2MHz?

-- 
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/20140328/dba7afc7/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #29 from Christian K?nig  ---
(In reply to comment #28)
> Perhaps before somebody is going to modify the algorithm, it is a good idea
> to verify that this is indeed the problem.
> If this is the problem why don't more people have these problems?
> 
> If I know which values for fb,ref and post to use for 23.976fps I can hard
> code these In a patch and test if it indeed works.
> 
> So which values are save to get a clock of 74.2MHz?

I've already hacked together a patch that from inituial testing seems to work
fine.

Just give me a about an hour to clean that up and then I will attach it so you
can test.

-- 
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/20140328/99e01759/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #14 from Ed Tomlinson  ---
disable_mclk_switching = true; gives 30fps and corruption (and eventually a gpu
stall)

disable_mclk_switching = true; and pi->mclk_dpm_key_disabled = 1; no
corruptions but speed is slow

with mclk_switching = true; and the patch disabling WREG32 setups, I get 30fps
& corruptions and gpu stalls/crashes

Ideas?

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

[PATCH] drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS

[Daniel Vetter]

On Fri, Mar 28, 2014 at 12:49:26PM +0200, Jani Nikula wrote:
> On Fri, 28 Mar 2014, Christoph Jaeger  wrote:
> > DRM_DEBUG_KMS includes printing the function name.
> >
> > Signed-off-by: Christoph Jaeger 
> 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-Daniel
> 
> 
> > ---
> >  drivers/gpu/drm/i915/dvo_ns2501.c | 22 --
> >  1 file changed, 8 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
> > b/drivers/gpu/drm/i915/dvo_ns2501.c
> > index 954acb2..ce5242f 100644
> > --- a/drivers/gpu/drm/i915/dvo_ns2501.c
> > +++ b/drivers/gpu/drm/i915/dvo_ns2501.c
> > @@ -233,9 +233,8 @@ static enum drm_mode_status ns2501_mode_valid(struct 
> > intel_dvo_device *dvo,
> >   struct drm_display_mode *mode)
> >  {
> > DRM_DEBUG_KMS
> > -   ("%s: is mode valid 
> > (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
> > -__FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
> > -mode->vtotal);
> > +   ("is mode valid (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
> > +mode->hdisplay, mode->htotal, mode->vdisplay, mode->vtotal);
> >  
> > /*
> >  * Currently, these are all the modes I have data from.
> > @@ -261,9 +260,8 @@ static void ns2501_mode_set(struct intel_dvo_device 
> > *dvo,
> > struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
> >  
> > DRM_DEBUG_KMS
> > -   ("%s: set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
> > -__FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
> > -mode->vtotal);
> > +   ("set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
> > +mode->hdisplay, mode->htotal, mode->vdisplay, mode->vtotal);
> >  
> > /*
> >  * Where do I find the native resolution for which scaling is not 
> > required???
> > @@ -277,8 +275,7 @@ static void ns2501_mode_set(struct intel_dvo_device 
> > *dvo,
> > if (mode->hdisplay == 800 && mode->vdisplay == 600) {
> > /* mode 277 */
> > ns->reg_8_shadow &= ~NS2501_8_BPAS;
> > -   DRM_DEBUG_KMS("%s: switching to 800x600\n",
> > - __FUNCTION__);
> > +   DRM_DEBUG_KMS("switching to 800x600\n");
> >  
> > /*
> >  * No, I do not know where this data comes from.
> > @@ -341,8 +338,7 @@ static void ns2501_mode_set(struct intel_dvo_device 
> > *dvo,
> >  
> > } else if (mode->hdisplay == 640 && mode->vdisplay == 480) {
> > /* mode 274 */
> > -   DRM_DEBUG_KMS("%s: switching to 640x480\n",
> > - __FUNCTION__);
> > +   DRM_DEBUG_KMS("switching to 640x480\n");
> > /*
> >  * No, I do not know where this data comes from.
> >  * It is just what the video bios left in the DVO, so
> > @@ -406,8 +402,7 @@ static void ns2501_mode_set(struct intel_dvo_device 
> > *dvo,
> >  
> > } else if (mode->hdisplay == 1024 && mode->vdisplay == 768) {
> > /* mode 280 */
> > -   DRM_DEBUG_KMS("%s: switching to 1024x768\n",
> > - __FUNCTION__);
> > +   DRM_DEBUG_KMS("switching to 1024x768\n");
> > /*
> >  * This might or might not work, actually. I'm silently
> >  * assuming here that the native panel resolution is
> > @@ -458,8 +453,7 @@ static void ns2501_dpms(struct intel_dvo_device *dvo, 
> > bool enable)
> > struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
> > unsigned char ch;
> >  
> > -   DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %i\n",
> > - __FUNCTION__, enable);
> > +   DRM_DEBUG_KMS("Trying set the dpms of the DVO to %i\n", enable);
> >  
> > ch = ns->reg_8_shadow;
> >  
> > -- 
> > 1.8.5.3
> >
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

[PATCHv4 04/13] drm/shmobile: Restrict plane loops to only operate on legacy planes

[Daniel Vetter]

On Fri, Mar 28, 2014 at 04:50:13PM +0100, Laurent Pinchart wrote:
> Hi Matt,
> 
> Thank you for the patch.
> 
> On Thursday 27 March 2014 17:44:29 Matt Roper wrote:
> > Ensure that existing driver loops over all planes do not change behavior
> > when we begin adding new types of planes (primary and cursor) to the DRM
> > plane list in future patches.
> > 
> > Cc: Laurent Pinchart 
> > Signed-off-by: Matt Roper 
> 
> Acked-by: Laurent Pinchart 
> 
> I have a question though. The patch set introduces three plane types, 
> OVERLAY, 
> PRIMARY and CURSOR. What should a driver that has no concept of primary plane 
> do ? Expose all planes as OVERLAY planes only ?

It's a matter of backwards compat with old userspace. primary/cursor are
simply ways to tell the drm core which planes to use to forward the legacy
cursor crtc and which plane will be used for the framebuffer in setCrtc.

So until we have the new atomic interface ready your driver kinda needs to
expose at least a primary plane, otherwise there's no way to even switch
on the crtc.

But besides this backwards compat issue there's no difference and you can
specify whatever plane you want as primary/cursor (or none if you don't
care about old userspace).
-Daniel

> 
> > ---
> >  drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c index 0428076..ea543b4 100644
> > --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > @@ -247,7 +247,7 @@ static void shmob_drm_crtc_start(struct shmob_drm_crtc
> > *scrtc) lcdc_write(sdev, LDDDSR, value);
> > 
> > /* Setup planes. */
> > -   list_for_each_entry(plane, >mode_config.plane_list, head) {
> > +   drm_for_each_legacy_plane(plane, >mode_config.plane_list) {
> > if (plane->crtc == crtc)
> > shmob_drm_plane_setup(plane);
> > }
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> 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

[PATCHv4 04/13] drm/shmobile: Restrict plane loops to only operate on legacy planes

[Daniel Vetter]

On Fri, Mar 28, 2014 at 06:52:50PM +0100, Daniel Vetter wrote:
> On Fri, Mar 28, 2014 at 04:50:13PM +0100, Laurent Pinchart wrote:
> > Hi Matt,
> > 
> > Thank you for the patch.
> > 
> > On Thursday 27 March 2014 17:44:29 Matt Roper wrote:
> > > Ensure that existing driver loops over all planes do not change behavior
> > > when we begin adding new types of planes (primary and cursor) to the DRM
> > > plane list in future patches.
> > > 
> > > Cc: Laurent Pinchart 
> > > Signed-off-by: Matt Roper 
> > 
> > Acked-by: Laurent Pinchart 
> > 
> > I have a question though. The patch set introduces three plane types, 
> > OVERLAY, 
> > PRIMARY and CURSOR. What should a driver that has no concept of primary 
> > plane 
> > do ? Expose all planes as OVERLAY planes only ?
> 
> It's a matter of backwards compat with old userspace. primary/cursor are
> simply ways to tell the drm core which planes to use to forward the legacy
> cursor crtc and which plane will be used for the framebuffer in setCrtc.
> 
> So until we have the new atomic interface ready your driver kinda needs to
> expose at least a primary plane, otherwise there's no way to even switch
> on the crtc.
> 
> But besides this backwards compat issue there's no difference and you can
> specify whatever plane you want as primary/cursor (or none if you don't
> care about old userspace).

Well the NULL primary plane probably needs a bit of work on top of Matt's
patch series here ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

[Daniel Vetter]

On Fri, Mar 28, 2014 at 04:48:42PM +0100, Laurent Pinchart wrote:
> On Friday 28 March 2014 09:32:06 Daniel Vetter wrote:
> > On Thu, Mar 27, 2014 at 05:44:31PM -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 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.
> > > 
> > > v2:
> > >  - Move plane helpers to a new file (drm_plane_helper.c)
> > >  - Tighten checks on update handler (check for scaling, CRTC coverage,
> > >subpixel positioning)
> > >  - Pass proper panning parameters to modeset interface
> > >  - Disallow disabling primary plane (and thus CRTC) if other planes are
> > >still active on the CRTC.
> > >  - Use a minimal format list that should work on all hardware/drivers.
> > >Drivers may call this function with a more accurate plane list to
> > >enable additional formats they can support.
> > > 
> > > Signed-off-by: Matt Roper 
> > > ---
> > > 
> > >  drivers/gpu/drm/Makefile   |   3 +-
> > >  drivers/gpu/drm/drm_plane_helper.c | 312 
> > >  include/drm/drm_plane_helper.h |  49 ++
> > 
> > DocBook integration is missing for all the great kerneldoc you've written.
> 
> I'd go a bit further than that, there's a chapter on planes in the DocBook 
> documentation that should also be updated, otherwise it would get outdated.

Probably better done as part of the patch which actually adds primary
planes, since this here is just the convenience helpers for easier
transition ...
-Daniel

> 
> > That boils down to adding a new section next to the other helper libraries
> > in the drm docbook to pull the kerneldoc in and running make htmldocs to
> > make sure the kerneldoc checks out.
> > 
> > If you want you can add a DOC: overview section and pull that into the
> > docbook too, see e.g. how the drm prime helpers are integrated.
> > 
> > >  3 files changed, 363 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/gpu/drm/drm_plane_helper.c
> > >  create mode 100644 include/drm/drm_plane_helper.h
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

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

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #30 from Christian K?nig  ---
Created attachment 96561
  --> https://bugs.freedesktop.org/attachment.cgi?id=96561=edit
Possible fix

Please try if the attached patch helps.

-- 
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/20140328/e4d93568/attachment.html>

[PATCHv4 10/13] drm: Add drm_crtc_init_with_planes()

[Daniel Vetter]

On Thu, Mar 27, 2014 at 05:44:35PM -0700, Matt Roper wrote:
> Add a new drm_crtc_init_with_planes() to allow drivers to provide
> specific primary and cursor planes at CRTC initialization.  The existing
> drm_crtc_init() interface remains to avoid driver churn in existing
> drivers; it will initialize the CRTC with a plane helper-created primary
> plane and no cursor plane.
> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_crtc.c | 44 +---
>  include/drm/drm_crtc.h | 11 +++
>  2 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 24226de..a983311 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -692,9 +693,12 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
>  EXPORT_SYMBOL(drm_framebuffer_remove);
>  
>  /**
> - * drm_crtc_init - Initialise a new CRTC object
> + * drm_crtc_init_with_planes - Initialise a new CRTC object with
> + *specified primary and cursor planes.
>   * @dev: DRM device
>   * @crtc: CRTC object to init
> + * @primary: Primary plane for CRTC
> + * @cursor: Cursor plane for CRTC
>   * @funcs: callbacks for the new CRTC
>   *
>   * Inits a new object created as base part of a driver crtc object.
> @@ -702,8 +706,10 @@ EXPORT_SYMBOL(drm_framebuffer_remove);
>   * Returns:
>   * Zero on success, error code on failure.
>   */
> -int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> -const struct drm_crtc_funcs *funcs)
> +int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
> +   struct drm_plane *primary,
> +   struct drm_plane *cursor,
> +   const struct drm_crtc_funcs *funcs)
>  {
>   int ret;
>  
> @@ -724,11 +730,41 @@ int drm_crtc_init(struct drm_device *dev, struct 
> drm_crtc *crtc,
>   list_add_tail(>head, >mode_config.crtc_list);
>   dev->mode_config.num_crtc++;
>  
> + crtc->primary = primary;
> + if (primary)
> + primary->possible_crtcs = 1 << drm_crtc_index(crtc);
> +
> + crtc->cursor = cursor;
> + if (cursor)
> + cursor->possible_crtcs = 1 << drm_crtc_index(crtc);
> +
>   out:
>   drm_modeset_unlock_all(dev);
>  
>   return ret;
>  }
> +EXPORT_SYMBOL(drm_crtc_init_with_planes);
> +
> +/**
> + * drm_crtc_init - Legacy CRTC initialization function
> + * @dev: DRM device
> + * @crtc: CRTC object to init
> + * @funcs: callbacks for the new CRTC
> + *
> + * Initialize a CRTC object with a default helper-provided primary plane and 
> no
> + * cursor plane.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> +   const struct drm_crtc_funcs *funcs)
> +{
> + struct drm_plane *primary;
> +
> + primary = drm_primary_helper_create_plane(dev, NULL, 0);
> + return drm_crtc_init_with_planes(dev, crtc, primary, NULL, funcs);
> +}
>  EXPORT_SYMBOL(drm_crtc_init);

I think we should move the drm_crtc_init to drm_plane_helpers.c to be
perfectly strict with the "nothing in drm core should depend upon helpers"
rule for avoiding midlayer mistakes.
-Daniel

>  
>  /**
> @@ -2248,6 +2284,8 @@ int drm_mode_set_config_internal(struct drm_mode_set 
> *set)
>  
>   ret = crtc->funcs->set_config(set);
>   if (ret == 0) {
> + crtc->primary->crtc = crtc;
> +
>   /* crtc->fb must be updated by ->set_config, enforces this. */
>   WARN_ON(fb != crtc->fb);
>   }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 78cf825..e7ed766 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -270,6 +270,8 @@ struct drm_crtc_funcs {
>   * @dev: parent DRM device
>   * @head: list management
>   * @base: base KMS object for ID tracking etc.
> + * @primary: primary plane for this CRTC
> + * @cursor: cursor plane for this CRTC
>   * @enabled: is this CRTC enabled?
>   * @mode: current mode timings
>   * @hwmode: mode timings as programmed to hw regs
> @@ -305,6 +307,10 @@ struct drm_crtc {
>  
>   struct drm_mode_object base;
>  
> + /* primary and cursor planes for CRTC */
> + struct drm_plane *primary;
> + struct drm_plane *cursor;
> +
>   /* framebuffer the connector is currently bound to */
>   struct drm_framebuffer *fb;
>  
> @@ -826,6 +832,11 @@ extern void drm_modeset_lock_all(struct drm_device *dev);
>  extern void drm_modeset_unlock_all(struct drm_device *dev);
>  extern void drm_warn_on_modeset_not_all_locked(struct drm_device *dev);
>  
> +extern int drm_crtc_init_with_planes(struct drm_device *dev,
> +  struct drm_crtc *crtc,
> +  struct drm_plane 

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

Christian K?nig  changed:

   What|Removed |Added

  Attachment #96561|0   |1
is obsolete||

--- Comment #31 from Christian K?nig  ---
Created attachment 96562
  --> https://bugs.freedesktop.org/attachment.cgi?id=96562=edit
Possible fix v2

Sorry just found a stupid typo in the last patch, attached is a new one.

-- 
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/20140328/a6196b96/attachment-0001.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #15 from Alex Deucher  ---
Please attach a copy of your vbios:
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

-- 
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/20140328/0114611f/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #16 from Ed Tomlinson  ---
Created attachment 96568
  --> https://bugs.freedesktop.org/attachment.cgi?id=96568=edit
pcie :01:00.0 rom

-- 
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/20140328/ed9afd8f/attachment.html>

[RFCv3 12/14] drm: Specify cursor plane at CRTC initialization

[Daniel Vetter]

On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote:
> Add cursor plane as a parameter to drm_crtc_init() and update all
> existing DRM drivers to use a helper-provided primary plane.  Passing
> NULL for this parameter indicates that there is no hardware cursor
> supported by the driver and no cursor plane should be provided to
> userspace.
> 
> Signed-off-by: Matt Roper 

Ok, cursor planes. I've poked around in this a lot and unfortunately I
don't think we can achieve nirvana :(

The first direction is automatically getting cursor plane support from
existing drivers using the existing callbacks. The irky thing is that we
don't have any means to sanely unwrap the framebuffer since both the bo
handle used by the legacy cursor ioctl and how a framebuffer would wrap
such a handle isn't generic. And e.g. vmwgfx doesn't even use gem for
those.

So I think we'll have to give up on that and drivers which want to expose
cursors with the atomic ioctls simply have to have proper support.

The other direction is that converted drivers don't need to have support
for legacy ioctls should be possible and is imo something we want - at
least for i915 I don't want to carry around two interfaces doing the same.

Which means we need some way to forward the legacy cursor ioctls to the
new plane callbacks exposed when using cursor planes. Unfortunately we
have a bit an api mismatch between the legacy cursor interfaces:

int (*cursor_set2)(struct drm_crtc *crtc, struct drm_file *file_priv,
   uint32_t handle, uint32_t width, uint32_t height,
   int32_t hot_x, int32_t hot_y);
int (*cursor_move)(struct drm_crtc *crtc, int x, int y);

And the plane interfaces:

int (*update_plane)(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h);
int (*disable_plane)(struct drm_plane *plane);

cursor_set2 with handle == 0 simply maps to a disable_plane call. But any
other call of the legacy ioctls simply maps to an update_plane, but we
don't have all the information available all the time.

- width, height and handle isn't a real concern - we can just wrap this
  all up into a drm private drm framebuffer. As long as the only reference
  to that framebuffer is held by crtc->cursor->fb it will also get cleaned
  up at the right time and so won't extend the lifetime of the underlying
  buffer object. And we don't need to cache width/height anywhere since
  they're accessible through crtc->cursor->fb.

- For the pixel format I think it's ok to always assume RGBA.

- hot_x and hot_y can simply be mapped to new plane properties. I think
  it'd be good for this to be generally available, just to have a
  consistent interface.

- The x/y coordinates of cursor_move are more annoying - userspace
  potentially doesn't supply them, so we need to cache them in the crtc
  struct somewhere. Originally I've thought it would be good to have a
  special struct drm_cursor_plane and use that as the blessed cursor plane
  object in drm_crtc_init_with_planes. But that will wreak havoc with hw
  platforms which have fully unified planes and want to use the same
  struct everywhere. So I think we need to add crtc->cursor_x/y fields.

With these bits we should be able to always create a valid call to
update_plane. Which allows drivers to not implement the legacy
cursor_set/move interface. Of course we also need to go through the drm
core to make sure that all the cursor code also works when crtc->cursor is
set.

To make driver writers life as easy as possible I think we should provide
a default helper for their cursor_update_plane callback which checks that
the update_plane call is indeed valid for a cursor:

- Checks that widht == pitch*bpp since that's what we assume with cursors.

- Checks that there's no scaling going on.

- Checks that the viewport matches the full cursor size.

- Checks that there's no subpixel positioning.

With that the only thing drivers need to do is:
- Kill the handle to bo pointer lookup, just use the one wrapped up in the
  framebuffer object.
- Call the above helper.
- Call into the low-level set_cursor_bo/move_cursor functions - all the
  arguments of the old ioctls have a 1:1 mapping in update_plane, so this
  should be simple.

... and of course they need to set up the cursor plane object.

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

[PATCH v2] drm/omap: Don't dereference list head when the connectors list is empty

[Laurent Pinchart]

Hi Rob,

On Tuesday 24 December 2013 12:58:01 Laurent Pinchart wrote:
> The connectors list iterator returns the list head when the list is
> empty. Fix it by returning NULL in that case.
> 
> Signed-off-by: Laurent Pinchart 

Could you please take this patch in your tree ?

> ---
>  drivers/gpu/drm/omapdrm/omap_fb.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Changes since v1:
> 
> - Use list_first_entry_or_null
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
> b/drivers/gpu/drm/omapdrm/omap_fb.c index f2b8f06..2c3acb3 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
> @@ -302,7 +302,8 @@ struct drm_connector
> *omap_framebuffer_get_next_connector( struct drm_connector *connector =
> from;
> 
>   if (!from)
> - return list_first_entry(connector_list, typeof(*from), head);
> + return list_first_entry_or_null(connector_list, typeof(*from),
> + head);
> 
>   list_for_each_entry_from(connector, connector_list, head) {
>   if (connector != from) {

-- 
Regards,

Laurent Pinchart

[PATCH v2] drm/omap: Don't dereference list head when the connectors list is empty

[Rob Clark]

On Fri, Mar 28, 2014 at 5:56 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Tuesday 24 December 2013 12:58:01 Laurent Pinchart wrote:
>> The connectors list iterator returns the list head when the list is
>> empty. Fix it by returning NULL in that case.
>>
>> Signed-off-by: Laurent Pinchart 
>
> Could you please take this patch in your tree ?

Tomi has been sending pull-req's for omapdrm, so it should probably go
via his tree.

(Tomi, I'll be sending a pull-req in a couple days, so if you don't
have anything queued up for 3.15 it isn't a problem for me to toss
this in, fwiw)

In either case, the patch is:

Reviewed-by: Rob Clark 

>
>> ---
>>  drivers/gpu/drm/omapdrm/omap_fb.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> Changes since v1:
>>
>> - Use list_first_entry_or_null
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
>> b/drivers/gpu/drm/omapdrm/omap_fb.c index f2b8f06..2c3acb3 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
>> @@ -302,7 +302,8 @@ struct drm_connector
>> *omap_framebuffer_get_next_connector( struct drm_connector *connector =
>> from;
>>
>>   if (!from)
>> - return list_first_entry(connector_list, typeof(*from), head);
>> + return list_first_entry_or_null(connector_list, typeof(*from),
>> + head);
>>
>>   list_for_each_entry_from(connector, connector_list, head) {
>>   if (connector != from) {
>
> --
> Regards,
>
> Laurent Pinchart
>

[PATCH] drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDs

[Daniel Thompson]

The 800x600 (SVGA) screen resolution was lacking in the set of
built-in selectable EDID screen resolutions that can be used to
repair misbehaving monitor firmware.

This patch adds the related data set and expands the documentation.
Note that the SVGA bit occupies a different byte to all the existing
users of the established timing bits forcing a rework of the
ESTABLISHED_TIMINGS_BITS macro.

Tested new EDID on an aged (and misbehaving) industrial LCD panel;
existing EDIDs still pass edid-decode's checksum checks.

Signed-off-by: Daniel Thompson 
---
 Documentation/EDID/1024x768.S   |  2 +-
 Documentation/EDID/1280x1024.S  |  2 +-
 Documentation/EDID/1600x1200.S  |  2 +-
 Documentation/EDID/1680x1050.S  |  2 +-
 Documentation/EDID/1920x1080.S  |  2 +-
 Documentation/EDID/800x600.S| 41 +
 Documentation/EDID/HOWTO.txt|  2 +-
 Documentation/EDID/edid.S   | 17 ++---
 drivers/gpu/drm/drm_edid_load.c | 21 -
 9 files changed, 81 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/EDID/800x600.S

diff --git a/Documentation/EDID/1024x768.S b/Documentation/EDID/1024x768.S
index 4b486fe..6f3e4b7 100644
--- a/Documentation/EDID/1024x768.S
+++ b/Documentation/EDID/1024x768.S
@@ -36,7 +36,7 @@
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux XGA"
-#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
+#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
 #define HSYNC_POL 0
 #define VSYNC_POL 0
 #define CRC 0x55
diff --git a/Documentation/EDID/1280x1024.S b/Documentation/EDID/1280x1024.S
index a2799fe..bd9bef2 100644
--- a/Documentation/EDID/1280x1024.S
+++ b/Documentation/EDID/1280x1024.S
@@ -36,7 +36,7 @@
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux SXGA"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0xa0
diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S
index 0ded64c..a45101c 100644
--- a/Documentation/EDID/1600x1200.S
+++ b/Documentation/EDID/1600x1200.S
@@ -36,7 +36,7 @@
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux UXGA"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x9d
diff --git a/Documentation/EDID/1680x1050.S b/Documentation/EDID/1680x1050.S
index 96f67ca..b0d7c69 100644
--- a/Documentation/EDID/1680x1050.S
+++ b/Documentation/EDID/1680x1050.S
@@ -36,7 +36,7 @@
 #define DPI 96
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux WSXGA"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x26
diff --git a/Documentation/EDID/1920x1080.S b/Documentation/EDID/1920x1080.S
index 36ed5d5..3084355e 100644
--- a/Documentation/EDID/1920x1080.S
+++ b/Documentation/EDID/1920x1080.S
@@ -36,7 +36,7 @@
 #define DPI 96
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux FHD"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x05
diff --git a/Documentation/EDID/800x600.S b/Documentation/EDID/800x600.S
new file mode 100644
index 000..6644e26
--- /dev/null
+++ b/Documentation/EDID/800x600.S
@@ -0,0 +1,41 @@
+/*
+   800x600.S: EDID data set for standard 800x600 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+   Copyright (C) 2014 Linaro Limited
+
+   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.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 4 /* kHz */
+#define XPIX 800
+#define YPIX 600
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 256
+#define YBLANK 28
+#define XOFFSET 40
+#define XPULSE 128
+#define YOFFSET (63+1)
+#define YPULSE (63+4)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux SVGA"
+#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */
+#define HSYNC_POL 1
+#define VSYNC_POL 1
+#define CRC 0xc2
+
+#include "edid.S"
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt
index 7146db1..835db33 100644
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/HOWTO.txt
@@ -18,7 +18,7 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to 
provide an
 individually prepared or corrected EDID data set in the /lib/firmware
 directory from where it is loaded via the 

[PATCH] drm/i915: use __func__ instead of __FUNCTION__

[Christoph Jaeger]

__FUNCTION__ is gcc specific; use __func__ instead.

Signed-off-by: Christoph Jaeger 
---
 drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 954acb2..e40cd26 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -234,7 +234,7 @@ static enum drm_mode_status ns2501_mode_valid(struct 
intel_dvo_device *dvo,
 {
DRM_DEBUG_KMS
("%s: is mode valid 
(hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
-__FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
+__func__, mode->hdisplay, mode->htotal, mode->vdisplay,
 mode->vtotal);

/*
@@ -262,7 +262,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,

DRM_DEBUG_KMS
("%s: set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
-__FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
+__func__, mode->hdisplay, mode->htotal, mode->vdisplay,
 mode->vtotal);

/*
@@ -277,8 +277,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
if (mode->hdisplay == 800 && mode->vdisplay == 600) {
/* mode 277 */
ns->reg_8_shadow &= ~NS2501_8_BPAS;
-   DRM_DEBUG_KMS("%s: switching to 800x600\n",
- __FUNCTION__);
+   DRM_DEBUG_KMS("%s: switching to 800x600\n", __func__);

/*
 * No, I do not know where this data comes from.
@@ -341,8 +340,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,

} else if (mode->hdisplay == 640 && mode->vdisplay == 480) {
/* mode 274 */
-   DRM_DEBUG_KMS("%s: switching to 640x480\n",
- __FUNCTION__);
+   DRM_DEBUG_KMS("%s: switching to 640x480\n", __func__);
/*
 * No, I do not know where this data comes from.
 * It is just what the video bios left in the DVO, so
@@ -406,8 +404,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,

} else if (mode->hdisplay == 1024 && mode->vdisplay == 768) {
/* mode 280 */
-   DRM_DEBUG_KMS("%s: switching to 1024x768\n",
- __FUNCTION__);
+   DRM_DEBUG_KMS("%s: switching to 1024x768\n", __func__);
/*
 * This might or might not work, actually. I'm silently
 * assuming here that the native panel resolution is
@@ -459,7 +456,7 @@ static void ns2501_dpms(struct intel_dvo_device *dvo, bool 
enable)
unsigned char ch;

DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %i\n",
- __FUNCTION__, enable);
+ __func__, enable);

ch = ns->reg_8_shadow;

-- 
1.8.5.3

[PATCH] drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS

[Christoph Jaeger]

DRM_DEBUG_KMS includes printing the function name.

Signed-off-by: Christoph Jaeger 
---
 drivers/gpu/drm/i915/dvo_ns2501.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 954acb2..ce5242f 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -233,9 +233,8 @@ static enum drm_mode_status ns2501_mode_valid(struct 
intel_dvo_device *dvo,
  struct drm_display_mode *mode)
 {
DRM_DEBUG_KMS
-   ("%s: is mode valid 
(hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
-__FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
-mode->vtotal);
+   ("is mode valid (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d)\n",
+mode->hdisplay, mode->htotal, mode->vdisplay, mode->vtotal);

/*
 * Currently, these are all the modes I have data from.
@@ -261,9 +260,8 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);

DRM_DEBUG_KMS
-   ("%s: set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
-__FUNCTION__, mode->hdisplay, mode->htotal, mode->vdisplay,
-mode->vtotal);
+   ("set mode (hdisplay=%d,htotal=%d,vdisplay=%d,vtotal=%d).\n",
+mode->hdisplay, mode->htotal, mode->vdisplay, mode->vtotal);

/*
 * Where do I find the native resolution for which scaling is not 
required???
@@ -277,8 +275,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
if (mode->hdisplay == 800 && mode->vdisplay == 600) {
/* mode 277 */
ns->reg_8_shadow &= ~NS2501_8_BPAS;
-   DRM_DEBUG_KMS("%s: switching to 800x600\n",
- __FUNCTION__);
+   DRM_DEBUG_KMS("switching to 800x600\n");

/*
 * No, I do not know where this data comes from.
@@ -341,8 +338,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,

} else if (mode->hdisplay == 640 && mode->vdisplay == 480) {
/* mode 274 */
-   DRM_DEBUG_KMS("%s: switching to 640x480\n",
- __FUNCTION__);
+   DRM_DEBUG_KMS("switching to 640x480\n");
/*
 * No, I do not know where this data comes from.
 * It is just what the video bios left in the DVO, so
@@ -406,8 +402,7 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,

} else if (mode->hdisplay == 1024 && mode->vdisplay == 768) {
/* mode 280 */
-   DRM_DEBUG_KMS("%s: switching to 1024x768\n",
- __FUNCTION__);
+   DRM_DEBUG_KMS("switching to 1024x768\n");
/*
 * This might or might not work, actually. I'm silently
 * assuming here that the native panel resolution is
@@ -458,8 +453,7 @@ static void ns2501_dpms(struct intel_dvo_device *dvo, bool 
enable)
struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
unsigned char ch;

-   DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %i\n",
- __FUNCTION__, enable);
+   DRM_DEBUG_KMS("Trying set the dpms of the DVO to %i\n", enable);

ch = ns->reg_8_shadow;

-- 
1.8.5.3

[PATCH] drm/i915: use __func__ instead of __FUNCTION__

[Christoph Jaeger]

Thanks for review.

This patch obsoletes patch "drm/i915: use __func__ instead of
__FUNCTION__".

Best,
Chris