date:20150430

Hello Gustavo!


Gustavo Padovan wrote:
> Hi Tobias,
> 
> 2015-04-30 Tobias Jakobi :
> 
>> First step in allowing a more generic way to setup complex
>> blending for the different layers.
>>
>> Signed-off-by: Tobias Jakobi 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 74 
>> +--
>>  1 file changed, 63 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 4155f43..a06b8e2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -63,6 +63,12 @@ struct mixer_resources {
>>  struct clk  *mout_mixer;
>>  };
>>  
>> +struct layer_config {
>> +unsigned int index;
>> +unsigned int priority;
>> +u32 cfg;
>> +};
> 
> I don't see why you are creating this struct, index and priority are
> never used in this patch series.
Good catch about 'priority'. But 'index' is used, see the second patch.



> 
>> +
>>  enum mixer_version_id {
>>  MXR_VER_0_0_0_16,
>>  MXR_VER_16_0_33_0,
>> @@ -75,6 +81,8 @@ struct mixer_context {
>>  struct drm_device   *drm_dev;
>>  struct exynos_drm_crtc  *crtc;
>>  struct exynos_drm_plane planes[MIXER_WIN_NR];
>> +const struct layer_config *layer_config;
>> +unsigned int num_layer;
>>  int pipe;
>>  boolinterlace;
>>  boolpowered;
>> @@ -95,6 +103,40 @@ struct mixer_drv_data {
>>  boolhas_sclk;
>>  };
>>  
>> +/*
>> + * The default layer priorities. A higher priority means that
>> + * the layer is at the top of layer stack.
>> + * The current configuration assumes the following usage scenario:
>> + * layer1: OSD [top]
>> + * layer0: main framebuffer
>> + * video layer: video overlay [bottom]
>> + * Note that the video layer is only usable when the
>> + * video processor is available.
>> + */
>> +
>> +static const struct layer_config default_layer_config[] = {
>> +{
>> +.index = 0, .priority = 1, /* layer0 */
>> +.cfg = MXR_LAYER_CFG_GRP0_VAL(1)
>> +}, {
>> +.index = 1, .priority = 2, /* layer1 */
>> +.cfg = MXR_LAYER_CFG_GRP1_VAL(2)
>> +}
>> +};
>> +
>> +static const struct layer_config vp_layer_config[] = {
>> +{
>> +.index = 2, .priority = 1, /* video layer */
>> +.cfg = MXR_LAYER_CFG_VP_VAL(1)
>> +}, {
>> +.index = 0, .priority = 2, /* layer0 */
>> +.cfg = MXR_LAYER_CFG_GRP0_VAL(2)
>> +}, {
>> +.index = 1, .priority = 3, /* layer1 */
>> +.cfg = MXR_LAYER_CFG_GRP1_VAL(3)
>> +}
>> +};
>> +
>>  static const u8 filter_y_horiz_tap8[] = {
>>  0,  -1, -1, -1, -1, -1, -1, -1,
>>  -1, -1, -1, -1, -1, 0,  0,  0,
>> @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources 
>> *res)
>>  filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
>>  }
>>  
>> +static void mixer_layer_priority(struct mixer_context *ctx)
>> +{
>> +u32 val = 0;
>> +unsigned int i;
>> +
>> +for (i = 0; i < ctx->num_layer; ++i)
>> +val |= ctx->layer_config[i].cfg;
>> +
>> +mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
>> +}
>> +
>>  static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
>>  {
>>  struct mixer_resources *res = >mixer_res;
>> @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
>>  mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
>>  MXR_STATUS_BURST_MASK);
>>  
>> -/* setting default layer priority: layer1 > layer0 > video
>> - * because typical usage scenario would be
>> - * layer1 - OSD
>> - * layer0 - framebuffer
>> - * video - video overlay
>> - */
>> -val = MXR_LAYER_CFG_GRP1_VAL(3);
>> -val |= MXR_LAYER_CFG_GRP0_VAL(2);
>> -if (ctx->vp_enabled)
>> -val |= MXR_LAYER_CFG_VP_VAL(1);
>> -mixer_reg_write(res, MXR_LAYER_CFG, val);
> 
> I would move this exaclty piece of code into mixer_layer_priority().
Then we end up with the same static/hardcoded setup as before. That's
something I want to move away from. The entire information about layer
ordering should be stored in 'layer_config'.



>> +mixer_layer_priority(ctx);
>>  
>>  /* setting background color */
>>  mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
>> @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev)
>>  ctx->vp_enabled = drv->is_vp_enabled;
>>  ctx->has_sclk = drv->has_sclk;
>>  ctx->mxr_ver = drv->version;
>> +
>> +if (drv->is_vp_enabled) {
>> +ctx->layer_config = vp_layer_config;
>> +ctx->num_layer = ARRAY_SIZE(vp_layer_config);
>> +} else {
>> +ctx->layer_config = default_layer_config;
>> +ctx->num_layer =

[Bug 66963] Rv6xx dpm problems

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

--- Comment #259 from Maciej Gluszek  ---
Sorry, I was wrong after all. After 2 days i got a lockup again and went back
to the old method.

When i don't set DPM at boot GPU is overheating and the fan goes crazy. When
setting performance to something other than "high" - lockups happen.

I'm on Ubuntu 14.04 and using kernels from
http://kernel.ubuntu.com/~kernel-ppa/mainline/

-- 
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/20150430/47c9dda5/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

--- Comment #258 from Guram Savinov  ---
(In reply to Maciej Gluszek from comment #257)
> @Guram Savinov: I also tried setting DPM + high performance for my HD3650
> and it worked but the fan was still running too loud (not overheating just
> loud).
> 
> Then i installed Kernel 4.0, removed "high performance" settings and it
> works great now. I still have DPM set during boot but no more setting the
> card to be running on high performance. Couple of days and no lockups.
> 
> I'm on Ubuntu.

Maybe turning off DPM (do not set radeon.dpm=1 in kernel parameters) is better
than using DPM with high performance?

What Ubuntu release do you use? How you installed kernel 4.0?

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

[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass

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

--- Comment #15 from Andy Furniss  ---
(In reply to Tom Stellard from comment #14)
> Created attachment 115488 [details] [review]
> Possible fix
> 
> Can you try this applying this patch only?

This fixes it.

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

[PATCH 04/11] drivers/gpu: include for modular rockchip code

2015-04-30 Thread Paul Gortmaker

These files are built off of a tristate Kconfig option and also contain
modular function calls so they should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.

Cc: David Airlie 
Cc: Mark Yao 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Paul Gortmaker 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 3962176ee713..01b558fe3695 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ccb0ce073ef2..38155215efcd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
 #include 

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

[Bug 89534] GPU lockup with wine

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

Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> changed:

   What|Removed |Added

 Attachment #115487|0   |1
is obsolete||

--- Comment #18 from Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> ---
Created attachment 115489
  --> https://bugs.freedesktop.org/attachment.cgi?id=115489=edit
Tera Online dmesg errors (fixed)

The last file had a line missing at the end.

Well just in case it matters, I only get the crash sometimes when using the
warrior combo attack skill.

-- 
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/20150430/ecf09403/attachment.html>

[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass

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

--- Comment #14 from Tom Stellard  ---
Created attachment 115488
  --> https://bugs.freedesktop.org/attachment.cgi?id=115488=edit
Possible fix

Can you try this applying this patch only?

-- 
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/20150430/35e82543/attachment.html>

[Bug 89534] GPU lockup with wine

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

--- Comment #17 from John  ---
I haven't tried Tom's comment yet, as I need my PC to be stable till the rest
of the day, but I've extensively played Tera Online, so I doubt the issue is
related.

Plus I get my issue both with nine and without it (just more often with nine).

-- 
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/20150430/2878e4ee/attachment.html>

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

--- Comment #43 from Daniele  ---
I confirm that your last patch makes things work here too

-- 
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/20150430/4ec70621/attachment.html>

[Bug 89534] GPU lockup with wine

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

--- Comment #16 from Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> ---
Created attachment 115487
  --> https://bugs.freedesktop.org/attachment.cgi?id=115487=edit
Tera Online dmesg errors

Parts of dmesg showing the errors.

-- 
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/20150430/6bb62176/attachment.html>

[Bug 89534] GPU lockup with wine

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

--- Comment #15 from Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> ---
Created attachment 115486
  --> https://bugs.freedesktop.org/attachment.cgi?id=115486=edit
R600_DEBUG=ps,gs,vs for Tera Online

I am having the same crash with another Unreal Engine 3 game, Tera Online.
I am also using wine with gallium nine. Pure wine works but is slow.

I have attached the whole output of R600_DEBUG=ps,gs,vs before the crash.


Gpu:
radeon r7 250x

Software:
Archlinux
linux 4.0.1-1-ARCH x86_64
mesa 10.5.4-1
llvm-libs 3.6.0-5
xorg-server 1.17.1-5

-- 
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/20150430/488db785/attachment.html>

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

--- Comment #42 from Erik  ---
Works like a charm :)

-- 
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/20150430/6b51a40f/attachment.html>

[PATCH v4 12/12] drm/exynos: remove unnecessary calls to disable_plane()

From: Gustavo Padovan 

The planes are already disabled by the drm_atomic_helper_commit() code
so we don't need to disable the in these two places.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 ---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |  8 
 2 files changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 519c569..9bf25ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -47,8 +47,6 @@ static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_plane *plane;
-   int ret;

if (!exynos_crtc->enabled)
return;
@@ -64,15 +62,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_OFF);

exynos_crtc->enabled = false;
-
-   drm_for_each_legacy_plane(plane, >dev->mode_config.plane_list) {
-   if (plane->crtc != crtc)
-   continue;
-
-   ret = plane->funcs->disable_plane(plane);
-   if (ret)
-   DRM_ERROR("Failed to disable plane %d\n", ret);
-   }
 }

 static bool
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 0648ba4..7b89fd5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -81,17 +81,9 @@ static void exynos_drm_encoder_disable(struct drm_encoder 
*encoder)
 {
struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
struct exynos_drm_display *display = exynos_encoder->display;
-   struct drm_plane *plane;
-   struct drm_device *dev = encoder->dev;

if (display->ops->dpms)
display->ops->dpms(display, DRM_MODE_DPMS_OFF);
-
-   /* all planes connected to this encoder should be also disabled. */
-   drm_for_each_legacy_plane(plane, >mode_config.plane_list) {
-   if (plane->crtc && (plane->crtc == encoder->crtc))
-   plane->funcs->disable_plane(plane);
-   }
 }

 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
-- 
2.1.0

[PATCH v4 11/12] drm/exynos: atomic dpms support

From: Gustavo Padovan 

Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.

v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms()
- do not use WARN_ON on crtc enable/disable

v3: - Fix build failure after the hdmi change in v2
- Change dpms helper of ptn3460 bridge

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/bridge/ps8622.c |  2 +-
 drivers/gpu/drm/bridge/ptn3460.c|  2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 99 -
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  6 +-
 10 files changed, 71 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index b604326..d686235 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -499,7 +499,7 @@ static void ps8622_connector_destroy(struct drm_connector 
*connector)
 }

 static const struct drm_connector_funcs ps8622_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
.destroy = ps8622_connector_destroy,
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 8ed3617..260bc9f 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -260,7 +260,7 @@ static void ptn3460_connector_destroy(struct drm_connector 
*connector)
 }

 static struct drm_connector_funcs ptn3460_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 59f2ca5..d468637 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -955,7 +955,7 @@ static void exynos_dp_connector_destroy(struct 
drm_connector *connector)
 }

 static struct drm_connector_funcs exynos_dp_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0db7b91..519c569 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -22,51 +22,57 @@
 #include "exynos_drm_encoder.h"
 #include "exynos_drm_plane.h"

-static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
+static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(crtc->primary);

-   DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);
-
-   if (exynos_crtc->dpms == mode) {
-   DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
+   if (exynos_crtc->enabled)
return;
-   }
-
-   if (mode > DRM_MODE_DPMS_ON) {
-   /* wait for the completion of page flip. */
-   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
-   (exynos_crtc->event == NULL), HZ/20))
-   exynos_crtc->event = NULL;
-   drm_crtc_vblank_off(crtc);
-   }

if (exynos_crtc->ops->dpms)
-   exynos_crtc->ops->dpms(exynos_crtc, mode);
+   exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_ON);

-   exynos_crtc->dpms = mode;
+   exynos_crtc->enabled = true;

-   if (mode == DRM_MODE_DPMS_ON)
-   drm_crtc_vblank_on(crtc);
-}
+   drm_crtc_vblank_on(crtc);

-static void exynos_drm_crtc_prepare(struct drm_crtc *crtc)
-{
-   /* drm framework doesn't check NULL. */
+   if (exynos_crtc->ops->win_commit)
+   exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
+
+   if (exynos_crtc->ops->commit)
+   exynos_crtc->ops->commit(exynos_crtc);
 }

-static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
+static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-

[PATCH v4 10/12] drm/exynos: don't disable unused functions at init

From: Gustavo Padovan 

Everything starts disabled so we don't really need to disable anything.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e71e331..e0b085b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -275,9 +275,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)

}

-   /* disable all the possible outputs/crtcs before entering KMS mode */
-   drm_helper_disable_unused_functions(dev);
-
ret = drm_fb_helper_initial_config(helper, PREFERRED_BPP);
if (ret < 0) {
DRM_ERROR("failed to set up hw configuration.\n");
-- 
2.1.0

[PATCH v4 09/12] drm/exynos: remove exported functions from exynos_drm_plane

From: Gustavo Padovan 

Now that no one is using the functions exported by exynos_drm_plane due
to the atomic conversion we can make remove some of the them or make them
static.

v2: remove unused exynos_drm_crtc

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 90 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 
 2 files changed, 37 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 7d42e09..8bad40e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -62,35 +62,12 @@ static int exynos_plane_get_size(int start, unsigned 
length, unsigned last)
return size;
 }

-int exynos_check_plane(struct drm_plane *plane, struct drm_framebuffer *fb)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   int nr;
-   int i;
-
-   nr = exynos_drm_fb_get_buf_cnt(fb);
-   for (i = 0; i < nr; i++) {
-   struct exynos_drm_gem_buf *buffer = exynos_drm_fb_buffer(fb, i);
-
-   if (!buffer) {
-   DRM_DEBUG_KMS("buffer is null\n");
-   return -EFAULT;
-   }
-
-   exynos_plane->dma_addr[i] = buffer->dma_addr;
-
-   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
-   i, (unsigned long)exynos_plane->dma_addr[i]);
-   }
-
-   return 0;
-}
-
-void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+static void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc 
*crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
 {
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
unsigned int actual_w;
@@ -145,24 +122,6 @@ void exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
plane->crtc = crtc;
 }

-void
-exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
-{
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-
-   exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
- crtc_w, crtc_h, src_x >> 16, src_y >> 16,
- src_w >> 16, src_h >> 16);
-
-   if (exynos_crtc->ops->win_commit)
-   exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -175,19 +134,44 @@ static struct drm_plane_funcs exynos_plane_funcs = {
 static int exynos_plane_atomic_check(struct drm_plane *plane,
 struct drm_plane_state *state)
 {
-   return exynos_check_plane(plane, state->fb);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   int nr;
+   int i;
+
+   nr = exynos_drm_fb_get_buf_cnt(state->fb);
+   for (i = 0; i < nr; i++) {
+   struct exynos_drm_gem_buf *buffer =
+   exynos_drm_fb_buffer(state->fb, i);
+
+   if (!buffer) {
+   DRM_DEBUG_KMS("buffer is null\n");
+   return -EFAULT;
+   }
+
+   exynos_plane->dma_addr[i] = buffer->dma_addr;
+
+   DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
+   i, (unsigned long)exynos_plane->dma_addr[i]);
+   }
+
+   return 0;
 }

 static void exynos_plane_atomic_update(struct drm_plane *plane,
   struct drm_plane_state *old_state)
 {
struct drm_plane_state *state = plane->state;
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(state->crtc);
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);

-   exynos_update_plane(plane, state->crtc, state->fb,
-   state->crtc_x, state->crtc_y,
-   state->crtc_w, state->crtc_h,
-

[PATCH v4 08/12] drm/exynos: atomic phase 3: convert page flips

From: Gustavo Padovan 

PageFlips now use the atomic helper to work through the atomic modesetting
API. Async page flips are not supported yet.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 +---
 drivers/gpu/drm/exynos/exynos_drm_fb.c   |  9 -
 2 files changed, 9 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b0888d4..0db7b91 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -123,67 +123,6 @@ static struct drm_crtc_helper_funcs 
exynos_crtc_helper_funcs = {
.disable= exynos_drm_crtc_disable,
 };

-static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-struct drm_pending_vblank_event *event,
-uint32_t page_flip_flags)
-{
-   struct drm_device *dev = crtc->dev;
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   unsigned int crtc_w, crtc_h;
-   int ret;
-
-   /* when the page flip is requested, crtc's dpms should be on */
-   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
-   DRM_ERROR("failed page flip request.\n");
-   return -EINVAL;
-   }
-
-   if (!event)
-   return -EINVAL;
-
-   spin_lock_irq(>event_lock);
-   if (exynos_crtc->event) {
-   ret = -EBUSY;
-   goto out;
-   }
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret)
-   goto out;
-
-   ret = drm_vblank_get(dev, exynos_crtc->pipe);
-   if (ret) {
-   DRM_DEBUG("failed to acquire vblank counter\n");
-   goto out;
-   }
-
-   exynos_crtc->event = event;
-   spin_unlock_irq(>event_lock);
-
-   /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
-   event->pipe = exynos_crtc->pipe;
-
-   crtc->primary->fb = fb;
-   crtc_w = fb->width - crtc->x;
-   crtc_h = fb->height - crtc->y;
-   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-   crtc_w, crtc_h, crtc->x, crtc->y,
-   crtc_w, crtc_h);
-
-   if (crtc->primary->state)
-   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
-
-   return 0;
-
-out:
-   spin_unlock_irq(>event_lock);
-   return ret;
-}
-
 static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
@@ -197,7 +136,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)

 static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
-   .page_flip  = exynos_drm_crtc_page_flip,
+   .page_flip  = drm_atomic_helper_page_flip,
.destroy= exynos_drm_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index dcda496..d5141af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -303,11 +303,18 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
exynos_drm_fbdev_init(dev);
 }

+static int exynos_atomic_commit(struct drm_device *dev,
+   struct drm_atomic_state *state,
+   bool async)
+{
+   return drm_atomic_helper_commit(dev, state, false);
+}
+
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
+   .atomic_commit = exynos_atomic_commit,
 };

 void exynos_drm_mode_config_init(struct drm_device *dev)
-- 
2.1.0

[PATCH v4 07/12] drm/exynos: atomic phase 3: use atomic .set_config helper

From: Gustavo Padovan 

Now that phase 1 and 2 are complete switch .set_config helper to
use the atomic one.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b080e83..b0888d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -196,7 +196,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
 }

 static struct drm_crtc_funcs exynos_crtc_funcs = {
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.page_flip  = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
-- 
2.1.0

[PATCH v4 06/12] drm/exynos: atomic phase 3: atomic updates of planes

From: Gustavo Padovan 

Now that phase 1 and 2 are complete we can switch the update/disable_plane
callbacks to their atomic version.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 8a38eb7..dcda496 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "exynos_drm_drv.h"
@@ -305,6 +306,8 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };

 void exynos_drm_mode_config_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d53dc44..7d42e09 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -164,8 +164,8 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 }

 static struct drm_plane_funcs exynos_plane_funcs = {
-   .update_plane   = drm_plane_helper_update,
-   .disable_plane  = drm_plane_helper_disable,
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
-- 
2.1.0

[PATCH v4 05/12] drm/exynos: atomic phase 2: keep track of framebuffer pointer

From: Gustavo Padovan 

Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 44e73d0..b080e83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -174,6 +174,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc_w, crtc_h, crtc->x, crtc->y,
crtc_w, crtc_h);

+   if (crtc->primary->state)
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
+
return 0;

 out:
-- 
2.1.0

[PATCH v4 04/12] drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy()

From: Gustavo Padovan 

Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/bridge/ps8622.c   | 4 
 drivers/gpu/drm/bridge/ptn3460.c  | 4 
 drivers/gpu/drm/exynos/exynos_dp_core.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 6 ++
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 2 ++
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 4 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 4 
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 4 
 10 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index e895aa7..b604326 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -31,6 +31,7 @@
 #include "drmP.h"
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"

 /* Brightness scale on the Parade chip */
 #define PS8622_MAX_BRIGHTNESS 0xff
@@ -502,6 +503,9 @@ static const struct drm_connector_funcs 
ps8622_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ps8622_detect,
.destroy = ps8622_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int ps8622_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 9d2f053..8ed3617 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -27,6 +27,7 @@

 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"
 #include "drm_edid.h"
 #include "drmP.h"

@@ -263,6 +264,9 @@ static struct drm_connector_funcs ptn3460_connector_funcs = 
{
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int ptn3460_bridge_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 1dbfba5..59f2ca5 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -958,6 +959,9 @@ static struct drm_connector_funcs exynos_dp_connector_funcs 
= {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static int exynos_dp_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 35f101f..44e73d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -14,6 +14,8 @@

 #include 
 #include 
+#include 
+#include 

 #include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
@@ -194,8 +196,12 @@ static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.page_flip  = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };

+
 struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
   struct drm_plane *plane,
   int pipe,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 37678cf..ced5c23 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -63,6 +64,9 @@ static struct drm_connector_funcs exynos_dpi_connector_funcs 
= {
.detect = exynos_dpi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = exynos_dpi_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+

[PATCH v4 03/12] drm/exynos: atomic phase 1: add .mode_set_nofb() callback

From: Gustavo Padovan 

The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +---
 1 file changed, 9 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 1c0d936..35f101f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -81,59 +81,16 @@ exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
 }

-static int
-exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode, int x, int y,
- struct drm_framebuffer *old_fb)
-{
-   struct drm_framebuffer *fb = crtc->primary->fb;
-   unsigned int crtc_w;
-   unsigned int crtc_h;
-   int ret;
-
-   /*
-* copy the mode data adjusted by mode_fixup() into crtc->mode
-* so that hardware can be seet to proper mode.
-*/
-   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret < 0)
-   return ret;
-
-   crtc_w = fb->width - x;
-   crtc_h = fb->height - y;
-   exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, x, y, crtc_w, crtc_h);
-
-   return 0;
-}
-
-static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
+static void
+exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_framebuffer *fb = crtc->primary->fb;
-   unsigned int crtc_w;
-   unsigned int crtc_h;
-   int ret;

-   /* when framebuffer changing is requested, crtc's dpms should be on */
-   if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
-   DRM_ERROR("failed framebuffer changing request.\n");
-   return -EPERM;
-   }
-
-   ret = exynos_check_plane(crtc->primary, fb);
-   if (ret)
-   return ret;
-
-   crtc_w = fb->width - x;
-   crtc_h = fb->height - y;
-   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+   if (WARN_ON(!crtc->state))
+   return;

-   return 0;
+   if (exynos_crtc->ops->commit)
+   exynos_crtc->ops->commit(exynos_crtc);
 }

 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -158,8 +115,9 @@ static struct drm_crtc_helper_funcs 
exynos_crtc_helper_funcs = {
.prepare= exynos_drm_crtc_prepare,
.commit = exynos_drm_crtc_commit,
.mode_fixup = exynos_drm_crtc_mode_fixup,
-   .mode_set   = exynos_drm_crtc_mode_set,
-   .mode_set_base  = exynos_drm_crtc_mode_set_base,
+   .mode_set   = drm_helper_crtc_mode_set,
+   .mode_set_nofb  = exynos_drm_crtc_mode_set_nofb,
+   .mode_set_base  = drm_helper_crtc_mode_set_base,
.disable= exynos_drm_crtc_disable,
 };

-- 
2.1.0

[PATCH v4 02/12] drm/exynos: atomic phase 1: use drm_plane_helper_disable()

From: Gustavo Padovan 

The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()

exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 26 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 929cb03..8a38eb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -136,7 +136,7 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct 
drm_framebuffer *fb)

exynos_fb = to_exynos_fb(fb);

-   return exynos_fb->buf_cnt;
+   return exynos_fb ? exynos_fb->buf_cnt : 0;
 }

 struct drm_framebuffer *
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d7a046a..ca93ad8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -162,21 +162,9 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
 }

-static int exynos_disable_plane(struct drm_plane *plane)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc);
-
-   if (exynos_crtc && exynos_crtc->ops->win_disable)
-   exynos_crtc->ops->win_disable(exynos_crtc,
- exynos_plane->zpos);
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_plane_helper_update,
-   .disable_plane  = exynos_disable_plane,
+   .disable_plane  = drm_plane_helper_disable,
.destroy= drm_plane_cleanup,
 };

@@ -198,9 +186,21 @@ static void exynos_plane_atomic_update(struct drm_plane 
*plane,
state->src_w >> 16, state->src_h >> 16);
 }

+static void exynos_plane_atomic_disable(struct drm_plane *plane,
+   struct drm_plane_state *old_state)
+{
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(old_state->crtc);
+
+   if (exynos_crtc->ops->win_disable)
+   exynos_crtc->ops->win_disable(exynos_crtc,
+ exynos_plane->zpos);
+}
+
 static const struct drm_plane_helper_funcs plane_helper_funcs = {
.atomic_check = exynos_plane_atomic_check,
.atomic_update = exynos_plane_atomic_update,
+   .atomic_disable = exynos_plane_atomic_disable,
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
-- 
2.1.0

[PATCH v4 01/12] drm/exynos: atomic phase 1: use drm_plane_helper_update()

From: Gustavo Padovan 

Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.

Update all users of exynos_update_plane() accordingly to call
exynos_check_plane() before.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 29 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 +-
 3 files changed, 43 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index eb49195..1c0d936 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -116,6 +116,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
struct drm_framebuffer *fb = crtc->primary->fb;
unsigned int crtc_w;
unsigned int crtc_h;
+   int ret;

/* when framebuffer changing is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -123,11 +124,16 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
return -EPERM;
}

+   ret = exynos_check_plane(crtc->primary, fb);
+   if (ret)
+   return ret;
+
crtc_w = fb->width - x;
crtc_h = fb->height - y;
+   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   crtc_w, crtc_h, x, y, crtc_w, crtc_h);

-   return exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
-  crtc_w, crtc_h, x, y, crtc_w, crtc_h);
+   return 0;
 }

 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
@@ -164,7 +170,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
int ret;

@@ -183,6 +188,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}

+   ret = exynos_check_plane(crtc->primary, fb);
+   if (ret)
+   goto out;
+
ret = drm_vblank_get(dev, exynos_crtc->pipe);
if (ret) {
DRM_DEBUG("failed to acquire vblank counter\n");
@@ -201,17 +210,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc->primary->fb = fb;
crtc_w = fb->width - crtc->x;
crtc_h = fb->height - crtc->y;
-   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
-   if (ret) {
-   crtc->primary->fb = old_fb;
-   spin_lock_irq(>event_lock);
-   exynos_crtc->event = NULL;
-   drm_vblank_put(dev, exynos_crtc->pipe);
-   spin_unlock_irq(>event_lock);
-   return ret;
-   }
+   exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   crtc_w, crtc_h, crtc->x, crtc->y,
+   crtc_w, crtc_h);

return 0;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 13ea334..d7a046a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -144,21 +144,15 @@ void exynos_plane_mode_set(struct drm_plane *plane, 
struct drm_crtc *crtc,
plane->crtc = crtc;
 }

-int
+void
 exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
 struct drm_framebuffer *fb, int crtc_x, int crtc_y,
 unsigned int crtc_w, unsigned int crtc_h,
 uint32_t src_x, uint32_t src_y,
 uint32_t src_w, uint32_t src_h)
 {
-
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   int ret;
-
-   ret = exynos_check_plane(plane, fb);
-   if (ret < 0)
-   return ret;

exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y,
  crtc_w, crtc_h, src_x >> 16, src_y >> 16,
@@ -166,8 +160,6 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,

if (exynos_crtc->ops->win_commit)
exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
-
-   return 0;
 }

 static int exynos_disable_plane(struct drm_plane *plane)
@@ -183,11 +175,34 @@ static int exynos_disable_plane(struct drm_plane *plane)
 }

 static struct drm_plane_funcs exynos_plane_funcs = {
-   .update_plane   = exynos_update_plane,
+   .update_plane   = drm_plane_helper_update,

drm/exynos: Add atomic modesetting support

Hi,

Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.

v2: fixes comments by Joonyoung
- remove unused var in patch 09
- use ->disable instead of outdated ->dpms in hdmi code
- remove WARN_ON from crtc enable/disable

v3: fixes comment by Joonyoung
- move the removal of drm_helper_disable_unused_functions() to
separated patch

v4: add patches that remove unnecessary calls to disable_plane()

Gustavo

---
Gustavo Padovan (12):
  drm/exynos: atomic phase 1: use drm_plane_helper_update()
  drm/exynos: atomic phase 1: use drm_plane_helper_disable()
  drm/exynos: atomic phase 1: add .mode_set_nofb() callback
  drm/exynos: atomic phase 2: wire up state reset(), duplicate() and 
destroy()
  drm/exynos: atomic phase 2: keep track of framebuffer pointer
  drm/exynos: atomic phase 3: atomic updates of planes
  drm/exynos: atomic phase 3: use atomic .set_config helper
  drm/exynos: atomic phase 3: convert page flips
  drm/exynos: remove exported functions from exynos_drm_plane
  drm/exynos: don't disable unused functions at init
  drm/exynos: atomic dpms support
  drm/exynos: remove unnecessary calls to disable_plane()

 drivers/gpu/drm/bridge/ps8622.c |   6 +-
 drivers/gpu/drm/bridge/ptn3460.c|   6 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 215 
+--
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |  35 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  12 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |   3 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c   | 115 +
 drivers/gpu/drm/exynos/exynos_drm_plane.h   |  11 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   6 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  10 +-
 15 files changed, 178 insertions(+), 265 deletions(-)

[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-04-30 Thread Javier Martinez Canillas

Hello Olof,

On 04/30/2015 05:57 PM, Olof Johansson wrote:
> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman  wrote:
>> Krzysztof Kozlowski  writes:
>
> This should fix issue reported by Javier [1][2].
>
> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
> especially on other Exynos 5xxx products.

 I hoped to try this on my exynos5 boards, but it doesn't seem to apply
 to linux-next or to Linus' master branch.

 Are there some other dependencies here?
>>>
>>> It is already applied:
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
>>
>> Er, yup.  That would explain it. ;)
>>
>> Sorry for the noise,
> 
> Well, noise or not, Exynos is still broken in mainline and was broken
> on -next for so long in different ways that bisecting it is a futile
> exercise in frustration.
> 
> It doesn't seem to show up with a trivial boot using only ramdisk, but
> when booting a real distro from disk, it certainly does.
> 
> For example:
> 
> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html
> 
> Disabling CONFIG_DRM makes it boot reliably.
> 
> Arndale doesn't show it for me, but it also doesn't have working graphics.
>

Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix
for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1
power domain on Exynos5420" patch that was posted a long time ago. I have
pinged Kukjin several times about this patch and he said that he will pick
it this weekend [0].

It is indeed very frustrating how many Exynos patches seems to be falling
through the crack, even important fixes like these ones that allow boards
to boot again.

Kevin suggested that Krzysztof could collect and queue patches [1] to help
Kukjin and start acting as a co-maintatiner which I think it's a very good
idea and Krzysztof already did for some patches during the 4.1 cycle.

> 
> -Olof
>

Best regards,
Javier

[0]: https://lkml.org/lkml/2015/4/29/781
[1]: https://lkml.org/lkml/2015/4/30/576
[2]: https://lkml.org/lkml/2015/3/11/403

[RFC 1/5] drm/exynos: mixer: refactor layer setup

2015-04-30 Tobias Jakobi :

> Hello Gustavo!
> 
> 
> Gustavo Padovan wrote:
> > Hi Tobias,
> > 
> > 2015-04-30 Tobias Jakobi :
> > 
> >> First step in allowing a more generic way to setup complex
> >> blending for the different layers.
> >>
> >> Signed-off-by: Tobias Jakobi 
> >> ---
> >>  drivers/gpu/drm/exynos/exynos_mixer.c | 74 
> >> +--
> >>  1 file changed, 63 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> >> b/drivers/gpu/drm/exynos/exynos_mixer.c
> >> index 4155f43..a06b8e2 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> >> @@ -63,6 +63,12 @@ struct mixer_resources {
> >>struct clk  *mout_mixer;
> >>  };
> >>  
> >> +struct layer_config {
> >> +  unsigned int index;
> >> +  unsigned int priority;
> >> +  u32 cfg;
> >> +};
> > 
> > I don't see why you are creating this struct, index and priority are
> > never used in this patch series.
> Good catch about 'priority'. But 'index' is used, see the second patch.
> 
> 
> 
> > 
> >> +
> >>  enum mixer_version_id {
> >>MXR_VER_0_0_0_16,
> >>MXR_VER_16_0_33_0,
> >> @@ -75,6 +81,8 @@ struct mixer_context {
> >>struct drm_device   *drm_dev;
> >>struct exynos_drm_crtc  *crtc;
> >>struct exynos_drm_plane planes[MIXER_WIN_NR];
> >> +  const struct layer_config *layer_config;
> >> +  unsigned int num_layer;
> >>int pipe;
> >>boolinterlace;
> >>boolpowered;
> >> @@ -95,6 +103,40 @@ struct mixer_drv_data {
> >>boolhas_sclk;
> >>  };
> >>  
> >> +/*
> >> + * The default layer priorities. A higher priority means that
> >> + * the layer is at the top of layer stack.
> >> + * The current configuration assumes the following usage scenario:
> >> + * layer1: OSD [top]
> >> + * layer0: main framebuffer
> >> + * video layer: video overlay [bottom]
> >> + * Note that the video layer is only usable when the
> >> + * video processor is available.
> >> + */
> >> +
> >> +static const struct layer_config default_layer_config[] = {
> >> +  {
> >> +  .index = 0, .priority = 1, /* layer0 */
> >> +  .cfg = MXR_LAYER_CFG_GRP0_VAL(1)
> >> +  }, {
> >> +  .index = 1, .priority = 2, /* layer1 */
> >> +  .cfg = MXR_LAYER_CFG_GRP1_VAL(2)
> >> +  }
> >> +};
> >> +
> >> +static const struct layer_config vp_layer_config[] = {
> >> +  {
> >> +  .index = 2, .priority = 1, /* video layer */
> >> +  .cfg = MXR_LAYER_CFG_VP_VAL(1)
> >> +  }, {
> >> +  .index = 0, .priority = 2, /* layer0 */
> >> +  .cfg = MXR_LAYER_CFG_GRP0_VAL(2)
> >> +  }, {
> >> +  .index = 1, .priority = 3, /* layer1 */
> >> +  .cfg = MXR_LAYER_CFG_GRP1_VAL(3)
> >> +  }
> >> +};
> >> +
> >>  static const u8 filter_y_horiz_tap8[] = {
> >>0,  -1, -1, -1, -1, -1, -1, -1,
> >>-1, -1, -1, -1, -1, 0,  0,  0,
> >> @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources 
> >> *res)
> >>filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
> >>  }
> >>  
> >> +static void mixer_layer_priority(struct mixer_context *ctx)
> >> +{
> >> +  u32 val = 0;
> >> +  unsigned int i;
> >> +
> >> +  for (i = 0; i < ctx->num_layer; ++i)
> >> +  val |= ctx->layer_config[i].cfg;
> >> +
> >> +  mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
> >> +}
> >> +
> >>  static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
> >>  {
> >>struct mixer_resources *res = >mixer_res;
> >> @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
> >>mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
> >>MXR_STATUS_BURST_MASK);
> >>  
> >> -  /* setting default layer priority: layer1 > layer0 > video
> >> -   * because typical usage scenario would be
> >> -   * layer1 - OSD
> >> -   * layer0 - framebuffer
> >> -   * video - video overlay
> >> -   */
> >> -  val = MXR_LAYER_CFG_GRP1_VAL(3);
> >> -  val |= MXR_LAYER_CFG_GRP0_VAL(2);
> >> -  if (ctx->vp_enabled)
> >> -  val |= MXR_LAYER_CFG_VP_VAL(1);
> >> -  mixer_reg_write(res, MXR_LAYER_CFG, val);
> > 
> > I would move this exaclty piece of code into mixer_layer_priority().
> Then we end up with the same static/hardcoded setup as before. That's
> something I want to move away from. The entire information about layer
> ordering should be stored in 'layer_config'.
> 
> 
> 
> >> +  mixer_layer_priority(ctx);
> >>  
> >>/* setting background color */
> >>mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
> >> @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev)
> >>ctx->vp_enabled = drv->is_vp_enabled;
> >>ctx->has_sclk = drv->has_sclk;
> >>ctx->mxr_ver = drv->version;
> >> +
> >> +  if (drv->is_vp_enabled) {
> >> +  ctx->layer_config =

[patch] drm/i915: checking IS_ERR() instead of NULL

2015-04-30 Thread Dan Carpenter

On Thu, Apr 30, 2015 at 03:43:02PM +0100, Chris Wilson wrote:
> On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote:
> > We switched from calling i915_gem_alloc_context_obj() to calling
> > i915_gem_alloc_object() so the error handling needs to be updated to
> > check for NULL instead of IS_ERR().
> 
> I had a patch to change i915_gem_alloc_object() to report the correct
> error rather than NULL - which can come in surprisingly handy at
> times...

That also works, of course.  Send it.  :)

regards,
dan carpenter

[patch] drm/i915: checking IS_ERR() instead of NULL

2015-04-30 Thread Dan Carpenter

We switched from calling i915_gem_alloc_context_obj() to calling
i915_gem_alloc_object() so the error handling needs to be updated to
check for NULL instead of IS_ERR().

Fixes: 149c86e74fe4 ('drm/i915: Allocate context objects from stolen')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 732fd63..0fa9209 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1895,10 +1895,9 @@ int intel_lr_context_deferred_create(struct 
intel_context *ctx,
context_size = round_up(get_lr_context_size(ring), 4096);

ctx_obj = i915_gem_alloc_object(dev, context_size);
-   if (IS_ERR(ctx_obj)) {
-   ret = PTR_ERR(ctx_obj);
-   DRM_DEBUG_DRIVER("Alloc LRC backing obj failed: %d\n", ret);
-   return ret;
+   if (!ctx_obj) {
+   DRM_DEBUG_DRIVER("Alloc LRC backing obj failed.\n");
+   return -ENOMEM;
}

if (is_global_default_ctx) {

[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype

Clock rates are stored in an unsigned long field, but ->round_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.

Change ->round_rate() prototype to return 0 or an error code, and pass the
requested rate as a pointer so that it can be adjusted depending on
hardware capabilities.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
Tested-by: Mikko Perttunen 
Reviewed-by: Heiko Stuebner 
---
CC: Jonathan Corbet 
CC: Shawn Guo 
CC: ascha Hauer 
CC: David Brown 
CC: Daniel Walker 
CC: Bryan Huntsman 
CC: Tony Lindgren 
CC: Paul Walmsley 
CC: Liviu Dudau 
CC: Sudeep Holla 
CC: Lorenzo Pieralisi 
CC: Ralf Baechle 
CC: Max Filippov 
CC: Heiko Stuebner 
CC: Sylwester Nawrocki  
CC: Tomasz Figa 
CC: Barry Song 
CC: Viresh Kumar 
CC: "Emilio LÃ³pez" 
CC: Maxime Ripard 
CC: Peter De Schrijver 
CC: Prashant Gaikwad 
CC: Stephen Warren 
CC: Thierry Reding 
CC: Alexandre Courbot 
CC: Tero Kristo 
CC: Ulf Hansson 
CC: Michal Simek 
CC: Philipp Zabel 
CC: linux-doc at vger.kernel.org
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
CC: linux-arm-msm at vger.kernel.org
CC: linux-omap at vger.kernel.org
CC: linux-mips at linux-mips.org
CC: patches at opensource.wolfsonmicro.com
CC: linux-rockchip at lists.infradead.org
CC: linux-samsung-soc at vger.kernel.org
CC: spear-devel at list.st.com
CC: linux-tegra at vger.kernel.org
CC: dri-devel at lists.freedesktop.org
CC: linux-media at vger.kernel.org
CC: rtc-linux at googlegroups.com

 Documentation/clk.txt|  4 +-
 arch/arm/mach-imx/clk-busy.c |  2 +-
 arch/arm/mach-imx/clk-cpu.c  | 12 +++-
 arch/arm/mach-imx/clk-fixup-div.c|  2 +-
 arch/arm/mach-imx/clk-pfd.c  | 11 ++--
 arch/arm/mach-imx/clk-pllv2.c|  8 ++-
 arch/arm/mach-imx/clk-pllv3.c| 46 +++--
 arch/arm/mach-msm/clock-pcom.c   |  4 +-
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 13 ++--
 arch/arm/mach-omap2/clkt_clksel.c|  6 +-
 arch/arm/mach-omap2/clkt_dpll.c  | 21 +++---
 arch/arm/mach-omap2/clock.h  |  4 +-
 arch/arm/mach-omap2/dpll3xxx.c   | 27 +---
 arch/arm/mach-omap2/dpll44xx.c   | 26 +---
 arch/arm/mach-vexpress/spc.c | 11 +++-
 arch/mips/alchemy/common/clock.c | 13 ++--
 drivers/clk/at91/clk-h32mx.c | 24 ---
 drivers/clk/at91/clk-peripheral.c| 31 +
 drivers/clk/at91/clk-pll.c   | 14 ++--
 drivers/clk/at91/clk-plldiv.c| 22 ---
 drivers/clk/at91/clk-smd.c   | 24 ---
 drivers/clk/at91/clk-usb.c   | 16 +++--
 drivers/clk/clk-axi-clkgen.c |  5 +-
 drivers/clk/clk-cdce706.c| 46 ++---
 drivers/clk/clk-composite.c  | 23 ---
 drivers/clk/clk-divider.c| 16 +++--
 drivers/clk/clk-fixed-factor.c   |  7 +-
 drivers/clk/clk-fractional-divider.c | 16 +++--
 drivers/clk/clk-highbank.c   | 18 +++---
 drivers/clk/clk-si5351.c | 96 ++--
 drivers/clk/clk-si570.c  | 14 ++--
 drivers/clk/clk-u300.c   | 65 ++-
 drivers/clk/clk-vt8500.c | 27 
 drivers/clk/clk-wm831x.c | 11 ++--
 drivers/clk/clk-xgene.c  | 11 ++--
 drivers/clk/clk.c| 14 ++--
 drivers/clk/mmp/clk-frac.c   | 14 ++--
 drivers/clk/mvebu/clk-corediv.c  |  7 +-
 drivers/clk/mvebu/clk-cpu.c  |  9 +--
 drivers/clk/mxs/clk-div.c|  4 +-
 drivers/clk/mxs/clk-frac.c   | 11 ++--
 drivers/clk/mxs/clk-ref.c| 11 ++--
 drivers/clk/qcom/clk-regmap-divider.c|  4 +-
 drivers/clk/rockchip/clk-pll.c   | 13 ++--
 drivers/clk/samsung/clk-pll.c| 13 ++--
 drivers/clk/shmobile/clk-div6.c  |  7 +-
 drivers/clk/shmobile/clk-rcar-gen2.c |  9 +--
 drivers/clk/sirf/clk-common.c| 18 +++---
 drivers/clk/spear/clk-aux-synth.c| 10 ++-
 drivers/clk/spear/clk-frac-synth.c   | 10 ++-
 drivers/clk/spear/clk-gpt-synth.c| 10 ++-
 drivers/clk/spear/clk-vco-pll.c  | 20 --
 drivers/clk/st/clk-flexgen.c | 11 ++--
 drivers/clk/st/clkgen-fsyn.c | 21 +++---
 drivers/clk/st/clkgen-mux.c  |  2 +-
 drivers/clk/sunxi/clk-factors.c  | 14 ++--
 drivers/clk/tegra/clk-audio-sync.c   |  8 +--
 drivers/clk/tegra/clk-divider.c  | 19 --
 drivers/clk/tegra/clk-periph.c   |  4 +-

[PATCH v2 0/2] clk: adapt ->round_rate()/->determine_rate() prototypes

Hello,

As previously discussed in this thread [1], this series is changing
clk_ops' ->round_rate()/->determine_rate() prototypes to avoid long
overflows when the returned rate is exceeding 2Ghz.

Most of those changes have been compile-tested, but none of them have
been tested on real hardware (the changes are quite simple though).

Best Regards,

Boris

[1]https://lkml.org/lkml/2015/4/14/528

Changes since v1:
- fix an 'uninitialized variable' bug reported by Heiko
- rebased on clk-next

CC: Jonathan Corbet 
CC: Shawn Guo 
CC: ascha Hauer 
CC: David Brown 
CC: Daniel Walker 
CC: Bryan Huntsman 
CC: Tony Lindgren 
CC: Paul Walmsley 
CC: Liviu Dudau 
CC: Sudeep Holla 
CC: Lorenzo Pieralisi 
CC: Ralf Baechle 
CC: Max Filippov 
CC: Heiko Stuebner 
CC: Sylwester Nawrocki  
CC: Tomasz Figa 
CC: Barry Song 
CC: Viresh Kumar 
CC: "Emilio LÃ³pez" 
CC: Maxime Ripard 
CC: Peter De Schrijver 
CC: Prashant Gaikwad 
CC: Stephen Warren 
CC: Thierry Reding 
CC: Alexandre Courbot 
CC: Tero Kristo 
CC: Ulf Hansson 
CC: Michal Simek 
CC: Philipp Zabel 
CC: linux-doc at vger.kernel.org
CC: linux-kernel at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org
CC: linux-arm-msm at vger.kernel.org
CC: linux-omap at vger.kernel.org
CC: linux-mips at linux-mips.org
CC: patches at opensource.wolfsonmicro.com
CC: linux-rockchip at lists.infradead.org
CC: linux-samsung-soc at vger.kernel.org
CC: spear-devel at list.st.com
CC: linux-tegra at vger.kernel.org
CC: dri-devel at lists.freedesktop.org
CC: linux-media at vger.kernel.org
CC: rtc-linux at googlegroups.com

Boris Brezillon (2):
  clk: change clk_ops' ->round_rate() prototype
  clk: change clk_ops' ->determine_rate() prototype

 Documentation/clk.txt|  8 +--
 arch/arm/mach-imx/clk-busy.c |  2 +-
 arch/arm/mach-imx/clk-cpu.c  | 12 +++-
 arch/arm/mach-imx/clk-fixup-div.c|  2 +-
 arch/arm/mach-imx/clk-pfd.c  | 11 ++--
 arch/arm/mach-imx/clk-pllv2.c|  8 ++-
 arch/arm/mach-imx/clk-pllv3.c| 46 +++--
 arch/arm/mach-msm/clock-pcom.c   |  4 +-
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 13 ++--
 arch/arm/mach-omap2/clkt_clksel.c|  6 +-
 arch/arm/mach-omap2/clkt_dpll.c  | 21 +++---
 arch/arm/mach-omap2/clock.h  |  4 +-
 arch/arm/mach-omap2/dpll3xxx.c   | 45 -
 arch/arm/mach-omap2/dpll44xx.c   | 44 +++--
 arch/arm/mach-vexpress/spc.c | 11 +++-
 arch/mips/alchemy/common/clock.c | 76 ++
 drivers/clk/at91/clk-h32mx.c | 24 ---
 drivers/clk/at91/clk-peripheral.c| 31 +
 drivers/clk/at91/clk-pll.c   | 14 ++--
 drivers/clk/at91/clk-plldiv.c| 22 ---
 drivers/clk/at91/clk-programmable.c  | 28 
 drivers/clk/at91/clk-smd.c   | 24 ---
 drivers/clk/at91/clk-usb.c   | 42 ++--
 drivers/clk/bcm/clk-kona.c   | 24 ---
 drivers/clk/clk-axi-clkgen.c |  5 +-
 drivers/clk/clk-cdce706.c| 46 ++---
 drivers/clk/clk-composite.c  | 27 
 drivers/clk/clk-divider.c| 16 +++--
 drivers/clk/clk-fixed-factor.c   |  7 +-
 drivers/clk/clk-fractional-divider.c | 16 +++--
 drivers/clk/clk-highbank.c   | 18 +++---
 drivers/clk/clk-si5351.c | 96 ++--
 drivers/clk/clk-si570.c  | 14 ++--
 drivers/clk/clk-u300.c   | 65 ++-
 drivers/clk/clk-vt8500.c | 27 
 drivers/clk/clk-wm831x.c | 11 ++--
 drivers/clk/clk-xgene.c  | 11 ++--
 drivers/clk/clk.c| 72 +++--
 drivers/clk/hisilicon/clk-hi3620.c   | 22 +++
 drivers/clk/mmp/clk-frac.c   | 14 ++--
 drivers/clk/mmp/clk-mix.c| 17 ++---
 drivers/clk/mvebu/clk-corediv.c  |  7 +-
 drivers/clk/mvebu/clk-cpu.c  |  9 +--
 drivers/clk/mxs/clk-div.c|  4 +-
 drivers/clk/mxs/clk-frac.c   | 11 ++--
 drivers/clk/mxs/clk-ref.c| 11 ++--
 drivers/clk/qcom/clk-pll.c   | 12 ++--
 drivers/clk/qcom/clk-rcg.c   | 32 +-
 drivers/clk/qcom/clk-rcg2.c  | 54 +---
 drivers/clk/qcom/clk-regmap-divider.c|  4 +-
 drivers/clk/rockchip/clk-pll.c   | 13 ++--
 drivers/clk/samsung/clk-pll.c| 13 ++--
 drivers/clk/shmobile/clk-div6.c  |  7 +-
 drivers/clk/shmobile/clk-rcar-gen2.c |  9 +--
 drivers/clk/sirf/clk-common.c| 18 +++---
 drivers/clk/spear/clk-aux-synth.c| 10 ++-

[RFC 1/5] drm/exynos: mixer: refactor layer setup

Hi Tobias,

2015-04-30 Tobias Jakobi :

> First step in allowing a more generic way to setup complex
> blending for the different layers.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 74 
> +--
>  1 file changed, 63 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 4155f43..a06b8e2 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -63,6 +63,12 @@ struct mixer_resources {
>   struct clk  *mout_mixer;
>  };
>  
> +struct layer_config {
> + unsigned int index;
> + unsigned int priority;
> + u32 cfg;
> +};

I don't see why you are creating this struct, index and priority are
never used in this patch series.

> +
>  enum mixer_version_id {
>   MXR_VER_0_0_0_16,
>   MXR_VER_16_0_33_0,
> @@ -75,6 +81,8 @@ struct mixer_context {
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
> + const struct layer_config *layer_config;
> + unsigned int num_layer;
>   int pipe;
>   boolinterlace;
>   boolpowered;
> @@ -95,6 +103,40 @@ struct mixer_drv_data {
>   boolhas_sclk;
>  };
>  
> +/*
> + * The default layer priorities. A higher priority means that
> + * the layer is at the top of layer stack.
> + * The current configuration assumes the following usage scenario:
> + * layer1: OSD [top]
> + * layer0: main framebuffer
> + * video layer: video overlay [bottom]
> + * Note that the video layer is only usable when the
> + * video processor is available.
> + */
> +
> +static const struct layer_config default_layer_config[] = {
> + {
> + .index = 0, .priority = 1, /* layer0 */
> + .cfg = MXR_LAYER_CFG_GRP0_VAL(1)
> + }, {
> + .index = 1, .priority = 2, /* layer1 */
> + .cfg = MXR_LAYER_CFG_GRP1_VAL(2)
> + }
> +};
> +
> +static const struct layer_config vp_layer_config[] = {
> + {
> + .index = 2, .priority = 1, /* video layer */
> + .cfg = MXR_LAYER_CFG_VP_VAL(1)
> + }, {
> + .index = 0, .priority = 2, /* layer0 */
> + .cfg = MXR_LAYER_CFG_GRP0_VAL(2)
> + }, {
> + .index = 1, .priority = 3, /* layer1 */
> + .cfg = MXR_LAYER_CFG_GRP1_VAL(3)
> + }
> +};
> +
>  static const u8 filter_y_horiz_tap8[] = {
>   0,  -1, -1, -1, -1, -1, -1, -1,
>   -1, -1, -1, -1, -1, 0,  0,  0,
> @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources 
> *res)
>   filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
>  }
>  
> +static void mixer_layer_priority(struct mixer_context *ctx)
> +{
> + u32 val = 0;
> + unsigned int i;
> +
> + for (i = 0; i < ctx->num_layer; ++i)
> + val |= ctx->layer_config[i].cfg;
> +
> + mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
> +}
> +
>  static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
>  {
>   struct mixer_resources *res = >mixer_res;
> @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
>   mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
>   MXR_STATUS_BURST_MASK);
>  
> - /* setting default layer priority: layer1 > layer0 > video
> -  * because typical usage scenario would be
> -  * layer1 - OSD
> -  * layer0 - framebuffer
> -  * video - video overlay
> -  */
> - val = MXR_LAYER_CFG_GRP1_VAL(3);
> - val |= MXR_LAYER_CFG_GRP0_VAL(2);
> - if (ctx->vp_enabled)
> - val |= MXR_LAYER_CFG_VP_VAL(1);
> - mixer_reg_write(res, MXR_LAYER_CFG, val);

I would move this exaclty piece of code into mixer_layer_priority().

> + mixer_layer_priority(ctx);
>  
>   /* setting background color */
>   mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
> @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev)
>   ctx->vp_enabled = drv->is_vp_enabled;
>   ctx->has_sclk = drv->has_sclk;
>   ctx->mxr_ver = drv->version;
> +
> + if (drv->is_vp_enabled) {
> + ctx->layer_config = vp_layer_config;
> + ctx->num_layer = ARRAY_SIZE(vp_layer_config);
> + } else {
> + ctx->layer_config = default_layer_config;
> + ctx->num_layer = ARRAY_SIZE(default_layer_config);
> + }

Then this piece of code is useless.

Gustavo

[RFC 5/5] drm/exynos: mixer: also allow ARGB1555 and ARGB4444

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 809f840..5a435aa 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -701,10 +701,12 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)

switch (plane->pixel_format) {
case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
fmt = MXR_FORMAT_ARGB;
break;

case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_ARGB1555:
fmt = MXR_FORMAT_ARGB1555;
break;

-- 
2.0.5

[RFC 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()

This updates the blending setup when the layer configuration
changes (triggered by mixer_win_{commit,disable}).

Extra care has to be taken for the layer that is currently
being enabled/disabled.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 3eec9ce..809f840 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -178,6 +178,18 @@ static inline bool is_alpha_format(const struct 
mixer_context* ctx, unsigned int
}
 }

+static inline unsigned int layer_bitmask(const struct mixer_context* ctx)
+{
+   unsigned int i, mask = 0;
+
+   for (i = 0; i < MIXER_WIN_NR; ++i) {
+   if (ctx->planes[i].enabled)
+   mask |= (1 << i);
+   }
+
+   return mask;
+}
+
 static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
 {
return readl(res->vp_regs + reg_id);
@@ -490,6 +502,7 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx, 
unsigned int height)
 static void mixer_cfg_layer(struct mixer_context *ctx, int win, bool enable)
 {
struct mixer_resources *res = >mixer_res;
+   unsigned int enable_state;
u32 val = enable ? ~0 : 0;

switch (win) {
@@ -507,6 +520,16 @@ static void mixer_cfg_layer(struct mixer_context *ctx, int 
win, bool enable)
}
break;
}
+
+   /* Determine the current enabled/disabled state of the layers. */
+   enable_state = layer_bitmask(ctx);
+   if (enable)
+   enable_state |= (1 << win);
+   else
+   enable_state &= ~(1 << win);
+
+   /* Layer configuration has changed, update blending setup. */
+   mixer_layer_blending(ctx, enable_state);
 }

 static void mixer_run(struct mixer_context *ctx)
-- 
2.0.5

[RFC 3/5] drm/exynos: mixer: remove all static blending setup

Previously blending setup was static and most of it was
done in mixer_win_reset().

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ff1168d..3eec9ce 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -504,11 +504,6 @@ static void mixer_cfg_layer(struct mixer_context *ctx, int 
win, bool enable)
vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
mixer_reg_writemask(res, MXR_CFG, val,
MXR_CFG_VP_ENABLE);
-
-   /* control blending of graphic layer 0 */
-   mixer_reg_writemask(res, MXR_GRAPHIC_CFG(0), val,
-   MXR_GRP_CFG_BLEND_PRE_MUL |
-   MXR_GRP_CFG_PIXEL_BLEND_EN);
}
break;
}
@@ -816,23 +811,6 @@ static void mixer_win_reset(struct mixer_context *ctx)
mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
mixer_reg_write(res, MXR_BG_COLOR2, 0x008080);

-   /* setting graphical layers */
-   val  = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
-   val |= MXR_GRP_CFG_WIN_BLEND_EN;
-   val |= MXR_GRP_CFG_ALPHA_VAL(0xff); /* non-transparent alpha */
-
-   /* Don't blend layer 0 onto the mixer background */
-   mixer_reg_write(res, MXR_GRAPHIC_CFG(0), val);
-
-   /* Blend layer 1 into layer 0 */
-   val |= MXR_GRP_CFG_BLEND_PRE_MUL;
-   val |= MXR_GRP_CFG_PIXEL_BLEND_EN;
-   mixer_reg_write(res, MXR_GRAPHIC_CFG(1), val);
-
-   /* setting video layers */
-   val = MXR_GRP_CFG_ALPHA_VAL(0);
-   mixer_reg_write(res, MXR_VIDEO_CFG, val);
-
if (ctx->vp_enabled) {
/* configuration of Video Processor Registers */
vp_win_reset(ctx);
-- 
2.0.5

[RFC 2/5] drm/exynos: mixer: introduce mixer_layer_blending()

This analyses the current layer configuration (which layers
are enabled, which have alpha-pixelformat, etc.) and setups
blending accordingly.

We currently disable all kinds of blending for the bottom-most
layer, since configuration of the mixer background is not
yet exposed.
Also blending is only enabled when the layer has a pixelformat
with alpha attached.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 101 ++
 drivers/gpu/drm/exynos/regs-mixer.h   |   1 +
 2 files changed, 102 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index a06b8e2..ff1168d 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -166,6 +166,18 @@ static const u8 filter_cr_horiz_tap4[] = {
70, 59, 48, 37, 27, 19, 11, 5,
 };

+static inline bool is_alpha_format(const struct mixer_context* ctx, unsigned 
int win)
+{
+   switch (ctx->planes[win].pixel_format) {
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_ARGB:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
 {
return readl(res->vp_regs + reg_id);
@@ -306,6 +318,95 @@ static void mixer_layer_priority(struct mixer_context *ctx)
mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
 }

+/* Configure blending for bottom-most layer. */
+static void mixer_bottom_layer(struct mixer_context *ctx,
+   const struct layer_config *cfg)
+{
+   u32 val;
+   struct mixer_resources *res = >mixer_res;
+
+   if (cfg->index == 2) {
+   val = 0; /* use defaults for video layer */
+   mixer_reg_write(res, MXR_VIDEO_CFG, val);
+   } else {
+   val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
+
+   /* Don't blend bottom-most layer onto the mixer background. */
+   mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
+   val, MXR_GRP_CFG_MISC_MASK);
+   }
+}
+
+static void mixer_general_layer(struct mixer_context *ctx,
+   const struct layer_config *cfg)
+{
+   u32 val;
+   struct mixer_resources *res = >mixer_res;
+
+   if (is_alpha_format(ctx, cfg->index)) {
+   val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
+   val |= MXR_GRP_CFG_BLEND_PRE_MUL;
+   val |= MXR_GRP_CFG_PIXEL_BLEND_EN;
+
+   /* The video layer never has an alpha pixelformat. */
+   mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
+   val, MXR_GRP_CFG_MISC_MASK);
+   } else {
+   if (cfg->index == 2) {
+   // TODO
+   } else {
+   val = MXR_GRP_CFG_COLOR_KEY_DISABLE;
+   mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
+   val, MXR_GRP_CFG_MISC_MASK);
+   }
+   }
+}
+
+static void mixer_layer_blending(struct mixer_context *ctx, unsigned int 
enable_state)
+{
+   const struct layer_config *cfg;
+   unsigned int i = 0;
+   unsigned int index;
+
+   /* Find bottom-most enabled layer. */
+   cfg = NULL;
+   while (i < ctx->num_layer) {
+   index = ctx->layer_config[i].index;
+   ++i;
+
+   if (enable_state & (1 << index)) {
+   cfg = >layer_config[i-1];
+   break;
+   }
+   }
+
+   /* No enabled layers found, nothing to do. */
+   if (!cfg)
+   return;
+
+   mixer_bottom_layer(ctx, cfg);
+
+   while (1) {
+   /* Find the next layer. */
+   cfg = NULL;
+   while (i < ctx->num_layer) {
+   index = ctx->layer_config[i].index;
+   ++i;
+
+   if (enable_state & (1 << index)) {
+   cfg = >layer_config[i-1];
+   break;
+   }
+   }
+
+   /* No more enabled layers found. */
+   if (!cfg)
+   return;
+
+   mixer_general_layer(ctx, cfg);
+   }
+}
+
 static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
 {
struct mixer_resources *res = >mixer_res;
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
b/drivers/gpu/drm/exynos/regs-mixer.h
index ac60260..118872e 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -113,6 +113,7 @@
 #define MXR_GRP_CFG_BLEND_PRE_MUL  (1 << 20)
 #define MXR_GRP_CFG_WIN_BLEND_EN   (1 << 17)
 #define MXR_GRP_CFG_PIXEL_BLEND_EN (1 << 16)
+#define MXR_GRP_CFG_MISC_MASK  ((3 << 16) | (3 << 20))
 #define

[RFC 1/5] drm/exynos: mixer: refactor layer setup

First step in allowing a more generic way to setup complex
blending for the different layers.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 74 +--
 1 file changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4155f43..a06b8e2 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -63,6 +63,12 @@ struct mixer_resources {
struct clk  *mout_mixer;
 };

+struct layer_config {
+   unsigned int index;
+   unsigned int priority;
+   u32 cfg;
+};
+
 enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
@@ -75,6 +81,8 @@ struct mixer_context {
struct drm_device   *drm_dev;
struct exynos_drm_crtc  *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
+   const struct layer_config *layer_config;
+   unsigned int num_layer;
int pipe;
boolinterlace;
boolpowered;
@@ -95,6 +103,40 @@ struct mixer_drv_data {
boolhas_sclk;
 };

+/*
+ * The default layer priorities. A higher priority means that
+ * the layer is at the top of layer stack.
+ * The current configuration assumes the following usage scenario:
+ * layer1: OSD [top]
+ * layer0: main framebuffer
+ * video layer: video overlay [bottom]
+ * Note that the video layer is only usable when the
+ * video processor is available.
+ */
+
+static const struct layer_config default_layer_config[] = {
+   {
+   .index = 0, .priority = 1, /* layer0 */
+   .cfg = MXR_LAYER_CFG_GRP0_VAL(1)
+   }, {
+   .index = 1, .priority = 2, /* layer1 */
+   .cfg = MXR_LAYER_CFG_GRP1_VAL(2)
+   }
+};
+
+static const struct layer_config vp_layer_config[] = {
+   {
+   .index = 2, .priority = 1, /* video layer */
+   .cfg = MXR_LAYER_CFG_VP_VAL(1)
+   }, {
+   .index = 0, .priority = 2, /* layer0 */
+   .cfg = MXR_LAYER_CFG_GRP0_VAL(2)
+   }, {
+   .index = 1, .priority = 3, /* layer1 */
+   .cfg = MXR_LAYER_CFG_GRP1_VAL(3)
+   }
+};
+
 static const u8 filter_y_horiz_tap8[] = {
0,  -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, 0,  0,  0,
@@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources *res)
filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
 }

+static void mixer_layer_priority(struct mixer_context *ctx)
+{
+   u32 val = 0;
+   unsigned int i;
+
+   for (i = 0; i < ctx->num_layer; ++i)
+   val |= ctx->layer_config[i].cfg;
+
+   mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
+}
+
 static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
 {
struct mixer_resources *res = >mixer_res;
@@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
MXR_STATUS_BURST_MASK);

-   /* setting default layer priority: layer1 > layer0 > video
-* because typical usage scenario would be
-* layer1 - OSD
-* layer0 - framebuffer
-* video - video overlay
-*/
-   val = MXR_LAYER_CFG_GRP1_VAL(3);
-   val |= MXR_LAYER_CFG_GRP0_VAL(2);
-   if (ctx->vp_enabled)
-   val |= MXR_LAYER_CFG_VP_VAL(1);
-   mixer_reg_write(res, MXR_LAYER_CFG, val);
+   mixer_layer_priority(ctx);

/* setting background color */
mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
@@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev)
ctx->vp_enabled = drv->is_vp_enabled;
ctx->has_sclk = drv->has_sclk;
ctx->mxr_ver = drv->version;
+
+   if (drv->is_vp_enabled) {
+   ctx->layer_config = vp_layer_config;
+   ctx->num_layer = ARRAY_SIZE(vp_layer_config);
+   } else {
+   ctx->layer_config = default_layer_config;
+   ctx->num_layer = ARRAY_SIZE(default_layer_config);
+   }
+
init_waitqueue_head(>wait_vsync_queue);
atomic_set(>wait_vsync_event, 0);

-- 
2.0.5

[RFC] drm/exynos: rework layer blending setup

Hello,

here's the rework of the layer blending setup that I discussed with Joonyoung 
in the past days. There's still 
some TODOs in the code, but more or less it does what it's supposed to do. What 
still bothers me a bit is that I 
currently call blending reconfig in mixer_cfg_layer(). It would be nice if this 
could be reduced to one call per 
"frame" (so with the last win_{commit,disable} call). Maybe atomic provides 
such an infrastructure?

With best wishes,
Tobias

[PATCH 2/9] mm: Provide new get_vaddr_pfns() helper

2015-04-30 Thread Mel Gorman

On Tue, Mar 17, 2015 at 12:56:32PM +0100, Jan Kara wrote:
> Provide new function get_vaddr_pfns().  This function maps virtual
> addresses from given start and fills given array with page frame numbers of
> the corresponding pages. If given start belongs to a normal vma, the function
> grabs reference to each of the pages to pin them in memory. If start
> belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
> should make sure pfns aren't reused for anything else while he is using
> them.
> 
> This function is created for various drivers to simplify handling of
> their buffers.
> 
> Signed-off-by: Jan Kara 
> ---
>  include/linux/mm.h |  38 +++
>  mm/gup.c   | 180 
> +
>  2 files changed, 218 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 47a93928b90f..a5045df92454 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1279,6 +1279,44 @@ long get_user_pages_unlocked(struct task_struct *tsk, 
> struct mm_struct *mm,
>   int write, int force, struct page **pages);
>  int get_user_pages_fast(unsigned long start, int nr_pages, int write,
>   struct page **pages);
> +
> +/* Container for pinned pfns / pages */
> +struct pinned_pfns {
> + unsigned int nr_allocated_pfns; /* Number of pfns we have space for */
> + unsigned int nr_pfns;   /* Number of pfns stored in pfns array 
> */
> + unsigned int got_ref:1; /* Did we pin pfns by getting page ref? 
> */
> + unsigned int is_pages:1;/* Does array contain pages or pfns? */

The bit field is probably overkill as I expect it'll get padded out for
pointer alignment anyway. Just use bools.

is_pfns is less ambiguous than is_pages but not very important.

The naming is not great in general. Only struct pages are pinned in the
traditional meaning of the word. The raw PFNs are not so there is no such
thing as a "pinned pfns". It might be better just to call it frame_vectors
and document that it's either raw PFNs that the caller should be responsible
for or struct pages that are pinned.

> + void *ptrs[0];  /* Array of pinned pfns / pages.
> +  * Use pfns_vector_pages() or
> +  * pfns_vector_pfns() for access */
> +};
> +
> +struct pinned_pfns *pfns_vector_create(int nr_pfns);
> +void pfns_vector_destroy(struct pinned_pfns *pfns);
> +int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force,
> +struct pinned_pfns *pfns);

It's not critical but I generally prefer to see bools for new APIs like
this.

unsigned int for nr_pfns.

> +void put_vaddr_pfns(struct pinned_pfns *pfns);
> +int pfns_vector_to_pages(struct pinned_pfns *pfns);
> +
> +static inline int pfns_vector_count(struct pinned_pfns *pfns)
> +{
> + return pfns->nr_pfns;
> +}

should return unsigned int.

> +
> +static inline struct page **pfns_vector_pages(struct pinned_pfns *pfns)
> +{
> + if (!pfns->is_pages)
> + return NULL;
> + return (struct page **)(pfns->ptrs);
> +}
> +
> +static inline unsigned long *pfns_vector_pfns(struct pinned_pfns *pfns)
> +{
> + if (pfns->is_pages)
> + return NULL;
> + return (unsigned long *)(pfns->ptrs);
> +}
> +
>  struct kvec;
>  int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
>   struct page **pages);
> diff --git a/mm/gup.c b/mm/gup.c
> index a6e24e246f86..63903913ab04 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -819,6 +819,186 @@ long get_user_pages(struct task_struct *tsk, struct 
> mm_struct *mm,
>  EXPORT_SYMBOL(get_user_pages);
>  
>  /**
> + * get_vaddr_pfns() - map virtual addresses to pfns
> + * @start:   starting user address
> + * @nr_pfns: number of pfns from start to map
> + * @write:   whether pages will be written to by the caller
> + * @force:   whether to force write access even if user mapping is
> + *   readonly. This will result in the page being COWed even
> + *   in MAP_SHARED mappings. You do not want this.
> + * @pfns:structure which receives pfns of the pages mapped.
> + *   It should have space for at least nr_pfns pfns.
> + *
> + * This function maps virtual addresses from @start and fills @pfns structure
> + * with page frame numbers of corresponding pages. If @start belongs to a
> + * normal vma, the function grabs reference to each of the pages to pin them 
> in
> + * memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page
> + * structures. Caller should make sure pfns aren't reused for anything else
> + * while he is using them.
> + *
> + * This function takes care of grabbing mmap_sem as necessary.
> + */
> +int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force,
> +struct pinned_pfns *pfns)
> +{
> + struct mm_struct *mm = current->mm;
> + struct

[PATCH] drm: panel: simple-panel: set appropriate mode type

2015-04-30 Thread Nicolas Ferre

Le 30/04/2015 16:39, Boris Brezillon a Ã©crit :
> All modes exposed by simple panels should be tagged as driver defined
> modes.
> Moreover, if a panel supports only one mode, this mode is obviously the
> preferred one.
> 
> Doing this also fix a problem occurring when a 'video=' parameter is passed
> on the kernel cmdline. In some cases the user provided mode is preferred
> over the simple panel ones, which might result in unpredictable behavior.
> 
> Signed-off-by: Boris Brezillon 

Tested-by: Nicolas Ferre 
On Atmel sama5d3xek board.

> ---
>  drivers/gpu/drm/panel/panel-simple.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index d14b904..95ae390 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -111,6 +111,10 @@ static int panel_simple_get_fixed_modes(struct 
> panel_simple *panel)
>   continue;
>   }
>  
> + mode->type |= DRM_MODE_TYPE_DRIVER;
> + if (panel->desc->num_modes == 1)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> +
>   drm_display_mode_from_videomode(, mode);
>  
>   drm_mode_probed_add(connector, mode);
> @@ -127,6 +131,10 @@ static int panel_simple_get_fixed_modes(struct 
> panel_simple *panel)
>   continue;
>   }
>  
> + mode->type |= DRM_MODE_TYPE_DRIVER;
> + if (panel->desc->num_modes == 1)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> +
>   drm_mode_set_name(mode);
>  
>   drm_mode_probed_add(connector, mode);
> 


-- 
Nicolas Ferre

[PATCH] drm: panel: simple-panel: set appropriate mode type

All modes exposed by simple panels should be tagged as driver defined
modes.
Moreover, if a panel supports only one mode, this mode is obviously the
preferred one.

Doing this also fix a problem occurring when a 'video=' parameter is passed
on the kernel cmdline. In some cases the user provided mode is preferred
over the simple panel ones, which might result in unpredictable behavior.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index d14b904..95ae390 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -111,6 +111,10 @@ static int panel_simple_get_fixed_modes(struct 
panel_simple *panel)
continue;
}

+   mode->type |= DRM_MODE_TYPE_DRIVER;
+   if (panel->desc->num_modes == 1)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
+
drm_display_mode_from_videomode(, mode);

drm_mode_probed_add(connector, mode);
@@ -127,6 +131,10 @@ static int panel_simple_get_fixed_modes(struct 
panel_simple *panel)
continue;
}

+   mode->type |= DRM_MODE_TYPE_DRIVER;
+   if (panel->desc->num_modes == 1)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
+
drm_mode_set_name(mode);

drm_mode_probed_add(connector, mode);
-- 
1.9.1

[PATCH] drm: panel: simple-panel: remove useless drm_mode_set_name

drm_display_mode_from_videomode() is already calling drm_mode_set_name() on
the provided mode.

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

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 30904a9..d14b904 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -112,7 +112,6 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
}

drm_display_mode_from_videomode(, mode);
-   drm_mode_set_name(mode);

drm_mode_probed_add(connector, mode);
num++;
-- 
1.9.1

[patch] drm/i915: checking IS_ERR() instead of NULL

2015-04-30 Thread Chris Wilson

On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote:
> We switched from calling i915_gem_alloc_context_obj() to calling
> i915_gem_alloc_object() so the error handling needs to be updated to
> check for NULL instead of IS_ERR().

I had a patch to change i915_gem_alloc_object() to report the correct
error rather than NULL - which can come in surprisingly handy at
times...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/5] drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6

2015-04-30 Thread Paulo Zanoni

2015-04-22 17:20 GMT-03:00 Alex Deucher :
> On Tue, Apr 21, 2015 at 2:09 PM, Todd Previte  wrote:
>> Displayport compliance test 4.2.2.6 requires that a source device be capable 
>> of
>> detecting a corrupt EDID. The test specification states that the sink device
>> sets up the EDID with an invalid checksum. To do this, the sink sets up an
>> invalid EDID header, expecting the source device to generate the checksum and
>> compare it to the value stored in the last byte of the block data.
>>
>> Unfortunately, the DRM EDID reading and parsing functions are actually too 
>> good
>> in this case; the header is fixed before the checksum is computed and thus 
>> the
>> test never sees the invalid checksum. This results in a failure to pass the
>> compliance test.
>>
>> To correct this issue, when the EDID code detects that the header is invalid,
>> a flag is set to indicate that the EDID is corrupted. In this case, it sets
>> edid_corrupt flag and continues with its fix-up code. This flag is also set 
>> in
>> the case of a more seriously damaged header (fixup score less than the
>> threshold). For consistency, the edid_corrupt flag is also set when the
>> checksum is invalid as well.
>>
>> V2:
>> - Removed the static bool global
>> - Added a bool to the drm_connector struct to reaplce the static one for
>>   holding the status of raw edid header corruption detection
>> - Modified the function signature of the is_valid function to take an
>>   additional parameter to store the corruption detected value
>> - Fixed the other callers of the above is_valid function
>> V3:
>> - Updated the commit message to be more clear about what and why this
>>   patch does what it does.
>> - Added comment in code to clarify the operations there
>> - Removed compliance variable and check_link_status update; those
>>   have been moved to a later patch
>> - Removed variable assignment from the bottom of the test handler
>> V4:
>> - Removed i915 tag from subject line as the patch is not i915-specific
>> V5:
>> - Moved code causing a compilation error to this patch where the variable
>>   is actually declared
>> - Maintained blank lines / spacing so as to not contaminate the patch
>> V6:
>> - Removed extra debug messages
>> - Added documentation to for the added parameter on drm_edid_block_valid
>> - Fixed more whitespace issues in check_link_status
>> - Added a clear of the header_corrupt flag to the end of the test handler
>>   in intel_dp.c
>> - Changed the usage of the new function prototype in several places to use
>>   NULL where it is not needed by compliance testing
>> V7:
>> - Updated to account for long_pulse flag propagation
>> V8:
>> - Removed clearing of header_corrupt flag from the test handler in intel_dp.c
>> - Added clearing of header_corrupt flag in the drm_edid_block_valid function
>> V9:
>> - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its
>>   value and purpose
>> - Updated commit message
>> V10:
>> - Updated for versioning and patch swizzle
>> - Revised the title to more accurately reflect the nature and contents of
>>   the patch
>> - Fixed formatting/whitespace problems
>> - Added set flag when computed checksum is invalid
>>
>> Signed-off-by: Todd Previte 
>> Cc: dri-devel at lists.freedesktop.org
>
> Seems reasonable.
>
> Reviewed-by: Alex Deucher 
Reviewed-by: Paulo Zanoni 
(since I made comments on the previous versions, this is my
documentation that the patch looks fine to me now)

>
>> ---
>>  drivers/gpu/drm/drm_edid.c  | 32 ++--
>>  drivers/gpu/drm/drm_edid_load.c |  7 +--
>>  include/drm/drm_crtc.h  |  8 +++-
>>  3 files changed, 38 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 53bc7a6..be6713c 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int 
>> length)
>>   * @raw_edid: pointer to raw EDID block
>>   * @block: type of block to validate (0 for base, extension otherwise)
>>   * @print_bad_edid: if true, dump bad EDID blocks to the console
>> + * @edid_corrupt: if true, the header or checksum is invalid
>>   *
>>   * Validate a base or extension EDID block and optionally dump bad blocks to
>>   * the console.
>>   *
>>   * Return: True if the block is valid, false otherwise.
>>   */
>> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
>> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
>> + bool *edid_corrupt)
>>  {
>> u8 csum;
>> struct edid *edid = (struct edid *)raw_edid;
>> @@ -1060,11 +1062,22 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
>> bool print_bad_edid)
>>
>> if (block == 0) {
>> int score = drm_edid_header_is_valid(raw_edid);
>> -   if (score == 8) ;
>> -   else if (score >= edid_fixup) {
>> +

[PULL] drm-intel-fixes

2015-04-30 Thread Jani Nikula


Hi Dave, just one fix for v4.1-rc2. Plenty of travel last week all
around, I'm sure we'll find more to worry about...

BR,
Jani.

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-04-30

for you to fetch changes up to a04f90a33fab74789b91fc973012f11022d1:

  drm/i915/chv: Implement WaDisableShadowRegForCpd (2015-04-28 17:31:29 +0300)


Deepak S (1):
  drm/i915/chv: Implement WaDisableShadowRegForCpd

 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 8 
 2 files changed, 10 insertions(+)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/msm/mdp5: Fix iteration on INTF config array

2015-04-30 Thread Stephane Viau

The current iteration in get_dsi_id_from_intf() is wrong:
instead of iterating until hw_cfg->intf.count, we need to iterate 
until MDP5_INTF_NUM_MAX here.

Let's take the example of msm8x16:

 hw_cfg->intf.count = 1
 intfs[0] = INTF_Disabled
 intfs[1] = INTF_DSI

If we stop iterating once i reaches hw_cfg->intf.count (== 1),
we will miss the test for intfs[1].

Actually, this hw_cfg->intf.count entry is quite confusing and is not
(or *should not be*) used anywhere else; let's remove it.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 34 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  9 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 12 ++--
 3 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 8bcd177..9ff25a3 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -72,14 +72,13 @@ const struct mdp5_cfg_hw msm8x74_config = {
.base = { 0x12d00, 0x12e00, 0x12f00 },
},
.intf = {
-   .count = 4,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
-   },
-   .intfs = {
-   [0] = INTF_eDP,
-   [1] = INTF_DSI,
-   [2] = INTF_DSI,
-   [3] = INTF_HDMI,
+   .connect = {
+   [0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
+   [3] = INTF_HDMI,
+   },
},
.max_clk = 2,
 };
@@ -142,14 +141,13 @@ const struct mdp5_cfg_hw apq8084_config = {
.base = { 0x12f00, 0x13000, 0x13100, 0x13200 },
},
.intf = {
-   .count = 5,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
-   },
-   .intfs = {
-   [0] = INTF_eDP,
-   [1] = INTF_DSI,
-   [2] = INTF_DSI,
-   [3] = INTF_HDMI,
+   .connect = {
+   [0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
+   [3] = INTF_HDMI,
+   },
},
.max_clk = 32000,
 };
@@ -196,10 +194,12 @@ const struct mdp5_cfg_hw msm8x16_config = {

},
.intf = {
-   .count = 1, /* INTF_1 */
-   .base = { 0x6B800 },
+   .base = { 0x0, 0x6b800 },
+   .connect = {
+   [0] = INTF_DISABLED,
+   [1] = INTF_DSI,
+   },
},
-   /* TODO enable .intfs[] with [1] = INTF_DSI, once DSI is implemented */
.max_clk = 32000,
 };

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index 3a551b0..69349ab 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -59,6 +59,11 @@ struct mdp5_smp_block {

 #define MDP5_INTF_NUM_MAX  5

+struct mdp5_intf_block {
+   uint32_t base[MAX_BASES];
+   u32 connect[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
+};
+
 struct mdp5_cfg_hw {
char  *name;

@@ -72,9 +77,7 @@ struct mdp5_cfg_hw {
struct mdp5_sub_block dspp;
struct mdp5_sub_block ad;
struct mdp5_sub_block pp;
-   struct mdp5_sub_block intf;
-
-   u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
+   struct mdp5_intf_block intf;

uint32_t max_clk;
 };
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 02ef86b..f6c5896 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -208,8 +208,8 @@ static struct drm_encoder *construct_encoder(struct 
mdp5_kms *mdp5_kms,

 static int get_dsi_id_from_intf(const struct mdp5_cfg_hw *hw_cfg, int intf_num)
 {
-   const int intf_cnt = hw_cfg->intf.count;
-   const u32 *intfs = hw_cfg->intfs;
+   const enum mdp5_intf_type *intfs = hw_cfg->intf.connect;
+   const int intf_cnt = ARRAY_SIZE(hw_cfg->intf.connect);
int id = 0, i;

for (i = 0; i < intf_cnt; i++) {
@@ -230,7 +230,7 @@ static int modeset_init_intf(struct mdp5_kms *mdp5_kms, int 
intf_num)
struct msm_drm_private *priv = dev->dev_private;
const struct mdp5_cfg_hw *hw_cfg =
mdp5_cfg_get_hw_config(mdp5_kms->cfg);
-   enum mdp5_intf_type intf_type = hw_cfg->intfs[intf_num];
+   enum mdp5_intf_type intf_type = hw_cfg->intf.connect[intf_num];
struct drm_encoder *encoder;
int ret = 0;

@@ -367,7 +367,7 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
/* Construct encoders and modeset initialize connector devices
 * for each external display interface.
 */
-   for (i = 0; i <

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

Christian KÃ¶nig  changed:

   What|Removed |Added

 Attachment #115398|0   |1
is obsolete||
 CC||deathsimple at vodafone.de

--- Comment #41 from Christian KÃ¶nig  ---
Created attachment 115475
  --> https://bugs.freedesktop.org/attachment.cgi?id=115475=edit
More to test.

Interesting, attached is another patch you could test.

It just disables using UVD semaphores for now.

-- 
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/20150430/b5ace94b/attachment.html>

[PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal

2015-04-30 Thread Shobhit Kumar

On 04/29/2015 07:57 PM, Lee Jones wrote:
> On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> 
>> On some Intel SoC platforms, the panel enable/disable signals are
>> controlled by CRC PMIC. Add those control as a new GPIO in a lookup
>> table for gpio-crystalcove chip during CRC driver load
>>
>> v2: Make the lookup table static (Thierry)
>> Remove the lookup table during driver remove (Thierry)
>>
>> CC: Samuel Ortiz 
>> Cc: Linus Walleij 
>> Cc: Alexandre Courbot 
>> Cc: Thierry Reding 
>> Signed-off-by: Shobhit Kumar 
>> ---
>>  drivers/mfd/intel_soc_pmic_core.c | 17 +
>>  1 file changed, 17 insertions(+)
> 
> I have no idea what this stuff is, but it looks plausible.

The CRC PMIC controls the panel enable/disable signal using one of GPIO
like lines. It was agreed by Linus Walleij to go this way. The matching
crystalcove gpio changes are already merged in Linux next as -
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=e189ca56d91bbf1d3fe2f88ab6858bf919d42adf

This just adds a consumer lookup table for the gpio. Since we do not
have a DT or board files, and since this was part of CRC driver, just
added the lookup table during CRC driver load itself. Same is done for
PWM in a later patch.

Regards
Shobhit

> 
> For my own reference:
>   Acked-by: Lee Jones 
> 
>> diff --git a/drivers/mfd/intel_soc_pmic_core.c 
>> b/drivers/mfd/intel_soc_pmic_core.c
>> index 7b50b6b..f3d918e 100644
>> --- a/drivers/mfd/intel_soc_pmic_core.c
>> +++ b/drivers/mfd/intel_soc_pmic_core.c
>> @@ -24,8 +24,19 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "intel_soc_pmic_core.h"
>>  
>> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */
>> +static struct gpiod_lookup_table panel_gpio_table = {
>> +/* Intel GFX is consumer */
>> +.dev_id = ":00:02.0",
>> +.table = {
>> +/* Panel EN/DISABLE */
>> +GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH),
>> +},
>> +};
>> +
>>  static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>>  {
>>  struct gpio_desc *desc;
>> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
>>  if (ret)
>>  dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
>>  
>> +/* Add lookup table binding for Panel Control to the GPIO Chip */
>> +gpiod_add_lookup_table(_gpio_table);
>> +
>>  ret = mfd_add_devices(dev, -1, config->cell_dev,
>>config->n_cell_devs, NULL, 0,
>>regmap_irq_get_domain(pmic->irq_chip_data));
>> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client 
>> *i2c)
>>  
>>  regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data);
>>  
>> +/* Remove lookup table for Panel Control from the GPIO Chip */
>> +gpiod_remove_lookup_table(_gpio_table);
>> +
>>  mfd_remove_devices(>dev);
>>  
>>  return 0;
>

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

--- Comment #40 from Erik  ---
I got a black screen at the beggining, and console show this:

Radeon :01:05.0 ring 5 stalled for more than .secs

-- 
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/20150430/fb92aac9/attachment.html>

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

--- Comment #39 from Nicola Mori  ---
(In reply to Christian KÃ¶nig from comment #37)
> Created attachment 115398 [details] [review]
> Something to test
> 
> Just an idea I had recently what this issue could be. Please test the
> attached patch and see if it works or not.

The patch made things on my system even worse. Before, playing a movie with VLC
and VDPAU enabled resulted in random screen freezes after some time, while with
the patched kernel the freeze happens immediately as I start playing, all the
times.

Tested with Mobility Radeon HD3400 (RV620) on ArchLinux 64 bit with linux-ck
4.0.1, mesa 10.5.4, mesa-vdpau 10.5.4 and libvdpau 1.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/20150430/a1fb4212/attachment.html>

[PATCH] libgencec: Add userspace library for the generic CEC kernel interface

2015-04-30 Thread Kamil Debski

Hi Emil,

From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of Emil Velikov
Sent: Wednesday, April 29, 2015 5:00 PM
> 
> Hi Kamil,
> 
> Allow me to put a few suggestions:
> 
> On 29 April 2015 at 11:02, Kamil Debski  wrote:
> > This is the first version of the libGenCEC library. It was designed
> to
> > act as an interface between the generic CEC kernel API and userspace
> > applications. It provides a simple interface for applications and an
> > example application that can be used to test the CEC functionality.
> >
> > signed-off-by: Kamil Debski 
> > ---
> >  AUTHORS  |1 +
> >  INSTALL  |9 +
> >  LICENSE  |  202 
> >  Makefile.am  |4 +
> >  README   |   22 ++
> >  configure.ac |   24 ++
> >  doc/index.html   |  345 +++
> >  examples/Makefile.am |4 +
> >  examples/cectest.c   |  631
> ++
> >  include/gencec.h |  255 
> >  src/Makefile.am  |4 +
> >  src/gencec.c |  445 +++
> >  12 files changed, 1946 insertions(+)
> >  create mode 100644 AUTHORS
> >  create mode 100644 INSTALL
> >  create mode 100644 LICENSE
> >  create mode 100644 Makefile.am
> >  create mode 100644 README
> >  create mode 100644 configure.ac
> >  create mode 100644 doc/index.html
> >  create mode 100644 examples/Makefile.am  create mode 100644
> > examples/cectest.c  create mode 100644 include/gencec.h  create mode
> > 100644 m4/.gitkeep  create mode 100644 src/Makefile.am  create mode
> > 100644 src/gencec.c
> >
> > diff --git a/AUTHORS b/AUTHORS
> > new file mode 100644
> > index 000..e4b7117
> > --- /dev/null
> > +++ b/AUTHORS
> > @@ -0,0 +1 @@
> > +Kamil Debski 
> > diff --git a/INSTALL b/INSTALL
> > new file mode 100644
> > index 000..aac6101
> > --- /dev/null
> > +++ b/INSTALL
> > @@ -0,0 +1,9 @@
> > +To install libgencec run following commands:
> > +
> > +autoreconf -i
> You might want add --force in here, otherwise the files will stay as-is
> if you update libtool and friends "mid-flight".
> Many projects include autogen.sh like the following. Feel free to add
> it to libgencec.

Thanks, I'll include this in the next version.

> $cat autogen.sh
> #! /bin/sh
> 
> srcdir=`dirname "$0"`
> test -z "$srcdir" && srcdir=.
> 
> ORIGDIR=`pwd`
> cd "$srcdir"
> 
> autoreconf --force --verbose --install || exit 1 cd "$ORIGDIR" || exit
> $?
> 
> if test -z "$NOCONFIGURE"; then
> "$srcdir"/configure "$@"
> fi
> 
> 
> 
> > --- /dev/null
> > +++ b/configure.ac
> > @@ -0,0 +1,24 @@
> 
> You can save yourself some headaches if you restrict old and/or buggy
> autoconf versions which don't work with the project.
> If I have to guess 2.60 should be ok.
> AC_PREREQ([XXX])

Good suggestion, thanks.

> 
> > +AC_INIT([libgencec], [0.1], [k.debski at samsung.com])
> > +AM_INIT_AUTOMAKE([-Wall -Werror foreign])
> > +
> > +AC_PROG_CC
> > +AM_PROG_AR
> > +AC_CONFIG_MACRO_DIR([m4])
> > +AC_DEFINE([_GNU_SOURCE], [], [Use GNU extensions])
> > +
> 
> Same for libtool - 2.2 perhaps ?
> LT_PREREQ([XXX])

I agree.

> 
> > +LT_INIT
> > +
> > +# Checks for typedefs, structures, and compiler characteristics.
> > +AC_C_INLINE
> > +AC_TYPE_SIZE_T
> > +AC_TYPE_UINT16_T
> > +AC_TYPE_UINT32_T
> > +AC_TYPE_UINT8_T
> > +
> > +#AC_CHECK_LIB([c], [malloc])
> > +# Checks for library functions.
> > +#AC_FUNC_MALLOC
> > +l
> > +AC_CONFIG_FILES([Makefile src/Makefile examples/Makefile])
> Would be nice if the library provides libgencec.pc file. This way any
> users can avoid the explicit header/library check, amongst other useful
> bits.

Thanks for the suggestion, I'll look into this.

> > --- /dev/null
> > +++ b/examples/Makefile.am
> > @@ -0,0 +1,4 @@
> > +bin_PROGRAMS = cectest
> > +cectest_SOURCES = cectest.c
> > +AM_CPPFLAGS=-I$(top_srcdir)/include/
> > +AM_LDFLAGS=-L../src/ -lgencec
> The following seems more common (in the projects I've seen at least)
> cectest_LDADD = $(top_builddir)/src/libgencec.la
> 
> > diff --git a/m4/.gitkeep b/m4/.gitkeep new file mode 100644 index
> > 000..e69de29
> Haven't seen any projects doing this. Curious what the benefits of
> keeping and empty folder might be ?

When I run autoreconf -i it complained about missing m4 folder, hence I added
this filler file such that the folder is created. Any suggestion on how to do
this better?

> 
> > diff --git a/src/Makefile.am b/src/Makefile.am new file mode 100644
> > index 000..cb024f0
> > --- /dev/null
> > +++ b/src/Makefile.am
> > @@ -0,0 +1,4 @@
> > +lib_LTLIBRARIES = libgencec.la
> > +libgencec_la_SOURCES = gencec.c
> > +libgencec_la_LDFLAGS = -version-info 0:1:0
> You might want to add -no-undefined in order to prevent having a
> library with unresolved symbols.
> 
> Hope you find the above useful :-)

Thank you so much for your review. It is my first real approach at autotools,
so your

[Bug 69301] no screen on update from 3.12.0

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

Jan Outhuis  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #21 from Jan Outhuis  ---
I'm changing the status of this bug to 'resolved'. I've moved on to kernel 4.0.
And somewhere down the line from 3.13.0 to 4.0 the issue with radeon.dpm
disappeared. So I could remove Radeon.dpm=0 from the kernel commandline, I'm
not quite sure, but I would say since kernel 3.15.0.

Apparently the support for dpm got implemented in the Radeon_si video driver.
I'm on Debian 8 now.

Greetings
Jan

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

[Bug 95911] Recursive error in radeon device driver module after resume from hibernation

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

Christian KÃ¶nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #10 from Christian KÃ¶nig  ---
(In reply to Michel DÃ¤nzer from comment #8)
> Can you attach the kernel log from before and across suspend/resume as well?
> 
> Christian, any ideas?

Only possibility I can see is a bug in the BOs reference counting or a race
between closing the handle and suspending.

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

[PATCH] drm/msm/dsi: Fix a couple more 64-bit build warnings

2015-04-30 Thread Stephane Viau

Avoid such errors at compilation time:
format '%d' expects argument of type 'int', but argument 3 has type 
'size_t'

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index fdc54e3..1e3cd30 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1023,7 +1023,7 @@ static int dsi_short_read1_resp(u8 *buf, const struct 
mipi_dsi_msg *msg)
*data = buf[1]; /* strip out dcs type */
return 1;
} else {
-   pr_err("%s: read data does not match with rx_buf len %d\n",
+   pr_err("%s: read data does not match with rx_buf len %zu\n",
__func__, msg->rx_len);
return -EINVAL;
}
@@ -1040,7 +1040,7 @@ static int dsi_short_read2_resp(u8 *buf, const struct 
mipi_dsi_msg *msg)
data[1] = buf[2];
return 2;
} else {
-   pr_err("%s: read data does not match with rx_buf len %d\n",
+   pr_err("%s: read data does not match with rx_buf len %zu\n",
__func__, msg->rx_len);
return -EINVAL;
}
-- 
Qualcomm Innovation Center, Inc.

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

[Bug 95911] Recursive error in radeon device driver module after resume from hibernation

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #9 from gitne at excite.co.jp ---
(In reply to Michel DÃ¤nzer from comment #8)
> Can you attach the kernel log from before and across suspend/resume as well?

I can try but there seems to be nothing worth noting before resume. Is there
any kernel boot parameter or a radeon module parameter that I can tune to get a
more verbose kernel log? I'll try running on my latest F21 kernel version
3.19.5 but I doubt I'll see any improvement, judging by the changelog.

Best regards

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

[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-04-30 Thread Olof Johansson

On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas
 wrote:
> Hello Olof,
>
> On 04/30/2015 05:57 PM, Olof Johansson wrote:
>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman  wrote:
>>> Krzysztof Kozlowski  writes:
>>
>> This should fix issue reported by Javier [1][2].
>>
>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>> especially on other Exynos 5xxx products.
>
> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
> to linux-next or to Linus' master branch.
>
> Are there some other dependencies here?

 It is already applied:
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
>>>
>>> Er, yup.  That would explain it. ;)
>>>
>>> Sorry for the noise,
>>
>> Well, noise or not, Exynos is still broken in mainline and was broken
>> on -next for so long in different ways that bisecting it is a futile
>> exercise in frustration.
>>
>> It doesn't seem to show up with a trivial boot using only ramdisk, but
>> when booting a real distro from disk, it certainly does.
>>
>> For example:
>>
>> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html
>>
>> Disabling CONFIG_DRM makes it boot reliably.
>>
>> Arndale doesn't show it for me, but it also doesn't have working graphics.
>>
>
> Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix
> for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1
> power domain on Exynos5420" patch that was posted a long time ago. I have
> pinged Kukjin several times about this patch and he said that he will pick
> it this weekend [0].
>
> It is indeed very frustrating how many Exynos patches seems to be falling
> through the crack, even important fixes like these ones that allow boards
> to boot again.
>
> Kevin suggested that Krzysztof could collect and queue patches [1] to help
> Kukjin and start acting as a co-maintatiner which I think it's a very good
> idea and Krzysztof already did for some patches during the 4.1 cycle.

Yes, that's a much needed improvement. I suggest starting out by
collecting critical fixes like these, and we'd be happy to merge them
directly if going through Kukjin will add latency.

Krzysztof, if you can, make sure you get a PGP key setup and start
collecting signatures from kernel developers.


-Olof

[GIT PULL] drm/rockchip: fixes and be rockchip/drm maintainer

2015-04-30 Thread Heiko Stübner

Hi Dave,

Am Montag, 20. April 2015, 09:30:06 schrieb Mark yao:
> Hi Dave
>  I'm interesting to maintain the rockchip drm, so add entry for
> Rockchip drm.
>  and some fixes.

can you consider these as fixes for 4.1?


Thanks
Heiko


> 
>  Can you land them?
> 
> The following changes since commit aa219a0dd7774e2454a5687e7d38e947a131cdee:
> 
>Merge tag 'drm-intel-next-fixes-2015-04-15' of
> git://anongit.freedesktop.org/drm-intel into drm-next (2015-04-16
> 08:34:51 +1000)
> 
> are available in the git repository at:
> 
> 
>https://github.com/markyzq/kernel-drm-rockchip.git drm-next0420
> 
> for you to fetch changes up to 3ea68922fc4148abc97557df43d4ba9a136b1c8d:
> 
>drm/rockchip: fix error check when getting irq (2015-04-20 09:02:31
> +0800)
> 
> 
> Heiko Stuebner (2):
>MAINTAINERS: add entry for Rockchip drm drivers
>drm/rockchip: fix error check when getting irq
> 
>   MAINTAINERS |7 +++
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |9 +
>   2 files changed, 12 insertions(+), 4 deletions(-)

[Bug 95911] Recursive error in radeon device driver module after resume from hibernation

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 CC||christian.koenig at amd.com

--- Comment #8 from Michel DÃ¤nzer  ---
Can you attach the kernel log from before and across suspend/resume as well?

Christian, any ideas?

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

[Bug 66963] Rv6xx dpm problems

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

--- Comment #257 from Maciej Gluszek  ---
@Guram Savinov: I also tried setting DPM + high performance for my HD3650 and
it worked but the fan was still running too loud (not overheating just loud).

Then i installed Kernel 4.0, removed "high performance" settings and it works
great now. I still have DPM set during boot but no more setting the card to be
running on high performance. Couple of days and no lockups.

I'm on Ubuntu.

-- 
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/20150430/d38bf5cc/attachment.html>

[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-04-30 Thread Olof Johansson

On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman  wrote:
> Krzysztof Kozlowski  writes:
>
>> 2015-04-30 2:31 GMT+09:00 Kevin Hilman :
>>> Krzysztof Kozlowski  writes:
>>>
 After adding display power domain for Exynos5250 in commit
 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
 display on Chromebook Snow and others stopped working after boot.

 The reason for this suggested Andrzej Hajda: the DP clock was disabled.
 This clock is required by Display Port and is enabled by bootloader.
 However when FIMD driver probing was deferred, the display power domain
 was turned off. This effectively reset the value of DP clock enable
 register.

 When exynos-dp is later probed, the clock is not enabled and display is
 not properly configured:

 exynos-dp 145b.dp-controller: Timeout of video streamclk ok
 exynos-dp 145b.dp-controller: unable to config video

 Signed-off-by: Krzysztof Kozlowski 
 Reported-by: Javier Martinez Canillas 
 Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
 Cc: 

 ---

 This should fix issue reported by Javier [1][2].

 Tested on Chromebook Snow (Exynos 5250). More testing would be great,
 especially on other Exynos 5xxx products.
>>>
>>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>>> to linux-next or to Linus' master branch.
>>>
>>> Are there some other dependencies here?
>>
>> It is already applied:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc
>
> Er, yup.  That would explain it. ;)
>
> Sorry for the noise,

Well, noise or not, Exynos is still broken in mainline and was broken
on -next for so long in different ways that bisecting it is a futile
exercise in frustration.

It doesn't seem to show up with a trivial boot using only ramdisk, but
when booting a real distro from disk, it certainly does.

For example:

http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html

Disabling CONFIG_DRM makes it boot reliably.

Arndale doesn't show it for me, but it also doesn't have working graphics.

-Olof

[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-04-30 Thread Krzysztof Kozlowski

2015-04-30 2:31 GMT+09:00 Kevin Hilman :
> Krzysztof Kozlowski  writes:
>
>> After adding display power domain for Exynos5250 in commit
>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>> display on Chromebook Snow and others stopped working after boot.
>>
>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>> This clock is required by Display Port and is enabled by bootloader.
>> However when FIMD driver probing was deferred, the display power domain
>> was turned off. This effectively reset the value of DP clock enable
>> register.
>>
>> When exynos-dp is later probed, the clock is not enabled and display is
>> not properly configured:
>>
>> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
>> exynos-dp 145b.dp-controller: unable to config video
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> Reported-by: Javier Martinez Canillas 
>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>> Cc: 
>>
>> ---
>>
>> This should fix issue reported by Javier [1][2].
>>
>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>> especially on other Exynos 5xxx products.
>
> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
> to linux-next or to Linus' master branch.
>
> Are there some other dependencies here?

It is already applied:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc

Best regards,
Krzysztof

[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-04-30 Thread Kevin Hilman

Krzysztof Kozlowski  writes:

> 2015-04-30 2:31 GMT+09:00 Kevin Hilman :
>> Krzysztof Kozlowski  writes:
>>
>>> After adding display power domain for Exynos5250 in commit
>>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
>>> display on Chromebook Snow and others stopped working after boot.
>>>
>>> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
>>> This clock is required by Display Port and is enabled by bootloader.
>>> However when FIMD driver probing was deferred, the display power domain
>>> was turned off. This effectively reset the value of DP clock enable
>>> register.
>>>
>>> When exynos-dp is later probed, the clock is not enabled and display is
>>> not properly configured:
>>>
>>> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
>>> exynos-dp 145b.dp-controller: unable to config video
>>>
>>> Signed-off-by: Krzysztof Kozlowski 
>>> Reported-by: Javier Martinez Canillas 
>>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
>>> Cc: 
>>>
>>> ---
>>>
>>> This should fix issue reported by Javier [1][2].
>>>
>>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>>> especially on other Exynos 5xxx products.
>>
>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>> to linux-next or to Linus' master branch.
>>
>> Are there some other dependencies here?
>
> It is already applied:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc

Er, yup.  That would explain it. ;)

Sorry for the noise,

Kevin

[Bug 97561] New: Regression: Issue with ATI HD 6570 (possibly others) HDMI output Purple Line

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

Bug ID: 97561
Summary: Regression: Issue with ATI HD 6570 (possibly others)
HDMI output Purple Line
Product: Drivers
Version: 2.5
Kernel Version: 4.0 and above
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri at kernel-bugs.osdl.org
Reporter: fr0 at bitservices.org.uk
Regression: No

Hi,

First ever kernel bug report so apologies for possibly getting it wrong. Both
Linux version 4.0 and 4.1-rc now display a vertical purple line on the far left
hand side of the screen. This only happens when using HDMI output and seems to
be related to HDMI audio.

Happens with MESA 10.5 and MESA 10.6 devel, happens on both Arch Linux and
Linux Mint (using a mainline kernel). Problem does NOT happen on Linux 3.19.3
and earlier.

Image of problem:

https://lh3.googleusercontent.com/-i_dXYiwJNBE/VUE1pbSid4I/Eus/uAfOCER4PSE/s912/IMG_20150429_203014.jpg

Very similar bug:

https://bugzilla.kernel.org/show_bug.cgi?id=43154 (resolved, but appears to be
happening again).

lspci:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks
PRO [Radeon HD 6570/7570/8550]

Giving this command resolves the problem - hence I think it is related to the
audio output part of the dri driver and is very similar to the bug linked too
above:

xrandr --output HDMI-0 --auto --set audio off

I am happy to provide logs of anything - please let me know what you need. I
don't want to take a wild guess and provide everything.

Thanks !

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

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #33 from George Cheban  ---
Sorry guys, made it hang up by opening player fullscreen and by grabbing it to
top of working space. For now can't even boot to any kernel because of "Minimal
Bash-like line editing is supported". Will try to bisect again T_T.

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

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #32 from George Cheban  ---
Created attachment 175331
  --> https://bugzilla.kernel.org/attachment.cgi?id=175331=edit
Screenshot

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

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #31 from George Cheban  ---
Compiled a new kernel v4.1: 
# git checkout -b v4.1
# git revert 1a81b94...
/* 30 minutes to find out how to quit from VIM :D */
# make oldconfig
# make -j3 && make modules_install && make install 
# reboot 

Working with 4.1.0-rc1+ about 5 hours. 
Tried everything: 
Full HD Videos on both monitors (1st Firefox, 2nd - Chrome, which is really
impressive, because Chrome in 90% of situations makes my system hang up) + 
compiling new kernel + downloading videos via browser + downloading via torrent
+ writing to flashdrive 10 gb of videos + playing video from another flash +
copying some files from 3rd flashdrive >>> All this in the same time. 
System works fine. Don't have any ideas how to make it hang up. 
Attaching screenshot for you to see. 

What to do next?

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

[Bug 90221] Triangle boundary artifact on Shadow Warrior game

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

--- Comment #1 from Michel DÃ¤nzer  ---
(In reply to Lucas from comment #0)
> Some special effects trigger a visible artifact on triangle primitive
> boundaries, probably, see screenshot attached.

Looks like bug 88642, which is fixed in current LLVM.


> Running with the following env var (otherwise the game is unplayable slow on
> current video settings):
> R600_DEBUG=sb

That environment variable has no effect with the radeonsi 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/20150430/4728a1d5/attachment.html>

[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

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

--- Comment #21 from Kevin  ---
Alright, so I think I did this correctly, but it did not help. This is what I
did...

cd ~/Downloads/llvm-3.6.0.src/
patch -p1 < ~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch 
cd ~/Downloads/llvm-cmake/
cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=prefix=/usr/local
~/Downloads/llvm-3.6.0.src/
make
sudo make install

Then I rebooted and ran Dota 2 and tried to view Morphling in the loadout
screen and my system froze the same as before. 

So I am thinking since Steam runs everything in 32-bit, that perhaps I need to
apply this patch somehow to lib32-llvm?

Sorry again for not knowing how to do this properly.

-- 
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/20150430/237fdb73/attachment.html>

[Bug 90221] Triangle boundary artifact on Shadow Warrior game

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Attachment #115419|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/20150430/2074d7f5/attachment.html>

[Bug 90202] Firefox nightly hangs with accelerated layers and latest r600 driver

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

--- Comment #6 from Michel DÃ¤nzer  ---
(In reply to Ernst SjÃ¶strand from comment #5)
> The backtraces are when using DRI2.

What do you mean by that? As you pointed out yourself in comment #3, that
backtrace is clearly from running with DRI3 enabled.

-- 
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/20150430/e66d0d5f/attachment.html>

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

2015-04-30 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #30 from Michel DÃ¤nzer  ---
Commit 1a81b94d4fc8470848eb80e39a6001c48cc3fc29 is specific to the c6x
architecture, so it can't be the cause of your problem. Looks like something
went wrong during the bisection. Most likely, you incorrectly declared a commit
as 'good' which was actually bad, because the problem doesn't happen every time
even with (some) bad commits.

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

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

--- Comment #38 from Erik  ---
I patched a 4.0.1 kernel on a Debian 8 for testing . i will test it with
several movies :)

-- 
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/20150430/e5e9e58f/attachment-0001.html>

[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

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

--- Comment #20 from Kevin  ---
OK, so I just realized this patch needs to be applied against llvm...so I have
downloaded 3.6.0 from http://llvm.org/releases/download.html#3.6.0 and applied
your patch. I am now attempting to compile.

$ patch -p1 <
~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch 
patching file lib/Target/R600/SIInstructions.td
Hunk #1 succeeded at 1809 (offset -86 lines).
Hunk #2 succeeded at 1867 (offset -86 lines).
patching file test/CodeGen/R600/llvm.AMDGPU.kill.ll
Hunk #1 succeeded at 15 (offset -1 lines).

-- 
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/20150430/313b929f/attachment.html>

[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

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

--- Comment #19 from Kevin  ---
OK, I now see that I am dumb and I typed -pl instead of p1. I downloaded
mesa-10.5.4.tar.gz from ftp://ftp.freedesktop.org/pub/mesa/10.5.4/ and unpacked
it. I then tried to patch but it seems the file needed is missing. Sorry for my
noobness, I am trying to learn. 

$ patch -p1 <
~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch 
can't find file to patch at input line 16
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|From 36d89bfaa834151adbc56315c771e1ba7fa12c7f Mon Sep 17 00:00:00 2001
|From: Tom Stellard 
|Date: Tue, 31 Mar 2015 17:52:24 +
|Subject: [PATCH] R600/SI: Add VCC as an implict def of SI_KILL
|
|When SI_KILL has a register operand, its lowered form writes to vcc.
|---
| lib/Target/R600/SIInstructions.td |  9 ++---
| test/CodeGen/R600/llvm.AMDGPU.kill.ll | 16 
| 2 files changed, 22 insertions(+), 3 deletions(-)
|
|diff --git a/lib/Target/R600/SIInstructions.td
b/lib/Target/R600/SIInstructions.td
|index 95b2470..d1db4ab 100644
|--- a/lib/Target/R600/SIInstructions.td
|+++ b/lib/Target/R600/SIInstructions.td
--
File to patch: ^C

-- 
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/20150430/41597b40/attachment-0001.html>

[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

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

--- Comment #18 from Kevin  ---
Tom, thank you for your help! I'm new to testing patches so this is what I did.
I am using Arch and used the mesa-git in the AUR to build mesa from git. I did
the following and got this message so I did not attempt to compile. 

cd ~/builds/mesa-git/src/mesa
$ patch -pl <
~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch 
patch:  strip count l is not a number

-- 
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/20150430/813c4c6b/attachment.html>

[Bug 90217] Counter Strike Global Offensive: GPU fault after a while