date:20140305

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

--- Comment #20 from Tom Stellard  ---
You don't need clang for graphics, so you can remove it from the tools
directory.  If you do want to build clang for some reason you need to make sure
your checkout of clang is from roughly the same date and time as the LLVM
checkout you are using.

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

Info: mapping multiple BARs. Your kernel is fine.

2014-03-05 Thread Stephane Eranian

Hi,

Any update on this problem?

On Thu, Feb 27, 2014 at 11:21 PM, Borislav Petkov  wrote:
> On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
>> I won't be able to look at that before Monday I'm afraid (personal
>> stuff).
>
> No worries, sir, whenever. It can wait.
>
> Thanks a lot!
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --

[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation

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

--- Comment #19 from farmboy0+freedesktop at googlemail.com ---
(In reply to comment #17)
> Can you try this branch:
> 
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

I cannot compile your repo with current clang git repo checked out in tools.
Not sure if I am doing something wrong here or something else is.

Heres the first part of the error message:

In file included from
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:57:
error: expected template-name before ?
clang::vfs::OverlayFileSystem::status(const llvm::Twine&)? marked override, but
does not override
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:151:20:
error: ?llvm::error_code clang::vfs::OverlayFileSystem::openFileForRead(const
llvm::Twine&, llvm::OwningPtr&)? marked override, but does
not override
In file included from
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:17:0,
 from
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20,
 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h: In
instantiation of ?static void llvm::IntrusiveRefCntPtrInfo::release(T*)
[with T = clang::vfs::FileSystem]?:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:176:31:  
required from ?void llvm::IntrusiveRefCntPtr::release() [with T =
clang::vfs::FileSystem]?
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:146:29:  
required from ?llvm::IntrusiveRefCntPtr::~IntrusiveRefCntPtr() [with T =
clang::vfs::FileSystem]?
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:166:78:
  required from here
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:89:35: error:
invalid use of incomplete type ?class clang::vfs::FileSystem?
In file included from
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7:
error: forward declaration of ?class clang::vfs::FileSystem?
In file included from
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:17:0,
 from
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20,
 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h: In
instantiation of ?static void llvm::IntrusiveRefCntPtrInfo::retain(T*) [with
T = clang::vfs::FileSystem]?:
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:175:30:  
required from ?void llvm::IntrusiveRefCntPtr::retain() [with T =
clang::vfs::FileSystem]?
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:123:7:  
required from ?llvm::IntrusiveRefCntPtr::IntrusiveRefCntPtr(const
llvm::IntrusiveRefCntPtr&) [with T = clang::vfs::FileSystem;
llvm::IntrusiveRefCntPtr =
llvm::IntrusiveRefCntPtr]?
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:231:12:
  required from here
/home/eho/workspace/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:88:34: error:
invalid use of incomplete type ?class clang::vfs::FileSystem?
In file included from
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/FileManager.h:20:0,
 from HeaderMap.cpp:16:
/home/eho/workspace/llvm/tools/clang/lib/Lex/../../include/clang/Basic/VirtualFileSystem.h:98:7:
error: forward declaration of ?class clang::vfs::FileSystem?

-- 
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/20140305/af4e6822/attachment.html>

[Bug 67994] Lockup with UVD and DPM on RV730

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

--- Comment #12 from Alex Deucher  ---
Is this still an issue with this kernel patch?
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=858a41c853cef2cb01de34dae334c19c1c15b237

-- 
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/20140305/505666a5/attachment.html>

[RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes

Sorry for interrupting,


2014-03-04 21:00 GMT+09:00 Andrzej Hajda :
> On 02/28/2014 02:39 PM, Tomi Valkeinen wrote:
>> On 28/02/14 15:31, Tomi Valkeinen wrote:
>>
>>> Compared to what I've done on OMAP, you don't seem to specify the video
>>> inputs for the tc358764 at all. In this case it's obvious, as the chip
>>> is a child of the DSI master. But the chip could as well be controlled
>>> via i2c, and so be placed as a child of the i2c nodes.
>>>
>>> So even if the driver doesn't use it, maybe it would be more future
>>> proof to have both input and output endpoints for the tc358764?
>> Oh, and one addition: how me and Laurent see the DSI case (and other
>> similar ones), the child/parent relationship gives the control bus path,
>> and the video ports give the video data path.
>>
>> So both are always needed. A DSI panel may be controlled via DSI, i2c,
>> spi, but the video path will always go from DSI master to the panel.
> I have made video path binding optional, in case of video bus
> if the specific video path is not present driver uses the bus it is
> connected to.

You mean the case that video path isn't wrote in dt file for some
machine? If so, shouldn't we always write video patch in the dt file
correctly? I'm not sure the optional binding is needed because which
bus and which panel are used depends on machine.

And If I understood correctly the video interfaces document, it seems
that you don't deal with the document.

The below is simple dt binding I think in case that video path goes
from MIPI-DSI to LVDS bridge, and then from LVDS bridge to LCD Panel,

panel {
...
port {
...
panel_0: endpoint {
remote-endpoint=<_1>;
};
};
};

lvds {
   ...
   port at 1 {
   ...
   lvds_0: endpoint {
   remote-endpoint=<_0>;
   };
   };
   port at 2 {
  ...
  lvds_1: endpoint {
   remote-endpoint=<_0>;
  };
   };
};

dsi {
...
port {
dsi_0: endpoint {
remote-endpoint=<_0>;
};
};
};

panel and lvds node could be a child of other masters, maybe i2c or spi.

Thanks,
Inki Dae


> In case DSI panel is controlled via different bus the path should be
> specified
> explicitly.
>
> I have no strong feelings against making this binding required but as
> you have
> stated above "in this case it's obvious" and for me quite redundant.
>
> What is the gain in specifying explicitly video paths in such cases?
>
>
>> Or, as a theoretical panel, you could have a DSI controlled panel, being
>> a child of the DSI master, but the video data would come via, say,
>> parallel RGB. You can actually do that with some panels/encoders, even
>> if the concept is silly.
>
> In this case explicit binding will work also.
>
> Regards
> Andrzej
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #9 from l.mollari at gmx.net ---
Sure, I am going to give it a try.

-- 
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/20140305/b9bec4d2/attachment.html>

[Bug 75719] mplayer -vo gl consume more CPU on r200

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

--- Comment #13 from smoki  ---
Created attachment 95182
  --> https://bugs.freedesktop.org/attachment.cgi?id=95182=edit
GOOD: 3.14-rc5 and VM_MIXEDMAP

-- 
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/20140305/b93d987d/attachment.html>

[Bug 75719] mplayer -vo gl consume more CPU on r200

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

--- Comment #12 from smoki  ---
Created attachment 95181
  --> https://bugs.freedesktop.org/attachment.cgi?id=95181=edit
BAD: 3.14-rc5 and VM_PFNMAP

(In reply to comment #8)
> 
> 2) If you're familiar with oprofile, it would be very helpful to see a
> profile of a "good" and a "bad" run, including kernel symbols.
>

 Not very familiar but to give it a try :). This is 3.14-rc5 proper kernel with
pfnmap which is bad case here and then oprofiled with pfnmap changed to
mixedmap which is good 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/20140305/43477c53/attachment.html>

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

--- Comment #14 from Chris Rankin  ---
(In reply to comment #13)
> This may help you get a little further.

Actually, I'm hoping that the valgrind output from WoW on my native 32 bit box
will be sufficient. It does seem to show a suspiciously large number of
allocations in the r600 code.

-- 
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/20140305/dcdf16de/attachment.html>

[PATCH] drm/radeon/cs: return an error if no uvd support

2014-03-05 Thread Alex Deucher

When selecting the engine, return an error if the GPU
doesn't have UVD.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_cs.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index dfb5a1d..fa7839b 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -145,7 +145,10 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p, 
u32 ring, s32 priority
}
break;
case RADEON_CS_RING_UVD:
-   p->ring = R600_RING_TYPE_UVD_INDEX;
+   if (p->rdev->has_uvd)
+   p->ring = R600_RING_TYPE_UVD_INDEX;
+   else
+   return -EINVAL;
break;
}
return 0;
-- 
1.8.3.1

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

--- Comment #13 from Nick Tenney  ---
try:
$apitrace /usr/bin/wine /opt/wine/World\ of\ Warcraft/Wow.exe -opengl
-noautoload64bit

To record an apitrace of a little bit of play. It will generate a .trace file
that you can run through valgrind (I believe same options as before, I can't
recall). This may help you get a little further.

-- 
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/20140305/715425ab/attachment.html>

[PATCH 2/2] drm: Remove the minor master list

2014-03-05 Thread David Herrmann

Hi

On Wed, Feb 19, 2014 at 2:40 PM, Thomas Hellstrom  
wrote:
> It doesn't appear to be used anywhere.

Looks good.

Reviewed-by: David Herrmann 

Thanks
David

> Signed-off-by: Thomas Hellstrom 
> ---
>  drivers/gpu/drm/drm_stub.c |5 -
>  include/drm/drmP.h |2 --
>  2 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 98a33c580..4f17c79 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -152,8 +152,6 @@ struct drm_master *drm_master_create(struct drm_minor 
> *minor)
> INIT_LIST_HEAD(>magicfree);
> master->minor = minor;
>
> -   list_add_tail(>head, >master_list);
> -
> return master;
>  }
>
> @@ -171,8 +169,6 @@ static void drm_master_destroy(struct kref *kref)
> struct drm_device *dev = master->minor->dev;
> struct drm_map_list *r_list, *list_temp;
>
> -   list_del(>head);
> -
> if (dev->driver->master_destroy)
> dev->driver->master_destroy(dev, master);
>
> @@ -296,7 +292,6 @@ static int drm_get_minor(struct drm_device *dev, struct 
> drm_minor **minor,
> new_minor->device = MKDEV(DRM_MAJOR, minor_id);
> new_minor->dev = dev;
> new_minor->index = minor_id;
> -   INIT_LIST_HEAD(_minor->master_list);
>
> idr_replace(_minors_idr, new_minor, minor_id);
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index ff68e26..56c519f 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -718,7 +718,6 @@ struct drm_master {
>
> struct kref refcount; /* refcount for this master */
>
> -   struct list_head head; /**< each minor contains a list of masters */
> struct drm_minor *minor; /**< link back to minor we are a master for 
> */
>
> char *unique;   /**< Unique identifier: e.g., busid */
> @@ -1050,7 +1049,6 @@ struct drm_minor {
> struct mutex debugfs_lock; /* Protects debugfs_list. */
>
> struct drm_master *master; /* currently active master for this node */
> -   struct list_head master_list;
> struct drm_mode_group mode_group;
>  };
>
> --
> 1.7.10.4
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 08/21] drm/panel: add TC358764 driver

2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
> The patch adds driver for Toshiba DSI/LVDS TC358764 bridge.
> Driver registers itself as mipi_dsi_driver. It is exposed to the
> system via drm_panel interface, it uses also drm_panel framework
> to interact with LVDS panel connected to it.
> Driver supports only DT bindings.
>
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/panel/Kconfig  |   7 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-tc358764.c | 505 
> +
>  3 files changed, 513 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-tc358764.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 7527557..b98a485 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -23,4 +23,11 @@ config DRM_PANEL_S6E8AA0
> select DRM_MIPI_DSI
> select VIDEOMODE_HELPERS
>
> +config DRM_PANEL_TC358764
> +   tristate "TC358764 DSI/LVDS bridge"
> +   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 181265b..7cbb0cf 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_S6E8AA0) += panel-s6e8aa0.o
> +obj-$(CONFIG_DRM_PANEL_TC358764) += panel-tc358764.o
> diff --git a/drivers/gpu/drm/panel/panel-tc358764.c 
> b/drivers/gpu/drm/panel/panel-tc358764.c
> new file mode 100644
> index 000..f9c1289
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-tc358764.c
> @@ -0,0 +1,505 @@
> +/*
> + * TC358764 MIPI-DSI to LVDS bridge panel driver.
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd
> + *
> + * 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 
...
> +/* of_* functions will be removed after acceptance of of_graph patches */
> +static struct device_node *
> +of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 
> reg)
> +{
> +   struct device_node *np;
> +
> +   for_each_child_of_node(parent, np) {
> +   u32 r;
> +
> +   if (!np->name || of_node_cmp(np->name, name))
> +   continue;
> +
> +   if (of_property_read_u32(np, "reg", ) < 0)
> +   r = 0;
> +
> +   if (reg == r)
> +   break;
> +   }
> +
> +   return np;
> +}
> +
> +static struct device_node *of_graph_get_port_by_reg(struct device_node 
> *parent,
> +   u32 reg)
> +{
> +   struct device_node *ports, *port;
> +
> +   ports = of_get_child_by_name(parent, "ports");
> +   if (ports) {
> +   port = of_get_child_by_name_reg(ports, "port", reg);
> +   of_node_put(ports);
> +   } else {
> +   port = of_get_child_by_name_reg(parent, "port", reg);
> +   }
> +   return port;
> +}
> +
> +static struct device_node *
> +of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
> +{
> +   return of_get_child_by_name_reg(port, "endpoint", reg);
> +}
> +
> +static struct device_node *
> +of_graph_get_remote_port_parent(const struct device_node *node)
> +{
> +   struct device_node *np;
> +   unsigned int depth;
> +
> +   /* Get remote endpoint node. */
> +   np = of_parse_phandle(node, "remote-endpoint", 0);
> +
> +   /* Walk 3 levels up only if there is 'ports' node. */
> +   for (depth = 3; depth && np; depth--) {
> +   np = of_get_next_parent(np);
> +   if (depth == 2 && of_node_cmp(np->name, "ports"))
> +   break;
> +   }
> +   return np;
> +}
> +
> +static struct device_node *tc358764_of_find_panel_node(struct device *dev)
> +{
> +   struct device_node *np, *ep;
> +
> +   np = of_graph_get_port_by_reg(dev->of_node, 1);
> +   if (!np)
> +   return NULL;
> +
> +   ep = of_graph_get_endpoint_by_reg(np, 0);
> +   of_node_put(np);
> +   if (!ep)
> +   return NULL;
> +
> +   np = of_graph_get_remote_port_parent(ep);
> +   of_node_put(ep);
> +
> +   return np;
> +}
> +
> +static int tc358764_parse_dt(struct tc358764 *ctx)
> +{
> +   struct device *dev = ctx->dev;
> +   struct device_node *np = dev->of_node;
> +   struct device_node *lvds;
> +
> +   ctx->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
> +   if (ctx->reset_gpio < 0) {
> +   dev_err(dev, "no reset GPIO pin provided\n");
> +   //return ctx->reset_gpio;

Seem like your mistake.

> +   }

[PATCH 1/2] drm: Make control nodes master-less

2014-03-05 Thread David Herrmann

Hi

On Wed, Feb 19, 2014 at 2:40 PM, Thomas Hellstrom  
wrote:
> Like for render-nodes, there is no point in maintaining the master concept
> for control nodes, so set the struct drm_file::master pointer to NULL.
>
> At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
> allowed when called through the control node. Previously the caller also
> needed to be master.
>
> Signed-off-by: Thomas Hellstrom 
> ---
>  drivers/gpu/drm/drm_drv.c  |5 +++--
>  drivers/gpu/drm/drm_fops.c |5 +++--
>  include/drm/drmP.h |5 +
>  3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 345be03..42af8bd 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -355,8 +355,9 @@ long drm_ioctl(struct file *filp,
> retcode = -EINVAL;
> } else if (((ioctl->flags & DRM_ROOT_ONLY) && 
> !capable(CAP_SYS_ADMIN)) ||
>((ioctl->flags & DRM_AUTH) && 
> !drm_is_render_client(file_priv) && !file_priv->authenticated) ||
> -  ((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
> -  (!(ioctl->flags & DRM_CONTROL_ALLOW) && 
> (file_priv->minor->type == DRM_MINOR_CONTROL)) ||
> +  (((ioctl->flags & DRM_MASTER) && !file_priv->is_master) &&
> +   !(drm_is_control(file_priv) && (ioctl->flags & 
> DRM_CONTROL_ALLOW))) ||
> +  (!(ioctl->flags & DRM_CONTROL_ALLOW) && 
> drm_is_control(file_priv)) ||
>(!(ioctl->flags & DRM_RENDER_ALLOW) && 
> drm_is_render_client(file_priv))) {
> retcode = -EACCES;
> } else {
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 7f2af9a..08a3196 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -259,7 +259,8 @@ 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);
> -   if (!priv->minor->master && !drm_is_render_client(priv)) {
> +   if (!priv->minor->master && !drm_is_render_client(priv) &&
> +   !drm_is_control(priv)) {
> /* create a new master */
> priv->minor->master = drm_master_create(priv->minor);
> if (!priv->minor->master) {
> @@ -297,7 +298,7 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> goto out_close;
> }
> }
> -   } else if (!drm_is_render_client(priv)) {
> +   } else if (!drm_is_render_client(priv) && !drm_is_control(priv)) {
> /* get a reference to the master */
> priv->master = drm_master_get(priv->minor->master);

Maybe I missed some other patches, but how is this going to work?
drm_crtc.c expects priv->master to be non-NULL (eg.,
drm_mode_getresources()). This is fine for render-nodes as they don't
allow any of those ioctls, but the control-node does allow them.

Thanks
David

> }
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 04a7f31..ff68e26 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1246,6 +1246,11 @@ static inline bool drm_is_render_client(struct 
> drm_file *file_priv)
> return file_priv->minor->type == DRM_MINOR_RENDER;
>  }
>
> +static inline bool drm_is_control(struct drm_file *file_priv)
> +{
> +   return file_priv->minor->type == DRM_MINOR_CONTROL;
> +}
> +
>  /**/
>  /** \name Internal function definitions */
>  /*@{*/
> --
> 1.7.10.4
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 01/11] staging: imx-drm-core: Use OF graph to find components and connections between encoder and crtcs

Am Mittwoch, den 05.03.2014, 10:05 + schrieb Russell King - ARM
Linux:
> On Wed, Mar 05, 2014 at 10:20:52AM +0100, Philipp Zabel wrote:
> > +struct imx_drm_component {
> > +   struct device_node *of_node;
> > +   struct list_head list;
> > +};
> > +
> 
> The only thing this structure appears to be doing is ensuring that a
> single component doesn't get added twice - is that correct? 

I also think of it as an optimization. Now we scan the whole device
graph once in the probe function into a list of needed components that
can be walked quickly every time master_ops' .add_components callback is
run, instead of having to walk the device tree graph over and over.

Functionally, it only protects against duplicate addition.

> If so, (and the troublesome problem with the IPU crtcs is now gone)
> we can modify the core component code such that it does this:
> 
> if (c->master && c->master != master)
> continue;
> 
> if (compare(c->dev, compare_data)) {
>   if (!c->master)
>   component_attach_master(master, c);
> ret = 0;
> break;
> }
> 
> which will mean that you don't need to build this list anymore to track
> what will be added - though I'd like to think a little more about that
> before making that change.  Please confirm whether this will eliminate
> your list generation.

Yes, I can confirm that with this change, I can remove the list, like
this (tested on i.MX6S with a single LVDS panel):

diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 014e546..f6135b9 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -32,11 +32,6 @@

 struct imx_drm_crtc;

-struct imx_drm_component {
-   struct device_node *of_node;
-   struct list_head list;
-};
-
 struct imx_drm_device {
struct drm_device   *drm;
struct imx_drm_crtc *crtc[MAX_CRTC];
@@ -587,72 +582,10 @@ static int compare_of(struct device *dev, void
*data)
return dev->of_node == np;
 }

-static LIST_HEAD(imx_drm_components);
-
 static int imx_drm_add_components(struct device *master, struct master
*m)
 {
-   struct imx_drm_component *component;
-   int ret;
-
-   list_for_each_entry(component, _drm_components, list) {
-   ret = component_master_add_child(m, compare_of,
-component->of_node);
-   if (ret)
-   return ret;
-   }
-   return 0;
-}
-
-static int imx_drm_bind(struct device *dev)
-{
-   return drm_platform_init(_drm_driver, to_platform_device(dev));
-}
-
-static void imx_drm_unbind(struct device *dev)
-{
-   drm_put_dev(dev_get_drvdata(dev));
-}
-
-static const struct component_master_ops imx_drm_ops = {
-   .add_components = imx_drm_add_components,
-   .bind = imx_drm_bind,
-   .unbind = imx_drm_unbind,
-};
-
-static struct imx_drm_component *imx_drm_find_component(struct device
*dev,
-   struct device_node *node)
-{
-   struct imx_drm_component *component;
-
-   list_for_each_entry(component, _drm_components, list)
-   if (component->of_node == node)
-   return component;
-
-   return NULL;
-}
-
-static int imx_drm_add_component(struct device *dev, struct device_node
*node)
-{
-   struct imx_drm_component *component;
-
-   if (imx_drm_find_component(dev, node))
-   return 0;
-
-   component = devm_kzalloc(dev, sizeof(*component), GFP_KERNEL);
-   if (!component)
-   return -ENOMEM;
-
-   component->of_node = node;
-   list_add_tail(>list, _drm_components);
-
-   return 0;
-}
-
-static int imx_drm_platform_probe(struct platform_device *pdev)
-{
struct device_node *ep, *port, *remote;
-   int ret;
-   int i;
+   int i, ret;

/*
 * Bind the IPU display interface ports first, so that
@@ -660,23 +593,18 @@ static int imx_drm_platform_probe(struct
platform_device *pdev)
 * works as expected.
 */
for (i = 0; ; i++) {
-   port = of_parse_phandle(pdev->dev.of_node, "ports", i);
+   port = of_parse_phandle(master->of_node, "ports", i);
if (!port)
break;

-   ret = imx_drm_add_component(>dev, port);
-   if (ret < 0)
+   ret = component_master_add_child(m, compare_of, port);
+   if (ret)
return ret;
}

-   if (i == 0) {
-   dev_err(>dev, "missing 'ports' property\n");
-   return -ENODEV;
-   }
-
/* Then bind all encoders */
for (i = 0; ; i++) {
-   port = of_parse_phandle(pdev->dev.of_node, "ports", i);
+   port =

[RFC PATCH v2 03/21] exynos/dsim: add DT bindings

2014-02-12 20:31 GMT+09:00 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 and frequencies of clocks.
>
> [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
> ---
>  .../devicetree/bindings/video/exynos_dsim.txt  | 53 
> ++
>  1 file changed, 53 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..2a49704
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
> @@ -0,0 +1,53 @@
> +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
> +  - samsung,burst-clock-frequency: specifies DSI frequency in high-speed 
> burst
> +mode
> +  - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
> +  - #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 DSI bindings [1])
> +
> +[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.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>;
> +   samsung,burst-clock-frequency = <5>;
> +   samsung,esc-clock-frequency = <2000>;

Isn't a property indicating cpu or video mode needed for the future
even though now DSI driver doesn't support CPU interface yet? Which
mode is used would depend on machine.

> +
> +   panel at 0 {
> +   reg = <0>;
> +   ...
> +   };
> +   };
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm: Allow the driver to reject vblank requests only when it really has the vblank interrupts disabled

2014-03-05 Thread Daniel Vetter

On Wed, Mar 05, 2014 at 02:38:25PM +0200, Ville Syrj?l? wrote:
> On Tue, Mar 04, 2014 at 10:24:54AM +0100, Daniel Vetter wrote:
> > On Fri, Feb 21, 2014 at 09:03:33PM +0200, ville.syrjala at linux.intel.com 
> > wrote:
> > > From: Ville Syrj?l? 
> > > 
> > > Allow the driver to specify whether all new vblank requests after
> > > drm_vblank_off() should be rejected. And add a counterpart called
> > > drm_vblank_on() which will again allow vblank requests to come in.
> > > 
> > > Signed-off-by: Ville Syrj?l? 
> > 
> > Not really happy about this - drm_irq.c is already a giant mess, adding
> > more driver-specific hacks doesn't help. I think we need a few bits of
> > polish on top of your code:
> > 
> > - Add stern warnings to pre/post_modeset that they're inherently racy.
> > 
> > - Add calls to drm_vblank_off to every driver lacking them. Put it at the
> >   beginning of their crtc disable functions expect when there's a call to
> >   pre_modeset. Then it should be right after that.
> > 
> > - Sprinkle calls to drm_vblank_on over all drivers. Put them at the end of
> >   their crtc enable functions except when there's a call to post_modeset.
> >   Then put it right before that.
> > 
> > - Rip out the reject argument again and make it the default. If we have
> >   drm_vblank_off everywhere then all old vblank waits should complete and
> >   there's no userspace yet out there which races a modeset with vblank
> >   ioctl calls. Then only issue would be userspace which does vblank waits
> >   on disabled ioctls which a) is buggy b) we can easily fix with a driver
> >   quirk flag if _really_ needed.
> > 
> > This way the drm_irq.c mess will at least converge a bit and so should
> > help generic display servers (like Wayland) a lot.
> > 
> > I can volunteer for this if you want to punt on it yourself.
> 
> Much appreciated. I'll punt.
> 
> My hope was that other people would fix their own mess after seeing how
> i915 did it, and then we could rip out the crap, but if you're feeling
> the urge to do it all upfront I certainly won't object.

My experience tells me that the only way to fix a cross-driver mess is to
simple charge ahead. If driver maintainers are asleep they'll end up with
a broken driver, but that usually gets their attention. Pleas and praying
don't ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PULL] drm-intel-fixes

2014-03-05 Thread Dave Airlie

On Tue, Mar 4, 2014 at 11:49 PM, Jani Nikula  wrote:
>
> Hi Dave -
>
> Small fixes all around, mostly stable material. Please pull.
>
> BR,
> Jani.
>
>
> The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
>
>   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
>
> are available in the git repository at:
>
>   ssh://git.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2014-03-04

I noticed this recently, please don't send pull reqs with ssh urls in
them, although I have access to that machine others don't, send one
like that to Linus and you'll know all about it.

Dave.

[PATCH 3/5] drm: Allow the driver to reject vblank requests only when it really has the vblank interrupts disabled

2014-03-05 Thread Ville Syrjälä

On Tue, Mar 04, 2014 at 10:24:54AM +0100, Daniel Vetter wrote:
> On Fri, Feb 21, 2014 at 09:03:33PM +0200, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrj?l? 
> > 
> > Allow the driver to specify whether all new vblank requests after
> > drm_vblank_off() should be rejected. And add a counterpart called
> > drm_vblank_on() which will again allow vblank requests to come in.
> > 
> > Signed-off-by: Ville Syrj?l? 
> 
> Not really happy about this - drm_irq.c is already a giant mess, adding
> more driver-specific hacks doesn't help. I think we need a few bits of
> polish on top of your code:
> 
> - Add stern warnings to pre/post_modeset that they're inherently racy.
> 
> - Add calls to drm_vblank_off to every driver lacking them. Put it at the
>   beginning of their crtc disable functions expect when there's a call to
>   pre_modeset. Then it should be right after that.
> 
> - Sprinkle calls to drm_vblank_on over all drivers. Put them at the end of
>   their crtc enable functions except when there's a call to post_modeset.
>   Then put it right before that.
> 
> - Rip out the reject argument again and make it the default. If we have
>   drm_vblank_off everywhere then all old vblank waits should complete and
>   there's no userspace yet out there which races a modeset with vblank
>   ioctl calls. Then only issue would be userspace which does vblank waits
>   on disabled ioctls which a) is buggy b) we can easily fix with a driver
>   quirk flag if _really_ needed.
> 
> This way the drm_irq.c mess will at least converge a bit and so should
> help generic display servers (like Wayland) a lot.
> 
> I can volunteer for this if you want to punt on it yourself.

Much appreciated. I'll punt.

My hope was that other people would fix their own mess after seeing how
i915 did it, and then we could rip out the crap, but if you're feeling
the urge to do it all upfront I certainly won't object.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 4/5] drm: Allow reenabling of vblank interrupts even if refcount>0

2014-03-05 Thread Ville Syrjälä

On Tue, Mar 04, 2014 at 10:16:02AM +0100, Daniel Vetter wrote:
> On Fri, Feb 21, 2014 at 09:03:34PM +0200, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrj?l? 
> > 
> > If someone holds a vblank reference across the modeset, and after/during
> > the modeset someone tries to grab a vblank reference, the current code
> > won't re-enable the vblank interrupts. That's not good, so instead allow
> > the driver to choose whether drm_vblank_get() should always enable the
> > interrupts regardless of the refcount.
> > 
> > Combined with the drm_vblank_off/drm_vblank_on reject mechanism, this
> > can also be used to allow drivers to use vblank interrupts during
> > modeset, whether or not someone is currently holding a vblank reference.
> > 
> > Signed-off-by: Ville Syrj?l? 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 3 ++-
> >  include/drm/drmP.h| 6 ++
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 6e5d820..d613b6f 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -897,7 +897,8 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
> > }
> >  
> > /* Going from 0->1 means we have to enable interrupts again */
> > -   if (atomic_add_return(1, >vblank[crtc].refcount) == 1) {
> > +   if (atomic_add_return(1, >vblank[crtc].refcount) == 1 ||
> > +   dev->vblank_always_enable_on_get) {
> > spin_lock(>vblank_time_lock);
> > if (!dev->vblank[crtc].enabled) {
> > /* Enable vblank irqs under vblank_time_lock protection.
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index ee40483..3eca0ee 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1156,6 +1156,12 @@ struct drm_device {
> >  */
> > bool vblank_disable_allowed;
> >  
> > +   /*
> > +* Should a non-rejected drm_vblank_get() always enable the
> > +* vblank interrupt regardless of the current refcount?
> > +*/
> > +   bool vblank_always_enable_on_get;
> 
> Nack for this hack. Why can't drm_vblank_on not just re-enable the vblank
> interrupt if we still have a vblank reference?

Hmm. Yeah that seems like a nicer way to go about it.

-- 
Ville Syrj?l?
Intel OTC

[Bug 75732] [r600g] Memory leak with celestia, RV790

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

--- Comment #7 from Marek Ol??k  ---
Leaking a radeon_winsys allocation is hardly an issue. There is only one
instance of the winsys per process anyway. This is really harmless. I wouldn't
even bother trying to fix this leak (if there really is a leak).

-- 
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/20140305/a432536a/attachment.html>

Adding set_blob ioctl to DRM

2014-03-05 Thread Rahul Sharma

Thanks Daniel and Bob,

Agree, DT is good enough for initial settings. But when need to support
on the fly parameter changes, we will end up with 2 solutions. Adding KMS
ioctls or improvising blob prop infrastructure (Ruled out existing KMS 64bit
props as list of parameters is close to 30, as if now).

Later seems better for three reasons; writable blobs are more scalable and
can be used for any type of parameter groups. Secondly these are very similar
to 64 bit props and use same set_property, get_property infrastructure
(else need
to add set_gamma kind of callbacks till down the layer). And at last, it looks
more complete and appropriate to provide writable blobs just like other KMS
property.

I am ready with RFC and posting it today. We can also continue this discussion
in RFC thread.

Regards,
Rahul Sharma.

On 4 March 2014 23:09, Bob Paauwe  wrote:
> On Tue, 4 Mar 2014 09:35:57 +0100
> Daniel Vetter  wrote:
>
>> On Thu, Feb 20, 2014 at 11:24:40AM +1000, Dave Airlie wrote:
>> > > I am working on enabling a Color Enhancement block for primary display
>> > > for Exynos SoC. I need to
>> > > set a bunch of parameters like Color Conversion matrix, Contrast
>> > > Improvement parameters etc ~ 30 parameters from User Space.
>> > >
>> > > I am planning to use KDS blob property to receive these parameters.
>> > > Currently drivers are not allowed to create a blob property inside
>> > > drm. Neither, user space can set the blob. There is no ioctl provided
>> > > for same.
>> >
>> > I don't really like the idea of sticking unstructured data into an
>> > ioctl, for the driver to interpret,
>> >
>> > it opens the door to all kinds of ugly driver hacks, so I think we
>> > should have writable blobs,
>> > but with well defined structures inside them, not per-driver ones.
>> >
>> > Per-driver structures will lead to binary userspace drivers that start
>> > sticking a pll timings blob on the end and require it to set a mode,
>> > because I know driver developers will abuse any interface in the worst
>> > way possible.
>> >
>> > Currently the only blob we really have is EDID and its well defined,
>> > so if we are going to add writable blobs, they need to be well defined
>> > and as little as possible driver specific, just to avoid driver
>> > writings doing what driver writers do.
>>
>> tbh I don't see a use for structured blobs at all and would much more
>> prefer a pile of properties. With the atomic modeset ioctl proposals
>> floating around we could then pass in an entire sets of properties, which
>> is essentially what the blob prop would be doing.
>>
>> The upshot of going all-in with explicitly named properties is that we can
>> shovel kms configuration descriptions into different formats. I'm thinking
>> of shovelling an initial config into DT or something similar as an
>> example.  For i915 we have some experimental patches which load a DT blob
>> as a firmware file and use the property values to set things up.
>
> I have most of this working with i915 now.  Using a DT configuration I
> can set module parameters, select which crtc's to enable, which
> connectors to enable, set connector properties at init time.  I'm
> working on some plane property code now.
>
> It's close to being ready for initial review/feedback but there's one
> problem, you can't currently build an x86_64 (32 bit is fine) kernel
> with DT enabled because of an unresolved symbol in the apic code.
>
>>
>> So imo a blob property needs some _really_ good justification. My default
>> stance is to oppose it ;-)
>>
>> Cheers, Daniel
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/8] various exynos cleanups

Hi,

Thanks you for cleanups.

2014-03-05 14:01 GMT+09:00 Daniel Kurtz :
> Just some clean up patches, mostly for libdrm_exynos.
>
> Daniel Kurtz (8):
>   eyxnos: install exynos tests if HAVE_INSTALL_TESTS
>   exynos: fix two warnings
>   exynos_fimg2d: fix cast from pointer to integer of different size
>   exynos: remove unusable "run" target
>   exynos_fimg2d_test: fix drmModeRmFB
>   drmOpenByName: remove redundant drmAvailable check
>   exynos: prime: use drmPrime*() helpers
>   exynos: removed unused fd field
>

1 through 5, and 7 through 8,

Acked-by: Inki Dae 


Thanks,
Inki Dae

>  exynos/exynos_drm.c   | 52 
> +--
>  exynos/exynos_drmif.h |  2 --
>  exynos/exynos_fimg2d.c|  4 +--
>  tests/exynos/Makefile.am  |  7 --
>  tests/exynos/exynos_fimg2d_test.c |  2 +-
>  xf86drm.c | 13 --
>  6 files changed, 20 insertions(+), 60 deletions(-)
>
> --
> 1.9.0.rc1.175.g0b1dcb5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #8 from Alex Deucher  ---
Can you use git to bisect between the 9.0 and 9.1 releases to see what commit
caused the regression?

-- 
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/20140305/42fb1ecb/attachment.html>

[RFC PATCH] drm/dp: let drivers specify the name of the I2C-over-AUX adapter

2014-03-05 Thread Jani Nikula

Let the drivers specify the name of the I2C-over-AUX adapter to maintain
backwards compatibility in the sysfs when converting to the new
I2C-over-AUX helper infrastructure.

The i915 driver currently uses DPDDC-A to DPDDC-D as names for the DP
i2c adapters. These names show up in the i2c sysfs name attribute. We'd
like to be able to maintain that when switching over to the new helpers.

Due to i2c device and connector cleanup ordering issues we also recently
made the drm device (instead of connector) the parent of the i2c
adapters:

commit 80f65de3c9b8101c1613fa82df500ba6a099a11c
Author: Imre Deak 
Date:   Tue Feb 11 17:12:49 2014 +0200

drm/i915: dp: fix order of dp aux i2c device cleanup

With the name picked up from the adapter parent using dev_name(), it
would be the same for all i2c adapters with the current I2C-over-AUX
helpers.

Signed-off-by: Jani Nikula 

---

I am not entirely happy with adding an extra name field, but I also
didn't like the caller having to set up aux.ddc.name in advance. Ideas
welcome.
---
 drivers/gpu/drm/drm_dp_helper.c |3 ++-
 include/drm/drm_dp_helper.h |4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 35251af3b14e..17832d048147 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -726,7 +726,8 @@ int drm_dp_aux_register_i2c_bus(struct drm_dp_aux *aux)
aux->ddc.dev.parent = aux->dev;
aux->ddc.dev.of_node = aux->dev->of_node;

-   strncpy(aux->ddc.name, dev_name(aux->dev), sizeof(aux->ddc.name));
+   strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
+   sizeof(aux->ddc.name));

return i2c_add_adapter(>ddc);
 }
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 42947566e755..b4f58914bf7d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -438,6 +438,9 @@ struct drm_dp_aux_msg {
  * The .dev field should be set to a pointer to the device that implements
  * the AUX channel.
  *
+ * The .name field may be used to specify the name of the I2C adapter. If set 
to
+ * NULL, dev_name() of .dev will be used.
+ *
  * Drivers provide a hardware-specific implementation of how transactions
  * are executed via the .transfer() function. A pointer to a drm_dp_aux_msg
  * structure describing the transaction is passed into this function. Upon
@@ -455,6 +458,7 @@ struct drm_dp_aux_msg {
  * should call drm_dp_aux_unregister_i2c_bus() to remove the I2C adapter.
  */
 struct drm_dp_aux {
+   const char *name;
struct i2c_adapter ddc;
struct device *dev;

-- 
1.7.9.5

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

Nicolas Delvaux  changed:

   What|Removed |Added

 CC||contact at nicolas-delvaux.org

--- Comment #6 from Nicolas Delvaux  ---
Same problem here on an MSI R7970 Lightning, tested with the latest Mesa
version. Enabling dpm change nothing.

For the record, here is the sensors output when the system is idle:

radeon-pci-0100
Adapter: PCI adapter
temp1:+33.0?C  

So this indeed seems to just be a fan control issue.

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

[RFC PATCH v2 00/21] Add DSI display support for Exynos based boards

Hi Andrzej,

Thanks for your contributions.

2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
> Hi,
>
> This patchset adds drivers and bindings to the following devices:
> - Exynos DSI master,
> - S6E8AA0 DSI panel,
> - TC358764 DSI/LVDS bridge,
> - HV070WSA-100 LVDS panel.
>
> It adds also display support in DTS files for the following boards:
> - Exynos4210/Trats,
> - Exynos4412/Trats2,
> - Exynos5250/Arndale.
>
> Things worth mentioning:
>
> 1. I have implemented DSI/LVDS bridge using drm_panel framework, ie.
> the driver exposes drm_panel interface on DSI side, and interact with
> panels on LVDS side using drm_panel framework. This approach seems to
> me simpler and more natural than using drm_bridge.

Can you give me more details about why you think better to use panel
framework than using drm_bridge?  "Simpler" and "more natural" are
ambiguous to me.

Using same drm_panel framework for LDVS bridge and real panel drivers
isn't reasonable to me as now because drm_panel framework would be for
real panel device even if the use of drm_panel framework looks like
suitable to LVDS bridge driver. I thought Sean's way, ptn3460 driver
using drm_bride stuff, is good enough, and that would be why
drm_bridge exists and why drm_encoder has drm_bridge.

And I'm finding more generic way, how to handle LVDS bridge using
super node so that  LVDS bridge driver isn't embedded to connector
drivers such as eDP and MIPI-DSI, and dt binding of LVDS bridge can be
done at top level of Exynos drm. Once the binding is done, encoder of
display bus driver will have drm_bridge object of LVDS bridge driver
so that display bus driver can handle LVDS bridge driver.

Will review your patch series soon.

Thanks,
Inki Dae

>
> 2. I have used video interface bindings to make link between bridge and LVDS 
> panel.
> Other places where such links can be created are:
> a) link between DSI master and slave, I wonder if it is always neccessary,
>DSI bus is also video bus,
> b) link between FIMD(display controller) and DSI Master, currently Exynos DRM
>framework uses driver's hardcoded links, converting it to video interface
>bindings should be done (if required) by separate patches.
>
> The patchset is based on Sean's Paul Exynos refactor patches v4 [1].
> To work properly porch calculation should be fixed according to my comment 
> [2].
>
> It is the 2nd iteration of the patches, main changes:
> - based on v4 refactor patches,
> - added arndale related stuff.
> Other changes are described in individual patches.
>
> [1] http://permalink.gmane.org/gmane.comp.video.dri.devel/99264
> [2] http://permalink.gmane.org/gmane.comp.video.dri.devel/99826
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (21):
>   drm_mipi_dsi: add flags to DSI messages
>   drm/exynos: delay fbdev initialization until an output is connected
>   exynos/dsim: add DT bindings
>   drm/exynos: add DSIM driver
>   panel/s6e8aa0: add DT bindings
>   drm/panel: add S6E8AA0 driver
>   panel/tc358764: add DT bindings
>   drm/panel: add TC358764 driver
>   panel/simple: add video interface DT bindings
>   panel/hv070wsa-100: add DT bindings
>   drm/panel: add support for BOE HV070WSA-100 panel to simple-panel
>   ARM: dts: exynos4: add MIPI DSI Master node
>   ARM: dts: exynos4210-trats: add panel node
>   ARM: dts: exynos4412-trats2: add panel node
>   ARM: dts: exynos5250: add mipi-phy node
>   ARM: dts: exynos5250: add display power domain node
>   ARM: dts: exynos5250: add DSI node
>   ARM: dts: exynos5250-arndale: add display regulators
>   ARM: dts: exynos5250-arndale: add dsi and panel nodes
>   ARM: dts: exynos4210-trats: enable exynos/fimd node
>   ARM: dts: exynos4412-trats2: enable exynos/fimd node
>
>  .../devicetree/bindings/panel/boe,hv070wsa-100.txt |7 +
>  .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   51 +
>  .../devicetree/bindings/panel/simple-panel.txt |6 +
>  .../devicetree/bindings/panel/toshiba,tc358764.txt |   41 +
>  .../devicetree/bindings/video/exynos_dsim.txt  |   53 +
>  arch/arm/boot/dts/exynos4.dtsi |   14 +
>  arch/arm/boot/dts/exynos4210-trats.dts |   42 +
>  arch/arm/boot/dts/exynos4412-trats2.dts|   51 +
>  arch/arm/boot/dts/exynos5250-arndale.dts   |   63 +
>  arch/arm/boot/dts/exynos5250.dtsi  |   25 +
>  drivers/gpu/drm/exynos/Kconfig |9 +
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   26 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1402 
> 
>  drivers/gpu/drm/exynos/exynos_drm_fb.c |3 +
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |4 +-
>  drivers/gpu/drm/panel/Kconfig  |   14 +
>  drivers/gpu/drm/panel/Makefile |2 +
>  drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1064 +++

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #7 from l.mollari at gmx.net ---
Created attachment 95161
  --> https://bugs.freedesktop.org/attachment.cgi?id=95161=edit
8. Output from xrandr

-- 
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/20140305/0e4c4ddb/attachment.html>

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #6 from l.mollari at gmx.net ---
Created attachment 95160
  --> https://bugs.freedesktop.org/attachment.cgi?id=95160=edit
7. Output from lspci (excerpt)

-- 
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/20140305/aa06400c/attachment.html>

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #5 from l.mollari at gmx.net ---
Created attachment 95159
  --> https://bugs.freedesktop.org/attachment.cgi?id=95159=edit
6. List of tested versions

-- 
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/20140305/336ee615/attachment.html>

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #4 from l.mollari at gmx.net ---
Created attachment 95158
  --> https://bugs.freedesktop.org/attachment.cgi?id=95158=edit
5. Latest Xorg.0.log from the affected system

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

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #3 from l.mollari at gmx.net ---
Created attachment 95157
  --> https://bugs.freedesktop.org/attachment.cgi?id=95157=edit
4. 0 A. D. with silhouette artifacts

-- 
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/20140305/3c84e3c4/attachment-0001.html>

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #2 from l.mollari at gmx.net ---
Created attachment 95156
  --> https://bugs.freedesktop.org/attachment.cgi?id=95156=edit
3. 0 A. D. with artifacts

-- 
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/20140305/545443c7/attachment.html>

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

--- Comment #1 from l.mollari at gmx.net ---
Created attachment 95155
  --> https://bugs.freedesktop.org/attachment.cgi?id=95155=edit
2. glxgears without artifacts at lower resolution

-- 
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/20140305/7826a276/attachment.html>

[Bug 75794] Accumulation of black squares with OpenGL applications at high resolutions

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

l.mollari at gmx.net changed:

   What|Removed |Added

  Attachment #95154|glxgears with artifacts |1. glxgears with artifacts
description||
  Attachment #95154|text/plain  |image/png
  mime type||

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

[Bug 75794] New: Accumulation of black squares with OpenGL applications at high resolutions

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

Priority: medium
Bug ID: 75794
Assignee: dri-devel at lists.freedesktop.org
Summary: Accumulation of black squares with OpenGL applications
at high resolutions
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: l.mollari at gmx.net
Hardware: x86-64 (AMD64)
Status: NEW
Version: 9.1
Component: Drivers/Gallium/r300
Product: Mesa

Created attachment 95154
--> https://bugs.freedesktop.org/attachment.cgi?id=95154=edit
glxgears with artifacts

I am having trouble with black areas made up by 8 ? 8 pixel squares that occur
in 3D enabled applications when using the build-in TFTs native resolution of
1920 ? 1200. Lower resolutions are not affected (see attached screenshots [1]
and [2]). The shape of these areas is sensitive to the actual content drawn in
such a way that it acts like a shadow or an impression of the actual 3D
geometry and even of 2D HUDs in 3D enabled games. These artifacts are
persistent across different applications i. e. the current application inherits
the artifacts from the previous one and vice versa [4]. I have uploaded a video
showing the artifacts described in 0 A. D.:

https://www.youtube.com/watch?v=Rpu-s8DowFw

I narrowed the glitches down to Mesa 3D version 9.1 that seemingly introduced
the bug. The bug seems to be still present in the most recent Mesa 3D and Linux
kernel versions [6].

Damaged hardware is unlikely to be the cause for these glitches since I was
able to reproduce the same artifacts on three different laptops of the same
product line, all equipped with the same GPU.

All tests were performed with unaltered default settings of the respective
distributions. No manually touched or customized xorg.conf files or kernel mode
settings were in place.

--
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/20140305/4d64faef/attachment.html>

[PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector

2014-03-05 Thread Tomi Valkeinen

On 01/03/14 20:58, Geert Uytterhoeven wrote:
> On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux
>  wrote:
>> There's actually three HDMI connectors:
>>
>>   All three connectors carry all required HDMI signals, including a TMDS
>>   link. The Type B connector is slightly larger and carries a second TMDS
>>   link, which is necessary to support very high resolution displays using
>>   dual link. The Type C connector carries the same signals as the Type A
>>   but is more compact and intended for mobile applications.
>>
>> So, Type C and Type A are electrically the same.
> 
> There's also D (e.g. on BeagleBone Black) and E:
> 
> http://en.wikipedia.org/wiki/HDMI#Connectors
> 
> Electrically they seem to be the same as A/C.

I made the following change compared to the posted version.

 Tomi

@@ -3,6 +3,7 @@ HDMI Connector

 Required properties:
 - compatible: "hdmi-connector"
+- type: the HDMI connector type: "a", "b", "c", "d" or "e"

 Optional properties:
 - label: a symbolic name for the connector
@@ -17,6 +18,8 @@ hdmi0: connector at 1 {
compatible = "hdmi-connector";
label = "hdmi";

+   type = "a";
+
hdmi_connector_in: endpoint {
remote-endpoint = <_out>;
};


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

[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector

2014-03-05 Thread Tomi Valkeinen

On 28/02/14 18:23, Russell King - ARM Linux wrote:

> That's rather a lot of compatible strings.  Another possibility is:
> 
>   compatible = "dvi-connector";
>   analog;
>   digital;
>   single-link;
>   dual-link;

I made the following changes compared to the posted version. I decided
to leave the "single-link" out, as it's implied if "digital" is set.

 Tomi

@@ -6,11 +6,16 @@ Required properties:

 Optional properties:
 - label: a symbolic name for the connector
-- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- analog: the connector has DVI analog pins
+- digital: the connector has DVI digital pins
+- dual-link: the connector has pins for DVI dual-link

 Required nodes:
 - Video port for DVI input

+Note: One (or both) of 'analog' or 'digital' must be set.
+
 Example
 ---

@@ -18,7 +23,9 @@ dvi0: connector at 0 {
compatible = "dvi-connector";
label = "dvi";

-   i2c-bus = <>;
+   digital;
+
+   ddc-i2c-bus = <>;

dvi_connector_in: endpoint {
remote-endpoint = <_out>;


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

[Intel-gfx] [PULL] drm-intel-fixes

2014-03-05 Thread Daniel Vetter

On Wed, Mar 5, 2014 at 9:24 AM, Jani Nikula  wrote:
> On Wed, 05 Mar 2014, Dave Airlie  wrote:
>> On Tue, Mar 4, 2014 at 11:49 PM, Jani Nikula  
>> wrote:
>>>
>>> Hi Dave -
>>>
>>> Small fixes all around, mostly stable material. Please pull.
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>> The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
>>>
>>>   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>   ssh://git.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2014-03-04
>>
>> I noticed this recently, please don't send pull reqs with ssh urls in
>> them, although I have access to that machine others don't, send one
>> like that to Linus and you'll know all about it.
>
> Right, I saw that too. I blame Daniel's maintainer script. ;) I've fixed
> it now.

Actually I've made this intentionally since I still don't have a
kernel keyring signed pgp key, you have ssh access anyway and ssh
blocks out sneaky people ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PULL] drm-intel-fixes

2014-03-05 Thread Jani Nikula

On Wed, 05 Mar 2014, Dave Airlie  wrote:
> On Tue, Mar 4, 2014 at 11:49 PM, Jani Nikula  wrote:
>>
>> Hi Dave -
>>
>> Small fixes all around, mostly stable material. Please pull.
>>
>> BR,
>> Jani.
>>
>>
>> The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
>>
>>   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
>>
>> are available in the git repository at:
>>
>>   ssh://git.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2014-03-04
>
> I noticed this recently, please don't send pull reqs with ssh urls in
> them, although I have access to that machine others don't, send one
> like that to Linus and you'll know all about it.

Right, I saw that too. I blame Daniel's maintainer script. ;) I've fixed
it now.

The public repository is at:

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

Everything else is the same.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v5 11/11] staging: imx-drm: Update TODO

The device tree bindings are updated regardless of the common display
framework and in the meantime the HDMI driver was included.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/TODO | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index 6a9da94..29636fb 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -1,15 +1,10 @@
 TODO:
 - get DRM Maintainer review for this code
-- Wait for common display framework to hit mainline and update the IPU
-  driver to use it. This will most probably make changes to the devicetree
-  bindings necessary.
-- Factor out more code to common helper functions
 - decide where to put the base driver. It is not specific to a subsystem
   and would be used by DRM/KMS and media/V4L2

 Missing features (not necessarily for moving out of staging):

-- Add i.MX6 HDMI support
 - Add support for IC (Image converter)
 - Add support for CSI (CMOS Sensor interface)
 - Add support for VDIC (Video Deinterlacer)
-- 
1.9.0.rc3

[PATCH v5 10/11] ARM: dts: imx6qdl: Add IPU DI ports and endpoints, move imx-drm node to dtsi

This patch connects IPU and display encoder (HDMI, LVDS, MIPI)
device tree nodes, as well as parallel displays on the DISP0
and DISP1 outputs, using the OF graph bindings described in
Documentation/devicetree/bindings/media/video-interfaces.txt

The IPU ports correspond to the two display interfaces. The
order of endpoints in the ports is arbitrary.

Each encoder with an associated input multiplexer has multiple
input ports in the device tree. The order and reg property of
the ports must correspond to the multiplexer input order.

Since the imx-drm node now only needs to contain links to the
display interfaces, it can be moved to the SoC dtsi level. At
the board level, only connections between the display interface
ports and encoders or panels have to be added.

Signed-off-by: Philipp Zabel 
---
 - Changed DT compatible string to 'fsl,imx-display-subsystem' instead
   of Linux specific 'fsl,imx-drm', changed DT node name from 'imx-drm'
   to 'display-subsystem'.
---
 arch/arm/boot/dts/imx6dl.dtsi  |  22 +++---
 arch/arm/boot/dts/imx6q-sabresd.dts|   4 --
 arch/arm/boot/dts/imx6q.dtsi   | 124 ++--
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi |   6 --
 arch/arm/boot/dts/imx6qdl.dtsi | 128 -
 5 files changed, 253 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 6dc3970..25bbdd6 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -70,6 +70,15 @@
};
};
};
+
+   display-subsystem {
+   compatible = "fsl,imx-display-subsystem";
+   ports = <_di0>, <_di1>;
+   };
+};
+
+ {
+   compatible = "fsl,imx6dl-hdmi";
 };

  {
@@ -79,17 +88,4 @@
clock-names = "di0_pll", "di1_pll",
  "di0_sel", "di1_sel",
  "di0", "di1";
-
-   lvds-channel at 0 {
-   crtcs = < 0>, < 1>;
-   };
-
-   lvds-channel at 1 {
-   crtcs = < 0>, < 1>;
-   };
-};
-
- {
-   compatible = "fsl,imx6dl-hdmi";
-   crtcs = < 0>, < 1>;
 };
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts 
b/arch/arm/boot/dts/imx6q-sabresd.dts
index 66f220a..9cbdfe7 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -20,10 +20,6 @@
compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
 };

-_drm {
-   crtcs = < 0>, < 1>, < 0>, < 1>;
-};
-
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 187fe33..2a8d9de 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -132,13 +132,84 @@
};

ipu2: ipu at 0280 {
-   #crtc-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
compatible = "fsl,imx6q-ipu";
reg = <0x0280 0x40>;
interrupts = <0 8 0x4 0 7 0x4>;
clocks = < 133>, < 134>, < 137>;
clock-names = "bus", "di0", "di1";
resets = < 4>;
+
+   ipu2_di0: port at 2 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <2>;
+
+   ipu2_di0_disp0: endpoint at 0 {
+   };
+
+   ipu2_di0_hdmi: endpoint at 1 {
+   remote-endpoint = <_mux_2>;
+   };
+
+   ipu2_di0_mipi: endpoint at 2 {
+   };
+
+   ipu2_di0_lvds0: endpoint at 3 {
+   remote-endpoint = <_mux_2>;
+   };
+
+   ipu2_di0_lvds1: endpoint at 4 {
+   remote-endpoint = <_mux_2>;
+   };
+   };
+
+   ipu2_di1: port at 3 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <3>;
+
+   ipu2_di1_hdmi: endpoint at 1 {
+   remote-endpoint = <_mux_3>;
+   };
+
+   ipu2_di1_mipi: endpoint at 2 {
+   };
+
+   ipu2_di1_lvds0: endpoint at 3 {
+   remote-endpoint = <_mux_3>;
+   };
+
+   ipu2_di1_lvds1: endpoint at 4 {
+   remote-endpoint = <_mux_3>;
+   };
+

[PATCH v5 09/11] ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi

This patch connects IPU and display encoder (VGA, LVDS)
device tree nodes, as well as parallel displays on the DISP0
and DISP1 outputs, using the OF graph bindings described in
Documentation/devicetree/bindings/media/video-interfaces.txt

The IPU ports correspond to the two display interfaces. The
order of endpoints in the ports is arbitrary.

Since the imx-drm node now only needs to contain links to the
display interfaces, it can be moved to the SoC dtsi level. At
the board level, only connections between the display interface
ports and encoders or panels have to be added.

Signed-off-by: Philipp Zabel 
---
 - Changed DT compatible string to 'fsl,imx-display-subsystem' instead
   of Linux specific 'fsl,imx-drm', changed DT node name from 'imx-drm'
   to 'display-subsystem'.
---
 arch/arm/boot/dts/imx53-m53evk.dts | 17 +-
 arch/arm/boot/dts/imx53-mba53.dts  | 15 +
 arch/arm/boot/dts/imx53-qsb.dts| 17 +-
 arch/arm/boot/dts/imx53.dtsi   | 64 +++---
 4 files changed, 89 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-m53evk.dts 
b/arch/arm/boot/dts/imx53-m53evk.dts
index ee6107b..0298adc 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -23,7 +23,6 @@
soc {
display1: display at di1 {
compatible = "fsl,imx-parallel-display";
-   crtcs = < 1>;
interface-pix-fmt = "bgr666";
pinctrl-names = "default";
pinctrl-0 = <_ipu_disp2_1>;
@@ -44,6 +43,12 @@
};
};
};
+
+   port {
+   display1_in: endpoint {
+   remote-endpoint = <_di1_disp1>;
+   };
+   };
};

backlight {
@@ -53,12 +58,6 @@
default-brightness-level = <6>;
};

-   imx-drm {
-   compatible = "fsl,imx-drm";
-   crtcs = < 1>;
-   connectors = <>;
-   };
-
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -227,6 +226,10 @@
};
 };

+_di1_disp1 {
+   remote-endpoint = <_in>;
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_nand_1>;
diff --git a/arch/arm/boot/dts/imx53-mba53.dts 
b/arch/arm/boot/dts/imx53-mba53.dts
index f2affb0..a5b55c6 100644
--- a/arch/arm/boot/dts/imx53-mba53.dts
+++ b/arch/arm/boot/dts/imx53-mba53.dts
@@ -38,15 +38,14 @@
compatible = "fsl,imx-parallel-display";
pinctrl-names = "default";
pinctrl-0 = <_disp1_1>;
-   crtcs = < 1>;
interface-pix-fmt = "rgb24";
status = "disabled";
-   };

-   imx-drm {
-   compatible = "fsl,imx-drm";
-   crtcs = < 1>;
-   connectors = <>, <>;
+   port {
+   display1_in: endpoint {
+   remote-endpoint = <_di1_disp1>;
+   };
+   };
};

reg_3p2v: 3p2v {
@@ -147,6 +146,10 @@
};
 };

+_di1_disp1 {
+   remote-endpoint = <_in>;
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 3cb4f77..8b25428 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -23,7 +23,6 @@

display0: display at di0 {
compatible = "fsl,imx-parallel-display";
-   crtcs = < 0>;
interface-pix-fmt = "rgb565";
pinctrl-names = "default";
pinctrl-0 = <_ipu_disp0_1>;
@@ -46,6 +45,12 @@
pixelclk-active = <0>;
};
};
+
+   port {
+   display0_in: endpoint {
+   remote-endpoint = <_di0_disp0>;
+   };
+   };
};

gpio-keys {
@@ -72,12 +77,6 @@
};
};

-   imx-drm {
-   compatible = "fsl,imx-drm";
-   crtcs = < 0>;
-   connectors = <>;
-   };
-
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -132,6 +131,10 @@
status = "okay";
 };

+_di0_disp0 {
+   remote-endpoint = <_in>;
+};
+
  {
fsl,mode = "i2s-slave";
status = "okay";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 4307e80..04d3127 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -45,6 +45,11 @@
};
};

+   display-subsystem {
+   compatible = "fsl,imx-display-subsystem";
+   ports = <_di0>, <_di1>;
+   };
+
tzic: tz-interrupt-controller

[PATCH v5 08/11] ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to dtsi

This patch connects IPU and and parallel display device tree
nodes using the OF graph bindings described in
Documentation/devicetree/bindings/media/video-interfaces.txt

The IPU ports correspond to the two display interfaces. The
order of endpoints in the ports is arbitrary.

Since the imx-drm node now only needs to contain links to the
display interfaces, it can be moved to the SoC dtsi level. At
the board level, only connections between the display interface
ports and panels have to be added.

Signed-off-by: Philipp Zabel 
---
Changes since v4:
 - Changed DT compatible string to 'fsl,imx-display-subsystem' instead
   of Linux specific 'fsl,imx-drm', changed DT node name from 'imx-drm'
   to 'display-subsystem'.
---
 arch/arm/boot/dts/imx51-apf51dev.dts | 11 ++-
 arch/arm/boot/dts/imx51-babbage.dts  | 28 
 arch/arm/boot/dts/imx51.dtsi | 22 +-
 3 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/imx51-apf51dev.dts 
b/arch/arm/boot/dts/imx51-apf51dev.dts
index 5a7f552..d3f9814 100644
--- a/arch/arm/boot/dts/imx51-apf51dev.dts
+++ b/arch/arm/boot/dts/imx51-apf51dev.dts
@@ -18,7 +18,6 @@

display at di1 {
compatible = "fsl,imx-parallel-display";
-   crtcs = < 0>;
interface-pix-fmt = "bgr666";
pinctrl-names = "default";
pinctrl-0 = <_ipu_disp1_1>;
@@ -41,6 +40,12 @@
pixelclk-active = <0>;
};
};
+
+   port {
+   display_in: endpoint {
+   remote-endpoint = <_di0_disp0>;
+   };
+   };
};

gpio-keys {
@@ -122,3 +127,7 @@
};
};
 };
+
+_di0_disp0 {
+   remote-endpoint = <_in>;
+};
diff --git a/arch/arm/boot/dts/imx51-babbage.dts 
b/arch/arm/boot/dts/imx51-babbage.dts
index 6ff15a0..6719271 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -23,7 +23,6 @@

display0: display at di0 {
compatible = "fsl,imx-parallel-display";
-   crtcs = < 0>;
interface-pix-fmt = "rgb24";
pinctrl-names = "default";
pinctrl-0 = <_ipu_disp1_1>;
@@ -41,11 +40,16 @@
vsync-len = <10>;
};
};
+
+   port {
+   display0_in: endpoint {
+   remote-endpoint = <_di0_disp0>;
+   };
+   };
};

display1: display at di1 {
compatible = "fsl,imx-parallel-display";
-   crtcs = < 1>;
interface-pix-fmt = "rgb565";
pinctrl-names = "default";
pinctrl-0 = <_ipu_disp2_1>;
@@ -68,6 +72,12 @@
pixelclk-active = <0>;
};
};
+
+   port {
+   display1_in: endpoint {
+   remote-endpoint = <_di1_disp1>;
+   };
+   };
};

gpio-keys {
@@ -81,12 +91,6 @@
};
};

-   imx-drm {
-   compatible = "fsl,imx-drm";
-   crtcs = < 0>, < 1>;
-   connectors = <>, <>;
-   };
-
sound {
compatible = "fsl,imx51-babbage-sgtl5000",
 "fsl,imx-audio-sgtl5000";
@@ -264,6 +268,14 @@
};
 };

+_di0_disp0 {
+   remote-endpoint = <_in>;
+};
+
+_di1_disp1 {
+   remote-endpoint = <_in>;
+};
+
  {
fsl,mode = "i2s-slave";
status = "okay";
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 4bcdd3a..28c96aa 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -79,6 +79,11 @@
};
};

+   display-subsystem {
+   compatible = "fsl,imx-display-subsystem";
+   ports = <_di0>, <_di1>;
+   };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -92,13 +97,28 @@
};

ipu: ipu at 4000 {
-   #crtc-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
compatible = "fsl,imx51-ipu";
reg = <0x4000 0x2000>;
interrupts = <11 10>;
clocks = < 59>, < 110>, < 61>;
clock-names = "bus", "di0", "di1";
resets = < 2>;
+
+   ipu_di0: port at 2 {
+   reg = <2>;
+
+   ipu_di0_disp0: endpoint {
+   };
+   };
+
+

[PATCH v5 07/11] ARM: dts: imx53-mba53: Fix TVE DDC I2C bus property

This patch fixes the Television Encoder node's DDC I2C bus property to
use the common property name of 'ddc-i2c-bus' instead of just 'ddc'.

Signed-off-by: Philipp Zabel 
---
 arch/arm/boot/dts/imx53-mba53.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx53-mba53.dts 
b/arch/arm/boot/dts/imx53-mba53.dts
index 9b6e769..f2affb0 100644
--- a/arch/arm/boot/dts/imx53-mba53.dts
+++ b/arch/arm/boot/dts/imx53-mba53.dts
@@ -234,7 +234,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_vga_sync_1>;
-   ddc = <>;
+   i2c-ddc-bus = <>;
fsl,tve-mode = "vga";
fsl,hsync-pin = <4>;
fsl,vsync-pin = <6>;
-- 
1.9.0.rc3

[PATCH v5 06/11] imx-drm: imx-tve: Fix DDC I2C bus property

This patch fixes the TV Encoder DDC I2C bus property to use the common
'ddc-i2c-bus' property name instead of 'ddc'.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/imx-tve.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/imx-tve.c 
b/drivers/staging/imx-drm/imx-tve.c
index 50b25f1..575533f 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -582,7 +582,7 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
tve->dev = dev;
spin_lock_init(>lock);

-   ddc_node = of_parse_phandle(np, "ddc", 0);
+   ddc_node = of_parse_phandle(np, "i2c-ddc-bus", 0);
if (ddc_node) {
tve->ddc = of_find_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
-- 
1.9.0.rc3

[PATCH v5 05/11] imx-drm: imx-hdmi: Fix DDC I2C bus property

This patch fixes the DDC I2C bus property to use the common 'ddc-i2c-bus'
property name instead of 'ddc'. This is already documented in
Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/imx-hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/staging/imx-drm/imx-hdmi.c
index 909bee4..4540a9aa 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -1610,7 +1610,7 @@ static int imx_hdmi_bind(struct device *dev, struct 
device *master, void *data)
hdmi->dev_type = device_id->driver_data;
}

-   ddc_node = of_parse_phandle(np, "ddc", 0);
+   ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
if (!hdmi->ddc)
-- 
1.9.0.rc3

[PATCH v5 04/11] staging: imx-drm: Document imx-hdmi device tree bindings

This patch adds device tree binding documentation for the HDMI transmitter
on i.MX6.

Signed-off-by: Philipp Zabel 
---
Changes since v4:
 - Fixed copy documentation error
 - Added optional 'ddc-i2c-bus' property
---
 .../devicetree/bindings/staging/imx-drm/hdmi.txt   | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
new file mode 100644
index 000..1b756cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
@@ -0,0 +1,58 @@
+Device-Tree bindings for HDMI Transmitter
+
+HDMI Transmitter
+
+
+The HDMI Transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+with accompanying PHY IP.
+
+Required properties:
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+ - compatible : should be "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi".
+ - gpr : should be <>.
+   The phandle points to the iomuxc-gpr region containing the HDMI
+   multiplexer control register.
+ - clocks, clock-names : phandles to the HDMI iahb and isrf clocks, as 
described
+   in Documentation/devicetree/bindings/clock/clock-bindings.txt and
+   Documentation/devicetree/bindings/clock/imx6q-clock.txt.
+ - port@[0-4]: Up to four port nodes with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt,
+   corresponding to the four inputs to the HDMI multiplexer.
+
+Optional properties:
+ - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+
+example:
+
+   gpr: iomuxc-gpr at 020e {
+   /* ... */
+   };
+
+hdmi: hdmi at 012 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx6q-hdmi";
+reg = <0x0012 0x9000>;
+interrupts = <0 115 0x04>;
+gpr = <>;
+clocks = < 123>, < 124>;
+clock-names = "iahb", "isfr";
+ddc-i2c-bus = <>;
+
+port at 0 {
+reg = <0>;
+
+hdmi_mux_0: endpoint {
+remote-endpoint = <_di0_hdmi>;
+};
+};
+
+port at 1 {
+reg = <1>;
+
+hdmi_mux_1: endpoint {
+remote-endpoint = <_di1_hdmi>;
+};
+};
+};
-- 
1.9.0.rc3

[PATCH v5 03/11] staging: imx-drm: Document updated imx-drm device tree bindings

This patch updates the device tree binding documentation for i.MX IPU/display
nodes using the OF graph bindings documented in
Documentation/devicetree/bindings/media/video-interfaces.txt.

Signed-off-by: Philipp Zabel 
---
Changes since v4:
 - changed DT compatible string to 'fsl,imx-display-subsystem' instead
   of Linux specific 'fsl,imx-drm'
 - Changed DT node name from 'imx-drm' to 'display-subsystem'
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   | 48 +++---
 .../devicetree/bindings/staging/imx-drm/ldb.txt| 20 +++--
 2 files changed, 59 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..3be5ce7 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -1,3 +1,22 @@
+Freescale i.MX DRM master device
+
+
+The freescale i.MX DRM master device is a virtual device needed to list all
+IPU or other display interface nodes that comprise the graphics subsystem.
+
+Required properties:
+- compatible: Should be "fsl,imx-display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface ports
+  of IPU devices
+
+example:
+
+display-subsystem {
+   compatible = "fsl,display-subsystem";
+   ports = <_di0>;
+};
+
+
 Freescale i.MX IPUv3
 

@@ -7,18 +26,31 @@ Required properties:
   datasheet
 - interrupts: Should contain sync interrupt and error interrupt,
   in this order.
-- #crtc-cells: 1, See below
 - resets: phandle pointing to the system reset controller and
   reset line index, see reset/fsl,imx-src.txt for details
+Optional properties:
+- port@[0-3]: Port nodes with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+  Ports 0 and 1 should correspond to CSI0 and CSI1,
+  ports 2 and 3 should correspond to DI0 and DI1, respectively.

 example:

 ipu: ipu at 1800 {
-   #crtc-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
compatible = "fsl,imx53-ipu";
reg = <0x1800 0x08000>;
interrupts = <11 10>;
resets = < 2>;
+
+   ipu_di0: port at 2 {
+   reg = <2>;
+
+   ipu_di0_disp0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
 };

 Parallel display support
@@ -26,19 +58,25 @@ Parallel display support

 Required properties:
 - compatible: Should be "fsl,imx-parallel-display"
-- crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
+  display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.

 example:

 display at di0 {
compatible = "fsl,imx-parallel-display";
edid = [edid-data];
-   crtc = < 0>;
interface-pix-fmt = "rgb24";
+
+   port {
+   display_in: endpoint {
+   remote-endpoint = <_di0_disp0>;
+   };
+   };
 };
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
index ed93778..578a1fc 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
@@ -50,12 +50,14 @@ have a look at 
Documentation/devicetree/bindings/video/display-timing.txt.

 Required properties:
  - reg : should be <0> or <1>
- - crtcs : a list of phandles with index pointing to the IPU display interfaces
-   that can be used as video source for this channel.
  - fsl,data-mapping : should be "spwg" or "jeida"
   This describes how the color bits are laid out in the
   serialized LVDS signal.
  - fsl,data-width : should be <18> or <24>
+ - port: A port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt.
+   On i.MX6, there should be four ports (port@[0-3]) that correspond
+   to the four LVDS multiplexer inputs.

 example:

@@ -77,23 +79,33 @@ ldb: ldb at 53fa8008 {

lvds-channel at 0 {
reg = <0>;
-   crtcs = < 0>;
fsl,data-mapping = "spwg";
fsl,data-width = <24>;

display-timings {
/* ... */
};
+
+   port {
+   lvds0_in: endpoint {
+   remote-endpoint =

[PATCH v5 02/11] staging: imx-drm-core: use of_graph_parse_endpoint

Using of_graph_parse_endpoint recovers the port id from an endpoint device
tree node. This just replaces an open coded read of the "reg" property.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/imx-drm-core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index ecfc88b..4144a75 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -501,8 +501,9 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
 {
struct imx_drm_crtc *imx_crtc = imx_drm_find_crtc(encoder->crtc);
struct device_node *ep = NULL;
+   struct of_endpoint endpoint;
struct device_node *port;
-   int id, ret;
+   int ret;

if (!node || !imx_crtc)
return -EINVAL;
@@ -515,9 +516,8 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
port = of_graph_get_remote_port(ep);
of_node_put(port);
if (port == imx_crtc->port) {
-   ret = of_property_read_u32(ep->parent, "reg", );
-   of_node_put(ep);
-   return ret ? ret : id;
+   ret = of_graph_parse_endpoint(ep, );
+   return ret ? ret : endpoint.id;
}
} while (ep);

-- 
1.9.0.rc3

[PATCH v5 01/11] staging: imx-drm-core: Use OF graph to find components and connections between encoder and crtcs

From: Philipp Zabel 

This patch adds support to find the involved components connected to
the IPU display interface ports using the OF graph bindings documented
in Documentation/devicetree/bindings/media/video-interfaces.txt.
It makes use of the of_graph (formerly v4l2_of) parsing helpers and
thus depends on the patch that moves those out to drivers/of.

Each display interface needs to have an associated port node in the
device tree. We can associate this node with the crtc platform device
and use it to find the crtc corresponding to a given port node instead
of using a combination of parent device node and id number, as before.

Explicitly converting the void* cookie to the port device tree node
allows to get rid of the ipu_id and di_id fields. The multiplexer
setting on i.MX6 now can be obtained from the port id (reg property)
in the device tree.

The imx-drm node now needs a ports property that contains phandles
to each of the IPU display interface port nodes. From there, all
attached encoders are scanned and enabled encoders are added to a
waiting list.
The bind order makes sure that once all components are probed, crtcs
are bound before encoders, so that imx_drm_encoder_parse_of can be
called from the encoder bind callbacks.

For parsing the OF graph, temporary copies of the V4L2 OF graph
helpers are used, that can be removed again once those are available
at a generic place.

Signed-off-by: Philipp Zabel 
---
Changes since v4:
 - changed DT compatible string to 'fsl,imx-display-subsystem' instead
   of Linux specific 'fsl,imx-drm'
---
 drivers/staging/imx-drm/imx-drm-core.c | 217 +++--
 drivers/staging/imx-drm/imx-drm.h  |   5 +-
 drivers/staging/imx-drm/imx-hdmi.c |   2 +-
 drivers/staging/imx-drm/imx-ldb.c  |   4 +-
 drivers/staging/imx-drm/ipuv3-crtc.c   |  47 +--
 5 files changed, 199 insertions(+), 76 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 6b91c8e..ecfc88b 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,11 @@

 struct imx_drm_crtc;

+struct imx_drm_component {
+   struct device_node *of_node;
+   struct list_head list;
+};
+
 struct imx_drm_device {
struct drm_device   *drm;
struct imx_drm_crtc *crtc[MAX_CRTC];
@@ -41,9 +47,7 @@ struct imx_drm_crtc {
struct drm_crtc *crtc;
int pipe;
struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
-   void*cookie;
-   int id;
-   int mux_id;
+   struct device_node  *port;
 };

 static int legacyfb_depth = 16;
@@ -341,14 +345,11 @@ err_kms:

 /*
  * imx_drm_add_crtc - add a new crtc
- *
- * The return value if !NULL is a cookie for the caller to pass to
- * imx_drm_remove_crtc later.
  */
 int imx_drm_add_crtc(struct drm_device *drm, struct drm_crtc *crtc,
struct imx_drm_crtc **new_crtc,
const struct imx_drm_crtc_helper_funcs *imx_drm_helper_funcs,
-   void *cookie, int id)
+   struct device_node *port)
 {
struct imx_drm_device *imxdrm = drm->dev_private;
struct imx_drm_crtc *imx_drm_crtc;
@@ -370,9 +371,7 @@ int imx_drm_add_crtc(struct drm_device *drm, struct 
drm_crtc *crtc,

imx_drm_crtc->imx_drm_helper_funcs = *imx_drm_helper_funcs;
imx_drm_crtc->pipe = imxdrm->pipes++;
-   imx_drm_crtc->cookie = cookie;
-   imx_drm_crtc->id = id;
-   imx_drm_crtc->mux_id = imx_drm_crtc->pipe;
+   imx_drm_crtc->port = port;
imx_drm_crtc->crtc = crtc;

imxdrm->crtc[imx_drm_crtc->pipe] = imx_drm_crtc;
@@ -416,49 +415,56 @@ int imx_drm_remove_crtc(struct imx_drm_crtc *imx_drm_crtc)
 EXPORT_SYMBOL_GPL(imx_drm_remove_crtc);

 /*
- * Find the DRM CRTC possible mask for the device node cookie/id.
+ * Find the DRM CRTC possible mask for the connected endpoint.
  *
  * The encoder possible masks are defined by their position in the
  * mode_config crtc_list.  This means that CRTCs must not be added
  * or removed once the DRM device has been fully initialised.
  */
 static uint32_t imx_drm_find_crtc_mask(struct imx_drm_device *imxdrm,
-   void *cookie, int id)
+   struct device_node *endpoint)
 {
+   struct device_node *port;
unsigned i;

+   port = of_graph_get_remote_port(endpoint);
+   if (!port)
+   return 0;
+   of_node_put(port);
+
for (i = 0; i < MAX_CRTC; i++) {
struct imx_drm_crtc *imx_drm_crtc = imxdrm->crtc[i];
-   if (imx_drm_crtc && imx_drm_crtc->id == id &&
-

[PATCH v5 00/11] imx-drm dt bindings

Hi,

this latest version of the imx-drm DT binding patches applies
on top of staging-next and also depends on the OF graph binding
patchset that moves the v4l2_of helpers to drivers/of.
Currently, the two patchsets are also available at:
git://git.pengutronix.de/git/pza/linux.git topic/of-graph
git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt

I have added device tree bindings between IPU and the encoders as
documented in Documentation/devicetree/bindings/graph.txt and used
those to determine the possible_crtcs and mux_id, and to find all
necessary components that hang off of the display interface ports.
This allows to move the imx-drm node into the SoC level dtsi. The
existing i.MX51 and i.MX53 device trees are updated and device tree
binding documentation is included.

Changes since v4:
 - Changed DT compatible string to 'fsl,imx-display-subsystem'
   instead of Linux specific 'fsl,imx-drm'
 - Changed DT node name from 'imx-drm' to 'display-subsystem'
 - Fixed copy documentation error and added optional
   'ddc-i2c-bus' property in HDMI binding documentation
 - Fixed imx-tve and imx-hdmi to use the common 'ddc-i2c-bus'
   property as already used by the simple-panel binding instead of
   the custom but very generic 'ddc'.

regards
Philipp


Philipp Zabel (11):
  staging: imx-drm-core: Use OF graph to find components and connections
between encoder and crtcs
  staging: imx-drm-core: use of_graph_parse_endpoint
  staging: imx-drm: Document updated imx-drm device tree bindings
  staging: imx-drm: Document imx-hdmi device tree bindings
  imx-drm: imx-hdmi: Fix DDC I2C bus property
  imx-drm: imx-tve: Fix DDC I2C bus property
  ARM: dts: imx53-mba53: Fix TVE DDC I2C bus property
  ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to
dtsi
  ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to
dtsi
  ARM: dts: imx6qdl: Add IPU DI ports and endpoints, move imx-drm node
to dtsi
  staging: imx-drm: Update TODO

 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |  48 -
 .../devicetree/bindings/staging/imx-drm/hdmi.txt   |  58 ++
 .../devicetree/bindings/staging/imx-drm/ldb.txt|  20 +-
 arch/arm/boot/dts/imx51-apf51dev.dts   |  11 +-
 arch/arm/boot/dts/imx51-babbage.dts|  28 ++-
 arch/arm/boot/dts/imx51.dtsi   |  22 ++-
 arch/arm/boot/dts/imx53-m53evk.dts |  17 +-
 arch/arm/boot/dts/imx53-mba53.dts  |  17 +-
 arch/arm/boot/dts/imx53-qsb.dts|  17 +-
 arch/arm/boot/dts/imx53.dtsi   |  64 +-
 arch/arm/boot/dts/imx6dl.dtsi  |  22 +--
 arch/arm/boot/dts/imx6q-sabresd.dts|   4 -
 arch/arm/boot/dts/imx6q.dtsi   | 124 +++-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi |   6 -
 arch/arm/boot/dts/imx6qdl.dtsi | 128 +++-
 drivers/staging/imx-drm/TODO   |   5 -
 drivers/staging/imx-drm/imx-drm-core.c | 217 +++--
 drivers/staging/imx-drm/imx-drm.h  |   5 +-
 drivers/staging/imx-drm/imx-hdmi.c |   4 +-
 drivers/staging/imx-drm/imx-ldb.c  |   4 +-
 drivers/staging/imx-drm/imx-tve.c  |   2 +-
 drivers/staging/imx-drm/ipuv3-crtc.c   |  47 -
 22 files changed, 712 insertions(+), 158 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt

-- 
1.9.0.rc3

[PATCH v5 01/11] staging: imx-drm-core: Use OF graph to find components and connections between encoder and crtcs

2014-03-05 Thread Russell King - ARM Linux

On Wed, Mar 05, 2014 at 10:20:52AM +0100, Philipp Zabel wrote:
> +struct imx_drm_component {
> + struct device_node *of_node;
> + struct list_head list;
> +};
> +

The only thing this structure appears to be doing is ensuring that a
single component doesn't get added twice - is that correct?  If so,
(and the troublesome problem with the IPU crtcs is now gone)
we can modify the core component code such that it does this:

if (c->master && c->master != master)
continue;

if (compare(c->dev, compare_data)) {
if (!c->master)
component_attach_master(master, c);
ret = 0;
break;
}

which will mean that you don't need to build this list anymore to track
what will be added - though I'd like to think a little more about that
before making that change.  Please confirm whether this will eliminate
your list generation.

Thanks.

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

[Bug 75732] [r600g] Memory leak with celestia, RV790

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

--- Comment #6 from Chris Rankin  ---
(In reply to comment #5)
> valgrind finds one 352 byte leak with celestia. That can't possibly explain
> the issues you're having with WoW.

I raised this as a separate issue for a reason... ;-). But I doubt that Mesa
contains functionality that is *specific* to WoW; other apps *must* be affected
by #74549 - although perhaps not as noticeably.

-- 
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/20140305/2a176681/attachment.html>

[PATCH 0/3] Reorder drivers/video directory

2014-03-05 Thread Tomi Valkeinen

On 04/03/14 21:21, Randy Dunlap wrote:

>> I have pushed this to my for-next branch. Let's see what happens... At
>> least I'm able to merge the current linux-next without any conflicts.
> 
> Thanks, I'm looking at this change in linux-next now.
> 
> EXYNOS_VIDEO seems to be a little bit odd.  Can you clarify that for me?
> (This is not a change that you introduced.)
> 
> 
> In particular, under Graphics support, select Framebuffer Devices.
> This lists:
>   Support for frame buffer devices -->
>   Exynos Video driver support
> 
> It appears to me that Exynos either is a Framebuffer Device and should depend
> on FB like the other drivers here do OR (actually XOR) it is not a frame 
> buffer
> device and it should not be listed here.
> 
> Then once that is cleared up :), we don't need 2 levels of menu to get to the
> list of FB drivers -- i.e., one of those levels can be removed.

There are others. For my config, I have:

{*} Support for frame buffer devices  --->
 OMAP2+ Display Subsystem support  --->
[ ] Exynos Video driver support  
< > Solomon SSD1307 framebuffer support

I didn't want to start fixing those at the moment, as I have no idea
about exynos or solomon, and I wanted to just try to do the reorder,
without any other changes.

I agree that there's something wrong with the items. For the OMAP DSS,
there are non-fbdev related items under that menu, used also by omapdrm.
So it should probably be split into different components.

> Oh, and if you keep the new menu item "Framebuffer Devices", please spell it
> like the other entry (Frame Buffer).

Ok, fixed.

> Other than those nits, I like this change very much.  Thanks.

Thanks. After pushing this to for-next, I'm getting compile error
reports from Fengguang and Stephen. Let's see if I manage to avoid
those... This is not the easiest change to manage.

 Tomi


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

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #95121|text/plain  |application/octet-stream
  mime type||

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

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #95119|text/plain  |application/octet-stream
  mime type||

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

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #95121|application/octet-stream|text/plain
  mime type||

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

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #95119|application/octet-stream|text/plain
  mime type||

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

[Bug 75732] [r600g] Memory leak with celestia, RV790

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

--- Comment #5 from Michel D?nzer  ---
(In reply to comment #4)
> [...] since valgrinding 32 bit WoW on a 64 bit box is currently beyond me,

As suggested in your WoW bug report, please try valgrind on replaying an
apitrace instead.


> I am hunting for memory errors in other workloads instead, in the hope that
> they might provide some insight.)

valgrind finds one 352 byte leak with celestia. That can't possibly explain the
issues you're having with WoW.

-- 
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/20140305/013e876e/attachment.html>

[Bug 75784] New: Octodad: Dadliest Catch - GPU crash on CAYMAN