[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=84500

--- Comment #38 from Alexandre Demers  ---
For the last couple of days, I've been playing with kernel 3.19 drm-next and
with some previously problematic 3.18 kernel versions. I was unable to
reproduce the problem.

Mesa was updated a couple of time since the beginning of the bisection, as for
the ddx drive. I'll keep this bug open for still a couple of days, but I may
end up closing it if I don't encounter the bug anymore.

-- 
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/20141117/a9d38f9a/attachment.html>


linux-next: manual merge of the drm tree with the drm-intel-fixes tree

2014-11-17 Thread Stephen Rothwell
Hi Dave,

Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit 6bc55a67bd4b ("drm/i915:
drop WaSetupGtModeTdRowDispatch:snb") from the drm-intel-fixes tree and
commits (not sure which ones - the code seems to have been rearranged
quite a bit) from the drm tree.

I fixed it up (I applied the former patch by hand to the file from the
drm tree) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141117/5f5de183/attachment.sig>


[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73528

--- Comment #17 from Michel Dänzer  ---
The situation hasn't changed since comment #13:

At this point, there's no way to make progress on this bug without someone who
can reproduce the problem and investigate or at least bisect it. It's up to you
if you want to look for someone else who fits the bill, or just bisect
yourself.

-- 
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/20141117/8ab2dcb9/attachment.html>


[Bug 86368] BUILD FAILED: why : forced (dist) upgrade for gcc 3.4.6 over a BIT COUNT, __builtin_ctz

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86368

Bug ID: 86368
   Summary: BUILD FAILED: why : forced (dist) upgrade for gcc
3.4.6 over a BIT COUNT, __builtin_ctz
   Product: DRI
   Version: DRI git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: johnandsara2 at cox.net

__builtin_ctz

see patch below, at end

just counts a few bits at most.  possibly it's builtin because some plats have
accel asm in their kernel can use.  my mileage is not all accel for i386 are in
linux yet, and the (amd64) ones that are are for tend to be used needlessly and
sparsely in distro installer code - possibly to cause dependancy issues where
they really aren't needed though hardly used.

__builtin_ctz first appears in gcc-3.4.6

https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Other-Builtins.html#Other-Builtins

$ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
# yes, i did build R7.6 w/ i915 on old sarge (target is a few pc's)

the fix below doesn't use any hw accel call, pow or F2XM1 anything elegant, but
it works (and won't ask for fpu if bus busy)

if i upgrade is anyone sending me all new hw ?  gee thanks!  and really i hear
someone is hacking gcc to be c++ "driven" to force c++ typing in C.  wretched. 
the more type info you give c++ the more it requires and fails.  and most
warnings and some errors are K&R C WRONG today.  if default is void or int or
PTR (int) and programmer doesn't say: be quiet the rule already has a default:
a hardware size.  C will convert to size, or not if there is no asm that can:
that is the rule in the book it should be assumed it's what programmer INTENDED
EXACTLY: not a new error.  any breakage and troubled should be had by those
specifying an option looking for such c++ trouble.  don't be adding in forced
c++ brain damage contrived error to what is  correct gcc bison parsed c to
varasm.c then output, right?  thanks for reading that wish.

finally.  i rue everyone compiling against latest libs if earlier ones suffice,
and a policy of never fixing breakage in older libs (which before the 2000's
was not done: they fixed it).  it causes dependancy issue havoc to go another
BIG-OH higher.  as well often minor lib versions cause breakage: they aren't
supposed to, minors are supposed to be still compatible.

the diff below may apply though used on newer version: but it's pretty obvious
what diff suggests

$ cd libdrm-2.4.20/radeon

$ diff -Naru radeon_cs_gem.c.old radeon_cs_gem.c.new
--- radeon_cs_gem.c.old 2014-11-16 23:44:55.0 -0500
+++ radeon_cs_gem.c.new 2014-11-16 22:28:53.0 -0500
@@ -76,14 +76,29 @@
 /**
  * result is undefined if called with ~0
  */
+  /* __builtin_ctz returns number of trailing zeros. */
 /*
 static uint32_t get_first_zero(const uint32_t n)
 {
-/* __builtin_ctz returns number of trailing zeros. */
 return 1 << __builtin_ctz(~n);
 }
 */

+#include 
+static uint32_t get_first_zero(const uint32_t n)
+{
+   unsigned int x,i, s, nn ;
+   nn=(unsigned int) n;
+   x=0;i=0;s=sizeof(n);
+   for(i=1;i<=sizeof(n)*CHAR_BIT;++i)
+   {
+ if( (nn & 1) == 0 ) ++x; else break;
+ nn=nn>>1;
+   }
+   return (uint32_t) x;
+}
+
+
 /**
  * Returns a free id for cs.
  * If there is no free id we return zero

-- 
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/20141117/901c56bf/attachment-0001.html>


[Bug 86368] BUILD FAILED: why : forced (dist) upgrade for gcc 3.4.6 over a BIT COUNT, __builtin_ctz

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86368

--- Comment #1 from debguy  ---

(all i meant with comments are: goal is not to continually upgrade gcc, bison,
etc, causing old code to be incompatible and faile: but to compile new
software: which is easily possible with early tools, new ELF or arch aside. 
__builtin could be a macro or check to see if accel was avail, rather than
using a tweak in gcc only new gcc has.  gcc is not the place to add convenience
functions: it's just not where they go.  libc might be.  even then for a bit
count that's the wrong avenue to expect C libs to be a "perl, unix in a big
module" of every new new bithack stacked against every kernel support of.  i
was pretty user processor support hacks are per arch in kernel, and lib c
sparsely supported them and driver coders commonly checked in the driver code
where useful for such, having both choices on hand)

-- 
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/20141117/01d0880a/attachment.html>


[Bug 86368] BUILD FAILED: why : forced (dist) upgrade for gcc 3.4.6 over a BIT COUNT, __builtin_ctz

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86368

--- Comment #2 from Matt Turner  ---
Wow. A couple of rants about software engineering best practices from a guy
using a gcc release that's literally more than 10 years old. 3.4.0 (which
supports the builtin) is actually *older* than what you're using.

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


[Bug 85647] Random radeonsi crashes with mesa 10.3.x

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=85647

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #28 from Michel Dänzer  ---
Module: Mesa
Branch: master
Commit: ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae4536b4f71cbe76230ea7edc7eb4d6041e651b4

Author: Michel Dänzer 
Date:   Tue Nov 11 16:10:20 2014 +0900

radeonsi: Disable asynchronous DMA except for PIPE_BUFFER

-- 
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/20141117/cc4f1a07/attachment.html>


[Bug 83500] si_dma_copy_tile causes GPU hangs

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=83500

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #10 from Michel Dänzer  ---
Module: Mesa
Branch: master
Commit: ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae4536b4f71cbe76230ea7edc7eb4d6041e651b4

Author: Michel Dänzer 
Date:   Tue Nov 11 16:10:20 2014 +0900

radeonsi: Disable asynchronous DMA except for PIPE_BUFFER

-- 
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/20141117/07dda8aa/attachment.html>


[PATCH] drivers: Change calls to mdelay to msleep in order to stop CPU busy looping in mdfld_dsi_pkg_sender.c

2014-11-17 Thread Jani Nikula
On Sat, 15 Nov 2014, Nicholas Krause  wrote:
> Changes the calls of mdelay to msleep in the driver file 
> mdfld_dsi_pkg_sender.c
> in order to prevent CPU busy looping in order to save CPU cycles as this is
> considered bad form over sleeping the CPU for high resolution timer function
> calls as this driver needs in order to function properly.

The code paths are called with sender->lock spinlock held.

BR,
Jani.

>
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 15 +--
>  1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c 
> b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
> index 87885d8..77c656a 100644
> --- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
> @@ -335,13 +335,11 @@ static int send_pkg_prepare(struct mdfld_dsi_pkg_sender 
> *sender, u8 data_type,
>  
>   /*wait for 120 milliseconds in case exit_sleep_mode just be sent*/
>   if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
> - /*TODO: replace it with msleep later*/
> - mdelay(120);
> + msleep(120);
>   }
>  
>   if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
> - /*TODO: replace it with msleep later*/
> - mdelay(120);
> + msleep(120);
>   }
>   return 0;
>  }
> @@ -364,15 +362,12 @@ static int send_pkg_done(struct mdfld_dsi_pkg_sender 
> *sender, u8 data_type,
>   /*update panel status*/
>   if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
>   sender->panel_mode |= MDFLD_DSI_PANEL_MODE_SLEEP;
> - /*TODO: replace it with msleep later*/
> - mdelay(120);
> + msleep(120);
>   } else if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
>   sender->panel_mode &= ~MDFLD_DSI_PANEL_MODE_SLEEP;
> - /*TODO: replace it with msleep later*/
> - mdelay(120);
> + msleep(120);
>   } else if (unlikely(cmd == DCS_SOFT_RESET)) {
> - /*TODO: replace it with msleep later*/
> - mdelay(5);
> + msleep(5);
>   }
>  
>   sender->status = MDFLD_DSI_PKG_SENDER_FREE;
> -- 
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH 00/14] drm/exynos: embed exynos-drm framework objects into driver private context

2014-11-17 Thread Andrzej Hajda
Hi Inki,

This patchset embed all remaining exynos_drm framework objects into driver 
private
context, thanks to this global variables can be removed and the code can be 
simplified.
It continues refactoring started by dsi related patchset [1].

I have tested it on trats and universal boards with following pipelines:
- fimd - dpi,
- fimd - dsi,
- mixer - hdmi.

The patchset is based on exynos-drm-next-todo + hdmi fixes patchset [2].

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/115960
[2]: http://permalink.gmane.org/gmane.comp.video.dri.devel/118257

Regards
Andrzej


Andrzej Hajda (14):
  drm/exynos/mixer: embed manager into private context
  drm/exynos/mixer: stop using manager->ctx pointer
  drm/exynos/vidi: embed manager into private context
  drm/exynos/vidi: stop using manager->ctx pointer
  drm/exynos/fimd: embed manager into private context
  drm/exynos/fimd: stop using manager->ctx pointer
  drm/exynos/hdmi: embed display into private context
  drm/exynos/hdmi: stop using display->ctx pointer
  drm/exynos/vidi: embed display into private context
  drm/exynos/vidi: stop using display->ctx pointer
  drm/exynos/dp: embed display into private context
  drm/exynos/dp: stop using display->ctx pointer
  drm/exynos/dpi: embed display into private context
  drm/exynos/dpi: stop using display->ctx pointer

 drivers/gpu/drm/exynos/exynos_dp_core.c  |  58 
 drivers/gpu/drm/exynos/exynos_dp_core.h  |   3 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  42 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 102 +--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |  89 
 drivers/gpu/drm/exynos/exynos_hdmi.c |  65 --
 drivers/gpu/drm/exynos/exynos_mixer.c| 114 +++
 8 files changed, 236 insertions(+), 241 deletions(-)

-- 
1.9.1



[PATCH 02/14] drm/exynos/mixer: stop using manager->ctx pointer

2014-11-17 Thread Andrzej Hajda
The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2c5d8e7..14a329a 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -106,6 +106,11 @@ struct mixer_context {
atomic_twait_vsync_event;
 };

+static inline struct mixer_context *mgr_to_mixer(struct exynos_drm_manager 
*mgr)
+{
+   return container_of(mgr, struct mixer_context, manager);
+}
+
 struct mixer_drv_data {
enum mixer_version_id   version;
boolis_vp_enabled;
@@ -854,7 +859,7 @@ static int mixer_initialize(struct exynos_drm_manager *mgr,
struct drm_device *drm_dev)
 {
int ret;
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);
struct exynos_drm_private *priv;
priv = drm_dev->dev_private;

@@ -885,7 +890,7 @@ static int mixer_initialize(struct exynos_drm_manager *mgr,

 static void mixer_mgr_remove(struct exynos_drm_manager *mgr)
 {
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);

if (is_drm_iommu_supported(mixer_ctx->drm_dev))
drm_iommu_detach_device(mixer_ctx->drm_dev, mixer_ctx->dev);
@@ -893,7 +898,7 @@ static void mixer_mgr_remove(struct exynos_drm_manager *mgr)

 static int mixer_enable_vblank(struct exynos_drm_manager *mgr)
 {
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);
struct mixer_resources *res = &mixer_ctx->mixer_res;

__set_bit(MXR_BIT_VSYNC, &mixer_ctx->flags);
@@ -909,7 +914,7 @@ static int mixer_enable_vblank(struct exynos_drm_manager 
*mgr)

 static void mixer_disable_vblank(struct exynos_drm_manager *mgr)
 {
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);
struct mixer_resources *res = &mixer_ctx->mixer_res;

__clear_bit(MXR_BIT_VSYNC, &mixer_ctx->flags);
@@ -925,7 +930,7 @@ static void mixer_disable_vblank(struct exynos_drm_manager 
*mgr)
 static void mixer_win_mode_set(struct exynos_drm_manager *mgr,
struct exynos_drm_overlay *overlay)
 {
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);
struct hdmi_win_data *win_data;
int win;

@@ -976,7 +981,7 @@ static void mixer_win_mode_set(struct exynos_drm_manager 
*mgr,

 static void mixer_win_commit(struct exynos_drm_manager *mgr, int zpos)
 {
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);
int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;

DRM_DEBUG_KMS("win: %d\n", win);
@@ -994,7 +999,7 @@ static void mixer_win_commit(struct exynos_drm_manager 
*mgr, int zpos)

 static void mixer_win_disable(struct exynos_drm_manager *mgr, int zpos)
 {
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);
struct mixer_resources *res = &mixer_ctx->mixer_res;
int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;
unsigned long flags;
@@ -1019,7 +1024,7 @@ static void mixer_win_disable(struct exynos_drm_manager 
*mgr, int zpos)

 static void mixer_wait_for_vblank(struct exynos_drm_manager *mgr)
 {
-   struct mixer_context *mixer_ctx = mgr->ctx;
+   struct mixer_context *mixer_ctx = mgr_to_mixer(mgr);

if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;
@@ -1042,7 +1047,7 @@ static void mixer_wait_for_vblank(struct 
exynos_drm_manager *mgr)

 static void mixer_window_suspend(struct exynos_drm_manager *mgr)
 {
-   struct mixer_context *ctx = mgr->ctx;
+   struct mixer_context *ctx = mgr_to_mixer(mgr);
struct hdmi_win_data *win_data;
int i;

@@ -1056,7 +1061,7 @@ static void mixer_window_suspend(struct 
exynos_drm_manager *mgr)

 static void mixer_window_resume(struct exynos_drm_manager *mgr)
 {
-   struct mixer_context *ctx = mgr->ctx;
+   struct mixer_context *ctx = mgr_to_mixer(mgr);
struct hdmi_win_data *win_data;
int i;

@@ -1071,7 +1076,7 @@ static void mixer_window_resume(struct exynos_drm_manager 
*mgr)

 static void mixer_poweron(struct exynos_drm_manager *mgr)
 {
-   struct mixer_context *ctx = mgr->ctx;
+   struct mixer_context *ctx = mgr_to_mixer(mgr);
struct mixer_resources *res = &ctx->mixer_res;

if (test_bit(MXR_BIT_POWERED, &ctx->flags))
@@ -1101,7 +1106,7 @@ static void mixer_poweron(struct exyno

[PATCH 03/14] drm/exynos/vidi: embed manager into private context

2014-11-17 Thread Andrzej Hajda
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to vidi private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 44 
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 50faf91..f47939c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -28,7 +28,6 @@
 /* vidi has totally three virtual windows. */
 #define WINDOWS_NR 3

-#define get_vidi_mgr(dev)  platform_get_drvdata(to_platform_device(dev))
 #define ctx_from_connector(c)  container_of(c, struct vidi_context, \
connector)

@@ -47,6 +46,7 @@ struct vidi_win_data {
 };

 struct vidi_context {
+   struct exynos_drm_manager   manager;
struct drm_device   *drm_dev;
struct drm_crtc *crtc;
struct drm_encoder  *encoder;
@@ -316,11 +316,6 @@ static struct exynos_drm_manager_ops vidi_manager_ops = {
.win_disable = vidi_win_disable,
 };

-static struct exynos_drm_manager vidi_manager = {
-   .type = EXYNOS_DISPLAY_TYPE_VIDI,
-   .ops = &vidi_manager_ops,
-};
-
 static void vidi_fake_vblank_handler(struct work_struct *work)
 {
struct vidi_context *ctx = container_of(work, struct vidi_context,
@@ -349,9 +344,8 @@ static void vidi_fake_vblank_handler(struct work_struct 
*work)
 static int vidi_show_connection(struct device *dev,
struct device_attribute *attr, char *buf)
 {
+   struct vidi_context *ctx = dev_get_drvdata(dev);
int rc;
-   struct exynos_drm_manager *mgr = get_vidi_mgr(dev);
-   struct vidi_context *ctx = mgr->ctx;

mutex_lock(&ctx->lock);

@@ -366,8 +360,7 @@ static int vidi_store_connection(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
 {
-   struct exynos_drm_manager *mgr = get_vidi_mgr(dev);
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = dev_get_drvdata(dev);
int ret;

ret = kstrtoint(buf, 0, &ctx->connected);
@@ -563,14 +556,13 @@ static struct exynos_drm_display vidi_display = {

 static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
 {
-   struct exynos_drm_manager *mgr = get_vidi_mgr(dev);
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = dev_get_drvdata(dev);
struct drm_crtc *crtc = ctx->crtc;
int ret;

-   vidi_mgr_initialize(mgr, drm_dev);
+   vidi_mgr_initialize(&ctx->manager, drm_dev);

-   ret = exynos_drm_crtc_create(&vidi_manager);
+   ret = exynos_drm_crtc_create(&ctx->manager);
if (ret) {
DRM_ERROR("failed to create crtc.\n");
return ret;
@@ -596,16 +588,18 @@ static int vidi_probe(struct platform_device *pdev)
if (!ctx)
return -ENOMEM;

+   ctx->manager.type = EXYNOS_DISPLAY_TYPE_VIDI;
+   ctx->manager.ops = &vidi_manager_ops;
ctx->default_win = 0;

INIT_WORK(&ctx->work, vidi_fake_vblank_handler);

-   vidi_manager.ctx = ctx;
+   ctx->manager.ctx = ctx;
vidi_display.ctx = ctx;

mutex_init(&ctx->lock);

-   platform_set_drvdata(pdev, &vidi_manager);
+   platform_set_drvdata(pdev, ctx);

subdrv = &ctx->subdrv;
subdrv->dev = &pdev->dev;
@@ -628,8 +622,7 @@ static int vidi_probe(struct platform_device *pdev)

 static int vidi_remove(struct platform_device *pdev)
 {
-   struct exynos_drm_manager *mgr = platform_get_drvdata(pdev);
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = platform_get_drvdata(pdev);

if (ctx->raw_edid != (struct edid *)fake_edid_info) {
kfree(ctx->raw_edid);
@@ -668,12 +661,19 @@ int exynos_drm_probe_vidi(void)
return ret;
 }

+static int exynos_drm_remove_vidi_device(struct device *dev, void *data)
+{
+   platform_device_unregister(to_platform_device(dev));
+
+   return 0;
+}
+
 void exynos_drm_remove_vidi(void)
 {
-   struct vidi_context *ctx = vidi_manager.ctx;
-   struct exynos_drm_subdrv *subdrv = &ctx->subdrv;
-   struct platform_device *pdev = to_platform_device(subdrv->dev);
+   int ret = driver_for_each_device(&vidi_driver.driver, NULL, NULL,
+exynos_drm_remove_vidi_device);
+   /* silence compiler warning */
+   (void)ret;

platform_driver_unregister(&vidi_driver);
-   platform_device_unregister(pdev);
 }
--

[PATCH 04/14] drm/exynos/vidi: stop using manager->ctx pointer

2014-11-17 Thread Andrzej Hajda
The patch replaces accesses to manager->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index f47939c..f048a90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -66,6 +66,11 @@ struct vidi_context {
int pipe;
 };

+static inline struct vidi_context *manager_to_vidi(struct exynos_drm_manager 
*m)
+{
+   return container_of(m, struct vidi_context, manager);
+}
+
 static const char fake_edid_info[] = {
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x4c, 0x2d, 0x05, 0x05,
0x00, 0x00, 0x00, 0x00, 0x30, 0x12, 0x01, 0x03, 0x80, 0x10, 0x09, 0x78,
@@ -93,7 +98,7 @@ static const char fake_edid_info[] = {

 static void vidi_apply(struct exynos_drm_manager *mgr)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);
struct exynos_drm_manager_ops *mgr_ops = mgr->ops;
struct vidi_win_data *win_data;
int i;
@@ -110,7 +115,7 @@ static void vidi_apply(struct exynos_drm_manager *mgr)

 static void vidi_commit(struct exynos_drm_manager *mgr)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);

if (ctx->suspended)
return;
@@ -118,7 +123,7 @@ static void vidi_commit(struct exynos_drm_manager *mgr)

 static int vidi_enable_vblank(struct exynos_drm_manager *mgr)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);

if (ctx->suspended)
return -EPERM;
@@ -140,7 +145,7 @@ static int vidi_enable_vblank(struct exynos_drm_manager 
*mgr)

 static void vidi_disable_vblank(struct exynos_drm_manager *mgr)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);

if (ctx->suspended)
return;
@@ -152,7 +157,7 @@ static void vidi_disable_vblank(struct exynos_drm_manager 
*mgr)
 static void vidi_win_mode_set(struct exynos_drm_manager *mgr,
struct exynos_drm_overlay *overlay)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);
struct vidi_win_data *win_data;
int win;
unsigned long offset;
@@ -204,7 +209,7 @@ static void vidi_win_mode_set(struct exynos_drm_manager 
*mgr,

 static void vidi_win_commit(struct exynos_drm_manager *mgr, int zpos)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);
struct vidi_win_data *win_data;
int win = zpos;

@@ -229,7 +234,7 @@ static void vidi_win_commit(struct exynos_drm_manager *mgr, 
int zpos)

 static void vidi_win_disable(struct exynos_drm_manager *mgr, int zpos)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);
struct vidi_win_data *win_data;
int win = zpos;

@@ -247,7 +252,7 @@ static void vidi_win_disable(struct exynos_drm_manager 
*mgr, int zpos)

 static int vidi_power_on(struct exynos_drm_manager *mgr, bool enable)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);

DRM_DEBUG_KMS("%s\n", __FILE__);

@@ -271,7 +276,7 @@ static int vidi_power_on(struct exynos_drm_manager *mgr, 
bool enable)

 static void vidi_dpms(struct exynos_drm_manager *mgr, int mode)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);

DRM_DEBUG_KMS("%d\n", mode);

@@ -297,7 +302,7 @@ static void vidi_dpms(struct exynos_drm_manager *mgr, int 
mode)
 static int vidi_mgr_initialize(struct exynos_drm_manager *mgr,
struct drm_device *drm_dev)
 {
-   struct vidi_context *ctx = mgr->ctx;
+   struct vidi_context *ctx = manager_to_vidi(mgr);
struct exynos_drm_private *priv = drm_dev->dev_private;

mgr->drm_dev = ctx->drm_dev = drm_dev;
@@ -594,7 +599,6 @@ static int vidi_probe(struct platform_device *pdev)

INIT_WORK(&ctx->work, vidi_fake_vblank_handler);

-   ctx->manager.ctx = ctx;
vidi_display.ctx = ctx;

mutex_init(&ctx->lock);
-- 
1.9.1



[PATCH 01/14] drm/exynos/mixer: embed manager into private context

2014-11-17 Thread Andrzej Hajda
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple mixer devices in the system.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 86 +--
 1 file changed, 41 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4858170e..2c5d8e7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -40,8 +40,6 @@
 #include "exynos_drm_iommu.h"
 #include "exynos_mixer.h"

-#define get_mixer_manager(dev) platform_get_drvdata(to_platform_device(dev))
-
 #define MIXER_WIN_NR   3
 #define MIXER_DEFAULT_WIN  0

@@ -91,6 +89,7 @@ enum mixer_flag_bits {
 };

 struct mixer_context {
+   struct exynos_drm_manager manager;
struct platform_device *pdev;
struct device   *dev;
struct drm_device   *drm_dev;
@@ -1170,11 +1169,6 @@ static struct exynos_drm_manager_ops mixer_manager_ops = 
{
.win_disable= mixer_win_disable,
 };

-static struct exynos_drm_manager mixer_manager = {
-   .type   = EXYNOS_DISPLAY_TYPE_HDMI,
-   .ops= &mixer_manager_ops,
-};
-
 static struct mixer_drv_data exynos5420_mxr_drv_data = {
.version = MXR_VER_128_0_0_184,
.is_vp_enabled = 0,
@@ -1232,46 +1226,17 @@ MODULE_DEVICE_TABLE(of, mixer_match_types);

 static int mixer_bind(struct device *dev, struct device *manager, void *data)
 {
-   struct platform_device *pdev = to_platform_device(dev);
+   struct mixer_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
-   struct mixer_context *ctx;
-   struct mixer_drv_data *drv;
int ret;

-   dev_info(dev, "probe start\n");
-
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
-   if (!ctx) {
-   DRM_ERROR("failed to alloc mixer context.\n");
-   return -ENOMEM;
-   }
-
-   if (dev->of_node) {
-   const struct of_device_id *match;
-   match = of_match_node(mixer_match_types, dev->of_node);
-   drv = (struct mixer_drv_data *)match->data;
-   } else {
-   drv = (struct mixer_drv_data *)
-   platform_get_device_id(pdev)->driver_data;
-   }
-
-   ctx->pdev = pdev;
-   ctx->dev = dev;
-   ctx->vp_enabled = drv->is_vp_enabled;
-   ctx->has_sclk = drv->has_sclk;
-   ctx->mxr_ver = drv->version;
-   init_waitqueue_head(&ctx->wait_vsync_queue);
-   atomic_set(&ctx->wait_vsync_event, 0);
-
-   mixer_manager.ctx = ctx;
-   ret = mixer_initialize(&mixer_manager, drm_dev);
+   ret = mixer_initialize(&ctx->manager, drm_dev);
if (ret)
return ret;

-   platform_set_drvdata(pdev, &mixer_manager);
-   ret = exynos_drm_crtc_create(&mixer_manager);
+   ret = exynos_drm_crtc_create(&ctx->manager);
if (ret) {
-   mixer_mgr_remove(&mixer_manager);
+   mixer_mgr_remove(&ctx->manager);
return ret;
}

@@ -1282,11 +1247,9 @@ static int mixer_bind(struct device *dev, struct device 
*manager, void *data)

 static void mixer_unbind(struct device *dev, struct device *master, void *data)
 {
-   struct exynos_drm_manager *mgr = dev_get_drvdata(dev);
+   struct mixer_context *ctx = dev_get_drvdata(dev);

-   dev_info(dev, "remove successful\n");
-
-   mixer_mgr_remove(mgr);
+   mixer_mgr_remove(&ctx->manager);

pm_runtime_disable(dev);
 }
@@ -1298,10 +1261,43 @@ static const struct component_ops mixer_component_ops = 
{

 static int mixer_probe(struct platform_device *pdev)
 {
+   struct device *dev = &pdev->dev;
+   struct mixer_drv_data *drv;
+   struct mixer_context *ctx;
int ret;

+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+   if (!ctx) {
+   DRM_ERROR("failed to alloc mixer context.\n");
+   return -ENOMEM;
+   }
+
+   ctx->manager.type = EXYNOS_DISPLAY_TYPE_HDMI;
+   ctx->manager.ops = &mixer_manager_ops;
+
+   if (dev->of_node) {
+   const struct of_device_id *match;
+
+   match = of_match_node(mixer_match_types, dev->of_node);
+   drv = (struct mixer_drv_data *)match->data;
+   } else {
+   drv = (struct mixer_drv_data *)
+   platform_get_device_id(pdev)->driver_data;
+   }
+
+   ctx->pdev = pdev;
+   ctx->dev = dev;
+   ctx->vp_enabled = drv->is_vp_enabled;
+   ctx->has_sclk = drv->has_sclk;
+   ctx->mxr_ver = drv->version;
+   init_waitqueue_head(&ctx->wait_vsync_queue);
+  

[PATCH 05/14] drm/exynos/fimd: embed manager into private context

2014-11-17 Thread Andrzej Hajda
exynos_drm_manager is used by internal Exynos DRM framework for
representing crtc. As it should be mapped 1:1 to fimd private context
it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple FIMD devices in the system.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 62 ++--
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index c949099..6cda128 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -89,8 +89,6 @@
 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5

-#define get_fimd_manager(mgr)  platform_get_drvdata(to_platform_device(dev))
-
 struct fimd_driver_data {
unsigned int timing_base;
unsigned int lcdblk_offset;
@@ -151,6 +149,7 @@ struct fimd_win_data {
 };

 struct fimd_context {
+   struct exynos_drm_manager   manager;
struct device   *dev;
struct drm_device   *drm_dev;
struct clk  *bus_clk;
@@ -952,8 +951,7 @@ static void fimd_dpms(struct exynos_drm_manager *mgr, int 
mode)

 static void fimd_trigger(struct device *dev)
 {
-   struct exynos_drm_manager *mgr = get_fimd_manager(dev);
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = dev_get_drvdata(dev);
struct fimd_driver_data *driver_data = ctx->driver_data;
void *timing_base = ctx->regs + driver_data->timing_base;
u32 reg;
@@ -1019,11 +1017,6 @@ static struct exynos_drm_manager_ops fimd_manager_ops = {
.te_handler = fimd_te_handler,
 };

-static struct exynos_drm_manager fimd_manager = {
-   .type = EXYNOS_DISPLAY_TYPE_LCD,
-   .ops = &fimd_manager_ops,
-};
-
 static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
 {
struct fimd_context *ctx = (struct fimd_context *)dev_id;
@@ -1059,11 +1052,11 @@ out:

 static int fimd_bind(struct device *dev, struct device *master, void *data)
 {
-   struct fimd_context *ctx = fimd_manager.ctx;
+   struct fimd_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;

-   fimd_mgr_initialize(&fimd_manager, drm_dev);
-   exynos_drm_crtc_create(&fimd_manager);
+   fimd_mgr_initialize(&ctx->manager, drm_dev);
+   exynos_drm_crtc_create(&ctx->manager);
if (ctx->display)
exynos_drm_create_enc_conn(drm_dev, ctx->display);

@@ -1074,15 +1067,14 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
 static void fimd_unbind(struct device *dev, struct device *master,
void *data)
 {
-   struct exynos_drm_manager *mgr = dev_get_drvdata(dev);
-   struct fimd_context *ctx = fimd_manager.ctx;
+   struct fimd_context *ctx = dev_get_drvdata(dev);

-   fimd_dpms(mgr, DRM_MODE_DPMS_OFF);
+   fimd_dpms(&ctx->manager, DRM_MODE_DPMS_OFF);

if (ctx->display)
exynos_dpi_remove(dev);

-   fimd_mgr_remove(mgr);
+   fimd_mgr_remove(&ctx->manager);
 }

 static const struct component_ops fimd_component_ops = {
@@ -1098,21 +1090,20 @@ static int fimd_probe(struct platform_device *pdev)
struct resource *res;
int ret = -EINVAL;

-   ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CRTC,
-   fimd_manager.type);
-   if (ret)
-   return ret;
-
-   if (!dev->of_node) {
-   ret = -ENODEV;
-   goto err_del_component;
-   }
+   if (!dev->of_node)
+   return -ENODEV;

ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
-   if (!ctx) {
-   ret = -ENOMEM;
-   goto err_del_component;
-   }
+   if (!ctx)
+   return -ENOMEM;
+
+   ctx->manager.type = EXYNOS_DISPLAY_TYPE_LCD;
+   ctx->manager.ops = &fimd_manager_ops;
+
+   ret = exynos_drm_component_add(dev, EXYNOS_DEVICE_TYPE_CRTC,
+  ctx->manager.type);
+   if (ret)
+   return ret;

ctx->dev = dev;
ctx->suspended = true;
@@ -1200,28 +1191,27 @@ static int fimd_probe(struct platform_device *pdev)

init_waitqueue_head(&ctx->wait_vsync_queue);
atomic_set(&ctx->wait_vsync_event, 0);
+   ctx->manager.ctx = ctx;

-   platform_set_drvdata(pdev, &fimd_manager);
-
-   fimd_manager.ctx = ctx;
+   platform_set_drvdata(pdev, ctx);

ctx->display = exynos_dpi_probe(dev);
if (IS_ERR(ctx->display))
return PTR_ERR(ctx->display);

-   pm_runtime_enable(&pdev->dev);
+   pm_runtime_enable(dev);

-   ret = component_add(&pdev->dev, &fimd_component_ops);
+   ret = component_add(dev, &fimd_compone

[PATCH 06/14] drm/exynos/fimd: stop using manager->ctx pointer

2014-11-17 Thread Andrzej Hajda
The patch replaces accesses to manager->ctx pointer by container_of
construct. As fimd was the last user of ctx the patch removes
this field as well.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 40 ++--
 2 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index d22e640..d8240fd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -227,7 +227,6 @@ struct exynos_drm_manager {
struct drm_crtc *crtc;
int pipe;
struct exynos_drm_manager_ops *ops;
-   void *ctx;
 };

 struct exynos_drm_g2d_private {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 6cda128..2a652ab 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -177,6 +177,11 @@ struct fimd_context {
struct exynos_drm_display *display;
 };

+static inline struct fimd_context *mgr_to_fimd(struct exynos_drm_manager *mgr)
+{
+   return container_of(mgr, struct fimd_context, manager);
+}
+
 static const struct of_device_id fimd_driver_dt_match[] = {
{ .compatible = "samsung,s3c6400-fimd",
  .data = &s3c64xx_fimd_driver_data },
@@ -201,7 +206,7 @@ static inline struct fimd_driver_data 
*drm_fimd_get_driver_data(

 static void fimd_wait_for_vblank(struct exynos_drm_manager *mgr)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);

if (ctx->suspended)
return;
@@ -247,7 +252,7 @@ static void fimd_channel_win(struct fimd_context *ctx, int 
win, bool enable)

 static void fimd_clear_channel(struct exynos_drm_manager *mgr)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);
int win, ch_enabled = 0;

DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -275,7 +280,7 @@ static void fimd_clear_channel(struct exynos_drm_manager 
*mgr)
 static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
struct drm_device *drm_dev)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);
struct exynos_drm_private *priv;
priv = drm_dev->dev_private;

@@ -297,7 +302,7 @@ static int fimd_mgr_initialize(struct exynos_drm_manager 
*mgr,

 static void fimd_mgr_remove(struct exynos_drm_manager *mgr)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);

/* detach this sub driver from iommu mapping if supported. */
if (is_drm_iommu_supported(ctx->drm_dev))
@@ -346,14 +351,14 @@ static bool fimd_mode_fixup(struct exynos_drm_manager 
*mgr,
 static void fimd_mode_set(struct exynos_drm_manager *mgr,
const struct drm_display_mode *in_mode)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);

drm_mode_copy(&ctx->mode, in_mode);
 }

 static void fimd_commit(struct exynos_drm_manager *mgr)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);
struct drm_display_mode *mode = &ctx->mode;
struct fimd_driver_data *driver_data = ctx->driver_data;
void *timing_base = ctx->regs + driver_data->timing_base;
@@ -452,7 +457,7 @@ static void fimd_commit(struct exynos_drm_manager *mgr)

 static int fimd_enable_vblank(struct exynos_drm_manager *mgr)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);
u32 val;

if (ctx->suspended)
@@ -484,7 +489,7 @@ static int fimd_enable_vblank(struct exynos_drm_manager 
*mgr)

 static void fimd_disable_vblank(struct exynos_drm_manager *mgr)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);
u32 val;

if (ctx->suspended)
@@ -509,7 +514,7 @@ static void fimd_disable_vblank(struct exynos_drm_manager 
*mgr)
 static void fimd_win_mode_set(struct exynos_drm_manager *mgr,
struct exynos_drm_overlay *overlay)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);
struct fimd_win_data *win_data;
int win;
unsigned long offset;
@@ -667,7 +672,7 @@ static void fimd_shadow_protect_win(struct fimd_context 
*ctx,

 static void fimd_win_commit(struct exynos_drm_manager *mgr, int zpos)
 {
-   struct fimd_context *ctx = mgr->ctx;
+   struct fimd_context *ctx = mgr_to_fimd(mgr);
struct fimd_win_data *win_data;
int win = zpos;
unsigned long val, alpha, size;
@@ -787,7 +792,7 @@ static void fimd_win_commit(struct exynos_drm_manager *mgr, 
int zpos)

 static void fimd_win_disable(struct exynos_drm_manager *mgr, int zpos)
 {
-

[PATCH 08/14] drm/exynos/hdmi: stop using display->ctx pointer

2014-11-17 Thread Andrzej Hajda
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f8ed123..37bb423 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -213,6 +213,11 @@ struct hdmi_context {
enum hdmi_type  type;
 };

+static inline struct hdmi_context *display_to_hdmi(struct exynos_drm_display 
*d)
+{
+   return container_of(d, struct hdmi_context, display);
+}
+
 struct hdmiphy_config {
int pixel_clock;
u8 conf[32];
@@ -1128,7 +1133,7 @@ static struct drm_connector_helper_funcs 
hdmi_connector_helper_funcs = {
 static int hdmi_create_connector(struct exynos_drm_display *display,
struct drm_encoder *encoder)
 {
-   struct hdmi_context *hdata = display->ctx;
+   struct hdmi_context *hdata = display_to_hdmi(display);
struct drm_connector *connector = &hdata->connector;
int ret;

@@ -2005,7 +2010,7 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
 static void hdmi_mode_set(struct exynos_drm_display *display,
struct drm_display_mode *mode)
 {
-   struct hdmi_context *hdata = display->ctx;
+   struct hdmi_context *hdata = display_to_hdmi(display);
struct drm_display_mode *m = mode;

DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%s\n",
@@ -2024,7 +2029,7 @@ static void hdmi_mode_set(struct exynos_drm_display 
*display,

 static void hdmi_commit(struct exynos_drm_display *display)
 {
-   struct hdmi_context *hdata = display->ctx;
+   struct hdmi_context *hdata = display_to_hdmi(display);

mutex_lock(&hdata->hdmi_mutex);
if (!hdata->powered) {
@@ -2038,7 +2043,7 @@ static void hdmi_commit(struct exynos_drm_display 
*display)

 static void hdmi_poweron(struct exynos_drm_display *display)
 {
-   struct hdmi_context *hdata = display->ctx;
+   struct hdmi_context *hdata = display_to_hdmi(display);
struct hdmi_resources *res = &hdata->res;

mutex_lock(&hdata->hdmi_mutex);
@@ -2069,7 +2074,7 @@ static void hdmi_poweron(struct exynos_drm_display 
*display)

 static void hdmi_poweroff(struct exynos_drm_display *display)
 {
-   struct hdmi_context *hdata = display->ctx;
+   struct hdmi_context *hdata = display_to_hdmi(display);
struct hdmi_resources *res = &hdata->res;

mutex_lock(&hdata->hdmi_mutex);
@@ -2104,7 +2109,7 @@ out:

 static void hdmi_dpms(struct exynos_drm_display *display, int mode)
 {
-   struct hdmi_context *hdata = display->ctx;
+   struct hdmi_context *hdata = display_to_hdmi(display);
struct drm_encoder *encoder = hdata->encoder;
struct drm_crtc *crtc = encoder->crtc;
struct drm_crtc_helper_funcs *funcs = NULL;
@@ -2481,7 +2486,6 @@ out_get_phy_port:
}

pm_runtime_enable(dev);
-   hdata->display.ctx = hdata;

ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
-- 
1.9.1



[PATCH 07/14] drm/exynos/hdmi: embed display into private context

2014-11-17 Thread Andrzej Hajda
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to hdmi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple hdmi devices in the system.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 49 +++-
 1 file changed, 20 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 65a2285..f8ed123 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -49,7 +49,6 @@
 #include 
 #include 

-#define get_hdmi_display(dev)  platform_get_drvdata(to_platform_device(dev))
 #define ctx_from_connector(c)  container_of(c, struct hdmi_context, connector)

 #define HOTPLUG_DEBOUNCE_MS1100
@@ -182,6 +181,7 @@ struct hdmi_conf_regs {
 };

 struct hdmi_context {
+   struct exynos_drm_display   display;
struct device   *dev;
struct drm_device   *drm_dev;
struct drm_connectorconnector;
@@ -2148,11 +2148,6 @@ static struct exynos_drm_display_ops hdmi_display_ops = {
.commit = hdmi_commit,
 };

-static struct exynos_drm_display hdmi_display = {
-   .type = EXYNOS_DISPLAY_TYPE_HDMI,
-   .ops = &hdmi_display_ops,
-};
-
 static void hdmi_hotplug_work_func(struct work_struct *work)
 {
struct hdmi_context *hdata;
@@ -2307,12 +2302,11 @@ MODULE_DEVICE_TABLE (of, hdmi_match_types);
 static int hdmi_bind(struct device *dev, struct device *master, void *data)
 {
struct drm_device *drm_dev = data;
-   struct hdmi_context *hdata;
+   struct hdmi_context *hdata = dev_get_drvdata(dev);

-   hdata = hdmi_display.ctx;
hdata->drm_dev = drm_dev;

-   return exynos_drm_create_enc_conn(drm_dev, &hdmi_display);
+   return exynos_drm_create_enc_conn(drm_dev, &hdata->display);
 }

 static void hdmi_unbind(struct device *dev, struct device *master, void *data)
@@ -2354,31 +2348,28 @@ static int hdmi_probe(struct platform_device *pdev)
struct resource *res;
int ret;

-   ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
-   hdmi_display.type);
-   if (ret)
-   return ret;
-
-   if (!dev->of_node) {
-   ret = -ENODEV;
-   goto err_del_component;
-   }
+   if (!dev->of_node)
+   return -ENODEV;

pdata = drm_hdmi_dt_parse_pdata(dev);
-   if (!pdata) {
-   ret = -EINVAL;
-   goto err_del_component;
-   }
+   if (!pdata)
+   return -EINVAL;

hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
-   if (!hdata) {
-   ret = -ENOMEM;
-   goto err_del_component;
-   }
+   if (!hdata)
+   return -ENOMEM;
+
+   hdata->display.type = EXYNOS_DISPLAY_TYPE_HDMI;
+   hdata->display.ops = &hdmi_display_ops;
+
+   ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
+   hdata->display.type);
+   if (ret)
+   return ret;

mutex_init(&hdata->hdmi_mutex);

-   platform_set_drvdata(pdev, &hdmi_display);
+   platform_set_drvdata(pdev, hdata);

match = of_match_node(hdmi_match_types, dev->of_node);
if (!match) {
@@ -2490,7 +2481,7 @@ out_get_phy_port:
}

pm_runtime_enable(dev);
-   hdmi_display.ctx = hdata;
+   hdata->display.ctx = hdata;

ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
@@ -2515,7 +2506,7 @@ err_del_component:

 static int hdmi_remove(struct platform_device *pdev)
 {
-   struct hdmi_context *hdata = hdmi_display.ctx;
+   struct hdmi_context *hdata = platform_get_drvdata(pdev);

cancel_delayed_work_sync(&hdata->hotplug_work);

-- 
1.9.1



[PATCH 09/14] drm/exynos/vidi: embed display into private context

2014-11-17 Thread Andrzej Hajda
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to vidi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple vidi devices in the system.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index f048a90..f58dd52 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -47,6 +47,7 @@ struct vidi_win_data {

 struct vidi_context {
struct exynos_drm_manager   manager;
+   struct exynos_drm_display   display;
struct drm_device   *drm_dev;
struct drm_crtc *crtc;
struct drm_encoder  *encoder;
@@ -554,11 +555,6 @@ static struct exynos_drm_display_ops vidi_display_ops = {
.create_connector = vidi_create_connector,
 };

-static struct exynos_drm_display vidi_display = {
-   .type = EXYNOS_DISPLAY_TYPE_VIDI,
-   .ops = &vidi_display_ops,
-};
-
 static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
 {
struct vidi_context *ctx = dev_get_drvdata(dev);
@@ -573,7 +569,7 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return ret;
}

-   ret = exynos_drm_create_enc_conn(drm_dev, &vidi_display);
+   ret = exynos_drm_create_enc_conn(drm_dev, &ctx->display);
if (ret) {
crtc->funcs->destroy(crtc);
DRM_ERROR("failed to create encoder and connector.\n");
@@ -595,11 +591,13 @@ static int vidi_probe(struct platform_device *pdev)

ctx->manager.type = EXYNOS_DISPLAY_TYPE_VIDI;
ctx->manager.ops = &vidi_manager_ops;
+   ctx->display.type = EXYNOS_DISPLAY_TYPE_VIDI;
+   ctx->display.ops = &vidi_display_ops;
ctx->default_win = 0;

INIT_WORK(&ctx->work, vidi_fake_vblank_handler);

-   vidi_display.ctx = ctx;
+   ctx->display.ctx = ctx;

mutex_init(&ctx->lock);

-- 
1.9.1



[PATCH 10/14] drm/exynos/vidi: stop using display->ctx pointer

2014-11-17 Thread Andrzej Hajda
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index f58dd52..3b6fdd6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -72,6 +72,11 @@ static inline struct vidi_context *manager_to_vidi(struct 
exynos_drm_manager *m)
return container_of(m, struct vidi_context, manager);
 }

+static inline struct vidi_context *display_to_vidi(struct exynos_drm_display 
*d)
+{
+   return container_of(d, struct vidi_context, display);
+}
+
 static const char fake_edid_info[] = {
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x4c, 0x2d, 0x05, 0x05,
0x00, 0x00, 0x00, 0x00, 0x30, 0x12, 0x01, 0x03, 0x80, 0x10, 0x09, 0x78,
@@ -419,7 +424,7 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void 
*data,
display = exynos_drm_get_display(encoder);

if (display->type == EXYNOS_DISPLAY_TYPE_VIDI) {
-   ctx = display->ctx;
+   ctx = display_to_vidi(display);
break;
}
}
@@ -529,7 +534,7 @@ static struct drm_connector_helper_funcs 
vidi_connector_helper_funcs = {
 static int vidi_create_connector(struct exynos_drm_display *display,
struct drm_encoder *encoder)
 {
-   struct vidi_context *ctx = display->ctx;
+   struct vidi_context *ctx = display_to_vidi(display);
struct drm_connector *connector = &ctx->connector;
int ret;

@@ -597,8 +602,6 @@ static int vidi_probe(struct platform_device *pdev)

INIT_WORK(&ctx->work, vidi_fake_vblank_handler);

-   ctx->display.ctx = ctx;
-
mutex_init(&ctx->lock);

platform_set_drvdata(pdev, ctx);
-- 
1.9.1



[PATCH 11/14] drm/exynos/dp: embed display into private context

2014-11-17 Thread Andrzej Hajda
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dp
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dp devices in the system.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 42 ++---
 drivers/gpu/drm/exynos/exynos_dp_core.h |  3 +++
 2 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 6adb1e5..a7f5feb 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -30,7 +30,6 @@
 #include 
 #include 

-#include "exynos_drm_drv.h"
 #include "exynos_dp_core.h"

 #define ctx_from_connector(c)  container_of(c, struct exynos_dp_device, \
@@ -1147,11 +1146,6 @@ static struct exynos_drm_display_ops 
exynos_dp_display_ops = {
.commit = exynos_dp_commit,
 };

-static struct exynos_drm_display exynos_dp_display = {
-   .type = EXYNOS_DISPLAY_TYPE_LCD,
-   .ops = &exynos_dp_display_ops,
-};
-
 static struct video_info *exynos_dp_dt_parse_pdata(struct device *dev)
 {
struct device_node *dp_node = dev->of_node;
@@ -1263,10 +1257,10 @@ static int exynos_dp_dt_parse_panel(struct 
exynos_dp_device *dp)

 static int exynos_dp_bind(struct device *dev, struct device *master, void 
*data)
 {
+   struct exynos_dp_device *dp = dev_get_drvdata(dev);
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm_dev = data;
struct resource *res;
-   struct exynos_dp_device *dp = exynos_dp_display.ctx;
unsigned int irq_flags;
int ret = 0;

@@ -1346,17 +1340,15 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)

dp->drm_dev = drm_dev;

-   platform_set_drvdata(pdev, &exynos_dp_display);
-
-   return exynos_drm_create_enc_conn(drm_dev, &exynos_dp_display);
+   return exynos_drm_create_enc_conn(drm_dev, &dp->display);
 }

 static void exynos_dp_unbind(struct device *dev, struct device *master,
void *data)
 {
-   struct exynos_drm_display *display = dev_get_drvdata(dev);
+   struct exynos_dp_device *dp = dev_get_drvdata(dev);

-   exynos_dp_dpms(display, DRM_MODE_DPMS_OFF);
+   exynos_dp_dpms(&dp->display, DRM_MODE_DPMS_OFF);
 }

 static const struct component_ops exynos_dp_ops = {
@@ -1371,16 +1363,20 @@ static int exynos_dp_probe(struct platform_device *pdev)
struct exynos_dp_device *dp;
int ret;

-   ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
-   exynos_dp_display.type);
-   if (ret)
-   return ret;
-
dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
if (!dp)
return -ENOMEM;

+   dp->display.type = EXYNOS_DISPLAY_TYPE_LCD;
+   dp->display.ops = &exynos_dp_display_ops;
+   platform_set_drvdata(pdev, dp);
+
+   ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
+   dp->display.type);
+   if (ret)
+   return ret;
+
panel_node = of_parse_phandle(dev->of_node, "panel", 0);
if (panel_node) {
dp->panel = of_drm_find_panel(panel_node);
@@ -1389,7 +1385,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}

-   exynos_dp_display.ctx = dp;
+   dp->display.ctx = dp;

ret = component_add(&pdev->dev, &exynos_dp_ops);
if (ret)
@@ -1410,19 +1406,17 @@ static int exynos_dp_remove(struct platform_device 
*pdev)
 #ifdef CONFIG_PM_SLEEP
 static int exynos_dp_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct exynos_drm_display *display = platform_get_drvdata(pdev);
+   struct exynos_dp_device *dp = dev_get_drvdata(dev);

-   exynos_dp_dpms(display, DRM_MODE_DPMS_OFF);
+   exynos_dp_dpms(&dp->display, DRM_MODE_DPMS_OFF);
return 0;
 }

 static int exynos_dp_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct exynos_drm_display *display = platform_get_drvdata(pdev);
+   struct exynos_dp_device *dp = dev_get_drvdata(dev);

-   exynos_dp_dpms(display, DRM_MODE_DPMS_ON);
+   exynos_dp_dpms(&dp->display, DRM_MODE_DPMS_ON);
return 0;
 }
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..763893ee 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -17,6 +17,8 @@
 #include 
 #include 

+#include "exyno

[PATCH 12/14] drm/exynos/dp: stop using display->ctx pointer

2014-11-17 Thread Andrzej Hajda
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a7f5feb..fadfe1f 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -35,6 +35,12 @@
 #define ctx_from_connector(c)  container_of(c, struct exynos_dp_device, \
connector)

+static inline struct exynos_dp_device *
+display_to_dp(struct exynos_drm_display *d)
+{
+   return container_of(d, struct exynos_dp_device, display);
+}
+
 struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -881,7 +887,7 @@ static void exynos_dp_hotplug(struct work_struct *work)

 static void exynos_dp_commit(struct exynos_drm_display *display)
 {
-   struct exynos_dp_device *dp = display->ctx;
+   struct exynos_dp_device *dp = display_to_dp(display);
int ret;

/* Keep the panel disabled while we configure video */
@@ -1019,7 +1025,7 @@ static int exynos_drm_attach_lcd_bridge(struct drm_device 
*dev,
 static int exynos_dp_create_connector(struct exynos_drm_display *display,
struct drm_encoder *encoder)
 {
-   struct exynos_dp_device *dp = display->ctx;
+   struct exynos_dp_device *dp = display_to_dp(display);
struct drm_connector *connector = &dp->connector;
int ret;

@@ -1077,7 +1083,7 @@ static void exynos_dp_phy_exit(struct exynos_dp_device 
*dp)

 static void exynos_dp_poweron(struct exynos_drm_display *display)
 {
-   struct exynos_dp_device *dp = display->ctx;
+   struct exynos_dp_device *dp = display_to_dp(display);

if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;
@@ -1098,7 +1104,7 @@ static void exynos_dp_poweron(struct exynos_drm_display 
*display)

 static void exynos_dp_poweroff(struct exynos_drm_display *display)
 {
-   struct exynos_dp_device *dp = display->ctx;
+   struct exynos_dp_device *dp = display_to_dp(display);

if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;
@@ -1123,7 +1129,7 @@ static void exynos_dp_poweroff(struct exynos_drm_display 
*display)

 static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
 {
-   struct exynos_dp_device *dp = display->ctx;
+   struct exynos_dp_device *dp = display_to_dp(display);

switch (mode) {
case DRM_MODE_DPMS_ON:
@@ -1385,8 +1391,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}

-   dp->display.ctx = dp;
-
ret = component_add(&pdev->dev, &exynos_dp_ops);
if (ret)
exynos_drm_component_del(&pdev->dev,
-- 
1.9.1



[PATCH 14/14] drm/exynos/dpi: stop using display->ctx pointer

2014-11-17 Thread Andrzej Hajda
The patch replaces accesses to display->ctx pointer by container_of
construct. The field is removed as well as dpi was the last user of it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 5 ++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 3acfc28..37678cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -106,7 +106,7 @@ static struct drm_connector_helper_funcs 
exynos_dpi_connector_helper_funcs = {
 static int exynos_dpi_create_connector(struct exynos_drm_display *display,
   struct drm_encoder *encoder)
 {
-   struct exynos_dpi *ctx = display->ctx;
+   struct exynos_dpi *ctx = display_to_dpi(display);
struct drm_connector *connector = &ctx->connector;
int ret;

@@ -147,7 +147,7 @@ static void exynos_dpi_poweroff(struct exynos_dpi *ctx)

 static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode)
 {
-   struct exynos_dpi *ctx = display->ctx;
+   struct exynos_dpi *ctx = display_to_dpi(display);

switch (mode) {
case DRM_MODE_DPMS_ON:
@@ -307,7 +307,6 @@ struct exynos_drm_display *exynos_dpi_probe(struct device 
*dev)
ctx->display.type = EXYNOS_DISPLAY_TYPE_LCD;
ctx->display.ops = &exynos_dpi_display_ops;
ctx->dev = dev;
-   ctx->display.ctx = ctx;
ctx->dpms_mode = DRM_MODE_DPMS_OFF;

ret = exynos_drm_component_add(dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index c5ad852..61855c3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -168,7 +168,6 @@ struct exynos_drm_display {
struct drm_encoder *encoder;
struct drm_connector *connector;
struct exynos_drm_display_ops *ops;
-   void *ctx;
 };

 /*
-- 
1.9.1



[PATCH 13/14] drm/exynos/dpi: embed display into private context

2014-11-17 Thread Andrzej Hajda
exynos_drm_display is used by internal Exynos DRM framework for
representing encoder:connector pair. As it should be mapped 1:1 to dpi
private context it seems more reasonable to embed it directly in that context.
As a result further code simplification will be possible.
Moreover it will be possible to handle multiple dpi devices in the system.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  | 39 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |  2 +-
 3 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 3dc678e..3acfc28 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -22,6 +22,7 @@
 #include "exynos_drm_drv.h"

 struct exynos_dpi {
+   struct exynos_drm_display display;
struct device *dev;
struct device_node *panel_node;

@@ -35,6 +36,11 @@ struct exynos_dpi {

 #define connector_to_dpi(c) container_of(c, struct exynos_dpi, connector)

+static inline struct exynos_dpi *display_to_dpi(struct exynos_drm_display *d)
+{
+   return container_of(d, struct exynos_dpi, display);
+}
+
 static enum drm_connector_status
 exynos_dpi_detect(struct drm_connector *connector, bool force)
 {
@@ -165,11 +171,6 @@ static struct exynos_drm_display_ops 
exynos_dpi_display_ops = {
.dpms = exynos_dpi_dpms
 };

-static struct exynos_drm_display exynos_dpi_display = {
-   .type = EXYNOS_DISPLAY_TYPE_LCD,
-   .ops = &exynos_dpi_display_ops,
-};
-
 /* of_* functions will be removed after merge of of_graph patches */
 static struct device_node *
 of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 reg)
@@ -299,20 +300,22 @@ struct exynos_drm_display *exynos_dpi_probe(struct device 
*dev)
struct exynos_dpi *ctx;
int ret;

-   ret = exynos_drm_component_add(dev,
-   EXYNOS_DEVICE_TYPE_CONNECTOR,
-   exynos_dpi_display.type);
-   if (ret)
-   return ERR_PTR(ret);
-
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
-   goto err_del_component;
+   return ERR_PTR(-ENOMEM);

+   ctx->display.type = EXYNOS_DISPLAY_TYPE_LCD;
+   ctx->display.ops = &exynos_dpi_display_ops;
ctx->dev = dev;
-   exynos_dpi_display.ctx = ctx;
+   ctx->display.ctx = ctx;
ctx->dpms_mode = DRM_MODE_DPMS_OFF;

+   ret = exynos_drm_component_add(dev,
+   EXYNOS_DEVICE_TYPE_CONNECTOR,
+   ctx->display.type);
+   if (ret)
+   return ERR_PTR(ret);
+
ret = exynos_dpi_parse_dt(ctx);
if (ret < 0) {
devm_kfree(dev, ctx);
@@ -328,7 +331,7 @@ struct exynos_drm_display *exynos_dpi_probe(struct device 
*dev)
}
}

-   return &exynos_dpi_display;
+   return &ctx->display;

 err_del_component:
exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
@@ -336,16 +339,16 @@ err_del_component:
return NULL;
 }

-int exynos_dpi_remove(struct device *dev)
+int exynos_dpi_remove(struct exynos_drm_display *display)
 {
-   struct exynos_dpi *ctx = exynos_dpi_display.ctx;
+   struct exynos_dpi *ctx = display_to_dpi(display);

-   exynos_dpi_dpms(&exynos_dpi_display, DRM_MODE_DPMS_OFF);
+   exynos_dpi_dpms(&ctx->display, DRM_MODE_DPMS_OFF);

if (ctx->panel)
drm_panel_detach(ctx->panel);

-   exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
+   exynos_drm_component_del(ctx->dev, EXYNOS_DEVICE_TYPE_CONNECTOR);

return 0;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index d8240fd..c5ad852 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -334,7 +334,7 @@ void exynos_platform_device_ipp_unregister(void);

 #ifdef CONFIG_DRM_EXYNOS_DPI
 struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
-int exynos_dpi_remove(struct device *dev);
+int exynos_dpi_remove(struct exynos_drm_display *display);
 #else
 static inline struct exynos_drm_display *
 exynos_dpi_probe(struct device *dev) { return NULL; }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 2a652ab..f4d24f2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1077,7 +1077,7 @@ static void fimd_unbind(struct device *dev, struct device 
*master,
fimd_dpms(&ctx->manager, DRM_MODE_DPMS_OFF);

if (ctx->display)
-   exynos_dpi_remove(dev);
+   exynos_dpi_remove(ctx->display);

fimd_mgr_remove(&ctx->manager);
 }
-- 
1.9.1



[PATCH 1/2] drm/edid: new drm_edid_block_checksum helper function

2014-11-17 Thread Jani Nikula
On Sun, 16 Nov 2014, Stefan Brüns  wrote:

This needs a rationale for its existence here.

You could also use the function in drm_edid_block_valid to not duplicate
the code.

BR,
Jani.

> Signed-off-by: Stefan Brüns 
> ---
>  drivers/gpu/drm/drm_edid.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0755d01..505960e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1184,6 +1184,17 @@ static bool drm_edid_is_zero(u8 *in_edid, int length)
>   return true;
>  }
>  
> +static u8
> +drm_edid_block_checksum(u8 *raw_edid)
> +{
> + int i;
> + u8 csum = 0;
> + for (i = 0; i < EDID_LENGTH; i++)
> + csum += raw_edid[i];
> +
> + return csum;
> +}
> +
>  static u8 *
>  drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
>  {
> -- 
> 1.8.4.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH 2/2] drm/edid: Tighten checksum conditions for CEA blocks

2014-11-17 Thread Jani Nikula
On Sun, 16 Nov 2014, Stefan Brüns  wrote:
> 4a638b4e38234233f5c7e6705662fbc0b58d80c2 disabled the checksumming

Please include the subject of the referenced commit, e.g.

4a638b4e3823 drm/edid: Allow non-fatal checksum errors in CEA blocks

or

commit 4a638b4e38234233f5c7e6705662fbc0b58d80c2
Author: Adam Jackson 
Date:   Tue May 25 16:33:09 2010 -0400

drm/edid: Allow non-fatal checksum errors in CEA blocks

> for CEA blocks. If only the checksum is wrong, reading twice should
> result in identical data, whereas a bad transfer will most likely
> corrupt diffent bytes.
>
> Signed-off-by: Stefan Brüns 
> ---
>  drivers/gpu/drm/drm_edid.c | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 505960e..9b6b65e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1200,6 +1200,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
> i2c_adapter *adapter)
>  {
>   int i, j = 0, valid_extensions = 0;
>   u8 *block, *new;
> + u8 *saved_block = NULL;
>   bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
> DRM_UT_KMS);
>  
>   if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> @@ -1234,15 +1235,29 @@ drm_do_get_edid(struct drm_connector *connector, 
> struct i2c_adapter *adapter)
>   block = new;
>  
>   for (j = 1; j <= block[0x7e]; j++) {
> + u8 *ext_block = block + (valid_extensions + 1) * EDID_LENGTH;

This bit could be a non-functional prep patch.

> + u8 csum, last_csum = 0;
>   for (i = 0; i < 4; i++) {
> - if (drm_do_probe_ddc_edid(adapter,
> -   block + (valid_extensions + 1) * EDID_LENGTH,
> -   j, EDID_LENGTH))
> + if (drm_do_probe_ddc_edid(adapter, ext_block, j, 
> EDID_LENGTH))
>   goto out;
> - if (drm_edid_block_valid(block + (valid_extensions + 1) 
> * EDID_LENGTH, j, print_bad_edid)) {

Now you skip drm_edid_block_valid for all blocks?

> + if ((csum = drm_edid_block_checksum(ext_block)) == 0) {

Please don't assign within the if condition.

>   valid_extensions++;
>   break;
> + } else if ((ext_block[0] == CEA_EXT) && (csum == 
> last_csum)) {

Too many braces.

Perhaps it would be sufficient to just check checksums instead of
comparing the data? *shrug*.

> + /*
> +  * Some switches mangle CEA contents without fixing the 
> checksum.
> +  * Accept CEA blocks when two reads return identical 
> data.
> +  */

So you end up here on the 2nd time you get identical checksums, but you
don't have the saved_block for the 1st attempt. Therefore you end up
saving the 2nd attempt and go for a 3rd attempt to end up here.

> + if (!saved_block)
> + saved_block = kmalloc(EDID_LENGTH, 
> GFP_KERNEL);
> + if (saved_block && !memcmp(ext_block, 
> saved_block, EDID_LENGTH)) {

On the 2nd attempt you compare ext_block to whatever kmalloc returned
you.

> + valid_extensions++;
> + break;
> + }
> + if (saved_block)
> + memcpy(saved_block, ext_block, 
> EDID_LENGTH);

You should use kmemdup, and rearrange the code to do what it says on the
commit message.

BR,
Jani.

>   }
> + last_csum = csum;
>   }
>  
>   if (i == 4 && print_bad_edid) {
> @@ -1263,6 +1278,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
> i2c_adapter *adapter)
>   block = new;
>   }
>  
> + kfree(saved_block);
>   return block;
>  
>  carp:
> @@ -1273,6 +1289,7 @@ carp:
>   connector->bad_edid_counter++;
>  
>  out:
> + kfree(saved_block);
>   kfree(block);
>   return NULL;
>  }
> -- 
> 1.8.4.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm/edid: Check for empty block prior to checksumming

2014-11-17 Thread Jani Nikula
On Sun, 16 Nov 2014, Stefan Brüns  wrote:
> drm_edid_block_valid will dump the whole EDID block. Shorten the log
> output to a single line stating the block is empty.

I'd think it would be better to teach drm_edid_block_valid to better
handle empty blocks.

BR,
Jani.

>
> Signed-off-by: Stefan Brüns 
> ---
>  drivers/gpu/drm/drm_edid.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3bf9991..0755d01 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1198,12 +1198,17 @@ drm_do_get_edid(struct drm_connector *connector, 
> struct i2c_adapter *adapter)
>   for (i = 0; i < 4; i++) {
>   if (drm_do_probe_ddc_edid(adapter, block, 0, EDID_LENGTH))
>   goto out;
> - if (drm_edid_block_valid(block, 0, print_bad_edid))
> - break;
>   if (i == 0 && drm_edid_is_zero(block, EDID_LENGTH)) {
>   connector->null_edid_counter++;
> - goto carp;
> + if (print_bad_edid) {
> + dev_warn(connector->dev->dev, "%s: EDID block 0 
> empty.\n",
> +  connector->name);
> + }
> + connector->bad_edid_counter++;
> + goto out;
>   }
> + if (drm_edid_block_valid(block, 0, print_bad_edid))
> + break;
>   }
>   if (i == 4)
>   goto carp;
> -- 
> 1.8.4.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center


Long radeon stalls on recent kernels

2014-11-17 Thread Michel Dänzer
On 15.11.2014 07:21, Andy Lutomirski wrote:
> I have a Caicos card, like this:
>
> [3.077260] [drm] radeon kernel modesetting enabled.
> [3.077338] checking generic (e000 60) vs hw (e000 1000)
> [3.077339] fb: switching to radeondrmfb from EFI VGA
> [3.077377] Console: switching to colour dummy device 80x25
> [3.078881] [drm] initializing kernel modesetting (CAICOS
> 0x1002:0x6779 0x174B:0xE164).
> [3.078903] [drm] register mmio base: 0xF4A2
> [3.078904] [drm] register mmio size: 131072
> [3.078982] ATOM BIOS: C26401
> [3.079572] radeon :09:00.0: VRAM: 1024M 0x -
> 0x3FFF (1024M used)
> [3.079574] radeon :09:00.0: GTT: 1024M 0x4000 -
> 0x7FFF
> [3.079576] [drm] Detected VRAM RAM=1024M, BAR=256M
> [3.079577] [drm] RAM width 64bits DDR
> [3.079755] [TTM] Zone  kernel: Available graphics memory: 8186568 kiB
> [3.079757] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [3.079757] [TTM] Initializing pool allocator
> [3.079773] [TTM] Initializing DMA pool allocator
> [3.080011] [drm] radeon: 1024M of VRAM memory ready
> [3.080012] [drm] radeon: 1024M of GTT memory ready.
> [3.080049] [drm] Loading CAICOS Microcode
> [3.080330] [drm] Internal thermal controller without fan control
> [3.081425] [drm] radeon: power management initialized
> [3.081551] [drm] GART: num cpu pages 262144, num gpu pages 262144
> [3.082589] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [3.085030] [drm] PCIE GART of 1024M enabled (table at 0x00274000).
> [3.085221] radeon :09:00.0: WB enabled
> [3.085224] radeon :09:00.0: fence driver on ring 0 use gpu
> addr 0x4c00 and cpu addr 0x88043d914c00
> [3.085225] radeon :09:00.0: fence driver on ring 3 use gpu
> addr 0x4c0c and cpu addr 0x88043d914c0c
> [3.097438] radeon :09:00.0: fence driver on ring 5 use gpu
> addr 0x00072118 and cpu addr 0xc900128b2118
> [3.097441] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [3.097442] [drm] Driver supports precise vblank timestamp query.
> [3.097514] radeon :09:00.0: irq 56 for MSI/MSI-X
> [3.097544] radeon :09:00.0: radeon: using MSI.
> [3.097614] [drm] radeon: irq initialized.
>
> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
> graphics intensive seems to cause my system to become unusable for
> tens of seconds.  Pointing Firefox at Google Maps is a big offender --
> it can take several minutes for me to move my mouse far enough to
> close the tab and get my computer back.
>
> On bootup, I get this warning:
> [drm:btc_dpm_set_power_state] *ERROR*
> rv770_restrict_performance_levels_before_switch failed
>
> Setting radeon.dpm=0 seems to work around this problem at the cost of
> giving my rather slow graphics.
>
> Are there known issues here?

Can you bisect the kernel, or at least isolate which kernel version 
first introduced the problem?


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


[Bug 85647] Random radeonsi crashes with mesa 10.3.x

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=85647

--- Comment #29 from Hannu  ---
(In reply to Michel Dänzer from comment #28)
> Module: Mesa
> Branch: master
> Commit: ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
> URL:   
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
> 
> Author: Michel Dänzer 
> Date:   Tue Nov 11 16:10:20 2014 +0900
> 
> radeonsi: Disable asynchronous DMA except for PIPE_BUFFER

There might be something that fixes this bug in linux 3.18.0-rc5.
I just tested linux 3.18.0-rc5 with the same mesa 10.4.0-devel package as in
comment 27.


Tested with a 23 minute full screen flash video same as before.

Mesa 10.4.0-devel and linux 3.18.0-rc5: 10 playbacks of the video, no
crashes/lockups.


I'll test mesa 10.3.2 original debian package without changes and linux
3.18.0-rc5 tomorrow.

-- 
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/20141117/617568d8/attachment.html>


[PATCH] drm: omapdrm: remove unused variable

2014-11-17 Thread Boris Brezillon
Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change
drm_flip_work_init prototype" changed the drm_flip_work_init prototype
to a void function, which makes 'ret' an unused variable.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/omapdrm/omap_plane.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 0ad7401..ee8e2b3 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -388,7 +388,6 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
struct drm_plane *plane = NULL;
struct omap_plane *omap_plane;
struct omap_overlay_info *info;
-   int ret;

DBG("%s: priv=%d", plane_names[id], private_plane);

-- 
1.9.1



[Bug 83461] hdmi screen flicker/unusable

2014-11-17 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=83461

--- Comment #21 from Christian König  ---
(In reply to kb from comment #20)
> Hi, unfortunately supplied patch does not fix the issue. Do you need some
> more debug output?

dmesg output generated with drm.debug=0xE on the kernel command line would be
nice. But I'm running out of idea what else this could be.

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


[PATCH 4/9] drm/exynos: fimd: add fimd_enable_shadow_channel_path() to cleanup

2014-11-17 Thread YoungJun Cho
This function is valid only the SoC has SHADOWCON register
and it should be used together with fimd_enable_video_output()
to match the ENWIN_F bit in WINCON# and C#_EN_F bit in SHADOWCON.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 5cfd251..fd7b469 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -242,6 +242,19 @@ static void fimd_enable_video_output(struct fimd_context 
*ctx, int win,
writel(val, ctx->regs + WINCON(win));
 }

+static void fimd_enable_shadow_channel_path(struct fimd_context *ctx, int win,
+   bool enable)
+{
+   u32 val = readl(ctx->regs + SHADOWCON);
+
+   if (enable)
+   val |= SHADOWCON_CHx_ENABLE(win);
+   else
+   val &= ~SHADOWCON_CHx_ENABLE(win);
+
+   writel(val, ctx->regs + SHADOWCON);
+}
+
 static void fimd_clear_channel(struct exynos_drm_manager *mgr)
 {
struct fimd_context *ctx = mgr->ctx;
@@ -256,12 +269,10 @@ static void fimd_clear_channel(struct exynos_drm_manager 
*mgr)
if (val & WINCONx_ENWIN) {
fimd_enable_video_output(ctx, win, false);

-   /* unprotect windows */
-   if (ctx->driver_data->has_shadowcon) {
-   val = readl(ctx->regs + SHADOWCON);
-   val &= ~SHADOWCON_CHx_ENABLE(win);
-   writel(val, ctx->regs + SHADOWCON);
-   }
+   if (ctx->driver_data->has_shadowcon)
+   fimd_enable_shadow_channel_path(ctx, win,
+   false);
+
ch_enabled = 1;
}
}
@@ -759,11 +770,8 @@ static void fimd_win_commit(struct exynos_drm_manager 
*mgr, int zpos)

fimd_enable_video_output(ctx, win, true);

-   if (ctx->driver_data->has_shadowcon) {
-   val = readl(ctx->regs + SHADOWCON);
-   val |= SHADOWCON_CHx_ENABLE(win);
-   writel(val, ctx->regs + SHADOWCON);
-   }
+   if (ctx->driver_data->has_shadowcon)
+   fimd_enable_shadow_channel_path(ctx, win, true);

/* Enable DMA channel and unprotect windows */
fimd_shadow_protect_win(ctx, win, false);
@@ -779,7 +787,6 @@ static void fimd_win_disable(struct exynos_drm_manager 
*mgr, int zpos)
struct fimd_context *ctx = mgr->ctx;
struct fimd_win_data *win_data;
int win = zpos;
-   u32 val;

if (win == DEFAULT_ZPOS)
win = ctx->default_win;
@@ -800,13 +807,10 @@ static void fimd_win_disable(struct exynos_drm_manager 
*mgr, int zpos)

fimd_enable_video_output(ctx, win, false);

-   /* unprotect windows */
-   if (ctx->driver_data->has_shadowcon) {
-   val = readl(ctx->regs + SHADOWCON);
-   val &= ~SHADOWCON_CHx_ENABLE(win);
-   writel(val, ctx->regs + SHADOWCON);
-   }
+   if (ctx->driver_data->has_shadowcon)
+   fimd_enable_shadow_channel_path(ctx, win, false);

+   /* unprotect windows */
fimd_shadow_protect_win(ctx, win, false);

win_data->enabled = false;
-- 
1.9.0



[PATCH v2 0/9] drm/exynos: modify LCD I80 interface display

2014-11-17 Thread YoungJun Cho
Hi,

This series modifies LCD I80 interface display for Exynos DRM driver
to make it similar with Video(RGB) interface.
Some patches in v1 are applied already and these are modified as Inki's
comments.
And Joonyoung's patches are also included for merge convenience.

This is based on exynos-drm-next branch.

The previous patches,
v1: http://www.spinics.net/lists/dri-devel/msg69159.html

Changelog v2:
- Splits patches into single feature. (commented by Inki)

I welcome any comments.

Thank you.
Best regards YJ

Joonyoung Shim (2):
  drm/exynos: move triggering checking
  drm/exynos: use irq_flags instead of triggering

YoungJun Cho (7):
  drm/exynos: fimd: move shadow unprotection position
  drm/exynos: fimd: add fimd_enable_video_output() to cleanup
  drm/exynos: fimd: add fimd_enable_shadow_channel_path() to cleanup
  drm/exynos: fimd: modify I80 i/f irq relevant routine
  drm/exynos: fimd: add triggering unset routine in fimd_trigger()
  drm/exynos: dsi: move TE irq handler registration position
  drm/exynos: dsi: set TE GPIO IRQ status as IRQ_NOAUTOEN

 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  19 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 135 ++-
 2 files changed, 85 insertions(+), 69 deletions(-)

-- 
1.9.0



[PATCH 1/9] drm/exynos: move triggering checking

2014-11-17 Thread YoungJun Cho
From: Joonyoung Shim 

It's better to be checking whether triggerring in fimd_trigger function.
Also it will return if in triggerring on fimd_te_handler, then it can't
execute remain codes.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0673a39..ec2d170 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -949,6 +949,13 @@ static void fimd_trigger(struct device *dev)
void *timing_base = ctx->regs + driver_data->timing_base;
u32 reg;

+/*
+* Skips to trigger if in triggering state, because multiple triggering
+* requests can cause panel reset.
+*/
+   if (atomic_read(&ctx->triggering))
+   return;
+
atomic_set(&ctx->triggering, 1);

reg = readl(ctx->regs + VIDINTCON0);
@@ -969,13 +976,6 @@ static void fimd_te_handler(struct exynos_drm_manager *mgr)
if (ctx->pipe < 0 || !ctx->drm_dev)
return;

-/*
-* Skips to trigger if in triggering state, because multiple triggering
-* requests can cause panel reset.
-*/
-   if (atomic_read(&ctx->triggering))
-   return;
-
/*
 * If there is a page flip request, triggers and handles the page flip
 * event so that current fb can be updated into panel GRAM.
-- 
1.9.0



[PATCH 2/9] drm/exynos: fimd: move shadow unprotection position

2014-11-17 Thread YoungJun Cho
The C#_EN_F in SHADOWCON register is updated per frame.
So it should be protected by fimd_shadow_protect_win().

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index ec2d170..77ba961 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -751,15 +751,15 @@ static void fimd_win_commit(struct exynos_drm_manager 
*mgr, int zpos)
val |= WINCONx_ENWIN;
writel(val, ctx->regs + WINCON(win));

-   /* Enable DMA channel and unprotect windows */
-   fimd_shadow_protect_win(ctx, win, false);
-
if (ctx->driver_data->has_shadowcon) {
val = readl(ctx->regs + SHADOWCON);
val |= SHADOWCON_CHx_ENABLE(win);
writel(val, ctx->regs + SHADOWCON);
}

+   /* Enable DMA channel and unprotect windows */
+   fimd_shadow_protect_win(ctx, win, false);
+
win_data->enabled = true;

if (ctx->i80_if)
-- 
1.9.0



[PATCH 3/9] drm/exynos: fimd: add fimd_enable_video_output() to cleanup

2014-11-17 Thread YoungJun Cho
This bit is used for video output and logic signal control.
So it is better for readability.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 77ba961..5cfd251 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -229,6 +229,19 @@ static void fimd_wait_for_vblank(struct exynos_drm_manager 
*mgr)
DRM_DEBUG_KMS("vblank wait timed out.\n");
 }

+static void fimd_enable_video_output(struct fimd_context *ctx, int win,
+   bool enable)
+{
+   u32 val = readl(ctx->regs + WINCON(win));
+
+   if (enable)
+   val |= WINCONx_ENWIN;
+   else
+   val &= ~WINCONx_ENWIN;
+
+   writel(val, ctx->regs + WINCON(win));
+}
+
 static void fimd_clear_channel(struct exynos_drm_manager *mgr)
 {
struct fimd_context *ctx = mgr->ctx;
@@ -241,9 +254,7 @@ static void fimd_clear_channel(struct exynos_drm_manager 
*mgr)
u32 val = readl(ctx->regs + WINCON(win));

if (val & WINCONx_ENWIN) {
-   /* wincon */
-   val &= ~WINCONx_ENWIN;
-   writel(val, ctx->regs + WINCON(win));
+   fimd_enable_video_output(ctx, win, false);

/* unprotect windows */
if (ctx->driver_data->has_shadowcon) {
@@ -746,10 +757,7 @@ static void fimd_win_commit(struct exynos_drm_manager 
*mgr, int zpos)
if (win != 0)
fimd_win_set_colkey(ctx, win);

-   /* wincon */
-   val = readl(ctx->regs + WINCON(win));
-   val |= WINCONx_ENWIN;
-   writel(val, ctx->regs + WINCON(win));
+   fimd_enable_video_output(ctx, win, true);

if (ctx->driver_data->has_shadowcon) {
val = readl(ctx->regs + SHADOWCON);
@@ -790,10 +798,7 @@ static void fimd_win_disable(struct exynos_drm_manager 
*mgr, int zpos)
/* protect windows */
fimd_shadow_protect_win(ctx, win, true);

-   /* wincon */
-   val = readl(ctx->regs + WINCON(win));
-   val &= ~WINCONx_ENWIN;
-   writel(val, ctx->regs + WINCON(win));
+   fimd_enable_video_output(ctx, win, false);

/* unprotect windows */
if (ctx->driver_data->has_shadowcon) {
-- 
1.9.0



[PATCH 5/9] drm/exynos: fimd: modify I80 i/f irq relevant routine

2014-11-17 Thread YoungJun Cho
For the I80 interface, the video interrupt pending register(VIDINTCON1)
should be handled in fimd_irq_handler() and the video interrupt control
register(VIDINTCON0) should be handled in fimd_enable_vblank() and
fimd_disable_vblank() like RGB interface.
So this patch moves each set / unset routines into proper positions.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 53 
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index fd7b469..3c63237 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -469,12 +469,19 @@ static int fimd_enable_vblank(struct exynos_drm_manager 
*mgr)
val = readl(ctx->regs + VIDINTCON0);

val |= VIDINTCON0_INT_ENABLE;
-   val |= VIDINTCON0_INT_FRAME;

-   val &= ~VIDINTCON0_FRAMESEL0_MASK;
-   val |= VIDINTCON0_FRAMESEL0_VSYNC;
-   val &= ~VIDINTCON0_FRAMESEL1_MASK;
-   val |= VIDINTCON0_FRAMESEL1_NONE;
+   if (ctx->i80_if) {
+   val |= VIDINTCON0_INT_I80IFDONE;
+   val |= VIDINTCON0_INT_SYSMAINCON;
+   val &= ~VIDINTCON0_INT_SYSSUBCON;
+   } else {
+   val |= VIDINTCON0_INT_FRAME;
+
+   val &= ~VIDINTCON0_FRAMESEL0_MASK;
+   val |= VIDINTCON0_FRAMESEL0_VSYNC;
+   val &= ~VIDINTCON0_FRAMESEL1_MASK;
+   val |= VIDINTCON0_FRAMESEL1_NONE;
+   }

writel(val, ctx->regs + VIDINTCON0);
}
@@ -493,9 +500,15 @@ static void fimd_disable_vblank(struct exynos_drm_manager 
*mgr)
if (test_and_clear_bit(0, &ctx->irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);

-   val &= ~VIDINTCON0_INT_FRAME;
val &= ~VIDINTCON0_INT_ENABLE;

+   if (ctx->i80_if) {
+   val &= ~VIDINTCON0_INT_I80IFDONE;
+   val &= ~VIDINTCON0_INT_SYSMAINCON;
+   val &= ~VIDINTCON0_INT_SYSSUBCON;
+   } else
+   val &= ~VIDINTCON0_INT_FRAME;
+
writel(val, ctx->regs + VIDINTCON0);
}
 }
@@ -959,19 +972,15 @@ static void fimd_trigger(struct device *dev)
u32 reg;

 /*
-* Skips to trigger if in triggering state, because multiple triggering
-* requests can cause panel reset.
-*/
+ * Skips triggering if in triggering state, because multiple triggering
+ * requests can cause panel reset.
+ */
if (atomic_read(&ctx->triggering))
return;

+   /* Enters triggering mode */
atomic_set(&ctx->triggering, 1);

-   reg = readl(ctx->regs + VIDINTCON0);
-   reg |= (VIDINTCON0_INT_ENABLE | VIDINTCON0_INT_I80IFDONE |
-   VIDINTCON0_INT_SYSMAINCON);
-   writel(reg, ctx->regs + VIDINTCON0);
-
reg = readl(timing_base + TRIGCON);
reg |= (TRGMODE_I80_RGB_ENABLE_I80 | SWTRGCMD_I80_RGB_ENABLE);
writel(reg, timing_base + TRIGCON);
@@ -1036,21 +1045,13 @@ static irqreturn_t fimd_irq_handler(int irq, void 
*dev_id)
if (ctx->pipe < 0 || !ctx->drm_dev)
goto out;

-   if (ctx->i80_if) {
-   /* unset I80 frame done interrupt */
-   val = readl(ctx->regs + VIDINTCON0);
-   val &= ~(VIDINTCON0_INT_I80IFDONE | VIDINTCON0_INT_SYSMAINCON);
-   writel(val, ctx->regs + VIDINTCON0);
+   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);

-   /* exit triggering mode */
+   if (ctx->i80_if) {
+   /* Exits triggering mode */
atomic_set(&ctx->triggering, 0);
-
-   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
-   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
} else {
-   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
-   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
-
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(&ctx->wait_vsync_event)) {
atomic_set(&ctx->wait_vsync_event, 0);
-- 
1.9.0



[PATCH 6/9] drm/exynos: fimd: add triggering unset routine in fimd_trigger()

2014-11-17 Thread YoungJun Cho
There is a case like set config which requires triggering
but vblank is not enabled yet.
So triggering unset routine is required to exit from
triggering mode.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 3c63237..e488b80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -984,6 +984,13 @@ static void fimd_trigger(struct device *dev)
reg = readl(timing_base + TRIGCON);
reg |= (TRGMODE_I80_RGB_ENABLE_I80 | SWTRGCMD_I80_RGB_ENABLE);
writel(reg, timing_base + TRIGCON);
+
+   /*
+* Exits triggering mode if vblank is not enabled yet, because when the
+* VIDINTCON0 register is not set, it can not exit from triggering mode.
+*/
+   if (!test_bit(0, &ctx->irq_flags))
+   atomic_set(&ctx->triggering, 0);
 }

 static void fimd_te_handler(struct exynos_drm_manager *mgr)
-- 
1.9.0



[PATCH 7/9] drm/exynos: use irq_flags instead of triggering

2014-11-17 Thread YoungJun Cho
From: Joonyoung Shim 

The drm_handle_vblank should be called whenever be vsync, te interrupt
means vsync on i80 interface.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e488b80..a8ab3ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1014,7 +1014,7 @@ static void fimd_te_handler(struct exynos_drm_manager 
*mgr)
wake_up(&ctx->wait_vsync_queue);
}

-   if (!atomic_read(&ctx->triggering))
+   if (test_bit(0, &ctx->irq_flags))
drm_handle_vblank(ctx->drm_dev, ctx->pipe);
 }

@@ -1052,13 +1052,15 @@ static irqreturn_t fimd_irq_handler(int irq, void 
*dev_id)
if (ctx->pipe < 0 || !ctx->drm_dev)
goto out;

-   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
-   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
-
if (ctx->i80_if) {
+   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+
/* Exits triggering mode */
atomic_set(&ctx->triggering, 0);
} else {
+   drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+   exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(&ctx->wait_vsync_event)) {
atomic_set(&ctx->wait_vsync_event, 0);
-- 
1.9.0



[PATCH 8/9] drm/exynos: dsi: move TE irq handler registration position

2014-11-17 Thread YoungJun Cho
The drm_helper_hpd_irq_event() does dpms control and
the panel is initialized and displayed on by it.
So the exynos_dsi_te_irq_handler() should be registered
beforehand.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 66d427e..6fe6486 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1207,9 +1207,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
*host,
dsi->mode_flags = device->mode_flags;
dsi->panel_node = device->dev.of_node;

-   if (dsi->connector.dev)
-   drm_helper_hpd_irq_event(dsi->connector.dev);
-
/*
 * This is a temporary solution and should be made by more generic way.
 *
@@ -1223,6 +1220,9 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
*host,
return ret;
}

+   if (dsi->connector.dev)
+   drm_helper_hpd_irq_event(dsi->connector.dev);
+
return 0;
 }

-- 
1.9.0



[PATCH 9/9] drm/exynos: dsi: set TE GPIO IRQ status as IRQ_NOAUTOEN

2014-11-17 Thread YoungJun Cho
The exynos_dsi_te_irq_handler() works only dsi(DPMS) is on.
So it is enough to enable and disable TE GPIO IRQ in
exynos_dsi_enable(disable)_irq() like DSI IRQ.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae a
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 6fe6486..717c719 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1155,6 +1155,7 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
 static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
 {
int ret;
+   int te_gpio_irq;

dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
if (!gpio_is_valid(dsi->te_gpio)) {
@@ -1169,14 +1170,10 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
*dsi)
goto out;
}

-   /*
-* This TE GPIO IRQ should not be set to IRQ_NOAUTOEN, because panel
-* calls drm_panel_init() first then calls mipi_dsi_attach() in probe().
-* It means that te_gpio is invalid when exynos_dsi_enable_irq() is
-* called by drm_panel_init() before panel is attached.
-*/
-   ret = request_threaded_irq(gpio_to_irq(dsi->te_gpio),
-   exynos_dsi_te_irq_handler, NULL,
+   te_gpio_irq = gpio_to_irq(dsi->te_gpio);
+
+   irq_set_status_flags(te_gpio_irq, IRQ_NOAUTOEN);
+   ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
IRQF_TRIGGER_RISING, "TE", dsi);
if (ret) {
dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
-- 
1.9.0



[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73528

--- Comment #18 from MirceaKitsune  ---
(In reply to Michel Dänzer from comment #17)

This happens since an year ago. Commit 2dc35a619c50139d07ad96fc4dfe456e5811c84e
is when I first noticed the problem. I'm uncertain whether I can even still
compile such an old version of MESA at this day. I shall attempt to however.

In case I can't compile: Is there a place where I can download pre-compiled
nightly / weekly builds of MESA at least, dating since last year?

-- 
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/20141117/1189521b/attachment.html>


[Bug 85843] sys-kernel/gentoo-sources-3.17.0 breakes 3D for nouveau on NVIDIA Corporation NV44A [GeForce 6200] (rev a1) → x11-drivers/xf86-video-nouveau-? with sys-kernel/gentoo-sources-3.17.1 - (EE)

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=85843

--- Comment #1 from miguelramos  ---
Problem solved in gentoo-sources-3.17.3

Glxinfo informs me that Gallium 0.4 on NV4A is the actual renderer using gdm.

No error now in dmesg.

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


[Bug 85843] sys-kernel/gentoo-sources-3.17.0 breakes 3D for nouveau on NVIDIA Corporation NV44A [GeForce 6200] (rev a1) → x11-drivers/xf86-video-nouveau-? with sys-kernel/gentoo-sources-3.17.1 - (EE)

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=85843

Ilia Mirkin  changed:

   What|Removed |Added

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

--- Comment #2 from Ilia Mirkin  ---
There was a regression in AGP handling, now fixed. I'm guessing that's what you
were hit by.

-- 
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/20141117/f8b2b079/attachment.html>


[Bug 86394] [radeonsi] Massive Chalice: visual corruption

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86394

Bug ID: 86394
   Summary: [radeonsi] Massive Chalice: visual corruption
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: kai at dev.carbon-project.org

Created attachment 109622
  --> https://bugs.freedesktop.org/attachment.cgi?id=109622&action=edit
Map screen with black areas.

Since I'm not affected by bug 86196 I was able to have a look at Massive
Chalice. In various places there seems to be visual corruption, compared to
screenshots from other people. Most obvious is the "black ring" on the map
screen, that separates the actual map in the foreground from the "oily"
background (see the attached image). It should look like
<http://www.destructoid.com/ul/280358-/MASSIVE%20CHALICE%20PAX%20screen%2012-620x.jpg>.

This might be another incarnation of bug 86038.

My current stack is (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/a4ffc2a445
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r222082 (3.6 devel)
X.Org: 2:1.16.1-1
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
# 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
# c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
# 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
# c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
# 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
# ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
# 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
# 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/7f6f5bff1f
DDX: 1:7.5.0-1

-- 
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/20141117/97a3a3c8/attachment-0001.html>


[Bug 86394] [radeonsi] Massive Chalice: visual corruption

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86394

Kai  changed:

   What|Removed |Added

 Attachment #109622|text/plain  |image/jpeg
  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/20141117/89f48245/attachment.html>


[Bug 85647] Random radeonsi crashes with mesa 10.3.x

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=85647

--- Comment #30 from Aaron B  ---
I would only attempt to say it's fixed after about 2 days of stability playing
multimedia content/dynamic content in an accelerated web browser. 23 Minutes is
not long enough to test this bug, it sometimes took days with flash for me. 

I got a replacement card, so I can't test anything anymore, so I can't help say
if rc5 has any fixes. Sorry.

-- 
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/20141117/fd14e642/attachment.html>


[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

2014-11-17 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=85491

--- Comment #14 from Marek  ---
I can try, but this will be the first time I am going to do this. I have read
this article: https://wiki.ubuntu.com/Kernel/KernelBisection and I am going to
proceed accordingly.

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


[PATCH 2/2] drm/edid: Tighten checksum conditions for CEA blocks

2014-11-17 Thread Brüns, Stefan
On Monday, November 17, 2014 11:08:48 Jani Nikula wrote:
> On Sun, 16 Nov 2014, Stefan Brüns  wrote:
> > 4a638b4e38234233f5c7e6705662fbc0b58d80c2 disabled the checksumming
> 
> Please include the subject of the referenced commit, e.g.
> 
> 4a638b4e3823 drm/edid: Allow non-fatal checksum errors in CEA blocks
> 
> or
> 
> commit 4a638b4e38234233f5c7e6705662fbc0b58d80c2
> Author: Adam Jackson 
> Date:   Tue May 25 16:33:09 2010 -0400
> 
> drm/edid: Allow non-fatal checksum errors in CEA blocks

OK

> 
> > for CEA blocks. If only the checksum is wrong, reading twice should
> > result in identical data, whereas a bad transfer will most likely
> > corrupt diffent bytes.
> > 
> > Signed-off-by: Stefan Brüns 
> > ---
> > 
> >  drivers/gpu/drm/drm_edid.c | 25 +
> >  1 file changed, 21 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 505960e..9b6b65e 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -1200,6 +1200,7 @@ drm_do_get_edid(struct drm_connector *connector,
> > struct i2c_adapter *adapter)> 
> >  {
> >  
> > int i, j = 0, valid_extensions = 0;
> > u8 *block, *new;
> > 
> > +   u8 *saved_block = NULL;
> > 
> > bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
> > DRM_UT_KMS);
> > 
> > if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > 
> > @@ -1234,15 +1235,29 @@ drm_do_get_edid(struct drm_connector *connector,
> > struct i2c_adapter *adapter)> 
> > block = new;
> > 
> > for (j = 1; j <= block[0x7e]; j++) {
> > 
> > +   u8 *ext_block = block + (valid_extensions + 1) * EDID_LENGTH;
> 
> This bit could be a non-functional prep patch.

OK

> > +   u8 csum, last_csum = 0;
> > 
> > for (i = 0; i < 4; i++) {
> > 
> > -   if (drm_do_probe_ddc_edid(adapter,
> > - block + (valid_extensions + 1) * EDID_LENGTH,
> > - j, EDID_LENGTH))
> > +   if (drm_do_probe_ddc_edid(adapter, ext_block, j, 
> > EDID_LENGTH))
> > 
> > goto out;
> > 
> > -   if (drm_edid_block_valid(block + (valid_extensions + 1) 
> > * 
EDID_LENGTH,
> > j, print_bad_edid)) {
> Now you skip drm_edid_block_valid for all blocks?

drm_edid_block_valid does a bunch of things, depending on the block number. 
For blocks after the first block, it is essentially just checksumming the 
block, but also ignores any errors for CEA blocks, which causes problems later 
on. Therefor the use of the new checksum helper.

> > +   if ((csum = drm_edid_block_checksum(ext_block)) == 0) {
> 
> Please don't assign within the if condition.

OK

> > valid_extensions++;
> > break;
> > 
> > +   } else if ((ext_block[0] == CEA_EXT) && (csum == 
> > last_csum)) {
> 
> Too many braces.
> 
> Perhaps it would be sufficient to just check checksums instead of
> comparing the data? *shrug*.

As the EDID checksum is just a linear checksum over all bytes there are a lot 
of error combinations having the same checksum, but different data. I think a 
byte-for-byte comparision is a must here (although the checksum-only would be 
an improvement).

> > +   /*
> > +* Some switches mangle CEA contents without fixing the 
> > checksum.
> > +* Accept CEA blocks when two reads return identical 
> > data.
> > +*/
> 
> So you end up here on the 2nd time you get identical checksums, but you
> don't have the saved_block for the 1st attempt. Therefore you end up
> saving the 2nd attempt and go for a 3rd attempt to end up here.

Good catch, this is obviously wrong. How about the following:

...
} else if (ext_block[0] == CEA_EXT) {
if (saved_block && csum == last_csum &&
!memcmp(ext_block, saved_block, EDID_LENGTH)) {
valid_extensions++;
break;
kfree(saved_block);
saved_block = kmemdup(ext_block, EDID_LENGTH, GFP_KERNEL);
last_csum = csum;
}
...

This should also address the other remarks.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424


[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73530

--- Comment #70 from Alex Deucher  ---
(In reply to Nicolas Werner from comment #69)
> 
> I also have the same problem. (same notebook, so not surprising)
> 
> I tried everything you recommended (in comment #65), in order, nothing
> helps. Any more suggestions?

Does this patch help?
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c9498425453bb65ef339a57705c5ef59fe1541d

> 
> Btw, I'm using OpenSUSE, so Kernel 3.16.6.
> 
> Also xrandr output is much shorter than the ones posted here, is that normal
> when you use modeset=0?

Yes.  When you set modeset=0 you are effectively disabling the radeon driver so
you end up with vesa or efifb or some other platform driver rather than the
native driver.

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


[Bug 86320] Monitor on DisplayPort doesn't wake up

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86320

Alex Deucher  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
Version|git |unspecified
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-team at lists.x.org   |

-- 
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/20141117/d84c8064/attachment.html>


[Bug 85647] Random radeonsi crashes with mesa 10.3.x

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=85647

--- Comment #31 from Malte Schröder  ---
3.18-rc5 does not fix the problem. I just tried and the system crashed after a
few minutes. Now running gain with my patched mesa 10.3.2.

-- 
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/20141117/9c2f6783/attachment-0001.html>


exynos boot falures in linux-next

2014-11-17 Thread Krzysztof Kozłowski
On 17.11.2014 16:57, Kevin Hilman wrote:
> FYI...
> 
> Various new exynos5 boot failures starting next-20141117.  Looking in
> the boot logs, the boot stops during DRM initialization.
> 
> Note that the boot failures are only on exynos_defconfig, and not
> multi_v7_defconfig.

Cc: +Inki Dae, +dri-devel

This came up on Trats2 board (Exynos 4412) since next-20141105:
https://lkml.org/lkml/2014/11/6/125

Disabling DRM helps.

Best regards,
Krzysztof

> 
> Excerpt from boot report below, or recent exynos boots can also be
> explored here:
> 
>http://status.armcloud.us/boot/?exynos
> 
> Kevin
> 
> 
> Kevin's boot bot  writes:
> 
>> Full Build report: http://status.armcloud.us/build/next/kernel/next-20141117/
>> Full Boot report:  
>> http://status.armcloud.us/boot/all/job/next/kernel/next-20141117/
>>
>> Tree/Branch: next
>> Git describe: next-20141117
>>
>> Failed boot tests
>> =
> 
> [...]
> 
>>exynos5422-odroid-xu3: FAIL:arm-exynos_defconfig
>>   
>> http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html
>>   exynos5250-arndale: FAIL:arm-exynos_defconfig
>>   
>> http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5250-arndale.html
>>  exynos5800-peach-pi: FAIL:arm-exynos_defconfig
>>   
>> http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5800-peach-pi.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



[radeonsi, regression, bisected] All my Steam games fail to load into the 3D-engine-powered part (SIGPWR and SIGXCPU)

2014-11-17 Thread Alex Deucher
On Sat, Nov 15, 2014 at 6:59 PM, Kai Wasserbäch
 wrote:
> Kai Wasserbäch wrote on 15.11.2014 22:22:
>> Kai Wasserbäch wrote on 15.11.2014 16:33:
>>> Is there anything besides a bisect you would need to debug this?
>>
>> Ok, I did a bisection, but that time was wasted for sure. My "first bad 
>> commit"
>> isn't bad at all. Is there any way to improve that experience? I'm really 
>> loathe
>> to go through the dozen boots again, just to get another broken bisection.
>
> Ok, after looking at the changes for radeon I decided to try the HEAD of
> drm-next-3.19 (c81b99423bd9d3fc35ac8752ca5fb4c50eab063c). That was still good.
> Armed with this much smaller bisection range, I came up with a result that
> sounds at least believable:
> 3cd76f3901e73a4a61d78c4526dcbf6d87c9a928 is the first bad commit
> commit 3cd76f3901e73a4a61d78c4526dcbf6d87c9a928
> Author: Christian König 
> Date:   Mon Oct 13 12:41:47 2014 +0200
>
> drm/radeon: update the VM after setting BO address (v2)
>
> This way the necessary VM update is kicked off immediately
> if all BOs involved are in GPU accessible memory.
>
> v2: fix vm lock handling
>
> Signed-off-by: Christian König 
> Signed-off-by: Alex Deucher 
>
> :04 04 5bb1cc4497cc2e5b9af3a59170d7a8d5c99fd0a0
> 3df4996bc1a25f9275b833c778cdc33a30b28838 M  drivers
>
> CCing Christian, maybe he has an idea, what's up.
>
> Let me know, if you need something else, to debug this or if I should file 
> this
> as a bug.
>
>
>> I noticed, however, that the following line is showing up with be762d181e in 
>> dmesg:
>> [drm:ci_dpm_init [radeon]] *ERROR* Invalid PCC GPIO!== power state 0 ==
>
> This seems to be unrelated as it shows up with all the commits from the 3.19
> branch, I've tested for this bisection run, even those, that worked. (Might 
> this
> be, however, related to ?)
>

Yes, that is just some additional debugging output for dpm on newer
kernels.  It doesn't change anything from a hw perspective.

Alex

> Cheers,
> Kai
>


[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82201

--- Comment #44 from Alex Deucher  ---
Do my 3.19-wip or 3.19-next kernel branches help?
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19

-- 
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/20141117/a73b73d4/attachment.html>


[Bug 86368] BUILD FAILED: why : forced (dist) upgrade for gcc 3.4.6 over a BIT COUNT, __builtin_ctz

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86368

--- Comment #3 from Emil Velikov  ---
Dear debguy/johnandsara2

As Matt, pointed out bashing is not most appropriate way to approach any person
or project.

Additionally I'm not sure why you build the radeon code, considering that
(based on your statement) you're not using it.

If you have a patch that adds a fall back in case of missing __builtin_ctz(old
compiler etc.), that follows the surrounding coding style, please submit it to
the dri-devel mailing list via git send-email.

Thanks

P.S. Using autoconf macros might be a nice way to detect the presence of
__builtin**. Take a look at the mesa project if you'd like an example.

-- 
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/20141117/b25962aa/attachment.html>


[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=82201

Kai  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #45 from Kai  ---
(In reply to Alex Deucher from comment #44)
> Do my 3.19-wip or 3.19-next kernel branches help?
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19

It seems so, I'm on your 3.19-wip branch (as you might have guessed from [0]),
currently at ab4587f716, because the next commit breaks many applications for
me ([0]), and I haven't seen a non-reclocking boot in a while. As far as I'm
concerned, we can close this (again), until this resurfaces again.


[0] <http://thread.gmane.org/gmane.comp.video.dri.devel/118415>

-- 
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/20141117/b825e2a8/attachment.html>


[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86267

jbart  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from jbart  ---
Hi. I'm unable to reproduce this issue again on a more recent kernel build
(3.18.0-0.rc4.git0.2). I'll just mark it worksforme.

-- 
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/20141117/8d0b63db/attachment-0001.html>


[PATCH] drm/msm/mdp5: get the core clock rate from MDP5 config

2014-11-17 Thread Stephane Viau
The core clock rate depends on the hw configuration. Once we have
read the hardware revision, we can set the core clock to its
maximum value.
Before then, the clock is set at a rate supported by all MDP5
revisions.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 9 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 3 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 1bb3a28..f2c15bd 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -62,6 +62,7 @@ static const struct mdp5_config msm8x74_config = {
.count = 4,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
},
+   .max_clk = 2,
 };

 static const struct mdp5_config apq8084_config = {
@@ -99,6 +100,7 @@ static const struct mdp5_config apq8084_config = {
.count = 5,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
},
+   .max_clk = 32000,
 };

 struct mdp5_config_entry {
@@ -420,12 +422,13 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
if (ret)
goto fail;

-   ret = clk_set_rate(mdp5_kms->src_clk, config->max_clk);
-
ret = mdp5_select_hw_cfg(kms);
if (ret)
goto fail;

+   /* TODO: compute core clock rate at runtime */
+   clk_set_rate(mdp5_kms->src_clk, mdp5_kms->hw_cfg->max_clk);
+
/* make sure things are off before attaching iommu (bootloader could
 * have left things on, in which case we'll start getting faults if
 * we don't disable):
@@ -486,8 +489,6 @@ static struct mdp5_platform_config *mdp5_get_config(struct 
platform_device *dev)
/* TODO */
 #endif
config.iommu = iommu_domain_alloc(&platform_bus_type);
-   /* TODO hard-coded in downstream mdss, but should it be? */
-   config.max_clk = 2;
/* TODO get from DT: */
config.smp_blk_cnt = 22;

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index c91101d..bdbdcda 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -37,6 +37,8 @@ struct mdp5_config {
struct mdp5_sub_block dspp;
struct mdp5_sub_block ad;
struct mdp5_sub_block intf;
+
+   uint32_t max_clk;
 };
 extern const struct mdp5_config *mdp5_cfg;
 #include "mdp5.xml.h"
@@ -78,7 +80,6 @@ struct mdp5_kms {
 /* platform config data (ie. from DT, or pdata) */
 struct mdp5_platform_config {
struct iommu_domain *iommu;
-   uint32_t max_clk;
int smp_blk_cnt;
 };

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project



[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73528

--- Comment #19 from MirceaKitsune  ---
Alright. I dusted up my local GIT clone of MESA, and started checking out and
compiling various versions. So far I only looked at the tags, and found the
releases between which the issue was added: mesa-9.2.5 (works fine) to
mesa-10.0-rc1 (contains the problem).

Now comes the painful process of narrowing down which commit between these two
tags implements the problem. It might take some time, but I'll post here the
moment I have a result.

-- 
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/20141117/cf0f1eeb/attachment.html>


[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73530

--- Comment #71 from Nicolas Werner  ---
Created attachment 109638
  --> https://bugs.freedesktop.org/attachment.cgi?id=109638&action=edit
dmesg with drm/radeon: add locking around atombios scratch space usage

(In reply to Alex Deucher from comment #70)
> (In reply to Nicolas Werner from comment #69)
> > 
> > I also have the same problem. (same notebook, so not surprising)
> > 
> > I tried everything you recommended (in comment #65), in order, nothing
> > helps. Any more suggestions?
> 
> Does this patch help?
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=1c9498425453bb65ef339a57705c5ef59fe1541d
> 
Well, not enough, to get something other than a black screen or some flickering
before between white and black before it decides to stay black. :/
dmesg with debug attached

> > 
> > Btw, I'm using OpenSUSE, so Kernel 3.16.6.
> > 
> > Also xrandr output is much shorter than the ones posted here, is that normal
> > when you use modeset=0?
> 
> Yes.  When you set modeset=0 you are effectively disabling the radeon driver
> so you end up with vesa or efifb or some other platform driver rather than
> the native driver.

Makes sense, thanks!

-- 
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/20141117/fb4f8032/attachment.html>


[Bug 86357] [RadeonSI] GPU lockup with mesa 10.3.3 / kernel 3.17.2

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86357

--- Comment #1 from Andreas Grois  ---
This might be a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=85647

-- 
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/20141117/27b3c3a3/attachment.html>


[Bug 86320] Monitor on DisplayPort doesn't wake up

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86320

--- Comment #2 from Bernhard Rosenkraenzer  ---
dmesg says

[554729.894304] [drm:radeon_dp_link_train_ce] *ERROR* displayport link status
failed
[554729.894307] [drm:radeon_dp_link_train_ce] *ERROR* channel eq failed
[554729.897695] [drm:radeon_dp_link_train_cr] *ERROR* displayport link status
failed
[554729.897697] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[555004.704953] [drm:btc_dpm_set_power_state] *ERROR*
rv770_restrict_performance_levels_before_switch failed

Xorg log dumps EDID information multiple times.

[555001.004] (II) RADEON(0): EDID vendor "SAM", prod id 2184
[555001.004] (II) RADEON(0): Using hsync ranges from config file
[555001.004] (II) RADEON(0): Using vrefresh ranges from config file
[555001.004] (II) RADEON(0): Printing DDC gathered Modelines:
[555001.004] (II) RADEON(0): Modeline "2560x1440"x0.0  241.50  2560 2608 2640
2720  1440 1443 1448 1481 +hsync -vsync (88.8 kHz eP)
[555001.004] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056 
600 601 605 628 +hsync +vsync (37.9 kHz e)
[555001.004] (II) RADEON(0): Modeline "800x600"x0.0   36.00  800 824 896 1024 
600 601 603 625 +hsync +vsync (35.2 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840 
480 481 484 500 -hsync -vsync (37.5 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 664 704 832 
480 489 492 520 -hsync -vsync (37.9 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   30.24  640 704 768 864 
480 483 486 525 -hsync -vsync (35.0 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800 
480 490 492 525 -hsync -vsync (31.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900 
400 412 414 449 -hsync +vsync (31.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440
1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[555001.005] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136
1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[555001.005] (II) RADEON(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184
1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184
1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[555001.005] (II) RADEON(0): Modeline "832x624"x0.0   57.28  832 864 928 1152 
624 625 628 667 -hsync -vsync (49.7 kHz e)
[555001.005] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056 
600 601 604 625 +hsync +vsync (46.9 kHz e)
[555001.005] (II) RADEON(0): Modeline "800x600"x0.0   50.00  800 856 976 1040 
600 637 643 666 +hsync +vsync (48.1 kHz e)
[555001.005] (II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344
1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x800"x0.0   83.50  1280 1352 1480
1680  800 803 809 831 -hsync +vsync (49.7 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488
1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)


[This entire block is repeated more than 100 times]

-- 
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/20141117/72508547/attachment.html>


[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86413

Bug ID: 86413
   Summary: Euro Truck Simulator 2: Severe stuttering with Kernel
>=3.17
   Product: Mesa
   Version: 10.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: dragon.arises at gmail.com

Created attachment 109641
  --> https://bugs.freedesktop.org/attachment.cgi?id=109641&action=edit
Screenshot of HUD on a bad configuration

When running Euro Truck Simulator 2 with the combination of Mesa 10.3 and Linux
3.17 or newer, the game shows severe stuttering whenever a new object enters
the field of view (gets loaded to GPU RAM?) or the camera is rotated. The game
stops for a short period of time, up to several seconds, just to return to a
normal framerate afterwards. This stuttering is not present when combining
either Mesa 10.2 with Linux 3.17, or Mesa 10.3 with Linux 3.16. With Mesa 10.4
from git the stuttering is present on recent Linux versions, but much less
severe than with Mesa 10.3.

This issue might be related to bug:
https://bugs.freedesktop.org/show_bug.cgi?id=84570

Hardware: 
GPU: Radeon R9 270X (vendor overclocked)
Mainboard: Asus M5A88V-EVO (PCIe 2)

Software: 
xorg-server 3.16.99.901
xf86-video-ati-7.5.0
Mesa 10.3.3 or Mesa 10.2.9
Kernel 3.16.5, 3.17.2, 3.18-rc5
radeon-ucode-20140823

-- 
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/20141117/54ac53a3/attachment.html>


[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86413

--- Comment #1 from Andreas Grois  ---
Created attachment 109642
  --> https://bugs.freedesktop.org/attachment.cgi?id=109642&action=edit
Screenshot of HUD on a good configuration (Mesa 10.3 + Linux 3.16)

-- 
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/20141117/c17da450/attachment.html>


[RFC] drm/msm/mdp5: use irqdomains

2014-11-17 Thread Rob Clark
For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
mdp block.  In order to decouple hdmi/eDP/etc, register an irq domain
in mdp5.  When hdmi/dsi/etc are used with mdp4, they can directly setup
their irqs in their DT nodes as normal.  When used with mdp5, instead
set the mdp device as the interrupt-parent, as in:

mdp: qcom,mdss_mdp at fd90 {
compatible = "qcom,mdss_mdp";
interrupt-controller;
#interrupt-cells = <1>;
...
};

hdmi: qcom,hdmi_tx at fd922100 {
compatible = "qcom,hdmi-tx-8074";
interrupt-parent = <&mdp>;
interrupts = <8 0>;   /* MDP5_HW_INTR_STATUS.INTR_HDMI */
...
};

There is a slight awkwardness, in that we cannot disable child irqs
at the mdp level, they can only be cleared in the child block.  So
you must not use threaded irq handlers in the child.  I'm not sure
if there is a better way to deal with that.

Signed-off-by: Rob Clark 
---
Courtney pointed out on IRC that irq_set_chained_handler() could help
with the child-using-threaded-handler issue..  although I'm not quite
sure how yet.  (Or whether it is even worth solving.)

 drivers/gpu/drm/msm/hdmi/hdmi.c | 33 ++--
 drivers/gpu/drm/msm/hdmi/hdmi.h |  3 --
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 94 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 10 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  7 +++
 drivers/gpu/drm/msm/msm_drv.h   |  1 -
 6 files changed, 122 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 9007761..db8c3b4 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -15,6 +15,7 @@
  * this program.  If not, see .
  */

+#include 
 #include "hdmi.h"

 void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
@@ -39,7 +40,7 @@ void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
power_on ? "Enable" : "Disable", ctrl);
 }

-irqreturn_t hdmi_irq(int irq, void *dev_id)
+static irqreturn_t hdmi_irq(int irq, void *dev_id)
 {
struct hdmi *hdmi = dev_id;

@@ -200,7 +201,6 @@ int hdmi_modeset_init(struct hdmi *hdmi,
 {
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = hdmi->pdev;
-   struct hdmi_platform_config *config = pdev->dev.platform_data;
int ret;

hdmi->dev = dev;
@@ -224,22 +224,20 @@ int hdmi_modeset_init(struct hdmi *hdmi,
goto fail;
}

-   if (!config->shared_irq) {
-   hdmi->irq = platform_get_irq(pdev, 0);
-   if (hdmi->irq < 0) {
-   ret = hdmi->irq;
-   dev_err(dev->dev, "failed to get irq: %d\n", ret);
-   goto fail;
-   }
+   hdmi->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+   if (hdmi->irq < 0) {
+   ret = hdmi->irq;
+   dev_err(dev->dev, "failed to get irq: %d\n", ret);
+   goto fail;
+   }

-   ret = devm_request_threaded_irq(&pdev->dev, hdmi->irq,
-   NULL, hdmi_irq, IRQF_TRIGGER_HIGH | 
IRQF_ONESHOT,
-   "hdmi_isr", hdmi);
-   if (ret < 0) {
-   dev_err(dev->dev, "failed to request IRQ%u: %d\n",
-   hdmi->irq, ret);
-   goto fail;
-   }
+   ret = devm_request_irq(&pdev->dev, hdmi->irq,
+   hdmi_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+   "hdmi_isr", hdmi);
+   if (ret < 0) {
+   dev_err(dev->dev, "failed to request IRQ%u: %d\n",
+   hdmi->irq, ret);
+   goto fail;
}

encoder->bridge = hdmi->bridge;
@@ -318,7 +316,6 @@ static int hdmi_bind(struct device *dev, struct device 
*master, void *data)
config.hpd_clk_cnt   = ARRAY_SIZE(hpd_clk_names);
config.pwr_clk_names = pwr_clk_names;
config.pwr_clk_cnt   = ARRAY_SIZE(pwr_clk_names);
-   config.shared_irq= true;
} else if (of_device_is_compatible(of_node, "qcom,hdmi-tx-8960")) {
static const char *hpd_clk_names[] = {"core_clk", 
"master_iface_clk", "slave_iface_clk"};
static const char *hpd_reg_names[] = {"core-vdda", "hdmi-mux"};
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index b981995..0a6f538 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -97,9 +97,6 @@ struct hdmi_platform_config {
/* gpio's: */
int ddc_clk_gpio, ddc_data_gpio, hpd_gpio, mux_en_gpio, mux_sel_gpio;
int mux_lpm_gpio;
-
-   /* older devices had their own irq, mdp5+ it is shared

[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86413

Andreas Grois  changed:

   What|Removed |Added

 Attachment #109641|0   |1
is obsolete||

--- Comment #2 from Andreas Grois  ---
Created attachment 109643
  --> https://bugs.freedesktop.org/attachment.cgi?id=109643&action=edit
Screenshot of HUD on a bad configuration (Mesa 10.3.2 + Linux 3.17.2)

Resubmit due to wrong file type of previous upload

-- 
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/20141117/24a086ea/attachment.html>


[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86413

--- Comment #3 from Andreas Grois  ---
Created attachment 109644
  --> https://bugs.freedesktop.org/attachment.cgi?id=109644&action=edit
journalctl output while running ets2 on a bad configuration

Not that I think that this contains something useful, but attached is the
journalctl output that was recorded while the game was running on a bad
configuration.

-- 
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/20141117/5f381115/attachment.html>


[Bug 86413] Euro Truck Simulator 2: Severe stuttering with Kernel >=3.17

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86413

--- Comment #4 from Andreas Grois  ---
Created attachment 109645
  --> https://bugs.freedesktop.org/attachment.cgi?id=109645&action=edit
dmesg of the bad configuration

Again, probably not very helpful, but here's the dmesg output of a bad
configuration.

-- 
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/20141117/0fbc63d4/attachment.html>


[PATCH] drm/msm/mdp5: get the core clock rate from MDP5 config

2014-11-17 Thread Rob Clark
On Mon, Nov 17, 2014 at 1:39 PM, Stephane Viau  wrote:
> The core clock rate depends on the hw configuration. Once we have
> read the hardware revision, we can set the core clock to its
> maximum value.
> Before then, the clock is set at a rate supported by all MDP5
> revisions.
>
> Signed-off-by: Stephane Viau 

Thanks, I have this queued up

BR,
-R

> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 9 +
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 3 ++-
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index 1bb3a28..f2c15bd 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -62,6 +62,7 @@ static const struct mdp5_config msm8x74_config = {
> .count = 4,
> .base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
> },
> +   .max_clk = 2,
>  };
>
>  static const struct mdp5_config apq8084_config = {
> @@ -99,6 +100,7 @@ static const struct mdp5_config apq8084_config = {
> .count = 5,
> .base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
> },
> +   .max_clk = 32000,
>  };
>
>  struct mdp5_config_entry {
> @@ -420,12 +422,13 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
> if (ret)
> goto fail;
>
> -   ret = clk_set_rate(mdp5_kms->src_clk, config->max_clk);
> -
> ret = mdp5_select_hw_cfg(kms);
> if (ret)
> goto fail;
>
> +   /* TODO: compute core clock rate at runtime */
> +   clk_set_rate(mdp5_kms->src_clk, mdp5_kms->hw_cfg->max_clk);
> +
> /* make sure things are off before attaching iommu (bootloader could
>  * have left things on, in which case we'll start getting faults if
>  * we don't disable):
> @@ -486,8 +489,6 @@ static struct mdp5_platform_config 
> *mdp5_get_config(struct platform_device *dev)
> /* TODO */
>  #endif
> config.iommu = iommu_domain_alloc(&platform_bus_type);
> -   /* TODO hard-coded in downstream mdss, but should it be? */
> -   config.max_clk = 2;
> /* TODO get from DT: */
> config.smp_blk_cnt = 22;
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> index c91101d..bdbdcda 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> @@ -37,6 +37,8 @@ struct mdp5_config {
> struct mdp5_sub_block dspp;
> struct mdp5_sub_block ad;
> struct mdp5_sub_block intf;
> +
> +   uint32_t max_clk;
>  };
>  extern const struct mdp5_config *mdp5_cfg;
>  #include "mdp5.xml.h"
> @@ -78,7 +80,6 @@ struct mdp5_kms {
>  /* platform config data (ie. from DT, or pdata) */
>  struct mdp5_platform_config {
> struct iommu_domain *iommu;
> -   uint32_t max_clk;
> int smp_blk_cnt;
>  };
>
> --
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>


[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=73528

--- Comment #20 from MirceaKitsune  ---
It is done. After nearly two hours of bisecting, I managed to track the exact
commit which adds the freezes... at least in the case of Second Life.

edbbfac6cfc634e697d7f981155a5072c52d77ac is the first bad commit
commit edbbfac6cfc634e697d7f981155a5072c52d77ac
Author: Grigori Goronzy 
Date:   Wed Sep 11 01:41:40 2013 +0200

r600g: fast color clears for single-sample buffers

Allocate a CMASK on demand and use it to fast clear single-sample
colorbuffers. Both FBOs and window system colorbuffers are fast
cleared. Expand as needed when colorbuffers are mapped or displayed
on screen.

v2: cosmetics, move transfer expansion into dma_blit

Signed-off-by: Marek Olšák 

:04 04 dbb6df4e7ed243043e46afc9b91c389b61549ef9
62ae46bd2049b7cb6e35e2dce2ba4725b413bdbe M  src

56d9a397aa2dbee6b12e1bbe56be39f426e1e34d is the last good commit

These are the changes in the bad commit: http://pastebin.com/raw.php?i=Z1RAGRcT

-- 
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/20141117/9a5c27ec/attachment.html>


[Bug 86418] Second Life crashes after login

2014-11-17 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=86418

Bug ID: 86418
   Summary: Second Life crashes after login
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: sonichedgehog_hyperblast00 at yahoo.com

I tried launching the Second Life viewer (Kokua 3.7.8 x64) using the latest GIT
version of MESA, and noticed the viewer crashes as soon as it's time to render
the world. The crash only happens when Basic Shaders are enabled. The only
relevant message printed in the console appears to be:

/home/mircea/Games/SecondLife/Kokua/kokua: line 151: 14351 Segmentation fault  
   LD_LIBRARY_PATH="`pwd`"/lib64:"`pwd`"/lib32:"${LD_LIBRARY_PATH}" $LL_WRAPPER
bin/do-not-directly-run-kokua-bin
*** Bad shutdown. ***

A GIT bisect leads to the following commit being at fault:

73dd50acf6d244979c2a657906aa56d3ac60d550 is the first bad commit
commit 73dd50acf6d244979c2a657906aa56d3ac60d550
Author: Tapani Pälli 
Date:   Wed Aug 6 09:46:54 2014 +0300

glsl: implement switch flow control using a loop

Patch removes old variable based logic for handling a break inside
switch. Switch is put inside a loop so that existing infrastructure
for loop flow control can be used for the switch, now also dead code
elimination works properly.

Possible 'continue' call inside a switch needs now special handling
which is taken care of by detecting continue, breaking out and calling
continue for the outside loop.

v2: remove one unnecessary ir_expression (Curro)

Fixes following Piglit tests:

   fs-exec-after-break.shader_test
   fs-conditional-break.shader_test

No Piglit or es3conform regressions.

Signed-off-by: Tapani Pälli 
Reviewed-by: Francisco Jerez 

:04 04 eac8a47066723ff804317ef11bb006dd0bb80d0f
b73ed6cc78a66c54d684635f69a358fd54f65929 M  src

-- 
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/20141117/6d9c2594/attachment-0001.html>


[PATCH v2] allow 32bpp framebuffers for cirrus drm

2014-11-17 Thread Stéphane Marchesin
Dave, any objections to merging this?

Stéphane


On Wed, Oct 29, 2014 at 11:04 AM, Zach Reizner  wrote:
> This patch allows framebuffers for cirrus to be created with
> 32bpp pixel formats provided that they do not violate certain
> restrictions of the cirrus hardware.
>
> v2: Use pci resource length for vram size.
>
> Signed-off-by: Zach Reizner 
> ---
>  drivers/gpu/drm/cirrus/cirrus_drv.h   |  3 +++
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  5 -
>  drivers/gpu/drm/cirrus/cirrus_main.c  | 27 +++
>  3 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
> b/drivers/gpu/drm/cirrus/cirrus_drv.h
> index d44e69d..693a456 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.h
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
> @@ -210,6 +210,9 @@ int cirrus_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_gem_object *obj);
>
> +bool cirrus_check_framebuffer(struct cirrus_device *cdev, int width, int 
> height,
> + int bpp, int pitch);
> +
> /* cirrus_display.c */
>  int cirrus_modeset_init(struct cirrus_device *cdev);
>  void cirrus_modeset_fini(struct cirrus_device *cdev);
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index d231b1c..502a89e 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -139,6 +139,7 @@ static int cirrusfb_create_object(struct cirrus_fbdev 
> *afbdev,
>struct drm_gem_object **gobj_p)
>  {
> struct drm_device *dev = afbdev->helper.dev;
> +   struct cirrus_device *cdev = dev->dev_private;
> u32 bpp, depth;
> u32 size;
> struct drm_gem_object *gobj;
> @@ -146,8 +147,10 @@ static int cirrusfb_create_object(struct cirrus_fbdev 
> *afbdev,
> int ret = 0;
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
>
> -   if (bpp > 24)
> +   if (!cirrus_check_framebuffer(cdev, mode_cmd->width, mode_cmd->height,
> + bpp, mode_cmd->pitches[0]))
> return -EINVAL;
> +
> size = mode_cmd->pitches[0] * mode_cmd->height;
> ret = cirrus_gem_create(dev, size, true, &gobj);
> if (ret)
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 99c1983..d9590fc 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -49,14 +49,16 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
>struct drm_file *filp,
>struct drm_mode_fb_cmd2 *mode_cmd)
>  {
> +   struct cirrus_device *cdev = dev->dev_private;
> struct drm_gem_object *obj;
> struct cirrus_framebuffer *cirrus_fb;
> int ret;
> u32 bpp, depth;
>
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
> -   /* cirrus can't handle > 24bpp framebuffers at all */
> -   if (bpp > 24)
> +
> +   if (!cirrus_check_framebuffer(cdev, mode_cmd->width, mode_cmd->height,
> + bpp, mode_cmd->pitches[0]))
> return ERR_PTR(-EINVAL);
>
> obj = drm_gem_object_lookup(dev, filp, mode_cmd->handles[0]);
> @@ -96,8 +98,7 @@ static int cirrus_vram_init(struct cirrus_device *cdev)
>  {
> /* BAR 0 is VRAM */
> cdev->mc.vram_base = pci_resource_start(cdev->dev->pdev, 0);
> -   /* We have 4MB of VRAM */
> -   cdev->mc.vram_size = 4 * 1024 * 1024;
> +   cdev->mc.vram_size = pci_resource_len(cdev->dev->pdev, 0);
>
> if (!request_mem_region(cdev->mc.vram_base, cdev->mc.vram_size,
> "cirrusdrmfb_vram")) {
> @@ -307,3 +308,21 @@ out_unlock:
> return ret;
>
>  }
> +
> +bool cirrus_check_framebuffer(struct cirrus_device *cdev, int width, int 
> height,
> + int bpp, int pitch)
> +{
> +   const int max_pitch = 0x1FF << 3; /* (4096 - 1) & ~111b bytes */
> +   const int max_size = cdev->mc.vram_size;
> +
> +   if (bpp > 32)
> +   return false;
> +
> +   if (pitch > max_pitch)
> +   return false;
> +
> +   if (pitch * height > max_size)
> +   return false;
> +
> +   return true;
> +}
> --
> 2.1.0.rc2.206.gedb03e5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/cirrus: fix leaky driver load error handling

2014-11-17 Thread Zach Reizner
Before this patch, cirrus_device_init could have failed while
cirrus_mm_init succeeded and the driver would have reported overall
success on load. This patch causes cirrus_device_init to return on
the first error encountered.

Reviewed-by: Stéphane Marchesin 
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 99c1983..ab7cb54 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -179,17 +179,22 @@ int cirrus_driver_load(struct drm_device *dev, unsigned 
long flags)
}

r = cirrus_mm_init(cdev);
-   if (r)
+   if (r) {
dev_err(&dev->pdev->dev, "fatal err on mm init\n");
+   goto out;
+   }

r = cirrus_modeset_init(cdev);
-   if (r)
+   if (r) {
dev_err(&dev->pdev->dev, "Fatal error during modeset init: 
%d\n", r);
+   goto out;
+   }

dev->mode_config.funcs = (void *)&cirrus_mode_funcs;
+
+   return 0;
 out:
-   if (r)
-   cirrus_driver_unload(dev);
+   cirrus_driver_unload(dev);
return r;
 }

-- 
2.1.0.rc2.206.gedb03e5



[PATCH 1/5] drm: Refactor mode stereo doubling into its own function

2014-11-17 Thread Matt Roper
There are places where we want to perform vertical doubling for stereo
modes without the other adjustments (doublescan, vscan > 1, etc.) that
drm_mode_set_crtcinfo() performs.  Refactor this logic into its own
function so that it can be called directly in such places.

Cc: dri-devel at lists.freedesktop.org
Suggested-by: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_modes.c | 39 ++-
 include/drm/drm_modes.h |  1 +
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6d8b941..8c25de3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -728,6 +728,30 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode)
 EXPORT_SYMBOL(drm_mode_vrefresh);

 /**
+ * drm_mode_stereo_double - Adjust mode timings for stereo modes
+ * @p: mode to adjust vertical timings of
+ *
+ * Performs stereo doubling of mode parameters when required by the stereo
+ * layout.  This may be used directly in places where the additional
+ * adjustments of drm_mode_set_crtcinfo() are undesired.
+ */
+void drm_mode_stereo_double(struct drm_display_mode *p)
+{
+   unsigned int layout = p->flags & DRM_MODE_FLAG_3D_MASK;
+
+   switch (layout) {
+   case DRM_MODE_FLAG_3D_FRAME_PACKING:
+   p->crtc_clock *= 2;
+   p->crtc_vdisplay += p->crtc_vtotal;
+   p->crtc_vsync_start += p->crtc_vtotal;
+   p->crtc_vsync_end += p->crtc_vtotal;
+   p->crtc_vtotal += p->crtc_vtotal;
+   break;
+   }
+}
+EXPORT_SYMBOL(drm_mode_stereo_double);
+
+/**
  * drm_mode_set_crtcinfo - set CRTC modesetting timing parameters
  * @p: mode
  * @adjust_flags: a combination of adjustment flags
@@ -779,19 +803,8 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int 
adjust_flags)
p->crtc_vtotal *= p->vscan;
}

-   if (adjust_flags & CRTC_STEREO_DOUBLE) {
-   unsigned int layout = p->flags & DRM_MODE_FLAG_3D_MASK;
-
-   switch (layout) {
-   case DRM_MODE_FLAG_3D_FRAME_PACKING:
-   p->crtc_clock *= 2;
-   p->crtc_vdisplay += p->crtc_vtotal;
-   p->crtc_vsync_start += p->crtc_vtotal;
-   p->crtc_vsync_end += p->crtc_vtotal;
-   p->crtc_vtotal += p->crtc_vtotal;
-   break;
-   }
-   }
+   if (adjust_flags & CRTC_STEREO_DOUBLE)
+   drm_mode_stereo_double(p);

p->crtc_vblank_start = min(p->crtc_vsync_start, p->crtc_vdisplay);
p->crtc_vblank_end = max(p->crtc_vsync_end, p->crtc_vtotal);
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 91d0582..2b3d05e 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -205,6 +205,7 @@ void drm_mode_set_name(struct drm_display_mode *mode);
 int drm_mode_hsync(const struct drm_display_mode *mode);
 int drm_mode_vrefresh(const struct drm_display_mode *mode);

+void drm_mode_stereo_double(struct drm_display_mode *p);
 void drm_mode_set_crtcinfo(struct drm_display_mode *p,
   int adjust_flags);
 void drm_mode_copy(struct drm_display_mode *dst,
-- 
1.8.5.1



[PATCH 2/5] drm: add helper to get crtc timings (v2)

2014-11-17 Thread Matt Roper
From: Gustavo Padovan 

We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.

v2 (by Matt): Use new stereo doubling function (suggested by Ville)

Cc: dri-devel at lists.freedesktop.org
Suggested-by: Ville Syrjälä 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c   | 22 --
 drivers/gpu/drm/i915/intel_display.c |  6 +++---
 include/drm/drm_crtc.h   |  2 ++
 3 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e7..64ec23b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2493,6 +2493,17 @@ int drm_mode_set_config_internal(struct drm_mode_set 
*set)
 }
 EXPORT_SYMBOL(drm_mode_set_config_internal);

+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+   int *hdisplay, int *vdisplay)
+{
+   struct drm_display_mode adjusted = *mode;
+
+   drm_mode_stereo_double(&adjusted);
+   *hdisplay = adjusted.crtc_hdisplay;
+   *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
 /**
  * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
  * CRTC viewport
@@ -2510,16 +2521,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
 {
int hdisplay, vdisplay;

-   hdisplay = mode->hdisplay;
-   vdisplay = mode->vdisplay;
-
-   if (drm_mode_is_stereo(mode)) {
-   struct drm_display_mode adjusted = *mode;
-
-   drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
-   hdisplay = adjusted.crtc_hdisplay;
-   vdisplay = adjusted.crtc_vdisplay;
-   }
+   drm_crtc_get_hv_timing(mode, &hdisplay, &vdisplay);

if (crtc->invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 320bf4c..a967623 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
 * computation to clearly distinguish it from the adjusted mode, which
 * can be changed by the connectors in the below retry loop.
 */
-   drm_mode_set_crtcinfo(&pipe_config->requested_mode, CRTC_STEREO_DOUBLE);
-   pipe_config->pipe_src_w = pipe_config->requested_mode.crtc_hdisplay;
-   pipe_config->pipe_src_h = pipe_config->requested_mode.crtc_vdisplay;
+   drm_crtc_get_hv_timing(&pipe_config->requested_mode,
+  &pipe_config->pipe_src_w,
+  &pipe_config->pipe_src_h);

 encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7b28ab0..23236f6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
 extern void drm_plane_cleanup(struct drm_plane *plane);
 extern unsigned int drm_plane_index(struct drm_plane *plane);
 extern void drm_plane_force_disable(struct drm_plane *plane);
+extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+  int *hdisplay, int *vdisplay);
 extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
   int x, int y,
   const struct drm_display_mode *mode,
-- 
1.8.5.1



[PATCH v11 02/12] staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter

2014-11-17 Thread Andy Yan

On 2014年11月15日 13:41, Daniel Kurtz wrote:
> On Fri, Nov 14, 2014 at 9:39 PM, Andy Yan  wrote:
>> drm driver may probe before the i2c bus, so the driver should
>> defer probing until it is available
>>
>> Signed-off-by: Andy Yan 
>>
>> ---
>>
>> Changes in v11: None
>> Changes in v10: None
>> Changes in v9: None
>> Changes in v8: None
>> Changes in v7: None
>> Changes in v6: None
>> Changes in v5: None
>> Changes in v4:
>> - defer probe ddc i2c adapter
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>   drivers/staging/imx-drm/imx-hdmi.c | 5 -
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
>> b/drivers/staging/imx-drm/imx-hdmi.c
>> index 79daec4..c2b035a 100644
>> --- a/drivers/staging/imx-drm/imx-hdmi.c
>> +++ b/drivers/staging/imx-drm/imx-hdmi.c
>> @@ -1611,8 +1611,11 @@ static int imx_hdmi_bind(struct device *dev, struct 
>> device *master, void *data)
>>  ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
>>  if (ddc_node) {
>>  hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
>> -   if (!hdmi->ddc)
>> +   if (!hdmi->ddc) {
>>  dev_dbg(hdmi->dev, "failed to read ddc node\n");
>> +   of_node_put(ddc_node);
>> +   return -EPROBE_DEFER;
>> +   }
> Nit:  You could move "of_node_put()" above "if (!hdmi->ddc)", and not
> need it in two places.
  thanks, I will take your advice
>
> Either way, this one is:
> Reviewed-by: Daniel Kurtz 
>
>>  of_node_put(ddc_node);
>>  } else {
>> --
>> 1.9.1
>>
>
>




[PATCH v12 02/11] staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter

2014-11-17 Thread Andy Yan
drm driver may probe before the i2c bus, so the driver should
defer probing until it is available

Signed-off-by: Andy Yan 
Reviewed-by: Daniel Kurtz 

---

Changes in v12:
- refactor of_node_put(ddc_node)

Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- defer probe ddc i2c adapter

Changes in v3: None
Changes in v2: None

 drivers/staging/imx-drm/imx-hdmi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/staging/imx-drm/imx-hdmi.c
index 79daec4..8029a07 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -1611,10 +1611,12 @@ static int imx_hdmi_bind(struct device *dev, struct 
device *master, void *data)
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
-   if (!hdmi->ddc)
+   of_node_put(ddc_node);
+   if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
+   return -EPROBE_DEFER;
+   }

-   of_node_put(ddc_node);
} else {
dev_dbg(hdmi->dev, "no ddc property found\n");
}
-- 
1.9.1




[RFC] add a struct page* parameter to dma_map_ops.unmap_page

2014-11-17 Thread Stefano Stabellini
Hi all,
I am writing this email to ask for your advice.

On architectures where dma addresses are different from physical
addresses, it can be difficult to retrieve the physical address of a
page from its dma address.

Specifically this is the case for Xen on arm and arm64 but I think that
other architectures might have the same issue.

Knowing the physical address is necessary to be able to issue any
required cache maintenance operations when unmap_page,
sync_single_for_cpu and sync_single_for_device are called.

Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
sync_single_for_device would make Linux dma handling on Xen on arm and
arm64 much easier and quicker.

I think that other drivers have similar problems, such as the Intel
IOMMU driver having to call find_iova and walking down an rbtree to get
the physical address in its implementation of unmap_page.

Callers have the struct page* in their hands already from the previous
map_page call so it shouldn't be an issue for them.  A problem does
exist however: there are about 280 callers of dma_unmap_page and
pci_unmap_page. We have even more callers of the dma_sync_single_for_*
functions.



Is such a change even conceivable? How would one go about it?

I think that Xen would not be the only one to gain from it, but I would
like to have a confirmation from others: given the magnitude of the
changes involved I would actually prefer to avoid them unless multiple
drivers/archs/subsystems could really benefit from them.

Cheers,

Stefano


diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..158a765 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -31,8 +31,9 @@ struct dma_map_ops {
   unsigned long offset, size_t size,
   enum dma_data_direction dir,
   struct dma_attrs *attrs);
-   void (*unmap_page)(struct device *dev, dma_addr_t dma_handle,
-  size_t size, enum dma_data_direction dir,
+   void (*unmap_page)(struct device *dev, struct page *page,
+  dma_addr_t dma_handle, size_t size,
+  enum dma_data_direction dir,
   struct dma_attrs *attrs);
int (*map_sg)(struct device *dev, struct scatterlist *sg,
  int nents, enum dma_data_direction dir,
@@ -41,10 +42,10 @@ struct dma_map_ops {
 struct scatterlist *sg, int nents,
 enum dma_data_direction dir,
 struct dma_attrs *attrs);
-   void (*sync_single_for_cpu)(struct device *dev,
+   void (*sync_single_for_cpu)(struct device *dev, struct page *page,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction dir);
-   void (*sync_single_for_device)(struct device *dev,
+   void (*sync_single_for_device)(struct device *dev, struct page *page,
   dma_addr_t dma_handle, size_t size,
   enum dma_data_direction dir);
void (*sync_sg_for_cpu)(struct device *dev,


[PATCH] drivers: Change calls to mdelay to msleep in order to stop CPU busy looping in mdfld_dsi_pkg_sender.c

2014-11-17 Thread Nick Krause
On Mon, Nov 17, 2014 at 3:40 AM, Jani Nikula
 wrote:
> On Sat, 15 Nov 2014, Nicholas Krause  wrote:
>> Changes the calls of mdelay to msleep in the driver file 
>> mdfld_dsi_pkg_sender.c
>> in order to prevent CPU busy looping in order to save CPU cycles as this is
>> considered bad form over sleeping the CPU for high resolution timer function
>> calls as this driver needs in order to function properly.
>
> The code paths are called with sender->lock spinlock held.
>
> BR,
> Jani.
>
>>
>> Signed-off-by: Nicholas Krause 
>> ---
>>  drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 15 +--
>>  1 file changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c 
>> b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
>> index 87885d8..77c656a 100644
>> --- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
>> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
>> @@ -335,13 +335,11 @@ static int send_pkg_prepare(struct 
>> mdfld_dsi_pkg_sender *sender, u8 data_type,
>>
>>   /*wait for 120 milliseconds in case exit_sleep_mode just be sent*/
>>   if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>>   }
>>
>>   if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>>   }
>>   return 0;
>>  }
>> @@ -364,15 +362,12 @@ static int send_pkg_done(struct mdfld_dsi_pkg_sender 
>> *sender, u8 data_type,
>>   /*update panel status*/
>>   if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
>>   sender->panel_mode |= MDFLD_DSI_PANEL_MODE_SLEEP;
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>>   } else if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
>>   sender->panel_mode &= ~MDFLD_DSI_PANEL_MODE_SLEEP;
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>>   } else if (unlikely(cmd == DCS_SOFT_RESET)) {
>> - /*TODO: replace it with msleep later*/
>> - mdelay(5);
>> + msleep(5);
>>   }
>>
>>   sender->status = MDFLD_DSI_PKG_SENDER_FREE;
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Technology Center
Then surely we can remove this to dos or do we have to move all the
code to another coding scheme for this driver using mutuxes as they
don't loop.


[PATCH v12 01/11] staging: imx-drm: imx-hdmi: make checkpatch happy

2014-11-17 Thread Andy Yan
CHECK: Alignment should match open parenthesis
+   if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+   (hdmi->vic == 12) || (hdmi->vic == 13) ||

CHECK: braces {} should be used on all arms of this statement
+   if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+   else {
[...]

Signed-off-by: Andy Yan 
Reviewed-by: Daniel Kurtz 

---

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- rearrange the patch order

Changes in v5: None
Changes in v4:
- fix checkpatch CHECK

Changes in v3: None
Changes in v2: None

 drivers/staging/imx-drm/imx-hdmi.c | 97 +++---
 1 file changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/staging/imx-drm/imx-hdmi.c
index aaec6b2..79daec4 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -163,7 +163,7 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 
mask, unsigned reg)
 }

 static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
- u8 shift, u8 mask)
+u8 shift, u8 mask)
 {
hdmi_modb(hdmi, data << shift, mask, reg);
 }
@@ -327,7 +327,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
 }

 static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,
-   unsigned long pixel_clk)
+unsigned long pixel_clk)
 {
unsigned int clk_n, clk_cts;

@@ -338,7 +338,7 @@ static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,

if (!clk_cts) {
dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n",
-__func__, pixel_clk);
+   __func__, pixel_clk);
return;
}

@@ -477,13 +477,11 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi 
*hdmi)
u16 coeff_b = (*csc_coeff)[1][i];
u16 coeff_c = (*csc_coeff)[2][i];

-   hdmi_writeb(hdmi, coeff_a & 0xff,
-   HDMI_CSC_COEF_A1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_a & 0xff, HDMI_CSC_COEF_A1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_a >> 8, HDMI_CSC_COEF_A1_MSB + i * 2);
hdmi_writeb(hdmi, coeff_b & 0xff, HDMI_CSC_COEF_B1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_b >> 8, HDMI_CSC_COEF_B1_MSB + i * 2);
-   hdmi_writeb(hdmi, coeff_c & 0xff,
-   HDMI_CSC_COEF_C1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_c & 0xff, HDMI_CSC_COEF_C1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_c >> 8, HDMI_CSC_COEF_C1_MSB + i * 2);
}

@@ -535,21 +533,22 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
struct hdmi_data_info *hdmi_data = &hdmi->hdmi_data;
u8 val, vp_conf;

-   if (hdmi_data->enc_out_format == RGB
-   || hdmi_data->enc_out_format == YCBCR444) {
-   if (!hdmi_data->enc_color_depth)
+   if (hdmi_data->enc_out_format == RGB ||
+   hdmi_data->enc_out_format == YCBCR444) {
+   if (!hdmi_data->enc_color_depth) {
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   else if (hdmi_data->enc_color_depth == 8) {
+   } else if (hdmi_data->enc_color_depth == 8) {
color_depth = 4;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   } else if (hdmi_data->enc_color_depth == 10)
+   } else if (hdmi_data->enc_color_depth == 10) {
color_depth = 5;
-   else if (hdmi_data->enc_color_depth == 12)
+   } else if (hdmi_data->enc_color_depth == 12) {
color_depth = 6;
-   else if (hdmi_data->enc_color_depth == 16)
+   } else if (hdmi_data->enc_color_depth == 16) {
color_depth = 7;
-   else
+   } else {
return;
+   }
} else if (hdmi_data->enc_out_format == YCBCR422_8BITS) {
if (!hdmi_data->enc_color_depth ||
hdmi_data->enc_color_depth == 8)
@@ -561,8 +560,9 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
else
return;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_YCC422;
-   } else
+   } else {
return;
+   }

/* set the packetizer registers */
val = ((color_depth << HDMI_VP_PR_CD_COLOR_DEPTH_OFFSET) &
@@ -623,34 +623,34 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
 }

 static inline void hdmi_phy_test_clear(struct imx_hdmi *hdmi,
-   unsigned char bit)
+  unsigned char bit)
 {
hdmi_modb(hdmi, bit <<

[PATCH v12 03/11] staging: imx-drm: imx-hdmi: convert imx-hdmi to drm_bridge mode

2014-11-17 Thread Andy Yan
IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.

To reuse the imx hdmi driver, convert it to drm_bridge

Signed-off-by: Andy Yan 
Signed-off-by: Yakir Yang 

---

Changes in v12:
- squash patch 

Changes in v11:
- squash patch  

Changes in v10:
- split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)

Changes in v9: None
Changes in v8: None
Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/staging/imx-drm/imx-hdmi.c | 498 +++--
 1 file changed, 314 insertions(+), 184 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/staging/imx-drm/imx-hdmi.c
index 8029a07..c42da29 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -23,6 +23,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 
 #include 
@@ -111,16 +112,24 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

+struct imx_hdmi_plat_data {
+   const struct mpll_config *mpll_cfg;
+   const struct curr_ctrl *cur_ctr;
+   const struct sym_term *sym_term;
+   enum imx_hdmi_devtype dev_type;
+};
+
 struct imx_hdmi {
struct drm_connector connector;
-   struct drm_encoder encoder;
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;

enum imx_hdmi_devtype dev_type;
struct device *dev;
-   struct clk *isfr_clk;
-   struct clk *iahb_clk;

struct hdmi_data_info hdmi_data;
+   const struct imx_hdmi_plat_data *plat_data;
+   void *priv;
int vic;

u8 edid[HDMI_EDID_LEN];
@@ -137,12 +146,13 @@ struct imx_hdmi {
int ratio;
 };

-static void imx_hdmi_set_ipu_di_mux(struct imx_hdmi *hdmi, int ipu_di)
-{
-   regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
-  IMX6Q_GPR3_HDMI_MUX_CTL_MASK,
-  ipu_di << IMX6Q_GPR3_HDMI_MUX_CTL_SHIFT);
-}
+struct imx_hdmi_priv {
+   struct device *dev;
+   struct clk *isfr_clk;
+   struct clk *iahb_clk;
+   struct regmap *regmap;
+   struct drm_encoder encoder;
+};

 static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
 {
@@ -743,7 +753,7 @@ struct mpll_config {
} res[RES_MAX];
 };

-static const struct mpll_config mpll_config[] = {
+static const struct mpll_config imx_mpll_cfg[] = {
{
4525, {
{ 0x01e0, 0x },
@@ -776,7 +786,7 @@ struct curr_ctrl {
u16 curr[RES_MAX];
 };

-static const struct curr_ctrl curr_ctrl[] = {
+static const struct curr_ctrl imx_cur_ctr[] = {
/*  pixelclk bpp8bpp10   bpp12 */
{
 5400, { 0x091c, 0x091c, 0x06dc },
@@ -793,11 +803,26 @@ static const struct curr_ctrl curr_ctrl[] = {
}
 };

+struct sym_term {
+   unsigned long mpixelclock;
+   u16 sym_ctr;/*clock symbol and transmitter control*/
+   u16 term;   /*transmission termination value*/
+};
+
+static const struct sym_term imx_sym_term[] = {
+   /*pixelclk   symbol   term*/
+   { 14850, 0x800d, 0x0005 },
+   { ~0UL,  0x, 0x }
+};
+
 static int hdmi_phy_configure(struct imx_hdmi *hdmi, unsigned char prep,
  unsigned char res, int cscon)
 {
unsigned res_idx, i;
u8 val, msec;
+   const struct mpll_config *mpll_cfg = hdmi->plat_data->mpll_cfg;
+   const struct curr_ctrl   *curr_ctr = hdmi->plat_data->cur_ctr;
+   const struct sym_term *sym_term =  hdmi->plat_data->sym_term;

if (prep)
return -EINVAL;
@@ -843,34 +868,41 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi, 
unsigned char prep,
hdmi_phy_test_clear(hdmi, 0);

/* PLL/MPLL Cfg - always match on final entry */
-   for (i = 0; i < ARRAY_SIZE(mpll_config) - 1; i++)
+   for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   mpll_config[i].mpixelclock)
+   mpll_cfg[i].mpixelclock)
break;

-   hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].cpce, 0x06);
-   hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].gmp, 0x15);
+   hdmi_phy_i2c_write(hdmi, mpll_cfg[i].res[res_idx].cpce, 0x06);
+   hdmi_phy_i2c_write(hdmi, mpll_cfg[i].res[res_idx].gmp, 0x15);

-   for (i = 0; i < ARRAY_SIZE(curr_ctrl); i++)
+   for (i = 0; curr_ctr[i].mpixelclock != (~0UL); i++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   curr_ctrl[i].m

[PATCH v12 05/11] dt-bindings: add document for dw_hdmi

2014-11-17 Thread Andy Yan
Signed-off-by: Andy Yan 

---

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
new file mode 100644
index 000..107c1ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
@@ -0,0 +1,40 @@
+DesignWare HDMI bridge bindings
+
+Required properities:
+- compatible: platform specific such as:
+   * "fsl,imx6q-hdmi"
+   * "fsl,imx6dl-hdmi"
+   * "rockchip,rk3288-dw-hdmi"
+- reg: Physical base address and length of the controller's registers.
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- interrupts: The HDMI interrupt number
+
+Optional properties
+- reg-io-width: the width of the reg:1,4, default set to 1 if not present
+
+Example:
+   hdmi: hdmi at 012 {
+   compatible = "fsl,imx6q-hdmi";
+   reg = <0x0012 0x9000>;
+   interrupts = <0 115 0x04>;
+   gpr = <&gpr>;
+   clocks = <&clks 123>, <&clks 124>;
+   clock-names = "iahb", "isfr";
+   ddc-i2c-bus = <&i2c2>;
+
+   port at 0 {
+   reg = <0>;
+
+   hdmi_mux_0: endpoint {
+   remote-endpoint = <&ipu1_di0_hdmi>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   hdmi_mux_1: endpoint {
+   remote-endpoint = <&ipu1_di1_hdmi>;
+   };
+   };
+   };
-- 
1.9.1




[PATCH v12 09/11] drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare

2014-11-17 Thread Andy Yan
RK3288 HDMI will not work without the spare bit of
HDMI_PHY_CONF0 enable

Signed-off-by: Andy Yan 

---

Changes in v12: None
Changes in v11:
- split from patch 

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 7 +++
 drivers/gpu/drm/bridge/dw_hdmi.h | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 898488d..c63bdf9 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -715,6 +715,13 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi *hdmi, 
u8 enable)
 HDMI_PHY_CONF0_ENTMDS_MASK);
 }

+static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
+{
+   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
+HDMI_PHY_CONF0_SPARECTRL_OFFSET,
+HDMI_PHY_CONF0_SPARECTRL_MASK);
+}
+
 static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
 {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index 04d8ebe..9900f24 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -837,7 +837,8 @@ enum {
HDMI_PHY_CONF0_PDZ_OFFSET = 7,
HDMI_PHY_CONF0_ENTMDS_MASK = 0x40,
HDMI_PHY_CONF0_ENTMDS_OFFSET = 6,
-   HDMI_PHY_CONF0_SPARECTRL = 0x20,
+   HDMI_PHY_CONF0_SPARECTRL_MASK = 0x20,
+   HDMI_PHY_CONF0_SPARECTRL_OFFSET = 5,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK = 0x10,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET = 4,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK = 0x8,
-- 
1.9.1




[PATCH v12 10/11] dt-bindings: Add documentation for rockchip dw hdmi

2014-11-17 Thread Andy Yan
Signed-off-by: Andy Yan 

---

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- Add documentation for rockchip dw hdmi

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt

diff --git a/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
new file mode 100644
index 000..0735464
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
@@ -0,0 +1,43 @@
+Rockchip specific extensions to the Synopsys Designware HDMI
+
+
+Required properties:
+- compatible: "rockchip,rk3288-dw-hdmi";
+- reg: Physical base address and length of the controller's registers.
+- ddc-i2c-bus:  phandle of an I2C controller used for DDC EDID probing
+- clocks: from common clock binding: handle to hdmi clock.
+- clock-names: should be "clk" "hdcp_clk"
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- interrupts: HDMI interrupt number
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. For
+  vopb,set the reg = <0> and set the reg = <1> for vopl.
+- reg-io-width: the width of the reg:1,4, the value should be 4 on
+  rk3288 platform
+
+Example:
+hdmi: hdmi at ff98 {
+   compatible = "rockchip,rk3288-dw-hdmi";
+   reg = <0xff98 0x2>;
+   reg-io-width = <4>;
+   ddc-i2c-bus = <&i2c5>;
+   rockchip,grf = <&grf>;
+   interrupts = ;
+   clocks = <&cru  PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
+   clock-names = "clk", "hdcp_clk";
+   status = "disabled";
+   ports {
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&vopb_out_hdmi>;
+   };
+   hdmi_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <&vopl_out_hdmi>;
+   };
+   };
+   };
+};
-- 
1.9.1




[PATCH v12 04/11] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

2014-11-17 Thread Andy Yan
the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi driver out
to drm/bridge and rename imx-hdmi to dw_hdmi

handle encoder in dw_hdmi-imx.c, as most of the encoder
operation are platform specific such as crtc select and
panel format set

Signed-off-by: Andy Yan 

---

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- use git format -M to generate these patch

 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 544 +
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|   4 +-
 drivers/staging/imx-drm/Kconfig|   1 +
 drivers/staging/imx-drm/Makefile   |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c  | 274 +++
 include/drm/bridge/dw_hdmi.h   |  57 +++
 8 files changed, 470 insertions(+), 418 deletions(-)
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (73%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (99%)
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c
 create mode 100644 include/drm/bridge/dw_hdmi.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..26162ef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,3 +3,8 @@ config DRM_PTN3460
depends on DRM
select DRM_KMS_HELPER
---help---
+
+config DRM_DW_HDMI
+   bool "Synopsys DesignWare High-Definition Multimedia Interface"
+   depends on DRM
+   select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d8a8cfd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm

 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
b/drivers/gpu/drm/bridge/dw_hdmi.c
similarity index 73%
rename from drivers/staging/imx-drm/imx-hdmi.c
rename to drivers/gpu/drm/bridge/dw_hdmi.c
index c42da29..f904bb4 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -6,21 +6,15 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
- * SH-Mobile High-Definition Multimedia Interface (HDMI) driver
- * for SLISHDMI13T and SLIPHDMIT IP cores
+ * Designware High-Definition Multimedia Interface (HDMI) driver
  *
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */
-
-#include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 

 #include 
@@ -28,10 +22,9 @@
 #include 
 #include 
 #include 
-#include 
+#include 

-#include "imx-hdmi.h"
-#include "imx-drm.h"
+#include "dw_hdmi.h"

 #define HDMI_EDID_LEN  512

@@ -55,11 +48,6 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
 };

-enum imx_hdmi_devtype {
-   IMX6Q_HDMI,
-   IMX6DL_HDMI,
-};
-
 static const u16 csc_coeff_default[3][4] = {
{ 0x2000, 0x, 0x, 0x },
{ 0x, 0x2000, 0x, 0x },
@@ -112,23 +100,16 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

-struct imx_hdmi_plat_data {
-   const struct mpll_config *mpll_cfg;
-   const struct curr_ctrl *cur_ctr;
-   const struct sym_term *sym_term;
-   enum imx_hdmi_devtype dev_type;
-};
-
-struct imx_hdmi {
+struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
struct drm_bridge *bridge;

-   enum imx_hdmi_devtype dev_type;
+   enum dw_hdmi_devtype dev_type;
struct device *dev;

struct hdmi_data_info hdmi_data;
-   const struct imx_hdmi_plat_data *plat_data;
+   const struct dw_hdmi_plat_data *plat_data;
void *priv;
int vic;

@@ -146,25 +127,17 @@ struct imx_hdmi {
int ratio;
 };

-struct imx_hdmi_priv {
-   struct device *dev;
-   struct clk *isfr_clk;
-   struct clk *iahb_clk;
-   struct regmap *regmap;
-   struct drm_encoder encoder;
-};
-
-static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
+static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
writeb(val, hdmi->regs + offset);
 }

-static inline u8 hdmi_readb(struct imx_hdmi *hdmi, int offset)
+static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
return readb(hdmi->regs + offset);
 }

-static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
+static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
 {
u8 val = hdmi_readb(hdmi, reg) & ~mask;

@@ -172,13 +145

[PATCH v12 06/11] drm: bridge/dw_hdmi: add support for multi-byte register width access

2014-11-17 Thread Andy Yan
On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers.  Byte width accesses (writeb,
readb) generate an imprecise external abort.

Signed-off-by: Andy Yan 

---

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- move some modification to  patch#6
- refactor register access without reg_shift

Changes in v5:
- refactor reg-io-width

Changes in v4: None
Changes in v3:
- split multi-register access to one indepent patch

Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 57 +++-
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index f904bb4..229aa7a 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -100,6 +100,11 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

+union dw_reg_ptr {
+   u32 __iomem *p32;
+   u8 __iomem *p8;
+};
+
 struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
@@ -121,20 +126,43 @@ struct dw_hdmi {

struct regmap *regmap;
struct i2c_adapter *ddc;
-   void __iomem *regs;
+   union dw_reg_ptr regs;

unsigned int sample_rate;
int ratio;
+
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
 };

+static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+   writel(val, hdmi->regs.p32 + offset);
+}
+
+static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
+{
+   return readl(hdmi->regs.p32 + offset);
+}
+
+static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+   writeb(val, hdmi->regs.p8 + offset);
+}
+
+static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
+{
+   return readb(hdmi->regs.p8 + offset);
+}
+
 static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
-   writeb(val, hdmi->regs + offset);
+   hdmi->write(hdmi, val, offset);
 }

 static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
-   return readb(hdmi->regs + offset);
+   return hdmi->read(hdmi, offset);
 }

 static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
@@ -1508,6 +1536,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
struct resource *iores;
struct dw_hdmi *hdmi;
int ret, irq;
+   u32 val = 1;

hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
@@ -1520,6 +1549,22 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
hdmi->ratio = 100;
hdmi->encoder = encoder;

+   of_property_read_u32(np, "reg-io-width", &val);
+
+   switch (val) {
+   case 4:
+   hdmi->write = dw_hdmi_writel;
+   hdmi->read = dw_hdmi_readl;
+   break;
+   case 1:
+   hdmi->write = dw_hdmi_writeb;
+   hdmi->read = dw_hdmi_readb;
+   break;
+   default:
+   dev_err(dev, "reg-io-width must be 1 or 4\n");
+   return -EINVAL;
+   }
+
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
@@ -1544,9 +1589,9 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
return ret;

iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   hdmi->regs = devm_ioremap_resource(dev, iores);
-   if (IS_ERR(hdmi->regs))
-   return PTR_ERR(hdmi->regs);
+   hdmi->regs.p32 = devm_ioremap_resource(dev, iores);
+   if (IS_ERR(hdmi->regs.p32))
+   return PTR_ERR(hdmi->regs.p32);

/* Product and revision IDs */
dev_info(dev,
-- 
1.9.1




[PATCH v12 07/11] drm: bridge/dw_hdmi: add mode_valid support

2014-11-17 Thread Andy Yan
some platform may not support all the display mode,
add mode_valid interface check it

also add drm_connector_register which add a debugfs
interface for dump display modes and edid information

Signed-off-by: Andy Yan 
---

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 17 +
 include/drm/bridge/dw_hdmi.h |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 229aa7a..7b32bb8 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1406,6 +1406,20 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return 0;
 }

+static enum drm_mode_status
+dw_hdmi_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = container_of(connector,
+  struct dw_hdmi, connector);
+   enum drm_mode_status mode_status = MODE_OK;
+
+   if (hdmi->plat_data->mode_valid)
+   mode_status = hdmi->plat_data->mode_valid(connector, mode);
+
+   return mode_status;
+}
+
 static struct drm_encoder *dw_hdmi_connector_best_encoder(struct drm_connector
   *connector)
 {
@@ -1430,6 +1444,7 @@ static struct drm_connector_funcs dw_hdmi_connector_funcs 
= {

 static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
.get_modes = dw_hdmi_connector_get_modes,
+   .mode_valid = dw_hdmi_connector_mode_valid,
.best_encoder = dw_hdmi_connector_best_encoder,
 };

@@ -1631,6 +1646,8 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,

dev_set_drvdata(dev, hdmi);

+   drm_connector_register(&hdmi->connector);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_bind);
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 1001470..ed358f0 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -44,6 +44,8 @@ struct sym_term {
 };

 struct dw_hdmi_plat_data {
+   enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
+ struct drm_display_mode *mode);
const struct mpll_config *mpll_cfg;
const struct curr_ctrl *cur_ctr;
const struct sym_term *sym_term;
-- 
1.9.1




[PATCH v12 08/11] drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done

2014-11-17 Thread Andy Yan
HDMI_IH_I2CMPHY_STAT0 is a clear on write register, which indicates i2cm
operation status(i2c transfer done or error), every hdmi phy register
configuration must check this register to make sure the configuration
has complete. But the indication bit should be cleared after check, otherwise
the corresponding bit will hold on forever, this may give a wrong signal for
next check.

Signed-off-by: Andy Yan 

---

Changes in v12: None
Changes in v11:
- split form patch 

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 7b32bb8..898488d 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -668,11 +668,15 @@ static inline void hdmi_phy_test_dout(struct dw_hdmi 
*hdmi,

 static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
 {
-   while ((hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
+   u32 val;
+
+   while ((val = hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
if (msec-- == 0)
return false;
udelay(1000);
}
+   hdmi_writeb(hdmi, val, HDMI_IH_I2CMPHY_STAT0);
+
return true;
 }

-- 
1.9.1




[Xen-devel] [RFC] add a struct page* parameter to dma_map_ops.unmap_page

2014-11-17 Thread David Vrabel
On 17/11/14 14:11, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
> 
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
> 
> Specifically this is the case for Xen on arm and arm64 but I think that
> other architectures might have the same issue.
> 
> Knowing the physical address is necessary to be able to issue any
> required cache maintenance operations when unmap_page,
> sync_single_for_cpu and sync_single_for_device are called.
> 
> Adding a struct page* parameter to unmap_page, sync_single_for_cpu and
> sync_single_for_device would make Linux dma handling on Xen on arm and
> arm64 much easier and quicker.

Using an opaque handle instead of struct page * would be more beneficial
for the Intel IOMMU driver.  e.g.,

typedef dma_addr_t dma_handle_t;

dma_handle_t dma_map_single(struct device *dev,
void *va, size_t size,
enum dma_data_direction dir);
void dma_unmap_single(struct device *dev,
  dma_handle_t handle, size_t size,
  enum dma_data_direction dir);

etc.

Drivers would then use:

dma_addr_t dma_addr(dma_handle_t handle);

To obtain the bus address from the handle.

> I think that other drivers have similar problems, such as the Intel
> IOMMU driver having to call find_iova and walking down an rbtree to get
> the physical address in its implementation of unmap_page.
> 
> Callers have the struct page* in their hands already from the previous
> map_page call so it shouldn't be an issue for them.  A problem does
> exist however: there are about 280 callers of dma_unmap_page and
> pci_unmap_page. We have even more callers of the dma_sync_single_for_*
> functions.

You will also need to fix dma_unmap_single() and pci_unmap_single()
(another 1000+ callers).

You may need to consider a parallel set of map/unmap API calls that
return/accept a handle, and then converting drivers one-by-one as
required, instead of trying to convert every single driver at once.

David


[PATCH] drm/tilcdc : fixing LCD clock divisor configuration

2014-11-17 Thread Bruno Ramey
Dear gentlemen,

My first contribution to the Linux kernel is for you !
(yes, really)

I apologize for all the mistake I can make in a one liner fix !

My hardware :
CPU : Beaglebone black, with ARM TI AM3358 processor
Display : Densitron ripdraw 7" 1024x600 HDMI

Software :
Kernel Linux 3.17
Buildroot 2014.08
Qt applications on framebuffer (no X)

Problem :
My display doesn't show anything.
In the EDID retrieved from my display, I have a pixel-clock at 43.980 MHz.

I enable debug in drm_drv.c :
unsigned int drm_debug = 1;

So in dmesg, I read :
[drm:tilcdc_crtc_update_clk] lcd_clk=8790, mode clock=43980, div=1
[drm:tilcdc_crtc_update_clk] fck=8790, dpll_disp_ck=8790

As you can see, div=1. Which is an error for tilcdc.
div = 8790 / 4398;
Which is, in real world about = 1,998..., but unfortunately round to 1 
in software world !

with my fix, I have :
[drm:tilcdc_crtc_update_clk] lcd_clk=8790, mode clock=43980, div=2
[drm:tilcdc_crtc_update_clk] fck=8790, dpll_disp_ck=8790
And my display works.

I try this with other display and see no regression.

Thanks for your attention,

Best regards,
Bruno

 From f6205b6506f96f99d67909931b59d3742c8e1272 Mon Sep 17 00:00:00 2001
From: Bruno RAMEY 
Date: Thu, 13 Nov 2014 12:58:36 +0100
Subject: [PATCH] drm/tilcdc : fixing LCD clock divisor configuration

Depending of the pixel clock of the connected display and the
rounding of the system clock, the LCDC_CLK_DIVISOR part of
the LCDC_CTRL_REG register could be misconfigured.
---
  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index d3e6858..0f715eb 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -555,7 +555,7 @@ void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
 }

 lcd_clk = clk_get_rate(priv->clk);
-   div = lcd_clk / (crtc->mode.clock * 1000);
+   div = DIV_ROUND_CLOSEST(lcd_clk, crtc->mode.clock * 1000);

 DBG("lcd_clk=%u, mode clock=%d, div=%u", lcd_clk, 
crtc->mode.clock, div);
 DBG("fck=%lu, dpll_disp_ck=%lu", clk_get_rate(priv->clk), 
clk_get_rate(priv->disp_clk));
-- 
1.9.3





[PATCH v12 0/11] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

2014-11-17 Thread Andy Yan

We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly differences, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only be accessed
by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0
support.

To reuse the imx-hdmi driver, we make this patch set:
(1): fix some CodingStyle warning to make checkpatch happy
(2): convert imx-hdmi to drm_bridge
(3): move imx-hdmi to bridge/dw_hdmi, and split platform specific code
(4): extend dw_hdmi.c to support rk3288 hdmi
(5): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c

Changes in v12:
- refactor of_node_put(ddc_node)
- squash patch  & 
- add comment for the depend on patch

Changes in v11:
- squash patch  
- split form patch 
- split from patch 

Changes in v10:
- split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)
- add more display mode support mpll configuration for rk3288

Changes in v9:
- move some phy configuration to platform driver

Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description
- Add documentation for rockchip dw hdmi

Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c

Changes in v6:
- rearrange the patch order
- move some modification to  patch#6
- refactor register access without reg_shift

Changes in v5:
- refactor reg-io-width

Changes in v4:
- fix checkpatch CHECK
- defer probe ddc i2c adapter

Changes in v3:
- split multi-register access to one indepent patch

Changes in v2:
- use git format -M to generate these patch

Andy Yan (11):
  staging: imx-drm: imx-hdmi: make checkpatch happy
  staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter
  staging: imx-drm: imx-hdmi: convert imx-hdmi to drm_bridge mode
  staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
  dt-bindings: add document for dw_hdmi
  drm: bridge/dw_hdmi: add support for multi-byte register width access
  drm: bridge/dw_hdmi: add mode_valid support
  drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done
  drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
  dt-bindings: Add documentation for rockchip dw hdmi
  drm: bridge/dw_hdmi: add rockchip rk3288 support

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt |  40 ++
 .../devicetree/bindings/video/dw_hdmi-rockchip.txt |  43 ++
 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c}| 767 +
 .../imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h}|   7 +-
 drivers/gpu/drm/rockchip/Kconfig   |  10 +
 drivers/gpu/drm/rockchip/Makefile  |   2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 355 ++
 drivers/staging/imx-drm/Kconfig|   1 +
 drivers/staging/imx-drm/Makefile   |   2 +-
 drivers/staging/imx-drm/dw_hdmi-imx.c  | 274 
 include/drm/bridge/dw_hdmi.h   |  60 ++
 13 files changed, 1139 insertions(+), 428 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
 rename drivers/{staging/imx-drm/imx-hdmi.c => gpu/drm/bridge/dw_hdmi.c} (70%)
 rename drivers/{staging/imx-drm/imx-hdmi.h => gpu/drm/bridge/dw_hdmi.h} (99%)
 create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
 create mode 100644 drivers/staging/imx-drm/dw_hdmi-imx.c
 create mode 100644 include/drm/bridge/dw_hdmi.h

-- 
1.9.1




[PATCH v12 11/11] drm: bridge/dw_hdmi: add rockchip rk3288 support

2014-11-17 Thread Andy Yan
Rockchip RK3288 hdmi is compatible with dw_hdmi

this patch is depend on patch by Mark Yao Add drm
driver for Rockchip Socs

see https://lkml.org/lkml/2014/10/8/201

Signed-off-by: Andy Yan 

---

Changes in v12:
- add comment for the depend on patch

Changes in v11: None
Changes in v10:
- add more display mode support mpll configuration for rk3288

Changes in v9:
- move some phy configuration to platform driver

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/dw_hdmi.c|   3 +
 drivers/gpu/drm/rockchip/Kconfig|  10 +
 drivers/gpu/drm/rockchip/Makefile   |   2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 355 
 include/drm/bridge/dw_hdmi.h|   1 +
 5 files changed, 370 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index c63bdf9..7df5f38 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -853,6 +853,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);

+   if (hdmi->dev_type == RK3288_HDMI)
+   dw_hdmi_phy_enable_spare(hdmi, 1);
+
/*Wait for PHY PLL lock */
msec = 5;
do {
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0ff6682..06371ae 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -15,3 +15,13 @@ config DRM_ROCKCHIP
  management to userspace. This driver does not provide
  2D or 3D acceleration; acceleration is performed by other
  IP found on the SoC.
+
+config ROCKCHIP_DW_HDMI
+bool "Rockchip specific extensions for Synopsys DW HDMI"
+depends on DRM_ROCKCHIP
+select DRM_DW_HDMI
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Synopsys DesignWare HDMI driver. If you want to
+ enable HDMI on RK3288 based SoC, you should selet this
+ option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index b3a5193..347e65c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -4,5 +4,5 @@

 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_drm_gem.o rockchip_drm_vop.o
-
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
new file mode 100644
index 000..16cad75
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -0,0 +1,355 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define GRF_SOC_CON60x025c
+#define HDMI_SEL_VOP_LIT(1 << 4)
+
+struct rockchip_hdmi {
+   struct device *dev;
+   struct clk *clk;
+   struct clk *hdcp_clk;
+   struct regmap *regmap;
+   struct drm_encoder encoder;
+};
+
+#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
+
+static const struct mpll_config rockchip_mpll_cfg[] = {
+   {
+   2700, {
+   { 0x00b3, 0x},
+   { 0x2153, 0x},
+   { 0x40f3, 0x}
+   },
+   }, {
+   3600, {
+   { 0x00b3, 0x},
+   { 0x2153, 0x},
+   { 0x40f3, 0x}
+   },
+   }, {
+   4000, {
+   { 0x00b3, 0x},
+   { 0x2153, 0x},
+   { 0x40f3, 0x}
+   },
+   }, {
+   5400, {
+   { 0x0072, 0x0001},
+   { 0x2142, 0x0001},
+   { 0x40a2, 0x0001},
+   },
+   }, {
+   6500, {
+   { 0x0072, 0x0001},
+   { 0x2142, 0x0001},
+   { 0x40a2, 0x0001},
+   },
+   }, {
+   6600, {
+   { 0x013e, 0x0003},
+   { 0x217e, 0x0002},
+   { 0x4061, 0x0002}
+