[pull] radeon drm-next-3.18

[Alex Deucher]

Hi Dave,

Just clearing out my -next queue before I go on vacation.  Two UVD
improvements that depend on the ttm change you just merged.

The following changes since commit 6adae108b2fb0c7b945e297e4a0f0b7d66599656:

  Merge branch 'drm-next-3.18' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2014-08-28 11:39:11 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-next-3.18

for you to fetch changes up to feba9b0bcf492ba991d7fbfc211dd49ebbc95a4b:

  drm/radeon: preallocate mem for UVD create/destroy msg (2014-08-27 22:46:23 
-0400)


Christian K?nig (2):
  drm/radeon: allow UVD to use a second 256MB segment
  drm/radeon: preallocate mem for UVD create/destroy msg

 drivers/gpu/drm/radeon/radeon.h|   3 +-
 drivers/gpu/drm/radeon/radeon_object.c |   5 +-
 drivers/gpu/drm/radeon/radeon_uvd.c| 119 -
 3 files changed, 48 insertions(+), 79 deletions(-)

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #121 from Andy Furniss  ---
(In reply to comment #119)
> I was browsing while compiling and once again it crashed:
> [57534.191174] Watchdog[29216]: segfault at 0 ip 7f402637ae58 sp
> 7f40131e1810 error 6 in chrome[7f40228fa000+590d000]
> [57544.227442] Watchdog[10690]: segfault at 0 ip 7f1ffab93e58 sp
> 7f1fe79fa810 error 6 in chrome[7f1ff7113000+590d000]
> 
> Does it happen with other browsers than chrome/chromium? Do someone use
> firefox?

I've been stable for some time now using seamonkey, but than I use flashblock
and don't usually use it for vid. Saying that I have deliberately tried and
failed to crash playing vids since this bug started.

I think there's another bug for chromium issues.

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

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||adf.lists at gmail.com

--- Comment #11 from Alex Deucher  ---
*** Bug 83167 has been marked as a duplicate of this 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/20140827/cb8db629/attachment-0001.html>

[Bug 83167] Xorg rendering faliure since u_vbuf: Simplify the format fallback translation

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 83148 ***

-- 
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/20140827/8a179900/attachment.html>

[PATCH] radeon: Test for PCI root bus before assuming bus->self

[Alex Deucher]

On Wed, Aug 27, 2014 at 9:32 PM, Dave Airlie  wrote:
>> On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson
>>  wrote:
>>> If we assign a Radeon device to a virtual machine, we can no longer
>>> assume a fixed hardware topology, like the GPU having a parent device.
>>> This patch simply adds a few pci_is_root_bus() tests to avoid passing
>>> a NULL pointer to PCI access functions, allowing the radeon driver to
>>> work in a QEMU 440FX machine with an assigned HD8570 on the emulated
>>> PCI root bus.
>>>
>>> Signed-off-by: Alex Williamson 
>>
>
> Does this mean inside a VM we can't enable pcie 2 speeds?
>
> This could lead to a quite disappointing speed decrease for DMA transfers.

It depends on the sbios, but most boards negotiate the highest speed at boot.

Alex

[Bug 83167] New: Xorg rendering faliure since u_vbuf: Simplify the format fallback translation

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

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

  Priority: medium
Bug ID: 83167
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Xorg rendering faliure since u_vbuf: Simplify the
format fallback translation
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: adf.lists at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

R9270X kernel drm-fixes-3.17-wip xorg Jun, but ddx/glamor head.

Tentatively, since -

commit bbbe3b65adee44c164532d7afb4ff8fd8f88bbf4
Author: Eric Anholt 
Date:   Fri Aug 22 10:34:55 2014 -0700

u_vbuf: Simplify the format fallback translation.

Individual caps made supporting new fallbacks more complicated than it
needed to be.  Instead, just make a table of fallbacks at context init
time.

v2: Fix inverted "do we need to install vbuf?" flagging caught by Marek.

There is a chance when I startx that rendering will be broken.

Fluxbox menues empty, screen black, can blindly use menu to start an xterm.

xterm OK at first look - maximised OK dmesg worked and showed nothing strange,
but trying to scroll up only updated the top 5 lines scrolling down only bottom
5.

tool bar and menu bar not being cleared, nothing rendered with glxgears.

mplayer video just first frame status line progressing as if normal.

This doesn't always happen, need quit/restart X several times to get bad during
bisect. Goods were tested 20 ish times so there's a small chance I got a false
good.

Xorg log normal.

-- 
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/20140827/fa2b0ed6/attachment.html>

drm_ioctl & WARNING at arch/x86/mm/ioremap.c:98

[Tommi Rantala]

Hello,

Got this warning while fuzzing v3.17-rc2-40-gff0c57a with Trinity. Was
running as root in qemu.

Tommi


ioremap: invalid physical address 40004000
[ cut here ]
WARNING: CPU: 0 PID: 2887 at arch/x86/mm/ioremap.c:98
__ioremap_caller+0x7a/0x2e0()
CPU: 0 PID: 2887 Comm: trinity-c6 Not tainted 3.17.0-rc2+ #29
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0009 880036ee7c90 8238ba09 
 880036ee7cc8 8113c603  40004000
 40008000 81747c7d 0010 880036ee7cd8
Call Trace:
 [] dump_stack+0x4d/0x66
 [] warn_slowpath_common+0x73/0x90
 [] ? drm_addmap_core+0x1dd/0x600
 [] warn_slowpath_null+0x15/0x20
 [] __ioremap_caller+0x7a/0x2e0
 [] ? kmemleak_alloc+0x23/0x50
 [] ? kmem_cache_alloc_trace+0x119/0x290
 [] ? drm_addmap_core+0x3b/0x600
 [] ioremap_nocache+0x12/0x20
 [] drm_addmap_core+0x1dd/0x600
 [] drm_addmap_ioctl+0x45/0x70
 [] drm_ioctl+0x3fe/0x640
 [] ? drm_addmap+0x30/0x30
 [] ? avc_has_perm+0x20/0x2f0
 [] ? sched_clock_cpu+0xa8/0xf0
 [] do_vfs_ioctl+0x4d0/0x510
 [] ? selinux_file_ioctl+0xf5/0x100
 [] SyS_ioctl+0x4e/0x80
 [] system_call_fastpath+0x16/0x1b
---[ end trace c988df0287baa491 ]---

[PATCH V7 09/12] Documentation: drm: bridge: move to video/bridge

[Ajay Kumar]

Move drm/bridge documentation to video/bridge.
Also, add proper documentation for gpios used by ptn3460.

Signed-off-by: Ajay Kumar 
---
 .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 
 .../devicetree/bindings/video/bridge/ptn3460.txt   |   27 
 2 files changed, 27 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
 create mode 100644 Documentation/devicetree/bindings/video/bridge/ptn3460.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt 
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
deleted file mode 100644
index 52b93b2..000
--- a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-ptn3460 bridge bindings
-
-Required properties:
-   - compatible: "nxp,ptn3460"
-   - reg: i2c address of the bridge
-   - powerdown-gpio: OF device-tree gpio specification
-   - reset-gpio: OF device-tree gpio specification
-   - edid-emulation: The EDID emulation entry to use
-   +---++--+
-   | Value | Resolution | Description  |
-   |   0   |  1024x768  | NXP Generic  |
-   |   1   |  1920x1080 | NXP Generic  |
-   |   2   |  1920x1080 | NXP Generic  |
-   |   3   |  1600x900  | Samsung LTM200KT |
-   |   4   |  1920x1080 | Samsung LTM230HT |
-   |   5   |  1366x768  | NXP Generic  |
-   |   6   |  1600x900  | ChiMei M215HGE   |
-   +---++--+
-
-Example:
-   lvds-bridge at 20 {
-   compatible = "nxp,ptn3460";
-   reg = <0x20>;
-   powerdown-gpio = < 5 1 0 0>;
-   reset-gpio = < 5 1 0 0>;
-   edid-emulation = <5>;
-   };
diff --git a/Documentation/devicetree/bindings/video/bridge/ptn3460.txt 
b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
new file mode 100644
index 000..d9281dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460 bridge bindings
+
+Required properties:
+   - compatible: "nxp,ptn3460"
+   - reg: i2c address of the bridge
+   - powerdown-gpios: OF device-tree gpio specification for PD_N pin.
+   - reset-gpios: OF device-tree gpio specification for RST_N pin.
+   - edid-emulation: The EDID emulation entry to use
+   +---++--+
+   | Value | Resolution | Description  |
+   |   0   |  1024x768  | NXP Generic  |
+   |   1   |  1920x1080 | NXP Generic  |
+   |   2   |  1920x1080 | NXP Generic  |
+   |   3   |  1600x900  | Samsung LTM200KT |
+   |   4   |  1920x1080 | Samsung LTM230HT |
+   |   5   |  1366x768  | NXP Generic  |
+   |   6   |  1600x900  | ChiMei M215HGE   |
+   +---++--+
+
+Example:
+   lvds-bridge at 20 {
+   compatible = "nxp,ptn3460";
+   reg = <0x20>;
+   powerdown-gpios = < 5 1 0 0>;
+   reset-gpios = < 5 1 0 0>;
+   edid-emulation = <5>;
+   };
-- 
1.7.9.5

[PATCH V7 10/12] Documentation: devicetree: Add vendor prefix for parade

[Ajay Kumar]

ps8622 eDP-LVDS converter bridge chip is from parade technologies

Signed-off-by: Ajay Kumar 
---
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac7269f..5f28264 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -100,6 +100,7 @@ nxp NXP Semiconductors
 onnn   ON Semiconductor Corp.
 opencores  OpenCores.org
 panasonic  Panasonic Corporation
+parade Parade Technologies Inc.
 phytec PHYTEC Messtechnik GmbH
 picochip   Picochip Ltd
 plathome   Plat'Home Co., Ltd.
-- 
1.7.9.5

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay Kumar]

Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.

Signed-off-by: Ajay Kumar 
---
 .../devicetree/bindings/video/bridge/ps8622.txt|   20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..0ec8172
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,20 @@
+ps8622-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8622" or "parade,ps8625"
+   - reg: first i2c address of the bridge
+   - sleep-gpios: OF device-tree gpio specification for PD_ pin.
+   - reset-gpios: OF device-tree gpio specification for RST_ pin.
+
+Optional properties:
+   - lane-count: number of DP lanes to use
+   - use-external-pwm: backlight will be controlled by an external PWM
+
+Example:
+   lvds-bridge at 48 {
+   compatible = "parade,ps8622";
+   reg = <0x48>;
+   sleep-gpios = < 6 1 0 0>;
+   reset-gpios = < 1 1 0 0>;
+   lane-count = <1>;
+   };
-- 
1.7.9.5

[PATCH] radeon: Test for PCI root bus before assuming bus->self

[Alex Williamson]

On Thu, 2014-08-28 at 11:32 +1000, Dave Airlie wrote:
> > On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson
> >  wrote:
> >> If we assign a Radeon device to a virtual machine, we can no longer
> >> assume a fixed hardware topology, like the GPU having a parent device.
> >> This patch simply adds a few pci_is_root_bus() tests to avoid passing
> >> a NULL pointer to PCI access functions, allowing the radeon driver to
> >> work in a QEMU 440FX machine with an assigned HD8570 on the emulated
> >> PCI root bus.
> >>
> >> Signed-off-by: Alex Williamson 
> >
> 
> Does this mean inside a VM we can't enable pcie 2 speeds?

Shouldn't the device already be set to something reasonable before it's
assigned?

> This could lead to a quite disappointing speed decrease for DMA transfers.

We couldn't do it before anyway, there's no decrease.  Even with a Q35
QEMU chipset the best we were doing was tweaking dummy registers on the
upstream port.  Should VFIO be doing bus tuning prior to exposing the
device?  I suppose our other option would be to let the link control
bits of the emulated downstream port pass through to the host.  In any
case, I don't see that this patch limits performance any more than it
already is for a VM.  Thanks,

Alex

[PATCH V7 12/12] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

[Ajay Kumar]

From: Vincent Palatin 

This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.

Signed-off-by: Vincent Palatin 
Signed-off-by: Andrew Bresticker 
Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/bridge/Kconfig  |   10 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ps8622.c |  681 +++
 3 files changed, 692 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ps8622.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index d35fb68..cd6061f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -8,6 +8,16 @@ config DRM_BRIDGE
 menu "bridge chips"
depends on DRM_BRIDGE

+config DRM_PS8622
+   tristate "Parade eDP/LVDS bridge"
+   depends on OF
+   depends on I2C
+   select DRM_PANEL
+   select BACKLIGHT_LCD_SUPPORT
+   select BACKLIGHT_CLASS_DEVICE
+   help
+ parade eDP-LVDS bridge chip driver.
+
 config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..105da3e 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm

+obj-$(CONFIG_DRM_PS8622) += ps8622.o
 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..bea69d1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,681 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "drmP.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) > \
+   (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error "T2.min + T1.max must be less than T2.max + T1.min"
+#endif
+
+struct ps8622_bridge {
+   struct drm_connector connector;
+   struct i2c_client *client;
+   struct drm_bridge bridge;
+   struct drm_panel *panel;
+   struct regulator *v12;
+   struct backlight_device *bl;
+
+   struct gpio_desc *gpio_slp;
+   struct gpio_desc *gpio_rst;
+
+   u32 max_lane_count;
+   u32 lane_count;
+
+   bool enabled;
+};
+
+static inline struct ps8622_bridge *
+   bridge_to_ps8622(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct ps8622_bridge, bridge);
+}
+
+static inline struct ps8622_bridge *
+   connector_to_ps8622(struct drm_connector *connector)
+{
+   return container_of(connector, struct ps8622_bridge, connector);
+}
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+   int ret;
+   struct i2c_adapter *adap = client->adapter;
+   struct i2c_msg msg;
+   u8 data[] = {reg, val};
+
+   msg.addr = client->addr + page;
+   msg.flags = 0;
+   msg.len = sizeof(data);
+   msg.buf = data;
+
+   ret = i2c_transfer(adap, , 1);
+   if (ret != 1)
+   pr_warn("PS8622 I2C write (0x%02x,0x%02x,0x%02x) failed: %d\n",
+   client->addr + page, reg, val, ret);
+   return !(ret == 1);
+}
+
+static int ps8622_send_config(struct ps8622_bridge *ps8622)
+{
+   struct i2c_client *cl = ps8622->client;
+   int err = 0;
+
+   /* HPD low */
+   err = ps8622_set(cl, 0x02, 0xa1, 0x01);
+   if (err)
+   goto error;
+
+   /* SW setting: [1:0] SW output 1.2V voltage is lower to 96% */
+   err = ps8622_set(cl, 0x04, 0x14, 0x01);
+   if (err)
+   goto error;
+
+   /* RCO SS setting: [5:4] = b01 0.5%, b10 1%, b11 1.5% */
+   err = ps8622_set(cl, 0x04, 0xe3, 0x20);
+   if (err)
+   goto error;
+
+   /* [7] RCO SS enable */
+   

[PATCH V7 08/12] drm/bridge: ptn3460: use gpiod interface

[Ajay Kumar]

Modify driver to support gpiod interface.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/bridge/ptn3460.c |   88 --
 1 file changed, 36 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 1bb4d2b..6f28c13 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -41,8 +41,8 @@ struct ptn3460_bridge {
struct drm_bridge bridge;
struct edid *edid;
struct drm_panel *panel;
-   int gpio_pd_n;
-   int gpio_rst_n;
+   struct gpio_desc *gpio_pd_n;
+   struct gpio_desc *gpio_rst_n;
u32 edid_emulation;
bool enabled;
 };
@@ -131,14 +131,11 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
if (ptn_bridge->enabled)
return;

-   if (gpio_is_valid(ptn_bridge->gpio_pd_n))
-   gpio_set_value(ptn_bridge->gpio_pd_n, 1);
+   gpiod_set_value(ptn_bridge->gpio_pd_n, 1);

-   if (gpio_is_valid(ptn_bridge->gpio_rst_n)) {
-   gpio_set_value(ptn_bridge->gpio_rst_n, 0);
-   usleep_range(10, 20);
-   gpio_set_value(ptn_bridge->gpio_rst_n, 1);
-   }
+   gpiod_set_value(ptn_bridge->gpio_rst_n, 0);
+   usleep_range(10, 20);
+   gpiod_set_value(ptn_bridge->gpio_rst_n, 1);

if (drm_panel_prepare(ptn_bridge->panel)) {
DRM_ERROR("failed to prepare panel\n");
@@ -183,11 +180,8 @@ static void ptn3460_disable(struct drm_bridge *bridge)
return;
}

-   if (gpio_is_valid(ptn_bridge->gpio_rst_n))
-   gpio_set_value(ptn_bridge->gpio_rst_n, 1);
-
-   if (gpio_is_valid(ptn_bridge->gpio_pd_n))
-   gpio_set_value(ptn_bridge->gpio_pd_n, 0);
+   gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
+   gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
 }

 static void ptn3460_post_disable(struct drm_bridge *bridge)
@@ -202,13 +196,7 @@ static void ptn3460_post_disable(struct drm_bridge *bridge)

 static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
 {
-   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
drm_bridge_cleanup(bridge);
-   if (gpio_is_valid(ptn_bridge->gpio_pd_n))
-   gpio_free(ptn_bridge->gpio_pd_n);
-   if (gpio_is_valid(ptn_bridge->gpio_rst_n))
-   gpio_free(ptn_bridge->gpio_rst_n);
/* Nothing else to free, we've got devm allocated memory */
 }

@@ -339,39 +327,41 @@ static int ptn3460_probe(struct i2c_client *client,
}

ptn_bridge->client = client;
-   ptn_bridge->gpio_pd_n = of_get_named_gpio(dev->of_node,
-   "powerdown-gpio", 0);
-   if (gpio_is_valid(ptn_bridge->gpio_pd_n)) {
-   ret = gpio_request_one(ptn_bridge->gpio_pd_n,
-   GPIOF_OUT_INIT_HIGH, "PTN3460_PD_N");
-   if (ret) {
-   dev_err(dev, "Request powerdown-gpio failed (%d)\n",
-   ret);
-   return ret;
-   }
+
+   ptn_bridge->gpio_pd_n = devm_gpiod_get(>dev, "powerdown");
+   if (IS_ERR(ptn_bridge->gpio_pd_n)) {
+   ret = PTR_ERR(ptn_bridge->gpio_pd_n);
+   dev_err(dev, "cannot get gpio_pd_n %d\n", ret);
+   return ret;
}

-   ptn_bridge->gpio_rst_n = of_get_named_gpio(dev->of_node,
-   "reset-gpio", 0);
-   if (gpio_is_valid(ptn_bridge->gpio_rst_n)) {
-   /*
-* Request the reset pin low to avoid the bridge being
-* initialized prematurely
-*/
-   ret = gpio_request_one(ptn_bridge->gpio_rst_n,
-   GPIOF_OUT_INIT_LOW, "PTN3460_RST_N");
-   if (ret) {
-   dev_err(dev, "Request reset-gpio failed (%d)\n", ret);
-   gpio_free(ptn_bridge->gpio_pd_n);
-   return ret;
-   }
+   ret = gpiod_direction_output(ptn_bridge->gpio_pd_n, 1);
+   if (ret) {
+   DRM_ERROR("cannot configure gpio_pd_n\n");
+   return ret;
+   }
+
+   ptn_bridge->gpio_rst_n = devm_gpiod_get(>dev, "reset");
+   if (IS_ERR(ptn_bridge->gpio_rst_n)) {
+   ret = PTR_ERR(ptn_bridge->gpio_rst_n);
+   DRM_ERROR("cannot get gpio_rst_n %d\n", ret);
+   return ret;
+   }
+   /*
+* Request the reset pin low to avoid the bridge being
+* initialized prematurely
+*/
+   ret = gpiod_direction_output(ptn_bridge->gpio_rst_n, 0);
+   if (ret) {
+   DRM_ERROR("cannot configure gpio_rst_n\n");
+   return ret;
}

ret = of_property_read_u32(dev->of_node, "edid-emulation",

[PATCH V7 07/12] drm/bridge: ptn3460: probe connector at the end of bridge attach

[Ajay Kumar]

Force bridge connector detection at the end of the bridge attach.
This is needed to detect the bridge connector early.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/bridge/ptn3460.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 3cb3a7c..1bb4d2b 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -287,6 +287,7 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;

+   ptn_bridge->connector.polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(bridge->drm, _bridge->connector,
_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
if (ret) {
@@ -302,6 +303,8 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
if (ptn_bridge->panel)
drm_panel_attach(ptn_bridge->panel, _bridge->connector);

+   drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
+
return ret;
 }

-- 
1.7.9.5

[PATCH V7 06/12] drm/bridge: ptn3460: support drm_panel

[Ajay Kumar]

Add drm_panel calls to the driver to make the panel and
bridge work together in tandem.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/bridge/Kconfig   |1 +
 drivers/gpu/drm/bridge/ptn3460.c |   37 +
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 7e63a52..d35fb68 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -12,6 +12,7 @@ config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
depends on OF
depends on I2C
+   select DRM_PANEL
help
  ptn3460 eDP-LVDS bridge chip driver.

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 651640a..3cb3a7c 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -20,6 +20,8 @@
 #include 
 #include 

+#include 
+
 #include "bridge/ptn3460.h"

 #include "drm_crtc.h"
@@ -38,6 +40,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_bridge bridge;
struct edid *edid;
+   struct drm_panel *panel;
int gpio_pd_n;
int gpio_rst_n;
u32 edid_emulation;
@@ -137,6 +140,11 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge->gpio_rst_n, 1);
}

+   if (drm_panel_prepare(ptn_bridge->panel)) {
+   DRM_ERROR("failed to prepare panel\n");
+   return;
+   }
+
/*
 * There's a bug in the PTN chip where it falsely asserts hotplug before
 * it is fully functional. We're forced to wait for the maximum start up
@@ -153,6 +161,12 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)

 static void ptn3460_enable(struct drm_bridge *bridge)
 {
+   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+
+   if (drm_panel_enable(ptn_bridge->panel)) {
+   DRM_ERROR("failed to enable panel\n");
+   return;
+   }
 }

 static void ptn3460_disable(struct drm_bridge *bridge)
@@ -164,6 +178,11 @@ static void ptn3460_disable(struct drm_bridge *bridge)

ptn_bridge->enabled = false;

+   if (drm_panel_disable(ptn_bridge->panel)) {
+   DRM_ERROR("failed to disable panel\n");
+   return;
+   }
+
if (gpio_is_valid(ptn_bridge->gpio_rst_n))
gpio_set_value(ptn_bridge->gpio_rst_n, 1);

@@ -173,6 +192,12 @@ static void ptn3460_disable(struct drm_bridge *bridge)

 static void ptn3460_post_disable(struct drm_bridge *bridge)
 {
+   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+
+   if (drm_panel_unprepare(ptn_bridge->panel)) {
+   DRM_ERROR("failed to unprepare panel\n");
+   return;
+   }
 }

 static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
@@ -274,6 +299,9 @@ int ptn3460_bridge_attach(struct drm_bridge *bridge)
drm_mode_connector_attach_encoder(_bridge->connector,
bridge->encoder);

+   if (ptn_bridge->panel)
+   drm_panel_attach(ptn_bridge->panel, _bridge->connector);
+
return ret;
 }

@@ -291,6 +319,7 @@ static int ptn3460_probe(struct i2c_client *client,
 {
struct device *dev = >dev;
struct ptn3460_bridge *ptn_bridge;
+   struct device_node *panel_node;
int ret;

ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
@@ -298,6 +327,14 @@ static int ptn3460_probe(struct i2c_client *client,
return -ENOMEM;
}

+   panel_node = of_parse_phandle(dev->of_node, "panel", 0);
+   if (panel_node) {
+   ptn_bridge->panel = of_drm_find_panel(panel_node);
+   of_node_put(panel_node);
+   if (!ptn_bridge->panel)
+   return -EPROBE_DEFER;
+   }
+
ptn_bridge->client = client;
ptn_bridge->gpio_pd_n = of_get_named_gpio(dev->of_node,
"powerdown-gpio", 0);
-- 
1.7.9.5

[PATCH V7 05/12] drm/exynos: dp: support drm_bridge

[Ajay Kumar]

Modify driver to support drm_bridge.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/Kconfig  |1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c |   38 +++
 drivers/gpu/drm/exynos/exynos_dp_core.h |1 +
 3 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 4c0e071..bdef294 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -54,6 +54,7 @@ config DRM_EXYNOS_DP
depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS
default DRM_EXYNOS
select DRM_PANEL
+   select DRM_BRIDGE
help
  This enables support for DP device.

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 61ce6e4..a8a8b87 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -987,9 +987,17 @@ static struct drm_connector_helper_funcs 
exynos_dp_connector_helper_funcs = {
 };

 /* returns the number of bridges attached */
-static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
struct drm_encoder *encoder)
 {
+   int ret;
+
+   ret = drm_bridge_attach(dp->bridge, encoder);
+   if (ret) {
+   DRM_ERROR("Failed to attach bridge to encoder\n");
+   return ret;
+   }
+
return 0;
 }

@@ -1003,9 +1011,11 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
dp->encoder = encoder;

/* Pre-empt DP connector creation if there's a bridge */
-   ret = exynos_drm_attach_lcd_bridge(dp->drm_dev, encoder);
-   if (ret)
-   return 0;
+   if (dp->bridge) {
+   ret = exynos_drm_attach_lcd_bridge(dp, encoder);
+   if (!ret)
+   return 0;
+   }

connector->polled = DRM_CONNECTOR_POLL_HPD;

@@ -1257,7 +1267,7 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
if (ret)
return ret;

-   if (!dp->panel) {
+   if (!dp->panel && !dp->bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
return ret;
@@ -1348,7 +1358,7 @@ static const struct component_ops exynos_dp_ops = {
 static int exynos_dp_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
-   struct device_node *panel_node;
+   struct device_node *node;
struct exynos_dp_device *dp;
int ret;

@@ -1362,14 +1372,22 @@ static int exynos_dp_probe(struct platform_device *pdev)
if (!dp)
return -ENOMEM;

-   panel_node = of_parse_phandle(dev->of_node, "panel", 0);
-   if (panel_node) {
-   dp->panel = of_drm_find_panel(panel_node);
-   of_node_put(panel_node);
+   node = of_parse_phandle(dev->of_node, "panel", 0);
+   if (node) {
+   dp->panel = of_drm_find_panel(node);
+   of_node_put(node);
if (!dp->panel)
return -EPROBE_DEFER;
}

+   node = of_parse_phandle(dev->of_node, "bridge", 0);
+   if (node) {
+   dp->bridge = of_drm_find_bridge(node);
+   of_node_put(node);
+   if (!dp->bridge)
+   return -EPROBE_DEFER;
+   }
+
exynos_dp_display.ctx = dp;

ret = component_add(>dev, _dp_ops);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..3b0ba93 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -150,6 +150,7 @@ struct exynos_dp_device {
struct drm_connectorconnector;
struct drm_encoder  *encoder;
struct drm_panel*panel;
+   struct drm_bridge   *bridge;
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-- 
1.7.9.5

[PATCH V7 04/12] drm/bridge: ptn3460: Convert to i2c driver model

[Ajay Kumar]

Use drm_bridge helpers to modify the driver to support
i2c driver model.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/bridge/Kconfig  |6 +-
 drivers/gpu/drm/bridge/ptn3460.c|  122 +--
 drivers/gpu/drm/exynos/Kconfig  |2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |   22 --
 4 files changed, 89 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 5a8e907..7e63a52 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -10,7 +10,9 @@ menu "bridge chips"

 config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
-   depends on DRM_BRIDGE
-   ---help---
+   depends on OF
+   depends on I2C
+   help
+ ptn3460 eDP-LVDS bridge chip driver.

 endmenu
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index a2ddc8d..651640a 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -36,7 +36,6 @@
 struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
-   struct drm_encoder *encoder;
struct drm_bridge bridge;
struct edid *edid;
int gpio_pd_n;
@@ -188,14 +187,6 @@ static void ptn3460_bridge_destroy(struct drm_bridge 
*bridge)
/* Nothing else to free, we've got devm allocated memory */
 }

-static struct drm_bridge_funcs ptn3460_bridge_funcs = {
-   .pre_enable = ptn3460_pre_enable,
-   .enable = ptn3460_enable,
-   .disable = ptn3460_disable,
-   .post_disable = ptn3460_post_disable,
-   .destroy = ptn3460_bridge_destroy,
-};
-
 static int ptn3460_get_modes(struct drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge;
@@ -240,7 +231,7 @@ static struct drm_encoder *ptn3460_best_encoder(struct 
drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);

-   return ptn_bridge->encoder;
+   return ptn_bridge->bridge.encoder;
 }

 static struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
@@ -266,31 +257,62 @@ static struct drm_connector_funcs ptn3460_connector_funcs 
= {
.destroy = ptn3460_connector_destroy,
 };

-int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
-   struct i2c_client *client, struct device_node *node)
+int ptn3460_bridge_attach(struct drm_bridge *bridge)
 {
+   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;
+
+   ret = drm_connector_init(bridge->drm, _bridge->connector,
+   _connector_funcs, DRM_MODE_CONNECTOR_LVDS);
+   if (ret) {
+   DRM_ERROR("Failed to initialize connector with drm\n");
+   return ret;
+   }
+   drm_connector_helper_add(_bridge->connector,
+   _connector_helper_funcs);
+   drm_connector_register(_bridge->connector);
+   drm_mode_connector_attach_encoder(_bridge->connector,
+   bridge->encoder);
+
+   return ret;
+}
+
+static struct drm_bridge_funcs ptn3460_bridge_funcs = {
+   .pre_enable = ptn3460_pre_enable,
+   .enable = ptn3460_enable,
+   .disable = ptn3460_disable,
+   .post_disable = ptn3460_post_disable,
+   .destroy = ptn3460_bridge_destroy,
+   .attach = ptn3460_bridge_attach,
+};
+
+static int ptn3460_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct device *dev = >dev;
struct ptn3460_bridge *ptn_bridge;
+   int ret;

-   ptn_bridge = devm_kzalloc(dev->dev, sizeof(*ptn_bridge), GFP_KERNEL);
+   ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
if (!ptn_bridge) {
return -ENOMEM;
}

ptn_bridge->client = client;
-   ptn_bridge->encoder = encoder;
-   ptn_bridge->gpio_pd_n = of_get_named_gpio(node, "powerdown-gpio", 0);
+   ptn_bridge->gpio_pd_n = of_get_named_gpio(dev->of_node,
+   "powerdown-gpio", 0);
if (gpio_is_valid(ptn_bridge->gpio_pd_n)) {
ret = gpio_request_one(ptn_bridge->gpio_pd_n,
GPIOF_OUT_INIT_HIGH, "PTN3460_PD_N");
if (ret) {
-   dev_err(>dev,
-   "Request powerdown-gpio failed (%d)\n", ret);
+   dev_err(dev, "Request powerdown-gpio failed (%d)\n",
+   ret);
return ret;
}
}

-   ptn_bridge->gpio_rst_n = of_get_named_gpio(node, "reset-gpio", 0);
+   ptn_bridge->gpio_rst_n = of_get_named_gpio(dev->of_node,
+   "reset-gpio", 0);
if 

[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

[Ajay Kumar]

A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.

The bridge devices register themselves on a lookup table
when they get probed by calling "drm_bridge_add".

The parent encoder driver waits till the bridge is available
in the lookup table(by calling "of_drm_find_bridge") and then
continues with its initialization.

The encoder driver should also call "drm_bridge_attach" to pass
on the drm_device, encoder pointers to the bridge object.

drm_bridge_attach inturn calls drm_bridge_init to register itself
with the drm core. Later, it calls "bridge->funcs->attach" so that
bridge can continue with other initializations.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/bridge/Kconfig |   15 -
 drivers/gpu/drm/drm_bridge.c   |  102 
 drivers/gpu/drm/drm_crtc.c |4 +-
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |4 +-
 include/drm/drm_crtc.h |   12 +++-
 6 files changed, 131 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_bridge.c

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..bdbfb6f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,6 +19,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-$(CONFIG_DRM_BRIDGE) += drm_bridge.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..5a8e907 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -1,5 +1,16 @@
-config DRM_PTN3460
-   tristate "PTN3460 DP/LVDS bridge"
+config DRM_BRIDGE
+   tristate
depends on DRM
select DRM_KMS_HELPER
+   help
+ Bridge registration and lookup framework.
+
+menu "bridge chips"
+   depends on DRM_BRIDGE
+
+config DRM_PTN3460
+   tristate "PTN3460 DP/LVDS bridge"
+   depends on DRM_BRIDGE
---help---
+
+endmenu
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
new file mode 100644
index 000..b2d43fd
--- /dev/null
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "drm/drmP.h"
+
+static DEFINE_MUTEX(bridge_lock);
+static LIST_HEAD(bridge_list);
+
+int drm_bridge_add(struct drm_bridge *bridge)
+{
+   mutex_lock(_lock);
+   list_add_tail(>list, _list);
+   mutex_unlock(_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_bridge_add);
+
+void drm_bridge_remove(struct drm_bridge *bridge)
+{
+   mutex_lock(_lock);
+   list_del_init(>list);
+   mutex_unlock(_lock);
+}
+EXPORT_SYMBOL(drm_bridge_remove);
+
+int drm_bridge_attach(struct drm_bridge *bridge,
+   struct drm_encoder *encoder)
+{
+   int ret;
+
+   if (!bridge || !encoder)
+   return -EINVAL;
+
+   if (bridge->encoder)
+   return -EBUSY;
+
+   encoder->bridge = bridge;
+   bridge->encoder = encoder;
+   bridge->drm = encoder->dev;
+
+   ret = drm_bridge_init(bridge->drm, bridge);
+   if (ret) {
+   DRM_ERROR("Failed to register bridge with drm\n");
+   return ret;
+   }
+
+   if (bridge->funcs->attach)
+   return bridge->funcs->attach(bridge);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_bridge_attach);
+
+#ifdef CONFIG_OF
+struct drm_bridge *of_drm_find_bridge(struct device_node *np)
+{
+   struct drm_bridge *bridge;
+
+   mutex_lock(_lock);
+
+   

[PATCH V7 02/12] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init

[Ajay Kumar]

Assign the pointer to bridge ops structure(drm_bridge_funcs) in
the bridge driver itself, instead of passing it to drm_bridge_init.

This will allow bridge driver developer to pack bridge private
information inside the bridge object and pass only the drm-relevant
information to drm_bridge_init.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/bridge/ptn3460.c   |3 ++-
 drivers/gpu/drm/drm_crtc.c |5 +
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 ++-
 drivers/gpu/drm/sti/sti_hda.c  |3 ++-
 drivers/gpu/drm/sti/sti_hdmi.c |3 ++-
 include/drm/drm_crtc.h |3 +--
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 4db38e1..a2ddc8d 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -313,7 +313,8 @@ int ptn3460_init(struct drm_device *dev, struct drm_encoder 
*encoder,
goto err;
}

-   ret = drm_bridge_init(dev, _bridge->bridge, _bridge_funcs);
+   ptn_bridge->bridge.funcs = _bridge_funcs;
+   ret = drm_bridge_init(dev, _bridge->bridge);
if (ret) {
DRM_ERROR("Failed to initialize bridge with drm\n");
goto err;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fa2be24..25f5cfa 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1022,7 +1022,6 @@ EXPORT_SYMBOL(drm_connector_unplug_all);
  * drm_bridge_init - initialize a drm transcoder/bridge
  * @dev: drm device
  * @bridge: transcoder/bridge to set up
- * @funcs: bridge function table
  *
  * Initialises a preallocated bridge. Bridges should be
  * subclassed as part of driver connector objects.
@@ -1030,8 +1029,7 @@ EXPORT_SYMBOL(drm_connector_unplug_all);
  * Returns:
  * Zero on success, error code on failure.
  */
-int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
-   const struct drm_bridge_funcs *funcs)
+int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge)
 {
int ret;

@@ -1042,7 +1040,6 @@ int drm_bridge_init(struct drm_device *dev, struct 
drm_bridge *bridge,
goto out;

bridge->dev = dev;
-   bridge->funcs = funcs;

list_add_tail(>head, >mode_config.bridge_list);
dev->mode_config.num_bridge++;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index f6cf745..0309539 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -221,8 +221,9 @@ struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi)
hdmi_bridge->hdmi = hdmi_reference(hdmi);

bridge = _bridge->base;
+   bridge->funcs = _bridge_funcs;

-   drm_bridge_init(hdmi->dev, bridge, _bridge_funcs);
+   drm_bridge_init(hdmi->dev, bridge);

return bridge;

diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 72d957f..b3344c7 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -664,7 +664,8 @@ static int sti_hda_bind(struct device *dev, struct device 
*master, void *data)
return -ENOMEM;

bridge->driver_private = hda;
-   drm_bridge_init(drm_dev, bridge, _hda_bridge_funcs);
+   bridge->funcs = _hda_bridge_funcs;
+   drm_bridge_init(drm_dev, bridge);

encoder->bridge = bridge;
connector->encoder = encoder;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 284e541..3ad319f 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -629,7 +629,8 @@ static int sti_hdmi_bind(struct device *dev, struct device 
*master, void *data)
return -ENOMEM;

bridge->driver_private = hdmi;
-   drm_bridge_init(drm_dev, bridge, _hdmi_bridge_funcs);
+   bridge->funcs = _hdmi_bridge_funcs;
+   drm_bridge_init(drm_dev, bridge);

encoder->bridge = bridge;
connector->encoder = encoder;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0..f48a436 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -906,8 +906,7 @@ extern void drm_connector_cleanup(struct drm_connector 
*connector);
 /* helper to unplug all connectors from sysfs for device */
 extern void drm_connector_unplug_all(struct drm_device *dev);

-extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
-  const struct drm_bridge_funcs *funcs);
+extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge);
 extern void drm_bridge_cleanup(struct drm_bridge *bridge);

 extern int drm_encoder_init(struct drm_device *dev,
-- 
1.7.9.5

[PATCH V7 01/12] drm/bridge: ptn3460: Few trivial cleanups

[Ajay Kumar]

This patch does the following changes:
-- Use usleep_range instead of udelay.
-- Remove driver_private member from ptn3460 structure.
-- Make all possible functions and structures static.
-- Use dev_err for non-DRM errors.
-- Arrange header files alphabetically.
-- s/edid/EDID in all error messages.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/bridge/ptn3460.c |   95 +++---
 1 file changed, 48 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index d466696..4db38e1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -13,19 +13,19 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 

-#include "drmP.h"
-#include "drm_edid.h"
+#include "bridge/ptn3460.h"
+
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"
-
-#include "bridge/ptn3460.h"
+#include "drm_edid.h"
+#include "drmP.h"

 #define PTN3460_EDID_ADDR  0x0
 #define PTN3460_EDID_EMULATION_ADDR0x84
@@ -37,7 +37,7 @@ struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_encoder *encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge bridge;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -45,6 +45,18 @@ struct ptn3460_bridge {
bool enabled;
 };

+static inline struct ptn3460_bridge *
+   bridge_to_ptn3460(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct ptn3460_bridge, bridge);
+}
+
+static inline struct ptn3460_bridge *
+   connector_to_ptn3460(struct drm_connector *connector)
+{
+   return container_of(connector, struct ptn3460_bridge, connector);
+}
+
 static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
u8 *buf, int len)
 {
@@ -92,7 +104,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge 
*ptn_bridge)
ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_SRAM_LOAD_ADDR,
ptn_bridge->edid_emulation);
if (ret) {
-   DRM_ERROR("Failed to transfer edid to sram, ret=%d\n", ret);
+   DRM_ERROR("Failed to transfer EDID to sram, ret=%d\n", ret);
return ret;
}

@@ -102,7 +114,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge 
*ptn_bridge)

ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
if (ret) {
-   DRM_ERROR("Failed to write edid value, ret=%d\n", ret);
+   DRM_ERROR("Failed to write EDID value, ret=%d\n", ret);
return ret;
}

@@ -111,7 +123,7 @@ static int ptn3460_select_edid(struct ptn3460_bridge 
*ptn_bridge)

 static void ptn3460_pre_enable(struct drm_bridge *bridge)
 {
-   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;

if (ptn_bridge->enabled)
@@ -122,7 +134,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)

if (gpio_is_valid(ptn_bridge->gpio_rst_n)) {
gpio_set_value(ptn_bridge->gpio_rst_n, 0);
-   udelay(10);
+   usleep_range(10, 20);
gpio_set_value(ptn_bridge->gpio_rst_n, 1);
}

@@ -135,7 +147,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)

ret = ptn3460_select_edid(ptn_bridge);
if (ret)
-   DRM_ERROR("Select edid failed ret=%d\n", ret);
+   DRM_ERROR("Select EDID failed ret=%d\n", ret);

ptn_bridge->enabled = true;
 }
@@ -146,7 +158,7 @@ static void ptn3460_enable(struct drm_bridge *bridge)

 static void ptn3460_disable(struct drm_bridge *bridge)
 {
-   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);

if (!ptn_bridge->enabled)
return;
@@ -164,9 +176,9 @@ static void ptn3460_post_disable(struct drm_bridge *bridge)
 {
 }

-void ptn3460_bridge_destroy(struct drm_bridge *bridge)
+static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
 {
-   struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
+   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);

drm_bridge_cleanup(bridge);
if (gpio_is_valid(ptn_bridge->gpio_pd_n))
@@ -176,7 +188,7 @@ void ptn3460_bridge_destroy(struct drm_bridge *bridge)
/* Nothing else to free, we've got devm allocated memory */
 }

-struct drm_bridge_funcs ptn3460_bridge_funcs = {
+static struct drm_bridge_funcs ptn3460_bridge_funcs = {
.pre_enable = ptn3460_pre_enable,
.enable = ptn3460_enable,
.disable = ptn3460_disable,
@@ -184,24 +196,24 @@ struct drm_bridge_funcs 

[PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support

[Ajay Kumar]

This series is based on master branch of Linus tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I have tested this after adding few DT changes for exynos5250-snow and
exynos5420-peach-pit boards.

The V4 series of this particular patchset was also tested by:
Rahul Sharma 
Javier Martinez Canillas 

Changes since V2:
-- Address comments from Jingoo Han for ps8622 driver
-- Address comments from Daniel, Rob and Thierry regarding
   bridge chaining
-- Address comments from Thierry regarding the names for
   new drm_panel functions

Changes since V3:
-- Remove hotplug based initialization of exynos_dp
-- Make exynos_dp work directly with drm_panel, remove
   dependency on panel_binder
-- Minor cleanups in panel_binder and panel_lvds driver

Changes since V4:
-- Use gpiod interface for panel-lvds and ps8622 drivers.
-- Address comments from Javier.
-- Fix compilation issues when PANEL_BINDER is selected as module.
-- Split Documentation patches from driver patches.
-- Rebase on top of the tree.

Changes since V5:
-- Modify bridge drivers to support driver model.
-- Drop the concept of bridge chain(sincle there are no 2 real bridges)
   Hence drop bridge-panel_binder layer.
-- Drop panel-lvds driver and accomodate the required changes in
   panel-simple driver.
-- Use gpiod interface in ptn3460 driver.
-- Address all comments by Thierry Reding for V5 series.
-- Address comments from Sean Paul for exynos_dp_commit issue.

Changes since V6:
-- Panel patches were seperated and they are merged already.
-- Fix few issues with ptn3460, before modifying the bridge core.
-- Modify drm_bridge as per Thierry's comments for V6 series.
-- Add drm_bridge changes minimally without breaking existing code.
-- Add new features for ptn3460, step-by-step.
-- Address comments from Thierry and Andreas for ptn3460 and ps8622.
-- Split documentation patches from driver patches.

"[PATCH V7 5/12] drm/exynos: dp: support drm_bridge" introduces following
Kconfig error:
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:39: symbol DRM_KMS_FB_HELPER depends on 
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:33: symbol DRM_KMS_HELPER is selected by DRM_BRIDGE
drivers/gpu/drm/bridge/Kconfig:1:   symbol DRM_BRIDGE is selected by 
DRM_EXYNOS_DP
drivers/gpu/drm/exynos/Kconfig:53:  symbol DRM_EXYNOS_DP depends on 
DRM_EXYNOS_FIMD
drivers/gpu/drm/exynos/Kconfig:28:  symbol DRM_EXYNOS_FIMD depends on FB_S3C
drivers/video/fbdev/Kconfig:2038:   symbol FB_S3C depends on FB

What's the best way to fix the above ambiguity?

Ajay Kumar (11):
  [PATCH V7 1/12] drm/bridge: ptn3460: Few trivial cleanups
  [PATCH V7 2/12] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
  [PATCH V7 3/12] drm/bridge: Add helper functions for drm_bridge
  [PATCH V7 4/12] drm/bridge: ptn3460: convert to i2c driver model
  [PATCH V7 5/12] drm/exynos: dp: support drm_bridge
  [PATCH V7 6/12] drm/bridge: ptn3460: support drm_panel
  [PATCH V7 7/12] drm/bridge: ptn3460: probe connector at the end of bridge 
attach
  [PATCH V7 8/12] drm/bridge: ptn3460: use gpiod interface
  [PATCH V7 9/12] Documentation: drm: bridge: move to video/bridge
  [PATCH V7 10/12] Documentation: devicetree: Add vendor prefix for parade
  [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT 
properties

Vincent Palatin (1):
  [PATCH V7 12/12] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

 .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 -
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 .../devicetree/bindings/video/bridge/ps8622.txt|   20 +
 .../devicetree/bindings/video/bridge/ptn3460.txt   |   27 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/bridge/Kconfig |   30 +-
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/ps8622.c|  681 
 drivers/gpu/drm/bridge/ptn3460.c   |  302 +
 drivers/gpu/drm/drm_bridge.c   |  102 +++
 drivers/gpu/drm/drm_crtc.c |9 +-
 drivers/gpu/drm/exynos/Kconfig |3 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c|   54 +-
 drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |7 +-
 drivers/gpu/drm/sti/sti_hda.c  |3 +-
 drivers/gpu/drm/sti/sti_hdmi.c |3 +-
 include/drm/drm_crtc.h |   15 +-
 18 files changed, 1098 insertions(+), 189 deletions(-)
 delete mode 100644 

Ilija Hadzic's Virtual CRTCs feature discuss

[Daniel Vetter]

Please don't drop mailing lists, especially when you've dug out some
good information like the stuff below. Readding dri-devel.
-Danel

On Wed, Aug 27, 2014 at 7:21 PM, Derek  wrote:
> Hi Daniel
> Thanks, Hans Verkuil's git repository is here
> git://linuxtv.org/hverkuil/media_tree.git. branch name vivid2.
> his slide is here:
> http://events.linuxfoundation.org/sites/events/files/slides/v4l2-testing.pdf
> And I'm agree that it isn't for virtual drm driver.
>
> I found that there are two virtual drm driver in kernel source code.
> first one is vmwgfx  driver/gpu/drm/vmwgfx
> according to
> http://mesa3d.org/vmware-guest.html
> This driver gives a Linux virtual machine access to the host's GPU for
> hardware-accelerated 3D.
>
> another one is gxl  drivers/gpu/drm/gxl
> It is for readhat virtualization KVM + spice.
>
> and seems drm infrastructure support virtual driver already. just search
> DRM_MODE_ENCODER_VIRTUAL/DRM_MODE_CONNECTOR_VIRTUAL
>
> both driver need user space XServer driver support.
>
> I will take a look these drivers find out if i can use similar driver to
> create virtual CRTC based on drm without extra userspace xserver driver. and
> develop a virtualMonitor which allow you to use compute, tablet, smartphone
> as a second monitor for your primary computer.  an example page is
> http://virtualmonitor.github.io
>
> Thanks a lots
>
> Best wishes
> Derek
>
>
>
> On Tue, Aug 26, 2014 at 1:18 AM, Daniel Vetter  wrote:
>>
>> On Mon, Aug 25, 2014 at 12:02:09PM -0700, Derek wrote:
>> > Hi, Daniel
>> > Thanks for your response!
>> > Talking about v4l's virtual gpu driver?  Could you please tell some more
>> > informations. is this driver in
>> > git.linuxtv.org/cgit.cgi/media_tree.git
>> > I want to take a look this driver. but I can't find it in their git
>> > repository. Or is there any introduction post related this driver?
>> > Thanks.
>>
>> It isn't merged yet afaik, but Hans Verkuil has made a nice presentation
>> about it at LinuxCon. Unfortunately the linuxcon page doesn't even have
>> the slides afaics.
>>
>>
>> http://lccona14.sched.org/event/2e156d3ce84309b2932f2e7a512904e0#.U_xCcjSmXmE
>>
>> The driver was called vidid (there's an older one called vidi apparently).
>> But I don't think it's a good model for a virtual drm driver, if that's
>> why you want to look at it. Just mentioned it to show that there's lots of
>> uses for virtual drivers.
>> -Daniel
>>
>> >
>> > Best wishes
>> > Derek
>> >
>> >
>> > On Mon, Aug 25, 2014 at 6:12 AM, Daniel Vetter  wrote:
>> >
>> > > On Mon, Aug 18, 2014 at 03:35:16PM -0700, Derek wrote:
>> > > > Hi every one
>> > > > I'm currently working on VirtualMonitor in my leisure time. It
>> > > > allows you
>> > > > to use compute/tablet/smartphone as a second monitor for your
>> > > > primary
>> > > > computer. please refer to http://virtualmonitor.github.io for more
>> > > > information. Currently I have released very basic version for
>> > > > windows2000-windows7 to demonstrate the project is feasible. When I
>> > > > was
>> > > > trying to make a further step on windows, I realized it is difficult
>> > > > for
>> > > an
>> > > > individual, as it is not open source and also without technical
>> > > > support
>> > > > from Microsoft.
>> > > >
>> > > > Then I want to move to linux, and I found Ilija Hadzic's post about
>> > > Virtual
>> > > > CRTCs. his post is here:
>> > > >
>> > >
>> > > http://lists.freedesktop.org/archives/dri-devel/2011-November/015975.html
>> > > > In his implementation, GPU driver can create arbitrary number of
>> > > > CRTCs
>> > > > (configurable by user) instead of only those CRTCs that represent
>> > > > real
>> > > > hardware.
>> > > > It is very useful not only for VirtualMonitor, but also
>> > > > VNC/Virtualization/USB display etc. based on this implementation
>> > > > those
>> > > > application will be able to take full advantage of the physical
>> > > > graphic
>> > > > card(3D acceleration).
>> > > >
>> > > > I want raise Ilijia's original question agian, if anybody in this
>> > > community
>> > > > think Virtual CRTCs is useful, and willing to work together to make
>> > > > a
>> > > > further progress.
>> > > > My thought is if can implement a driver independent layer between
>> > > > dri and
>> > > > vendor specific GPU driver, with some general API. maybe implement
>> > > > this
>> > > > based one vendor related GPU first? e.g. based on Ilijia's
>> > > > implementation
>> > > > for Radeon as a daemon?
>> > > >
>> > > > GPU driver is not my expertise, If some expert from this community
>> > > > think
>> > > > this feature is interesting, and willing to initiate a project for
>> > > > this
>> > > > feature, that will be great. Then people can work and discuss
>> > > > together.
>> > > >
>> > > > Any comments regarding to Virtual CRTC or VirtualMonitor are very
>> > > welcome.
>> > > > Thanks.
>> > >
>> > > I think the concept is overall sound (haven't looked at the old
>> > > patches in
>> > > detail).For the 

[Bug 82918] [tahiti xt] dota2 crashes

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

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

--- Comment #12 from Sylvain BERTRAND  ---
fedora rawhide is still using llvm kludge 3.4, notified fedora guy:
https://bugzilla.redhat.com/show_bug.cgi?id=1134563

Let you know once they get llvm 3.5 into rawhide.

-- 
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/20140827/0fd88e60/attachment.html>

[PATCH 03/16] video: Add DT binding documentation for VGA connector

[Laurent Pinchart]

Hi Rob,

On Wednesday 27 August 2014 12:12:36 Rob Herring wrote:
> On Wed, Aug 27, 2014 at 11:41 AM, Laurent Pinchart wrote:
> > The VGA connector is described by a single input port and an optional
> > DDC bus.
> 
> Wasn't there a generic connector binding for DVI, HDMI, etc.?

As far as I know, there are three separate generic bindings for DVI 
connectors, HDMI connectors, and analog TV connectors. The VGA connector 
doesn't seem to really fit into one of those categories.

> > Cc: devicetree at vger.kernel.org
> > Cc: linux-fbdev at vger.kernel.org
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  .../devicetree/bindings/video/vga-connector.txt| 28
> >  ++ 1 file changed, 28 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/video/vga-connector.txt> 
> > diff --git a/Documentation/devicetree/bindings/video/vga-connector.txt
> > b/Documentation/devicetree/bindings/video/vga-connector.txt new file mode
> > 100644
> > index 000..9a45ec1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/vga-connector.txt
> > @@ -0,0 +1,28 @@
> > +VGA Connector
> > +==
> > +
> > +Required properties:
> > +- compatible: "vga-connector"
> > +
> > +Optional properties:
> > +- label: a symbolic name for the connector
> 
> ...which corresponds to hardware labels.
> 
> > +- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC
> > +
> > +Required nodes:
> > +- Video port for VGA input
> 
> A reference to the relevant video graph bindings should be added here.

I'll fix that.

> > +
> > +Example
> > +---
> > +
> > +vga0: connector at 0 {
> > +   compatible = "vga-connector";
> > +   label = "vga";
> > +
> > +   ddc-i2c-bus = <>;
> > +
> > +   port {
> > +   vga_connector_in: endpoint {
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > +};

-- 
Regards,

Laurent Pinchart

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #26 from Andy Furniss  ---
(In reply to comment #23)
> Created attachment 105318 [details] [review]
> r600g,radeonsi: Inform the kernel if a BO will likely be accessed by the CPU
> 
> Does this Mesa patch (instead of the PIPE_USAGE_STREAM change) together with
> the previous two kernel patches I attached help Valley?

No difference with those.

The big kernel patch didn't apply on drm-fixes-3.17-wip, but it only failed in
noveau so I deleted that from it.

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

[PATCH] drm/i915: Remove bogus __init annotation from DMI callbacks

[Mathias Krause]

The __init annotations for the DMI callback functions are wrong as this
code can be called even after the module has been initialized, e.g. like
this:

  # echo 1 > /sys/bus/pci/devices/:00:02.0/remove
  # modprobe i915
  # echo 1 > /sys/bus/pci/rescan

The first command will remove the PCI device from the kernel's device
list so the second command won't see it right away. But as it registers
a PCI driver it'll see it on the third command. If the system happens to
match one of the DMI table entries we'll try to call a function in long
released memory and generate an Oops, at best.

Fix this by removing the bogus annotation.

Modpost should have caught that one but it ignores section reference
mismatches from the .rodata section. :/

Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT")
Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...")
Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...")
Signed-off-by: Mathias Krause 
Cc: Daniel Vetter 
Cc: Duncan Laurie 
Cc: Jarod Wilson 
Cc: Rusty Russell # Can modpost be fixed?
Cc: stable at vger.kernel.org
---

In the long run me might want to move the DMI tests to some __init code
to be able to mark the DMI tables as __initconst, thereby allowing to
release this memory after module initialization. That would safe us some
~11 kB of memory, as the DMI data shouldn't change at run-time.

 drivers/gpu/drm/i915/intel_bios.c |2 +-
 drivers/gpu/drm/i915/intel_crt.c  |2 +-
 drivers/gpu/drm/i915/intel_lvds.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index a66955037e4e..eee79e1c3222 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1123,7 +1123,7 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
}
 }

-static int __init intel_no_opregion_vbt_callback(const struct dmi_system_id 
*id)
+static int intel_no_opregion_vbt_callback(const struct dmi_system_id *id)
 {
DRM_DEBUG_KMS("Falling back to manually reading VBT from "
  "VBIOS ROM for %s\n",
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index e8abfce40976..9212e6504e0f 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -804,7 +804,7 @@ static const struct drm_encoder_funcs intel_crt_enc_funcs = 
{
.destroy = intel_encoder_destroy,
 };

-static int __init intel_no_crt_dmi_callback(const struct dmi_system_id *id)
+static int intel_no_crt_dmi_callback(const struct dmi_system_id *id)
 {
DRM_INFO("Skipping CRT initialization for %s\n", id->ident);
return 1;
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 881361c0f27e..fdf40267249c 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -538,7 +538,7 @@ static const struct drm_encoder_funcs intel_lvds_enc_funcs 
= {
.destroy = intel_encoder_destroy,
 };

-static int __init intel_no_lvds_dmi_callback(const struct dmi_system_id *id)
+static int intel_no_lvds_dmi_callback(const struct dmi_system_id *id)
 {
DRM_INFO("Skipping LVDS initialization for %s\n", id->ident);
return 1;
-- 
1.7.10.4

[PATCH 16/16] ARM: shmobile: koelsch: Enable DU device in DT

[Laurent Pinchart]

Specify the DU output topology, enable the DU device and configure the
related pins.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 178431d..19d7b36 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -209,6 +209,46 @@
states = <330 1
  180 0>;
};
+
+   panel {
+   compatible = "mitsubishi,aa104xd12", "panel-dpi";
+
+   width-mm = <210>;
+   height-mm = <158>;
+
+   panel-timing {
+   /* 1024x768 @65Hz */
+   clock-frequency = <6500>;
+   hactive = <1024>;
+   vactive = <768>;
+   hsync-len = <136>;
+   hfront-porch = <20>;
+   hback-porch = <160>;
+   vfront-porch = <3>;
+   vback-porch = <29>;
+   vsync-len = <6>;
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   ports {
+   port at 1 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };

 _clk {
@@ -216,9 +256,6 @@
 };

  {
-   pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
-
i2c2_pins: i2c2 {
renesas,groups = "i2c2";
renesas,function = "i2c2";
-- 
1.8.5.5

[PATCH 15/16] ARM: shmobile: lager: Enable DU device in DT

[Laurent Pinchart]

Specify the DU output topology, enable the DU device and configure the
related pins.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 78 +++--
 1 file changed, 75 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 48412bf..41e0806 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -144,6 +144,81 @@
states = <330 1
  180 0>;
};
+
+   adv7123 {
+   compatible = "adi,adv7123";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   port at 0 {
+   adv7123_in: endpoint {
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+   port at 1 {
+   adv7123_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   vga {
+   compatible = "vga-connector";
+
+   port {
+   vga_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   panel {
+   compatible = "mitsubishi,aa104xd12", "panel-dpi";
+
+   width-mm = <210>;
+   height-mm = <158>;
+
+   panel-timing {
+   /* 1024x768 @65Hz */
+   clock-frequency = <6500>;
+   hactive = <1024>;
+   vactive = <768>;
+   hsync-len = <136>;
+   hfront-porch = <20>;
+   hback-porch = <160>;
+   vfront-porch = <3>;
+   vback-porch = <29>;
+   vsync-len = <6>;
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out_lvds1>;
+   };
+   };
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   ports {
+   port at 0 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   port at 2 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };

 _clk {
@@ -151,9 +226,6 @@
 };

  {
-   pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
-
du_pins: du {
renesas,groups = "du_rgb666", "du_sync_1", "du_clk_out_0";
renesas,function = "du";
-- 
1.8.5.5

[PATCH 14/16] ARM: shmobile: marzen: Enable DU device in DT

[Laurent Pinchart]

Specify the DU output topology, enable the DU device and configure the
related pins.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7779-marzen.dts | 106 +++
 1 file changed, 106 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts 
b/arch/arm/boot/dts/r8a7779-marzen.dts
index c160404..da2d0aa 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -68,6 +68,101 @@
gpios = < 31 GPIO_ACTIVE_HIGH>;
};
};
+
+   vga-enc {
+   compatible = "adi,adv7123";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   port at 0 {
+   vga_enc_in: endpoint {
+   remote-endpoint = <_out_rgb0>;
+   };
+   };
+   port at 1 {
+   vga_enc_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   vga {
+   compatible = "vga-connector";
+
+   port {
+   vga_in: endpoint {
+   remote-endpoint = <_enc_out>;
+   };
+   };
+   };
+
+   lvds-enc {
+   compatible = "thine,thc63lvdm83d";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   port at 0 {
+   lvds_enc_in: endpoint {
+   remote-endpoint = <_out_rgb1>;
+   };
+   };
+   port at 1 {
+   lvds_enc_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   panel {
+   compatible = "mitsubishi,aa104xd12", "panel-dpi";
+
+   width-mm = <210>;
+   height-mm = <158>;
+
+   panel-timing {
+   /* 1024x768 @65Hz */
+   clock-frequency = <6500>;
+   hactive = <1024>;
+   vactive = <768>;
+   hsync-len = <136>;
+   hfront-porch = <20>;
+   hback-porch = <160>;
+   vfront-porch = <3>;
+   vback-porch = <29>;
+   vsync-len = <6>;
+   };
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_enc_out>;
+   };
+   };
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   ports {
+   port at 0 {
+   endpoint {
+   remote-endpoint = <_enc_in>;
+   };
+   };
+   port at 1 {
+   endpoint {
+   remote-endpoint = <_enc_in>;
+   };
+   };
+   };
 };

  {
@@ -83,6 +178,17 @@
 };

  {
+   du_pins: du {
+   du0 {
+   renesas,groups = "du0_rgb888", "du0_sync_1", 
"du0_clk_out_0";
+   renesas,function = "du0";
+   };
+   du1 {
+   renesas,groups = "du1_rgb666", "du1_sync_1", 
"du1_clk_out";
+   renesas,function = "du1";
+   };
+   };
+
lan0_pins: lan0 {
intc {
renesas,groups = "intc_irq1_b";
-- 
1.8.5.5

[PATCH 13/16] ARM: shmobile: koelsch-reference: Remove DU platform device

[Laurent Pinchart]

The DU device is now instantiated from the device tree, remote the
corresponding platform device.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-shmobile/board-koelsch-reference.c | 73 
 1 file changed, 73 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-koelsch-reference.c 
b/arch/arm/mach-shmobile/board-koelsch-reference.c
index 46aa540..c370818 100644
--- a/arch/arm/mach-shmobile/board-koelsch-reference.c
+++ b/arch/arm/mach-shmobile/board-koelsch-reference.c
@@ -19,87 +19,15 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */

-#include 
 #include 
 #include 
-#include 

 #include 

-#include "clock.h"
 #include "common.h"
-#include "irqs.h"
 #include "r8a7791.h"
 #include "rcar-gen2.h"

-/* DU */
-static struct rcar_du_encoder_data koelsch_du_encoders[] = {
-   {
-   .type = RCAR_DU_ENCODER_NONE,
-   .output = RCAR_DU_OUTPUT_LVDS0,
-   .connector.lvds.panel = {
-   .width_mm = 210,
-   .height_mm = 158,
-   .mode = {
-   .pixelclock = 6500,
-   .hactive = 1024,
-   .hfront_porch = 20,
-   .hback_porch = 160,
-   .hsync_len = 136,
-   .vactive = 768,
-   .vfront_porch = 3,
-   .vback_porch = 29,
-   .vsync_len = 6,
-   },
-   },
-   },
-};
-
-static struct rcar_du_platform_data koelsch_du_pdata = {
-   .encoders = koelsch_du_encoders,
-   .num_encoders = ARRAY_SIZE(koelsch_du_encoders),
-};
-
-static const struct resource du_resources[] __initconst = {
-   DEFINE_RES_MEM(0xfeb0, 0x4),
-   DEFINE_RES_MEM_NAMED(0xfeb9, 0x1c, "lvds.0"),
-   DEFINE_RES_IRQ(gic_spi(256)),
-   DEFINE_RES_IRQ(gic_spi(268)),
-};
-
-static void __init koelsch_add_du_device(void)
-{
-   struct platform_device_info info = {
-   .name = "rcar-du-r8a7791",
-   .id = -1,
-   .res = du_resources,
-   .num_res = ARRAY_SIZE(du_resources),
-   .data = _du_pdata,
-   .size_data = sizeof(koelsch_du_pdata),
-   .dma_mask = DMA_BIT_MASK(32),
-   };
-
-   platform_device_register_full();
-}
-
-/*
- * This is a really crude hack to provide clkdev support to platform
- * devices until they get moved to DT.
- */
-static const struct clk_name clk_names[] __initconst = {
-   { "du0", "du.0", "rcar-du-r8a7791" },
-   { "du1", "du.1", "rcar-du-r8a7791" },
-   { "lvds0", "lvds.0", "rcar-du-r8a7791" },
-};
-
-static void __init koelsch_add_standard_devices(void)
-{
-   shmobile_clk_workaround(clk_names, ARRAY_SIZE(clk_names), false);
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-
-   koelsch_add_du_device();
-}
-
 static const char * const koelsch_boards_compat_dt[] __initconst = {
"renesas,koelsch",
"renesas,koelsch-reference",
@@ -110,7 +38,6 @@ DT_MACHINE_START(KOELSCH_DT, "koelsch")
.smp= smp_ops(r8a7791_smp_ops),
.init_early = shmobile_init_delay,
.init_time  = rcar_gen2_timer_init,
-   .init_machine   = koelsch_add_standard_devices,
.init_late  = shmobile_init_late,
.reserve= rcar_gen2_reserve,
.dt_compat  = koelsch_boards_compat_dt,
-- 
1.8.5.5

[PATCH 12/16] ARM: shmobile: lager-reference: Remove DU platform device

[Laurent Pinchart]

The DU device is now instantiated from the device tree, remote the
corresponding platform device.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-shmobile/board-lager-reference.c | 80 --
 1 file changed, 80 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-lager-reference.c 
b/arch/arm/mach-shmobile/board-lager-reference.c
index bc4b483..82b077a 100644
--- a/arch/arm/mach-shmobile/board-lager-reference.c
+++ b/arch/arm/mach-shmobile/board-lager-reference.c
@@ -18,94 +18,15 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */

-#include 
 #include 
 #include 
-#include 

 #include 

-#include "clock.h"
 #include "common.h"
-#include "irqs.h"
 #include "r8a7790.h"
 #include "rcar-gen2.h"

-/* DU */
-static struct rcar_du_encoder_data lager_du_encoders[] = {
-   {
-   .type = RCAR_DU_ENCODER_VGA,
-   .output = RCAR_DU_OUTPUT_DPAD0,
-   }, {
-   .type = RCAR_DU_ENCODER_NONE,
-   .output = RCAR_DU_OUTPUT_LVDS1,
-   .connector.lvds.panel = {
-   .width_mm = 210,
-   .height_mm = 158,
-   .mode = {
-   .pixelclock = 6500,
-   .hactive = 1024,
-   .hfront_porch = 20,
-   .hback_porch = 160,
-   .hsync_len = 136,
-   .vactive = 768,
-   .vfront_porch = 3,
-   .vback_porch = 29,
-   .vsync_len = 6,
-   },
-   },
-   },
-};
-
-static struct rcar_du_platform_data lager_du_pdata = {
-   .encoders = lager_du_encoders,
-   .num_encoders = ARRAY_SIZE(lager_du_encoders),
-};
-
-static const struct resource du_resources[] __initconst = {
-   DEFINE_RES_MEM(0xfeb0, 0x7),
-   DEFINE_RES_MEM_NAMED(0xfeb9, 0x1c, "lvds.0"),
-   DEFINE_RES_MEM_NAMED(0xfeb94000, 0x1c, "lvds.1"),
-   DEFINE_RES_IRQ(gic_spi(256)),
-   DEFINE_RES_IRQ(gic_spi(268)),
-   DEFINE_RES_IRQ(gic_spi(269)),
-};
-
-static void __init lager_add_du_device(void)
-{
-   struct platform_device_info info = {
-   .name = "rcar-du-r8a7790",
-   .id = -1,
-   .res = du_resources,
-   .num_res = ARRAY_SIZE(du_resources),
-   .data = _du_pdata,
-   .size_data = sizeof(lager_du_pdata),
-   .dma_mask = DMA_BIT_MASK(32),
-   };
-
-   platform_device_register_full();
-}
-
-/*
- * This is a really crude hack to provide clkdev support to platform
- * devices until they get moved to DT.
- */
-static const struct clk_name clk_names[] __initconst = {
-   { "du0", "du.0", "rcar-du-r8a7790" },
-   { "du1", "du.1", "rcar-du-r8a7790" },
-   { "du2", "du.2", "rcar-du-r8a7790" },
-   { "lvds0", "lvds.0", "rcar-du-r8a7790" },
-   { "lvds1", "lvds.1", "rcar-du-r8a7790" },
-};
-
-static void __init lager_add_standard_devices(void)
-{
-   shmobile_clk_workaround(clk_names, ARRAY_SIZE(clk_names), false);
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-
-   lager_add_du_device();
-}
-
 static const char *lager_boards_compat_dt[] __initdata = {
"renesas,lager",
"renesas,lager-reference",
@@ -116,7 +37,6 @@ DT_MACHINE_START(LAGER_DT, "lager")
.smp= smp_ops(r8a7790_smp_ops),
.init_early = shmobile_init_delay,
.init_time  = rcar_gen2_timer_init,
-   .init_machine   = lager_add_standard_devices,
.init_late  = shmobile_init_late,
.reserve= rcar_gen2_reserve,
.dt_compat  = lager_boards_compat_dt,
-- 
1.8.5.5

[PATCH 11/16] ARM: shmobile: r8a7791: Add DU node to device tree

[Laurent Pinchart]

Add the DU device with a disabled state. Boards that want to enable the
DU need to specify the output topology

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 8a07505..d5f9ae06 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -637,6 +637,36 @@
status = "disabled";
};

+   du: du at feb0 {
+   compatible = "renesas,du-r8a7791";
+   reg = <0 0xfeb0 0 0x4>,
+ <0 0xfeb9 0 0x1c>;
+   reg-names = "du", "lvds.0";
+   interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
+<0 268 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clks R8A7791_CLK_DU0>,
+<_clks R8A7791_CLK_DU1>,
+<_clks R8A7791_CLK_LVDS0>;
+   clock-names = "du.0", "du.1", "lvds.0";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   du_out_rgb: endpoint {
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   du_out_lvds0: endpoint {
+   };
+   };
+   };
+   };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
-- 
1.8.5.5

[PATCH 10/16] ARM: shmobile: r8a7790: Add DU node to device tree

[Laurent Pinchart]

Add the DU device with a disabled state. Boards that want to enable the
DU need to specify the output topology.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7790.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index a3cd307..a1617b7 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -600,6 +600,45 @@
status = "disabled";
};

+   du: du at feb0 {
+   compatible = "renesas,du-r8a7790";
+   reg = <0 0xfeb0 0 0x7>,
+ <0 0xfeb9 0 0x1c>,
+ <0 0xfeb94000 0 0x1c>;
+   reg-names = "du", "lvds.0", "lvds.1";
+   interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
+<0 268 IRQ_TYPE_LEVEL_HIGH>,
+<0 269 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clks R8A7790_CLK_DU0>,
+<_clks R8A7790_CLK_DU1>,
+<_clks R8A7790_CLK_DU2>,
+<_clks R8A7790_CLK_LVDS0>,
+<_clks R8A7790_CLK_LVDS1>;
+   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   du_out_rgb: endpoint {
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   du_out_lvds0: endpoint {
+   };
+   };
+   port at 2 {
+   reg = <2>;
+   du_out_lvds1: endpoint {
+   };
+   };
+   };
+   };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
-- 
1.8.5.5

[PATCH 09/16] ARM: shmobile: r8a7779: Add DU node to device tree

[Laurent Pinchart]

Add the DU device with a disabled state. Boards that want to enable the
DU need to specify the output topology

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7779.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 559788b..9689314 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -379,6 +379,30 @@
status = "disabled";
};

+   du: du at fff8 {
+   compatible = "renesas,du-r8a7779";
+   reg = <0 0xfff8 0 0x4>;
+   interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clks R8A7779_CLK_DU>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   du_out_rgb0: endpoint {
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   du_out_rgb1: endpoint {
+   };
+   };
+   };
+   };
+
clocks {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.8.5.5

[PATCH 08/16] drm/rcar-du: Add OF support

[Laurent Pinchart]

Implement support for the R-Car DU DT bindings in the rcar-du DRM
driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 170 --
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   2 +
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  11 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 231 +++---
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  30 +++-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |   3 +-
 7 files changed, 344 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index fda64b7..4ee8cb2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,97 @@
 #include "rcar_du_regs.h"

 /* 
-
+ * Device Information
+ */
+
+static const struct rcar_du_device_info rcar_du_r8a7779_info = {
+   .features = 0,
+   .num_crtcs = 2,
+   .routes = {
+   /* R8A7779 has two RGB outputs and one (currently unsupported)
+* TCON output.
+*/
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(0),
+   .encoder_type = DRM_MODE_ENCODER_NONE,
+   .port = 0,
+   },
+   [RCAR_DU_OUTPUT_DPAD1] = {
+   .possible_crtcs = BIT(1) | BIT(0),
+   .encoder_type = DRM_MODE_ENCODER_NONE,
+   .port = 1,
+   },
+   },
+   .num_lvds = 0,
+};
+
+static const struct rcar_du_device_info rcar_du_r8a7790_info = {
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_DEFR8,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
+   .num_crtcs = 3,
+   .routes = {
+   /* R8A7790 has one RGB output, two LVDS outputs and one
+* (currently unsupported) TCON output.
+*/
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(2) | BIT(1) | BIT(0),
+   .encoder_type = DRM_MODE_ENCODER_NONE,
+   .port = 0,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .encoder_type = DRM_MODE_ENCODER_LVDS,
+   .port = 1,
+   },
+   [RCAR_DU_OUTPUT_LVDS1] = {
+   .possible_crtcs = BIT(2) | BIT(1),
+   .encoder_type = DRM_MODE_ENCODER_LVDS,
+   .port = 2,
+   },
+   },
+   .num_lvds = 2,
+};
+
+static const struct rcar_du_device_info rcar_du_r8a7791_info = {
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_DEFR8,
+   .num_crtcs = 2,
+   .routes = {
+   /* R8A7791 has one RGB output, one LVDS output and one
+* (currently unsupported) TCON output.
+*/
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(1),
+   .encoder_type = DRM_MODE_ENCODER_NONE,
+   .port = 0,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .encoder_type = DRM_MODE_ENCODER_LVDS,
+   .port = 1,
+   },
+   },
+   .num_lvds = 1,
+};
+
+static const struct platform_device_id rcar_du_id_table[] = {
+   { "rcar-du-r8a7779", (kernel_ulong_t)_du_r8a7779_info },
+   { "rcar-du-r8a7790", (kernel_ulong_t)_du_r8a7790_info },
+   { "rcar-du-r8a7791", (kernel_ulong_t)_du_r8a7791_info },
+   { }
+};
+
+MODULE_DEVICE_TABLE(platform, rcar_du_id_table);
+
+static const struct of_device_id rcar_du_of_table[] = {
+   { .compatible = "renesas,du-r8a7779", .data = _du_r8a7779_info },
+   { .compatible = "renesas,du-r8a7790", .data = _du_r8a7790_info },
+   { .compatible = "renesas,du-r8a7791", .data = _du_r8a7791_info },
+   { }
+};
+
+MODULE_DEVICE_TABLE(of, rcar_du_of_table);
+
+/* 
-
  * DRM operations
  */

@@ -53,12 +145,13 @@ static int rcar_du_unload(struct drm_device *dev)
 static int rcar_du_load(struct drm_device *dev, unsigned long flags)
 {
struct platform_device *pdev = dev->platformdev;
+   struct device_node *np = pdev->dev.of_node;
struct rcar_du_platform_data *pdata = pdev->dev.platform_data;
struct rcar_du_device *rcdu;
struct resource *mem;
int ret;

-   if (pdata == NULL) {
+   if (pdata == NULL && np == NULL) {

[PATCH 07/16] drm/rcar-du: Use struct videomode in platform data

[Laurent Pinchart]

In preparation for DT support where panel timings will be described by a
DRM-agnostic video mode, replace the struct drm_mode_modeinfo instance
in the panel platform data with a struct videomode.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-shmobile/board-koelsch-reference.c | 19 +--
 arch/arm/mach-shmobile/board-koelsch.c   | 19 +--
 arch/arm/mach-shmobile/board-lager-reference.c   | 19 +--
 arch/arm/mach-shmobile/board-lager.c | 19 +--
 arch/arm/mach-shmobile/board-marzen.c| 19 +--
 drivers/gpu/drm/rcar-du/Kconfig  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c| 15 +++
 include/linux/platform_data/rcar-du.h|  4 ++--
 8 files changed, 51 insertions(+), 64 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-koelsch-reference.c 
b/arch/arm/mach-shmobile/board-koelsch-reference.c
index 9db5e67..46aa540 100644
--- a/arch/arm/mach-shmobile/board-koelsch-reference.c
+++ b/arch/arm/mach-shmobile/board-koelsch-reference.c
@@ -41,16 +41,15 @@ static struct rcar_du_encoder_data koelsch_du_encoders[] = {
.width_mm = 210,
.height_mm = 158,
.mode = {
-   .clock = 65000,
-   .hdisplay = 1024,
-   .hsync_start = 1048,
-   .hsync_end = 1184,
-   .htotal = 1344,
-   .vdisplay = 768,
-   .vsync_start = 771,
-   .vsync_end = 777,
-   .vtotal = 806,
-   .flags = 0,
+   .pixelclock = 6500,
+   .hactive = 1024,
+   .hfront_porch = 20,
+   .hback_porch = 160,
+   .hsync_len = 136,
+   .vactive = 768,
+   .vfront_porch = 3,
+   .vback_porch = 29,
+   .vsync_len = 6,
},
},
},
diff --git a/arch/arm/mach-shmobile/board-koelsch.c 
b/arch/arm/mach-shmobile/board-koelsch.c
index b7d5bc7..ad10ddb 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -63,16 +63,15 @@ static struct rcar_du_encoder_data koelsch_du_encoders[] = {
.width_mm = 210,
.height_mm = 158,
.mode = {
-   .clock = 65000,
-   .hdisplay = 1024,
-   .hsync_start = 1048,
-   .hsync_end = 1184,
-   .htotal = 1344,
-   .vdisplay = 768,
-   .vsync_start = 771,
-   .vsync_end = 777,
-   .vtotal = 806,
-   .flags = 0,
+   .pixelclock = 6500,
+   .hactive = 1024,
+   .hfront_porch = 20,
+   .hback_porch = 160,
+   .hsync_len = 136,
+   .vactive = 768,
+   .vfront_porch = 3,
+   .vback_porch = 29,
+   .vsync_len = 6,
},
},
},
diff --git a/arch/arm/mach-shmobile/board-lager-reference.c 
b/arch/arm/mach-shmobile/board-lager-reference.c
index 2a05c02..bc4b483 100644
--- a/arch/arm/mach-shmobile/board-lager-reference.c
+++ b/arch/arm/mach-shmobile/board-lager-reference.c
@@ -43,16 +43,15 @@ static struct rcar_du_encoder_data lager_du_encoders[] = {
.width_mm = 210,
.height_mm = 158,
.mode = {
-   .clock = 65000,
-   .hdisplay = 1024,
-   .hsync_start = 1048,
-   .hsync_end = 1184,
-   .htotal = 1344,
-   .vdisplay = 768,
-   .vsync_start = 771,
-   .vsync_end = 777,
-   .vtotal = 806,
-   .flags = 0,
+   .pixelclock = 6500,
+   .hactive = 1024,
+   .hfront_porch = 20,
+   .hback_porch = 160,
+   .hsync_len = 136,
+   

[PATCH 06/16] video: Add DT bindings for the R-Car Display Unit

[Laurent Pinchart]

Aside of the usual boring core properties (compatible, reg, interrupts
and clocks), the bindings use the OF graph bindings to model connections
between the DU output video ports and the on-board and off-board
components.

Cc: devicetree at vger.kernel.org
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/video/renesas,du.txt   | 84 ++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/renesas,du.txt

diff --git a/Documentation/devicetree/bindings/video/renesas,du.txt 
b/Documentation/devicetree/bindings/video/renesas,du.txt
new file mode 100644
index 000..5102830
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/renesas,du.txt
@@ -0,0 +1,84 @@
+* Renesas R-Car Display Unit (DU)
+
+Required Properties:
+
+  - compatible: must be one of the following.
+- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
+- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
+- "renesas,du-r8a7791" for R8A7791 (R-Car M2) compatible DU
+
+  - reg: A list of base address and length of each memory resource, one for
+each entry in the reg-names property.
+  - reg-names: Name of the memory resources. The DU requires one memory
+resource for the DU core (named "du") and one memory resource for each
+LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
+index).
+
+  - interrupt-parent: phandle of the parent interrupt controller.
+  - interrupts: Interrupt specifiers for the DU interrupts.
+
+  - clocks: A list of phandles + clock-specifier pairs, one for each entry in
+the clock-names property.
+  - clock-names: Name of the clocks. This property is model-dependent.
+- R8A7779 uses a single functional clock. The clock doesn't need to be
+  named.
+- R8A7790 and R8A7791 use one functional clock per channel and one clock
+  per LVDS encoder. The functional clocks must be named "du.x" with "x"
+  being the channel numerical index. The LVDS clocks must be named
+  "lvds.x" with "x" being the LVDS encoder numerical index.
+
+Required nodes:
+
+The connections to the DU output video ports are modeled using the OF graph
+bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+The following table lists for each supported model the port number
+corresponding to each DU output.
+
+   Port 0  Port1   Port2
+-
+ R8A7779 (H1)  DPAD 0  DPAD 1  -
+ R8A7790 (H2)  DPADLVDS 0  LVDS 1
+ R8A7791 (M2)  DPADLVDS 0  -
+
+
+Example: R8A7790 (R-Car H2) DU
+
+   du: du at feb0 {
+   compatible = "renesas,du-r8a7790";
+   reg = <0 0xfeb0 0 0x7>,
+ <0 0xfeb9 0 0x1c>,
+ <0 0xfeb94000 0 0x1c>;
+   reg-names = "du", "lvds.0", "lvds.1";
+   interrupt-parent = <>;
+   interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
+<0 268 IRQ_TYPE_LEVEL_HIGH>,
+<0 269 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clks R8A7790_CLK_DU0>,
+<_clks R8A7790_CLK_DU1>,
+<_clks R8A7790_CLK_DU2>,
+<_clks R8A7790_CLK_LVDS0>,
+<_clks R8A7790_CLK_LVDS1>;
+   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   du_out_rgb: endpoint {
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   du_out_lvds0: endpoint {
+   };
+   };
+   port at 2 {
+   reg = <2>;
+   du_out_lvds1: endpoint {
+   };
+   };
+   };
+   };
-- 
1.8.5.5

[PATCH 05/16] video: Add THC63LVDM83D DT bindings documentation

[Laurent Pinchart]

The THC63LVDM83D is a video LVDS serializer described by an input port,
an output port, and an optional power down GPIO.

Cc: devicetree at vger.kernel.org
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/video/thine,thc63lvdm83d   | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/thine,thc63lvdm83d

diff --git a/Documentation/devicetree/bindings/video/thine,thc63lvdm83d 
b/Documentation/devicetree/bindings/video/thine,thc63lvdm83d
new file mode 100644
index 000..527e236
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/thine,thc63lvdm83d
@@ -0,0 +1,50 @@
+THine Electronics THC63LVDM83D LVDS serializer
+--
+
+The THC63LVDM83D is an LVDS serializer designed to support pixel data
+transmission between a host and a flat panel.
+
+Required properties:
+
+- compatible: Should be "thine,thc63lvdm83d"
+
+Optional properties:
+
+- pwdn-gpios: Power down control GPIO
+
+Required nodes:
+
+The THC63LVDM83D has two video ports. Their connections are modeled using the
+OFgraph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for CMOS/TTL input
+- Video port 1 for LVDS output
+
+
+Example
+---
+
+   lvds_enc: encoder at 0 {
+   compatible = "thine,thc63lvdm83d";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+
+   lvds_enc_in: endpoint at 0 {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   lvds_enc_out: endpoint at 0 {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.8.5.5

[PATCH 04/16] video: Add ADV7123 DT bindings documentation

[Laurent Pinchart]

The ADV7123 is a video DAC described by an input port, an output port,
and an optional power save GPIO.

Cc: devicetree at vger.kernel.org
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/video/adi,adv7123.txt  | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/adi,adv7123.txt

diff --git a/Documentation/devicetree/bindings/video/adi,adv7123.txt 
b/Documentation/devicetree/bindings/video/adi,adv7123.txt
new file mode 100644
index 000..a6b2b2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/adi,adv7123.txt
@@ -0,0 +1,50 @@
+Analog Device ADV7123 Video DAC
+---
+
+The ADV7123 is a digital-to-analog converter that outputs VGA signals from a
+parallel video input.
+
+Required properties:
+
+- compatible: Should be "adi,adv7123"
+
+Optional properties:
+
+- psave-gpios: Power save control GPIO
+
+Required nodes:
+
+The ADV7123 has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DPI input
+- Video port 1 for VGA output
+
+
+Example
+---
+
+   adv7123: encoder at 0 {
+   compatible = "adi,adv7123";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+
+   adv7123_in: endpoint at 0 {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   adv7123_out: endpoint at 0 {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+   };
+   };
-- 
1.8.5.5

[PATCH 03/16] video: Add DT binding documentation for VGA connector

[Laurent Pinchart]

The VGA connector is described by a single input port and an optional
DDC bus.

Cc: devicetree at vger.kernel.org
Cc: linux-fbdev at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/video/vga-connector.txt| 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/vga-connector.txt

diff --git a/Documentation/devicetree/bindings/video/vga-connector.txt 
b/Documentation/devicetree/bindings/video/vga-connector.txt
new file mode 100644
index 000..9a45ec1
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/vga-connector.txt
@@ -0,0 +1,28 @@
+VGA Connector
+==
+
+Required properties:
+- compatible: "vga-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC
+
+Required nodes:
+- Video port for VGA input
+
+Example
+---
+
+vga0: connector at 0 {
+   compatible = "vga-connector";
+   label = "vga";
+
+   ddc-i2c-bus = <>;
+
+   port {
+   vga_connector_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+};
-- 
1.8.5.5

[PATCH 02/16] devicetree: Add vendor prefix "thine" to vendor-prefixes.txt

[Laurent Pinchart]

Use the company name as vendor prefix.

Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 7292cfc..2b5648b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -134,6 +134,7 @@ st  STMicroelectronics
 steST-Ericsson
 stericsson ST-Ericsson
 synology   Synology, Inc.
+thine  THine Electronics, Inc.
 ti Texas Instruments
 tlmTrusted Logic Mobility
 toradexToradex AG
-- 
1.8.5.5

[PATCH 01/16] devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt

[Laurent Pinchart]

Mitsubishi Electric Corporation has a numerical stock ticker, use the
company name as vendor prefix.

Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac7269f..7292cfc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -83,6 +83,7 @@ maxim Maxim Integrated Products
 mediatek   MediaTek Inc.
 micrel Micrel Inc.
 microchip  Microchip Technology Inc.
+mitsubishi Mitsubishi Electric Corporation
 mosaixtech Mosaix Technologies, Inc.
 moxa   Moxa
 mplMPL AG
-- 
1.8.5.5

[PATCH 00/16] R-Car Display Unit DT bindings

[Laurent Pinchart]

Hello,

This patch series documents and implements DT bindings support for the R-Car
Display Unit (DU).

Unlike the previous attempt that tried to create a new model for composite
display devices and failed to get any real traction from DRM developers, the
approach taken here focuses on DT bindings without requiring core changes
outside of the DU driver.

Aside of the usual boring core properties (compatible, reg, interrupts and
clocks), the proposed bindings use the OF graph bindings to model connections
between the DU output video ports and the on-board and off-board components.
As such they do not depend on any particular implementation or implementation
philosophy.

The series starts by documenting DT bindings for the devices present on the
Marzen, Lager and Koelsch boards not already supported in the mainline kernel
(01/16 to 05/16) and for the DU (06/16). It then reworks the rcar_du platform
data to ease implementation of the DT bindings (07/16). The next step is to
implement support for the DU DT bindings in the R-Car DU DRM driver (08/16).
Finally the remaining patches add the DU DT nodes for all supported SoCs
(09/16 to 11/16), remove DU platform data from the DT-based board files (12/16
and 13/16) and describe the on-board devices connected to the DU outputs for
the Marzen, Lager and Koelsch boards (14/16 to 16/16).

Cc: devicetree at vger.kernel.org
Cc: linux-fbdev at vger.kernel.org

Laurent Pinchart (16):
  devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt
  devicetree: Add vendor prefix "thine" to vendor-prefixes.txt
  video: Add DT binding documentation for VGA connector
  video: Add ADV7123 DT bindings documentation
  video: Add THC63LVDM83D DT bindings documentation
  video: Add DT bindings for the R-Car Display Unit
  drm/rcar-du: Use struct videomode in platform data
  drm/rcar-du: Add OF support
  ARM: shmobile: r8a7779: Add DU node to device tree
  ARM: shmobile: r8a7790: Add DU node to device tree
  ARM: shmobile: r8a7791: Add DU node to device tree
  ARM: shmobile: lager-reference: Remove DU platform device
  ARM: shmobile: koelsch-reference: Remove DU platform device
  ARM: shmobile: marzen: Enable DU device in DT
  ARM: shmobile: lager: Enable DU device in DT
  ARM: shmobile: koelsch: Enable DU device in DT

 .../devicetree/bindings/vendor-prefixes.txt|   2 +
 .../devicetree/bindings/video/adi,adv7123.txt  |  50 +
 .../devicetree/bindings/video/renesas,du.txt   |  84 
 .../devicetree/bindings/video/thine,thc63lvdm83d   |  50 +
 .../devicetree/bindings/video/vga-connector.txt|  28 +++
 arch/arm/boot/dts/r8a7779-marzen.dts   | 106 ++
 arch/arm/boot/dts/r8a7779.dtsi |  24 +++
 arch/arm/boot/dts/r8a7790-lager.dts|  78 ++-
 arch/arm/boot/dts/r8a7790.dtsi |  39 
 arch/arm/boot/dts/r8a7791-koelsch.dts  |  43 +++-
 arch/arm/boot/dts/r8a7791.dtsi |  30 +++
 arch/arm/mach-shmobile/board-koelsch-reference.c   |  74 ---
 arch/arm/mach-shmobile/board-koelsch.c |  19 +-
 arch/arm/mach-shmobile/board-lager-reference.c |  81 
 arch/arm/mach-shmobile/board-lager.c   |  19 +-
 arch/arm/mach-shmobile/board-marzen.c  |  19 +-
 drivers/gpu/drm/rcar-du/Kconfig|   1 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 170 ---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   2 +
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |  11 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 231 +++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  43 ++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  |   3 +-
 include/linux/platform_data/rcar-du.h  |   4 +-
 25 files changed, 904 insertions(+), 310 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/adi,adv7123.txt
 create mode 100644 Documentation/devicetree/bindings/video/renesas,du.txt
 create mode 100644 Documentation/devicetree/bindings/video/thine,thc63lvdm83d
 create mode 100644 Documentation/devicetree/bindings/video/vga-connector.txt

-- 
Regards,

Laurent Pinchart

[pull] radeon drm-fixes-3.17

[Alex Deucher]

Hi Dave,

Just a few more radeon fixes for 3.17.

The following changes since commit a284e9d14e35b776807c3a40dd1ff1e05429d4a4:

  MAINTAINERS: Add entry for Renesas DRM drivers (2014-08-24 16:37:47 +1000)

are available in the git repository at:

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

for you to fetch changes up to 0bd252de78d406485c896508c13a8f7a78ee8353:

  radeon: Test for PCI root bus before assuming bus->self (2014-08-27 17:54:50 
-0400)


Alex Deucher (1):
  drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2)

Alex Williamson (1):
  radeon: Test for PCI root bus before assuming bus->self

Christian K?nig (1):
  drm/radeon: save/restore the PD addr on suspend/resume

 drivers/gpu/drm/radeon/cik.c| 26 +++---
 drivers/gpu/drm/radeon/ni.c |  9 -
 drivers/gpu/drm/radeon/r600.c   | 26 --
 drivers/gpu/drm/radeon/radeon.h |  2 ++
 drivers/gpu/drm/radeon/rv770.c  | 23 ---
 drivers/gpu/drm/radeon/si.c | 21 ++---
 6 files changed, 63 insertions(+), 44 deletions(-)

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #10 from Gabriel Mazetto  ---
Created attachment 105350
  --> https://bugs.freedesktop.org/attachment.cgi?id=105350=edit
Gabriel Mazetto's 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/20140827/f709beaf/attachment.html>

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #9 from Gabriel Mazetto  ---
I'm using oibaf's ppa with Ubuntu 14.04 and I can confirm that it's happening
as the OP reported. (Attaching my Xorg.log to help with the ticket)

-- 
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/20140827/de21afda/attachment.html>

[PATCH] radeon: Test for PCI root bus before assuming bus->self

[Alex Deucher]

On Wed, Aug 27, 2014 at 3:01 PM, Alex Williamson
 wrote:
> If we assign a Radeon device to a virtual machine, we can no longer
> assume a fixed hardware topology, like the GPU having a parent device.
> This patch simply adds a few pci_is_root_bus() tests to avoid passing
> a NULL pointer to PCI access functions, allowing the radeon driver to
> work in a QEMU 440FX machine with an assigned HD8570 on the emulated
> PCI root bus.
>
> Signed-off-by: Alex Williamson 

Added to my -fixes queue.  thanks!

Alex


> ---
>
>  drivers/gpu/drm/radeon/cik.c |6 +-
>  drivers/gpu/drm/radeon/si.c  |6 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 79a5a55..cc34308 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -9555,6 +9555,9 @@ static void cik_pcie_gen3_enable(struct radeon_device 
> *rdev)
> int ret, i;
> u16 tmp16;
>
> +   if (pci_is_root_bus(rdev->pdev->bus))
> +   return;
> +
> if (radeon_pcie_gen2 == 0)
> return;
>
> @@ -9781,7 +9784,8 @@ static void cik_program_aspm(struct radeon_device *rdev)
> if (orig != data)
> WREG32_PCIE_PORT(PCIE_LC_LINK_WIDTH_CNTL, 
> data);
>
> -   if (!disable_clkreq) {
> +   if (!disable_clkreq &&
> +   !pci_is_root_bus(rdev->pdev->bus)) {
> struct pci_dev *root = rdev->pdev->bus->self;
> u32 lnkcap;
>
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index a1274a3..ffb1d4e 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -7177,6 +7177,9 @@ static void si_pcie_gen3_enable(struct radeon_device 
> *rdev)
> int ret, i;
> u16 tmp16;
>
> +   if (pci_is_root_bus(rdev->pdev->bus))
> +   return;
> +
> if (radeon_pcie_gen2 == 0)
> return;
>
> @@ -7454,7 +7457,8 @@ static void si_program_aspm(struct radeon_device *rdev)
> if (orig != data)
> WREG32_PIF_PHY1(PB1_PIF_CNTL, data);
>
> -   if (!disable_clkreq) {
> +   if (!disable_clkreq &&
> +   !pci_is_root_bus(rdev->pdev->bus)) {
> struct pci_dev *root = rdev->pdev->bus->self;
> u32 lnkcap;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-next-3.18

[Alex Deucher]

Hi Dave,

More radeon changes for drm-next.  Highlights:
- UVD support for older asics
- Reset rework in preparation for Maarten's fence patches
I have a few more patches which depend on Christian's ttm changes,
I'll send them out separately once you've merged the ttm changes.
Just a heads up, I'll be on vacation next week.

The following changes since commit 484048db6b4890bc433aac7f5e32fdcf1b2b4786:

  Merge branch 'drm-next-3.18' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2014-08-26 09:05:14 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-next-3.18

for you to fetch changes up to 3c0363891c0fa5d17b683b758bff0d81fa6a9775:

  drm/radeon: drop doing resets in a work item (2014-08-27 17:42:13 -0400)


Alex Deucher (2):
  drm/radeon: add set_uvd_clocks callback for r6xx v4
  drm/radeon: 760G/780V/880V don't have UVD

Christian K?nig (12):
  drm/radeon: move the IB test after the AGP fallback
  drm/radeon: force UVD buffers into VRAM on RS[78]80 v2
  drm/radeon: properly init UVD MC bits on R600
  drm/radeon: add UVD support for older asics v4
  drm/radeon: implement UVD hw workarounds for R6xx v3
  drm/radeon: enable RB_ARB before resetting the VCPU
  drm/radeon: add UVD fw names for older asic
  drm/radeon: wake up all fences on manual reset
  drm/radeon: force fence completion only on problematic rings (v2)
  drm/radeon: handle lockup in delayed work, v5
  drm/radeon: drop RADEON_FENCE_SIGNALED_SEQ v2
  drm/radeon: drop doing resets in a work item

Maarten Lankhorst (2):
  drm/radeon: take exclusive_lock in read mode during ring tests, v5
  drm/radeon: add timeout argument to radeon_fence_wait_seq v2

 drivers/gpu/drm/radeon/cik.c|   6 +-
 drivers/gpu/drm/radeon/r600.c   | 132 
 drivers/gpu/drm/radeon/r600d.h  |  41 -
 drivers/gpu/drm/radeon/radeon.h |  10 +-
 drivers/gpu/drm/radeon/radeon_asic.c|  25 ++-
 drivers/gpu/drm/radeon/radeon_asic.h|   3 +
 drivers/gpu/drm/radeon/radeon_cs.c  |  16 +-
 drivers/gpu/drm/radeon/radeon_device.c  |  58 +++
 drivers/gpu/drm/radeon/radeon_display.c |   4 +-
 drivers/gpu/drm/radeon/radeon_fence.c   | 267 ++--
 drivers/gpu/drm/radeon/radeon_ib.c  |   1 +
 drivers/gpu/drm/radeon/radeon_irq_kms.c |  18 ---
 drivers/gpu/drm/radeon/radeon_uvd.c |  23 +++
 drivers/gpu/drm/radeon/uvd_v1_0.c   | 107 -
 drivers/gpu/drm/radeon/uvd_v2_2.c   |   4 +
 15 files changed, 531 insertions(+), 184 deletions(-)

[PATCH] ww-mutex: clarify help text for DEBUG_WW_MUTEX_SLOWPATH

[Maarten Lankhorst]

Acked-by: Maarten Lankhorst 

On 27-08-14 17:19, Rob Clark wrote:
> We really don't want distro's enabling this in their kernels.  Try and
> make that more clear.
> 
> Signed-off-by: Rob Clark 
> ---
>  lib/Kconfig.debug | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 07c2832..1b233fc 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -892,6 +892,10 @@ config DEBUG_WW_MUTEX_SLOWPATH
>the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
>will test all possible w/w mutex interface abuse with the
>exception of simply not acquiring all the required locks.
> +  Note that this feature can introduce significant overhead, so
> +  it really should not be enabled in a production or distro kernel,
> +  even a debug kernel.  If you are a driver writer, enable it.  If
> +  you are a distro, do not.
>  
>  config DEBUG_LOCK_ALLOC
>   bool "Lock debugging: detect incorrect freeing of live locks"
> 

[Bug 83201] CPU soft lockups in nouveau under load

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

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

Ted Percival  changed:

   What|Removed |Added

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

--- Comment #2 from Ted Percival  ---
I've seen this on my old 3.2 kernel too. My hardware sucks. Sorry about the
noise.

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

drm/i915/bdw: Provide the BDW specific HDMI buffer translation table

[Dan Carpenter]

Hello Damien Lespiau,

The patch a26aa8baee6c: "drm/i915/bdw: Provide the BDW specific HDMI
buffer translation table" from Aug 1, 2014, leads to the following
static checker warning:

drivers/gpu/drm/i915/intel_ddi.c:225 intel_prepare_ddi_buffers()
error: buffer overflow 'ddi_translations_hdmi' 24 <= 31

drivers/gpu/drm/i915/intel_ddi.c
   155  static void intel_prepare_ddi_buffers(struct drm_device *dev, enum port 
port)
   156  {
   157  struct drm_i915_private *dev_priv = dev->dev_private;
   158  u32 reg;
   159  int i, n_hdmi_entries, hdmi_800mV_0dB;
   160  int hdmi_level = 
dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
^^
The static checker thinks this is a number between 0-15.  I didn't check
if that was correct.

   161  const u32 *ddi_translations_fdi;

[ snip ]

   186  ddi_translations_hdmi = bdw_ddi_translations_hdmi;
   187  n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
^^
limit is the size of the array.

   188  hdmi_800mV_0dB = 7;
   189  }
   190  
   191  switch (port) {
   192  case PORT_A:
   193  ddi_translations = ddi_translations_edp;
   194  break;
   195  case PORT_B:
   196  case PORT_C:
   197  ddi_translations = ddi_translations_dp;
   198  break;
   199  case PORT_D:
   200  if (intel_dp_is_edp(dev, PORT_D))
   201  ddi_translations = ddi_translations_edp;
   202  else
   203  ddi_translations = ddi_translations_dp;
   204  break;
   205  case PORT_E:
   206  ddi_translations = ddi_translations_fdi;
   207  break;
   208  default:
   209  BUG();
   210  }
   211  
   212  for (i = 0, reg = DDI_BUF_TRANS(port);
   213   i < ARRAY_SIZE(hsw_ddi_translations_fdi); i++) {
   214  I915_WRITE(reg, ddi_translations[i]);
   215  reg += 4;
   216  }
   217  
   218  /* Choose a good default if VBT is badly populated */
   219  if (hdmi_level == HDMI_LEVEL_SHIFT_UNKNOWN ||
   220  hdmi_level >= n_hdmi_entries)
  ^^
We cap it at the size of the array which is either 20 or 24.  The static
checker thinks it's already capped at 15 so this is not a problem.

Should this be n_hdmi_entries / 2 or something?  Maybe a - 1 in there?

   221  hdmi_level = hdmi_800mV_0dB;
   222  
   223  /* Entry 9 is for HDMI: */
   224  for (i = 0; i < 2; i++) {
   225  I915_WRITE(reg, ddi_translations_hdmi[hdmi_level * 2 + 
i]);
  ^^
The static checker thinks "15 * 2 + 1 = 31" so we are beyond the size
of the largest array (either 20 or 24).

   226  reg += 4;
   227  }
   228  }

regards,
dan carpenter

[PATCH] drm/cma: remove to allocate shmfs backing store

[Joonyoung Shim]

Initialize GEM object using drm_gem_private_object_init instead of
drm_gem_object_init. It doesn't need to have shmfs backing store because
the CMA GEM object uses CMA area.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index e467e67..a65cbd0 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -52,7 +52,7 @@ __drm_gem_cma_create(struct drm_device *drm, unsigned int 
size)

gem_obj = _obj->base;

-   ret = drm_gem_object_init(drm, gem_obj, size);
+   ret = drm_gem_private_object_init(drm, gem_obj, size);
if (ret)
goto error;

-- 
1.9.1

[PATCH 9/9] drm/radeon: drop doing resets in a work item

[Christian König]

From: Christian K?nig 

Blocking completely innocent processes with a GPU reset is
a pretty bad idea. Just set needs_reset and let the next
command submission or fence wait do the job.

Signed-off-by: Christian K?nig 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/cik.c|  6 --
 drivers/gpu/drm/radeon/radeon.h |  1 -
 drivers/gpu/drm/radeon/radeon_device.c  |  7 ---
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 18 --
 4 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index db11446..c2eca22 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8237,8 +8237,10 @@ restart_ih:
}
if (queue_hotplug)
schedule_work(>hotplug_work);
-   if (queue_reset)
-   schedule_work(>reset_work);
+   if (queue_reset) {
+   rdev->needs_reset = true;
+   wake_up_all(>fence_queue);
+   }
if (queue_thermal)
schedule_work(>pm.dpm.thermal.work);
rdev->ih.rptr = rptr;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ca74b72..fa66f65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2346,7 +2346,6 @@ struct radeon_device {
struct radeon_mec mec;
struct work_struct hotplug_work;
struct work_struct audio_work;
-   struct work_struct reset_work;
int num_crtc; /* number of crtcs */
struct mutex dc_hw_i2c_mutex; /* display controller hw i2c mutex */
bool has_uvd;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 9f66637..d30f1cc 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1673,9 +1673,6 @@ int radeon_gpu_reset(struct radeon_device *rdev)
return 0;
}

-   rdev->in_reset = true;
-   rdev->needs_reset = false;
-
radeon_save_bios_scratch_regs(rdev);
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(>mman.bdev);
@@ -1738,6 +1735,10 @@ int radeon_gpu_reset(struct radeon_device *rdev)
radeon_hpd_init(rdev);

ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
+
+   rdev->in_reset = true;
+   rdev->needs_reset = false;
+
downgrade_write(>exclusive_lock);

drm_helper_resume_force_mode(rdev->ddev);
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 16807af..f0bff4b 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -88,23 +88,6 @@ static void radeon_hotplug_work_func(struct work_struct 
*work)
 }

 /**
- * radeon_irq_reset_work_func - execute gpu reset
- *
- * @work: work struct
- *
- * Execute scheduled gpu reset (cayman+).
- * This function is called when the irq handler
- * thinks we need a gpu reset.
- */
-static void radeon_irq_reset_work_func(struct work_struct *work)
-{
-   struct radeon_device *rdev = container_of(work, struct radeon_device,
- reset_work);
-
-   radeon_gpu_reset(rdev);
-}
-
-/**
  * radeon_driver_irq_preinstall_kms - drm irq preinstall callback
  *
  * @dev: drm dev pointer
@@ -284,7 +267,6 @@ int radeon_irq_kms_init(struct radeon_device *rdev)

INIT_WORK(>hotplug_work, radeon_hotplug_work_func);
INIT_WORK(>audio_work, r600_audio_update_hdmi);
-   INIT_WORK(>reset_work, radeon_irq_reset_work_func);

rdev->irq.installed = true;
r = drm_irq_install(rdev->ddev, rdev->ddev->pdev->irq);
-- 
1.9.1

[PATCH 8/9] drm/radeon: drop RADEON_FENCE_SIGNALED_SEQ v2

[Christian König]

From: Christian K?nig 

It's causing issues with VMID handling and comparing the
fence value two times actually doesn't make handling faster.

v2: rebased on reset changes

Signed-off-by: Christian K?nig 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon.h   |  3 ---
 drivers/gpu/drm/radeon/radeon_fence.c | 18 ++
 2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fce8b32..ca74b72 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -119,9 +119,6 @@ extern int radeon_use_pflipirq;
 #define RADEONFB_CONN_LIMIT4
 #define RADEON_BIOS_NUM_SCRATCH8

-/* fence seq are set to this number when signaled */
-#define RADEON_FENCE_SIGNALED_SEQ  0LL
-
 /* internal ring indices */
 /* r1xx+ has gfx CP ring */
 #define RADEON_RING_TYPE_GFX_INDEX 0
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index a54bfd6..ecdba3a 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -328,16 +328,10 @@ static bool radeon_fence_seq_signaled(struct 
radeon_device *rdev,
  */
 bool radeon_fence_signaled(struct radeon_fence *fence)
 {
-   if (!fence) {
-   return true;
-   }
-   if (fence->seq == RADEON_FENCE_SIGNALED_SEQ) {
+   if (!fence)
return true;
-   }
-   if (radeon_fence_seq_signaled(fence->rdev, fence->seq, fence->ring)) {
-   fence->seq = RADEON_FENCE_SIGNALED_SEQ;
+   if (radeon_fence_seq_signaled(fence->rdev, fence->seq, fence->ring))
return true;
-   }
return false;
 }

@@ -445,15 +439,11 @@ int radeon_fence_wait(struct radeon_fence *fence, bool 
intr)
}

seq[fence->ring] = fence->seq;
-   if (seq[fence->ring] == RADEON_FENCE_SIGNALED_SEQ)
-   return 0;
-
r = radeon_fence_wait_seq_timeout(fence->rdev, seq, intr, 
MAX_SCHEDULE_TIMEOUT);
if (r < 0) {
return r;
}

-   fence->seq = RADEON_FENCE_SIGNALED_SEQ;
return 0;
 }

@@ -487,10 +477,6 @@ int radeon_fence_wait_any(struct radeon_device *rdev,

seq[i] = fences[i]->seq;
++num_rings;
-
-   /* test if something was allready signaled */
-   if (seq[i] == RADEON_FENCE_SIGNALED_SEQ)
-   return 0;
}

/* nothing to wait for ? */
-- 
1.9.1

[PATCH 7/9] drm/radeon: add timeout argument to radeon_fence_wait_seq v2

[Christian König]

From: Maarten Lankhorst 

This makes it possible to wait for a specific amount of time,
rather than wait until infinity.

v2 (chk): rebased on other changes

Signed-off-by: Maarten Lankhorst 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_fence.c | 48 ---
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index ac15f34..a54bfd6 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -364,28 +364,31 @@ static bool radeon_fence_any_seq_signaled(struct 
radeon_device *rdev, u64 *seq)
 }

 /**
- * radeon_fence_wait_seq - wait for a specific sequence numbers
+ * radeon_fence_wait_seq_timeout - wait for a specific sequence numbers
  *
  * @rdev: radeon device pointer
  * @target_seq: sequence number(s) we want to wait for
  * @intr: use interruptable sleep
+ * @timeout: maximum time to wait, or MAX_SCHEDULE_TIMEOUT for infinite wait
  *
  * Wait for the requested sequence number(s) to be written by any ring
  * (all asics).  Sequnce number array is indexed by ring id.
  * @intr selects whether to use interruptable (true) or non-interruptable
  * (false) sleep when waiting for the sequence number.  Helper function
  * for radeon_fence_wait_*().
- * Returns 0 if the sequence number has passed, error for all other cases.
+ * Returns remaining time if the sequence number has passed, 0 when
+ * the wait timeout, or an error for all other cases.
  * -EDEADLK is returned when a GPU lockup has been detected.
  */
-static int radeon_fence_wait_seq(struct radeon_device *rdev, u64 *target_seq,
-bool intr)
+static long radeon_fence_wait_seq_timeout(struct radeon_device *rdev,
+ u64 *target_seq, bool intr,
+ long timeout)
 {
long r;
int i;

if (radeon_fence_any_seq_signaled(rdev, target_seq))
-   return 0;
+   return timeout;

/* enable IRQs and tracing */
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
@@ -399,11 +402,11 @@ static int radeon_fence_wait_seq(struct radeon_device 
*rdev, u64 *target_seq,
if (intr) {
r = wait_event_interruptible_timeout(rdev->fence_queue, (
radeon_fence_any_seq_signaled(rdev, target_seq)
-|| rdev->needs_reset), MAX_SCHEDULE_TIMEOUT);
+|| rdev->needs_reset), timeout);
} else {
r = wait_event_timeout(rdev->fence_queue, (
radeon_fence_any_seq_signaled(rdev, target_seq)
-|| rdev->needs_reset), MAX_SCHEDULE_TIMEOUT);
+|| rdev->needs_reset), timeout);
}

if (rdev->needs_reset)
@@ -417,14 +420,14 @@ static int radeon_fence_wait_seq(struct radeon_device 
*rdev, u64 *target_seq,
trace_radeon_fence_wait_end(rdev->ddev, i, target_seq[i]);
}

-   return r < 0 ? r : 0;
+   return r;
 }

 /**
  * radeon_fence_wait - wait for a fence to signal
  *
  * @fence: radeon fence object
- * @intr: use interruptable sleep
+ * @intr: use interruptible sleep
  *
  * Wait for the requested fence to signal (all asics).
  * @intr selects whether to use interruptable (true) or non-interruptable
@@ -434,7 +437,7 @@ static int radeon_fence_wait_seq(struct radeon_device 
*rdev, u64 *target_seq,
 int radeon_fence_wait(struct radeon_fence *fence, bool intr)
 {
uint64_t seq[RADEON_NUM_RINGS] = {};
-   int r;
+   long r;

if (fence == NULL) {
WARN(1, "Querying an invalid fence : %p !\n", fence);
@@ -445,9 +448,10 @@ int radeon_fence_wait(struct radeon_fence *fence, bool 
intr)
if (seq[fence->ring] == RADEON_FENCE_SIGNALED_SEQ)
return 0;

-   r = radeon_fence_wait_seq(fence->rdev, seq, intr);
-   if (r)
+   r = radeon_fence_wait_seq_timeout(fence->rdev, seq, intr, 
MAX_SCHEDULE_TIMEOUT);
+   if (r < 0) {
return r;
+   }

fence->seq = RADEON_FENCE_SIGNALED_SEQ;
return 0;
@@ -472,7 +476,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev,
 {
uint64_t seq[RADEON_NUM_RINGS];
unsigned i, num_rings = 0;
-   int r;
+   long r;

for (i = 0; i < RADEON_NUM_RINGS; ++i) {
seq[i] = 0;
@@ -493,8 +497,8 @@ int radeon_fence_wait_any(struct radeon_device *rdev,
if (num_rings == 0)
return -ENOENT;

-   r = radeon_fence_wait_seq(rdev, seq, intr);
-   if (r) {
+   r = radeon_fence_wait_seq_timeout(rdev, seq, intr, 
MAX_SCHEDULE_TIMEOUT);
+   if (r < 0) {
return r;
}
return 0;
@@ -513,6 +517,7 @@ int radeon_fence_wait_any(struct radeon_device *rdev,
 int radeon_fence_wait_next(struct 

[PATCH 6/9] drm/radeon: handle lockup in delayed work, v5

[Christian König]

From: Christian K?nig 

v5 (chk): complete rework, start when the first fence is emitted,
  stop when the last fence is signalled, make it work
  correctly with GPU resets, cleanup radeon_fence_wait_seq

Signed-off-by: Maarten Lankhorst 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h   |   2 +
 drivers/gpu/drm/radeon/radeon_fence.c | 200 +-
 2 files changed, 124 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index f528ae8..fce8b32 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -349,6 +349,7 @@ extern void evergreen_tiling_fields(unsigned tiling_flags, 
unsigned *bankw,
  * Fences.
  */
 struct radeon_fence_driver {
+   struct radeon_device*rdev;
uint32_tscratch_reg;
uint64_tgpu_addr;
volatile uint32_t   *cpu_addr;
@@ -356,6 +357,7 @@ struct radeon_fence_driver {
uint64_tsync_seq[RADEON_NUM_RINGS];
atomic64_t  last_seq;
boolinitialized;
+   struct delayed_work lockup_work;
 };

 struct radeon_fence {
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index e8a28e7..ac15f34 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -98,6 +98,25 @@ static u32 radeon_fence_read(struct radeon_device *rdev, int 
ring)
 }

 /**
+ * radeon_fence_schedule_check - schedule lockup check
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index we should work with
+ *
+ * Queues a delayed work item to check for lockups.
+ */
+static void radeon_fence_schedule_check(struct radeon_device *rdev, int ring)
+{
+   /*
+* Do not reset the timer here with mod_delayed_work,
+* this can livelock in an interaction with TTM delayed destroy.
+*/
+   queue_delayed_work(system_power_efficient_wq,
+  >fence_drv[ring].lockup_work,
+  RADEON_FENCE_JIFFIES_TIMEOUT);
+}
+
+/**
  * radeon_fence_emit - emit a fence on the requested ring
  *
  * @rdev: radeon_device pointer
@@ -122,19 +141,21 @@ int radeon_fence_emit(struct radeon_device *rdev,
(*fence)->ring = ring;
radeon_fence_ring_emit(rdev, ring, *fence);
trace_radeon_fence_emit(rdev->ddev, ring, (*fence)->seq);
+   radeon_fence_schedule_check(rdev, ring);
return 0;
 }

 /**
- * radeon_fence_process - process a fence
+ * radeon_fence_activity - check for fence activity
  *
  * @rdev: radeon_device pointer
  * @ring: ring index the fence is associated with
  *
- * Checks the current fence value and wakes the fence queue
- * if the sequence number has increased (all asics).
+ * Checks the current fence value and calculates the last
+ * signalled fence value. Returns true if activity occured
+ * on the ring, and the fence_queue should be waken up.
  */
-void radeon_fence_process(struct radeon_device *rdev, int ring)
+static bool radeon_fence_activity(struct radeon_device *rdev, int ring)
 {
uint64_t seq, last_seq, last_emitted;
unsigned count_loop = 0;
@@ -190,7 +211,67 @@ void radeon_fence_process(struct radeon_device *rdev, int 
ring)
}
} while (atomic64_xchg(>fence_drv[ring].last_seq, seq) > seq);

-   if (wake)
+   if (seq < last_emitted)
+   radeon_fence_schedule_check(rdev, ring);
+
+   return wake;
+}
+
+/**
+ * radeon_fence_check_lockup - check for hardware lockup
+ *
+ * @work: delayed work item
+ *
+ * Checks for fence activity and if there is none probe
+ * the hardware if a lockup occured.
+ */
+static void radeon_fence_check_lockup(struct work_struct *work)
+{
+   struct radeon_fence_driver *fence_drv;
+   struct radeon_device *rdev;
+   int ring;
+
+   fence_drv = container_of(work, struct radeon_fence_driver,
+lockup_work.work);
+   rdev = fence_drv->rdev;
+   ring = fence_drv - >fence_drv[0];
+
+   if (!down_read_trylock(>exclusive_lock)) {
+   /* just reschedule the check if a reset is going on */
+   radeon_fence_schedule_check(rdev, ring);
+   return;
+   }
+
+   if (radeon_fence_activity(rdev, ring))
+   wake_up_all(>fence_queue);
+
+   else if (radeon_ring_is_lockup(rdev, ring, >ring[ring])) {
+
+   /* good news we believe it's a lockup */
+   dev_warn(rdev->dev, "GPU lockup (current fence id "
+"0x%016llx last fence id 0x%016llx on ring %d)\n",
+(uint64_t)atomic64_read(_drv->last_seq),
+fence_drv->sync_seq[ring], ring);
+
+   /* remember that we need an reset */
+   

[PATCH 5/9] drm/radeon: take exclusive_lock in read mode during ring tests, v4

[Christian König]

From: Maarten Lankhorst 

This is needed for the next commit, because the lockup detection
will need the read lock to run.

v4 (chk): split out forced fence completion, remove unrelated changes,
  add and handle in_reset flag

Signed-off-by: Maarten Lankhorst 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h |  2 +-
 drivers/gpu/drm/radeon/radeon_cs.c  |  7 ++
 drivers/gpu/drm/radeon/radeon_device.c  | 39 ++---
 drivers/gpu/drm/radeon/radeon_display.c |  4 +++-
 4 files changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 821bf51..f528ae8 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2326,7 +2326,7 @@ struct radeon_device {
boolneed_dma32;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
-   boolneeds_reset;
+   boolneeds_reset, in_reset;
struct radeon_surface_reg surface_regs[RADEON_GEM_MAX_SURFACES];
const struct firmware *me_fw;   /* all family ME firmware */
const struct firmware *pfp_fw;  /* r6/700 PFP firmware */
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index c91d8c8..06cbc9a 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -652,6 +652,13 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
up_read(>exclusive_lock);
return -EBUSY;
}
+   if (rdev->in_reset) {
+   up_read(>exclusive_lock);
+   r = radeon_gpu_reset(rdev);
+   if (!r)
+   r = -EAGAIN;
+   return r;
+   }
/* initialize parser */
memset(, 0, sizeof(struct radeon_cs_parser));
parser.filp = filp;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index bca7d45..9f66637 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1673,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev)
return 0;
}

+   rdev->in_reset = true;
rdev->needs_reset = false;

radeon_save_bios_scratch_regs(rdev);
@@ -1691,7 +1692,6 @@ int radeon_gpu_reset(struct radeon_device *rdev)
}
}

-retry:
r = radeon_asic_reset(rdev);
if (!r) {
dev_info(rdev->dev, "GPU reset succeeded, trying to resume\n");
@@ -1700,26 +1700,12 @@ retry:

radeon_restore_bios_scratch_regs(rdev);

-   if (!r) {
-   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   if (!r && ring_data[i]) {
radeon_ring_restore(rdev, >ring[i],
ring_sizes[i], ring_data[i]);
-   ring_sizes[i] = 0;
-   ring_data[i] = NULL;
-   }
-
-   r = radeon_ib_ring_tests(rdev);
-   if (r) {
-   dev_err(rdev->dev, "ib ring test failed (%d).\n", r);
-   if (saved) {
-   saved = false;
-   radeon_suspend(rdev);
-   goto retry;
-   }
-   }
-   } else {
-   radeon_fence_driver_force_completion(rdev);
-   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   } else {
+   radeon_fence_driver_force_completion(rdev, i);
kfree(ring_data[i]);
}
}
@@ -1751,19 +1737,28 @@ retry:
/* reset hpd state */
radeon_hpd_init(rdev);

+   ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
+   downgrade_write(>exclusive_lock);
+
drm_helper_resume_force_mode(rdev->ddev);

/* set the power state here in case we are a PX system or headless */
if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled)
radeon_pm_compute_clocks(rdev);

-   ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
-   if (r) {
+   if (!r) {
+   r = radeon_ib_ring_tests(rdev);
+   if (r && saved)
+   r = -EAGAIN;
+   } else {
/* bad news, how to tell it to userspace ? */
dev_info(rdev->dev, "GPU reset failed\n");
}

-   up_write(>exclusive_lock);
+   rdev->needs_reset = r == -EAGAIN;
+   rdev->in_reset = false;
+
+   up_read(>exclusive_lock);
return r;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 

[PATCH 4/9] drm/radeon: force fence completion only on problematic rings

[Christian König]

From: Christian K?nig 

Instead of resetting all fence numbers, only reset the
number of the problematic ring. Split out from a patch
from Maarten Lankhorst 

Signed-off-by: Christian K?nig 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon.h|  2 +-
 drivers/gpu/drm/radeon/radeon_device.c |  6 +-
 drivers/gpu/drm/radeon/radeon_fence.c  | 12 
 drivers/gpu/drm/radeon/radeon_ib.c |  1 +
 4 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 8810df3..821bf51 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -370,7 +370,7 @@ struct radeon_fence {
 int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
 int radeon_fence_driver_init(struct radeon_device *rdev);
 void radeon_fence_driver_fini(struct radeon_device *rdev);
-void radeon_fence_driver_force_completion(struct radeon_device *rdev);
+void radeon_fence_driver_force_completion(struct radeon_device *rdev, int 
ring);
 int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence **fence, 
int ring);
 void radeon_fence_process(struct radeon_device *rdev, int ring);
 bool radeon_fence_signaled(struct radeon_fence *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index b6aee40..bca7d45 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1488,7 +1488,6 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
suspend, bool fbcon)
struct drm_crtc *crtc;
struct drm_connector *connector;
int i, r;
-   bool force_completion = false;

if (dev == NULL || dev->dev_private == NULL) {
return -ENODEV;
@@ -1532,12 +1531,9 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
suspend, bool fbcon)
r = radeon_fence_wait_empty(rdev, i);
if (r) {
/* delay GPU reset to resume */
-   force_completion = true;
+   radeon_fence_driver_force_completion(rdev, i);
}
}
-   if (force_completion) {
-   radeon_fence_driver_force_completion(rdev);
-   }

radeon_save_bios_scratch_regs(rdev);

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 5bd837a..e8a28e7 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -758,7 +758,7 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
r = radeon_fence_wait_empty(rdev, ring);
if (r) {
/* no need to trigger GPU reset as we are unloading */
-   radeon_fence_driver_force_completion(rdev);
+   radeon_fence_driver_force_completion(rdev, ring);
}
wake_up_all(>fence_queue);
radeon_scratch_free(rdev, rdev->fence_drv[ring].scratch_reg);
@@ -771,19 +771,15 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
  * radeon_fence_driver_force_completion - force all fence waiter to complete
  *
  * @rdev: radeon device pointer
+ * @ring: the ring to complete
  *
  * In case of GPU reset failure make sure no process keep waiting on fence
  * that will never complete.
  */
-void radeon_fence_driver_force_completion(struct radeon_device *rdev)
+void radeon_fence_driver_force_completion(struct radeon_device *rdev, int ring)
 {
-   int ring;
-
-   for (ring = 0; ring < RADEON_NUM_RINGS; ring++) {
-   if (!rdev->fence_drv[ring].initialized)
-   continue;
+   if (rdev->fence_drv[ring].initialized)
radeon_fence_write(rdev, rdev->fence_drv[ring].sync_seq[ring], 
ring);
-   }
 }


diff --git a/drivers/gpu/drm/radeon/radeon_ib.c 
b/drivers/gpu/drm/radeon/radeon_ib.c
index 65b0c21..bc77e01 100644
--- a/drivers/gpu/drm/radeon/radeon_ib.c
+++ b/drivers/gpu/drm/radeon/radeon_ib.c
@@ -268,6 +268,7 @@ int radeon_ib_ring_tests(struct radeon_device *rdev)

r = radeon_ib_test(rdev, i, ring);
if (r) {
+   radeon_fence_driver_force_completion(rdev, i);
ring->ready = false;
rdev->needs_reset = false;

-- 
1.9.1

[PATCH 3/9] drm/radeon: fix display handling in radeon_gpu_reset

[Christian König]

From: Alex Deucher 

If the display hw was reset or a hard reset was used,
we need to re-init some of the common display hardware as well.

Signed-off-by: Alex Deucher 
Reviewed-by: Christian K?nig 
Reviewed-by: Maarten Lankhorst 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_device.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index d2ff12e..b6aee40 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1683,6 +1683,7 @@ int radeon_gpu_reset(struct radeon_device *rdev)
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(>mman.bdev);
radeon_suspend(rdev);
+   radeon_hpd_fini(rdev);

for (i = 0; i < RADEON_NUM_RINGS; ++i) {
ring_sizes[i] = radeon_ring_backup(rdev, >ring[i],
@@ -1739,6 +1740,21 @@ retry:
radeon_pm_resume(rdev);
}

+   /* init dig PHYs, disp eng pll */
+   if (rdev->is_atom_bios) {
+   radeon_atom_encoder_init(rdev);
+   radeon_atom_disp_eng_pll_init(rdev);
+   /* turn on the BL */
+   if (rdev->mode_info.bl_encoder) {
+   u8 bl_level = radeon_get_backlight_level(rdev,
+
rdev->mode_info.bl_encoder);
+   radeon_set_backlight_level(rdev, 
rdev->mode_info.bl_encoder,
+  bl_level);
+   }
+   }
+   /* reset hpd state */
+   radeon_hpd_init(rdev);
+
drm_helper_resume_force_mode(rdev->ddev);

/* set the power state here in case we are a PX system or headless */
-- 
1.9.1

[PATCH 2/9] drm/radeon: fix pm handling in radeon_gpu_reset

[Christian König]

From: Alex Deucher 

pm_suspend is handled in the radeon_suspend callbacks.
pm_resume has special handling depending on whether
dpm or legacy pm is enabled.  Change radeon_gpu_reset
to mirror the behavior in the suspend and resume
paths.

Signed-off-by: Alex Deucher 
Reviewed-by: Christian K?nig 
Reviewed-by: Maarten Lankhorst 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_device.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 152181d..d2ff12e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1682,7 +1682,6 @@ int radeon_gpu_reset(struct radeon_device *rdev)
radeon_save_bios_scratch_regs(rdev);
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(>mman.bdev);
-   radeon_pm_suspend(rdev);
radeon_suspend(rdev);

for (i = 0; i < RADEON_NUM_RINGS; ++i) {
@@ -1728,9 +1727,24 @@ retry:
}
}

-   radeon_pm_resume(rdev);
+   if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled) {
+   /* do dpm late init */
+   r = radeon_pm_late_init(rdev);
+   if (r) {
+   rdev->pm.dpm_enabled = false;
+   DRM_ERROR("radeon_pm_late_init failed, disabling 
dpm\n");
+   }
+   } else {
+   /* resume old pm late */
+   radeon_pm_resume(rdev);
+   }
+
drm_helper_resume_force_mode(rdev->ddev);

+   /* set the power state here in case we are a PX system or headless */
+   if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled)
+   radeon_pm_compute_clocks(rdev);
+
ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
if (r) {
/* bad news, how to tell it to userspace ? */
-- 
1.9.1

[PATCH 1/9] drm/radeon: wake up all fences on manual reset

[Christian König]

From: Christian K?nig 

Wake up all fences when we manually trigger a reset.

Signed-off-by: Christian K?nig 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon_fence.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 9137870..5bd837a 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -833,6 +833,7 @@ static int radeon_debugfs_gpu_reset(struct seq_file *m, 
void *data)
down_read(>exclusive_lock);
seq_printf(m, "%d\n", rdev->needs_reset);
rdev->needs_reset = true;
+   wake_up_all(>fence_queue);
up_read(>exclusive_lock);

return 0;
-- 
1.9.1

drm/radeon: reset patches and common fence preparation

[Christian König]

Hey Alex,

please pull the following patches into drm-next-3.18. Compared to the last 
version I only fixed the typos Michel noted.

@Maarten: Can you rebase your branch on top of those? I want to take a look at 
the remaining changes as well and also test that branch a bit.

Thanks,
Christian.

[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

[Thierry Reding]

On Wed, Aug 27, 2014 at 08:47:54AM +0100, Damien Lespiau wrote:
> On Tue, Aug 26, 2014 at 01:28:19PM +0200, Thierry Reding wrote:
> > On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jindal at intel.com wrote:
> > > From: Sonika Jindal 
> > > 
> > > Adding new defines, older one will be removed in the last patch in the 
> > > series.
> > > This is to rename the defines to have levels instead of values for vswing 
> > > and
> > > pre-emph levels as the values may differ in other scenarios like low 
> > > vswing of
> > > eDP1.4 where the values are different.
> > > 
> > > Done using following cocci patch for each define:
> > > @@
> > > @@
> > > 
> > >  # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
> > > + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> > 
> > Could this perhaps be simply:
> > 
> > #define DP_TRAIN_VOLTAGE_SWING(x) ((x) << 0)
> > 
> > As it is, there's no information about the value within the symbolic
> > name anyway, so _LEVEL_* really isn't that useful and keeping several
> > macros for each value seems isn't either.
> 
> The _LEVEL_ part is quite important IMHO, that's what changes between those
> different defines, controlling a level shifter, somewhere.
> 
> So we're left with
> 
>   #define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> 
> Vs
> 
>   #define DP_TRAIN_VOLTAGE_SWING_LEVEL(x) ((x) << 0)
> 
> The second variant doesn't really bring much more clarity? Can we just
> go with the first?

I think the parameterized version is more convenient, especially if you
want to use that during training sequences and iterate over the levels.

But I don't feel too strongly about it, so either way is fine with me.

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

[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

[Thierry Reding]

On Wed, Aug 27, 2014 at 08:51:35AM +0100, Damien Lespiau wrote:
> On Wed, Aug 27, 2014 at 08:47:54AM +0100, Damien Lespiau wrote:
> > > An alternative would be to provide a second set of defines for eDP 1.4
> > > where the name implies the meaning and then use them as appropriate.
> > 
> > We went through the idea as well and:
> > 
> > I actually think the nominal voltage swing and pre-emph values are quite
> > misleading. The hw is free to implement a wildly different set of voltage
> > swing/pre-emph values.
> > 
> > eDP 1.4 changes those nominal values as described in the cover letter,
> > but there again, the actual hw implementation can choose fairly
> > different values than the nominal ones.
> > 
> > Also, the DP 1.2 spec documents this field as (see address 103h):
> > 
> > TRAINING_LANE0_SET : Link Training Control_Lane0
> >   Bits 1:0 = VOLTAGE SWING SET
> > 00 ?Voltage swing level 0
> > 01 ?Voltage swing level 1
> > 10 ?Voltage swing level 2
> > 11 ?Voltage swing level 3
> > 
> > So, in that sense, we're closer to the latest spec with those LEVEL_X
> > defines.
> 
> I forgot to mention here that if we have separate defines for eDP 1.4,
> then we lose the possibility to share training code with big DP and eDP
> 1.3, not something desirable.

Yeah, I'd like to see the training sequences extracted into common
helpers.

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

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #8 from smoki  ---

 Not usung Unity or Ubuntu, but i also have these ussues on Kabini, problem
started with
http://cgit.freedesktop.org/mesa/mesa/commit/?id=bbbe3b65adee44c164532d7afb4ff8fd8f88bbf4

-- 
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/20140827/0bc8fffd/attachment.html>

[PATCH] drm: Test for PCI root bus to avoid NULL pointer dereference

[Alex Deucher]

On Wed, Aug 27, 2014 at 2:57 PM, Alex Williamson
 wrote:
> If we have a GPU on the PCI root bus that calls
> drm_pcie_get_speed_cap_mask() we end up with a NULL pointer
> dereference since pdev->bus->self is NULL.  We already protect
> against callers passing non-PCI devices, so let's also catch this
> case and return -EINVAL.
>
> Root complex graphics are not terribly likely outside of IGD, but
> when we assign a standard plugin GPU to a virtual machine, our
> assumption that we have a parent device quickly becomes invalid.
>
> Signed-off-by: Alex Williamson 

Reviewed-by: Alex Deucher 

> ---
>
>  drivers/gpu/drm/drm_pci.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 020cfd9..411e806 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -390,7 +390,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, 
> u32 *mask)
> u32 lnkcap, lnkcap2;
>
> *mask = 0;
> -   if (!dev->pdev)
> +   if (!dev->pdev || pci_is_root_bus(dev->pdev->bus))
> return -EINVAL;
>
> root = dev->pdev->bus->self;
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/ast: Improve mode matching

[Egbert Eich]

Hi YC,

you should probably be a bit more verbose in your changelog entry.

As subject something like:
 Add reduced blanking modes for wide screen mode

As text:
 Add reduced blanking modes, improve mode matching to
 identify these modes by their sync polarities.

Y.C. Chen writes:
 > From: "Y.C. Chen" 
 > 
 > Signed-off-by: Egbert Eich 
 > Signed-off-by: Y.C. Chen 
 > 
 > v2: Add two pass mode selection, first try to match sync polarities and 
 > refresh
 > if this fails, try matching refresh only. Suggested by: Egbert Eich 
 > 
 > @@ -99,6 +104,8 @@ static struct ast_vbios_dclk_info dclk_table[] = {
 >  {0x25, 0x65, 0x80}, /* 16: 
 > VCLK88.75*/
 >  {0x77, 0x58, 0x80}, /* 17: VCLK119  
 > */
 >  {0x32, 0x67, 0x80}, /* 18: VCLK85_5 
 > */
 > +{0x6a, 0x6d, 0x80}, /* 19: 
 > VCLK97_75*/

Weren't you going to put this line into a separate patch 
- as it fixes a 'run off the end of the list' bug?

 > +{0x3b, 0x2c, 0x81}, /* 1A: 
 > VCLK118_25   */
 >  };
 >  
 >  static struct ast_vbios_stdtable vbios_stdtable[] = {
 > @@ -245,8 +252,10 @@ static struct ast_vbios_enhtable res_1360x768[] = {

I've tested your patches, so with the above changes:

Tested-by: Egbert Eich 

Cheers,
Egbert.

[Bug 83341] New: Failure to check return value leads to missed -EDEADLK and a kernel warning printout

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

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

Bug ID: 83341
   Summary: Failure to check return value leads to missed -EDEADLK
and a kernel warning printout
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16 and above
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: thellstrom at vmware.com
Regression: No

Please see 

https://bugzilla.redhat.com/show_bug.cgi?id=1114160

The error is in the following lines, where no error checking takes place on
drm_modeset_lock().

drm_modeset_lock_all(dev);
drm_modeset_lock_init(>mutex);
/* dropped by _unlock_all(): */
drm_modeset_lock(>mutex, config->acquire_ctx);

This is probably under the assumption that the lock is just initialized and
will therefore always succeed. However, the ww_mutex subsystem has a fault
injection option and when that kicks in, that lock may fail.

Fixing this turns out to be a little involved. Personally I think a trylock()
would be in order here, but that would mean extending the drm_modeset_lock()
API.

The error message copied from Redhat Bugzilla:

[5.082609] [ cut here ]
[5.083548] WARNING: CPU: 0 PID: 369 at
drivers/gpu/drm/drm_modeset_lock.c:91 drm_modeset_drop_locks+0x71/0x80 [drm]()
[5.084483] Modules linked in: vmwgfx(+) drm_kms_helper ttm drm mptspi
scsi_transport_spi e1000 mptscsih mptbase i2c_core ata_generic pata_acpi
[5.085536] CPU: 0 PID: 369 Comm: systemd-udevd Not tainted
3.16.0-0.rc2.git3.1.fc21.x86_64 #1
[5.086689] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 07/31/2013
[5.088693]   54dc8e0c 880036e27910
81807c4c
[5.090714]   880036e27948 8109b3ed
880039073000
[5.091584]  8800391ee900 8800391ee900 88003890fe00
8840
[5.092662] Call Trace:
[5.093311]  [] dump_stack+0x4d/0x66
[5.093867]  [] warn_slowpath_common+0x7d/0xa0
[5.094562]  [] warn_slowpath_null+0x1a/0x20
[5.095241]  [] drm_modeset_drop_locks+0x71/0x80 [drm]
[5.095773]  [] drm_modeset_unlock_all+0x2e/0x70 [drm]
[5.096196]  [] drm_crtc_init_with_planes+0xa7/0x110 [drm]
[5.096659]  [] drm_crtc_init+0x33/0x40 [drm_kms_helper]
[5.097050]  []
vmw_kms_init_screen_object_display+0x1a9/0x260 [vmwgfx]
[5.098174]  [] vmw_kms_init+0x59/0x70 [vmwgfx]
[5.098725]  [] vmw_driver_load+0x8d0/0xda0 [vmwgfx]
[5.099129]  [] drm_dev_register+0xad/0x100 [drm]
[5.099486]  [] drm_get_pci_dev+0x8d/0x200 [drm]
[5.099900]  [] vmw_probe+0x15/0x20 [vmwgfx]
[5.100274]  [] local_pci_probe+0x45/0xa0
[5.100626]  [] ? pci_match_device+0xe5/0x110
[5.100959]  [] pci_device_probe+0xf9/0x150
[5.101286]  [] driver_probe_device+0xa3/0x400
[5.101589]  [] __driver_attach+0x8b/0x90
[5.101934]  [] ? __device_attach+0x40/0x40
[5.102242]  [] bus_for_each_dev+0x73/0xc0
[5.102545]  [] driver_attach+0x1e/0x20
[5.102808]  [] bus_add_driver+0x188/0x260
[5.103075]  [] driver_register+0x64/0xf0
[5.103352]  [] __pci_register_driver+0x60/0x70
[5.103616]  [] drm_pci_init+0x10a/0x140 [drm]
[5.103913]  [] ? 0xa012dfff
[5.104176]  [] vmwgfx_init+0x18/0x1000 [vmwgfx]
[5.104482]  [] do_one_initcall+0xd8/0x210
[5.104745]  [] ? __vunmap+0xba/0x120
[5.105015]  [] load_module+0x2110/0x2740
[5.105275]  [] ? store_uevent+0x70/0x70
[5.105551]  [] ? lock_release_holdtime.part.28+0xf/0x200
[5.105951]  [] ? lock_release_non_nested+0x3c6/0x3d0
[5.106357]  [] SyS_init_module+0xe7/0x140
[5.106849]  [] system_call_fastpath+0x16/0x1b
[5.107162] ---[ end trace 225f20829bb0d8e8 ]---

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

[PATCH 1/2] drm/ttm: move fpfn and lpfn into each placement

[Dave Airlie]

On 26 August 2014 21:28, Christian K?nig  wrote:
> Hi Dave,
>
> any preferences how I can push this change upstream?
>
> Since it affects a whole bunch of drivers it would be nice if I could get
> more reviews and/or acks on it. And if we just push it to you through the
> Radeon tree it will probably cause a bunch of merge conflicts.

Can you send me a separate git tree base on drm-next and I'll pull it
into drm-next directly.

Though it would be nice to get some acks on it, it doesn't look like a
major amount of damage could be caused and -next should pick it up.

Dave.

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #7 from Maciej  ---
Comment on attachment 105340
  --> https://bugs.freedesktop.org/attachment.cgi?id=105340
another screenshot showing corruption

This happened after lightdm restart, suddenly Unity works, but everything else
is corrupted.

-- 
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/20140827/a4902061/attachment.html>

drm/i915/bdw: Provide the BDW specific HDMI buffer translation table

[Damien Lespiau]

On Wed, Aug 27, 2014 at 04:04:46PM +0300, Dan Carpenter wrote:
> Hello Damien Lespiau,
> 
> The patch a26aa8baee6c: "drm/i915/bdw: Provide the BDW specific HDMI
> buffer translation table" from Aug 1, 2014, leads to the following
> static checker warning:
> 
>   drivers/gpu/drm/i915/intel_ddi.c:225 intel_prepare_ddi_buffers()
>   error: buffer overflow 'ddi_translations_hdmi' 24 <= 31
> 
> drivers/gpu/drm/i915/intel_ddi.c
>155  static void intel_prepare_ddi_buffers(struct drm_device *dev, enum 
> port port)
>156  {
>157  struct drm_i915_private *dev_priv = dev->dev_private;
>158  u32 reg;
>159  int i, n_hdmi_entries, hdmi_800mV_0dB;
>160  int hdmi_level = 
> dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
> ^^
> The static checker thinks this is a number between 0-15.  I didn't check
> if that was correct.
> 
>161  const u32 *ddi_translations_fdi;
> 
> [ snip ]
> 
>186  ddi_translations_hdmi = bdw_ddi_translations_hdmi;
>187  n_hdmi_entries = 
> ARRAY_SIZE(bdw_ddi_translations_hdmi);
> ^^
> limit is the size of the array.
> 
>188  hdmi_800mV_0dB = 7;
>189  }
>190  
>191  switch (port) {
>192  case PORT_A:
>193  ddi_translations = ddi_translations_edp;
>194  break;
>195  case PORT_B:
>196  case PORT_C:
>197  ddi_translations = ddi_translations_dp;
>198  break;
>199  case PORT_D:
>200  if (intel_dp_is_edp(dev, PORT_D))
>201  ddi_translations = ddi_translations_edp;
>202  else
>203  ddi_translations = ddi_translations_dp;
>204  break;
>205  case PORT_E:
>206  ddi_translations = ddi_translations_fdi;
>207  break;
>208  default:
>209  BUG();
>210  }
>211  
>212  for (i = 0, reg = DDI_BUF_TRANS(port);
>213   i < ARRAY_SIZE(hsw_ddi_translations_fdi); i++) {
>214  I915_WRITE(reg, ddi_translations[i]);
>215  reg += 4;
>216  }
>217  
>218  /* Choose a good default if VBT is badly populated */
>219  if (hdmi_level == HDMI_LEVEL_SHIFT_UNKNOWN ||
>220  hdmi_level >= n_hdmi_entries)
>   ^^
> We cap it at the size of the array which is either 20 or 24.  The static
> checker thinks it's already capped at 15 so this is not a problem.
> 
> Should this be n_hdmi_entries / 2 or something?  Maybe a - 1 in there?

Indeed, n_hdmi_entries needed to be:

  n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi) / 2;

This was fixed by:

  commit d6699dd3a7f696a80a5f8e5bb6ecf6ff6dd7c998
  Author: Damien Lespiau 
  Date:   Sat Aug 9 16:29:31 2014 +0100

  drm/i915: Fix wrong number of HDMI translation entries

-- 
Damien

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #6 from Maciej  ---
Created attachment 105341
  --> https://bugs.freedesktop.org/attachment.cgi?id=105341=edit
systemd-logind fail

Not sure if it's relevant, but this shows up along with latest mesa and those
Unity glitches.

-- 
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/20140827/9722a044/attachment.html>

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

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

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

--- Comment #4 from Klaus Kusche  ---
Logs after
xset dpms force standby   (screen goes black)
touching the mouse(screen starts flickering)
xrandr --output eDP --off (screen goes black)
xrandr --output eDP --auto(screen becomes readable after a few seconds
delay)

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

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #5 from Maciej  ---
I have no idea how to bisect mesa tbh. I'll look into it later and see if I can
manage.

-- 
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/20140827/e5ed27d2/attachment.html>

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

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

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

--- Comment #3 from Klaus Kusche  ---
Created attachment 148511
  --> https://bugzilla.kernel.org/attachment.cgi?id=148511=edit
X log

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

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

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

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

--- Comment #2 from Klaus Kusche  ---
Created attachment 148501
  --> https://bugzilla.kernel.org/attachment.cgi?id=148501=edit
Kernel and system log

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

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #4 from Maciej  ---
Created attachment 105340
  --> https://bugs.freedesktop.org/attachment.cgi?id=105340=edit
another screenshot showing corruption

-- 
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/20140827/f1d1d570/attachment.html>

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #3 from Maciej  ---
Created attachment 105339
  --> https://bugs.freedesktop.org/attachment.cgi?id=105339=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/20140827/ea709fa8/attachment.html>

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #2 from Maciej  ---
Created attachment 105338
  --> https://bugs.freedesktop.org/attachment.cgi?id=105338=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/20140827/81936f61/attachment.html>

[Intel-gfx] [PATCH v2 0/7] Rename DP training vswing/pre-emph defines

[Deucher, Alexander]

> -Original Message-
> From: Jindal, Sonika [mailto:sonika.jindal at intel.com]
> Sent: Wednesday, August 27, 2014 2:09 AM
> To: Jindal, Sonika; intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org; kgene.kim at samsung.com;
> jg1.han at samsung.com; airlied at linux.ie; Deucher, Alexander;
> thierry.reding at gmail.com; Lespiau, Damien
> Subject: RE: [Intel-gfx] [PATCH v2 0/7] Rename DP training vswing/pre-emph
> defines
> 
> Hi,
> 
> Did anybody get a chance to review the patches?
> Adding respective owners for different drivers..

I gave my RB to danvet on IRC, but if you need it:

Reviewed-by: Alex Deucher 

> 
> Thanks,
> Sonika
> 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Jindal, Sonika
> Sent: Tuesday, August 19, 2014 1:42 PM
> To: intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 0/7] Rename DP training vswing/pre-emph
> defines
> 
> Hi,
> 
> Did anybody get a chance to review other patches in this series?
> I got r-b for 2 patches (patches with changes in drm and i915) from Damien.
> 
> Thanks,
> Sonika
> 
> -Original Message-
> From: Jindal, Sonika
> Sent: Friday, August 8, 2014 4:24 PM
> To: intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org; Jindal, Sonika
> Subject: [PATCH v2 0/7] Rename DP training vswing/pre-emph defines
> 
> From: Sonika Jindal 
> 
> Rename the defines to have levels instead of values for vswing and pre-
> emph levels as the values may differ in other scenarios like low vswing of
> eDP 1.4 where the values are different.
> Updated in all the drivers as well
> 
> v2: Keeping the old defines in first patch and removing them in last patch.
> Used cocci semantic patch to replace the defines.
> 
> Sonika Jindal (7):
>   drm: Renaming DP training vswing pre emph defines
>   drm/i915: Renaming DP training vswing pre emph defines
>   drm/exynos: Renaming DP training vswing pre emph defines
>   drm/gma500: Renaming DP training vswing pre emph defines
>   drm/radeon: Renaming DP training vswing pre emph defines
>   drm/tegra: Renaming DP training vswing pre emph defines
>   drm: Remove old defines for vswing and pre-emph values
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c |4 +-
>  drivers/gpu/drm/gma500/cdv_intel_dp.c   |4 +-
>  drivers/gpu/drm/gma500/intel_bios.c |   16 +--
>  drivers/gpu/drm/i915/intel_bios.c   |   16 +--
>  drivers/gpu/drm/i915/intel_dp.c |  194 
> +++
>  drivers/gpu/drm/radeon/atombios_dp.c|4 +-
>  drivers/gpu/drm/tegra/dpaux.c   |4 +-
>  include/drm/drm_dp_helper.h |   16 +--
>  8 files changed, 129 insertions(+), 129 deletions(-)
> 
> --
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg ouput.  Can you bisect mesa?

-- 
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/20140827/e5b55138/attachment.html>

[Bug 83148] Unity invisible under Ubuntu 14.04 and 14.10

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #105337|text/plain  |image/png
  mime type||

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

[PATCH 1/2] drm/ttm: move fpfn and lpfn into each placement

[Christian König]

Hi Dave,

Am 27.08.2014 um 06:21 schrieb Dave Airlie:
> On 26 August 2014 21:28, Christian K?nig  wrote:
>> Hi Dave,
>>
>> any preferences how I can push this change upstream?
>>
>> Since it affects a whole bunch of drivers it would be nice if I could get
>> more reviews and/or acks on it. And if we just push it to you through the
>> Radeon tree it will probably cause a bunch of merge conflicts.
> Can you send me a separate git tree base on drm-next and I'll pull it
> into drm-next directly.

Sounds good, branch is on FDO and formal pull request below.

> Though it would be nice to get some acks on it, it doesn't look like a
> major amount of damage could be caused and -next should pick it up.

Agree, the change is rather straight forward.

My most concern is that I somehow missed something that only driver 
maintainers know about, but I can confirm that all changed drivers still 
compile fine on my box.

If anybody has additional comments on the patch or wants to give an 
rb/ab just send a mail, the patch is on the list for quite a while now.

Regards,
Christian.

The following changes since commit 484048db6b4890bc433aac7f5e32fdcf1b2b4786:

   Merge branch 'drm-next-3.18' of 
git://people.freedesktop.org/~agd5f/linux into drm-next (2014-08-26 
09:05:14 +1000)

are available in the git repository at:


   git://people.freedesktop.org/~deathsimple/linux ttm_pfn

for you to fetch changes up to f1217ed09f827e42a49ffa6a5aab672aa6f57a65:

   drm/ttm: move fpfn and lpfn into each placement v2 (2014-08-27 
13:16:04 +0200)


Christian K?nig (1):
   drm/ttm: move fpfn and lpfn into each placement v2

  drivers/gpu/drm/ast/ast_drv.h |   2 +-
  drivers/gpu/drm/ast/ast_ttm.c |  20 --
  drivers/gpu/drm/bochs/bochs.h |   2 +-
  drivers/gpu/drm/bochs/bochs_mm.c  |  20 +-
  drivers/gpu/drm/cirrus/cirrus_drv.h   |   2 +-
  drivers/gpu/drm/cirrus/cirrus_ttm.c   |  17 +++-
  drivers/gpu/drm/mgag200/mgag200_drv.h |   2 +-
  drivers/gpu/drm/mgag200/mgag200_ttm.c |  20 --
  drivers/gpu/drm/nouveau/nouveau_bo.c  |  52 
---
  drivers/gpu/drm/nouveau/nouveau_bo.h  |   4 +--
  drivers/gpu/drm/nouveau/nouveau_ttm.c |   9 +++
  drivers/gpu/drm/qxl/qxl_drv.h |   2 +-
  drivers/gpu/drm/qxl/qxl_object.c  |  17 +++-
  drivers/gpu/drm/qxl/qxl_ttm.c |   8 +++---
  drivers/gpu/drm/radeon/radeon.h   |   2 +-
  drivers/gpu/drm/radeon/radeon_object.c|  71 
++--
  drivers/gpu/drm/radeon/radeon_ttm.c   |  25 +
  drivers/gpu/drm/radeon/radeon_uvd.c   |   8 --
  drivers/gpu/drm/ttm/ttm_bo.c  |  93 
+++
  drivers/gpu/drm/ttm/ttm_bo_manager.c  |   9 +++
  drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c| 136 
+---
  drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c|  22 ++-
  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|  10 +--
  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |   3 +--
  include/drm/ttm/ttm_bo_api.h  |  40 
+--
  include/drm/ttm/ttm_bo_driver.h   |   3 +--
  26 files changed, 346 insertions(+), 253 deletions(-)

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

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

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

--- Comment #20 from Alex Deucher  ---
(In reply to comment #19)
> @Damian, I had the same problems. My configuration is similar to yours:
> Radeon 7870, Linux 3.16.1, xorg 1.16, MESA 10.3 RC1 (fedora f21 branch).
> 
> After consulting https://wiki.archlinux.org/index.php/ATI it tried adding
> radeon.dpm=0 to my kernel command line as a workaround. It solved the
> problem. No more lockups. The system is now stable with the above
> configuration. Clearly this has something to do with the powermanagement
> changes in MESA and the kernel (there were no lockups with earlier versions
> of MESA)

There is no power management code in mesa.  Power management is completely
self-contained in the kernel.  If you are not getting lockups with dpm enabled
and an older version of mesa, it may be a mesa issue.

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

[Bug 83148] New: Unity invisible under Ubuntu 14.04 and 14.10

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

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

  Priority: medium
Bug ID: 83148
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Unity invisible under Ubuntu 14.04 and 14.10
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: gutigen at outlook.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 105337
  --> https://bugs.freedesktop.org/attachment.cgi?id=105337=edit
screenshot of the issue

Unity is invisible when using latest mesa git from Oibaf PPA. It started
happening after update from yesterday or two days ago (updating almost daily).

Ubuntu 14.04 with kernel 3.16.1 and Ubuntu 14.10 with kernel 3.16.0.

-- 
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/20140827/e6270739/attachment.html>

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output after the panel has gone out of
sync.

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

[PATCH v2 14/15] drm/exynos/fimc: simplify buffer queuing

[Andrzej Hajda]

The patch removes redundant checks, redundant HW reads
and simplifies code.

Signed-off-by: Andrzej Hajda 
---
v2:
- fixed bit cleaning operation
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 64 
 1 file changed, 15 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 62ba033..59ba8bb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1126,67 +1126,34 @@ static int fimc_dst_set_size(struct device *dev, int 
swap,
return 0;
 }

-static int fimc_dst_get_buf_count(struct fimc_context *ctx)
-{
-   u32 cfg, buf_num;
-
-   cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
-
-   buf_num = hweight32(cfg);
-
-   DRM_DEBUG_KMS("buf_num[%d]\n", buf_num);
-
-   return buf_num;
-}
-
-static int fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
+static void fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
enum drm_exynos_ipp_buf_type buf_type)
 {
-   struct exynos_drm_ippdrv *ippdrv = >ippdrv;
-   bool enable;
-   u32 cfg;
-   u32 mask = 0x0001 << buf_id;
-   int ret = 0;
unsigned long flags;
+   u32 buf_num;
+   u32 cfg;

DRM_DEBUG_KMS("buf_id[%d]buf_type[%d]\n", buf_id, buf_type);

spin_lock_irqsave(>lock, flags);

-   /* mask register set */
cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);

-   switch (buf_type) {
-   case IPP_BUF_ENQUEUE:
-   enable = true;
-   break;
-   case IPP_BUF_DEQUEUE:
-   enable = false;
-   break;
-   default:
-   dev_err(ippdrv->dev, "invalid buf ctrl parameter.\n");
-   ret =  -EINVAL;
-   goto err_unlock;
-   }
+   if (buf_type == IPP_BUF_ENQUEUE)
+   cfg |= (1 << buf_id);
+   else
+   cfg &= ~(1 << buf_id);

-   /* sequence id */
-   cfg &= ~mask;
-   cfg |= (enable << buf_id);
fimc_write(ctx, cfg, EXYNOS_CIFCNTSEQ);

-   /* interrupt enable */
-   if (buf_type == IPP_BUF_ENQUEUE &&
-   fimc_dst_get_buf_count(ctx) >= FIMC_BUF_START)
-   fimc_mask_irq(ctx, true);
+   buf_num = hweight32(cfg);

-   /* interrupt disable */
-   if (buf_type == IPP_BUF_DEQUEUE &&
-   fimc_dst_get_buf_count(ctx) <= FIMC_BUF_STOP)
+   if (buf_type == IPP_BUF_ENQUEUE && buf_num >= FIMC_BUF_START)
+   fimc_mask_irq(ctx, true);
+   else if (buf_type == IPP_BUF_DEQUEUE && buf_num <= FIMC_BUF_STOP)
fimc_mask_irq(ctx, false);

-err_unlock:
spin_unlock_irqrestore(>lock, flags);
-   return ret;
 }

 static int fimc_dst_set_addr(struct device *dev,
@@ -1244,7 +1211,9 @@ static int fimc_dst_set_addr(struct device *dev,
break;
}

-   return fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
+   fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
+
+   return 0;
 }

 static struct exynos_drm_ipp_ops fimc_dst_ops = {
@@ -1299,10 +1268,7 @@ static irqreturn_t fimc_irq_handler(int irq, void 
*dev_id)

DRM_DEBUG_KMS("buf_id[%d]\n", buf_id);

-   if (fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE) < 0) {
-   DRM_ERROR("failed to dequeue.\n");
-   return IRQ_HANDLED;
-   }
+   fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE);

event_work->ippdrv = ippdrv;
event_work->buf_id[EXYNOS_DRM_OPS_DST] = buf_id;
-- 
1.9.1

[PATCH] radeon: Test for PCI root bus before assuming bus->self

[Alex Williamson]

If we assign a Radeon device to a virtual machine, we can no longer
assume a fixed hardware topology, like the GPU having a parent device.
This patch simply adds a few pci_is_root_bus() tests to avoid passing
a NULL pointer to PCI access functions, allowing the radeon driver to
work in a QEMU 440FX machine with an assigned HD8570 on the emulated
PCI root bus.

Signed-off-by: Alex Williamson 
---

 drivers/gpu/drm/radeon/cik.c |6 +-
 drivers/gpu/drm/radeon/si.c  |6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 79a5a55..cc34308 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -9555,6 +9555,9 @@ static void cik_pcie_gen3_enable(struct radeon_device 
*rdev)
int ret, i;
u16 tmp16;

+   if (pci_is_root_bus(rdev->pdev->bus))
+   return;
+
if (radeon_pcie_gen2 == 0)
return;

@@ -9781,7 +9784,8 @@ static void cik_program_aspm(struct radeon_device *rdev)
if (orig != data)
WREG32_PCIE_PORT(PCIE_LC_LINK_WIDTH_CNTL, data);

-   if (!disable_clkreq) {
+   if (!disable_clkreq &&
+   !pci_is_root_bus(rdev->pdev->bus)) {
struct pci_dev *root = rdev->pdev->bus->self;
u32 lnkcap;

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index a1274a3..ffb1d4e 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -7177,6 +7177,9 @@ static void si_pcie_gen3_enable(struct radeon_device 
*rdev)
int ret, i;
u16 tmp16;

+   if (pci_is_root_bus(rdev->pdev->bus))
+   return;
+
if (radeon_pcie_gen2 == 0)
return;

@@ -7454,7 +7457,8 @@ static void si_program_aspm(struct radeon_device *rdev)
if (orig != data)
WREG32_PIF_PHY1(PB1_PIF_CNTL, data);

-   if (!disable_clkreq) {
+   if (!disable_clkreq &&
+   !pci_is_root_bus(rdev->pdev->bus)) {
struct pci_dev *root = rdev->pdev->bus->self;
u32 lnkcap;

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

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

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

--- Comment #19 from paul.woegerer at gmail.com ---
@Damian, I had the same problems. My configuration is similar to yours: Radeon
7870, Linux 3.16.1, xorg 1.16, MESA 10.3 RC1 (fedora f21 branch).

After consulting https://wiki.archlinux.org/index.php/ATI it tried adding
radeon.dpm=0 to my kernel command line as a workaround. It solved the problem.
No more lockups. The system is now stable with the above configuration. Clearly
this has something to do with the powermanagement changes in MESA and the
kernel (there were no lockups with earlier versions of MESA)

-- 
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/20140827/59be04c7/attachment-0001.html>

[PATCH] drm: Test for PCI root bus to avoid NULL pointer dereference

[Alex Williamson]

If we have a GPU on the PCI root bus that calls
drm_pcie_get_speed_cap_mask() we end up with a NULL pointer
dereference since pdev->bus->self is NULL.  We already protect
against callers passing non-PCI devices, so let's also catch this
case and return -EINVAL.

Root complex graphics are not terribly likely outside of IGD, but
when we assign a standard plugin GPU to a virtual machine, our
assumption that we have a parent device quickly becomes invalid.

Signed-off-by: Alex Williamson 
---

 drivers/gpu/drm/drm_pci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 020cfd9..411e806 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -390,7 +390,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 
*mask)
u32 lnkcap, lnkcap2;

*mask = 0;
-   if (!dev->pdev)
+   if (!dev->pdev || pci_is_root_bus(dev->pdev->bus))
return -EINVAL;

root = dev->pdev->bus->self;

(UVD RS780 first impression)

[Michel Dänzer]

On 26.08.2014 23:14, Stefan Lange wrote:
> Hi,
>
> first of all: Thanks a lot for putting effort into this sort of ancient
> hardware, I'm really surprised in a very positive way to see open source
> UVD support happen on old R600 GPUs. I gave the recently posted patches
> a shot an here is my first impression:
>
> Kernel from uvd-r600-release branch compiles and boots fine
> (I also included the 3.16.1 and Con Kolivas' ck/BFS patch as well, I
> hope that was OK; I could give it a try without modifications as well,
> if that would help.)
>
> Mesa with the posted patch applied also compiled fine
>
> First tests with mplayer were not so successful, unfortunately:
> I tried "big buck bunny" with both software and hardwarde decoding.
> Software looks OK (as expected). Hardware decoding seems to work,
> mplayer doesn't complain and CPU usage also goes down significantly, the
> resulting image is distorted, however.
> I tried to get a screen shots to illustrate the issue, see attachment.
> Looks like part of the top is found at the bottom, and look sort of like
> an interlaced image.

Sounds like you're missing 
http://cgit.freedesktop.org/mesa/mesa/commit/?id=80771e47b6c1e47ab55f17311e1d4e227a9eb3d8
 
. 


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

[PATCH 1/9] drm/radeon: wake up all fences on manual reset

[Michel Dänzer]

I noticed a bunch of typos, other than that the series looks good to me.


Patch 1:

> Wake up all fences when we manually trigger an reset.

'trigger a reset.'


Patch 2:

> pathes.

'paths.'


Patch 7:

> drm/radeon: add timeout argument to, radeon_fence_wait_seq

'to radeon_fence_wait_seq'


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

[PATCH 06/15] drm/exynos/ipp: free partially allocated resources on error

[Andrzej Hajda]

On 08/26/2014 07:00 AM, Joonyoung Shim wrote:
> Hi Andrzej,
>
> On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
>> In case of allocation errors some already allocated buffers
>> were not freed. The patch fixes it.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 68 
>> -
>>  1 file changed, 33 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> index 060a198..728f3b9 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> @@ -599,6 +599,37 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
>> *ippdrv,
>>  return ret;
>>  }
>>  
>> +static int ipp_put_mem_node(struct drm_device *drm_dev,
>> +struct drm_exynos_ipp_cmd_node *c_node,
>> +struct drm_exynos_ipp_mem_node *m_node)
>> +{
>> +int i;
>> +
>> +DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>> +
>> +if (!m_node) {
>> +DRM_ERROR("invalid dequeue node.\n");
>> +return -EFAULT;
>> +}
>> +
>> +DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>> +
>> +/* put gem buffer */
>> +for_each_ipp_planar(i) {
>> +unsigned long handle = m_node->buf_info.handles[i];
>> +if (handle)
>> +exynos_drm_gem_put_dma_addr(drm_dev, handle,
>> +c_node->filp);
>> +}
>> +
>> +/* conditionally remove from queue */
>> +if (m_node->list.next)
> How about do INIT_LIST_HEAD for list in ipp_get_mem_node()?

I am not sure if it is better. For sure it adds unnecessary
initialization sequence.
Maybe adding list_is_initialized inline function to list.h would be the
best solution.

Regards
Andrzej

>
>> +list_del(_node->list);
>> +kfree(m_node);
>> +
>> +return 0;
>> +}
>> +
>>  static struct drm_exynos_ipp_mem_node
>>  *ipp_get_mem_node(struct drm_device *drm_dev,
>>  struct drm_file *file,
>> @@ -634,7 +665,8 @@ static struct drm_exynos_ipp_mem_node
>>  qbuf->handle[i], file);
>>  if (IS_ERR(addr)) {
>>  DRM_ERROR("failed to get addr.\n");
>> -goto err_clear;
>> +ipp_put_mem_node(drm_dev, c_node, m_node);
>> +return ERR_PTR(-EFAULT);
>>  }
>>  
>>  buf_info->handles[i] = qbuf->handle[i];
>> @@ -649,40 +681,6 @@ static struct drm_exynos_ipp_mem_node
>>  mutex_unlock(_node->mem_lock);
>>  
>>  return m_node;
>> -
>> -err_clear:
>> -kfree(m_node);
>> -return ERR_PTR(-EFAULT);
>> -}
>> -
>> -static int ipp_put_mem_node(struct drm_device *drm_dev,
>> -struct drm_exynos_ipp_cmd_node *c_node,
>> -struct drm_exynos_ipp_mem_node *m_node)
>> -{
>> -int i;
>> -
>> -DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>> -
>> -if (!m_node) {
>> -DRM_ERROR("invalid dequeue node.\n");
>> -return -EFAULT;
>> -}
>> -
>> -DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>> -
>> -/* put gem buffer */
>> -for_each_ipp_planar(i) {
>> -unsigned long handle = m_node->buf_info.handles[i];
>> -if (handle)
>> -exynos_drm_gem_put_dma_addr(drm_dev, handle,
>> -c_node->filp);
>> -}
>> -
>> -/* delete list in queue */
>> -list_del(_node->list);
>> -kfree(m_node);
>> -
>> -return 0;
>>  }
>>  
>>  static void ipp_free_event(struct drm_pending_event *event)
>>
>

[PATCH 03/16] video: Add DT binding documentation for VGA connector

[Rob Herring]

On Wed, Aug 27, 2014 at 11:41 AM, Laurent Pinchart
 wrote:
> The VGA connector is described by a single input port and an optional
> DDC bus.

Wasn't there a generic connector binding for DVI, HDMI, etc.?

>
> Cc: devicetree at vger.kernel.org
> Cc: linux-fbdev at vger.kernel.org
> Signed-off-by: Laurent Pinchart 
> ---
>  .../devicetree/bindings/video/vga-connector.txt| 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/vga-connector.txt
>
> diff --git a/Documentation/devicetree/bindings/video/vga-connector.txt 
> b/Documentation/devicetree/bindings/video/vga-connector.txt
> new file mode 100644
> index 000..9a45ec1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/vga-connector.txt
> @@ -0,0 +1,28 @@
> +VGA Connector
> +==
> +
> +Required properties:
> +- compatible: "vga-connector"
> +
> +Optional properties:
> +- label: a symbolic name for the connector

...which corresponds to hardware labels.

> +- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC
> +
> +Required nodes:
> +- Video port for VGA input

A reference to the relevant video graph bindings should be added here.

> +
> +Example
> +---
> +
> +vga0: connector at 0 {
> +   compatible = "vga-connector";
> +   label = "vga";
> +
> +   ddc-i2c-bus = <>;
> +
> +   port {
> +   vga_connector_in: endpoint {
> +   remote-endpoint = <_out>;
> +   };
> +   };
> +};
> --
> 1.8.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 83331] New: radeon: Laptop panel out of sync after dpms standby/suspend/off

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

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

Bug ID: 83331
   Summary: radeon: Laptop panel out of sync after dpms
standby/suspend/off
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15.10
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: klaus.kusche at computerix.info
Regression: No

I've a problem on my laptop
(Dell Precision M6700 with AMD Cap Verde graphics, ChipID = 0x6825)
with the radeon driver (radeon-ucode-20140430):

Whenever the X server switches to dpms standby, suspend or off state
(it does so after 5 minutes when I'm on battery and idle)
and then back to dpms on, the internal panel is out of sync:
It is completely unreadable, flashes or shows strange moving patterns.
External displays are fine.
The problem is independent of the radeon powersave mode
(profile or dpm).

The only way to recover is either to power cycle
or to blindly type
xrandr --output eDP --off
xrandr --output eDP --auto

Switching from X to a text (framebuffer) VT does not help:
They are also corrupted.

When initializing radeon during boot, the kernel log says
radeon :01:00.0: Invalid ROM contents
Could that be related?
Everything else looks fine.
When the problem happens, nothing is written to the kernel log.

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

[PATCH 01/16] devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt

[Rob Herring]

On Wed, Aug 27, 2014 at 11:40 AM, Laurent Pinchart
 wrote:
> Mitsubishi Electric Corporation has a numerical stock ticker, use the
> company name as vendor prefix.
>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Laurent Pinchart 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index ac7269f..7292cfc 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -83,6 +83,7 @@ maxim Maxim Integrated Products
>  mediatek   MediaTek Inc.
>  micrel Micrel Inc.
>  microchip  Microchip Technology Inc.
> +mitsubishi Mitsubishi Electric Corporation
>  mosaixtech Mosaix Technologies, Inc.
>  moxa   Moxa
>  mplMPL AG
> --
> 1.8.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/16] devicetree: Add vendor prefix "thine" to vendor-prefixes.txt

[Rob Herring]

On Wed, Aug 27, 2014 at 11:40 AM, Laurent Pinchart
 wrote:
> Use the company name as vendor prefix.
>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Laurent Pinchart 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 7292cfc..2b5648b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -134,6 +134,7 @@ st  STMicroelectronics
>  steST-Ericsson
>  stericsson ST-Ericsson
>  synology   Synology, Inc.
> +thine  THine Electronics, Inc.
>  ti Texas Instruments
>  tlmTrusted Logic Mobility
>  toradexToradex AG
> --
> 1.8.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

PCI Radeon RV100 detection hang on sparc64

[Michel Dänzer]

On 26.08.2014 16:07, Meelis Roos wrote:
 r100 init hangs in a different place. Original dmesg first, then my
 instrumented dmesg (seems to get further):
>>>
>>> The instrumented dmesg had a couple of my local test changes and was
>>> bad now that I had ROM. Reverted them exept my readb changes (instead
>>> of direct dereferences of iomapped space) and redid
>>> logging to be more precise.
>>>
 [drm] radeon kernel modesetting enabled.
 PCI: Enabling device: (:02:02.0), cmd 82
 [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
 [drm] register mmio base: 0x1000
 [drm] register mmio size: 32768
 [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR
>>>
>>> This was still the unchanged kernel hanging.
>>>
>>> Below is a new debug log to pinpoint the hang. It seems to hang in
>>> r100_gfx_get_rptr but not on first try.
>>
>> It's most likely hanging in readl() in r100_mm_rreg() then.
>
> Yes, it is doing direct readl() there. But what does this hang mean?

I'm not sure if the read can hang because of the GPU, or if indicates a 
more fundamental PCI issue. Dave?


> By the way, I get these warnings from r100. Seem to be unrelated but
> still worth reporting IMHO:

Looks unrelated indeed.


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

[PATCH] ww-mutex: clarify help text for DEBUG_WW_MUTEX_SLOWPATH

[Rob Clark]

We really don't want distro's enabling this in their kernels.  Try and
make that more clear.

Signed-off-by: Rob Clark 
---
 lib/Kconfig.debug | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 07c2832..1b233fc 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -892,6 +892,10 @@ config DEBUG_WW_MUTEX_SLOWPATH
 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
 will test all possible w/w mutex interface abuse with the
 exception of simply not acquiring all the required locks.
+Note that this feature can introduce significant overhead, so
+it really should not be enabled in a production or distro kernel,
+even a debug kernel.  If you are a driver writer, enable it.  If
+you are a distro, do not.

 config DEBUG_LOCK_ALLOC
bool "Lock debugging: detect incorrect freeing of live locks"
-- 
1.9.3

[PATCH] drm/radeon: soft reset uvd on RV770 uvd init

[Alex Deucher]

On Wed, Aug 27, 2014 at 4:10 AM, Christian K?nig
 wrote:
> Am 27.08.2014 um 05:04 schrieb Alex Deucher:
>
>> Fixes avoids and error message on boot which is harmless,
>> but confusing to users.
>>
>> Signed-off-by: Alex Deucher 
>
>
> The attached patch fixes the underlying issue for me on RS780.
>
> Does it also work on RV770? If yes than it's probably the better approach.

Yup, that fixes it on RV770.  I'll add that patch to the 3.18 queue.

Thanks!

Alex

>
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/radeon/uvd_v1_0.c | 7 +++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c
>> b/drivers/gpu/drm/radeon/uvd_v1_0.c
>> index e251624..82e4fa6 100644
>> --- a/drivers/gpu/drm/radeon/uvd_v1_0.c
>> +++ b/drivers/gpu/drm/radeon/uvd_v1_0.c
>> @@ -325,6 +325,13 @@ int uvd_v1_0_start(struct radeon_device *rdev)
>> WREG32_P(UVD_RB_ARB_CTRL, 0, ~(1 << 3));
>>   + if (rdev->family == CHIP_RV770) {
>> +   WREG32_P(UVD_SOFT_RESET, VCPU_SOFT_RESET,
>> ~VCPU_SOFT_RESET);
>> +   mdelay(10);
>> +   WREG32_P(UVD_SOFT_RESET, 0, ~VCPU_SOFT_RESET);
>> +   mdelay(10);
>> +   }
>> +
>> for (i = 0; i < 10; ++i) {
>> uint32_t status;
>> for (j = 0; j < 100; ++j) {
>
>