[Bug 68805] 48 fps and 50 fps video decoding is stutter on UVD

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68805

--- Comment #2 from kwah...@wp.pl ---
I have very similar config to your (3.11 + DPM + oibaf PPA) except HD 6670
instead 6310 - but vdpainfo output looks exactly the same. However, I cannot
confirm your issue. I am curious what is your
/sys/kernel/debug/dri/0/radeon_pm_info?

Mine:
sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
uvdvclk: 7 dclk: 56000
power level 0sclk: 8 mclk: 10 vddc: 1100 vddci: 0

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/tda998x: BUG() on invalid audio format

2013-09-01 Thread David Herrmann
Suppress warning of unused-variables by adding a BUG()+return for invalid
audio-formats.

Cc: Rob Clark 
Signed-off-by: David Herrmann 
---
Hey Rob

No idea whether it's correct. But all I know is when we hit the default: path,
several variables will be unset. To avoid gcc warn about it, I added the BUG().
If we should just silently return, feel free to adjust the patch to your needs.

Cheers
David

 drivers/gpu/drm/i2c/tda998x_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index c2bd711..b1f8fc6 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -596,6 +596,10 @@ tda998x_configure_audio(struct drm_encoder *encoder,
cts_n = CTS_N_M(3) | CTS_N_K(3);
ca_i2s = CA_I2S_CA_I2S(0);
break;
+
+   default:
+   BUG();
+   return;
}
 
reg_write(encoder, REG_AIP_CLKSEL, clksel_aip);
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 0/6] SimpleDRM Driver

2013-09-01 Thread David Herrmann
Hi

With the upcoming 3.12 merge-window, I thought people might find themselves with
nothing to do, so here's a new SimpleDRM series. Comments welcome!

This depends on the tip/x86/fb series in the x86-tip tree:
  http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/fb
Which, as far as I understood, will be pushed into 3.12 by the x86 people.

Patches #1 and #2 implement the SimpleDRM driver which can replace vesafb,
efifb, simplefb, vgafb and more. Just enable the CONFIG_X86_SYSFB option and
you're good to go.

Patches #3 to #6 implement drm_kick_out_firmware() to make x86 drivers kick out
firmware-DRM drivers instead of only fbdev via
remove_conflicting_framebuffers().

I tested this based on drm-next plus the x86/fb series merged with i915 and
nouveau and it worked just fine.

Regards
David


David Herrmann (6):
  drm: add SimpleDRM driver
  drm: simpledrm: add fbdev fallback support
  drm: add helpers to kick out firmware drivers
  drm: nouveau: kick out firmware drivers during probe
  drm/i915: use new drm_kick_out_firmware()
  drm/radeon: use new drm_kick_out_firmware()

 MAINTAINERS |   8 +
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_pci.c   |   1 +
 drivers/gpu/drm/drm_platform.c  |   1 +
 drivers/gpu/drm/drm_stub.c  | 118 +
 drivers/gpu/drm/drm_usb.c   |   1 +
 drivers/gpu/drm/i915/i915_dma.c |   6 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  29 ++-
 drivers/gpu/drm/radeon/radeon_drv.c |  28 ---
 drivers/gpu/drm/radeon/radeon_kms.c |  30 +++
 drivers/gpu/drm/simpledrm/Kconfig   |  29 +++
 drivers/gpu/drm/simpledrm/Makefile  |   4 +
 drivers/gpu/drm/simpledrm/simpledrm.h   | 112 +
 drivers/gpu/drm/simpledrm/simpledrm_drv.c   | 226 +
 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 153 
 drivers/gpu/drm/simpledrm/simpledrm_main.c  | 363 
 drivers/gpu/drm/simpledrm/simpledrm_mem.c   | 242 +++
 include/drm/drmP.h  |  26 ++
 19 files changed, 1342 insertions(+), 38 deletions(-)
 create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
 create mode 100644 drivers/gpu/drm/simpledrm/Makefile
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_main.c
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_mem.c

-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 1/6] drm: add SimpleDRM driver

2013-09-01 Thread David Herrmann
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.

Userspace can create one dumb-buffer and attach it to the CRTC. Only if
the buffer is destroyed, a new buffer can be created. The buffer is
directly mapped into user-space, so we have only resources for a single
buffer. Otherwise, shadow buffers plus damage-request would be needed.

Signed-off-by: David Herrmann 
Tested-by: Stephen Warren 
---
 MAINTAINERS|   8 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/simpledrm/Kconfig  |  18 ++
 drivers/gpu/drm/simpledrm/Makefile |   3 +
 drivers/gpu/drm/simpledrm/simpledrm.h  |  89 
 drivers/gpu/drm/simpledrm/simpledrm_drv.c  | 225 
 drivers/gpu/drm/simpledrm/simpledrm_main.c | 328 +
 drivers/gpu/drm/simpledrm/simpledrm_mem.c  | 242 +
 9 files changed, 916 insertions(+)
 create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
 create mode 100644 drivers/gpu/drm/simpledrm/Makefile
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_main.c
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_mem.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a26b10e..35c2fab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7435,6 +7435,14 @@ S:   Odd Fixes
 F: drivers/media/platform/sh_vou.c
 F: include/media/sh_vou.h
 
+SIMPLE DRM DRIVER
+M: David Herrmann 
+L: dri-devel@lists.freedesktop.org
+T: git git://people.freedesktop.org/~dvdhrm/linux
+S: Maintained
+F: drivers/gpu/drm/simpledrm
+F: include/linux/platform_data/simpledrm.h
+
 SIMPLE FIRMWARE INTERFACE (SFI)
 M: Len Brown 
 L: sfi-de...@simplefirmware.org
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..33c1765 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source "drivers/gpu/drm/tilcdc/Kconfig"
 source "drivers/gpu/drm/qxl/Kconfig"
 
 source "drivers/gpu/drm/msm/Kconfig"
+
+source "drivers/gpu/drm/simpledrm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..fe23d6f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -55,4 +55,5 @@ obj-$(CONFIG_DRM_OMAP)+= omapdrm/
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_MSM) += msm/
+obj-$(CONFIG_DRM_SIMPLEDRM) += simpledrm/
 obj-y  += i2c/
diff --git a/drivers/gpu/drm/simpledrm/Kconfig 
b/drivers/gpu/drm/simpledrm/Kconfig
new file mode 100644
index 000..35bcce8
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/Kconfig
@@ -0,0 +1,18 @@
+config DRM_SIMPLEDRM
+   tristate "Simple firmware framebuffer DRM driver"
+   depends on DRM && (FB_SIMPLE = n)
+   help
+ SimpleDRM can run on all systems with pre-initialized graphics
+ hardware. It uses a framebuffer that was initialized during
+ firmware boot. No page-flipping, modesetting or other advanced
+ features are available. However, other DRM drivers can be loaded
+ later and take over from SimpleDRM if they provide real hardware
+ support.
+
+ SimpleDRM supports "simple-framebuffer" DeviceTree objects and
+ compatible platform framebuffers.
+
+ If unsure, say Y.
+
+ To compile this driver as a module, choose M here: the
+ module will be called simpledrm.
diff --git a/drivers/gpu/drm/simpledrm/Makefile 
b/drivers/gpu/drm/simpledrm/Makefile
new file mode 100644
index 000..ceb97eb
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/Makefile
@@ -0,0 +1,3 @@
+simpledrm-y := simpledrm_drv.o simpledrm_main.o simpledrm_mem.o
+
+obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h 
b/drivers/gpu/drm/simpledrm/simpledrm.h
new file mode 100644
index 000..977b344
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/simpledrm.h
@@ -0,0 +1,89 @@
+/*
+ * SimpleDRM firmware framebuffer driver
+ * Copyright (c) 2012-2013 David Herrmann 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#ifndef SDRM_DRV_H
+#define SDRM_DRV_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sdrm_device;
+struct sdrm_gem_object;
+struct sdrm_framebuffer;
+
+/* simpledrm devices */
+
+struct sdrm_device {
+   struct drm_device *ddev;
+
+   /* framebuffer information */
+   const struct simplefb_format *fb_sformat;
+   u32 fb_format;
+ 

[PATCH v4 2/6] drm: simpledrm: add fbdev fallback support

2013-09-01 Thread David Herrmann
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.

Signed-off-by: David Herrmann 
Tested-by: Stephen Warren 
---
 drivers/gpu/drm/simpledrm/Kconfig   |  11 ++
 drivers/gpu/drm/simpledrm/Makefile  |   1 +
 drivers/gpu/drm/simpledrm/simpledrm.h   |  22 
 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 153 
 drivers/gpu/drm/simpledrm/simpledrm_main.c  |   2 +
 5 files changed, 189 insertions(+)
 create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c

diff --git a/drivers/gpu/drm/simpledrm/Kconfig 
b/drivers/gpu/drm/simpledrm/Kconfig
index 35bcce8..eef2a36 100644
--- a/drivers/gpu/drm/simpledrm/Kconfig
+++ b/drivers/gpu/drm/simpledrm/Kconfig
@@ -12,7 +12,18 @@ config DRM_SIMPLEDRM
  SimpleDRM supports "simple-framebuffer" DeviceTree objects and
  compatible platform framebuffers.
 
+ If fbdev support is enabled, this driver will also provide an fbdev
+ compatibility layer.
+
  If unsure, say Y.
 
  To compile this driver as a module, choose M here: the
  module will be called simpledrm.
+
+config DRM_SIMPLEDRM_FBDEV
+   bool
+   depends on DRM_SIMPLEDRM && FB
+   default y
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
diff --git a/drivers/gpu/drm/simpledrm/Makefile 
b/drivers/gpu/drm/simpledrm/Makefile
index ceb97eb..2144787 100644
--- a/drivers/gpu/drm/simpledrm/Makefile
+++ b/drivers/gpu/drm/simpledrm/Makefile
@@ -1,3 +1,4 @@
 simpledrm-y := simpledrm_drv.o simpledrm_main.o simpledrm_mem.o
+simpledrm-$(CONFIG_DRM_SIMPLEDRM_FBDEV) += simpledrm_fbdev.o
 
 obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h 
b/drivers/gpu/drm/simpledrm/simpledrm.h
index 977b344..b854981 100644
--- a/drivers/gpu/drm/simpledrm/simpledrm.h
+++ b/drivers/gpu/drm/simpledrm/simpledrm.h
@@ -46,6 +46,9 @@ struct sdrm_device {
struct drm_encoder enc;
struct drm_connector conn;
struct drm_display_mode *mode;
+
+   /* fbdev */
+   struct fb_info *fbdev;
 };
 
 int sdrm_drm_load(struct drm_device *ddev, unsigned long flags);
@@ -86,4 +89,23 @@ struct sdrm_framebuffer {
 
 #define to_sdrm_fb(x) container_of(x, struct sdrm_framebuffer, base)
 
+/* simpledrm fbdev helpers */
+
+#ifdef CONFIG_DRM_SIMPLEDRM_FBDEV
+
+void sdrm_fbdev_init(struct sdrm_device *sdrm);
+void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
+
+#else /* CONFIG_DRM_SIMPLEDRM_FBDEV */
+
+static inline void sdrm_fbdev_init(struct sdrm_device *sdrm)
+{
+}
+
+static inline void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
+{
+}
+
+#endif /* CONFIG_DRM_SIMPLEDRM_FBDEV */
+
 #endif /* SDRM_DRV_H */
diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c 
b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
new file mode 100644
index 000..7e2e4a2
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
@@ -0,0 +1,153 @@
+/*
+ * SimpleDRM firmware framebuffer driver
+ * Copyright (c) 2012-2013 David Herrmann 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+/*
+ * fbdev compatibility layer
+ * We provide a basic fbdev device for the same framebuffer that is used for
+ * the pseudo CRTC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "simpledrm.h"
+
+struct sdrm_fbdev {
+   u32 palette[16];
+};
+
+static int sdrm_fbdev_setcolreg(u_int regno, u_int red, u_int green,
+   u_int blue, u_int transp, struct fb_info *info)
+{
+   u32 *pal = info->pseudo_palette;
+   u32 cr = red >> (16 - info->var.red.length);
+   u32 cg = green >> (16 - info->var.green.length);
+   u32 cb = blue >> (16 - info->var.blue.length);
+   u32 value;
+
+   if (regno >= 16)
+   return -EINVAL;
+
+   value = (cr << info->var.red.offset) |
+   (cg << info->var.green.offset) |
+   (cb << info->var.blue.offset);
+
+   if (info->var.transp.length > 0) {
+   u32 mask = (1 << info->var.transp.length) - 1;
+   mask <<= info->var.transp.offset;
+   value |= mask;
+   }
+
+   pal[regno] = value;
+
+   return 0;
+}
+
+static struct fb_ops sdrm_fbdev_ops = {
+   .owner  = THIS_MODULE,
+   .fb_setcolreg   = sdrm_fbdev_setcolreg,
+   .fb_fillrect= cfb_fillrect,
+   .fb_copyarea= cfb_copyarea,
+   .fb_imageblit   = cfb_imageblit,
+};
+
+void sdrm_fbdev_init(struct sdrm_device *sdrm)
+{
+   struct sdrm_fbdev *fb;
+   struct fb_info *info;
+   int ret;
+
+   if (fb_get_options("simpledrmfb", NULL))
+   return;
+
+   info = framebuffer_alloc(sizeof(struct sdrm_fbdev), sdrm->dd

[PATCH v4 3/6] drm: add helpers to kick out firmware drivers

2013-09-01 Thread David Herrmann
If we load a real hardware DRM driver, we want all firmware drivers to be
unloaded. Historically, this was done via
remove_conflicting_framebuffers(), but for DRM drivers (like SimpleDRM) we
need a new way.

This patch introduces DRIVER_FIRMWARE and DRM apertures to provide a quite
similar way to kick out firmware DRM drivers. Additionally, unlike the
fbdev equivalent, DRM firmware drivers can now query the system whether a
real hardware driver is already loaded and prevent loading themselves.

Whenever a real hardware DRM driver is loaded which claims to provide the
boot fw FB, we invalidate the firmware framebuffer. Otherwise, simpledrm
could be loaded again, after a real hw-driver was unloaded (which is
very unlikely to work, except if hw-drivers reset fw FBs during unload).
Note that fbdev doesn't provide such protection against late driver
probing.

Signed-off-by: David Herrmann 
Tested-by: Stephen Warren 
---
 drivers/gpu/drm/drm_pci.c  |   1 +
 drivers/gpu/drm/drm_platform.c |   1 +
 drivers/gpu/drm/drm_stub.c | 118 +
 drivers/gpu/drm/drm_usb.c  |   1 +
 drivers/gpu/drm/simpledrm/simpledrm.h  |   1 +
 drivers/gpu/drm/simpledrm/simpledrm_drv.c  |   3 +-
 drivers/gpu/drm/simpledrm/simpledrm_main.c |  33 
 include/drm/drmP.h |  26 +++
 8 files changed, 183 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 1f96cee..f3de4d6 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -378,6 +378,7 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
}
 
list_add_tail(&dev->driver_item, &driver->device_list);
+   list_add_tail(&dev->global_item, &drm_devlist);
 
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
 driver->name, driver->major, driver->minor, driver->patchlevel,
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index f7a18c6..a287429 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -94,6 +94,7 @@ static int drm_get_platform_dev(struct platform_device 
*platdev,
}
 
list_add_tail(&dev->driver_item, &driver->device_list);
+   list_add_tail(&dev->global_item, &drm_devlist);
 
mutex_unlock(&drm_global_mutex);
 
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index e7eb027..363e47b 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -49,6 +49,10 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
 unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 EXPORT_SYMBOL(drm_timestamp_precision);
 
+static bool drm_fw_invalid;/* true if fw FBs have been destroyed */
+LIST_HEAD(drm_devlist);/* device list; protected by global 
lock */
+EXPORT_SYMBOL(drm_devlist);
+
 /*
  * Default to use monotonic timestamps for wait-for-vblank and page-flip
  * complete events.
@@ -459,7 +463,9 @@ void drm_put_dev(struct drm_device *dev)
 
drm_put_minor(&dev->primary);
 
+   list_del(&dev->global_item);
list_del(&dev->driver_item);
+   kfree(dev->apertures);
kfree(dev->devname);
kfree(dev);
 }
@@ -484,3 +490,115 @@ void drm_unplug_dev(struct drm_device *dev)
mutex_unlock(&drm_global_mutex);
 }
 EXPORT_SYMBOL(drm_unplug_dev);
+
+void drm_unplug_dev_locked(struct drm_device *dev)
+{
+   /* for a USB device */
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   drm_unplug_minor(dev->control);
+   drm_unplug_minor(dev->primary);
+
+   drm_device_set_unplugged(dev);
+
+   /* TODO: schedule drm_put_dev if open_count == 0 */
+}
+EXPORT_SYMBOL(drm_unplug_dev_locked);
+
+#define VGA_FB_PHYS 0xa
+
+static bool apertures_overlap(struct drm_device *dev,
+ struct apertures_struct *ap,
+ bool boot)
+{
+   unsigned int i, j;
+   struct aperture *a, *b;
+
+   if (!dev->apertures)
+   return false;
+
+   for (i = 0; i < dev->apertures->count; ++i) {
+   a = &dev->apertures->ranges[i];
+
+   if (boot && a->base == VGA_FB_PHYS)
+   return true;
+
+   for (j = 0; ap && j < ap->count; ++j) {
+   b = &ap->ranges[j];
+   if (a->base <= b->base && a->base + a->size > b->base)
+   return true;
+   if (b->base <= a->base && b->base + b->size > a->base)
+   return true;
+   }
+   }
+
+   return false;
+}
+
+/**
+ * Kick out firmware
+ *
+ * Virtually unplug any firmware graphics devices which overlap the given
+ * region. This must be called with the global-drm-mutex locked.
+ * This calls the kick_out_firmware() callback on any firmware DRM driver and
+ * after t

[PATCH v4 4/6] drm: nouveau: kick out firmware drivers during probe

2013-09-01 Thread David Herrmann
Use the new DRM infrastructure to kick out firmware drivers before probing
the real driver.

Cc: Maarten Lankhorst 
Cc: Ben Skeggs 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 62c6118..452cc21 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -252,13 +252,11 @@ nouveau_accel_init(struct nouveau_drm *drm)
nouveau_bo_move_init(drm);
 }
 
-static int nouveau_drm_probe(struct pci_dev *pdev,
-const struct pci_device_id *pent)
+static int nouveau_kick_out_firmware(struct drm_device *dev)
 {
-   struct nouveau_device *device;
struct apertures_struct *aper;
bool boot = false;
-   int ret;
+   struct pci_dev *pdev = dev->pdev;
 
/* remove conflicting drivers (vesafb, efifb etc) */
aper = alloc_apertures(3);
@@ -284,8 +282,18 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
 #ifdef CONFIG_X86
boot = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
 #endif
-   remove_conflicting_framebuffers(aper, "nouveaufb", boot);
-   kfree(aper);
+
+   drm_kick_out_firmware(aper, boot);
+   dev->apertures = aper;
+   dev->apert_boot = boot;
+   return 0;
+}
+
+static int nouveau_drm_probe(struct pci_dev *pdev,
+const struct pci_device_id *pent)
+{
+   struct nouveau_device *device;
+   int ret;
 
ret = nouveau_device_create(pdev, nouveau_name(pdev), pci_name(pdev),
nouveau_config, nouveau_debug, &device);
@@ -336,10 +344,14 @@ nouveau_drm_load(struct drm_device *dev, unsigned long 
flags)
struct nouveau_drm *drm;
int ret;
 
-   ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**)&drm);
+   ret = nouveau_kick_out_firmware(dev);
if (ret)
return ret;
 
+   ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**)&drm);
+   if (ret)
+   goto fail_apert;
+
dev->dev_private = drm;
drm->dev = dev;
 
@@ -444,6 +456,9 @@ fail_ttm:
nouveau_vga_fini(drm);
 fail_device:
nouveau_cli_destroy(&drm->client);
+fail_apert:
+   kfree(dev->apertures);
+   dev->apertures = NULL;
return ret;
 }
 
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 5/6] drm/i915: use new drm_kick_out_firmware()

2013-09-01 Thread David Herrmann
Use the new DRM infrastructure to kick out firmware DRM drivers before
loading i915.

Cc: Daniel Vetter 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/i915/i915_dma.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3e4e607..9d375a6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1414,9 +1414,9 @@ static void i915_kick_out_firmware_fb(struct 
drm_i915_private *dev_priv)
primary =
pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
 
-   remove_conflicting_framebuffers(ap, "inteldrmfb", primary);
-
-   kfree(ap);
+   drm_kick_out_firmware(ap, primary);
+   dev_priv->dev->apertures = ap;
+   dev_priv->dev->apert_boot = primary;
 }
 
 static void i915_dump_device_info(struct drm_i915_private *dev_priv)
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 6/6] drm/radeon: use new drm_kick_out_firmware()

2013-09-01 Thread David Herrmann
Kick out firmware DRM and fbdev drivers via the new
drm_kick_out_firmware() before loading radeon.

Cc: Alex Deucher 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 28 
 drivers/gpu/drm/radeon/radeon_kms.c | 30 ++
 2 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 1f93dd5..13f1e15 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -311,37 +311,9 @@ static struct drm_driver driver_old = {
 
 static struct drm_driver kms_driver;
 
-static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
-{
-   struct apertures_struct *ap;
-   bool primary = false;
-
-   ap = alloc_apertures(1);
-   if (!ap)
-   return -ENOMEM;
-
-   ap->ranges[0].base = pci_resource_start(pdev, 0);
-   ap->ranges[0].size = pci_resource_len(pdev, 0);
-
-#ifdef CONFIG_X86
-   primary = pdev->resource[PCI_ROM_RESOURCE].flags & 
IORESOURCE_ROM_SHADOW;
-#endif
-   remove_conflicting_framebuffers(ap, "radeondrmfb", primary);
-   kfree(ap);
-
-   return 0;
-}
-
 static int radeon_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
-   int ret;
-
-   /* Get rid of things like offb */
-   ret = radeon_kick_out_firmware_fb(pdev);
-   if (ret)
-   return ret;
-
return drm_get_pci_dev(pdev, ent, &kms_driver);
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index b46a561..d8f2a38 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -62,6 +62,30 @@ done_free:
return 0;
 }
 
+static int radeon_kick_out_firmware(struct drm_device *dev)
+{
+   struct pci_dev *pdev = dev->pdev;
+   struct apertures_struct *ap;
+   bool primary = false;
+
+   ap = alloc_apertures(1);
+   if (!ap)
+   return -ENOMEM;
+
+   ap->ranges[0].base = pci_resource_start(pdev, 0);
+   ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+#ifdef CONFIG_X86
+   primary = pdev->resource[PCI_ROM_RESOURCE].flags & 
IORESOURCE_ROM_SHADOW;
+#endif
+
+   drm_kick_out_firmware(ap, primary);
+   dev->apertures = ap;
+   dev->apert_boot = primary;
+
+   return 0;
+}
+
 /**
  * radeon_driver_load_kms - Main load function for KMS.
  *
@@ -86,6 +110,12 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
}
dev->dev_private = (void *)rdev;
 
+   r = radeon_kick_out_firmware(dev);
+   if (r) {
+   kfree(rdev);
+   return r;
+   }
+
/* update BUS flag */
if (drm_pci_device_is_agp(dev)) {
flags |= RADEON_IS_AGP;
-- 
1.8.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68503

Vadim Girlin  changed:

   What|Removed |Added

  Attachment #84573|0   |1
is obsolete||

--- Comment #9 from Vadim Girlin  ---
Created attachment 85011
  --> https://bugs.freedesktop.org/attachment.cgi?id=85011&action=edit
[PATCH] r600g/sb: work around hw issues with stack on eg/cm

Here is a new patch that hopefully should not affect performance, please test.

I'm not sure about correctness of workaround condition though, the description
is not very clear, so if it doesn't work as is then please find the following
line in src/gallium/drivers/r600/sb/sb_bc_finalize.cpp (should be line 713):
unsigned depth = elems; // or maybe ifs?
and replace elems with ifs:
unsigned depth = ifs;

If this doesn't help either, try 
unsigned depth = elems + 1;

and "+ 2", "+ 3". And then the same using ifs instead of elems again. One of
these variants should work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68503

Vadim Girlin  changed:

   What|Removed |Added

  Attachment #85011|0   |1
is obsolete||

--- Comment #10 from Vadim Girlin  ---
Created attachment 85013
  --> https://bugs.freedesktop.org/attachment.cgi?id=85013&action=edit
r600g/sb: work around hw issues with stack on eg/cm

Sorry, previous patch was written on top of the first patch from this bug and
requires that patch to be applied first, this one is independent and can be
applied directly on master branch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/radeon/dpm: implement force performance levels for rs780 (v2)

2013-09-01 Thread Anthoine Bourgeois

Allows you to limit the selected power levels via sysfs.

Force the feedback divider to select a power level.

v2: fix checking in rs780_force_fbdiv,
   drop a duplicate divider structure in rs780_dpm_force_performance_level,
   Force the voltage level too.

Signed-off-by: Anthoine Bourgeois 
---
drivers/gpu/drm/radeon/radeon_asic.c |  1 +
drivers/gpu/drm/radeon/radeon_asic.h |  2 +
drivers/gpu/drm/radeon/rs780_dpm.c   | 89 ++--
3 files changed, 77 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index f8f8b31..437d357 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1272,6 +1272,7 @@ static struct radeon_asic rs780_asic = {
.get_mclk = &rs780_dpm_get_mclk,
.print_power_state = &rs780_dpm_print_power_state,
.debugfs_print_current_performance_level = 
&rs780_dpm_debugfs_print_current_performance_level,
+   .force_performance_level = &rs780_dpm_force_performance_level,
},
.pflip = {
.pre_page_flip = &rs600_pre_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 3d61d5a..0d81dbd 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -437,6 +437,8 @@ void rs780_dpm_print_power_state(struct radeon_device *rdev,
 struct radeon_ps *ps);
void rs780_dpm_debugfs_print_current_performance_level(struct radeon_device 
*rdev,
   struct seq_file *m);
+int rs780_dpm_force_performance_level(struct radeon_device *rdev,
+ enum radeon_dpm_forced_level level);

/* uvd */
int r600_uvd_init(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c 
b/drivers/gpu/drm/radeon/rs780_dpm.c
index d1a1ce7..625d6ea 100644
--- a/drivers/gpu/drm/radeon/rs780_dpm.c
+++ b/drivers/gpu/drm/radeon/rs780_dpm.c
@@ -376,9 +376,8 @@ static void rs780_disable_vbios_powersaving(struct 
radeon_device *rdev)
WREG32_P(CG_INTGFX_MISC, 0, ~0xFFF0);
}

-static void rs780_force_voltage_to_high(struct radeon_device *rdev)
+static void rs780_force_voltage(struct radeon_device *rdev, u16 voltage)
{
-   struct igp_power_info *pi = rs780_get_pi(rdev);
struct igp_ps *current_state = rs780_get_ps(rdev->pm.dpm.current_ps);

if ((current_state->max_voltage == RS780_VDDC_LEVEL_HIGH) &&
@@ -390,7 +389,7 @@ static void rs780_force_voltage_to_high(struct 
radeon_device *rdev)
udelay(1);

WREG32_P(FVTHROT_PWM_CTRL_REG0,
-STARTING_PWM_HIGHTIME(pi->max_voltage),
+STARTING_PWM_HIGHTIME(voltage),
 ~STARTING_PWM_HIGHTIME_MASK);

WREG32_P(FVTHROT_PWM_CTRL_REG0,
@@ -404,6 +403,26 @@ static void rs780_force_voltage_to_high(struct 
radeon_device *rdev)
WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
}

+static void rs780_force_fbdiv(struct radeon_device *rdev, u32 fb_div)
+{
+   struct igp_ps *current_state = rs780_get_ps(rdev->pm.dpm.current_ps);
+
+   if (current_state->sclk_low == current_state->sclk_high)
+   return;
+
+   WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL, ~SPLL_BYPASS_CNTL);
+
+   WREG32_P(FVTHROT_FBDIV_REG2, FORCED_FEEDBACK_DIV(fb_div),
+~FORCED_FEEDBACK_DIV_MASK);
+   WREG32_P(FVTHROT_FBDIV_REG1, STARTING_FEEDBACK_DIV(fb_div),
+~STARTING_FEEDBACK_DIV_MASK);
+   WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV, ~FORCE_FEEDBACK_DIV);
+
+   udelay(100);
+
+   WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
+}
+
static int rs780_set_engine_clock_scaling(struct radeon_device *rdev,
  struct radeon_ps *new_ps,
  struct radeon_ps *old_ps)
@@ -432,17 +451,7 @@ static int rs780_set_engine_clock_scaling(struct 
radeon_device *rdev,
if (ret)
return ret;

-   WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL, ~SPLL_BYPASS_CNTL);
-
-   WREG32_P(FVTHROT_FBDIV_REG2, FORCED_FEEDBACK_DIV(max_dividers.fb_div),
-~FORCED_FEEDBACK_DIV_MASK);
-   WREG32_P(FVTHROT_FBDIV_REG1, STARTING_FEEDBACK_DIV(max_dividers.fb_div),
-~STARTING_FEEDBACK_DIV_MASK);
-   WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV, ~FORCE_FEEDBACK_DIV);
-
-   udelay(100);
-
-   WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
+   rs780_force_fbdiv(rdev, max_dividers.fb_div);

if (max_dividers.fb_div > min_dividers.fb_div) {
WREG32_P(FVTHROT_FBDIV_REG0,
@@ -649,7 +658,7 @@ int rs780_dpm_set_power_state(struct radeon_device *rdev)
rs780_set_uvd_clock_before_set_eng_clock(rdev, new_ps, old_ps);

if (pi->voltage_control) {
-   

[PATCH 1/1] drm/exynos: Fix build error with exynos_drm_connector.c

2013-09-01 Thread Sachin Kamat
exynos_drm_connector.c now uses videomode helper API. Hence select
VIDEOMODE_HELPERS at DRM_EXYNOS level itself instead of at
DRM_EXYNOS_FIMD to avoid the following compilation error when FIMD
is not selected (introduced by commit cf796235a6 "drm/exynos: fimd:
replace struct fb_videomode with videomode"):
drivers/built-in.o: In function `exynos_drm_connector_get_modes':
drivers/gpu/drm/exynos/exynos_drm_connector.c:86:
undefined reference to `drm_display_mode_from_videomode'

Signed-off-by: Sachin Kamat 
Cc: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 80a251a..4752f22 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -6,6 +6,7 @@ config DRM_EXYNOS
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
+   select VIDEOMODE_HELPERS
help
  Choose this option if you have a Samsung SoC EXYNOS chipset.
  If M is selected the module will be called exynosdrm.
@@ -26,7 +27,6 @@ config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
select FB_MODE_HELPERS
-   select VIDEOMODE_HELPERS
help
  Choose this option if you want to use Exynos FIMD for DRM.
 
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver

2013-09-01 Thread Rahul Sharma
Exynos hdmiphy operations and configs are kept inside
the hdmi driver. Hdmiphy related code is tightly coupled
with hdmi IP driver.

This patche moves hdmiphy related code to hdmiphy driver.
It will help in cleanly supporting the hdmiphy variations
in further SoCs.

Signed-off-by: Rahul Sharma 
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |2 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h   |   11 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  343 +++
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|  438 +++-
 drivers/gpu/drm/exynos/regs-hdmiphy.h  |   35 ++
 5 files changed, 533 insertions(+), 296 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 50decf8..240eca5 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -25,6 +25,7 @@ Required properties:
sclk_pixel.
 - clock-names: aliases as per driver requirements for above clock IDs:
"hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
+- phy: it points to hdmiphy dt node.
 Example:
 
hdmi {
@@ -32,4 +33,5 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 1>;
+   phy = <&hdmiphy>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 724cab1..1c839f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context 
*ctx);
 void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
 void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
 void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
+
+int exynos_hdmiphy_driver_register(void);
+void exynos_hdmiphy_driver_unregister(void);
+
+void exynos_hdmiphy_enable(struct device *dev);
+void exynos_hdmiphy_disable(struct device *dev);
+int exynos_hdmiphy_check_mode(struct device *dev,
+   struct drm_display_mode *mode);
+int exynos_hdmiphy_set_mode(struct device *dev,
+   struct drm_display_mode *mode);
+int exynos_hdmiphy_conf_apply(struct device *dev);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f67ffca..3af4e4c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,6 +34,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -172,7 +174,6 @@ struct hdmi_v14_conf {
 };
 
 struct hdmi_conf_regs {
-   int pixel_clock;
int cea_video_id;
union {
struct hdmi_v13_conf v13_conf;
@@ -193,9 +194,9 @@ struct hdmi_context {
int irq;
 
struct i2c_client   *ddc_port;
-   struct i2c_client   *hdmiphy_port;
+   struct device   *hdmiphy_dev;
 
-   /* current hdmiphy conf regs */
+   /* current hdmi ip configuration registers. */
struct hdmi_conf_regs   mode_conf;
 
struct hdmi_resources   res;
@@ -205,180 +206,6 @@ struct hdmi_context {
enum hdmi_type  type;
 };
 
-struct hdmiphy_config {
-   int pixel_clock;
-   u8 conf[32];
-};
-
-/* list of phy config settings */
-static const struct hdmiphy_config hdmiphy_v13_configs[] = {
-   {
-   .pixel_clock = 2700,
-   .conf = {
-   0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
-   0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
-   0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
-   0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
-   },
-   },
-   {
-   .pixel_clock = 27027000,
-   .conf = {
-   0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
-   0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
-   0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
-   0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
-   },
-   },
-   {
-   .pixel_clock = 74176000,
-   .conf = {
-   0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
-   0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54, 0xb9,
-   0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
-   0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00, 0x00,
-   },
-   },
-   {
-   .pixel_clock = 7425,
-   .conf = {
-   0x01, 0x05, 0x00, 0xd8, 0x10

[PATCH 2/7] drm/exynos: remove dummy hdmiphy clock

2013-09-01 Thread Rahul Sharma
hdmiphy is a dummy clock which actually controls the PMU bit
to enable/disbale hdmiphy (before CCF). This clock is cleaned
from the hdmi driver.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3af4e4c..cd1d921 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -84,7 +84,6 @@ struct hdmi_resources {
struct clk  *sclk_hdmi;
struct clk  *sclk_pixel;
struct clk  *sclk_hdmiphy;
-   struct clk  *hdmiphy;
struct clk  *mout_hdmi;
struct regulator_bulk_data  *regul_bulk;
int regul_count;
@@ -1431,7 +1430,6 @@ static void hdmi_poweron(struct hdmi_context *hdata)
if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
DRM_DEBUG_KMS("failed to enable regulator bulk\n");
 
-   clk_prepare_enable(res->hdmiphy);
clk_prepare_enable(res->hdmi);
clk_prepare_enable(res->sclk_hdmi);
 
@@ -1456,7 +1454,6 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
 
clk_disable_unprepare(res->sclk_hdmi);
clk_disable_unprepare(res->hdmi);
-   clk_disable_unprepare(res->hdmiphy);
regulator_bulk_disable(res->regul_count, res->regul_bulk);
 
mutex_lock(&hdata->hdmi_mutex);
@@ -1549,11 +1546,6 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
goto fail;
}
-   res->hdmiphy = devm_clk_get(dev, "hdmiphy");
-   if (IS_ERR(res->hdmiphy)) {
-   DRM_ERROR("failed to get clock 'hdmiphy'\n");
-   goto fail;
-   }
res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
if (IS_ERR(res->mout_hdmi)) {
DRM_ERROR("failed to get clock 'mout_hdmi'\n");
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

2013-09-01 Thread Rahul Sharma
Currently, exynos hdmiphy operations and configs are kept
inside the hdmi driver. Hdmiphy related code is tightly
coupled with hdmi IP driver.

This series also removes hdmiphy dummy clock for hdmiphy
and replace it with Phy PMU Control from the hdmiphy driver.

At the end, support for exynos5420 hdmiphy is added to the
hdmiphy driver which is a platform device.

Drm related paches are based on exynos-drm-next branch at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Arch patches are dependent on 
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg22195.html

Rahul Sharma (7):
  drm/exynos: move hdmiphy related code to hdmiphy driver
  drm/exynos: remove dummy hdmiphy clock
  drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
  drm/exynos: add support for exynos5420 hdmiphy
  exynos/drm: fix ddc i2c device probe failure
  ARM: dts: update hdmiphy dt node for exynos5250
  ARM: dts: update hdmiphy dt node for exynos5420

 .../devicetree/bindings/video/exynos_hdmi.txt  |2 +
 .../devicetree/bindings/video/exynos_hdmiphy.txt   |6 +
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |9 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   12 +
 drivers/gpu/drm/exynos/exynos_ddc.c|5 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h   |   13 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  353 ++
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|  738 +++-
 drivers/gpu/drm/exynos/regs-hdmiphy.h  |   35 +
 9 files changed, 868 insertions(+), 305 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/7] drm/exynos: add hdmiphy pmu bit control in hdmiphy driver

2013-09-01 Thread Rahul Sharma
Before hdmiphy operation like config, start etc, hdmiphy
bit in PMU block should be enabled. Earlier this happens
in hdmi drvier through a dummy "hdmiphy" clock.

Signed-off-by: Rahul Sharma 
---
 .../devicetree/bindings/video/exynos_hdmiphy.txt   |6 ++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h   |2 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|   82 
 4 files changed, 92 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 162f641..f6bf096 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -6,10 +6,16 @@ Required properties:
2) "samsung,exynos4210-hdmiphy".
3) "samsung,exynos4212-hdmiphy".
 - reg: I2C address of the hdmiphy device.
+- phy-power-control: this child node represents phy power control
+   register which is inside the pmu block (power management unit).
 
 Example:
 
hdmiphy {
compatible = "samsung,exynos4210-hdmiphy";
reg = <0x38>;
+
+   phy-power-control {
+   reg = <0x10040700 0x04>;
+   };
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 1c839f8..9a14f96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -68,6 +68,8 @@ void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
 int exynos_hdmiphy_driver_register(void);
 void exynos_hdmiphy_driver_unregister(void);
 
+void exynos_hdmiphy_poweron(struct device *dev);
+void exynos_hdmiphy_poweroff(struct device *dev);
 void exynos_hdmiphy_enable(struct device *dev);
 void exynos_hdmiphy_disable(struct device *dev);
 int exynos_hdmiphy_check_mode(struct device *dev,
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index cd1d921..a6234fc 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1131,6 +1131,7 @@ static void hdmiphy_poweron(struct hdmi_context *hdata)
if (hdata->type == HDMI_TYPE14)
hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0,
HDMI_PHY_POWER_OFF_EN);
+   exynos_hdmiphy_poweron(hdata->hdmiphy_dev);
 }
 
 static void hdmiphy_poweroff(struct hdmi_context *hdata)
@@ -1138,6 +1139,7 @@ static void hdmiphy_poweroff(struct hdmi_context *hdata)
if (hdata->type == HDMI_TYPE14)
hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0,
HDMI_PHY_POWER_OFF_EN);
+   exynos_hdmiphy_poweroff(hdata->hdmiphy_dev);
 }
 
 static void hdmi_conf_apply(struct hdmi_context *hdata)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c 
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index 82daa42..b1b8a0f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -30,6 +30,9 @@ struct hdmiphy_context {
struct device   *dev;
struct hdmiphy_config   *current_conf;
 
+   /* hdmiphy resources */
+   void __iomem*phy_pow_ctrl_reg;
+
struct hdmiphy_config   *confs;
unsigned intnr_confs;
 };
@@ -225,6 +228,49 @@ static struct hdmiphy_config *hdmiphy_find_conf(struct 
hdmiphy_context *hdata,
return NULL;
 }
 
+static int hdmiphy_dt_parse_power_control(struct hdmiphy_context *hdata)
+{
+   struct device_node *phy_pow_ctrl_node;
+   u32 buf[2];
+   int ret = 0;
+
+   phy_pow_ctrl_node = of_get_child_by_name(hdata->dev->of_node,
+   "phy-power-control");
+   if (!phy_pow_ctrl_node) {
+   DRM_ERROR("Failed to find phy power control node\n");
+   ret = -ENODEV;
+   goto fail;
+   }
+
+   /* reg property holds two informations: addr of pmu register, size */
+   if (of_property_read_u32_array(phy_pow_ctrl_node, "reg",
+   (u32 *)&buf, 2)) {
+   DRM_ERROR("faild to get phy power control reg\n");
+   ret = -EINVAL;
+   goto fail;
+   }
+
+   hdata->phy_pow_ctrl_reg = devm_ioremap(hdata->dev, buf[0], buf[1]);
+   if (!hdata->phy_pow_ctrl_reg) {
+   DRM_ERROR("failed to ioremap phy pmu reg\n");
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+fail:
+   of_node_put(phy_pow_ctrl_node);
+   return ret;
+}
+
+static inline void hdmiphy_pow_ctrl_reg_writemask(
+   struct hdmiphy_context *hdata,
+   u32 value, u32 mask)
+{
+   u32 old = readl(hdata->phy_pow_ctrl_reg);
+   value = (value & mask) | (old & ~mask);
+   writel(value, hdata->phy_pow_ctrl_reg);
+}
+
 static int hdmiphy_reg_writeb(struct hdmiphy_context *hdata,
  

[PATCH 4/7] drm/exynos: add support for exynos5420 hdmiphy

2013-09-01 Thread Rahul Sharma
Exynos5420 hdmiphy device is a platform device, unlike
predecessor SoCs where it used to be a I2C device. This
support is added to the hdmiphy driver.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmiphy.c |  224 ++-
 1 file changed, 221 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c 
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index b1b8a0f..33e89d9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -32,6 +32,7 @@ struct hdmiphy_context {
 
/* hdmiphy resources */
void __iomem*phy_pow_ctrl_reg;
+   void __iomem*regs;
 
struct hdmiphy_config   *confs;
unsigned intnr_confs;
@@ -48,6 +49,135 @@ struct hdmiphy_drv_data {
 };
 
 /* list of all required phy config settings */
+static struct hdmiphy_config hdmiphy_5420_configs[] = {
+   {
+   .pixel_clock = 2520,
+   .conf = {
+   0x01, 0x52, 0x3F, 0x55, 0x40, 0x01, 0x00, 0xC8,
+   0x82, 0xC8, 0xBD, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x06, 0x80, 0x01, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xF4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 2700,
+   .conf = {
+   0x01, 0xD1, 0x22, 0x51, 0x40, 0x08, 0xFC, 0xE0,
+   0x98, 0xE8, 0xCB, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xE4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 27027000,
+   .conf = {
+   0x01, 0xD1, 0x2D, 0x72, 0x40, 0x64, 0x12, 0xC8,
+   0x43, 0xE8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xE3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 3600,
+   .conf = {
+   0x01, 0x51, 0x2D, 0x55, 0x40, 0x40, 0x00, 0xC8,
+   0x02, 0xC8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xAB, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 4000,
+   .conf = {
+   0x01, 0xD1, 0x21, 0x31, 0x40, 0x3C, 0x28, 0xC8,
+   0x87, 0xE8, 0xC8, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0x9A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 6500,
+   .conf = {
+   0x01, 0xD1, 0x36, 0x34, 0x40, 0x0C, 0x04, 0xC8,
+   0x82, 0xE8, 0x45, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xBD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 7100,
+   .conf = {
+   0x01, 0xD1, 0x3B, 0x35, 0x40, 0x0C, 0x04, 0xC8,
+   0x85, 0xE8, 0x63, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0x57, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 74176000,
+   .conf = {
+   0x01, 0xD1, 0x1F, 0x10, 0x40, 0x5B, 0xEF, 0xC8,
+   0x81, 0xE8, 0xB9, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xA6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 7425,
+   .conf = {
+   0x01, 0xD1, 0x1F, 0x10, 0x40, 0x40, 0xF8, 0xC8,
+   0x81, 0xE8, 0xBA, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0xA5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 8350,
+   .conf = {
+   0x01, 0xD1, 0x23, 0x11, 0x40, 0x0C, 0xFB, 0xC8,
+   0x85, 0xE8, 0xD1, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+   0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+   0x54, 0x4A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
+   .pixel_clock = 10650,
+   .conf = {
+   0x01

[PATCH 5/7] exynos/drm: fix ddc i2c device probe failure

2013-09-01 Thread Rahul Sharma
Exynos hdmi ddc is a I2C device and if we register hdmi ddc
driver with id_table as NULL, cause failure in probing.

id_table field should not be NULL for i2c_driver registeration.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_ddc.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 6a8c84e..54ead55 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -51,12 +51,17 @@ static struct of_device_id hdmiddc_match_types[] = {
}
 };
 
+static struct i2c_device_id ddc_idtable[] = {
+   { },
+};
+
 struct i2c_driver ddc_driver = {
.driver = {
.name = "exynos-hdmiddc",
.owner = THIS_MODULE,
.of_match_table = hdmiddc_match_types,
},
+   .id_table   = ddc_idtable,
.probe  = s5p_ddc_probe,
.remove = s5p_ddc_remove,
.command= NULL,
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 6/7] ARM: dts: update hdmiphy dt node for exynos5250

2013-09-01 Thread Rahul Sharma
hdmiphy dt node needs a child node called 'phy-power-control'
which represents the PMU register for power controlling the
hdmiphy.

hdmi driver dt node provides phy property which points to
the hdmiphy dt node.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 49f18c2..99a83412 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -134,9 +134,15 @@
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
 
-   hdmiphy@38 {
+   hdmiphy: hdmiphy@38 {
compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   phy-power-control {
+   reg = <0x10040700 0x04>;
+   };
};
};
 
@@ -220,6 +226,7 @@
 
hdmi {
hpd-gpio = <&gpx3 7 0>;
+   phy = <&hdmiphy>;
};
 
codec@1100 {
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 7/7] ARM: dts: update hdmiphy dt node for exynos5420

2013-09-01 Thread Rahul Sharma
hdmiphy dt node needs a child node called 'phy-power-control'
which represents the PMU register for power controlling the
hdmiphy.

hdmi driver dt node provides phy property which points to
the hdmiphy dt node.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index ed687ac..5262781 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -215,6 +215,18 @@
clock-names = "hdmi", "sclk_hdmi", "sclk_pixel",
"sclk_hdmiphy", "mout_hdmi";
status = "disabled";
+   phy = <&hdmiphy>;
+   };
+
+   hdmiphy: hdmiphy@145D {
+   compatible = "samsung,exynos5420-hdmiphy";
+   reg = <0x145D 0x20>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   phy-power-control {
+   reg = <0x10040700 0x04>;
+   };
};
 
mixer@1445 {
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 2/3] drm/panel: Add simple panel support

2013-09-01 Thread Kumar Gala

On Aug 30, 2013, at 10:25 AM, Thierry Reding wrote:

> Add a driver for simple panels. Such panels can have a regulator that
> provides the supply voltage and a separate GPIO to enable the panel.
> Optionally the panels can have a backlight associated with them so it
> can be enabled or disabled according to the panel's power management
> mode.
> 
> Support is added for three panels: An AU Optronics 10.1" WSVGA, a
> Chunghwa Picture Tubes 10.1" WXGA and a Panasonic 10.1 WUXGA TFT LCD
> panel.
> 
> Signed-off-by: Thierry Reding 
> ---
> .../devicetree/bindings/panel/panel-simple.txt |  25 ++
> drivers/gpu/drm/Makefile   |   1 +
> drivers/gpu/drm/panel/Kconfig  |  13 +
> drivers/gpu/drm/panel/Makefile |   1 +
> drivers/gpu/drm/panel/panel-simple.c   | 335 +
> 5 files changed, 375 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/panel/panel-simple.txt
> create mode 100644 drivers/gpu/drm/panel/Makefile
> create mode 100644 drivers/gpu/drm/panel/panel-simple.c
> 
> diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt 
> b/Documentation/devicetree/bindings/panel/panel-simple.txt
> new file mode 100644
> index 000..dfd4b76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panel-simple.txt
> @@ -0,0 +1,25 @@
> +Simple display panel
> +
> +Required properties:
> +- compatible: should be one of:
> +  - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> +  - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> +  - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel
> +

It would seem there should be a more generic compatible to cover the basic 
"panel-simple" case.

> +Optional properties:
> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> +- power-supply: regulator to provide the supply voltage
> +- enable-gpios: GPIO pin to enable or disable the panel
> +- backlight: phandle of the backlight device attached to the panel
> +

If these are all optional, what does it mean to be a "panel-simple"?

> +Example:
> +
> + panel: panel {
> + compatible = "cptt,claa101wb01";
> + ddc-i2c-bus = <&panelddc>;
> +
> + power-supply = <&vdd_pnl_reg>;
> + enable-gpios = <&gpio 90 0>;
> +
> + backlight = <&backlight>;
> + };

We'd normally do this as unique binding specs for the specific devices and a 
generic one to cover the concepts of a simple panel.  Who know if in the future 
a 'auo,b101aw03' might want some other unique properties.

[snip]

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68783] Segmentation fault on BONAIRE (hd7790) after starting X server

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68783

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #4 from Alex Deucher  ---


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

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 66673] NULL pointer dereference on BONAIRE (hd7790) after starting X server

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=66673

Alex Deucher  changed:

   What|Removed |Added

 CC||nrn...@gmail.com

--- Comment #4 from Alex Deucher  ---
*** Bug 68783 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68585

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Alex Deucher  ---
fixed in:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=89a665eb5fa176f68223bf54a472d6a0567c3546

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68708] Intel+Radeon Hybrid laptop hang on boot while being on the battery

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68708

--- Comment #6 from Alex Deucher  ---
(In reply to comment #5)
> Thank you, Alex. I've tested this patch (booted on battery, plugged in and
> disconnected charger, suspended and resumed) and it works nicely.
> Will this patch come to the stable branch of 3.11?

Yes.  It should show up in the 3.11 tree eventually.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=52952

--- Comment #22 from Alex Deucher  ---
(In reply to comment #21)
> (In reply to Comment 19)
> 
> Hi Alex,
> 
> Is it possible you or someone can backport the fix so that this issue can be
> resolved on Ubuntu 10.04 LTS (Linux 2.6.32 kernel) and Ubuntu 12.04 LTS
> (Linux 3.2 kernel)?
> It will be nice if the fix can be applied via apt-get.

It will show up in stable kernels eventually.  However, it would be nice if you
could actually test and verify the fix for your specific system.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #11 from kwah...@wp.pl ---
I patched after first patch (not master Mesa) and there i no artifacts neither
performance improvement. I didn't change anything in code.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68708] Intel+Radeon Hybrid laptop hang on boot while being on the battery

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68708

Hohahiu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] drm fixes

2013-09-01 Thread Linus Torvalds
On Sat, Aug 31, 2013 at 4:02 PM, Linus Torvalds
 wrote:
>
> Any known issues with DVI on Haswell (it seems to show up as "HDMI1"
> as the output, but it's a DVI cable)?

With a DP cable and the same monitor, the problem doesn't seem to
occur. So it does seem to somehow be related to the HDMI1/DVI output.

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 60827] X under radeon driver crashes after resuming from hibernation

2013-09-01 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=60827

Lan Tianyu  changed:

   What|Removed |Added

 CC||tianyu@intel.com
  Component|Hibernation/Suspend |Video(DRI - non Intel)
   Assignee|r...@rjwysocki.net   |drivers_video-dri@kernel-bu
   ||gs.osdl.org
Product|Power Management|Drivers

--- Comment #1 from Lan Tianyu  ---
This should be a gpu issue rather then hibernation/suspend bug. So reassign to
associated category.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 68805] 48 fps and 50 fps video decoding is stutter on UVD

2013-09-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=68805

--- Comment #3 from russianneuroman...@ya.ru ---
While playback this sample video:
uvdvclk: 53334 dclk: 4
power level 0sclk: 49231 vddc: 975

Quote from dmesg:
[147358.038752] switching from power state:
[147358.038772] ui class: performance
[147358.038778] internal class: none
[147358.038782] caps: 
[147358.038787] uvdvclk: 0 dclk: 0
[147358.038793] power level 0sclk: 27827 vddc: 900
[147358.038796] power level 1sclk: 49231 vddc: 975
[147358.038799] status: c 
[147358.038803] switching to power state:
[147358.038805] ui class: none
[147358.038807] internal class: uvd 
[147358.038811] caps: 
[147358.038814] uvdvclk: 53334 dclk: 4
[147358.038817] power level 0sclk: 49231 vddc: 975
[147358.038819] status: r

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

2013-09-01 Thread Inki Dae
Hi Rahul,

> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Rahul Sharma
> Sent: Friday, August 30, 2013 7:06 PM
> To: Inki Dae
> Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
> Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
> Nawrocki; sunil joshi
> Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
> 
> Thanks Mr. Dae,
> 
> I have some points for discussion.
> 
> On 30 August 2013 14:03, Inki Dae  wrote:
> > Hi Rahul.
> >
> > Thanks for your patch set.
> >
> > I had just quick review to all patch series. And I think we could fully
> hide
> > hdmiphy interfaces,
> > exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
> > driver.
> > That may be prototyped like below,
> >
> > at exynos_hdmi.h
> >
> > /* Define hdmiphy callbacks. */
> > struct exynos_hdmiphy_ops {
> > void (*enable)(struct device *dev);
> > void (*disable)(struct device *dev);
> > int (*check_mode)(struct device *dev, struct drm_display_mode
> > *mode);
> > int (*set_mode)(struct device *dev, struct drm_display_mode
*mode);
> > int (*apply)(struct device *dev);
> > };
> >
> 
> Above looks fine to me. I will hide the ops as you suggested.
> 
> >
> > at exynos_hdmi.c
> >
> > /*
> >   * Add a new structure for hdmi driver data.
> >   * type could be HDMI_TYPE13 or HDMI_TYPE14.
> >   * i2c_hdmiphy could be true or false: true means that current hdmi
> device
> > uses i2c
> >   * based hdmiphy device, otherwise platform device based one.
> >   */
> > struct hdmi_drv_data {
> > unsigned int type;
> > unsigned int i2c_hdmiphy;
> > };
> >
> > ...
> >
> > /* Add new members to hdmi context. */
> > struct hdmi_context {
> > ...
> > struct hdmi_drv_data *drv_data;
> > struct hdmiphy_ops *ops;
> > ...
> > };
> >
> >
> > /* Add hdmi device data according Exynos SoC. */
> > static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
> > .type = HDMI_TYPE14,
> > .i2c_hdmiphy = true
> > };
> >
> > static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
> > .type = HDMI_TYPE14,
> > .i2c_hdmiphy = false
> > };
> >
> >
> > static struct of_device_id hdmi_match_types[] = {
> > {
> > .compatible = "samsung,exynos4212-hdmi",
> > .data   = (void *)&exynos4212_hdmi_drv_data,
> > }, {
> > ...
> >
> > .compatible = "samsung,exynos5420-hdmi",
> > .data   = (void *)&exynos5420_hdmi_drv_data,
> > }, {
> > }
> > };
> >
> > /* the below example function shows how hdmiphy interfaces can be hided
> from
> > hdmi driver. */
> > static void hdmi_mode_set(...)
> > {
> > ...
> > hdata->ops->set_mode(hdata->hdmiphy_dev, mode);
> 
> This looks fine.
> 
> > }
> >
> > static int hdmi_get_phy_device(struct hdmi_context *hdata)
> > {
> > struct hdmi_drv_data *data = hdata->drv_data;
> >
> > ...
> > /* Register hdmiphy driver according to i2c_hdmiphy value. */
> > ret = exynos_hdmiphy_driver_register(data->i2c_hdmiphy);
> > ...
> > /* Get hdmiphy driver ops according to i2c_hdmiphy value. */
> > hdata->ops = exynos_hdmiphy_get_ops(data->i2c_hdmiphy);
> > ...
> > }
> >
> >
> > at exynos_hdmiphy.c
> >
> > /* Define hdmiphy ops respectively. */
> > struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
> > .enable = exynos_hdmiphy_i2c_enable,
> > .disable = exynos_hdmiphy_i2c_disable,
> > ...
> > };
> >
> > struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
> > .enable = exynos_hdmiphy_platdev_enable,
> > .disable = exynos_hdmiphy_platdev_disable,
> > ...
> > };
> 
> Actually, Ops for Hdmiphy I2c and platform devices are exactly
> same. We don't need 2 sets. Only difference is in static function to
> write configuration values to phy. Based on i2c_verify_client(hdata->dev),
> we use i2c_master_send or writeb.
> 
> >
> > struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
> i2c_hdmiphy)
> > {
> > /* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
> > if (i2c_hdmiphy)
> > return &hdmiphy_i2c_ops;
> >
> > return &hdmiphy_platdev_ops;
> > }
> 
> We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
> this information is available in hdmiphy driver itself.
> 
> >
> > int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
> > {
> > ...
> > /* Register hdmiphy driver appropriately according to
i2c_hdmiphy.
> > */
> > if (i2c_hdmiphy) {
> > ret = i2c_add_driver(&hdmiphy_i2c_driver);
> > ...
> > } else {
> > ret =
platform_driver_register(&hdmiphy_platform_driver);
> > ...
> > 

Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver

2013-09-01 Thread Rahul Sharma
On 2 September 2013 10:38, Inki Dae  wrote:
> Hi Rahul,
>
>> -Original Message-
>> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
>> ow...@vger.kernel.org] On Behalf Of Rahul Sharma
>> Sent: Friday, August 30, 2013 7:06 PM
>> To: Inki Dae
>> Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
>> Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
>> Nawrocki; sunil joshi
>> Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
>> driver
>>
>> Thanks Mr. Dae,
>>
>> I have some points for discussion.
>>
>> On 30 August 2013 14:03, Inki Dae  wrote:
>> > Hi Rahul.
>> >
>> > Thanks for your patch set.
>> >
>> > I had just quick review to all patch series. And I think we could fully
>> hide
>> > hdmiphy interfaces,
>> > exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
>> > driver.
>> > That may be prototyped like below,
>> >
>> > at exynos_hdmi.h
>> >
>> > /* Define hdmiphy callbacks. */
>> > struct exynos_hdmiphy_ops {
>> > void (*enable)(struct device *dev);
>> > void (*disable)(struct device *dev);
>> > int (*check_mode)(struct device *dev, struct drm_display_mode
>> > *mode);
>> > int (*set_mode)(struct device *dev, struct drm_display_mode
> *mode);
>> > int (*apply)(struct device *dev);
>> > };
>> >
>>
>> Above looks fine to me. I will hide the ops as you suggested.
>>
>> >
>> > at exynos_hdmi.c
>> >
>> > /*
>> >   * Add a new structure for hdmi driver data.
>> >   * type could be HDMI_TYPE13 or HDMI_TYPE14.
>> >   * i2c_hdmiphy could be true or false: true means that current hdmi
>> device
>> > uses i2c
>> >   * based hdmiphy device, otherwise platform device based one.
>> >   */
>> > struct hdmi_drv_data {
>> > unsigned int type;
>> > unsigned int i2c_hdmiphy;
>> > };
>> >
>> > ...
>> >
>> > /* Add new members to hdmi context. */
>> > struct hdmi_context {
>> > ...
>> > struct hdmi_drv_data *drv_data;
>> > struct hdmiphy_ops *ops;
>> > ...
>> > };
>> >
>> >
>> > /* Add hdmi device data according Exynos SoC. */
>> > static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
>> > .type = HDMI_TYPE14,
>> > .i2c_hdmiphy = true
>> > };
>> >
>> > static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
>> > .type = HDMI_TYPE14,
>> > .i2c_hdmiphy = false
>> > };
>> >
>> >
>> > static struct of_device_id hdmi_match_types[] = {
>> > {
>> > .compatible = "samsung,exynos4212-hdmi",
>> > .data   = (void *)&exynos4212_hdmi_drv_data,
>> > }, {
>> > ...
>> >
>> > .compatible = "samsung,exynos5420-hdmi",
>> > .data   = (void *)&exynos5420_hdmi_drv_data,
>> > }, {
>> > }
>> > };
>> >
>> > /* the below example function shows how hdmiphy interfaces can be hided
>> from
>> > hdmi driver. */
>> > static void hdmi_mode_set(...)
>> > {
>> > ...
>> > hdata->ops->set_mode(hdata->hdmiphy_dev, mode);
>>
>> This looks fine.
>>
>> > }
>> >
>> > static int hdmi_get_phy_device(struct hdmi_context *hdata)
>> > {
>> > struct hdmi_drv_data *data = hdata->drv_data;
>> >
>> > ...
>> > /* Register hdmiphy driver according to i2c_hdmiphy value. */
>> > ret = exynos_hdmiphy_driver_register(data->i2c_hdmiphy);
>> > ...
>> > /* Get hdmiphy driver ops according to i2c_hdmiphy value. */
>> > hdata->ops = exynos_hdmiphy_get_ops(data->i2c_hdmiphy);
>> > ...
>> > }
>> >
>> >
>> > at exynos_hdmiphy.c
>> >
>> > /* Define hdmiphy ops respectively. */
>> > struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
>> > .enable = exynos_hdmiphy_i2c_enable,
>> > .disable = exynos_hdmiphy_i2c_disable,
>> > ...
>> > };
>> >
>> > struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
>> > .enable = exynos_hdmiphy_platdev_enable,
>> > .disable = exynos_hdmiphy_platdev_disable,
>> > ...
>> > };
>>
>> Actually, Ops for Hdmiphy I2c and platform devices are exactly
>> same. We don't need 2 sets. Only difference is in static function to
>> write configuration values to phy. Based on i2c_verify_client(hdata->dev),
>> we use i2c_master_send or writeb.
>>
>> >
>> > struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
>> i2c_hdmiphy)
>> > {
>> > /* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
>> > if (i2c_hdmiphy)
>> > return &hdmiphy_i2c_ops;
>> >
>> > return &hdmiphy_platdev_ops;
>> > }
>>
>> We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
>> this information is available in hdmiphy driver itself.
>>
>> >
>> > int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
>> > {
>> > ...
>> > /* Register hdmiphy driver appropriately according to
> i2c_hdmiphy.
>> > */
>> > if (i2c_hdmiphy) {
>> > 

Re: [git pull] drm fixes

2013-09-01 Thread Daniel Vetter
On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote:
> Hmm. I just updated my machine to a i7-4770S (kept everything else the
> same, just switched out motherboards), and now when my display goes to
> sleep, it seems to never come back.

Sleep as in dpms off ($ xset dpms force off) or sleep as in system
suspend?

> Any known issues with DVI on Haswell (it seems to show up as "HDMI1"
> as the output, but it's a DVI cable)? I need to get a DP cable anyway
> (right now I'm driving my 2560x1440 display at 32Hz due to DVI crap)
> and maybe that will fix things, but this happens even if I don't force
> that odd mode (so it maxes out at 1920x1200 or whatever).
> 
> I doubt this is new, but I've only ever run current -git on this
> machine, so who knows..  The machine ends up being kind of unusable. I
> guess I can just turn off power save.

Hm, doesn't ring a bell here. Adding Paulo, our residential hsw display
expert.

Aside hsw hdmi ports support 300MHz dotclocks, but still only single-link.
So I guess your dvi screen is still out of luck since it likely wants a
dual-link dvi signal. But if you have a hdmi port it should work a bit
better (hdmi pumped up the max dotclock a bit already a while ago ...).

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