[PATCH] drm/exynos: dpi: Fix NULL pointer dereference with legacy bindings

[Tomasz Figa]

If there is no panel node in DT and instead display timings are provided
directly in FIMD node, there is no panel object created and ctx->panel
becomes NULL. However during Exynos DRM initialization
drm_helper_hpd_irq_event() is called, which in turns calls
exynos_dpi_detect(), which dereferences ctx->panel without a check,
causing a NULL pointer derefrence.

This patch fixes the issue by adding necessary NULL pointer check.

Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index f1b8587..f44bd90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -40,7 +40,7 @@ exynos_dpi_detect(struct drm_connector *connector, bool force)
 {
struct exynos_dpi *ctx = connector_to_dpi(connector);

-   if (!ctx->panel->connector)
+   if (ctx->panel && !ctx->panel->connector)
drm_panel_attach(ctx->panel, >connector);

return connector_status_connected;
-- 
2.0.0

[patch] gma500: remove duplicate FB_REG09 define

[Alan Cox]

> Adding an entry would make people think that I have time to spend on gma500
> development or is in some way responsible for it. At the moment, that is sadly
> not the case. I have a few things on my todo-list which I intend to fix but
> after that I would much rather work on something more productive.

A wise man indeed.

I'll try and keep an eye on it for minor fixes but hopefully its "done".
Apart from one person trying to port Linux to the Lenovo Tablet 2 I
don't think there is anything that is likely to happen here new ?

Alan

[PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

[Daniel Vetter]

On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes  
wrote:
> Yes, that's what I do below... I even added it to the changelog:
> http://patchwork.freedesktop.org/patch/27223/
>
> Did you miss the later hunk in intel_display.c?
>
> What we try to do here is enable swizzling if possible, which we can do
> if no inherited fbs are tiled.
>
> So I think I've done exactly what you repeated above, and documented
> it.  So you're going to need to repeat it with different words so I can
> understand, if I'm still missing something.

In swizzle_detect:

...

if (GEN6+) {
if (preserve_bios_swizzle) {
if (I915_READ(DISP_ARB_CTL) & DISP_TILE_SURFACE_SWIZZLING) {
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
...
} else {
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
...
}
} else {
/* existing/old logic to decide about swizzling */
}
}

...

Plus no shortcut in i915_gem_init_swizzling. Personally I'd also just use
a small helper function to compute preserve_bios_swizzle instead of
storing it in dev_priv (since we will only use it at exactly one place),
but that's a pure style preference.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #12 from nucrap at hotmail.com ---
Thanks, I will try the patch!


In case somebody has my graphics card (or a HD 7790 or maybe others too??) I
found a definite and easy way to reproduce it:

1. Start a lightweight DE with e.g. openbox or xfwm4 (compositing disabled)
2. Install and start "compton" from a terminal
3. Play this youtube video from firefox with flashplayer:
http://www.youtube.com/watch?v=d-Cc6j2ZBwk (happens on others too, but this
video is definately affected)
4. The bug should occur in less than 1:30 minutes
5. If it doesn't occur the first time just reload

This should definitely trigger the bug.

-- 
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/20140610/714ebed7/attachment.html>

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

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

Does this kernel patch help?

-- 
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/20140610/08c8a861/attachment.html>

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #10 from nucrap at hotmail.com ---
Now this is interesting:
Only compton and compiz are affected by this bug.
I tested it with Kwin and xfwm4 with compositing enabled but it just doesn't
happen. Also this bug can only be reproduced once - after that I need to
restart my PC to trigger it (relogin is not enough).

Hope this was helpful.

-- 
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/20140610/04b2900f/attachment-0001.html>

[Bug 79895] Google Hangout crashes radeon

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
Version|XOrg CVS|unspecified
  Component|DRM/Radeon  |Drivers/Gallium/radeonsi

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

[Bug 79895] New: Google Hangout crashes radeon

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

sclk: 3 mclk: 15000 vddc:
850 vddci: 875 pcie gen: 3
[380784.625388] power level 1sclk: 50100 mclk: 125000 vddc:
950 vddci: 875 pcie gen: 3
[380784.625390] power level 2sclk: 81000 mclk: 125000 vddc:
1090 vddci: 875 pcie gen: 3
[380784.625390] status: r

-- 
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/20140610/a83f5744/attachment.html>

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

joshua.r.marshall.1991 at gmail.com changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #9 from joshua.r.marshall.1991 at gmail.com ---
That looks to be it.

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

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

--- Comment #8 from Alex Deucher  ---
You need to build the firmware into the kernel image if you build the driver
into the kernel otherwise, the driver will not be able to fetch the firmware. 
What you may be seeing is the kernel firmware loading waiting for firmware to
become available, but it never does since it's not actually in the kernel
binary.

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

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

--- Comment #7 from joshua.r.marshall.1991 at gmail.com ---
I'm not aware of anything involving firmware for building the modules
separately or part of the main kernel.  I follow the same build procedure for
both.

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

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

--- Comment #6 from Alex Deucher  ---
Did you build the necessary firmware into your kernel image when you built the
driver into the kernel?  I don't think this has anything to do with the
handoff.

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

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

--- Comment #5 from joshua.r.marshall.1991 at gmail.com ---
Created attachment 138981
  --> https://bugzilla.kernel.org/attachment.cgi?id=138981=edit
dmesg output

I found where my kernel is leaking memory (USB audio related) but this hand off
should still not have been an issue.

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

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

--- Comment #4 from joshua.r.marshall.1991 at gmail.com ---
Created attachment 138971
  --> https://bugzilla.kernel.org/attachment.cgi?id=138971=edit
New kernel config that does boot

I used localmodconfig for then, then added debug info -- my guess is something
related to having the module built in vs. loaded.  I ran into similar issues
with my intel graphics a while back.

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

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

--- Comment #3 from joshua.r.marshall.1991 at gmail.com ---
This is the R7 GPU on the A10-7850K

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

[PATCH 3/3] drm/debugfs: add an "edid_override" file per connector

[David Herrmann]

Hi

On Thu, May 29, 2014 at 5:57 PM, Thomas Wood  wrote:
> Add a file to debugfs for each connector that allows the edid data to be
> overridden.
>
> Signed-off-by: Thomas Wood 
> ---
>  drivers/gpu/drm/drm_crtc.c |  4 +++
>  drivers/gpu/drm/drm_debugfs.c  | 56 
> ++
>  drivers/gpu/drm/drm_probe_helper.c |  9 +-
>  include/drm/drm_crtc.h |  1 +
>  4 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 59a2784..8543eac 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3701,6 +3701,10 @@ int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
> struct drm_device *dev = connector->dev;
> int ret, size;
>
> +   /* ignore requests to set edid when overridden */
> +   if (connector->override_edid)
> +   return 0;
> +
> if (connector->edid_blob_ptr)
> drm_property_destroy_blob(dev, connector->edid_blob_ptr);
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index b57b614..2c666ba 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #if defined(CONFIG_DEBUG_FS)
>
> @@ -295,6 +296,55 @@ static ssize_t connector_write(struct file *file, const 
> char __user *ubuf,
> return len;
>  }
>
> +static int edid_show(struct seq_file *m, void *data)
> +{
> +   struct drm_connector *connector = m->private;
> +   struct drm_property_blob *edid = connector->edid_blob_ptr;
> +
> +   if (connector->override_edid && edid)
> +   seq_write(m, edid->data, edid->length);
> +
> +   return 0;
> +}
> +
> +static int edid_open(struct inode *inode, struct file *file)
> +{
> +   struct drm_connector *dev = inode->i_private;
> +
> +   return single_open(file, edid_show, dev);
> +}
> +
> +static ssize_t edid_write(struct file *file, const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> +   struct seq_file *m = file->private_data;
> +   struct drm_connector *connector = m->private;

Please copy "ubuf" before accessing it.. that's a user-space buffer.
> +
> +   if (len >= EDID_LENGTH) {

What? So if you write any invalid EDID, you reset it? That's wrong..
You should return an error in those cases.

> +   drm_mode_connector_update_edid_property(connector,
> +   (struct edid *) ubuf);
> +   connector->override_edid = true;

Please check the error-code of update_edid_property() before setting
override_edid. You should also return that code if it is an error.

Furthermore, you must force override_edid = false; before calling
update_edid_property, otherwise writing twice to this file will
discard the second write (because update_edid_property() will do
nothing as override_edid is already true).

Last but not least, you *must* do an overflow check here!

> +   } else {
> +   if (connector->override_edid) {
> +   connector->override_edid = false;
> +   drm_mode_connector_update_edid_property(connector,
> +   NULL);
> +   }
> +   }
> +
> +   return len;


Maybe you want something like this (untested!):


char *buf;
struct edid *edid;
int ret;

buf = memdup_user(ubuf, len);
if (IS_ERR(buf))
return PTR_ERR(buf);

edid = buf;
connector->override_edid = false;

if (len == 5 && !strcmp(buf, "reset")) {
ret = drm_mode_connector_update_edid_property(connector, NULL);
} else if (len < EDID_LENGTH || EDID_LENGTH * (1 + edid->extensions) > len) {
ret = -EINVAL;
} else {
ret = drm_mode_connector_update_edid_property(connector,
(struct edid*)buf);
if (!ret)
connector->override_edid = true;
}

kfree(buf);
return ret ? : len;



Thanks
David

> +}
> +
> +static const struct file_operations drm_edid_fops = {
> +   .owner = THIS_MODULE,
> +   .open = edid_open,
> +   .read = seq_read,
> +   .llseek = seq_lseek,
> +   .release = single_release,
> +   .write = edid_write
> +};
> +
> +
>  static const struct file_operations drm_connector_fops = {
> .owner = THIS_MODULE,
> .open = connector_open,
> @@ -325,6 +375,12 @@ int drm_debugfs_connector_add(struct drm_connector 
> *connector)
> if (!ent)
> return -ENOMEM;
>
> +   /* edid */
> +   ent = debugfs_create_file("edid_override", S_IRUGO, root, connector,

IRUGO? Shouldn't this be writable for root?

> + _edid_fops);
> +   if (!ent)
> +   return -ENOMEM;
> +
> return 0;
>  }
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> 

[PATCH 2/3] drm/debugfs: add a "force" file per connector

[David Herrmann]

Hi

On Thu, May 29, 2014 at 5:57 PM, Thomas Wood  wrote:
> Add a file to debugfs for each connector to enable modification of the
> "force" connector attribute. This allows connectors to be enabled or
> disabled for testing and debugging purposes.
>
> Signed-off-by: Thomas Wood 
> ---
>  drivers/gpu/drm/drm_crtc.c|  17 ++-
>  drivers/gpu/drm/drm_debugfs.c | 101 
> ++
>  include/drm/drmP.h|  11 +
>  include/drm/drm_crtc.h|   2 +
>  4 files changed, 130 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 998663c..59a2784 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -841,6 +841,8 @@ int drm_connector_init(struct drm_device *dev,
> drm_object_attach_property(>base,
>   dev->mode_config.dpms_property, 0);
>
> +   connector->debugfs_entry = NULL;
> +
>  out_put:
> if (ret)
> drm_mode_object_put(dev, >base);
> @@ -891,7 +893,19 @@ EXPORT_SYMBOL(drm_connector_cleanup);
>   */
>  int drm_connector_register(struct drm_connector *connector)
>  {
> -   return drm_sysfs_connector_add(connector);
> +   int ret;
> +
> +   ret = drm_sysfs_connector_add(connector);
> +   if (ret != 0)

nitpick: I've never seen "xy != 0" in DRM code, I think "if (ret)" or
"if (ret < 0)" is what we usually use..

> +   return ret;
> +
> +   ret = drm_debugfs_connector_add(connector);
> +   if (ret != 0) {
> +   drm_sysfs_connector_remove(connector);
> +   return ret;
> +   }
> +
> +   return 0;
>  }
>  EXPORT_SYMBOL(drm_connector_register);
>
> @@ -904,6 +918,7 @@ EXPORT_SYMBOL(drm_connector_register);
>  void drm_connector_unregister(struct drm_connector *connector)
>  {
> drm_sysfs_connector_remove(connector);
> +   drm_debugfs_connector_remove(connector);
>  }
>  EXPORT_SYMBOL(drm_connector_unregister);
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index b4b51d4..b57b614 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -237,5 +237,106 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> return 0;
>  }
>
> +static int connector_show(struct seq_file *m, void *data)
> +{
> +   struct drm_connector *connector = m->private;
> +   const char *status;
> +
> +   switch (connector->force) {
> +   case DRM_FORCE_ON:
> +   status = "on\n";
> +   break;
> +
> +   case DRM_FORCE_ON_DIGITAL:
> +   status = "digital\n";
> +   break;
> +
> +   case DRM_FORCE_OFF:
> +   status = "off\n";
> +   break;
> +
> +   case DRM_FORCE_UNSPECIFIED:
> +   status = "unspecified\n";
> +   break;
> +
> +   default:
> +   return 0;
> +   }
> +
> +   seq_puts(m, status);
> +
> +   return 0;
> +}
> +
> +static int connector_open(struct inode *inode, struct file *file)
> +{
> +   struct drm_connector *dev = inode->i_private;
> +
> +   return single_open(file, connector_show, dev);
> +}
> +
> +static ssize_t connector_write(struct file *file, const char __user *ubuf,
> +  size_t len, loff_t *offp)
> +{
> +   struct seq_file *m = file->private_data;
> +   struct drm_connector *connector = m->private;
> +
> +   if (strncmp(ubuf, "on", len) == 0)

That hits on "o" as strncmp("o", "on", 1) == 0. We really need a
"startswith()" macro in the kernel.. same below.

> +   connector->force = DRM_FORCE_ON;
> +   else if (strncmp(ubuf, "digital", len) == 0)
> +   connector->force = DRM_FORCE_ON_DIGITAL;
> +   else if (strncmp(ubuf, "off", len) == 0)
> +   connector->force = DRM_FORCE_OFF;
> +   else if (strncmp(ubuf, "unspecified", len) == 0)
> +   connector->force = DRM_FORCE_UNSPECIFIED;
> +   else
> +   return -EINVAL;
> +
> +   return len;
> +}
> +
> +static const struct file_operations drm_connector_fops = {
> +   .owner = THIS_MODULE,
> +   .open = connector_open,
> +   .read = seq_read,
> +   .llseek = seq_lseek,
> +   .release = single_release,
> +   .write = connector_write
> +};
> +
> +int drm_debugfs_connector_add(struct drm_connector *connector)
> +{
> +   struct drm_minor *minor = connector->dev->primary;
> +   struct dentry *root, *ent;
> +
> +   if (!minor->debugfs_root)
> +   return -1;
> +
> +   root = debugfs_create_dir(drm_get_connector_name(connector),
> + minor->debugfs_root);
> +   if (!root)
> +   return -ENOMEM;
> +
> +   connector->debugfs_entry = root;
> +
> +   /* force */
> +   ent = debugfs_create_file("force", S_IRUGO, root, connector,
> + 

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #9 from nucrap at hotmail.com ---
Appears the bug is independent of UVD enabled or not.
At least with UVD enabled I have got an additional error in dmseg:

[  236.334117] radeon :0b:00.0: GPU fault detected: 146 0x0ee6480c
[  236.334121] radeon :0b:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x10F7
[  236.334123] radeon :0b:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0604800C
[  236.334126] VM fault (0x0c, vmid 3) at page 4343, read from 'TC2'
(0x54433200) (72)

-- 
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/20140610/8fff1e13/attachment-0001.html>

[PATCH 1/3] drm: add register and unregister functions for connectors

[David Herrmann]

Hi

On Thu, May 29, 2014 at 5:57 PM, Thomas Wood  wrote:
> Introduce generic functions to register and unregister connectors. This
> provides a common place to add and remove associated user space
> interfaces.
>
> Signed-off-by: Thomas Wood 
> ---
>  Documentation/DocBook/drm.tmpl|  6 +++---
>  drivers/gpu/drm/armada/armada_output.c|  4 ++--
>  drivers/gpu/drm/ast/ast_mode.c|  4 ++--
>  drivers/gpu/drm/bridge/ptn3460.c  |  2 +-
>  drivers/gpu/drm/drm_crtc.c| 30 
> ++-
>  drivers/gpu/drm/drm_sysfs.c   |  2 --
>  drivers/gpu/drm/exynos/exynos_dp_core.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |  6 +++---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/gma500/cdv_intel_crt.c|  4 ++--
>  drivers/gpu/drm/gma500/cdv_intel_dp.c |  4 ++--
>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c   |  4 ++--
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  4 ++--
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c |  4 ++--
>  drivers/gpu/drm/gma500/oaktrail_hdmi.c|  2 +-
>  drivers/gpu/drm/gma500/oaktrail_lvds.c|  2 +-
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  4 ++--
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  4 ++--
>  drivers/gpu/drm/i915/intel_crt.c  |  2 +-
>  drivers/gpu/drm/i915/intel_display.c  |  2 +-
>  drivers/gpu/drm/i915/intel_dp.c   |  4 ++--
>  drivers/gpu/drm/i915/intel_dsi.c  |  2 +-
>  drivers/gpu/drm/i915/intel_dvo.c  |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  2 +-
>  drivers/gpu/drm/i915/intel_lvds.c |  2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c | 10 -
>  drivers/gpu/drm/i915/intel_tv.c   |  2 +-
>  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
>  drivers/gpu/drm/msm/hdmi/hdmi_connector.c |  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_connector.c   |  4 ++--
>  drivers/gpu/drm/omapdrm/omap_connector.c  |  4 ++--
>  drivers/gpu/drm/qxl/qxl_display.c |  4 ++--
>  drivers/gpu/drm/radeon/radeon_connectors.c|  6 +++---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |  4 ++--
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c |  6 +++---
>  drivers/gpu/drm/tegra/output.c|  4 ++--
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c |  2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c |  2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c|  2 +-
>  drivers/gpu/drm/udl/udl_connector.c   |  4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c   |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c  |  2 +-
>  drivers/staging/imx-drm/imx-drm-core.c|  6 +++---

You even caught imx.. and you removed the EXPORT_SYMBOL. So looks all
good to me.
I like that refactoring and I don't think we need an ACK from all
driver authors. This is:

Reviewed-by: David Herrmann 

Maybe Daniel or Dave can pick this up?

Thanks
David

>  include/drm/drm_crtc.h|  2 ++
>  49 files changed, 110 insertions(+), 82 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 00f1c25..0f96b25 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -1574,7 +1574,7 @@ int max_width, max_height;
>The connector is then registered with a call to
>drm_connector_init with a pointer to the 
> connector
>functions and a connector type, and exposed through sysfs with a 
> call to
> -  drm_sysfs_connector_add.
> +  drm_connector_register.
>  
>  
>Supported connector types are
> @@ -1732,7 +1732,7 @@ int max_width, max_height;
> (drm_encoder_cleanup) and connectors
> (drm_connector_cleanup). Furthermore, connectors
> that have been added to sysfs must be removed by a call to
> -   drm_sysfs_connector_remove before calling
> +   drm_connector_unregister before calling
> drm_connector_cleanup.
>
>
> @@ -1777,7 +1777,7 @@ void intel_crt_init(struct drm_device *dev)
> drm_encoder_helper_add(_output->enc, _crt_helper_funcs);
> drm_connector_helper_add(connector, 
> _crt_connector_helper_funcs);
>
> -   drm_sysfs_connector_add(connector);
> +   drm_connector_register(connector);
>  }]]>
>
>  In the example above (taken from the i915 driver), a CRTC, connector 
> and
> diff --git a/drivers/gpu/drm/armada/armada_output.c 
> b/drivers/gpu/drm/armada/armada_output.c
> index d685a54..abbc309 100644
> --- 

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Tue, Jun 10, 2014 at 05:14:21PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> > where 'M' is the IPU DI clock muxer.  However, we're currently setting
> > this up as:
> > 
> > LM --+ LDB serial
> >   `- /7 -+ LDB DI clock
> > IPM --- /N  IM --- IPU DI clock
> > 
> > and hoping that the LDB and IPU DI clocks are appropriately synchronised.
> 
> I've just found that we do indeed do this - but there's nothing to
> switch the configuration back when the LDB is no longer using a
> particular DI.
> 
> Also, I'm having a hard time working out why we have the LDB being
> given all sorts of clocks...
> 
> LM --+- LDB serial(clks 33, aka di0_pll)
>   `- /7 -+- LDB DI clock  (clks 135, aka di0)
>   `- IM --- IPU DI clock  (clks 39, aka di0_sel)
> 
> The LDB is given all of these to play with, including reprogramming
> the IM, and there's nothing which ever programs IM to anything but
> the LDB DI clock once it's set there.

*Sigh*... is the clock tree represented in Linux even correct?

--|\
--| |
--| |--+-
--| |  ^ ldb_di0_sel   |
--|/ (clks 33) |
   `-- /3.5  /2 -- G -+--
  ^   ^ ldb_di0_podf  | ^ ldb_di0
  ldb_di0_div_3_5 |
   .--'
   |
   '--|\
 (ldb_di1)| |
 (ipp_di0)| |- G 
 (ipp_di1)| | ^ ^ ipu1_di0
(ipu1_di0_pre)|/ ipu1_di0_sel

This diagram is drawn from the code in clk-imx6.c, and it does not
agree with what is in the SoC manuals - this is the representation
redrawn from the manuals:

--|\
--| |
--| |--+-- G 
--| |  ^ ldb_di0_sel   |^ ldb serial
--|/ (clks 33) |
   `-- /3.5  /2 -+---
  ^   ^ ldb_di0_podf |  ^ ldb di
  ldb_di0_div_3_5|
   .-'
   |
   '--|\
 (ldb_di1)| |
 (ipp_di0)| |- G 
 (ipp_di1)| | ^ ^ ipu1_di0
(ipu1_di0_pre)|/ ipu1_di0_sel


The difference is, there is no clock gate between the LDB DI clock and
the /7 divider, but there is a clock gate on the LDB serial clock.

In another location, the iMX6QDL manual suggests that it may be more
like this:

--|\
--| |
--| |--- cg ---+-
--| |  ^ ldb_di0_sel   |^ ldb serial
--|/ (clks 33) |
   `-- /3.5  /2 -+---
  ^   ^ ldb_di0_podf |  ^ ldb di
  ldb_di0_div_3_5|
   .-'
   |
   '--|\
 (ldb_di1)| |
 (ipp_di0)| |
 (ipp_di1)| | ^ ^ ipu1_di0
(ipu1_di0_pre)-- cg --|/ ipu1_di0_sel

although "cg" is not defined what it is.  Another place seems to
confirm the above diagram, saying that the "ldb_di0_clk_enable"
gating bits controls both "ch_0_serial_clk" (presumably the
ldb serial clock) and "di_0_clk_nc" (presumably the ldb di clock.
If that's correct "cg" refers to the clock gating via the CCM_CCGR
registers, which appear in the CCM clock tree diagram under LPCG.

So... I wonder which one of these three is actually the right one...

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

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

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

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

--- Comment #11 from o-k at gmx.at ---
Yes the issue is still active with 3.14.4. I tested the open driver up to
3.15rc4 and there were no changes yet. Neither in performance nor fan noise.
(on the R9 270 from MSI)

-- 
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/20140610/c49be8dc/attachment.html>

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> where 'M' is the IPU DI clock muxer.  However, we're currently setting
> this up as:
> 
> LM --+ LDB serial
>   `- /7 -+ LDB DI clock
> IPM --- /N  IM --- IPU DI clock
> 
> and hoping that the LDB and IPU DI clocks are appropriately synchronised.

I've just found that we do indeed do this - but there's nothing to
switch the configuration back when the LDB is no longer using a
particular DI.

Also, I'm having a hard time working out why we have the LDB being
given all sorts of clocks...

LM --+- LDB serial  (clks 33, aka di0_pll)
  `- /7 -+- LDB DI clock(clks 135, aka di0)
  `- IM --- IPU DI clock(clks 39, aka di0_sel)

The LDB is given all of these to play with, including reprogramming
the IM, and there's nothing which ever programs IM to anything but
the LDB DI clock once it's set there.

Not only does this feel horribly unclean from the DT perspective, but
it's also a horrid violation of reasonable layering.  What if we wanted
to fix this by adding control of di0_sel to the HDMI interface too?
We then need to list yet again the IPU DI clock and the desired input
clock there, and make the imx-hdmi code aware of that.

Wouldn't it be better to have the ipuv3-crtc, or even the IPU DI code
be in control of its external clock mux, and request the IPU DI code
to select a particular input clock?  In other words, have one central
place where the IPU DI clock is controlled, rather than ending up with
it spread through lots of different sub-drivers?

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

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #3 from Sylvain BERTRAND  ---
Created attachment 100833
  --> https://bugs.freedesktop.org/attachment.cgi?id=100833=edit
linux config file

I don't get anything in dmesg after increasing drm debug to 2 in sysfs. But I
wonder if the fedora rawhide debug kernel has the proper enabled options for
drm debugging. I attached the linux config file to allow you to quickly check.

-- 
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/20140610/f78a083c/attachment-0001.html>

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Tue, Jun 10, 2014 at 09:58:54AM -0300, Fabio Estevam wrote:
> Booting the kernel with the HDMI cable connected (no image is seen on
> HDMI, only on LVDS):

Reformatting a bit:

> disp 0: panel size = 1920 x 1080
> Clocks: IPU 26400Hz DI 2400Hz Needed 13850Hz
>   IPU clock can give 13200 with divider 2, error -4.3%
> Want 13850Hz IPU 26400Hz DI 13850Hz using DI, 13850Hz
> disp 1: panel size = 1024 x 768
> Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
> Want 6500Hz IPU 26400Hz DI 6499Hz using DI, 6499Hz
> 
> After cable removal:
> disp 0: panel size = 1024 x 768
> Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
> Want 6500Hz IPU 26400Hz DI 6499Hz using DI, 6499Hz

So here we can see that the clock for DI0 got changed beneath it from
138.5MHz to 65MHz, probably when the DI1 clock was changed.

> After cable re-insertion (image is seen on both HDMI and LVDS):
> disp 0: panel size = 1920 x 1080
> Clocks: IPU 26400Hz DI 6499Hz Needed 13850Hz
>   IPU clock can give 13200 with divider 2, error -4.3%
> Want 13850Hz IPU 26400Hz DI 12997Hz using DI, 12997Hz
> disp 1: panel size = 1024 x 768
> Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
> Want 6500Hz IPU 26400Hz DI 6499Hz using DI, 6499Hz

The strange thing here is that DI0, when asking for 138.5MHz, only gets
130MHz (a multiple of DI1's frequency) yet when DI1 reduced it to 65MHz,
the CCF just obliged.

Let's go back to the basic requirements for LDB, because I think there's
a bug here.

1. the LDB serial clock must be 7x the LDB DI clock.
2. for single/split/separate mode, the IPU DI clock must be the same
   and synchronous with the LDB DI clock.
3. for dual mode, the IPU DI clock must be twice the LDB DI clock, and
   must be synchronised with the LDB DI clock.

(1) is provided for us via the CCM clock tree - there is already a /7
divider between the LDB serial clock and the LDB DI clock:

LM --+ LDB serial
  `- /7 -- LDB DI clock

where LM is the LDB clock muxer.

I'm going to leave case (3) for the time being, because at the moment, I
can't see how to achieve it given the clock tree structure that the iMX6
CPUs offer - I'm going to make the assumption at the present time that
this mode is not supported.

The easiest way to achieve (2) is to set the IPU DI clock mux to select
the LDB DI clock directly:

LM --+ LDB serial
  `- /7 -+ LDB DI clock
  `- IM -- IPU DI clock

where 'M' is the IPU DI clock muxer.  However, we're currently setting
this up as:

LM --+ LDB serial
  `- /7 -+ LDB DI clock
IPM --- /N  IM --- IPU DI clock

and hoping that the LDB and IPU DI clocks are appropriately synchronised.
This is the bug I refer to above.

Finally, for HDMI, we need:

PLL5 -- IPM -- IM -- IPU DI clock

What this implies is that we need control of the IPU DI clock muxer (IM)
and each DI needs to know what kind of display bridge(s) are connected
to it, so that the appropriate parent(s) can be selected.

We can get a little closer to that (and clean up the code) with the patch
below.  It gives us some of the information we have really been wanting to
know all along in ipu_crtc_mode_set(), that is which kinds of bridges are
connected to the DI.

What we /really/ need to solve the above problem is exactly which bridges
are connected as well - whether it's LDB0 or LDB1, and also how to get at
the clocks to be able to control that mux.  I'm at a loss how best to do
that given the complexity of iMX6 DT, and I don't think we want to add
these to the IPU/DI node as the IPU/DI isn't really connected to these
clocks - it's connected to the IM mux which is internal to the CCM.

I think this patch also should help Denis Carikli, as the polarity of
the clock signal (etc) also depends on the type(s) of encoders attached
to the DI.  We really should fail if we end up with encoders with
incompatible requirements trying to be bound to a single DI.

(side note: I'd really like to get rid of imx_drm_panel_format*()...)

In any case, to fix this I think we're looking at changing the DT stuff
again, and as the IPU code is moving out of drivers/staging, this is going
to become increasing difficult... 

 drivers/staging/imx-drm/imx-drm-core.c |  3 +--
 drivers/staging/imx-drm/imx-drm.h  |  2 +-
 drivers/staging/imx-drm/ipuv3-crtc.c   | 40 +++---
 3 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 7da0cad27b49..c538c82f8a32 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -115,8 +115,7 @@ int imx_drm_panel_format_pins(struct drm_encoder *encoder,
helper = _crtc->imx_drm_helper_funcs;
if (helper->set_interface_pix_fmt)
return 

[PATCH 5/5] drm/i915: enable fastboot by default

[Daniel Vetter]

On Fri, Jun 06, 2014 at 02:12:44PM +0300, Jani Nikula wrote:
> On Thu, 05 Jun 2014, Jesse Barnes  wrote:
> > Let them eat mincemeat pie.
> >
> > Signed-off-by: Jesse Barnes 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > b/drivers/gpu/drm/i915/i915_params.c
> > index d05a2af..081ab2f 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
> > .preliminary_hw_support = 
> > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> > .disable_power_well = 1,
> > .enable_ips = 1,
> > -   .fastboot = 0,
> > +   .fastboot = 42,
> 
> The answer to the ultimate question of life, the universe, and
> everything should simply be "true" here. Personally, I don't think it's
> a bad answer.
> 
> > .prefault_disable = 0,
> > .reset = true,
> > .invert_brightness = 0,
> > @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, "Enable IPS (default: 
> > true)");
> >  
> >  module_param_named(fastboot, i915.fastboot, bool, 0600);
> 
> Side note, why do we allow the param to be changed after boot?

Because fastboot works for every modeset, or at least should. E.g. if you
go from an upscale panel resolotion to the full one we still want to just
fixup the pfit, even when it's a normal modeset.

So fastboot really is a bit a misnomer, since the leftover bits (after
I've convinced Jesse that the fb takeover should be done unconditionally
really) is just some modeset fastpaths.

Aside: We still have a leak on the inherited fb, see

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

-Daniel

> 
> BR,
> Jani.
> 
> >  MODULE_PARM_DESC(fastboot,
> > -   "Try to skip unnecessary mode sets at boot time (default: false)");
> > +   "Try to skip unnecessary mode sets at boot time (default: true)");
> >  
> >  module_param_named(prefault_disable, i915.prefault_disable, bool, 0600);
> >  MODULE_PARM_DESC(prefault_disable,
> > -- 
> > 1.8.3.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

[Daniel Vetter]

On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> Let them eat mincemeat pie.
> 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/i915/i915_params.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index d05a2af..081ab2f 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
>   .preliminary_hw_support = 
> IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
>   .disable_power_well = 1,
>   .enable_ips = 1,
> - .fastboot = 0,
> + .fastboot = 42,
>   .prefault_disable = 0,
>   .reset = true,
>   .invert_brightness = 0,
> @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, "Enable IPS (default: 
> true)");
>  
>  module_param_named(fastboot, i915.fastboot, bool, 0600);
>  MODULE_PARM_DESC(fastboot,
> - "Try to skip unnecessary mode sets at boot time (default: false)");
> + "Try to skip unnecessary mode sets at boot time (default: true)");

Nah, that wasn't the intention of this option. It was meant as a hack to
experiment around with fastboot and get things going, but imo we need to
really do the full modeset and short-circuit if the state matches.

And there's still a bunch of things we don't track like infoframes which
we either need to fix up (similar to the pfit fixup) or quirk to disallow
fastboot.
-Daniel

>  
>  module_param_named(prefault_disable, i915.prefault_disable, bool, 0600);
>  MODULE_PARM_DESC(prefault_disable,
> -- 
> 1.8.3.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH 4/5] drm/i915: use current mode if the size matches the preferred mode

[Daniel Vetter]

On Thu, Jun 05, 2014 at 11:24:30AM -0700, Jesse Barnes wrote:
> From: Kristian H?gsberg 
> 
> The BIOS may set a native mode that doesn't quite match the preferred
> mode timings.  It should be ok to use however if it uses the same size,
> so try to avoid a mode set in that case.
> 
> Signed-off-by: Kristian H?gsberg 
> Signed-off-by: Jesse Barnes 

Not sure we want this since this seems to override the cmdline options to
force a specific edid. Also not sure whether we shouldn't just add this as
the preferred mode when probing (before the preferred mode the vbt/edid
provides ofc).

What exactly is the mismatch here? It could be DRRS or something fancy,
too.

Not sure what to do here really.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 47 
> +++---
>  1 file changed, 18 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 088fe93..09819ae 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -379,42 +379,31 @@ static bool intel_fb_initial_config(struct 
> drm_fb_helper *fb_helper,
>   /* go for command line mode first */
>   modes[i] = drm_pick_cmdline_mode(fb_conn, width, height);
>  
> - /* try for preferred next */
> + /* try for preferred next or match current */
>   if (!modes[i]) {
> - DRM_DEBUG_KMS("looking for preferred mode on connector 
> %s\n",
> -   connector->name);
> - modes[i] = drm_has_preferred_mode(fb_conn, width,
> -   height);
> - }
> + struct drm_display_mode *preferred;
>  
> - /* No preferred mode marked by the EDID? Are there any modes? */
> - if (!modes[i] && !list_empty(>modes)) {
> - DRM_DEBUG_KMS("using first mode listed on connector 
> %s\n",
> + DRM_DEBUG_KMS("looking for preferred mode on connector 
> %s\n",
> connector->name);
> - modes[i] = list_first_entry(>modes,
> - struct drm_display_mode,
> - head);
> - }
> + preferred = drm_has_preferred_mode(fb_conn, width,
> +height);
>  
> - /* last resort: use current mode */
> - if (!modes[i]) {
> - /*
> -  * IMPORTANT: We want to use the adjusted mode (i.e.
> -  * after the panel fitter upscaling) as the initial
> -  * config, not the input mode, which is what crtc->mode
> -  * usually contains. But since our current fastboot
> -  * code puts a mode derived from the post-pfit timings
> -  * into crtc->mode this works out correctly. We don't
> -  * use hwmode anywhere right now, so use it for this
> -  * since the fb helper layer wants a pointer to
> -  * something we own.
> -  */
> - DRM_DEBUG_KMS("looking for current mode on connector 
> %s\n",
> -   connector->name);
>   intel_mode_from_pipe_config(>crtc->hwmode,
>   
> _intel_crtc(encoder->crtc)->config);
> - modes[i] = >crtc->hwmode;
> + modes[i] = >crtc->hwmode;
> +
> + if (preferred &&
> + !drm_mode_same_size(preferred, modes[i])) {
> + DRM_DEBUG_KMS("using preferred mode %s "
> +   "instead of current mode %s "
> +   "on connector %d\n",
> +   preferred->name,
> +   modes[i]->name,
> +   fb_conn->connector->base.id);
> + modes[i] = preferred;
> + }
>   }
> +
>   crtcs[i] = new_crtc;
>  
>   DRM_DEBUG_KMS("connector %s on pipe %d [CRTC:%d]: %dx%d%s\n",
> -- 
> 1.8.3.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

Hi Tim,

On Tue, Jun 10, 2014 at 3:54 PM, Tim Harvey  wrote:

> Fabio,
>
> I'm following along with this thread as I see the same thing you do on
> our Ventana boards that support both LVDS and HDMI: without
> hot-plugging the HDMI connector I get not HDMI out simply by having
> the LVDS node populated.
>
> I am curious however how you are getting simultaneous display on both
> LVDS and HDMI on a SabreSD board as the standard resistor loading
> would make the EDID's of both conflict (which causes EDID read
> failures) - perhaps you are using an LVDS display with no EDID or

Yes, there is no EDID in the LVDS I am using.

imxqdl-sabresd.dtsi declares the LVDS resolution to be 1024x768 and it
never changes.

[PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

[Daniel Vetter]

On Thu, Jun 05, 2014 at 11:24:28AM -0700, Jesse Barnes wrote:
> Some machines (like MBAs) might use a tiled framebuffer but not enable
> display swizzling at boot time.  We want to preserve that configuration
> if possible to prevent a boot time mode set.  On IVB+ it shouldn't
> affect performance anyway since the memory controller does internal
> swizzling anyway.
> 
> For most other configs we'll be able to enable swizzling at boot time,
> since the initial framebuffer won't be tiled, thus we won't see any
> corruption when we enable it.
> 
> v2: preserve swizzling if BIOS had it set (Daniel)
> v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel)
> check display swizzle setting in detect_bit_6_swizzle (Daniel)
> use gen6 as cutoff point (Daniel)
> 
> Reported-by: Kristian H?gsberg 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  1 +
>  drivers/gpu/drm/i915/i915_gem.c|  3 +++
>  drivers/gpu/drm/i915/i915_gem_tiling.c | 38 
> +++---
>  drivers/gpu/drm/i915/intel_display.c   |  3 +++
>  4 files changed, 28 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f57b752..f49fdcb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1405,6 +1405,7 @@ struct drm_i915_private {
>   struct intel_vbt_data vbt;
>  
>   bool bios_ssc; /* BIOS had SSC enabled at boot? */
> + bool preserve_bios_swizzle;
>  
>   /* overlay */
>   struct intel_overlay *overlay;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index bfc7af0..0b168fb 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4580,6 +4580,9 @@ void i915_gem_init_swizzling(struct drm_device *dev)
>   dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
>   return;
>  
> + if (INTEL_INFO(dev)->gen >= 6 && dev_priv->preserve_bios_swizzle)
> + return;
> +

Above two hunks shouldnt be needed if the setup in
i915_gem_detect_bit_6_swizzle works correctly.

>   I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
>DISP_TILE_SURFACE_SWIZZLING);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
> b/drivers/gpu/drm/i915/i915_gem_tiling.c
> index cb150e8..73005ad 100644
> --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
> +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
> @@ -91,26 +91,30 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
>   uint32_t swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
>   uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
>  
> - if (IS_VALLEYVIEW(dev)) {
> - swizzle_x = I915_BIT_6_SWIZZLE_NONE;
> - swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> - } else if (INTEL_INFO(dev)->gen >= 6) {
> + if (INTEL_INFO(dev)->gen >= 6) {
>   uint32_t dimm_c0, dimm_c1;
> - dimm_c0 = I915_READ(MAD_DIMM_C0);
> - dimm_c1 = I915_READ(MAD_DIMM_C1);
> - dimm_c0 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
> - dimm_c1 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
> - /* Enable swizzling when the channels are populated with
> -  * identically sized dimms. We don't need to check the 3rd
> -  * channel because no cpu with gpu attached ships in that
> -  * configuration. Also, swizzling only makes sense for 2
> -  * channels anyway. */
> - if (dimm_c0 == dimm_c1) {
> - swizzle_x = I915_BIT_6_SWIZZLE_9_10;
> - swizzle_y = I915_BIT_6_SWIZZLE_9;
> - } else {
> +
> + /* Make sure to honor boot time display configuration */
> + if (!(I915_READ(DISP_ARB_CTL) & DISP_TILE_SURFACE_SWIZZLING)) {

Not quite what I had in mind. Imo we need to check for whether any
inherited fbs are tiled and if so also inherit the swizzle setting
unconditionally, whether it is swizzled or unswizzled. See

http://patchwork.freedesktop.org/patch/22204/

Cheers, Daniel

>   swizzle_x = I915_BIT_6_SWIZZLE_NONE;
>   swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> + } else {
> + dimm_c0 = I915_READ(MAD_DIMM_C0);
> + dimm_c1 = I915_READ(MAD_DIMM_C1);
> + dimm_c0 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
> + dimm_c1 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
> + /* Enable swizzling when the channels are populated with
> +  * identically sized dimms. We don't need to check the
> +  * 3rd channel because no cpu with gpu attached ships
> +  * in that configuration. Also, swizzling only makes
> +  * sense for 2 channels anyway. */
> + if (dimm_c0 == 

[Intel-gfx] [PATCH 1/5] drm/i915: preserve SSC if previously set v2

[Daniel Vetter]

On Thu, Jun 05, 2014 at 11:24:27AM -0700, Jesse Barnes wrote:
> Some machines may have a broken VBT or no VBT at all, but we still want
> to use SSC there.  So check for it and keep it enabled if we see it
> already on.  Based on an earlier fix from Kristian.
> 
> v2: honor modparam if set too (Daniel)
> read out at init time and store for panel_use_ssc() use (Jesse)
> 
> Reported-by: Kristian H?gsberg 
> Signed-off-by: Jesse Barnes 

Ugh.

This means the BIOS idea of when we need SSC and ours are diverging, which
isn't good. And I think we should further lock this down by tracking the
"uses SSC refclk" state in the pipe config, just to make sure we don't
fumble this.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_display.c | 11 ++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8631fb3..f57b752 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1404,6 +1404,8 @@ struct drm_i915_private {
>   struct intel_opregion opregion;
>   struct intel_vbt_data vbt;
>  
> + bool bios_ssc; /* BIOS had SSC enabled at boot? */
> +
>   /* overlay */
>   struct intel_overlay *overlay;
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b5cbb28..0e8c9bc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5355,7 +5355,7 @@ static inline bool intel_panel_use_ssc(struct 
> drm_i915_private *dev_priv)
>  {
>   if (i915.panel_use_ssc >= 0)
>   return i915.panel_use_ssc != 0;
> - return dev_priv->vbt.lvds_use_ssc
> + return (dev_priv->vbt.lvds_use_ssc || dev_priv->bios_ssc)
>   && !(dev_priv->quirks & QUIRK_LVDS_SSC_DISABLE);
>  }
>  
> @@ -12478,6 +12478,7 @@ void intel_modeset_setup_hw_state(struct drm_device 
> *dev,
>  
>  void intel_modeset_gem_init(struct drm_device *dev)
>  {
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_crtc *c;
>   struct intel_framebuffer *fb;
>  
> @@ -12485,6 +12486,14 @@ void intel_modeset_gem_init(struct drm_device *dev)
>   intel_init_gt_powersave(dev);
>   mutex_unlock(>struct_mutex);
>  
> + /*
> +  * There may be no VBT; and if the BIOS enabled SSC we can
> +  * just keep using it to avoid unnecessary flicker.
> +  */
> + if ((HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) &&
> + (I915_READ(PCH_DREF_CONTROL) & DREF_SSC1_ENABLE))
> + dev_priv->bios_ssc = true;
> +
>   intel_modeset_init_hw(dev);
>  
>   intel_setup_overlay(dev);
> -- 
> 1.8.3.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

looking for i915 direct programming sample application

[Jani Nikula]

On Sun, 08 Jun 2014, Matt Turner  wrote:
> On Sat, Jun 7, 2014 at 3:45 PM, G?bor Bereczki
>  wrote:
>> did some  more research. Is the following correct?
>> -OpenCL is not yet supported for Intel GPU on Linux
>
> The Beignet project [1] supports OpenCL IvyBridge (and Haswell, I think).
>
> I believe your time would be much better spent contributing to the
> Beignet project than attempting what you're suggesting.

Agreed.

However, you might find intel-gpu-tools [1] interesting. It's not your
pretty textbook examples, and there are sharp edges, because it's mostly
debug tools and tests, but I presume some of the code is the kind you're
looking for.

BR,
Jani.


[1] http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 3/5] gpu/drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.

[Konrad Rzeszutek Wilk]

On Sat, May 31, 2014 at 12:00:45PM +0900, Tetsuo Handa wrote:
> >From 4e8d1a83629c5966bfd401c5f2187355624194f2 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Sat, 31 May 2014 09:59:44 +0900
> Subject: [PATCH 3/5] gpu/drm/ttm: Use mutex_trylock() to avoid deadlock 
> inside shrinker functions.
> 
> I can observe that RHEL7 environment stalls with 100% CPU usage when a
> certain type of memory pressure is given. While the shrinker functions
> are called by shrink_slab() before the OOM killer is triggered, the stall
> lasts for many minutes.
> 
> One of reasons of this stall is that
> ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
> are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with
> _manager->lock held causes someone (including kswapd) to deadlock when
> these functions are called due to memory pressure. This patch changes
> "mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
> avoid deadlock.
> 
> Signed-off-by: Tetsuo Handa 
> Cc: stable  [3.3+]
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index d8e59f7..620da39 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -1014,7 +1014,8 @@ ttm_dma_pool_shrink_scan(struct shrinker *shrink, 
> struct shrink_control *sc)
>   if (list_empty(&_manager->pools))
>   return SHRINK_STOP;
>  
> - mutex_lock(&_manager->lock);
> + if (!mutex_lock(&_manager->lock))
> + return SHRINK_STOP;

Hmm..

/home/konrad/linux/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: In function 
?ttm_dma_pool_shrink_scan?:
/home/konrad/linux/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1015:2: error: 
invalid use of void expression
  if (!mutex_lock(&_manager->lock))

This is based on v3.15 with these patches.

>   if (!_manager->npools)
>   goto out;
>   pool_offset = ++start_pool % _manager->npools;
> @@ -1047,7 +1048,8 @@ ttm_dma_pool_shrink_count(struct shrinker *shrink, 
> struct shrink_control *sc)
>   struct device_pools *p;
>   unsigned long count = 0;
>  
> - mutex_lock(&_manager->lock);
> + if (!mutex_trylock(&_manager->lock))
> + return 0;
>   list_for_each_entry(p, &_manager->pools, pools)
>   count += p->pool->npages_free;
>   mutex_unlock(&_manager->lock);
> -- 
> 1.7.1

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #8 from Alex Deucher  ---
(In reply to comment #7)
> 
> I will try with UVD enabled but anyways this should be fixed.

Right.  I just want to figure out where the issue may be (UVD or 3D).

-- 
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/20140610/92888a12/attachment.html>

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #7 from nucrap at hotmail.com ---
Thanks for the hint :)
The radeon vdpau driver is installed on my system but hw accelaration was of
course disabled in my mms.cfg file.

I will try with UVD enabled but anyways this should be fixed.

-- 
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/20140610/83fb5565/attachment.html>

[Bug 77471] VESA VGA to radeondri handoff results in boot hang

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

https://bugzilla.kernel.org/show_bug.cgi?id=77471

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #2 from Alex Deucher  ---
Can you attach the dmesg output from a sucessful load the driver?  What GPU is
this?

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

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Tue, Jun 10, 2014 at 2:04 PM, Russell King - ARM Linux
 wrote:

> This diagram is drawn from the code in clk-imx6.c, and it does not
> agree with what is in the SoC manuals - this is the representation
> redrawn from the manuals:


> The difference is, there is no clock gate between the LDB DI clock and
> the /7 divider, but there is a clock gate on the LDB serial clock.

This is the correct version. "i.MX 6Dual/6Quad Applications Processor
Reference Manual - Rev. 1, 04/2013" shows it incorrectly though.

[PATCH v3 1/4] drm/crtc: Add property for aspect ratio

[Vandana Kannan]

On Jun-05-2014 2:58 PM, Thierry Reding wrote:
> On Thu, Jun 05, 2014 at 02:40:08PM +0530, Vandana Kannan wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> [...]
>>  /**
>> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
>> + * @dev: DRM device
>> + *
>> + * Called by a driver the first time it's needed, must be attached to 
>> desired
>> + * connectors.
>> + */
>> +int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
>> +{
>> +if (dev->mode_config.aspect_ratio_property)
>> +return 0;
>> +
>> +dev->mode_config.aspect_ratio_property =
>> +drm_property_create_enum(dev, 0, "aspect ratio",
>> +drm_aspect_ratio_enum_list,
>> +ARRAY_SIZE(drm_aspect_ratio_enum_list));
>> +
>> +return 0;
> 
> Sorry for not noticing this before: what if drm_propert_create_enum()
> fails? Should that return an error? This function will currently
> silently ignore failure to create the property.
> 
> Thierry
> 
Yes..
I can
1. modify this to return the property (which would be NULL if create
fails) and have a NULL check at the calling end or
2. have a NULL check for the property at the calling end keeping the
existing implementation or
3. return a non-zero value in case of failure.

Please let me know your inputs on this..
- Vandana

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

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

https://bugzilla.kernel.org/show_bug.cgi?id=76761

--- Comment #18 from Alex Deucher  ---
swoorupj you have some other issue then.  It's not related to this bug.

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

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #6 from Alex Deucher  ---
flash plugin will use vdpau (and hence possibly UVD if you have the radeon
vdpau driver installed) if you enable acceleration support in you adobe
mms.cfg.

-- 
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/20140610/f257c1bd/attachment.html>

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #5 from nucrap at hotmail.com ---
It just happened again with the same video:
http://www.youtube.com/watch?v=d-Cc6j2ZBwk in 360p, firefox.

I don't know if I use UVD, but I don't think so (I guess this would require hw
accelaration through gstreamer, but I don't have the corresponding packages
installed).

-- 
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/20140610/82dfa11a/attachment.html>

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #4 from nucrap at hotmail.com ---
Created attachment 100818
  --> https://bugs.freedesktop.org/attachment.cgi?id=100818=edit
Xorg.0.log

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

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #3 from nucrap at hotmail.com ---
Created attachment 100817
  --> https://bugs.freedesktop.org/attachment.cgi?id=100817=edit
dmesg

-- 
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/20140610/9356ac4a/attachment.html>

[PATCH v3 1/4] drm/crtc: Add property for aspect ratio

[Thierry Reding]

On Tue, Jun 10, 2014 at 02:00:37PM +0530, Vandana Kannan wrote:
> On Jun-05-2014 2:58 PM, Thierry Reding wrote:
> > On Thu, Jun 05, 2014 at 02:40:08PM +0530, Vandana Kannan wrote:
> > [...]
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > [...]
> >>  /**
> >> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
> >> + * @dev: DRM device
> >> + *
> >> + * Called by a driver the first time it's needed, must be attached to 
> >> desired
> >> + * connectors.
> >> + */
> >> +int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
> >> +{
> >> +  if (dev->mode_config.aspect_ratio_property)
> >> +  return 0;
> >> +
> >> +  dev->mode_config.aspect_ratio_property =
> >> +  drm_property_create_enum(dev, 0, "aspect ratio",
> >> +  drm_aspect_ratio_enum_list,
> >> +  ARRAY_SIZE(drm_aspect_ratio_enum_list));
> >> +
> >> +  return 0;
> > 
> > Sorry for not noticing this before: what if drm_propert_create_enum()
> > fails? Should that return an error? This function will currently
> > silently ignore failure to create the property.
> > 
> > Thierry
> > 
> Yes..
> I can
> 1. modify this to return the property (which would be NULL if create
> fails) and have a NULL check at the calling end or
> 2. have a NULL check for the property at the calling end keeping the
> existing implementation or
> 3. return a non-zero value in case of failure.

I prefer 3. -ENOMEM sounds like a good candidate here.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/995ddec5/attachment.sig>

[PATCH] drm/tegra: Make job submission 64-bit safe

[Thierry Reding]

From: Thierry Reding 

Job submission currently relies on the fact that struct drm_tegra_reloc
and struct host1x_reloc are the same size and uses a simple call to the
copy_from_user() function to copy them to kernel space. This causes the
handle to be stored in the buffer object field, which then needs a cast
to a 32 bit integer to resolve it to a proper buffer object pointer and
store it back in the buffer object field.

On 64-bit architectures that will no longer work, since pointers are 64
bits wide whereas handles will remain 32 bits. This causes the sizes of
both structures to because different and copying will no longer work.

Fix this by adding a new function, host1x_reloc_get_user(), that copies
the structures field by field.

While at it, use substructures for the command and target buffers in
struct host1x_reloc for better readability. Also use unsized types to
make it more obvious that this isn't part of userspace ABI.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 62 -
 drivers/gpu/host1x/job.c| 22 
 include/linux/host1x.h  | 15 ++-
 3 files changed, 64 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 56ef81a6f28f..57a774b8402a 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -132,6 +132,45 @@ host1x_bo_lookup(struct drm_device *drm, struct drm_file 
*file, u32 handle)
return >base;
 }

+static int host1x_reloc_copy_from_user(struct host1x_reloc *dest,
+  struct drm_tegra_reloc __user *src,
+  struct drm_device *drm,
+  struct drm_file *file)
+{
+   u32 cmdbuf, target;
+   int err;
+
+   err = get_user(cmdbuf, >cmdbuf.handle);
+   if (err < 0)
+   return err;
+
+   err = get_user(dest->cmdbuf.offset, >cmdbuf.offset);
+   if (err < 0)
+   return err;
+
+   err = get_user(target, >target.handle);
+   if (err < 0)
+   return err;
+
+   err = get_user(dest->target.offset, >cmdbuf.offset);
+   if (err < 0)
+   return err;
+
+   err = get_user(dest->shift, >shift);
+   if (err < 0)
+   return err;
+
+   dest->cmdbuf.bo = host1x_bo_lookup(drm, file, cmdbuf);
+   if (!dest->cmdbuf.bo)
+   return -ENOENT;
+
+   dest->target.bo = host1x_bo_lookup(drm, file, target);
+   if (!dest->target.bo)
+   return -ENOENT;
+
+   return 0;
+}
+
 int tegra_drm_submit(struct tegra_drm_context *context,
 struct drm_tegra_submit *args, struct drm_device *drm,
 struct drm_file *file)
@@ -184,26 +223,13 @@ int tegra_drm_submit(struct tegra_drm_context *context,
cmdbufs++;
}

-   if (copy_from_user(job->relocarray, relocs,
-  sizeof(*relocs) * num_relocs)) {
-   err = -EFAULT;
-   goto fail;
-   }
-
+   /* copy and resolve relocations from submit */
while (num_relocs--) {
-   struct host1x_reloc *reloc = >relocarray[num_relocs];
-   struct host1x_bo *cmdbuf, *target;
-
-   cmdbuf = host1x_bo_lookup(drm, file, (u32)reloc->cmdbuf);
-   target = host1x_bo_lookup(drm, file, (u32)reloc->target);
-
-   reloc->cmdbuf = cmdbuf;
-   reloc->target = target;
-
-   if (!reloc->target || !reloc->cmdbuf) {
-   err = -ENOENT;
+   err = host1x_reloc_copy_from_user(>relocarray[num_relocs],
+ [num_relocs], drm,
+ file);
+   if (err < 0)
goto fail;
-   }
}

if (copy_from_user(job->waitchk, waitchks,
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 6f72b6e01d36..e115bf22e5d8 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -185,16 +185,16 @@ static unsigned int pin_job(struct host1x_job *job)
struct sg_table *sgt;
dma_addr_t phys_addr;

-   reloc->target = host1x_bo_get(reloc->target);
-   if (!reloc->target)
+   reloc->target.bo = host1x_bo_get(reloc->target.bo);
+   if (!reloc->target.bo)
goto unpin;

-   phys_addr = host1x_bo_pin(reloc->target, );
+   phys_addr = host1x_bo_pin(reloc->target.bo, );
if (!phys_addr)
goto unpin;

job->addr_phys[job->num_unpins] = phys_addr;
-   job->unpins[job->num_unpins].bo = reloc->target;
+   job->unpins[job->num_unpins].bo = reloc->target.bo;
job->unpins[job->num_unpins].sgt = 

[PATCH 4/4] drm/tegra: Allow non-authenticated processes to create buffer objects

[Thierry Reding]

From: Thierry Reding 

This matches what other drivers do for equivalent IOCTLs.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index f292c29ef62f..56ef81a6f28f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -598,7 +598,7 @@ static int tegra_gem_get_flags(struct drm_device *drm, void 
*data,

 static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
 #ifdef CONFIG_DRM_TEGRA_STAGING
-   DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create, DRM_UNLOCKED | 
DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_gem_create, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_gem_mmap, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_READ, tegra_syncpt_read, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_SYNCPT_INCR, tegra_syncpt_incr, DRM_UNLOCKED),
-- 
1.9.2

[PATCH 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

[Thierry Reding]

From: Thierry Reding 

The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flags of a
buffer object after it has been allocated or imported. Flags associated
with a buffer object can be queried using the DRM_TEGRA_GEM_GET_FLAGS
IOCTL.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c  | 48 
 include/uapi/drm/tegra_drm.h | 21 +++
 2 files changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 5dca20982f3b..f292c29ef62f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -548,6 +548,52 @@ static int tegra_gem_get_tiling(struct drm_device *drm, 
void *data,

return err;
 }
+
+static int tegra_gem_set_flags(struct drm_device *drm, void *data,
+  struct drm_file *file)
+{
+   struct drm_tegra_gem_set_flags *args = data;
+   struct drm_tegra_bo *bo;
+   unsigned long flags = 0;
+
+   if (args->flags & ~DRM_TEGRA_GEM_FLAGS)
+   return -EINVAL;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -EINVAL;
+
+   bo = to_tegra_bo(gem);
+   bo->flags = 0;
+
+   if (args->flags & DRM_TEGRA_GEM_BOTTOM_UP)
+   bo->flags |= TEGRA_BO_BOTTOM_UP;
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
+
+static int tegra_gem_get_flags(struct drm_device *drm, void *data,
+  struct drm_file *file)
+{
+   struct drm_tegra_gem_get_flags *args = data;
+   struct drm_tegra_bo *bo;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -EINVAL;
+
+   bo = to_tegra_bo(gem);
+   args->flags = 0;
+
+   if (bo->flags & TEGRA_BO_BOTTOM_UP)
+   args->flags |= DRM_TEGRA_GEM_BOTTOM_UP;
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
 #endif

 static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
@@ -564,6 +610,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
DRM_UNLOCKED),
 #endif
 };

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 0829f75eb986..c15d781ecc0f 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -150,6 +150,23 @@ struct drm_tegra_gem_get_tiling {
__u32 pad;
 };

+#define DRM_TEGRA_GEM_BOTTOM_UP(1 << 0)
+#define DRM_TEGRA_GEM_FLAGS(DRM_TEGRA_GEM_BOTTOM_UP)
+
+struct drm_tegra_gem_set_flags {
+   /* input */
+   __u32 handle;
+   /* output */
+   __u32 flags;
+};
+
+struct drm_tegra_gem_get_flags {
+   /* input */
+   __u32 handle;
+   /* output */
+   __u32 flags;
+};
+
 #define DRM_TEGRA_GEM_CREATE   0x00
 #define DRM_TEGRA_GEM_MMAP 0x01
 #define DRM_TEGRA_SYNCPT_READ  0x02
@@ -162,6 +179,8 @@ struct drm_tegra_gem_get_tiling {
 #define DRM_TEGRA_GET_SYNCPT_BASE  0x09
 #define DRM_TEGRA_GEM_SET_TILING   0x0a
 #define DRM_TEGRA_GEM_GET_TILING   0x0b
+#define DRM_TEGRA_GEM_SET_FLAGS0x0c
+#define DRM_TEGRA_GEM_GET_FLAGS0x0d

 #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
 #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
@@ -175,5 +194,7 @@ struct drm_tegra_gem_get_tiling {
 #define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base)
 #define DRM_IOCTL_TEGRA_GEM_SET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_SET_TILING, struct drm_tegra_gem_set_tiling)
 #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
+#define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
+#define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)

 #endif
-- 
1.9.2

[PATCH 2/4] drm/tegra: Add SET/GET_TILING IOCTLs

[Thierry Reding]

From: Thierry Reding 

Currently the tiling parameters of buffer objects can only be set at
allocation time, and only a single tiled mode is supported. This new
DRM_TEGRA_GEM_SET_TILING IOCTL allows more modes to be set and also
allows the tiling mode to be changed after the allocation. This will
enable the Tegra DRM driver to import buffers from a GPU and directly
scan them out by configuring the display controller appropriately.

To complement this, the DRM_TEGRA_GEM_GET_TILING IOCTL can query the
current tiling mode of a buffer object. This is necessary when importing
buffers via handle (as is done in Mesa for example) so that userspace
can determine the proper parameters for the 2D or 3D engines.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c  | 95 
 include/uapi/drm/tegra_drm.h | 25 
 2 files changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index fd736efd14bd..5dca20982f3b 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -455,6 +455,99 @@ static int tegra_get_syncpt_base(struct drm_device *drm, 
void *data,

return 0;
 }
+
+static int tegra_gem_set_tiling(struct drm_device *drm, void *data,
+   struct drm_file *file)
+{
+   struct drm_tegra_gem_set_tiling *args = data;
+   enum tegra_bo_tiling_mode mode;
+   struct drm_gem_object *gem;
+   unsigned long value = 0;
+   struct tegra_bo *bo;
+
+   switch (args->mode) {
+   case DRM_TEGRA_GEM_TILING_MODE_PITCH:
+   mode = TEGRA_BO_TILING_MODE_PITCH;
+
+   if (args->value != 0)
+   return -EINVAL;
+
+   break;
+
+   case DRM_TEGRA_GEM_TILING_MODE_TILED:
+   mode = TEGRA_BO_TILING_MODE_TILED;
+
+   if (args->value != 0)
+   return -EINVAL;
+
+   break;
+
+   case DRM_TEGRA_GEM_TILING_MODE_BLOCK:
+   mode = TEGRA_BO_TILING_MODE_BLOCK;
+
+   if (args->value > 5)
+   return -EINVAL;
+
+   value = args->value;
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -EINVAL;
+
+   bo = to_tegra_bo(gem);
+
+   bo->tiling.mode = mode;
+   bo->tiling.value = value;
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
+
+static int tegra_gem_get_tiling(struct drm_device *drm, void *data,
+   struct drm_file *file)
+{
+   struct drm_tegra_gem_get_tiling *args = data;
+   struct drm_gem_object *gem;
+   struct tegra_bo *bo;
+   int err = 0;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -EINVAL;
+
+   bo = to_tegra_bo(gem);
+
+   switch (bo->tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   args->mode = DRM_TEGRA_GEM_TILING_MODE_PITCH;
+   args->value = 0;
+   break;
+
+   case TEGRA_BO_TILING_MODE_TILED:
+   args->mode = DRM_TEGRA_GEM_TILING_MODE_TILED;
+   args->value = 0;
+   break;
+
+   case TEGRA_BO_TILING_MODE_BLOCK:
+   args->mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
+   args->value = bo->tiling.value;
+   break;
+
+   default:
+   err = -EINVAL;
+   break;
+   }
+
+   drm_gem_object_unreference(gem);
+
+   return err;
+}
 #endif

 static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
@@ -469,6 +562,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT, tegra_get_syncpt, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_SUBMIT, tegra_submit, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_TILING, tegra_gem_set_tiling, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
DRM_UNLOCKED),
 #endif
 };

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index b75482112428..0829f75eb986 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -129,6 +129,27 @@ struct drm_tegra_submit {
__u32 reserved[5];  /* future expansion */
 };

+#define DRM_TEGRA_GEM_TILING_MODE_PITCH 0
+#define DRM_TEGRA_GEM_TILING_MODE_TILED 1
+#define DRM_TEGRA_GEM_TILING_MODE_BLOCK 2
+
+struct drm_tegra_gem_set_tiling {
+   /* input */
+   __u32 handle;
+   __u32 mode;
+   __u32 value;
+   __u32 pad;
+};
+
+struct drm_tegra_gem_get_tiling {
+   /* input */
+   __u32 handle;
+   /* output */
+   __u32 mode;
+   __u32 value;
+   __u32 pad;
+};
+
 #define DRM_TEGRA_GEM_CREATE   

[PATCH 1/4] drm/tegra: Implement more tiling modes

[Thierry Reding]

From: Thierry Reding 

Tegra124 supports a block-linear mode in addition to the regular pitch
linear and tiled modes. Add support for these by moving the internal
representation into a structure rather than a simple flag.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/dc.c  | 102 +---
 drivers/gpu/drm/tegra/dc.h  |   5 +++
 drivers/gpu/drm/tegra/drm.h |   8 +++-
 drivers/gpu/drm/tegra/fb.c  |   9 ++--
 drivers/gpu/drm/tegra/gem.c |   2 +-
 drivers/gpu/drm/tegra/gem.h |  16 ++-
 6 files changed, 118 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index ef40381f3909..afcca04f5367 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -18,6 +18,7 @@
 struct tegra_dc_soc_info {
bool supports_interlacing;
bool supports_cursor;
+   bool supports_block_linear;
 };

 struct tegra_plane {
@@ -212,15 +213,44 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
tegra_dc_writel(dc, h_offset, DC_WINBUF_ADDR_H_OFFSET);
tegra_dc_writel(dc, v_offset, DC_WINBUF_ADDR_V_OFFSET);

-   if (window->tiled) {
-   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
-   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   if (dc->soc->supports_block_linear) {
+   unsigned long height = window->tiling.value;
+
+   switch (window->tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   value = DC_WINBUF_SURFACE_KIND_PITCH;
+   break;
+
+   case TEGRA_BO_TILING_MODE_TILED:
+   value = DC_WINBUF_SURFACE_KIND_TILED;
+   break;
+
+   case TEGRA_BO_TILING_MODE_BLOCK:
+   value = DC_WINBUF_SURFACE_KIND_BLOCK_HEIGHT(height) |
+   DC_WINBUF_SURFACE_KIND_BLOCK;
+   break;
+   }
+
+   tegra_dc_writel(dc, value, DC_WINBUF_SURFACE_KIND);
} else {
-   value = DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV |
-   DC_WIN_BUFFER_ADDR_MODE_LINEAR;
-   }
+   switch (window->tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   value = DC_WIN_BUFFER_ADDR_MODE_LINEAR_UV |
+   DC_WIN_BUFFER_ADDR_MODE_LINEAR;
+   break;

-   tegra_dc_writel(dc, value, DC_WIN_BUFFER_ADDR_MODE);
+   case TEGRA_BO_TILING_MODE_TILED:
+   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
+   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   break;
+
+   case TEGRA_BO_TILING_MODE_BLOCK:
+   DRM_ERROR("hardware doesn't support block linear 
mode\n");
+   return -EINVAL;
+   }
+
+   tegra_dc_writel(dc, value, DC_WIN_BUFFER_ADDR_MODE);
+   }

value = WIN_ENABLE;

@@ -288,6 +318,7 @@ static int tegra_plane_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
struct tegra_dc *dc = to_tegra_dc(crtc);
struct tegra_dc_window window;
unsigned int i;
+   int err;

memset(, 0, sizeof(window));
window.src.x = src_x >> 16;
@@ -301,7 +332,10 @@ static int tegra_plane_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
window.format = tegra_dc_format(fb->pixel_format, );
window.bits_per_pixel = fb->bits_per_pixel;
window.bottom_up = tegra_fb_is_bottom_up(fb);
-   window.tiled = tegra_fb_is_tiled(fb);
+
+   err = tegra_fb_get_tiling(fb, );
+   if (err < 0)
+   return err;

for (i = 0; i < drm_format_num_planes(fb->pixel_format); i++) {
struct tegra_bo *bo = tegra_fb_get_plane(fb, i);
@@ -402,8 +436,14 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
 {
struct tegra_bo *bo = tegra_fb_get_plane(fb, 0);
unsigned int h_offset = 0, v_offset = 0;
+   struct tegra_bo_tiling tiling;
unsigned int format, swap;
unsigned long value;
+   int err;
+
+   err = tegra_fb_get_tiling(fb, );
+   if (err < 0)
+   return err;

tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);

@@ -417,15 +457,44 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
tegra_dc_writel(dc, format, DC_WIN_COLOR_DEPTH);
tegra_dc_writel(dc, swap, DC_WIN_BYTE_SWAP);

-   if (tegra_fb_is_tiled(fb)) {
-   value = DC_WIN_BUFFER_ADDR_MODE_TILE_UV |
-   DC_WIN_BUFFER_ADDR_MODE_TILE;
+   if (dc->soc->supports_block_linear) {
+   unsigned long height = tiling.value;
+
+   switch (tiling.mode) {
+   case TEGRA_BO_TILING_MODE_PITCH:
+   value = DC_WINBUF_SURFACE_KIND_PITCH;
+  

[PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

[Jesse Barnes]

On Tue, 10 Jun 2014 21:33:27 +0200
Daniel Vetter  wrote:

> On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes  
> wrote:
> > Yes, that's what I do below... I even added it to the changelog:
> > http://patchwork.freedesktop.org/patch/27223/
> >
> > Did you miss the later hunk in intel_display.c?
> >
> > What we try to do here is enable swizzling if possible, which we can do
> > if no inherited fbs are tiled.
> >
> > So I think I've done exactly what you repeated above, and documented
> > it.  So you're going to need to repeat it with different words so I can
> > understand, if I'm still missing something.
> 
> In swizzle_detect:
> 
> ...
> 
> if (GEN6+) {
>   if (preserve_bios_swizzle) {
>   if (I915_READ(DISP_ARB_CTL) & DISP_TILE_SURFACE_SWIZZLING) {
>   swizzle_x = I915_BIT_6_SWIZZLE_9_10;
>   ...
>   } else {
>   swizzle_x = I915_BIT_6_SWIZZLE_NONE;
>   ...
>   }
>   } else {
>   /* existing/old logic to decide about swizzling */
>   }
> }
> 
> ...
> 
> Plus no shortcut in i915_gem_init_swizzling. Personally I'd also just use
> a small helper function to compute preserve_bios_swizzle instead of
> storing it in dev_priv (since we will only use it at exactly one place),
> but that's a pure style preference.

Doesn't this amount to the same thing?  I.e. we enable it if possible,
otherwise just report it as unswizzled?  So you're just wanting a style
change here?

-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH v13 10/10] ARM: dts: mbimx51sd: Add CMO-QVGA backlight support.

[Denis Carikli]

Signed-off-by: Denis Carikli 
---
ChangeLog v11->v13:
- No changes
ChangeLog v9->v11:
- Now uses the drm-panel instead of the display-timings.

ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- The backlight is now on at boot.

ChangeLog v6->v7:
- Shrinked even more the Cc list.

ChangeLog v5->v6:
- Reordered the Cc list.

ChangeLog v3->v5:
- Updated to the new GPIO defines.

ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51 
boards.
- This patch now only adds backlight support.
- Added some interested people in the Cc list, and removed some people that
  might be annoyed by the receiving of that patch which is unrelated to their
  subsystem.
---
 .../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts  |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts 
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
index d273d09..6e36dae 100644
--- a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -17,9 +17,19 @@
model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga", 
"eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";

+   backlight: backlight {
+   compatible = "gpio-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight_1>;
+   gpios = < 4 GPIO_ACTIVE_HIGH>;
+   default-brightness-level = <1>;
+   default-on;
+   };
+
panel: panel {
compatible = "eukrea,mbimxsd51-cmo-qvga", "simple-panel";
power-supply = <_lcd_3v3>;
+   backlight = <>;
};

reg_lcd_3v3: lcd-en {
-- 
1.7.9.5

[PATCH v13 09/10] ARM: dts: mbimx51sd: Add display support.

[Denis Carikli]

The CMO-QVGA, DVI-SVGA and DVI-VGA are added.

Signed-off-by: Denis Carikli 
---
ChangeLog v10->v13:
- Rebased
- Removed enable-active-high in reg_lcd_3v3: its GPIO
  already has the GPIO_ACTIVE_HIGH flag.
  Without this removal, the display was off at boot
  and powering it off and on was necessary to get an
  image on it after the boot.

ChangeLog v10->v11:
- Now uses the drm-panel instead of the display-timings.
  This is to get regulator support, which is lacking in
  the imx-drm driver when using the display-timings.

ChangeLog v9->v10:
- Rebased
- Now enables the cmo-qvga regulator at boot.

ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- updated pixelclk-active after the following patch:
  "imx-drm: Match ipu_di_signal_cfg's clk_pol with its description."

ChangeLog v7->v8:
- Rebased the patch: added the now required imx-drm node.
- Adapted the svga clock-frequency value in order to still
  be able to display an image after the following commit:
  "imx-drm: ipu-v3: more inteligent DI clock selection"

ChangeLog v6->v7:
- Shrinked even more the Cc list.
- Since the pingrp headers were removed, the references
  to it where replaced by the actual pins.
- Added the targets to arch/arm/boot/dts/Makefile

ChangeLog v5->v6:
- Reordered the Cc list.

ChangeLog v3->v5:
- Updated to new GPIO defines.
- Updated to new licenses checkpatch requirements.
- one whitespace cleanup.

ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51 
boards.
- This patch now only adds display support.
- Added some interested people in the Cc list, and removed some people that
  might be annoyed by the receiving of that patch which is unrelated to their
  subsystem.
- rebased and reworked the dts displays addition.
- Also rebased and reworked the fsl,pins usage.
---
 arch/arm/boot/dts/Makefile |3 ++
 .../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts  |   40 
 .../imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts  |   28 +++
 .../imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts   |   28 +++
 .../boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts  |   49 
 5 files changed, 148 insertions(+)
 create mode 100644 
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
 create mode 100644 
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
 create mode 100644 
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0f1e8be..f0ec7b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -177,6 +177,9 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx51-babbage.dtb \
imx51-digi-connectcore-jsk.dtb \
imx51-eukrea-mbimxsd51-baseboard.dtb \
+   imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dtb \
+   imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dtb \
+   imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dtb \
imx53-ard.dtb \
imx53-m53evk.dtb \
imx53-mba53.dtb \
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts 
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
new file mode 100644
index 000..d273d09
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx51-eukrea-mbimxsd51-baseboard.dts"
+
+/ {
+   model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
+   compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga", 
"eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+
+   panel: panel {
+   compatible = "eukrea,mbimxsd51-cmo-qvga", "simple-panel";
+   power-supply = <_lcd_3v3>;
+   };
+
+   reg_lcd_3v3: lcd-en {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_reg_lcd_3v3>;
+   regulator-name = "lcd-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 13 GPIO_ACTIVE_HIGH>;
+   regulator-boot-on;
+   };
+};
+
+ {
+   status = "okay";
+   fsl,panel = <>;
+};
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts 
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
new file mode 100644
index 000..323ebf4
--- /dev/null
+++ 

[PATCH v13 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Denis Carikli]

Signed-off-by: Denis Carikli 
---
ChangeLog v12->v13:
- Added a note explaining why the size is zero in
  the eukrea_mbimxsd51_dvi(s)vga structs.
ChangeLog v11->v12:
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names

ChangeLog v10->v11:
- New patch.
---
 .../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt   |7 ++
 .../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt   |7 ++
 .../bindings/panel/eukrea,mbimxsd51-dvi-vga.txt|7 ++
 drivers/gpu/drm/panel/panel-simple.c   |   83 
 4 files changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
 create mode 100644 
Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
 create mode 100644 
Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt

diff --git 
a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt 
b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
new file mode 100644
index 000..03679d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
@@ -0,0 +1,7 @@
+Eukrea CMO-QVGA (320x240 pixels) TFT LCD panel
+
+Required properties:
+- compatible: should be "eukrea,mbimxsd51-cmo-qvga"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git 
a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
new file mode 100644
index 000..f408c9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
@@ -0,0 +1,7 @@
+Eukrea DVI-SVGA (800x600 pixels) DVI output.
+
+Required properties:
+- compatible: should be "eukrea,mbimxsd51-dvi-svga"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git 
a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
new file mode 100644
index 000..8ea90da
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
@@ -0,0 +1,7 @@
+Eukrea DVI-VGA (640x480 pixels) DVI output.
+
+Required properties:
+- compatible: should be "eukrea,mbimxsd51-dvi-vga"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index a251361..adc40a7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
},
 };

+static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
+   .clock = 6500,
+   .hdisplay = 320,
+   .hsync_start = 320 + 38,
+   .hsync_end = 320 + 38 + 20,
+   .htotal = 320 + 38 + 20 + 30,
+   .vdisplay = 240,
+   .vsync_start = 240 + 15,
+   .vsync_end = 240 + 15 + 4,
+   .vtotal = 240 + 15 + 4 + 3,
+   .vrefresh = 60,
+   .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
+DRM_MODE_FLAG_POL_DE_LOW,
+};
+
+static const struct panel_desc eukrea_mbimxsd51_cmoqvga = {
+   .modes = _mbimxsd51_cmoqvga_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 73,
+   .height = 56,
+   },
+};
+
+static const struct drm_display_mode eukrea_mbimxsd51_dvisvga_mode = {
+   .clock = 44333,
+   .hdisplay = 800,
+   .hsync_start = 800 + 112,
+   .hsync_end = 800 + 112 + 32,
+   .htotal = 800 + 112 + 32 + 80,
+   .vdisplay = 600,
+   .vsync_start = 600 + 3,
+   .vsync_end = 600 + 3 + 17,
+   .vtotal = 600 + 3 + 17 + 4,
+   .vrefresh = 60,
+   .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_POSEDGE |
+DRM_MODE_FLAG_POL_DE_HIGH,
+};
+
+static const struct panel_desc eukrea_mbimxsd51_dvisvga = {
+   .modes = _mbimxsd51_dvisvga_mode,
+   .num_modes = 1,
+   /* This is a DVI adapter for external displays */
+   .size = {
+   .width = 0,
+   .height = 0,
+   },
+};
+
+static const struct drm_display_mode eukrea_mbimxsd51_dvivga_mode = {
+   .clock = 23750,
+   .hdisplay = 640,
+   .hsync_start = 640 + 80,
+   .hsync_end = 640 + 80 + 16,
+   .htotal = 640 + 80 + 16 + 64,
+   .vdisplay = 480,
+   .vsync_start = 480 + 3,
+   .vsync_end = 480 + 3 + 13,
+   .vtotal  = 480 + 3 + 13 + 4,
+   .vrefresh = 60,
+   .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_POSEDGE |
+DRM_MODE_FLAG_POL_DE_HIGH,
+};
+
+static const struct panel_desc eukrea_mbimxsd51_dvivga = {
+   .modes = _mbimxsd51_dvivga_mode,
+   .num_modes = 1,
+   /* This is a DVI adapter for external displays */
+   .size = {
+   .width = 0,
+   

[PATCH v13 07/10] imx-drm: Use drm_display_mode timings flags.

[Denis Carikli]

The previous hardware behaviour was kept if the
flags are not set.

Signed-off-by: Denis Carikli 
---
ChangeLog v12->v13:
- This patch doesn't need the DRM_MODE_FLAG_POL_*_PRESERVE flags anymore.
- code cleanup to improve readability:
  - ENABLE_POL_PRESERVE is now gone
  - Less modifications in ipu_di_init_sync_panel
  - more readable modifications in int ipu_crtc_mode_set
ChangeLog v11->v12:
- Rebased: It now uses the following new flags defines names:
  CLK_POL, ENABLE_POL
- The inversions in ipuv3-crtc.c are now fixed.
- ipuv3-crtc.c was still using mode->private_flags
  from the previous versions of this patchset, that's now fixed.

ChangeLog v10->v11:
- This patch was splitted-out and adapted from:
  "Prepare imx-drm for extra display-timings retrival."
- The display-timings dt specific part was removed.
- The flags names were changed to use the DRM ones from:
  "drm: drm_display_mode: add signal polarity flags"
---
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |4 ++--
 drivers/staging/imx-drm/ipu-v3/ipu-di.c |2 ++
 drivers/staging/imx-drm/ipuv3-crtc.c|   18 --
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h 
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index 015e3bf..94b0d8e 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -43,10 +43,10 @@ struct ipu_di_signal_cfg {
unsigned clksel_en:1;
unsigned clkidle_en:1;
unsigned data_pol:1;/* true = inverted */
-   unsigned clk_pol:1;
-   unsigned enable_pol:1;
unsigned Hsync_pol:1;   /* true = active high */
unsigned Vsync_pol:1;
+   u8 clk_pol;
+   u8 enable_pol;

u16 width;
u16 height;
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index 0ce3f52..faf08e2 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
@@ -597,6 +597,8 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct 
ipu_di_signal_cfg *sig)

if (sig->clk_pol == CLK_POL_POSEDGE)
di_gen |= DI_GEN_POLARITY_DISP_CLK;
+   else if (sig->clk_pol == CLK_POL_NEGEDGE)
+   di_gen &= ~DI_GEN_POLARITY_DISP_CLK;

ipu_di_write(di, di_gen, DI_GENERAL);

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index ba9eea3..10b46b5 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -165,8 +165,22 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;

-   sig_cfg.enable_pol = ENABLE_POL_HIGH;
-   sig_cfg.clk_pol = CLK_POL_NEGEDGE;
+   if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_POSEDGE)
+   sig_cfg.clk_pol = CLK_POL_POSEDGE;
+   else if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE)
+   sig_cfg.clk_pol = CLK_POL_NEGEDGE;
+   else
+   /* If no PIXDATA flags were set, keep the old behaviour */
+   sig_cfg.clk_pol = CLK_POL_NEGEDGE;
+
+   if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_HIGH)
+   sig_cfg.enable_pol = ENABLE_POL_HIGH;
+   else if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_LOW)
+   sig_cfg.enable_pol = ENABLE_POL_LOW;
+   else
+   /* If no DE flags were set, keep the old behaviour */
+   sig_cfg.enable_pol = ENABLE_POL_HIGH;
+
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
-- 
1.7.9.5

[PATCH v13 06/10] drm: drm_display_mode: add signal polarity flags

[Denis Carikli]

We need a way to pass signal polarity informations
  between DRM panels, and the display drivers.

To do that, a pol_flags field was added to drm_display_mode.

Signed-off-by: Denis Carikli 
---
ChangeLog v12->v13:
- Added Docbook documentation for pol_flags the struct field.
- Removed the _PRESERVE defines: it was used by patches
  against the imx_drm driver. Now theses patches have been
  adapted not to require that defines.
ChangeLog v11->v12:
- Rebased: This patch now applies against drm_modes.h
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names

ChangeLog v10->v11:
- Since the imx-drm won't be able to retrive its regulators
  from the device tree when using display-timings nodes,
  and that I was told that the drm simple-panel driver 
  already supported that, I then, instead, added what was
  lacking to make the eukrea displays work with the
  drm-simple-panel driver.

  That required a way to get back the display polarity
  informations from the imx-drm driver without affecting
  userspace.
---
 Documentation/DocBook/drm.tmpl |   30 ++
 include/drm/drm_modes.h|6 ++
 2 files changed, 36 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index c526d81..29c0e5a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2292,6 +2292,36 @@ void intel_crt_init(struct drm_device *dev)
 and height_mm fields are only used 
internally
 during EDID parsing and should not be set when creating modes 
manually.
   
+  
+The pol_flags value represents the 
display
+signal polarity flags, it can be a combination of
+
+  
+DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE
+ 
+ drive pixel data on falling edge, sample data on rising 
edge.
+ 
+  
+  
+DRM_MODE_FLAG_POL_PIXDATA_POSEDGE
+
+  Drive pixel data on rising edge, sample data on falling edge.
+
+  
+  
+DRM_MODE_FLAG_POL_DE_LOW
+
+  data-enable pulse is active low
+
+  
+  
+DRM_MODE_FLAG_POL_DE_HIGH
+
+  data-enable pulse is active low
+
+  
+
+  
 
 
   int (*mode_valid)(struct drm_connector *connector,
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 91d0582..c5cbe31 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -93,6 +93,11 @@ enum drm_mode_status {

 #define DRM_MODE_FLAG_3D_MAX   DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF

+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE  BIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE  BIT(2)
+#define DRM_MODE_FLAG_POL_DE_LOW   BIT(3)
+#define DRM_MODE_FLAG_POL_DE_HIGH  BIT(4)
+
 struct drm_display_mode {
/* Header */
struct list_head head;
@@ -144,6 +149,7 @@ struct drm_display_mode {
int vrefresh;   /* in Hz */
int hsync;  /* in kHz */
enum hdmi_picture_aspect picture_aspect_ratio;
+   unsigned int pol_flags;
 };

 /* mode specified on the command line */
-- 
1.7.9.5

[PATCH v13 05/10] ARM: dts: imx5*, imx6*: correct display-timings nodes.

[Denis Carikli]

The imx-drm driver can't use the de-active and
pixelclk-active display-timings properties yet.

Instead the data-enable and the pixel data clock
polarity are hardcoded in the imx-drm driver.

So theses properties are now set to keep
the same behaviour when imx-drm will start
using them.

Signed-off-by: Denis Carikli 
---
ChangeLog v10->v11:
- imx53-tx53-x03x.dts change was removed because it 
  already had the correct setting.
ChangeLog v9->v10:
- New patch that was splitted out of:
  "staging imx-drm: Use de-active and pixelclk-active
  display-timings."
---
 arch/arm/boot/dts/imx51-babbage.dts   |2 ++
 arch/arm/boot/dts/imx53-m53evk.dts|2 ++
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi |2 ++
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |2 ++
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi |2 ++
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi  |2 ++
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi  |2 ++
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi|2 ++
 8 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/imx51-babbage.dts 
b/arch/arm/boot/dts/imx51-babbage.dts
index ee51a10..b64a9e3 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -56,6 +56,8 @@
vfront-porch = <7>;
hsync-len = <60>;
vsync-len = <10>;
+   de-active = <1>;
+   pixelclk-active = <0>;
};
};

diff --git a/arch/arm/boot/dts/imx53-m53evk.dts 
b/arch/arm/boot/dts/imx53-m53evk.dts
index 4b036b4..d03ced7 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -41,6 +41,8 @@
vfront-porch = <9>;
vsync-len = <3>;
vsync-active = <1>;
+   de-active = <1>;
+   pixelclk-active = <0>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index d3125f0..7f993d6 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -512,6 +512,8 @@
vfront-porch = <7>;
hsync-len = <60>;
vsync-len = <10>;
+   de-active = <1>;
+   pixelclk-active = <0>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 532347f..e06cf9e 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -534,6 +534,8 @@
vfront-porch = <7>;
hsync-len = <60>;
vsync-len = <10>;
+   de-active = <1>;
+   pixelclk-active = <0>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 4c4b175..bcf5178 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -353,6 +353,8 @@
vfront-porch = <7>;
hsync-len = <60>;
vsync-len = <10>;
+   de-active = <1>;
+   pixelclk-active = <0>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 009abd6..230bbc6 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -405,6 +405,8 @@
vfront-porch = <7>;
hsync-len = <60>;
vsync-len = <10>;
+   de-active = <1>;
+   pixelclk-active = <0>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 6df6127..9f6b406 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -353,6 +353,8 @@
vfront-porch = <7>;
hsync-len = <60>;
vsync-len = <10>;
+   de-active = <1>;
+   pixelclk-active = <0>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 

[PATCH v13 04/10] imx-drm: use defines for clock polarity settings

[Denis Carikli]

Signed-off-by: Denis Carikli 
---
ChangeLog 12->v13:
- No changes
ChangeLog 11->v12:
- Improved the define names to match the hardware:
  ENABLE_POL is not a clock signal but instead an enable signal.

ChangeLog v9->v10:
- New patch which was splitted out from:
  "staging: imx-drm: Use de-active and pixelclk-active display-timings.".
- Fixes many issues in "staging: imx-drm: Use de-active and pixelclk-active
  display-timings.":
  - More clear meaning of the polarity settings.
  - The SET_CLK_POL and SET_DE_POL masks are not
needed anymore.
---
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |8 +++-
 drivers/staging/imx-drm/ipu-v3/ipu-di.c |4 ++--
 drivers/staging/imx-drm/ipuv3-crtc.c|4 ++--
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h 
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
index c2c6fab..015e3bf 100644
--- a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -27,6 +27,12 @@ enum ipuv3_type {

 #define IPU_PIX_FMT_GBR24  v4l2_fourcc('G', 'B', 'R', '3')

+#define CLK_POL_NEGEDGE0
+#define CLK_POL_POSEDGE1
+
+#define ENABLE_POL_LOW 0
+#define ENABLE_POL_HIGH1
+
 /*
  * Bitfield of Display Interface signal polarities.
  */
@@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
unsigned clksel_en:1;
unsigned clkidle_en:1;
unsigned data_pol:1;/* true = inverted */
-   unsigned clk_pol:1; /* true = rising edge */
+   unsigned clk_pol:1;
unsigned enable_pol:1;
unsigned Hsync_pol:1;   /* true = active high */
unsigned Vsync_pol:1;
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index 849b3e1..0ce3f52 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
@@ -595,7 +595,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct 
ipu_di_signal_cfg *sig)
}
}

-   if (sig->clk_pol)
+   if (sig->clk_pol == CLK_POL_POSEDGE)
di_gen |= DI_GEN_POLARITY_DISP_CLK;

ipu_di_write(di, di_gen, DI_GENERAL);
@@ -606,7 +606,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct 
ipu_di_signal_cfg *sig)
reg = ipu_di_read(di, DI_POL);
reg &= ~(DI_POL_DRDY_DATA_POLARITY | DI_POL_DRDY_POLARITY_15);

-   if (sig->enable_pol)
+   if (sig->enable_pol == ENABLE_POL_HIGH)
reg |= DI_POL_DRDY_POLARITY_15;
if (sig->data_pol)
reg |= DI_POL_DRDY_DATA_POLARITY;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 47bec5e..ba9eea3 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -165,8 +165,8 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;

-   sig_cfg.enable_pol = 1;
-   sig_cfg.clk_pol = 0;
+   sig_cfg.enable_pol = ENABLE_POL_HIGH;
+   sig_cfg.clk_pol = CLK_POL_NEGEDGE;
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
-- 
1.7.9.5

[PATCH v13 03/10] imx-drm: Correct BGR666 and the board's dts that use them.

[Denis Carikli]

The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.

Signed-off-by: Denis Carikli 
Acked-by: Philipp Zabel 
---
ChangeLog v10->v13:
- Rebased
ChangeLog v9->v10:
- Rebased.
- Added Philipp Zabel's Ack.
- Included Lothar Wa?mann's suggestion about imx-ldb.c.
- Shortened the patch title

ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.

ChangeLog v7->v8:
- Shrinked even more the Cc list.

ChangeLog v6->v7:
- Shrinked even more the Cc list.

ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
- Added a better explanation of the change.

ChangeLog v5:
- New patch.
---
 arch/arm/boot/dts/imx51-apf51dev.dts|2 +-
 arch/arm/boot/dts/imx53-m53evk.dts  |2 +-
 drivers/staging/imx-drm/imx-ldb.c   |4 ++--
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c |4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/imx51-apf51dev.dts 
b/arch/arm/boot/dts/imx51-apf51dev.dts
index c5a9a24..7b3851d 100644
--- a/arch/arm/boot/dts/imx51-apf51dev.dts
+++ b/arch/arm/boot/dts/imx51-apf51dev.dts
@@ -18,7 +18,7 @@

display at di1 {
compatible = "fsl,imx-parallel-display";
-   interface-pix-fmt = "bgr666";
+   interface-pix-fmt = "rgb666";
pinctrl-names = "default";
pinctrl-0 = <_ipu_disp1>;

diff --git a/arch/arm/boot/dts/imx53-m53evk.dts 
b/arch/arm/boot/dts/imx53-m53evk.dts
index d5d146a..4b036b4 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -24,7 +24,7 @@
soc {
display1: display at di1 {
compatible = "fsl,imx-parallel-display";
-   interface-pix-fmt = "bgr666";
+   interface-pix-fmt = "rgb666";
pinctrl-names = "default";
pinctrl-0 = <_ipu_disp1>;

diff --git a/drivers/staging/imx-drm/imx-ldb.c 
b/drivers/staging/imx-drm/imx-ldb.c
index 7e3f019..5d22e40 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -188,11 +188,11 @@ static void imx_ldb_encoder_prepare(struct drm_encoder 
*encoder)
switch (imx_ldb_ch->chno) {
case 0:
pixel_fmt = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH0_24) ?
-   V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+   V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_RGB666;
break;
case 1:
pixel_fmt = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH1_24) ?
-   V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+   V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_RGB666;
break;
default:
dev_err(ldb->dev, "unable to config di%d panel format\n",
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 9d0324d..cd250d5 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -440,9 +440,9 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,

/* bgr666 */
ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
-   ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
+   ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
-   ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+   ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */

/* lvds666 */
ipu_dc_map_clear(priv, IPU_DC_MAP_LVDS666);
-- 
1.7.9.5

[PATCH v13 02/10] imx-drm: Add RGB666 support for parallel display.

[Denis Carikli]

Signed-off-by: Denis Carikli 
Acked-by: Philipp Zabel 
---
ChangeLog v9->v13:
- Rebased
ChangeLog v8->v9:
- Rebased.
- Added Philipp Zabel's ack.
- Shortened the patch title.

ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- Rebased.

ChangeLog v7->v8:
- Shrinked even more the Cc list.

ChangeLog v6->v7:
- Shrinked even more the Cc list.

ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.

ChangeLog v3->v5:
- Use the correct RGB order.

ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Removed the commit message long desciption that was just a copy of the short
  description.
- Rebased the patch.
- Fixed a copy-paste error in the ipu_dc_map_clear parameter.
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |4 ++--
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c|9 +
 drivers/staging/imx-drm/parallel-display.c |2 ++
 3 files changed, 13 insertions(+), 2 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 e75f0e5..c0eb95a 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -60,8 +60,8 @@ Required properties:
 - compatible: Should be "fsl,imx-parallel-display"
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
-  and "lvds666".
+  display interface. Currently supported types: "rgb24", "rgb565", "bgr666",
+  "rgb666" and "lvds666".
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 784a4a1..9d0324d 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -94,6 +94,7 @@ enum ipu_dc_map {
IPU_DC_MAP_BGR666,
IPU_DC_MAP_LVDS666,
IPU_DC_MAP_BGR24,
+   IPU_DC_MAP_RGB666,
 };

 struct ipu_dc {
@@ -162,6 +163,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_LVDS666;
case V4L2_PIX_FMT_BGR24:
return IPU_DC_MAP_BGR24;
+   case V4L2_PIX_FMT_RGB666:
+   return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -453,6 +456,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */

+   /* rgb666 */
+   ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+
return 0;
 }

diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index b567832..64b34336 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -218,6 +218,8 @@ static int imx_pd_bind(struct device *dev, struct device 
*master, void *data)
imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, "bgr666"))
imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+   else if (!strcmp(fmt, "rgb666"))
+   imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB666;
else if (!strcmp(fmt, "lvds666"))
imxpd->interface_pix_fmt = v4l2_fourcc('L', 'V', 'D', 
'6');
}
-- 
1.7.9.5

[PATCH v13 01/10] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

[Denis Carikli]

That new macro is needed by the imx_drm staging driver
  for supporting the QVGA display of the eukrea-cpuimx51 board.

Signed-off-by: Denis Carikli 
Acked-by: Mauro Carvalho Chehab 
Acked-by: Laurent Pinchart 
Acked-by: Philipp Zabel 
---
ChangeLog v10->v13:
- No changes
ChangeLog v9->v10:
- Rebased on top of:
  "211e7f2 [media] DocBook media: drop the old incorrect packed RGB table"
- Added Philipp Zabel's Ack.

ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.

ChangeLog v7->v8:
- Added Mauro Carvalho Chehab back to the list of Cc

ChangeLog v6->v7:
- Shrinked even more the Cc list.
ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.

ChangeLog v3->v4:
- Added Laurent Pinchart's Ack.

ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Added Mauro Carvalho Chehab's Ack.
- Added documentation.
---
 .../DocBook/media/v4l/pixfmt-packed-rgb.xml|   39 
 include/uapi/linux/videodev2.h |1 +
 2 files changed, 40 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml 
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index e1c4f8b..88a7fe1 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -279,6 +279,45 @@ colorspace 
V4L2_COLORSPACE_SRGB.


  
+ 
+   V4L2_PIX_FMT_RGB666
+   'RGBH'
+   
+   r5
+   r4
+   r3
+   r2
+   r1
+   r0
+   g5
+   g4
+   
+   g3
+   g2
+   g1
+   g0
+   b5
+   b4
+   b3
+   b2
+   
+   b1
+   b0
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+ 
  
V4L2_PIX_FMT_BGR24
'BGR3'
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 168ff50..08cac01 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -299,6 +299,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16  RGB-5-5-5 
BE  */
 #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16  RGB-5-6-5 
BE  */
 #define V4L2_PIX_FMT_BGR666  v4l2_fourcc('B', 'G', 'R', 'H') /* 18  BGR-6-6-6  
  */
+#define V4L2_PIX_FMT_RGB666  v4l2_fourcc('R', 'G', 'B', 'H') /* 18  RGB-6-6-6  
  */
 #define V4L2_PIX_FMT_BGR24   v4l2_fourcc('B', 'G', 'R', '3') /* 24  BGR-8-8-8  
   */
 #define V4L2_PIX_FMT_RGB24   v4l2_fourcc('R', 'G', 'B', '3') /* 24  RGB-8-8-8  
   */
 #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R', '4') /* 32  
BGR-8-8-8-8   */
-- 
1.7.9.5

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Tim Harvey]

On Mon, Jun 9, 2014 at 7:29 AM, Fabio Estevam  wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
>  wrote:
>
>> Please check the status in /sys/class/drm/card0-HDMI-A-1/status.  This
>> should report the current state of the hotplug detection.
>
> /sys/class/drm/card0-HDMI-A-1/status returns the correct state for
> HDMI cable connection.
>
>> Remember that this code detects off the HPD signal - if the HPD signal
>> has not been correctly wired up, this patch is not going to help (really
>> it comes down to a hardware fault, which I'm not trying to solve with
>> this patch.)
>>
>> What I'm trying to resolve with this patch is that the state detected
>> on properly wired up systems corresponds with the real initial state of
>> the interface at initialisation time.
>>
>> The problem with the current code is that we start off assuming that the
>> interface is disconnected, and we rely on an interrupt arriving to change
>> that state.  If for whatever reason that interrupt does not arrive, then,
>> even if the HPD signal is active, we continue believing that the interface
>> is not connected.
>>
>> I seem to remember discussion in the past that the HPD signal is not
>> wired up on SabreSD.  Really, this needs to be a DT flag to indicate
>
> It is sabrelite board that does not have HPD signal not wired up.
>
> sabresd does have HPD signal connected.
>
> The HDMI undetected issue I am seeing on sabresd seems to be related
> to the simultaneous usage of HDMI and LVDS.
>
> If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI
> cable is correctly detected and HDMI is shown right after boot.

Fabio,

I'm following along with this thread as I see the same thing you do on
our Ventana boards that support both LVDS and HDMI: without
hot-plugging the HDMI connector I get not HDMI out simply by having
the LVDS node populated.

I am curious however how you are getting simultaneous display on both
LVDS and HDMI on a SabreSD board as the standard resistor loading
would make the EDID's of both conflict (which causes EDID read
failures) - perhaps you are using an LVDS display with no EDID or
perhaps you have modified the resistor loading on a SabreSD to move
them to different i2cs? Or is there some kernel param/config I don't
see to tell the imx_hdmi driver to ignore EDID and force in a mode?

Regards,

Tim

[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

[Jesse Barnes]

On Tue, 10 Jun 2014 11:01:06 -0700
St?phane Marchesin  wrote:

> On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes  
> wrote:
> > On Tue, 10 Jun 2014 16:07:44 +0200
> > Daniel Vetter  wrote:
> >
> >> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> >> > Let them eat mincemeat pie.
> >> >
> >> > Signed-off-by: Jesse Barnes 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_params.c | 4 ++--
> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> >> > b/drivers/gpu/drm/i915/i915_params.c
> >> > index d05a2af..081ab2f 100644
> >> > --- a/drivers/gpu/drm/i915/i915_params.c
> >> > +++ b/drivers/gpu/drm/i915/i915_params.c
> >> > @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
> >> > .preliminary_hw_support = 
> >> > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> >> > .disable_power_well = 1,
> >> > .enable_ips = 1,
> >> > -   .fastboot = 0,
> >> > +   .fastboot = 42,
> >> > .prefault_disable = 0,
> >> > .reset = true,
> >> > .invert_brightness = 0,
> >> > @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, "Enable IPS (default: 
> >> > true)");
> >> >
> >> >  module_param_named(fastboot, i915.fastboot, bool, 0600);
> >> >  MODULE_PARM_DESC(fastboot,
> >> > -   "Try to skip unnecessary mode sets at boot time (default: false)");
> >> > +   "Try to skip unnecessary mode sets at boot time (default: true)");
> >>
> >> Nah, that wasn't the intention of this option. It was meant as a hack to
> >> experiment around with fastboot and get things going, but imo we need to
> >> really do the full modeset and short-circuit if the state matches.
> >>
> >> And there's still a bunch of things we don't track like infoframes which
> >> we either need to fix up (similar to the pfit fixup) or quirk to disallow
> >> fastboot.
> >
> > Hm that contradicts our earlier discussions w/Damien when we decided
> > the infoframes stuff were too esoteric to matter...
> 
> My 2 cents is that I've seen some really bad TVs which didn't work
> because infoframes were missing (IIRC it relied on the VIC to detect
> the video mode).

Yeah so we'd still leave them in place in this case, and apply them on
the next mode set as well, but we wouldn't be explicitly cross checking
for them, at least not yet.

It's a good thing to add, I just didn't think it was a blocker based on
our last discussion about this.

-- 
Jesse Barnes, Intel Open Source Technology Center

[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

[Stéphane Marchesin]

On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes  
wrote:
> On Tue, 10 Jun 2014 16:07:44 +0200
> Daniel Vetter  wrote:
>
>> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
>> > Let them eat mincemeat pie.
>> >
>> > Signed-off-by: Jesse Barnes 
>> > ---
>> >  drivers/gpu/drm/i915/i915_params.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
>> > b/drivers/gpu/drm/i915/i915_params.c
>> > index d05a2af..081ab2f 100644
>> > --- a/drivers/gpu/drm/i915/i915_params.c
>> > +++ b/drivers/gpu/drm/i915/i915_params.c
>> > @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
>> > .preliminary_hw_support = 
>> > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
>> > .disable_power_well = 1,
>> > .enable_ips = 1,
>> > -   .fastboot = 0,
>> > +   .fastboot = 42,
>> > .prefault_disable = 0,
>> > .reset = true,
>> > .invert_brightness = 0,
>> > @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, "Enable IPS (default: 
>> > true)");
>> >
>> >  module_param_named(fastboot, i915.fastboot, bool, 0600);
>> >  MODULE_PARM_DESC(fastboot,
>> > -   "Try to skip unnecessary mode sets at boot time (default: false)");
>> > +   "Try to skip unnecessary mode sets at boot time (default: true)");
>>
>> Nah, that wasn't the intention of this option. It was meant as a hack to
>> experiment around with fastboot and get things going, but imo we need to
>> really do the full modeset and short-circuit if the state matches.
>>
>> And there's still a bunch of things we don't track like infoframes which
>> we either need to fix up (similar to the pfit fixup) or quirk to disallow
>> fastboot.
>
> Hm that contradicts our earlier discussions w/Damien when we decided
> the infoframes stuff were too esoteric to matter...

My 2 cents is that I've seen some really bad TVs which didn't work
because infoframes were missing (IIRC it relied on the VIC to detect
the video mode).

St?phane

[PATCH 2/2] drm/radeon: Bypass hw lut's for > 8 bpc framebuffer scanout.

[Alex Deucher]

From: Mario Kleiner 

The hardware lut's only have 256 slots for indexing by a
8 bpc framebuffer. In 10 bpc scanout modes, framebuffer
color values would get truncated to their 8 msb's,
thereby losing the extra precision afforded by a 10 bpc
framebuffer.

To retain full precision, bypass the hw lut in 10 bpc
scanout mode.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 27 +++
 drivers/gpu/drm/radeon/evergreen_reg.h  |  2 ++
 drivers/gpu/drm/radeon/r500_reg.h   |  1 +
 drivers/gpu/drm/radeon/radeon_display.c |  3 ++-
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b91f79e..9758f91 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1136,6 +1136,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
u32 fb_swap = EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_NONE);
u32 tmp, viewport_w, viewport_h;
int r;
+   bool bypass_lut = false;

/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -1225,6 +1226,8 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
 #ifdef __BIG_ENDIAN
fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN32);
 #endif
+   /* Greater 8 bpc fb needs to bypass hw-lut to retain precision 
*/
+   bypass_lut = true;
break;
case DRM_FORMAT_BGRX1010102:
case DRM_FORMAT_BGRA1010102:
@@ -1233,6 +1236,8 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
 #ifdef __BIG_ENDIAN
fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN32);
 #endif
+   /* Greater 8 bpc fb needs to bypass hw-lut to retain precision 
*/
+   bypass_lut = true;
break;
default:
DRM_ERROR("Unsupported screen format %s\n",
@@ -1365,6 +1370,18 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
WREG32(EVERGREEN_GRPH_CONTROL + radeon_crtc->crtc_offset, fb_format);
WREG32(EVERGREEN_GRPH_SWAP_CONTROL + radeon_crtc->crtc_offset, fb_swap);

+   /*
+* The LUT only has 256 slots for indexing by a 8 bpc fb. Bypass the LUT
+* for > 8 bpc scanout to avoid truncation of fb indices to 8 msb's, to
+* retain the full precision throughout the pipeline.
+*/
+   WREG32_P(EVERGREEN_GRPH_LUT_10BIT_BYPASS_CONTROL + 
radeon_crtc->crtc_offset,
+(bypass_lut ? EVERGREEN_LUT_10BIT_BYPASS_EN : 0),
+~EVERGREEN_LUT_10BIT_BYPASS_EN);
+
+   if (bypass_lut)
+   DRM_DEBUG_KMS("Bypassing hardware LUT due to 10 bit fb 
scanout.\n");
+
WREG32(EVERGREEN_GRPH_SURFACE_OFFSET_X + radeon_crtc->crtc_offset, 0);
WREG32(EVERGREEN_GRPH_SURFACE_OFFSET_Y + radeon_crtc->crtc_offset, 0);
WREG32(EVERGREEN_GRPH_X_START + radeon_crtc->crtc_offset, 0);
@@ -1432,6 +1449,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
u32 fb_swap = R600_D1GRPH_SWAP_ENDIAN_NONE;
u32 tmp, viewport_w, viewport_h;
int r;
+   bool bypass_lut = false;

/* no fb bound */
if (!atomic && !crtc->primary->fb) {
@@ -1517,6 +1535,8 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
 #ifdef __BIG_ENDIAN
fb_swap = R600_D1GRPH_SWAP_ENDIAN_32BIT;
 #endif
+   /* Greater 8 bpc fb needs to bypass hw-lut to retain precision 
*/
+   bypass_lut = true;
break;
default:
DRM_ERROR("Unsupported screen format %s\n",
@@ -1559,6 +1579,13 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
if (rdev->family >= CHIP_R600)
WREG32(R600_D1GRPH_SWAP_CONTROL + radeon_crtc->crtc_offset, 
fb_swap);

+   /* LUT only has 256 slots for 8 bpc fb. Bypass for > 8 bpc scanout for 
precision */
+   WREG32_P(AVIVO_D1GRPH_LUT_SEL + radeon_crtc->crtc_offset,
+(bypass_lut ? AVIVO_LUT_10BIT_BYPASS_EN : 0), 
~AVIVO_LUT_10BIT_BYPASS_EN);
+
+   if (bypass_lut)
+   DRM_DEBUG_KMS("Bypassing hardware LUT due to 10 bit fb 
scanout.\n");
+
WREG32(AVIVO_D1GRPH_SURFACE_OFFSET_X + radeon_crtc->crtc_offset, 0);
WREG32(AVIVO_D1GRPH_SURFACE_OFFSET_Y + radeon_crtc->crtc_offset, 0);
WREG32(AVIVO_D1GRPH_X_START + radeon_crtc->crtc_offset, 0);
diff --git a/drivers/gpu/drm/radeon/evergreen_reg.h 
b/drivers/gpu/drm/radeon/evergreen_reg.h
index a0f63ff..333d143 100644
--- a/drivers/gpu/drm/radeon/evergreen_reg.h
+++ b/drivers/gpu/drm/radeon/evergreen_reg.h
@@ -116,6 +116,8 @@
 #   define EVERGREEN_GRPH_ARRAY_LINEAR_ALIGNED  1
 #   define EVERGREEN_GRPH_ARRAY_1D_TILED_THIN1  2
 #   define EVERGREEN_GRPH_ARRAY_2D_TILED_THIN1  4
+#define EVERGREEN_GRPH_LUT_10BIT_BYPASS_CONTROL  

[PATCH 1/2] drm/radeon: use pixel formats instead of depth/bpp

[Alex Deucher]

From: Fredrik H?glund 

This disambiguates depth 16 formats, such as ARGB1555 and ARGB,
and depth 32 formats such as ARGB2101010 and ARGB.

This patch also adds support for depth 30 (XRGB2101010) framebuffers.

Signed-off-by: Fredrik H?glund 
Reviewed-by: Mario Kleiner 
Tested-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c | 89 --
 1 file changed, 73 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 26c12a3..b91f79e 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1174,33 +1174,69 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
radeon_bo_get_tiling_flags(rbo, _flags, NULL);
radeon_bo_unreserve(rbo);

-   switch (target_fb->bits_per_pixel) {
-   case 8:
+   switch (target_fb->pixel_format) {
+   case DRM_FORMAT_C8:
fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_8BPP) |
 
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_INDEXED));
break;
-   case 15:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_16BPP) |
+
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_ARGB));
+#ifdef __BIG_ENDIAN
+   fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN16);
+#endif
+   break;
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_ARGB1555:
fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_16BPP) |
 
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_ARGB1555));
+#ifdef __BIG_ENDIAN
+   fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN16);
+#endif
break;
-   case 16:
+   case DRM_FORMAT_BGRX5551:
+   case DRM_FORMAT_BGRA5551:
+   fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_16BPP) |
+
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_BGRA5551));
+#ifdef __BIG_ENDIAN
+   fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN16);
+#endif
+   break;
+   case DRM_FORMAT_RGB565:
fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_16BPP) |
 
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_ARGB565));
 #ifdef __BIG_ENDIAN
fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN16);
 #endif
break;
-   case 24:
-   case 32:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_32BPP) |
 
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_ARGB));
 #ifdef __BIG_ENDIAN
fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN32);
 #endif
break;
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_ARGB2101010:
+   fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_32BPP) |
+
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_ARGB2101010));
+#ifdef __BIG_ENDIAN
+   fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN32);
+#endif
+   break;
+   case DRM_FORMAT_BGRX1010102:
+   case DRM_FORMAT_BGRA1010102:
+   fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_32BPP) |
+
EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_BGRA1010102));
+#ifdef __BIG_ENDIAN
+   fb_swap = 
EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN32);
+#endif
+   break;
default:
-   DRM_ERROR("Unsupported screen depth %d\n",
- target_fb->bits_per_pixel);
+   DRM_ERROR("Unsupported screen format %s\n",
+ drm_get_format_name(target_fb->pixel_format));
return -EINVAL;
}

@@ -1433,18 +1469,30 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
radeon_bo_get_tiling_flags(rbo, _flags, NULL);
radeon_bo_unreserve(rbo);

-   switch (target_fb->bits_per_pixel) {
-   case 8:
+   switch (target_fb->pixel_format) {
+   case DRM_FORMAT_C8:
fb_format =
AVIVO_D1GRPH_CONTROL_DEPTH_8BPP |
AVIVO_D1GRPH_CONTROL_8BPP_INDEXED;
break;
-   case 15:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   fb_format =
+   AVIVO_D1GRPH_CONTROL_DEPTH_16BPP |
+   AVIVO_D1GRPH_CONTROL_16BPP_ARGB;
+#ifdef __BIG_ENDIAN
+   fb_swap = R600_D1GRPH_SWAP_ENDIAN_16BIT;
+#endif
+   break;
+   case DRM_FORMAT_XRGB1555:
fb_format =
 

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Tue, Jun 10, 2014 at 9:58 AM, Fabio Estevam  wrote:
> On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
>  wrote:
>
>> Right, so the problem isn't at the HDMI level, but at the DI level... so
>> that's where we need to debug what's being setup.  I left some debugging
>> in ipu-di.c - could you try enabling that please?
>
> Booting the kernel with the HDMI cable connected (no image is seen on
> HDMI, only on LVDS):

In case it helps, I am also able to reproduce the problem on a
imx6dl-hummingboard using the attached debug patch.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-hummingboardlvds.patch
Type: text/x-patch
Size: 1229 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/3be844f8/attachment.bin>

[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

[Jesse Barnes]

On Tue, 10 Jun 2014 16:07:44 +0200
Daniel Vetter  wrote:

> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> > Let them eat mincemeat pie.
> > 
> > Signed-off-by: Jesse Barnes 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > b/drivers/gpu/drm/i915/i915_params.c
> > index d05a2af..081ab2f 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
> > .preliminary_hw_support = 
> > IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> > .disable_power_well = 1,
> > .enable_ips = 1,
> > -   .fastboot = 0,
> > +   .fastboot = 42,
> > .prefault_disable = 0,
> > .reset = true,
> > .invert_brightness = 0,
> > @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, "Enable IPS (default: 
> > true)");
> >  
> >  module_param_named(fastboot, i915.fastboot, bool, 0600);
> >  MODULE_PARM_DESC(fastboot,
> > -   "Try to skip unnecessary mode sets at boot time (default: false)");
> > +   "Try to skip unnecessary mode sets at boot time (default: true)");
> 
> Nah, that wasn't the intention of this option. It was meant as a hack to
> experiment around with fastboot and get things going, but imo we need to
> really do the full modeset and short-circuit if the state matches.
> 
> And there's still a bunch of things we don't track like infoframes which
> we either need to fix up (similar to the pfit fixup) or quirk to disallow
> fastboot.

Hm that contradicts our earlier discussions w/Damien when we decided
the infoframes stuff were too esoteric to matter...

Also do you want the mod_parm_desc updated to be more accurate?  Not
sure what the request is here.

-- 
Jesse Barnes, Intel Open Source Technology Center

[Intel-gfx] [PATCH 4/5] drm/i915: use current mode if the size matches the preferred mode

[Jesse Barnes]

On Tue, 10 Jun 2014 16:05:36 +0200
Daniel Vetter  wrote:

> On Thu, Jun 05, 2014 at 11:24:30AM -0700, Jesse Barnes wrote:
> > From: Kristian H?gsberg 
> > 
> > The BIOS may set a native mode that doesn't quite match the preferred
> > mode timings.  It should be ok to use however if it uses the same size,
> > so try to avoid a mode set in that case.
> > 
> > Signed-off-by: Kristian H?gsberg 
> > Signed-off-by: Jesse Barnes 
> 
> Not sure we want this since this seems to override the cmdline options to
> force a specific edid. Also not sure whether we shouldn't just add this as
> the preferred mode when probing (before the preferred mode the vbt/edid
> provides ofc).
> 
> What exactly is the mismatch here? It could be DRRS or something fancy,
> too.
> 
> Not sure what to do here really.

AFAICT it's just slightly different timings for fun.  I don't think
they go low enough to reduce the DP lane count... maybe there's just a
mismatch between their hard coded panel timings and the ones reported
by the EDID.  Not sure which to trust...  Kristian can you post the
timings you see here?  Both the BIOS timings and the EDID ones?

So I'm stuck here too, I think it's a rare case though.

-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3

[Jesse Barnes]

On Tue, 10 Jun 2014 16:02:51 +0200
Daniel Vetter  wrote:

> On Thu, Jun 05, 2014 at 11:24:28AM -0700, Jesse Barnes wrote:
> > Some machines (like MBAs) might use a tiled framebuffer but not enable
> > display swizzling at boot time.  We want to preserve that configuration
> > if possible to prevent a boot time mode set.  On IVB+ it shouldn't
> > affect performance anyway since the memory controller does internal
> > swizzling anyway.
> > 
> > For most other configs we'll be able to enable swizzling at boot time,
> > since the initial framebuffer won't be tiled, thus we won't see any
> > corruption when we enable it.
> > 
> > v2: preserve swizzling if BIOS had it set (Daniel)
> > v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel)
> > check display swizzle setting in detect_bit_6_swizzle (Daniel)
> > use gen6 as cutoff point (Daniel)
> > 
> > Reported-by: Kristian H?gsberg 
> > Signed-off-by: Jesse Barnes 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  1 +
> >  drivers/gpu/drm/i915/i915_gem.c|  3 +++
> >  drivers/gpu/drm/i915/i915_gem_tiling.c | 38 
> > +++---
> >  drivers/gpu/drm/i915/intel_display.c   |  3 +++
> >  4 files changed, 28 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index f57b752..f49fdcb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1405,6 +1405,7 @@ struct drm_i915_private {
> > struct intel_vbt_data vbt;
> >  
> > bool bios_ssc; /* BIOS had SSC enabled at boot? */
> > +   bool preserve_bios_swizzle;
> >  
> > /* overlay */
> > struct intel_overlay *overlay;
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index bfc7af0..0b168fb 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4580,6 +4580,9 @@ void i915_gem_init_swizzling(struct drm_device *dev)
> > dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
> > return;
> >  
> > +   if (INTEL_INFO(dev)->gen >= 6 && dev_priv->preserve_bios_swizzle)
> > +   return;
> > +
> 
> Above two hunks shouldnt be needed if the setup in
> i915_gem_detect_bit_6_swizzle works correctly.
> 
> > I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
> >  DISP_TILE_SURFACE_SWIZZLING);
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
> > b/drivers/gpu/drm/i915/i915_gem_tiling.c
> > index cb150e8..73005ad 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
> > @@ -91,26 +91,30 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
> > uint32_t swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
> > uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
> >  
> > -   if (IS_VALLEYVIEW(dev)) {
> > -   swizzle_x = I915_BIT_6_SWIZZLE_NONE;
> > -   swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> > -   } else if (INTEL_INFO(dev)->gen >= 6) {
> > +   if (INTEL_INFO(dev)->gen >= 6) {
> > uint32_t dimm_c0, dimm_c1;
> > -   dimm_c0 = I915_READ(MAD_DIMM_C0);
> > -   dimm_c1 = I915_READ(MAD_DIMM_C1);
> > -   dimm_c0 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
> > -   dimm_c1 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
> > -   /* Enable swizzling when the channels are populated with
> > -* identically sized dimms. We don't need to check the 3rd
> > -* channel because no cpu with gpu attached ships in that
> > -* configuration. Also, swizzling only makes sense for 2
> > -* channels anyway. */
> > -   if (dimm_c0 == dimm_c1) {
> > -   swizzle_x = I915_BIT_6_SWIZZLE_9_10;
> > -   swizzle_y = I915_BIT_6_SWIZZLE_9;
> > -   } else {
> > +
> > +   /* Make sure to honor boot time display configuration */
> > +   if (!(I915_READ(DISP_ARB_CTL) & DISP_TILE_SURFACE_SWIZZLING)) {
> 
> Not quite what I had in mind. Imo we need to check for whether any
> inherited fbs are tiled and if so also inherit the swizzle setting
> unconditionally, whether it is swizzled or unswizzled. See
> 
> http://patchwork.freedesktop.org/patch/22204/

Yes, that's what I do below... I even added it to the changelog:
http://patchwork.freedesktop.org/patch/27223/

Did you miss the later hunk in intel_display.c?

What we try to do here is enable swizzling if possible, which we can do
if no inherited fbs are tiled.

So I think I've done exactly what you repeated above, and documented
it.  So you're going to need to repeat it with different words so I can
understand, if I'm still missing something.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH] drm/radeon: Move fb update from radeon_flip_work_func to radeon_crtc_page_flip

[Michel Dänzer]

From: Michel D?nzer 

Fixes WARN()s from the DRM core since the page flip rework.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77521
Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_display.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index a4e725c..5ed6170 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -462,9 +462,6 @@ static void radeon_flip_work_func(struct work_struct 
*__work)
/* We borrow the event spin lock for protecting flip_work */
spin_lock_irqsave(>dev->event_lock, flags);

-   /* update crtc fb */
-   crtc->primary->fb = fb;
-
/* set the proper interrupt */
radeon_irq_kms_pflip_irq_get(rdev, radeon_crtc->crtc_id);

@@ -539,6 +536,9 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
}
radeon_crtc->flip_work = work;

+   /* update crtc fb */
+   crtc->primary->fb = fb;
+
spin_unlock_irqrestore(>dev->event_lock, flags);

queue_work(radeon_crtc->flip_queue, >flip_work);
-- 
2.0.0

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Fabio Estevam]

On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
 wrote:

> Right, so the problem isn't at the HDMI level, but at the DI level... so
> that's where we need to debug what's being setup.  I left some debugging
> in ipu-di.c - could you try enabling that please?

Booting the kernel with the HDMI cable connected (no image is seen on
HDMI, only on LVDS):

imx-ipuv3 240.ipu: DI0 base: 0x0264 remapped to c08f6000
imx-ipuv3 240.ipu: DI1 base: 0x02648000 remapped to c08fe000
imx-ipuv3 240.ipu: IPUv3H probed
imx-ipuv3 280.ipu: DI0 base: 0x02a4 remapped to c09b6000
imx-ipuv3 280.ipu: DI1 base: 0x02a48000 remapped to c09be000
imx-ipuv3 280.ipu: IPUv3H probed
mmcblk0: mmc1:0007 SD4GB 3.70 GiB
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops)
imx-hdmi 12.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)
imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
 mmcblk0: unknown partition table
imx-ipuv3 240.ipu: disp 0: panel size = 1920 x 1080
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 2400Hz Needed 13850Hz
imx-ipuv3 240.ipu:   IPU clock can give 13200 with divider 2,
error -4.3%
imx-ipuv3 240.ipu: Want 13850Hz IPU 26400Hz DI 13850Hz
using DI, 13850Hz
imx-ipuv3 240.ipu: disp 1: panel size = 1024 x 768
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
imx-ipuv3 240.ipu: Want 6500Hz IPU 26400Hz DI 6499Hz
using DI, 6499Hz

After cable removal:
root at freescale /$ imx-ipuv3 240.ipu: disp 0: panel size = 1024 x 768
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
imx-ipuv3 240.ipu: Want 6500Hz IPU 26400Hz DI 6499Hz
using DI, 6499Hz

After cable re-insertion (image is seen on both HDMI and LVDS):

imx-ipuv3 240.ipu: disp 0: panel size = 1920 x 1080
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 6499Hz Needed 13850Hz
imx-ipuv3 240.ipu:   IPU clock can give 13200 with divider 2,
error -4.3%
imx-ipuv3 240.ipu: Want 13850Hz IPU 26400Hz DI 12997Hz
using DI, 12997Hz
imx-ipuv3 240.ipu: disp 1: panel size = 1024 x 768
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
imx-ipuv3 240.ipu: Want 6500Hz IPU 26400Hz DI 6499Hz
using DI, 6499Hz

[Intel-gfx] [PATCH 3/3] drm/i915: Fix the confusing comment about the ioctl limits

[Daniel Vetter]

On Mon, Jun 09, 2014 at 02:39:51PM +0100, Damien Lespiau wrote:
> It was reported that this comment was confusing, and indeed it is.
> 
> Signed-off-by: Damien Lespiau 
> ---
>  include/uapi/drm/i915_drm.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index ff57f07..eacd063 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -171,8 +171,12 @@ typedef struct _drm_i915_sarea {
>  #define I915_BOX_TEXTURE_LOAD  0x8
>  #define I915_BOX_LOST_CONTEXT  0x10
>  
> -/* I915 specific ioctls
> - * The device specific ioctl range is 0x40 to 0x79.
> +/*
> + * i915 specific ioctls.
> + *
> + * The device specific ioctl range is [DRM_COMMAND_BASE, DRM_COMMAND_END) ie
> + * [0x40, 0xa0) (a0 is excluded) and those defines are offsets from
> + * DRM_COMMAND_BASE.

Maybe do the math for us and say what's the largest relative ioctl number
for i915?
-Daniel

>   */
>  #define DRM_I915_INIT0x00
>  #define DRM_I915_FLUSH   0x01
> -- 
> 1.8.3.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

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

https://bugzilla.kernel.org/show_bug.cgi?id=76761

--- Comment #17 from swoorupj at gmail.com ---
Sorry I have mislead you. I meant I started using linux since 3.8. And I have
had this problem since. I don't recall it working with KMS.

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

Mismatch in gmch_pfit.lvds_border_bits on EeePC 900

[Daniel Vetter]

On Sun, Jun 08, 2014 at 10:30:15PM +0100, Sitsofe Wheeler wrote:
> With a tree that is close to 3.15 final I'm regularly seeing the
> following on my EeePC 900 when starting ioquake3:
> 
> [drm:intel_pipe_config_compare] *ERROR* mismatch in 
> gmch_pfit.lvds_border_bits (expected 32768, found 0)

Hm, I've thought we've fixed that by now. Alas, no :(

Can you please add drm.debug=0xe to your kernel cmdline, reproduce the
issue and attach the entire dmesg? Please make sure it contains everything
since boot-up so that we can reconstruct the state properly (might need to
grab it from logfiles if dmesg is cut off).

Also, do you have any ideas when you reproduce this? Anything that changes
the lvds output could be relevant ...
-Daniel

> [ cut here ]
> WARNING: CPU: 0 PID: 1594 at drivers/gpu/drm/i915/intel_display.c:9834 
> check_crtc_state+0x998/0x9ef()
> pipe state doesn't match!
> CPU: 0 PID: 1594 Comm: Xorg Not tainted 3.15.0-rc8-00106-ge585b54 #49
> Hardware name: ASUSTeK Computer INC. 900/900, BIOS 100603/03/2009
>  b0485438 b011f61f b057c98a ebb03b04 063a b057b5f4 266a b02c31ef
>  b02c31ef ee42c000 ee488c00  ee488d74 b011f684 0009 ebb03aec
>  b057c98a ebb03b04 b02c31ef b057b5f4 266a b057c98a  ebb03bdc
> Call Trace:
>  [] ? dump_stack+0xa/0x13
>  [] ? warn_slowpath_common+0x70/0x85
>  [] ? check_crtc_state+0x998/0x9ef
>  [] ? check_crtc_state+0x998/0x9ef
>  [] ? warn_slowpath_fmt+0x33/0x37
>  [] ? check_crtc_state+0x998/0x9ef
>  [] ? intel_modeset_check_state+0x353/0x5fb
>  [] ? intel_set_mode+0x2a/0x32
>  [] ? intel_crtc_set_config+0x8c9/0x962
>  [] ? idr_alloc+0xb5/0xc3
>  [] ? drm_mode_set_config_internal+0x39/0x9b
>  [] ? drm_mode_setcrtc+0x397/0x438
>  [] ? drm_crtc_check_viewport+0xef/0xef
>  [] ? drm_ioctl+0x327/0x38f
>  [] ? drm_crtc_check_viewport+0xef/0xef
>  [] ? do_sync_read+0x5a/0x7f
>  [] ? drm_version+0x73/0x73
>  [] ? do_vfs_ioctl+0x350/0x419
>  [] ? recalc_sigpending+0xe/0x36
>  [] ? __set_task_blocked+0x61/0x67
>  [] ? __set_current_blocked+0xd/0xf
>  [] ? sigprocmask+0x77/0x87
>  [] ? SyS_ioctl+0x31/0x54
>  [] ? sysenter_do_call+0x12/0x26
>  [] ? klist_release+0x14/0x87
> ---[ end trace 900fd39ab2e2b03f ]---
> 
> -- 
> Sitsofe | http://sucs.org/~sits/

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

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

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

https://bugzilla.kernel.org/show_bug.cgi?id=76761

--- Comment #16 from Vitaliy Filippov  ---
Since you know everything was ok in 3.8, maybe you'll just also try to bisect?
:)

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

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #2 from Michel D?nzer  ---
Are you sure it's using page flipping? If you write 2 to
/sys/module/drm/parameters/debug, do you get messages like

 [drm:radeon_crtc_page_flip] flip-ioctl() cur_fbo = 880100f89000, cur_bbo =
88000d714800

in dmesg?

-- 
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/20140610/f88e639a/attachment.html>

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

https://bugzilla.kernel.org/show_bug.cgi?id=51381

--- Comment #34 from Teofilis Martisius  ---
Hello,

I have applied patch2 to 3.15-rc8 along with patch1 and delay of 200, ran with
"radeon.runpm=0", tried to turn off and on the dGPU, and the problem is still
there. Dmesg attached.

Sincerely,
Teofilis Martisius

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

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

https://bugzilla.kernel.org/show_bug.cgi?id=51381

--- Comment #33 from Teofilis Martisius  ---
Created attachment 138791
  --> https://bugzilla.kernel.org/attachment.cgi?id=138791=edit
dmesg output for 3.15-rc8, delay of 200, patched with testing patch 2

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

[Bug 79858] Artifacts/Glitches in Blender menu

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

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

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core

--- Comment #3 from Michel D?nzer  ---
I think this is more likely a generic DRI2 issue related to front buffer
rendering than anything driver specific.

-- 
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/20140610/bd7ffb89/attachment-0001.html>

[Bug 79858] Artifacts/Glitches in Blender menu

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

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

--- Comment #2 from smoki  ---

 Cannot reproduce by maximizing this in current Debian Sid: kernel 3.14.5, mesa
10.1.4, blender 2.70, openbox, Radeon 8400 / r3.

 But of course i can see those artifacts when resizing, but it got refreshed
here does not stay :). 

 Area with those artifacts are black with LIBGL_ALWAYS_SOFTWARE=1 blender

-- 
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/20140610/3d84bb87/attachment.html>

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

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

https://bugzilla.kernel.org/show_bug.cgi?id=76761

--- Comment #15 from swoorupj at gmail.com ---
Is there a way or patch, I could get all the state of the card and test how
they differ before and after suspending?

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

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

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

https://bugzilla.kernel.org/show_bug.cgi?id=76761

--- Comment #14 from swoorupj at gmail.com ---
(In reply to Alex Deucher from comment #13)
> (In reply to swoorupj from comment #12)
> > Hi Alex,
> > 
> > I have reported the same issue in bugs.freedesktop. I tried out the 3.15
> > linux kernel in archlinux just today. And this issue is still prevalent to
> > me. 
> 
> Is it the same commit (6c7bccea390853bdec5b76fe31fc50f3b36f75d5) that caused
> the regression for you as well?  If not, you are experienceing a different
> issue.

No, this issue has been occurring since kernel 3.8.

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

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #2 from Alex Deucher  ---
What GPU is this?  How are you playing back the video?  Were you using UVD? 
Please attach your full dmesg output and xorg log.

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

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #1 from nucrap at hotmail.com ---
Damn, forgot to add:
Graphics card: MSI R7 260x

-- 
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/20140610/7a3a764b/attachment.html>

[Bug 79862] New: Driver crash while playing YouTube video (flash)

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

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

  Priority: medium
Bug ID: 79862
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Driver crash while playing YouTube video (flash)
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: nucrap at hotmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 100782
  --> https://bugs.freedesktop.org/attachment.cgi?id=100782=edit
crash log

While watching a YouTube video (flash player) I experienced a driver crash, the
monitor went black but recovered.

I attached the error log of the radeon driver.

-- 
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/20140610/a5a892e2/attachment.html>

[Bug 79858] Artifacts/Glitches in Blender menu

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
  Component|DRM/Radeon  |Drivers/Gallium/radeonsi

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

[Bug 79852] Mesa-10.2.1/src/gallium/state_trackers/vega/api_params.c:60: possible bad if test ?

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

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

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/r300|Mesa core

-- 
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/20140610/45b2f733/attachment.html>

[Bug 79551] DRI_PRIME not working

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

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

--- Comment #9 from Michel D?nzer  ---
(In reply to comment #8)
> others.
> Today I've tested with DRI_PRIME=0. Same lags. It's appear, when xcompmgr
> running.

That's not directly related to this bug report then. If xcompmgr -a doesn't
work better, there are many other compositing managers you can 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/20140610/17d768e0/attachment.html>

[Bug 79858] Artifacts/Glitches in Blender menu

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

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

Ilia Mirkin  changed:

   What|Removed |Added

 Attachment #100776|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: 

[Bug 79858] Artifacts/Glitches in Blender menu

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

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

nucrap at hotmail.com changed:

   What|Removed |Added

 Attachment #100777|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: 

[Bug 79858] Artifacts/Glitches in Blender menu

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

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

--- Comment #1 from nucrap at hotmail.com ---
Created attachment 100777
  --> https://bugs.freedesktop.org/attachment.cgi?id=100777=edit
glitch in blender menu 2

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

[Bug 79858] New: Artifacts/Glitches in Blender menu

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

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

  Priority: medium
Bug ID: 79858
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Artifacts/Glitches in Blender menu
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: nucrap at hotmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 100776
  --> https://bugs.freedesktop.org/attachment.cgi?id=100776=edit
glitch in blender menu

Mostly when maximizing blender (you might need to try a few times) the menu at
the top is full of artifacts and glitches.
It is independent of DE or any compositing effects because I tested this under
compiz and openbox (without compiz) and it always occurs.

I have attached screenshots for better understanding.
I have tested it with both a HD4770 and a R7 260x graphics card (and I think it
also happened on my laptop HD 5xxx).

My bugreport on the blender bugtracker: https://developer.blender.org/T37504

This should be really easy to reproduce. I use Archlinux with the latest
software.

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