[PATCH] drm/usb: select USB_SUPPORT in Kconfig

[Sachin Kamat]

Hi Dave,

What is your opinion about this patch?

On 15 August 2012 01:27, Sascha Hauer  wrote:
> On Tue, Aug 14, 2012 at 05:12:22PM +0530, Sachin Kamat wrote:
>>
>> In general what you suggested seems to be the right thing to do.
>> However in this particular case, making this "depends on" creates
>> recursive dependencies
>> and probably that is the reason Dave Airlie decided to make it "select USB" 
>> (?)
>>
>
> Probably, yes. Trying to fix this resulted in a race through Kconfig
> entries throughout the kernel. Given that your patch is probably ok,
> though this should really be fixed properly.
>
> Sascha
>
> --
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |



-- 
With warm regards,
Sachin

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||kphillisjr at gmail.com

--- Comment #8 from Alex Deucher  2012-08-17 21:08:36 UTC 
---
*** Bug 53657 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DRM/V4L2 buffer sharing

[Mauro Carvalho Chehab]

Em 17-08-2012 18:01, Sylwester Nawrocki escreveu:
> Hi Laurent,
> 
> On 08/15/2012 11:09 PM, Laurent Pinchart wrote:
>> On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote:
>>> On 08/15/2012 12:06 AM, Laurent Pinchart wrote:
 On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote:
> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote:
>> This one requires more testing:
>>
>> May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API
>>http://patchwork.linuxtv.org/patch/11268  Sylwester Nawrocki
>> 
>
> Hmm, this is not valid any more. Tomasz just posted a new patch series
> that adds DMABUF importer and exporter feature altogether.
>
> [PATCHv8 00/26] Integration of videobuf2 with DMABUF
>
> I guess we need someone else to submit test patches for other H/W than
> just Samsung SoCs. I'm not sure if we've got enough resources to port
> this to other hardware. We have been using these features internally for
> some time already. It's been 2 kernel releases and I can see only Ack
> tags from Laurent on Tomasz's patch series, hence it seems there is no
> wide interest in DMABUF support in V4L2 and this patch series is probably
> going to stay in a fridge for another few kernel releases.

 What would be required to push it to v3.7 ?
>>>
>>> Mauro requested more test coverage on that, which is understood since this
>>> is a fairly important API enhancement and the V4L2 video overlay API
>>> replacement.
>>>
>>> We need DMABUF support added at some webcam driver and a DRM driver with
>>> prime support (or some V4L2 output driver), I guess it would be best to
>>> have that in a PC environment. It looks like i915/radeon/nouveau drivers
>>> already have prime support.
>>
>> uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can 
>> easily
>> test that, except that I have no idea how to export buffers on the i915 side
>> when X is running. Have you looked into that ?
> 
> All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop 
> with i915 driver, but in the running system drmModeGetResources() just fails 
> with EPERM. I've CCed dri-devel, so hopefully someone can shed some light
> on this.

Likely, you need to run with root permission to use it, or to write an Xorg
driver.

It is probably easier to get the V4L driver there, that uses the VIDIOC_OVERLAY
stuff, and make it work via DMABUF:
http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/

In order to test it, xawtv has already the code needed to talk with the v4l
plugin.

What the plugin does is to export the video board as a XV extension, accessible
via xawtv. It currently talks with the display card also via XV, but I believe 
it
won't be hard to port it to work with DMABUF.

As the interface between xawtv and the v4l plugin is just Xv, changing the code
there from VIDIOC_OVERLAY to DMABUF should be trivial.

Regards,
Mauro

[PATCH 13/13] drm/exynos: make sure that hardware overlay for hdmi is disabled

[Inki Dae]

the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   11 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |1 +
 drivers/gpu/drm/exynos/exynos_mixer.c|   13 +
 3 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 38250cb..6323cc8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -274,10 +274,21 @@ static void drm_mixer_disable(struct device *subdrv_dev, 
int zpos)
ctx->enabled[win] = false;
 }

+static void drm_mixer_wait_for_vblank(struct device *subdrv_dev)
+{
+   struct drm_hdmi_context *ctx = to_context(subdrv_dev);
+
+   DRM_DEBUG_KMS("%s\n", __FILE__);
+
+   if (mixer_ops && mixer_ops->wait_for_vblank)
+   mixer_ops->wait_for_vblank(ctx->mixer_ctx->client);
+}
+
 static struct exynos_drm_overlay_ops drm_hdmi_overlay_ops = {
.mode_set = drm_mixer_mode_set,
.commit = drm_mixer_commit,
.disable = drm_mixer_disable,
+   .wait_for_vblank = drm_mixer_wait_for_vblank,
 };

 static struct exynos_drm_manager hdmi_manager = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 237434d..93e8a2b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -67,6 +67,7 @@ struct exynos_mixer_ops {
void (*dpms)(void *ctx, int mode);

/* overlay */
+   void (*wait_for_vblank)(void *ctx);
void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
void (*win_commit)(void *ctx, int zpos);
void (*win_disable)(void *ctx, int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d3ff595..1ab5267 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -726,6 +726,18 @@ static void mixer_dpms(void *ctx, int mode)
}
 }

+static void mixer_wait_for_vblank(void *ctx)
+{
+   struct mixer_context *mixer_ctx = ctx;
+   struct mixer_resources *res = _ctx->mixer_res;
+   int ret;
+
+   ret = wait_for((mixer_reg_read(res, MXR_INT_STATUS) &
+   MXR_INT_STATUS_VSYNC), 50);
+   if (ret < 0)
+   DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
 static void mixer_win_mode_set(void *ctx,
  struct exynos_drm_overlay *overlay)
 {
@@ -818,6 +830,7 @@ static struct exynos_mixer_ops mixer_ops = {
.dpms   = mixer_dpms,

/* overlay */
+   .wait_for_vblank= mixer_wait_for_vblank,
.win_mode_set   = mixer_win_mode_set,
.win_commit = mixer_win_commit,
.win_disable= mixer_win_disable,
-- 
1.7.4.1

[PATCH 12/13] drm/exynos: fixed build warning

[Inki Dae]

the argument of drm_hdmi_mode_fixup function, struct drm_display_mode
should be declared as const.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index bced38e..38250cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -142,7 +142,7 @@ static void drm_hdmi_disable_vblank(struct device 
*subdrv_dev)

 static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
-- 
1.7.4.1

[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer

[Inki Dae]

this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   38 +++---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c |   12 
 drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
 4 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..bced38e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->is_connected)
-   return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
+   return hdmi_ops->is_connected(ctx->hdmi_ctx->client);

return false;
 }
@@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->get_edid)
-   return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx, connector, edid,
- len);
+   return hdmi_ops->get_edid(ctx->hdmi_ctx->client, connector,
+   edid, len);

return 0;
 }
@@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev, void 
*timing)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->check_timing)
-   return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
+   return hdmi_ops->check_timing(ctx->hdmi_ctx->client, timing);

return 0;
 }
@@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int mode)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->power_on)
-   return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
+   return hdmi_ops->power_on(ctx->hdmi_ctx->client, mode);

return 0;
 }
@@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device *subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (mixer_ops && mixer_ops->enable_vblank)
-   return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
+   return mixer_ops->enable_vblank(ctx->mixer_ctx->client,
manager->pipe);

return 0;
@@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device 
*subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (mixer_ops && mixer_ops->disable_vblank)
-   return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
+   return mixer_ops->disable_vblank(ctx->mixer_ctx->client);
 }

 static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
-   const struct drm_display_mode *mode,
+   struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
@@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->mode_fixup)
-   hdmi_ops->mode_fixup(ctx->hdmi_ctx->ctx, connector, mode,
+   hdmi_ops->mode_fixup(ctx->hdmi_ctx->client, connector, mode,
 adjusted_mode);
 }

@@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device *subdrv_dev, 
void *mode)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->mode_set)
-   hdmi_ops->mode_set(ctx->hdmi_ctx->ctx, mode);
+   hdmi_ops->mode_set(ctx->hdmi_ctx->client, mode);
 }

 static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
@@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device 
*subdrv_dev,
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->get_max_resol)
-   hdmi_ops->get_max_resol(ctx->hdmi_ctx->ctx, width, height);
+   hdmi_ops->get_max_resol(ctx->hdmi_ctx->client, width, height);
 }

 static void drm_hdmi_commit(struct device *subdrv_dev)
@@ -182,7 +182,7 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (hdmi_ops && hdmi_ops->commit)
-   hdmi_ops->commit(ctx->hdmi_ctx->ctx);
+   hdmi_ops->commit(ctx->hdmi_ctx->client);
 }

 static void drm_hdmi_dpms(struct device *subdrv_dev, int mode)
@@ -192,10 +192,10 @@ static void drm_hdmi_dpms(struct device *subdrv_dev, int 
mode)
DRM_DEBUG_KMS("%s\n", __FILE__);

if (mixer_ops && mixer_ops->dpms)
-   mixer_ops->dpms(ctx->mixer_ctx->ctx, mode);
+   

[PATCH 10/13] drm/exynos: update crtc to plane safely

[Inki Dae]

if old_crtc isn't same as encoder->crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane->crtc should be set to new crtc(encoder->crtc)

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   59 +-
 1 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index a562a94..7bcace8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -44,6 +44,7 @@
  * @dpms: store the encoder dpms value.
  */
 struct exynos_drm_encoder {
+   struct drm_crtc *old_crtc;
struct drm_encoder  drm_encoder;
struct exynos_drm_manager   *manager;
int dpms;
@@ -106,22 +107,74 @@ exynos_drm_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
 }

+static void disable_plane_to_crtc(struct drm_device *dev,
+   struct drm_crtc *old_crtc,
+   struct drm_crtc *new_crtc)
+{
+   struct drm_plane *plane;
+
+   /*
+* if old_crtc isn't same as encoder->crtc then it means that
+* user changed crtc id to another one so the plane to old_crtc
+* should be disabled and plane->crtc should be set to new_crtc
+* (encoder->crtc)
+*/
+   list_for_each_entry(plane, >mode_config.plane_list, head) {
+   if (plane->crtc == old_crtc) {
+   /*
+* do not change below call order.
+*
+* plane->funcs->disable_plane call checks
+* if encoder->crtc is same as plane->crtc and if same
+* then overlay_ops->disable callback will be called
+* to diasble current hw overlay so plane->crtc should
+* have new_crtc because new_crtc was set to
+* encoder->crtc in advance.
+*/
+   plane->crtc = new_crtc;
+   plane->funcs->disable_plane(plane);
+   }
+   }
+}
+
 static void exynos_drm_encoder_mode_set(struct drm_encoder *encoder,
 struct drm_display_mode *mode,
 struct drm_display_mode *adjusted_mode)
 {
struct drm_device *dev = encoder->dev;
struct drm_connector *connector;
-   struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
-   struct exynos_drm_manager_ops *manager_ops = manager->ops;
+   struct exynos_drm_manager *manager;
+   struct exynos_drm_manager_ops *manager_ops;

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

list_for_each_entry(connector, >mode_config.connector_list, head) {
-   if (connector->encoder == encoder)
+   if (connector->encoder == encoder) {
+   struct exynos_drm_encoder *exynos_encoder;
+
+   exynos_encoder = to_exynos_encoder(encoder);
+
+   if (exynos_encoder->old_crtc != encoder->crtc &&
+   exynos_encoder->old_crtc) {
+
+   /*
+* disable a plane to old crtc and change
+* crtc of the plane to new one.
+*/
+   disable_plane_to_crtc(dev,
+   exynos_encoder->old_crtc,
+   encoder->crtc);
+   }
+
+   manager = exynos_drm_get_manager(encoder);
+   manager_ops = manager->ops;
+
if (manager_ops && manager_ops->mode_set)
manager_ops->mode_set(manager->dev,
adjusted_mode);
+
+   exynos_encoder->old_crtc = encoder->crtc;
+   }
}
 }

-- 
1.7.4.1

[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly

[Inki Dae]

this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd->handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   65 +++-
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   20 +++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
 4 files changed, 73 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
  * exynos specific framebuffer structure.
  *
  * @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
  * @exynos_gem_obj: array of exynos specific gem object containing a gem 
object.
  */
 struct exynos_drm_fb {
struct drm_framebuffer  fb;
+   unsigned intbuf_cnt;
struct exynos_drm_gem_obj   *exynos_gem_obj[MAX_FB_BUFFER];
 };

@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
.dirty  = exynos_drm_fb_dirty,
 };

+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+   unsigned int cnt)
+{
+   struct exynos_drm_fb *exynos_fb;
+
+   exynos_fb = to_exynos_fb(fb);
+
+   exynos_fb->buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+   struct exynos_drm_fb *exynos_fb;
+
+   exynos_fb = to_exynos_fb(fb);
+
+   return exynos_fb->buf_cnt;
+}
+
 struct drm_framebuffer *
 exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return _fb->fb;
 }

+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   unsigned int cnt = 0;
+
+   if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
+   return 2;
+
+   while (cnt != MAX_FB_BUFFER) {
+   if (!mode_cmd->handles[cnt])
+   break;
+   cnt++;
+   }
+
+   /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+   if (cnt == 2) {
+   /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+   if (mode_cmd->offsets[1] &&
+   mode_cmd->handles[0] == mode_cmd->handles[1])
+   cnt = 1;
+   }
+
+   return cnt;
+}
+
 static struct drm_framebuffer *
 exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
  struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
-   int nr;
int i;

DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
}

exynos_fb = to_exynos_fb(fb);
-   nr = exynos_drm_format_num_buffers(fb->pixel_format);
+   exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+
+   DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);

-   for (i = 1; i < nr; i++) {
+   for (i = 1; i < exynos_fb->buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd->handles[i]);
if (!obj) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h 
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 5082375..96262e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -28,19 +28,6 @@
 #ifndef _EXYNOS_DRM_FB_H_
 #define _EXYNOS_DRM_FB_H

-static inline int exynos_drm_format_num_buffers(uint32_t format)
-{
-   switch (format) {
-   case DRM_FORMAT_NV12:
-   case DRM_FORMAT_NV12MT:
-   return 2;
-   case DRM_FORMAT_YUV420:
-   return 3;
-   default:
-   return 1;
-   }
-}
-
 struct drm_framebuffer *
 exynos_drm_framebuffer_init(struct drm_device *dev,
struct 

[PATCH 08/13] drm/exynos: make sure that hardware overlay for fimd is disabled

[Inki Dae]

the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   17 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   10 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   12 
 3 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..00e4bdc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
 #define MAX_FB_BUFFER  4
 #define DEFAULT_ZPOS   -1

+#define _wait_for(COND, MS) ({ \
+   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS);   \
+   int ret__ = 0;  \
+   while (!(COND)) {   \
+   if (time_after(jiffies, timeout__)) {   \
+   ret__ = -ETIMEDOUT; \
+   break;  \
+   }   \
+   }   \
+   ret__;  \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
 struct drm_device;
 struct exynos_drm_overlay;
 struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
  * @commit: apply hardware specific overlay data to registers.
  * @enable: enable hardware specific overlay.
  * @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * dma transfer is completed.
  */
 struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+   void (*wait_for_vblank)(struct device *subdrv_dev);
 };

 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 7da5714..a562a94 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -399,4 +399,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder 
*encoder, void *data)

if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
+
+   /*
+* wait for vblank interrupt
+* - with iommu, the dma operation could induce page fault
+* when accessed to memory after gem buffer was released so
+* make sure that the dma operation is completed before releasing
+* the gem bufer.
+*/
+   if (overlay_ops->wait_for_vblank)
+   overlay_ops->wait_for_vblank(manager->dev);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0ec9d86..2378d80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int zpos)
win_data->enabled = false;
 }

+static void fimd_wait_for_vblank(struct device *dev)
+{
+   struct fimd_context *ctx = get_fimd_context(dev);
+   int ret;
+
+   ret = wait_for((__raw_readl(ctx->regs + VIDCON1) &
+   VIDCON1_VSTATUS_BACKPORCH), 50);
+   if (ret < 0)
+   DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
 static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.mode_set = fimd_win_mode_set,
.commit = fimd_win_commit,
.disable = fimd_win_disable,
+   .wait_for_vblank = fimd_wait_for_vblank,
 };

 static struct exynos_drm_manager fimd_manager = {
-- 
1.7.4.1

[PATCH 07/13] drm/exynos: control display power at connector module.

[Inki Dae]

it doesn't need that display power is controlled by encoder's dpms so
moves it into connector module so that the display power can be controlled
by connector's dpms propely.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   11 ++-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   21 -
 2 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 65acf0d..d2ac6ed 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -226,11 +226,20 @@ static struct drm_connector_helper_funcs 
exynos_connector_helper_funcs = {
.best_encoder   = exynos_drm_best_encoder,
 };

+static void exynos_drm_display_power(struct drm_encoder *encoder, int mode)
+{
+   struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
+   struct exynos_drm_display_ops *display_ops = manager->display_ops;
+
+   if (display_ops && display_ops->power_on)
+   display_ops->power_on(manager->dev, mode);
+}
+
 static void exynos_drm_connector_dpms(struct drm_connector *connector, int 
mode)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);

-   /* drm framework doesn't check NULL. */
+   exynos_drm_display_power(connector->encoder, mode);
 }

 static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 3dae250..7da5714 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -49,25 +49,6 @@ struct exynos_drm_encoder {
int dpms;
 };

-static void exynos_drm_display_power(struct drm_encoder *encoder, int mode)
-{
-   struct drm_device *dev = encoder->dev;
-   struct drm_connector *connector;
-   struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
-
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
-   if (connector->encoder == encoder) {
-   struct exynos_drm_display_ops *display_ops =
-   manager->display_ops;
-
-   DRM_DEBUG_KMS("connector[%d] dpms[%d]\n",
-   connector->base.id, mode);
-   if (display_ops && display_ops->power_on)
-   display_ops->power_on(manager->dev, mode);
-   }
-   }
-}
-
 static void exynos_drm_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
struct drm_device *dev = encoder->dev;
@@ -88,13 +69,11 @@ static void exynos_drm_encoder_dpms(struct drm_encoder 
*encoder, int mode)
case DRM_MODE_DPMS_ON:
if (manager_ops && manager_ops->apply)
manager_ops->apply(manager->dev);
-   exynos_drm_display_power(encoder, mode);
exynos_encoder->dpms = mode;
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
-   exynos_drm_display_power(encoder, mode);
exynos_encoder->dpms = mode;
break;
default:
-- 
1.7.4.1

[PATCH 06/13] drm/exynos: separeated fimd_power_on into some parts.

[Inki Dae]

this patch separetes fimd_power_on into fimd_activate and fimd_clock and
fimd_activate function will call fimd_clock to control fimd power and
vsync interrupt.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   60 --
 1 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 47396e1..0ec9d86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -747,16 +747,10 @@ static void fimd_clear_win(struct fimd_context *ctx, int 
win)
writel(val, ctx->regs + SHADOWCON);
 }

-static int fimd_power_on(struct fimd_context *ctx, bool enable)
+static int fimd_clock(struct fimd_context *ctx, bool enable)
 {
-   struct exynos_drm_subdrv *subdrv = >subdrv;
-   struct device *dev = subdrv->dev;
-
DRM_DEBUG_KMS("%s\n", __FILE__);

-   if (enable != false && enable != true)
-   return -EINVAL;
-
if (enable) {
int ret;

@@ -769,18 +763,31 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
clk_disable(ctx->bus_clk);
return ret;
}
+   } else {
+   clk_disable(ctx->lcd_clk);
+   clk_disable(ctx->bus_clk);
+   }

-   ctx->suspended = false;
+   return 0;
+}
+
+static int fimd_activate(struct fimd_context *ctx, bool enable)
+{
+   if (enable) {
+   int ret;
+   struct device *dev = ctx->subdrv.dev;
+
+   ret = fimd_clock(ctx, true);
+   if (ret < 0)
+   return ret;

/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, >irq_flags))
fimd_enable_vblank(dev);

-   fimd_apply(dev);
+   ctx->suspended = false;
} else {
-   clk_disable(ctx->lcd_clk);
-   clk_disable(ctx->bus_clk);
-
+   fimd_clock(ctx, false);
ctx->suspended = true;
}

@@ -930,15 +937,15 @@ static int fimd_suspend(struct device *dev)
 {
struct fimd_context *ctx = get_fimd_context(dev);

-   if (pm_runtime_suspended(dev))
-   return 0;
-
/*
 * do not use pm_runtime_suspend(). if pm_runtime_suspend() is
 * called here, an error would be returned by that interface
 * because the usage_count of pm runtime is more than 1.
 */
-   return fimd_power_on(ctx, false);
+   if (!pm_runtime_suspended(dev))
+   return fimd_activate(ctx, false);
+
+   return 0;
 }

 static int fimd_resume(struct device *dev)
@@ -950,8 +957,21 @@ static int fimd_resume(struct device *dev)
 * of pm runtime would still be 1 so in this case, fimd driver
 * should be on directly not drawing on pm runtime interface.
 */
-   if (!pm_runtime_suspended(dev))
-   return fimd_power_on(ctx, true);
+   if (pm_runtime_suspended(dev)) {
+   int ret;
+
+   ret = fimd_activate(ctx, false);
+   if (ret < 0)
+   return ret;
+
+   /*
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
+*/
+   fimd_apply(dev);
+   }

return 0;
 }
@@ -964,7 +984,7 @@ static int fimd_runtime_suspend(struct device *dev)

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

-   return fimd_power_on(ctx, false);
+   return fimd_activate(ctx, false);
 }

 static int fimd_runtime_resume(struct device *dev)
@@ -973,7 +993,7 @@ static int fimd_runtime_resume(struct device *dev)

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

-   return fimd_power_on(ctx, true);
+   return fimd_activate(ctx, true);
 }
 #endif

-- 
1.7.4.1

[PATCH 05/13] drm/exynos: removed exynos_drm_encoder_dpms call

[Inki Dae]

encoder's mode_set callback isn't specific to hardware so it doesn't
need to call exynos_drm_encoder_dpms().

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 2c037cd..3dae250 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -138,8 +138,6 @@ static void exynos_drm_encoder_mode_set(struct drm_encoder 
*encoder,

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

-   exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
-
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->encoder == encoder)
if (manager_ops && manager_ops->mode_set)
-- 
1.7.4.1

[PATCH 04/13] drm/exynos: use empty function instead of drm_helper_connector_dpms

[Inki Dae]

crtc and encoder's dpms callback will be called before connector's dpms
is called so drm_helper_connector_dpms doesn't need to be called.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index d956819..65acf0d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -226,6 +226,13 @@ static struct drm_connector_helper_funcs 
exynos_connector_helper_funcs = {
.best_encoder   = exynos_drm_best_encoder,
 };

+static void exynos_drm_connector_dpms(struct drm_connector *connector, int 
mode)
+{
+   DRM_DEBUG_KMS("%s\n", __FILE__);
+
+   /* drm framework doesn't check NULL. */
+}
+
 static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
unsigned int max_width, unsigned int max_height)
 {
@@ -285,7 +292,7 @@ static void exynos_drm_connector_destroy(struct 
drm_connector *connector)
 }

 static struct drm_connector_funcs exynos_connector_funcs = {
-   .dpms   = drm_helper_connector_dpms,
+   .dpms   = exynos_drm_connector_dpms,
.fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
-- 
1.7.4.1

[PATCH 03/13] drm/exynos: fixed page align bug.

[Inki Dae]

do not align in page unit at dumb creation. the align is done
by exynos_drm_gem_create() to be called commonly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index da4e3ca..a38051c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -662,7 +662,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
 */

args->pitch = args->width * ((args->bpp + 7) / 8);
-   args->size = PAGE_ALIGN(args->pitch * args->height);
+   args->size = args->pitch * args->height;

exynos_gem_obj = exynos_drm_gem_create(dev, args->flags, args->size);
if (IS_ERR(exynos_gem_obj))
-- 
1.7.4.1

[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.

[Inki Dae]

this patch separates sub driver's probe call and encoder/connector creation
so that exynos drm core module can take exception when some operation was
failed properly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |   93 +-
 1 files changed, 65 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@

 static LIST_HEAD(exynos_drm_subdrv_list);

-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
 {
struct drm_encoder *encoder;
struct drm_connector *connector;
+   int ret;

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

-   if (subdrv->probe) {
-   int ret;
-
-   /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
-   ret = subdrv->probe(dev, subdrv->dev);
-   if (ret)
-   return ret;
-   }
-
if (!subdrv->manager)
return 0;

@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
-   encoder->funcs->destroy(encoder);
-   return -EFAULT;
+   ret = -EFAULT;
+   goto err_destroy_encoder;
}

subdrv->encoder = encoder;
subdrv->connector = connector;

return 0;
+
+err_destroy_encoder:
+   encoder->funcs->destroy(encoder);
+   return ret;
 }

-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
 {
-   DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
-   if (subdrv->remove)
-   subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
 }

+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+   struct exynos_drm_subdrv *subdrv)
+{
+   if (subdrv->probe) {
+   int ret;
+
+   subdrv->drm_dev = dev;
+
+   /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+   ret = subdrv->probe(dev, subdrv->dev);
+   if (ret)
+   return ret;
+   }
+
+   if (!subdrv->manager)
+   return -EINVAL;
+
+   subdrv->manager->dev = subdrv->dev;
+
+   return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+   DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+   if (subdrv->remove)
+   subdrv->remove(dev, subdrv->dev);
+}
+
 int exynos_drm_device_register(struct drm_device *dev)
 {
struct exynos_drm_subdrv *subdrv, *n;
+   unsigned int fine_cnt = 0;
int err;

DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;

list_for_each_entry_safe(subdrv, n, _drm_subdrv_list, list) {
-   subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG("exynos drm subdrv probe failed.\n");
list_del(>list);
+   continue;
}
+
+   err = exynos_drm_create_enc_conn(dev, subdrv);
+   if (err) {
+   DRM_DEBUG("failed to create encoder and connector.\n");
+   exynos_drm_subdrv_remove(dev, subdrv);
+   list_del(>list);
+   continue;
+   }
+
+   fine_cnt++;
}

+   if (!fine_cnt)
+ 

[PATCH 01/13] drm/exynos: added device object to subdrv's remove callback as argument

[Inki Dae]

when remove callback of exynos_drm_subdrv is called, it could need
device object for sub driver to control things specific to hw such as
runtime pm.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e22704b..24c45d8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -266,7 +266,7 @@ struct exynos_drm_subdrv {
struct exynos_drm_manager *manager;

int (*probe)(struct drm_device *drm_dev, struct device *dev);
-   void (*remove)(struct drm_device *dev);
+   void (*remove)(struct drm_device *drm_dev, struct device *dev);
int (*open)(struct drm_device *drm_dev, struct device *dev,
struct drm_file *file);
void (*close)(struct drm_device *drm_dev, struct device *dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b19cd93..47396e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -678,7 +678,7 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return 0;
 }

-static void fimd_subdrv_remove(struct drm_device *drm_dev)
+static void fimd_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 537027a..f900da0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -466,7 +466,7 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return 0;
 }

-static void vidi_subdrv_remove(struct drm_device *drm_dev)
+static void vidi_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);

-- 
1.7.4.1

[PATCH 00/13] updated exynos-drm-fixes

[Inki Dae]

Hello all,

This patch set fixes the following:
. fixed page align
  - page align is done by exynos_drm_gem_create() so do not align
in page unit at exynos_drm_gem_dumb_create().
. removed unnecessary dpms call
  - encoder's mode_set callback isn't specific to hardware so
it doesn't need to call exynos_drm_encoder_dpms()
. control display power at connector module
  - it doesn't need that display power is controlled by encoder's dpms
so moves it into connector module so that the display power can be
controlled by connector's dpms properly.
. make sure that hardware overlay for fimd and hdmi is disabled
  - the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
. check NV12M format specific to Exynos properly
  - this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd->handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
. updated crtc to plane safely
  - if old_crtc isn't same as encoder->crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane->crtc should be set to new crtc(encoder->crtc)

And code clean like below:
. separated fimd_power_on into some parts
  - separated fimd_power_on into fimd_activate and fimd_clock functions
and fimd_activate function will call fimd_clock to control fimd power
and vsync interrupt.
. separated subdrv->probe call and encoder/connector creation
  - with this patch, exynos drm core module can take exception when some
operation was failed properly.
. changed context name of hdmi and mixer
  - changed ctx variable name in exynos_drm_hdmi_context structure to client
because the use of ctx variable name makes it confused.
. fixed build warning

Thanks.

Inki Dae (13):
  drm/exynos: added device object to subdrv's remove callback as
argument
  drm/exynos: separated subdrv->probe call and encoder/connector
creation.
  drm/exynos: fixed page align bug.
  drm/exynos: use empty function instead of drm_helper_connector_dpms
  drm/exynos: removed exynos_drm_encoder_dpms call
  drm/exynos: separeated fimd_power_on into some parts.
  drm/exynos: control display power at connector module.
  drm/exynos: make sure that hardware overlay for fimd is disabled
  drm/exynos: check NV12M format specific to Exynos properly
  drm/exynos: update crtc to plane safely
  drm/exynos: changed context name of hdmi and mixer
  drm/exynos: fixed build warning
  drm/exynos: make sure that hardware overlay for hdmi is disabled

 drivers/gpu/drm/exynos/exynos_drm_connector.c |   18 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   93 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   19 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   92 +---
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   65 -
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   20 ++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   74 ++--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   47 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |5 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   12 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c |   21 +-
 15 files changed, 349 insertions(+), 126 deletions(-)

-- 
1.7.4.1

[Intel-gfx] [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training

[Lespiau, Damien]

On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard  wrote:
> @@ -2324,6 +2324,8 @@ static void intel_fdi_normal_train(struct drm_crtc 
> *crtc)
> temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
> }
> I915_WRITE(reg, temp);
> +   POSTING_READ(reg);
> +   udelay(100);

The docs don't mention a delay between writing the TX and RX training
patterns, the POSTING_READ() seems like a good idea.

> reg = FDI_RX_CTL(pipe);
> temp = I915_READ(reg);
> @@ -2334,16 +2336,15 @@ static void intel_fdi_normal_train(struct drm_crtc 
> *crtc)
> temp &= ~FDI_LINK_TRAIN_NONE;
> temp |= FDI_LINK_TRAIN_NONE;
> }
> +   /* IVB wants error correction enabled */
> +   if (IS_IVYBRIDGE(dev))
> +   temp |= FDI_FS_ERRC_ENABLE | FDI_FE_ERRC_ENABLE;
> +
> I915_WRITE(reg, temp | FDI_RX_ENHANCE_FRAME_ENABLE);
>
> /* wait one idle pattern time */
> POSTING_READ(reg);
> udelay(1000);
> -
> -   /* IVB wants error correction enabled */
> -   if (IS_IVYBRIDGE(dev))
> -   I915_WRITE(reg, I915_READ(reg) | FDI_FS_ERRC_ENABLE |
> -  FDI_FE_ERRC_ENABLE);
>  }
>
>  static void cpt_phase_pointer_enable(struct drm_device *dev, int pipe)

Reviewed-by: Damien Lespiau 

-- 
Damien

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

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

--- Comment #30 from Kunal  2012-08-17 
18:11:43 UTC ---
Created attachment 65704
  --> https://bugs.freedesktop.org/attachment.cgi?id=65704
xorg log as of 17th Aug, 2012

xorg log for the same.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

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

--- Comment #29 from Kunal  2012-08-17 
18:11:08 UTC ---
Created attachment 65703
  --> https://bugs.freedesktop.org/attachment.cgi?id=65703
dmesg output as of 17th Aug., 2012.

dmesg output with the new kernel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

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

--- Comment #28 from Kunal  2012-08-17 
18:10:08 UTC ---
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > You might try the 5 patches starting with this one:
> > > http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html
> > 
> > On top of previous patche(s) (by Jerome)? or as separate set?
> 
> They apply on top of his patches.

No luck :(
It's still the same after applying those patches and rebuilding the kernel.

Attaching the xorg log and dmesg log after this.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: avoid turning off spread spectrum for used pll

[Jerome Glisse]

On Fri, Aug 17, 2012 at 2:54 PM, Alex Deucher  wrote:
> On Fri, Aug 17, 2012 at 2:40 PM,   wrote:
>> From: Jerome Glisse 
>>
>> If spread spectrum is enabled and in use for a given pll we
>> should not turn it off as it will lead to turning off display
>> for crtc that use the pll (this behavior was observed on chelsea
>> edp).
>>
>> Signed-off-by: Jerome Glisse 
>
> Looks good.  I think an alternative would be to just always enable SS
> for DP/eDP rather than checking the DPCD since all DP connections run
> on the same PLL.  IIRC, that's what the closed driver does.
>
> Reviewed-by: Alex Deucher 

Forgot cc stable

>
>> ---
>>  drivers/gpu/drm/radeon/atombios_crtc.c |   25 +
>>  1 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>> index c6fcb5b..cb18813 100644
>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> @@ -444,11 +444,28 @@ union atom_enable_ss {
>>  static void atombios_crtc_program_ss(struct radeon_device *rdev,
>>  int enable,
>>  int pll_id,
>> +int crtc_id,
>>  struct radeon_atom_ss *ss)
>>  {
>> +   unsigned i;
>> int index = GetIndexIntoMasterTable(COMMAND, 
>> EnableSpreadSpectrumOnPPLL);
>> union atom_enable_ss args;
>>
>> +   if (!enable) {
>> +   for (i = 0; i < 6; i++) {
>> +   if (rdev->mode_info.crtcs[i] &&
>> +   rdev->mode_info.crtcs[i]->enabled &&
>> +   i != crtc_id &&
>> +   pll_id == rdev->mode_info.crtcs[i]->pll_id) {
>> +   /* one other crtc is using this pll don't 
>> turn
>> +* off spread spectrum as it might turn off
>> +* display on active crtc
>> +*/
>> +   return;
>> +   }
>> +   }
>> +   }
>> +
>> memset(, 0, sizeof(args));
>>
>> if (ASIC_IS_DCE5(rdev)) {
>> @@ -1028,7 +1045,7 @@ static void atombios_crtc_set_pll(struct drm_crtc 
>> *crtc, struct drm_display_mode
>> radeon_compute_pll_legacy(pll, adjusted_clock, _clock, 
>> _div, _fb_div,
>>   _div, _div);
>>
>> -   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, 
>> );
>> +   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, 
>> radeon_crtc->crtc_id, );
>>
>> atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, 
>> radeon_crtc->pll_id,
>>   encoder_mode, radeon_encoder->encoder_id, 
>> mode->clock,
>> @@ -1051,7 +1068,7 @@ static void atombios_crtc_set_pll(struct drm_crtc 
>> *crtc, struct drm_display_mode
>> ss.step = step_size;
>> }
>>
>> -   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
>> radeon_crtc->pll_id, );
>> +   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
>> radeon_crtc->pll_id, radeon_crtc->crtc_id, );
>> }
>>  }
>>
>> @@ -1572,11 +1589,11 @@ void radeon_atom_disp_eng_pll_init(struct 
>> radeon_device *rdev)
>>
>> ASIC_INTERNAL_SS_ON_DCPLL,
>>
>> rdev->clock.default_dispclk);
>> if (ss_enabled)
>> -   atombios_crtc_program_ss(rdev, ATOM_DISABLE, 
>> ATOM_DCPLL, );
>> +   atombios_crtc_program_ss(rdev, ATOM_DISABLE, 
>> ATOM_DCPLL, -1, );
>> /* XXX: DCE5, make sure voltage, dispclk is high enough */
>> atombios_crtc_set_disp_eng_pll(rdev, 
>> rdev->clock.default_dispclk);
>> if (ss_enabled)
>> -   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
>> ATOM_DCPLL, );
>> +   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
>> ATOM_DCPLL, -1, );
>> }
>>
>>  }
>> --
>> 1.7.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

[Matthew Garrett]

On Fri, Aug 17, 2012 at 12:56:31PM -0400, Alex Deucher wrote:
> > I guess we could leave it as is for now for -fixes and then switch it
> > use use the new exported symbol for -next?  Is it ok to export a new
> > symbol for -fixes?

I don't see why not, providing the ACPI people are happy with it.

> >> So, er, I had no clue how to clean up the return value of acpi_get_table
> >> - does this actually need to be cleaned up?  Or do you just get a
> >> pointer straight to the "real" ACPI table?
> >
> > Not sure on that.  Anyone know more about the acpi code?

Not sure what you're asking here - acpi_get_table returns acpi_status, 
not a pointer.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX

[Lespiau, Damien]

On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard  wrote:
> Doesn't make sense to disable in the other order.
>
> Signed-off-by: Keith Packard 
> ---
>  drivers/gpu/drm/i915/intel_display.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

I can't see anything in the docs about an order requirement for those.
Not sure why the other way does not make sense. Somehow disabling TX
before RX makes some sense to me (TX enabled without a ready RX looks
weird?, no data should flow as the pipe is shutdown at that point
anyway). Maybe it just does not matter?

Another detail is that disabling the PLLs seem to have an order in the
disabling sequence, TX, then RX.

I.  Disable CPU FDI Transmitter PLL
II. Disable PCH FDI Receiver PLL

-- 
Damien

[Intel-gfx] [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR

[Lespiau, Damien]

On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard  wrote:
> These should probably all look like
>
> enabled |= (1 << pipe)
>
> so that the intent is clear...
>
> Signed-off-by: Keith Packard 
> ---
>  drivers/gpu/drm/i915/intel_pm.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 94aabca..1a84425 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1815,7 +1815,7 @@ static void sandybridge_update_wm(struct drm_device 
> *dev)
> DRM_DEBUG_KMS("FIFO watermarks For pipe C -"
>   " plane %d, cursor: %d\n",
>   plane_wm, cursor_wm);
> -   enabled |= 3;
> +   enabled |= 4;
> }

Looks like a very good catch!

Reviewed-by: Damien Lespiau 

-- 
Damien

[PATCH V6 11/15] drm: Handle io prot correctly for MIPS

[Huacai Chen]

Signed-off-by: Huacai Chen 
Signed-off-by: Hongliang Tao 
Signed-off-by: Hua Yan 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_vm.c  |2 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..3f06166 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
vm_area_struct *vma)
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
-#elif defined(__sparc__) || defined(__arm__)
+#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
 #endif
return tmp;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..0df71ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
else
tmp = pgprot_noncached(tmp);
 #endif
-#if defined(__sparc__)
+#if defined(__sparc__) || defined(__mips__)
if (!(caching_flags & TTM_PL_FLAG_CACHED))
tmp = pgprot_noncached(tmp);
 #endif
-- 
1.7.7.3

[Intel-gfx] [PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear FDI_RX_IIR before training

[Lespiau, Damien]

On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard  wrote:
> Just a bit of cleanup; it appears to have no effect.
>
> Signed-off-by: Keith Packard 
> ---
>  drivers/gpu/drm/i915/intel_display.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Clearing the locking bit in FDI_RX_IIR looks like a good move and
waiting between tries can't hurt, looks good to me.

Reviewed-by: Damien Lespiau 

-- 
Damien

[Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge

[Lespiau, Damien]

On Fri, Aug 17, 2012 at 4:00 PM, Keith Packard  wrote:
>> I guess this does not cover the case of pipe B using 3 lanes meaning
>> pipe C can use 1?
>
> It didn't look like that was a supported mode from the docs.

Ah yes, found it now "FDI B maximum port width is 4 lanes when FDI C
is disabled, 2 lanes when FDI C is enabled."

>> This duplicates the code just that is just a few lines away, instead
>> how about moving the logic to set target_clock up in front of this
>> whole if()?
>
> It's not the same, it's the inverse -- computing bpp from lanes+clock
> clock instead of computing lanes from bpp+clock. But, yeah, it would be
> nice to have these merged somehow. I couldn't figure out a good way though.

I meant the

> +   if (is_dp)
> +   target_clock = mode->clock;
> +   else
> +   target_clock = adjusted_mode->clock;

Just after that else block you have

/* [e]DP over FDI requires target mode clock instead of link clock. */
if (edp_encoder)
target_clock = intel_edp_target_clock(edp_encoder, mode);
else if (is_dp)
target_clock = mode->clock;
else
target_clock = adjusted_mode->clock;

Those look strangely similar to me. The later could be moved up.

-- 
Damien

[Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX

[Keith Packard]

"Lespiau, Damien"  writes:

> I can't see anything in the docs about an order requirement for those.

Right, the docs don't say anything, which is a bit disconcerting.

> Not sure why the other way does not make sense. Somehow disabling TX
> before RX makes some sense to me (TX enabled without a ready RX looks
> weird?, no data should flow as the pipe is shutdown at that point
> anyway). Maybe it just does not matter?

And here I figured disabling RX before TX made more sense -- otherwise
the receiver wouldn't be seeing anything. In other areas of the driver,
we're careful to disable receivers before senders (disable CRTC before
PLL, etc).

> Another detail is that disabling the PLLs seem to have an order in the
> disabling sequence, TX, then RX.
>
> I.  Disable CPU FDI Transmitter PLL
> II. Disable PCH FDI Receiver PLL

That ordering doesn't matter as the FDI receiver and transmitter are
both disabled by that point, so they aren't talking at all.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120817/e4993471/attachment.pgp>

[RFC 3/5] video: panel: Add MIPI DBI bus support

[Laurent Pinchart]

Hi Tomi,

On Friday 17 August 2012 16:06:30 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 14:33 +0200, Laurent Pinchart wrote:
> > > But first, the data type should be byte, not unsigned long. How would
> > > you write 8 bits or 16 bits with your API?
> > 
> > u8 and u16 both fit in an unsigned long :-) Please see below.
> 
> Ah, I see, so the driver would just discard 24 bits or 16 bits from the
> ulong.

That's right.

> I somehow thought that if you have 8 bit bus, and you call the write with
> ulong, 4 bytes will be written.
> 
> > > Then again, I'd hope to have DCS somehow as a separate library, which
> > > would then use DBI/DSI/whatnot to actually send the data.
> > > 
> > > I'm not quite sure how easy that is because of the differences between
> > > the busses.
> > > 
> > > > Is DBI limited to 8-bit data transfers for commands ? Pixels can be
> > > > transferred 16-bit at a time, commands might as well. While DCS only
> > > > specifies 8-bit command/data, DBI panels that are not DCS compliant
> > > > can use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel,
> > > > does so).
> > > 
> > > I have to say I don't remember much about DBI =). Looking at OMAP's
> > > driver, which was made for omap2 and hasn't been much updated since, I
> > > see that there are 4 modes, 8/9/12/16 bits. I think that defines how
> > > many of the parallel data lines are used.
> > 
> > SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored
> > when transferring instructions and data other than pixels (for pixels the
> > 18-bits bus width can be used to transfer RGB666 in a single clock cycle).
> > 
> > See page 87 of
> > http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.
> > 
> > > However, I don't think that matters for the panel driver when it wants
> > > to send data. The panel driver should just call dbi_write(buf, buf_len),
> > > and the dbi driver would send the data in the buffer according to the
> > > bus width.
> > 
> > According to the DCS specification, commands and parameters are
> > transferred using 8-bit data. Non-DCS panels can however use wider
> > commands and parameters (all commands and parameters are 16-bits wide for
> > the R61505 for instance).
> > 
> > We can add an API to switch the DBI bus width on the fly. For Renesas
> > hardware this would "just" require shifting bits around to output the
> > 8-bit or 16-bit commands on the right data lines (the R61505 uses D17-D9
> > in 8-bit mode, while the DCS specification mentions D7-D0) based on how
> > the panel is connected and on which lines the panel expects data.
> > 
> > As commands can be expressed on either 8 or 16 bits I would use a 16 type
> > for them.
> 
> I won't put my head on the block, but I don't think DBI has any
> restriction on the size of the command. A "command" just means a data
> transfer while keeping the D/CX line low, and "data" when the line is
> high. Similar transfers for n bytes can be done in both modes.

Right. I'll see if the API could be simplified by having a single write 
callback function with a data/command parameter.

> > For parameters, we can either express everything as u8 * in the DBI bus
> > operations, or use a union similar to i2c_smbus_data
> > 
> > union i2c_smbus_data {
> > 
> > __u8 byte;
> > __u16 word;
> > __u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for
> > length */
> > 
> >/* and one more for user-space
> >compatibility */
> > 
> > };
> 
> There's no DBI_BLOCK_MAX, so at least identical union won't work. I
> think it's simplest to have u8 * function as a base, and then a few
> helpers to write the most common datatypes.

OK, that sounds good to me.

> So we could have on the lowest level something like:
> 
> dbi_write_command(u8 *buf, size_t size);
> dbi_write_data(u8 *buf, size_t size);
> 
> And possible helpers:
> 
> dbi_write_data(u8 *cmd_buf, size_t cmd_size, u8 *data_buf, size_t
> data_size);
> 
> dbi_write_dcs(u8 cmd, u8 *data, size_t size);
> 
> And variations:
> 
> dbi_write_dcs_0(u8 cmd);
> dbi_write_dcs_1(u8 cmd, u8 data);
> 
> etc. So a simple helper to send 16 bits would be:
> 
> dbi_write_data(u16 data)
> {
>   // or are the bytes the other way around...
>   u8 buf[2] = { data & 0xff, (data >> 8) & 0xff };
>   return dbi_write_data(buf, 2);
> }
> 
> > Helper functions would be available to perform 8-bit, 16-bit or n*8 bits
> > transfers.
> > 
> > Would that work for your use cases ?
> > 
> > > Also note that some chips need to change the bus width on the fly. The
> > > chip used on N800 wants configuration to be done with 8-bits, and pixel
> > > transfers with 16-bits. Who knows why...
> > 
> > On which data lines is configuration performed ? D7-D0 ?
> 
> I guess so, but does it matter? All the bus driver needs to know is how
> to send 8/16/.. bit data. On OMAP we just write the data to a 32 bit
> register, and 

[RFC 3/5] video: panel: Add MIPI DBI bus support

[Tomi Valkeinen]

 bit modes. I'm not sure what kind of shifting is needed for
those.

> > > We might just need to provide fake timings. Video mode timings are at the
> > > core of display support in all drivers so we can't just get rid of them.
> > > The h/v front/back porch and sync won't be used by display drivers for
> > > DBI/DSI panels anyway.
> > 
> > Right. But we should probably think if we can, at the panel level, easily
> > separate conventional panels and smart panels. Then this framework wouldn't
> > need to fake the timings, and it'd be up to the higher level to decide if
> > and how to fake them. Then again, this is no biggie. Just thought that at
> > the lowest level it'd be nice to be "correct" and leave faking to upper
> > layers =).
> 
> But we would then have two different APIs at the lower level depending on the 
> panel type. I'm not sure that's a good thing.

Different API for what? Why anyway need panel type specific functions.
In the panel struct we could just have an union of the different types
of parameters for different types of panels.

But if this complicates things, it's not a biggie. Just something that
has been in my mind when dealing with smart panels and assigning dummy
video timings for them =).

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120817/248c54c1/attachment.pgp>

3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

[Randy Dunlap]

On 08/17/2012 03:55 PM, Dave Airlie wrote:

> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie  wrote:
>> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap  
>> wrote:
>>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>>>
 for , we have verified cases on inteldrmfb, radeondrmfb, and
 cirrusdrmfb.

 This is the last message displayed before the system hangs.  This seems
 to be hitting a large number of users in Fedora, though certainly not
 everyone.  This started happening with the 3.5 updates, and is still an
 issue.  It appears to be a race condition, because various things have
 allowed boot to continue for some users, though there is no clear work
 around. Has anyone else run across this?  Any ideas.  For more
 background we have the following bugs:

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

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

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

 It should be noted that the conflicting fb hw usage message is not new,
 it has been around for a while, but this is the last message seen before
 the hang.
>>>
>>>
>>> Hi,  (adding dri-devel mailing list)
>>>
>>>
>>> I started seeing this problem on 3.5-rc6.
>>>
>>> AFAICT, the system is not actually hung, it's just that no output
>>> is showing up on the real (physical) output device (display) -- it's
>>> going somewhere else (or to the bit bucket).
>>>
>>
>> Can we bisect this at all?

I'll try.

>> I worry the intel one will bisect to where we moved the conflict
>> resolution earlier, but I'd like to see if applying that patch earlier
>> causes the issue, since radeon has it.
>>
>> I haven't reproduced this on any hw I own, I also can't get it under qemu.
> 
> I'm also wondering whether this grub2 related in some way, grub2 is
> starting to mess with the graphics adapter pointlessly.


I'm using lilo, not grub.

-- 
~Randy

[Intel-gfx] [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set

[Lespiau, Damien]

On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard  wrote:
> @@ -3845,8 +3836,20 @@ static bool intel_choose_pipe_bpp_dither(struct 
> drm_crtc *crtc,
>
> display_bpc = min(display_bpc, bpc);
>
> -   DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d)\n",
> - bpc, display_bpc);
> +   display_bpc = 6;

It seems that you are overriding display_bpc unconditionally here,
some left over from debugging?

> +   if (display_bpc * 3 > max_fdi_bpp) {
> +   if (max_fdi_bpp < 24)
> +   display_bpc = 6;
> +   else if (max_fdi_bpp < 30)
> +   display_bpc = 8;
> +   else if (max_fdi_bpp < 36)
> +   display_bpc = 10;
> +   DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
> +   }
> +
> +   DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d) 
> (max_fdi_bpp %d)\n",
> + bpc, display_bpc, max_fdi_bpp);
>
> *pipe_bpp = display_bpc * 3;

"setting pipe bpc to %d", bpc and  *pipe_bpp = display_bpc, looks like
a bogus debug message to me.

> @@ -4763,9 +4765,12 @@ static int ironlake_crtc_mode_set(struct drm_crtc 
> *crtc,
>  * Compute the available FDI bandwidth, use that
>  * to compute the maximum supported BPP
>  */
> -   fdi_bw = link_bw * max_lane * 19 / 20;
> -   max_fdi_bpp = fdi_bw / target_clock;
> -   DRM_DEBUG_KMS("max lane %d yields max fdi bpp %d\n", 
> max_lane, max_fdi_bpp);
> +   fdi_bw = (link_bw * 8) * max_lane;
> +   pps = target_clock * 21 / 20;
> +
> +   max_fdi_bpp = fdi_bw / pps;
> +   DRM_DEBUG_KMS("link_bw %d max_lane %d fdi_bw %u pps %u 
> max_fdi_bpp %d\n",
> + link_bw, max_lane, fdi_bw, pps, max_fdi_bpp);
> }

While I understood the first computation of max_fdi_bpp in patch 2 of
this series, I have to confess you lost me there. Would you mind
clarifying this?

-- 
Damien

[Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge

[Lespiau, Damien]

On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard  wrote:

@@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
  */
 static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
 unsigned int *pipe_bpp,
-struct drm_display_mode *mode)
+struct drm_display_mode *mode,
+int max_fdi_bpp)

There's some kernel-doc for this function, maybe add a @max_fdi_bpp there?


> @@ -3800,6 +3801,15 @@ static bool intel_choose_pipe_bpp_dither(struct 
> drm_crtc *crtc,
> display_bpc = 6;
> }
>
> +   if (display_bpc * 3 > max_fdi_bpp) {
> +   if (max_fdi_bpp < 24)
> +   display_bpc = 6;
> +   else if (max_fdi_bpp < 30)
> +   display_bpc = 8;
> +   else if (max_fdi_bpp < 36)
> +   display_bpc = 10;
> +   DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
> +   }

This chunk is being moved around in a later patch in the series,
merging the two patches in one looks like a good idea?


> +   /* If the other FDI link is using too many lanes, we can't have
> +* any
> +*/
> +   if (other_intel_crtc->fdi_lanes > 2)
> +   return 0;
> +
> +   /* When both are running, we only get 2 lanes at most
> +*/
> +   return 2;
> +}

I guess this does not cover the case of pipe B using 3 lanes meaning
pipe C can use 1?

> @@ -4672,7 +4731,18 @@ static int ironlake_crtc_mode_set(struct drm_crtc 
> *crtc,
>according to current link config */
> if (is_cpu_edp) {
> intel_edp_link_config(edp_encoder, , _bw);
> +   max_fdi_bpp = 0;
> +   max_lane = lane;
> } else {
> +   u32 fdi_bw;
> +
> +   /* [e]DP over FDI requires target mode clock
> +  instead of link clock */
> +   if (is_dp)
> +   target_clock = mode->clock;
> +   else
> +   target_clock = adjusted_mode->clock;
> +

This duplicates the code just that is just a few lines away, instead
how about moving the logic to set target_clock up in front of this
whole if()?

> /* FDI is a binary signal running at ~2.7GHz, encoding
>  * each output octet as 10 bits. The actual frequency
>  * is stored as a divider into a 100MHz clock, and the
> @@ -4681,6 +4751,18 @@ static int ironlake_crtc_mode_set(struct drm_crtc 
> *crtc,
>  * is:
>  */
> link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
> +
> +   max_lane = 4;
> +   if (IS_IVYBRIDGE(dev))
> +   max_lane = ivb_fdi_max_lanes(crtc);
> +
> +   /*
> +* Compute the available FDI bandwidth, use that
> +* to compute the maximum supported BPP
> +*/
> +   fdi_bw = link_bw * max_lane * 19 / 20;
> +   max_fdi_bpp = fdi_bw / target_clock;
> +   DRM_DEBUG_KMS("max lane %d yields max fdi bpp %d\n", 
> max_lane, max_fdi_bpp);
> }

This chunk is also reworked in a later commit in this series.

-- 
Damien

3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

[Randy Dunlap]

On 08/17/2012 03:25 PM, Justin M. Forbes wrote:

> for , we have verified cases on inteldrmfb, radeondrmfb, and
> cirrusdrmfb.
> 
> This is the last message displayed before the system hangs.  This seems
> to be hitting a large number of users in Fedora, though certainly not
> everyone.  This started happening with the 3.5 updates, and is still an
> issue.  It appears to be a race condition, because various things have
> allowed boot to continue for some users, though there is no clear work
> around. Has anyone else run across this?  Any ideas.  For more
> background we have the following bugs:
> 
> inteldrmfb:
> https://bugzilla.redhat.com/show_bug.cgi?id=843826
> 
> radeondrmfb:
> https://bugzilla.redhat.com/show_bug.cgi?id=845745
> 
> cirrusdrmfb :
> https://bugzilla.redhat.com/show_bug.cgi?id=843860
> 
> It should be noted that the conflicting fb hw usage message is not new,
> it has been around for a while, but this is the last message seen before
> the hang.


Hi,  (adding dri-devel mailing list)


I started seeing this problem on 3.5-rc6.

AFAICT, the system is not actually hung, it's just that no output
is showing up on the real (physical) output device (display) -- it's
going somewhere else (or to the bit bucket).

-- 
~Randy

[PATCH] drm: Remove two unused fields from struct drm_display_mode

[Damien Lespiau]

From: Damien Lespiau 

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_modes.c |3 ---
 include/drm/drm_crtc.h  |2 --
 2 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index b7adb4a..28637c1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -706,9 +706,6 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int 
adjust_flags)
p->crtc_vblank_end = max(p->crtc_vsync_end, p->crtc_vtotal);
p->crtc_hblank_start = min(p->crtc_hsync_start, p->crtc_hdisplay);
p->crtc_hblank_end = max(p->crtc_hsync_end, p->crtc_htotal);
-
-   p->crtc_hadjusted = false;
-   p->crtc_vadjusted = false;
 }
 EXPORT_SYMBOL(drm_mode_set_crtcinfo);

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a1a0386..ced3625 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -166,8 +166,6 @@ struct drm_display_mode {
int crtc_vsync_start;
int crtc_vsync_end;
int crtc_vtotal;
-   int crtc_hadjusted;
-   int crtc_vadjusted;

/* Driver private mode info */
int private_size;
-- 
1.7.7.5

[PATCH V3 2/2] video: drm: exynos: Add device tree support

[Leela Krishna Amudala]

Hello,

On Fri, Aug 17, 2012 at 6:55 AM, Joonyoung Shim  wrote:
> Hi,
>
> 2012/8/16 Leela Krishna Amudala :
>> Add device tree based discovery support for DRM-FIMD driver.
>>
>> Signed-off-by: Leela Krishna Amudala 
>> ---
>>  Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 
>> -
>>  2 files changed, 173 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
>>
>> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
>> b/Documentation/devicetree/bindings/fb/drm-fimd.txt
>> new file mode 100644
>> index 000..8ad8814
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
>> @@ -0,0 +1,80 @@
>> +* Samsung Display Controller using DRM frame work
>> +
>> +The display controller is used to transfer image data from memory to an
>> +external LCD driver interface. It supports various color formats such as
>> +rgb and yuv.
>> +
>> +Required properties:
>> + - compatible: Should be "samsung,exynos5-drm" for fimd using DRM frame 
>> work.
>
> Just use "samsung,exynos5-fb" and add to support exynos4-fb
>

In the first version of this patch set I used "samsung,exynos5-fb",
but as per Kyungmin Park's suggestion changed it to exynos5-drm.

>> + - reg: physical base address of the controller and length of memory
>> +   mapped region.
>> + - interrupts: Three interrupts should be specified. The interrupts should 
>> be
>> +   specified in the following order.
>> +   - VSYNC interrupt
>> +   - FIFO level interrupt
>> +   - FIMD System Interrupt
>> +
>> + - samsung,fimd-display: This property should specify the phandle of the
>> +   display device node which holds the video interface timing with the
>> +   below mentioned properties.
>> +
>> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
>> + horizontal timing includes four parameters in the following order.
>> +
>> + - horizontal back porch (in number of lcd clocks)
>> + - horizontal front porch (in number of lcd clocks)
>> + - hsync pulse width (in number of lcd clocks)
>> + - Display panels X resolution.
>> +
>> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
>> + vertical timing includes four parameters in the following order.
>> +
>> + - vertical back porch (in number of lcd lines)
>> + - vertical front porch (in number of lcd lines)
>> + - vsync pulse width (in number of lcd clocks)
>> + - Display panels Y resolution.
>> +
>> +
>> + - samsung,default-window: Specifies the default window number of the fimd 
>> controller.
>> +
>> + - samsung,fimd-win-bpp: Specifies the bits per pixel.
>> +
>> +Optional properties:
>> + - supports-mipi-panel: Specifies the lcd is mipi panel type
>
> How is this property used?
>
As this driver can be interfaced through MIPI or eDP, Arch side code
will check whether this property is available or not, if it is
available then it assumes mipi panel is connected and certain clock
rate will be set to fimd clock, otherwise assumes other panel is
connected and other clock rate will be set at arch side.

>> + - samsung,fimd-vidout-rgb: Video output format is RGB.
>> + - samsung,fimd-inv-vclk: invert video clock polarity.
>> + - samsung,fimd-frame-rate: Number of video frames per second.
>> +
>> +Example:
>> +
>> +   The following is an example for the fimd controller is split into
>> +   two portions. The SoC specific portion can be specified in the SoC
>> +   specific dts file. The board specific portion can be specified in the
>> +   board specific dts file.
>> +
>> +   - SoC Specific portion
>> +
>> +   fimd {
>> +   compatible = "samsung,exynos5-drm";
>> +   interrupt-parent = <>;
>> +   reg = <0x1440 0x4>;
>> +   interrupts = <18 5>, <18 4>, <18 6>;
>> +   };
>> +
>> +   - Board Specific portion
>> +
>> +   lcd_fimd0: lcd_panel0 {
>> +   lcd-htiming = <4 4 4 480>;
>> +   lcd-vtiming = <4 4 4 320>;
>> +   supports-mipi-panel;
>> +   };
>> +
>> +   fimd {
>> +   samsung,fimd-display = <_fimd0>;
>> +   samsung,fimd-vidout-rgb;
>> +   samsung,fimd-inv-vclk;
>> +   samsung,fimd-frame-rate = <60>;
>> +   samsung,default-window = <0>;
>> +   samsung,fimd-win-bpp = <32>;
>> +   };
>> +
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 8379c59..1753846 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -103,9 +104,18 @@ struct fimd_context {
>> struct exynos_drm_panel_info *panel;
>>  };
>>
>> +static const 

[PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd

[Leela Krishna Amudala]

Hello,

On Fri, Aug 17, 2012 at 6:18 AM, Joonyoung Shim  wrote:
>
> Hi Leela.
>
> 2012/8/16 Leela Krishna Amudala :
> > The name of the exynos drm fimd device is renamed to exynos-drm-fimd
> > and two device ids are created for exynos4-fb and exynos5-drm-fimd.
> > Also, added driver data for exynos5 to pick the fimd version at runtime
> > and
> > to choose the VIDTCON register offsets accordingly.
> >
> > Signed-off-by: Leela Krishna Amudala 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   56
> > +++---
> >  1 files changed, 51 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 24c0bd4..8379c59 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -57,6 +57,18 @@
> >
> >  #define get_fimd_context(dev)
> > platform_get_drvdata(to_platform_device(dev))
> >
> > +enum fimd_version_type {
> > +   VERSION_8, /* FIMD_VERSION8 */
> > +};
> > +
> > +struct drm_fimd_driver_data {
>
> Don't use drm_ prefix for code consistency.
>

Ok, I'll remove the drm_prefix

> > +   enum fimd_version_type fimd_ver;
>
> I don't prefer to check using version, it needs many if statement.
> Refer s3c-fb driver and how about use changed base address?
>
> struct fimd_driverdata {
>unsigned inttiming_base;
> };
>
> static struct fimd_driverdata exynos5_fimd_data = {
>.timing_base= 0x2,
> };
>

Ok, If I use the above structure as driver data for exynos5, then the
register write calls look this way

writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
[driver_data->timing_base = 0x2 in case of exynos5 and 0 in case
of exynos4]
and only one statement is enough for both exynos4 and exynos5.

I had put some effort for the patch set
http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html
that contains macro definitions for FIMD_V8_VIDCONX and is already
merged to kgene's for-next branch.
If I go with the approach that you suggested then these macros will not be used.

If other reviewers also accepted to use timing_base as driver data,
then will go for it other wise will keep the code same :) .

> > +};
> > +
> > +struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
> > +   .fimd_ver = VERSION_8,
> > +};
> > +
> >  struct fimd_win_data {
> > unsigned intoffset_x;
> > unsigned intoffset_y;
> > @@ -91,6 +103,13 @@ struct fimd_context {
> > struct exynos_drm_panel_info *panel;
> >  };
> >
> > +static inline struct drm_fimd_driver_data *drm_fimd_get_driver_data(
> > +   struct platform_device *pdev)
> > +{
> > +   return (struct drm_fimd_driver_data *)
> > +   platform_get_device_id(pdev)->driver_data;
> > +}
> > +
> >  static bool fimd_display_is_connected(struct device *dev)
> >  {
> > DRM_DEBUG_KMS("%s\n", __FILE__);
> > @@ -194,32 +213,47 @@ static void fimd_commit(struct device *dev)
> > struct fimd_context *ctx = get_fimd_context(dev);
> > struct exynos_drm_panel_info *panel = ctx->panel;
> > struct fb_videomode *timing = >timing;
> > +   struct drm_fimd_driver_data *driver_data;
> > +   struct platform_device *pdev = to_platform_device(dev);
> > u32 val;
> >
> > +   driver_data = drm_fimd_get_driver_data(pdev);
> > if (ctx->suspended)
> > return;
> >
> > DRM_DEBUG_KMS("%s\n", __FILE__);
> >
> > /* setup polarity values from machine code. */
> > -   writel(ctx->vidcon1, ctx->regs + VIDCON1);
> > +   if (driver_data->fimd_ver == VERSION_8)
> > +   writel(ctx->vidcon1, ctx->regs + FIMD_V8_VIDCON1);
> > +   else
> > +   writel(ctx->vidcon1, ctx->regs + VIDCON1);
> >
> > /* setup vertical timing values. */
> > val = VIDTCON0_VBPD(timing->upper_margin - 1) |
> >VIDTCON0_VFPD(timing->lower_margin - 1) |
> >VIDTCON0_VSPW(timing->vsync_len - 1);
> > -   writel(val, ctx->regs + VIDTCON0);
> > +   if (driver_data->fimd_ver == VERSION_8)
> > +   writel(val, ctx->regs + FIMD_V8_VIDTCON0);
> > +   else
> > +   writel(val, ctx->regs + VIDTCON0);
> >
> > /* setup horizontal timing values.  */
> > val = VIDTCON1_HBPD(timing->left_margin - 1) |
> >VIDTCON1_HFPD(timing->right_margin - 1) |
> >VIDTCON1_HSPW(timing->hsync_len - 1);
> > -   writel(val, ctx->regs + VIDTCON1);
> > +   if (driver_data->fimd_ver == VERSION_8)
> > +   writel(val, ctx->regs + FIMD_V8_VIDTCON1);
> > +   else
> > +   writel(val, ctx->regs + VIDTCON1);
> >
> > /* setup horizontal and vertical display size. */
> > val = VIDTCON2_LINEVAL(timing->yres - 1) |
> >VIDTCON2_HOZVAL(timing->xres - 1);
> > -   writel(val, ctx->regs + 

[PATCH] drm/radeon: avoid turning off spread spectrum for used pll

[Alex Deucher]

On Fri, Aug 17, 2012 at 2:54 PM, Alex Deucher  wrote:
> On Fri, Aug 17, 2012 at 2:40 PM,   wrote:
>> From: Jerome Glisse 
>>
>> If spread spectrum is enabled and in use for a given pll we
>> should not turn it off as it will lead to turning off display
>> for crtc that use the pll (this behavior was observed on chelsea
>> edp).
>>
>> Signed-off-by: Jerome Glisse 
>
> Looks good.  I think an alternative would be to just always enable SS
> for DP/eDP rather than checking the DPCD since all DP connections run
> on the same PLL.

On discrete cards anyway.  APUs are a little different, but the same idea holds.

Alex

[PATCH] drm/radeon: avoid turning off spread spectrum for used pll

[Alex Deucher]

On Fri, Aug 17, 2012 at 2:40 PM,   wrote:
> From: Jerome Glisse 
>
> If spread spectrum is enabled and in use for a given pll we
> should not turn it off as it will lead to turning off display
> for crtc that use the pll (this behavior was observed on chelsea
> edp).
>
> Signed-off-by: Jerome Glisse 

Looks good.  I think an alternative would be to just always enable SS
for DP/eDP rather than checking the DPCD since all DP connections run
on the same PLL.  IIRC, that's what the closed driver does.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/atombios_crtc.c |   25 +
>  1 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index c6fcb5b..cb18813 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -444,11 +444,28 @@ union atom_enable_ss {
>  static void atombios_crtc_program_ss(struct radeon_device *rdev,
>  int enable,
>  int pll_id,
> +int crtc_id,
>  struct radeon_atom_ss *ss)
>  {
> +   unsigned i;
> int index = GetIndexIntoMasterTable(COMMAND, 
> EnableSpreadSpectrumOnPPLL);
> union atom_enable_ss args;
>
> +   if (!enable) {
> +   for (i = 0; i < 6; i++) {
> +   if (rdev->mode_info.crtcs[i] &&
> +   rdev->mode_info.crtcs[i]->enabled &&
> +   i != crtc_id &&
> +   pll_id == rdev->mode_info.crtcs[i]->pll_id) {
> +   /* one other crtc is using this pll don't turn
> +* off spread spectrum as it might turn off
> +* display on active crtc
> +*/
> +   return;
> +   }
> +   }
> +   }
> +
> memset(, 0, sizeof(args));
>
> if (ASIC_IS_DCE5(rdev)) {
> @@ -1028,7 +1045,7 @@ static void atombios_crtc_set_pll(struct drm_crtc 
> *crtc, struct drm_display_mode
> radeon_compute_pll_legacy(pll, adjusted_clock, _clock, 
> _div, _fb_div,
>   _div, _div);
>
> -   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, 
> );
> +   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, 
> radeon_crtc->crtc_id, );
>
> atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, 
> radeon_crtc->pll_id,
>   encoder_mode, radeon_encoder->encoder_id, 
> mode->clock,
> @@ -1051,7 +1068,7 @@ static void atombios_crtc_set_pll(struct drm_crtc 
> *crtc, struct drm_display_mode
> ss.step = step_size;
> }
>
> -   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
> radeon_crtc->pll_id, );
> +   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
> radeon_crtc->pll_id, radeon_crtc->crtc_id, );
> }
>  }
>
> @@ -1572,11 +1589,11 @@ void radeon_atom_disp_eng_pll_init(struct 
> radeon_device *rdev)
>
> ASIC_INTERNAL_SS_ON_DCPLL,
>
> rdev->clock.default_dispclk);
> if (ss_enabled)
> -   atombios_crtc_program_ss(rdev, ATOM_DISABLE, 
> ATOM_DCPLL, );
> +   atombios_crtc_program_ss(rdev, ATOM_DISABLE, 
> ATOM_DCPLL, -1, );
> /* XXX: DCE5, make sure voltage, dispclk is high enough */
> atombios_crtc_set_disp_eng_pll(rdev, 
> rdev->clock.default_dispclk);
> if (ss_enabled)
> -   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
> ATOM_DCPLL, );
> +   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
> ATOM_DCPLL, -1, );
> }
>
>  }
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/5] Generic panel framework

[Tomi Valkeinen]

On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote:

> What kind of directory structure do you have in mind ? Panels are already 
> isolated in drivers/video/panel/ so we could already ditch the panel- prefix 
> in drivers.

The same directory also contains files for the framework and buses. But
perhaps there's no need for additional directories if the amount of
non-panel files is small. And you can easily see from the name that they
are not panel drivers (e.g. mipi_dbi_bus.c).

> Would you also create include/video/panel/ ?

Perhaps that would be good. Well, having all the files prefixed with
panel- is not bad as such, but just feel extra.

> > ---
> > 
> > Should we aim for DT only solution from the start? DT is the direction we
> > are going, and I feel the older platform data stuff would be deprecated
> > soon.
> 
> Don't forget about non-ARM architectures :-/ We need panel drivers for SH as 
> well, which doesn't use DT. I don't think that would be a big issue, a DT-
> compliant solution should be easy to use through board code and platform data 
> as well.

I didn't forget about them as I didn't even think about them ;). I
somehow had the impression that other architectures would also use DT,
sooner or later. I could be mistaken, though.

And true, it's not a big issue to support both DT and non-DT versions,
but I've been porting omap stuff for DT and keeping the old platform
data stuff also there, and it just feels burdensome. For very simple
panels it's easy, but when you've passing lots of parameters the code
starts to get longer.

> > This one would be rather impossible with the upper layer handling the
> > enabling of the video stream. Thus I see that the panel driver needs to
> > control the sequences, and the Sharp panel driver's enable would look
> > something like:
> > 
> > regulator_enable(...);
> > sleep();
> > dpi_enable_video();
> > sleep();
> > gpip_set(..);
> 
> I have to admit I have no better solution to propose at the moment, even if I 
> don't really like making the panel control the video stream. When several 
> devices will be present in the chain all of them might have similar annoying 
> requirements, and my feeling is that the resulting code will be quite messy. 
> At the end of the day the only way to really find out is to write an 
> implementation.

If we have a chain of devices, and each device uses the bus interface
from the previous device in the chain, there shouldn't be a problem. In
that model each device can handle the task however is best for it.

I think the problems come from the divided control we'll have. I mean,
if the panel driver would decide itself what to send to its output, and
it would provide the data (think of an i2c device), this would be very
simple. And it actually is for things like configuration data etc, but
not so for video stream.

> > It could cause some locking issues, though. First the panel's remove
> > could take a lock, but the remove sequence would cause the display
> > driver to call disable on the panel, which could again try to take the
> > same lock...
> 
> We have two possible ways of calling panel operations, either directly (panel-
> >bus->ops->enable(...)) or indirectly (panel_enable(...)).
> 
> The former is what V4L2 currently does with subdevs, and requires display 
> drivers to hold a reference to the panel. The later can do without a direct 
> reference only if we use a global lock, which is something I would like to 

Wouldn't panel_enable() just do the same panel->bus->ops->enable()
anyway, and both require a panel reference? I don't see the difference.

> avoid. A panel-wide lock wouldn't work, as the access function would need to 
> take the lock on a panel instance that can be removed at any time.

Can't this be handled with some kind of get/put refcounting? If there's
a ref, it can't be removed.

Generally about locks, if we define that panel ops may only be called
exclusively, does it simplify things? I think we can make such
requirements, as there should be only one display framework that handles
the panel. Then we don't need locking for things like enable/disable.

Of course we need to be careful about things where calls come from
"outside" the display framework. I guess one such thing is rmmod, but if
that causes a notification to the display framework, which again handles
locking, it shouldn't be a problem.

Another thing to be careful about is if the panel internally uses irqs,
workqueues, sysfs files or such. In that case it needs to handle
locking.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120817/f4ea6583/attachment.pgp>

[PATCH] drm/radeon: avoid turning off spread spectrum for used pll

[j.gli...@gmail.com]

From: Jerome Glisse 

If spread spectrum is enabled and in use for a given pll we
should not turn it off as it will lead to turning off display
for crtc that use the pll (this behavior was observed on chelsea
edp).

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |   25 +
 1 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index c6fcb5b..cb18813 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -444,11 +444,28 @@ union atom_enable_ss {
 static void atombios_crtc_program_ss(struct radeon_device *rdev,
 int enable,
 int pll_id,
+int crtc_id,
 struct radeon_atom_ss *ss)
 {
+   unsigned i;
int index = GetIndexIntoMasterTable(COMMAND, 
EnableSpreadSpectrumOnPPLL);
union atom_enable_ss args;

+   if (!enable) {
+   for (i = 0; i < 6; i++) {
+   if (rdev->mode_info.crtcs[i] &&
+   rdev->mode_info.crtcs[i]->enabled &&
+   i != crtc_id &&
+   pll_id == rdev->mode_info.crtcs[i]->pll_id) {
+   /* one other crtc is using this pll don't turn
+* off spread spectrum as it might turn off
+* display on active crtc
+*/
+   return;
+   }
+   }
+   }
+
memset(, 0, sizeof(args));

if (ASIC_IS_DCE5(rdev)) {
@@ -1028,7 +1045,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
radeon_compute_pll_legacy(pll, adjusted_clock, _clock, 
_div, _fb_div,
  _div, _div);

-   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, );
+   atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, 
radeon_crtc->crtc_id, );

atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, 
radeon_crtc->pll_id,
  encoder_mode, radeon_encoder->encoder_id, 
mode->clock,
@@ -1051,7 +1068,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
ss.step = step_size;
}

-   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
radeon_crtc->pll_id, );
+   atombios_crtc_program_ss(rdev, ATOM_ENABLE, 
radeon_crtc->pll_id, radeon_crtc->crtc_id, );
}
 }

@@ -1572,11 +1589,11 @@ void radeon_atom_disp_eng_pll_init(struct radeon_device 
*rdev)
   
ASIC_INTERNAL_SS_ON_DCPLL,
   
rdev->clock.default_dispclk);
if (ss_enabled)
-   atombios_crtc_program_ss(rdev, ATOM_DISABLE, 
ATOM_DCPLL, );
+   atombios_crtc_program_ss(rdev, ATOM_DISABLE, 
ATOM_DCPLL, -1, );
/* XXX: DCE5, make sure voltage, dispclk is high enough */
atombios_crtc_set_disp_eng_pll(rdev, 
rdev->clock.default_dispclk);
if (ss_enabled)
-   atombios_crtc_program_ss(rdev, ATOM_ENABLE, ATOM_DCPLL, 
);
+   atombios_crtc_program_ss(rdev, ATOM_ENABLE, ATOM_DCPLL, 
-1, );
}

 }
-- 
1.7.1

[RFC 3/5] video: panel: Add MIPI DBI bus support

[Laurent Pinchart]

Hi Tomi,

On Friday 17 August 2012 13:51:49 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 12:02 +0200, Laurent Pinchart wrote:
> > On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
> > > On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > > > +/*
> > > > --
> > > > ---
> > > >  + * Bus operations
> > > > + */
> > > > +
> > > > +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned
> > > > long
> > > > cmd) +{
> > > > +   dev->bus->ops->write_command(dev->bus, cmd);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(panel_dbi_write_command);
> > > > +
> > > > +void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
> > > > data) +{
> > > > +   dev->bus->ops->write_data(dev->bus, data);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(panel_dbi_write_data);
> > > > +
> > > > +unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
> > > > +{
> > > > +   return dev->bus->ops->read_data(dev->bus);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(panel_dbi_read_data);
> > > 
> > > I'm not that familiar with how to implement bus drivers, can you
> > > describe in pseudo code how the SoC's DBI driver would register these?
> > 
> > Sure.
> > 
> > The DBI bus driver first needs to create a panel_dbi_bus_ops instance:
> > 
> > static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
> > 
> > .write_command = lcdc_dbi_write_command,
> > .write_data = lcdc_dbi_write_data,
> > .read_data = lcdc_dbi_read_data,
> > 
> > };
> 
> Thanks for the example, I think it cleared up things a bit.
> 
> As I mentioned earlier, I really think "panel" is not right here. While
> the whole framework may be called panel framework, the bus drivers are
> not panels, and we should support external chips also, which are not
> panels either.

I agree. I've renamed panel_dbi_* to mipi_dbi_*.

> > > I think write/read data functions are a bit limited. Shouldn't they be
> > > something like write_data(const u8 *buf, int size) and read_data(u8
> > > *buf, int len)?
> > 
> > Good point. My hardware doesn't support multi-byte read/write operations
> > directly so I haven't thought about adding those.
> 
> OMAP HW doesn't support it either. Well, not quite true, as OMAP's
> system DMA could be used to write a buffer to the DBI output. But that's
> really the same as doing the write with a a loop with CPU.
> 
> But first, the data type should be byte, not unsigned long. How would
> you write 8 bits or 16 bits with your API?

u8 and u16 both fit in an unsigned long :-) Please see below.

> And second, if the function takes just u8, you'd need lots of calls to do
> simple writes.

I agree, an array write function is a good idea.

> > Can your hardware group command + data writes in a single operation ? If
> > so we should expose that at the API level as well.
> 
> No it can't. But with DCS that is a common operation, so we could have
> some helpers to send command + data with one call.

Agreed.

> Then again, I'd hope to have DCS somehow as a separate library, which would
> then use DBI/DSI/whatnot to actually send the data.
> 
> I'm not quite sure how easy that is because of the differences between
> the busses.
> 
> > Is DBI limited to 8-bit data transfers for commands ? Pixels can be
> > transferred 16-bit at a time, commands might as well. While DCS only
> > specifies 8-bit command/data, DBI panels that are not DCS compliant can
> > use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel, does
> > so).
> 
> I have to say I don't remember much about DBI =). Looking at OMAP's
> driver, which was made for omap2 and hasn't been much updated since, I
> see that there are 4 modes, 8/9/12/16 bits. I think that defines how
> many of the parallel data lines are used.

SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored when 
transferring instructions and data other than pixels (for pixels the 18-bits 
bus width can be used to transfer RGB666 in a single clock cycle).

See page 87 of 
http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.

> However, I don't think that matters for the panel driver when it wants
> to send data. The panel driver should just call dbi_write(buf, buf_len),
> and the dbi driver would send the data in the buffer according to the
> bus width.

According to the DCS specification, commands and parameters are transferred 
using 8-bit data. Non-DCS panels can however use wider commands and parameters 
(all commands and parameters are 16-bits wide for the R61505 for instance).

We can add an API to switch the DBI bus width on the fly. For Renesas hardware 
this would "just" require shifting bits around to output the 8-bit or 16-bit 
commands on the right data lines (the R61505 uses D17-D9 in 8-bit mode, while 
the DCS specification mentions D7-D0) based on how the panel is connected and 
on which lines the panel expects data.

As commands can be 

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

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

--- Comment #27 from Alex Deucher  2012-08-17 14:21:26 UTC 
---
(In reply to comment #26)
> (In reply to comment #25)
> > You might try the 5 patches starting with this one:
> > http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html
> 
> On top of previous patche(s) (by Jerome)? or as separate set?

They apply on top of his patches.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

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

--- Comment #26 from Kunal  2012-08-17 
13:54:43 UTC ---
(In reply to comment #25)
> You might try the 5 patches starting with this one:
> http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html

On top of previous patche(s) (by Jerome)? or as separate set?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[RFC 3/5] video: panel: Add MIPI DBI bus support

[Tomi Valkeinen]

fficult (we only need to add timing 
> information to the panel platform data and add a function to the DBI API to 
> retrieve it), one of challenges might be to express it in a way that's both 
> universal enough and easy to use for DBI bus drivers.

As I pointed above, I think the panel driver shouldn't expose it, but
the panel driver should somehow set it. Or at least allowed to change it
in some manner. This is actually again, the same problem as with enable
and transfer: who controls what's going on.

How I think it should work is something like:

mipi_dbi_set_timings(dbi_dev, mytimings);
mipi_dbi_set_bus_width(dbi_dev, 8);
mipi_dbi_write(dbi_dev, ...);
mipi_dbi_set_bus_width(dbi_dev, 16);
start_frame_transfer(dbi_dev, ...);

> > And this makes me wonder, you use DBI bus for SYS-80 panel. The busses
> > may look similar in operation, but are they really so similar when you
> > take into account the timings (and perhaps something else, it's been
> > years since I read the MIPI DBI spec)?
> 
> I'll have to check all the details. SYS-80 is similar to DBI-B, but supports 
> a 
> wider bus width of 18 bits. I think the interfaces are similar enough to use 
> a 
> single bus implementation, possibly with quirks and/or options (see SCCB 
> support in I2C for instance, with flags to ignore acks, force a stop bit 
> generation, ...). We would duplicate lots of code if we had two different 
> implementations, and would prevent a DBI panel to be attached to a SYS-80 
> host 
> and vice-versa (the format is known to work).

Ah ok, if a DBI panel can be connected to SYS-80 output and vice versa,
then I agree they are similar enough.

> We might just need to provide fake timings. Video mode timings are at the 
> core 
> of display support in all drivers so we can't just get rid of them. The h/v 
> front/back porch and sync won't be used by display drivers for DBI/DSI panels 
> anyway.

Right. But we should probably think if we can, at the panel level,
easily separate conventional panels and smart panels. Then this
framework wouldn't need to fake the timings, and it'd be up to the
higher level to decide if and how to fake them. Then again, this is no
biggie. Just thought that at the lowest level it'd be nice to be
"correct" and leave faking to upper layers =).

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120817/71a139ee/attachment-0001.pgp>

[RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.

[Soby Mathew]

Hi Hans
 I didnt catch this sentence in the documentation of the API "It is
not possible to set part of an EDID, it is always all or nothing." .
Guess, I have to read the documentation thoroughly before making
assumptions. It makes my question irrelevant.

Best Regards
Soby Mathew



On Thu, Aug 16, 2012 at 11:25 PM, Soby Mathew  wrote:
> Hi Hans,
>For EDID update, it is recommended that the HPD line be toggled
> after the EDID update is completed. So for the driver to detect the
> EDID write is complete, probably a field mentioning the EDID write
> completed would be good, so that the HPD toggling can be done by the
> driver.
>
> Best Regards
> Soby Mathew
>

[RFC 0/5] Generic panel framework

[Laurent Pinchart]

Hi Tomi,

Thanks a lot for the review.

On Friday 17 August 2012 11:38:14 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > I will appreciate all reviews, comments, criticisms, ideas, remarks, ...
> > If
> 
> Oookay, where to start... ;)
> 
> A few cosmetic/general comments first.
> 
> I find the file naming a bit strange. You have panel.c, which is the
> core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which
> is driver for r61517 panel...
> 
> Perhaps something in this direction (in order): panel-core.c,
> mipi-dbi-bus.c, panel-r61517.c?

That looks good to me. I'll then rename panel_dbi_* to mipi_dbi_*.

> And we probably end up with quite a lot of panel drivers, perhaps we should
> already divide these into separate directories, and then we wouldn't need to
> prefix each panel with "panel-" at all.

What kind of directory structure do you have in mind ? Panels are already 
isolated in drivers/video/panel/ so we could already ditch the panel- prefix 
in drivers.

Would you also create include/video/panel/ ?

> ---
> 
> Should we aim for DT only solution from the start? DT is the direction we
> are going, and I feel the older platform data stuff would be deprecated
> soon.

Don't forget about non-ARM architectures :-/ We need panel drivers for SH as 
well, which doesn't use DT. I don't think that would be a big issue, a DT-
compliant solution should be easy to use through board code and platform data 
as well.

> ---
> 
> Something missing from the intro is how this whole thing should be used.
> It doesn't help if we know how to turn on the panel, we also need to
> display something on it =). So I think some kind of diagram/example of
> how, say, drm would use this thing, and also how the SoC specific DBI
> bus driver would be done, would clarify things.

Of course. If I had all that information already I would have shared it :-) 
This is really a first RFC, my goal is to make sure that I'm going in the 
right direction.

> ---
> 
> We have discussed face to face about the different hardware setups and
> scenarios that we should support, but I'll list some of them here for
> others:
> 
> 1) We need to support chains of external display chips and panels. A
> simple example is a chip that takes DSI in, and outputs DPI. In that
> case we'd have a chain of SoC -> DSI2DPI -> DPI panel.
> 
> In final products I think two external devices is the maximum (at least
> I've never seen three devices in a row), but in theory and in
> development environments the chain can be arbitrarily long. Also the
> connections are not necessarily 1-to-1, but a device can take one input
> while it has two outputs, or a device can take two inputs.
> 
> Now, I think two external devices is a must requirement. I'm not sure if
> supporting more is an important requirement. However, if we support two
> devices, it could be that it's trivial to change the framework to
> support n devices.
> 
> 2) Panels and display chips are all but standard. They very often have
> their own sequences how to do things, have bugs, or implement some
> feature in slightly different way than some other panel. This is why the
> panel driver should be able to control or define the way things happen.
> 
> As an example, Sharp LQ043T1DG01 panel
> (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with
> the following sequence:
> 
> - Enable VCC and AVDD regulators
> - Wait min 50ms
> - Enable full video stream (pck, syncs, pixels) from SoC
> - Wait min 0.5ms
> - Set DISP GPIO, which turns on the display panel
> 
> Here we could split the enabling of panel to two parts, prepare (in this
> case starts regulators and waits 50ms) and finish (wait 0.5ms and set
> DISP GPIO), and the upper layer would start the video stream in between.
> 
> I realize this could be done with the PANEL_ENABLE_* levels in your RFC,
> but I don't think the concepts quite match:
> 
> - PANEL_ENABLE_BLANK level is needed for "smart panels", as we need to
> configure them and send the initial frame at that operating level. With
> dummy panels there's really no such level, there's just one enable
> sequence that is always done right away.
> 
> - I find waiting at the beginning of a function very ugly (what are we
> waiting for?) and we'd need that when changing the panel to
> PANEL_ENABLE_ON level.
> 
> - It's still limited if the panel is a stranger one (see following
> example).
> 
> Consider the following theoretical panel enable example, taken to absurd
> level just to show the general problem:
> 
> - Enable regulators
> - Enable video stream
> - Wait 50ms
> - Disable video stream
> - Set enable GPIO
> - Enable video stream
> 
> This one would be rather impossible with the upper layer handling the
> enabling of the video stream. Thus I see that the panel driver needs to
> control the sequences, and the Sharp panel driver's enable would look
> something like:
> 
> regulator_enable(...);
> sleep();
> 

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

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

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

--- Comment #50 from Alex Deucher  2012-08-17 13:09:32 UTC 
---
Created attachment 65693
  --> https://bugs.freedesktop.org/attachment.cgi?id=65693
upstream 2/2

Second patch.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #65659|0   |1
is obsolete||

--- Comment #49 from Alex Deucher  2012-08-17 13:09:02 UTC 
---
Created attachment 65692
  --> https://bugs.freedesktop.org/attachment.cgi?id=65692
upstream 1/2

This set of stable patches will apply cleanly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)

[Alex Deucher]

Adding Matthew in case he as any ideas.

On Thu, Aug 16, 2012 at 3:51 PM, Alex Deucher  wrote:
> On Thu, Aug 16, 2012 at 3:40 PM, David Lamparter  
> wrote:
>> On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeucher at gmail.com wrote:
>>> From: David L 
>> From: David Lamparter 
>>
>> There are still two rough edges left in here, I didn't get around to
>> clean it up, other stuff came up -- sorry...
>>
>>> This is required for pure UEFI systems.  The vbios is stored
>>> in ACPI rather than at the legacy vga location.
>>>
>>> Fixes:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>>>
>>> V2: fix #ifdefs as per Greg's comments
>>>
>>> Signed-off-by: Alex Deucher 
>>> Cc: stable at vger.kernel.org
>>> ---
>> [...]
>>> + struct acpi_table_header *hdr;
>>> + /* acpi_get_table_with_size is not exported :( */
>>> + acpi_size tbl_size = 0x7fff;
>>
>> I was using acpi_get_table_with_size, but that needs an export, with
>> 0x7fff all the tests below are kinda useless because they always
>> succeed.  I think it'd be useful to keep the length checks in case some
>> vendor breaks their ACPI tables, so this needs an EXPORT_SYMBOL.
>
> I guess we could leave it as is for now for -fixes and then switch it
> use use the new exported symbol for -next?  Is it ok to export a new
> symbol for -fixes?
>
>>
>>> + UEFI_ACPI_VFCT *vfct;
>>> + GOP_VBIOS_CONTENT *vbios;
>>> + VFCT_IMAGE_HEADER *vhdr;
>>> +
>>> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, )))
>>> + return false;
>>> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
>>> + DRM_ERROR("ACPI VFCT table present but broken (too short 
>>> #1)\n");
>>> + goto out_unmap;
>>> + }
>>> +
>>> + vfct = (UEFI_ACPI_VFCT *)hdr;
>>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
>>> + DRM_ERROR("ACPI VFCT table present but broken (too short 
>>> #2)\n");
>>> + goto out_unmap;
>>> + }
>>> +
>>> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
>>> + vhdr = >VbiosHeader;
>>> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size 
>>> %d\n",
>>> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
>>> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
>>> +
>>> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
>>> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
>>> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
>>> + vhdr->VendorID != rdev->pdev->vendor ||
>>> + vhdr->DeviceID != rdev->pdev->device) {
>>> + DRM_INFO("ACPI VFCT table is not for this card\n");
>>> + goto out_unmap;
>>> + };
>>> +
>>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) + 
>>> vhdr->ImageLength > tbl_size) {
>>> + DRM_ERROR("ACPI VFCT image truncated\n");
>>> + goto out_unmap;
>>> + }
>>> +
>>> + rdev->bios = kmemdup(>VbiosContent, vhdr->ImageLength, 
>>> GFP_KERNEL);
>>> + ret = !!rdev->bios;
>>> +
>>> +out_unmap:
>>> + /* uh, no idea what to do here... */
>>
>> So, er, I had no clue how to clean up the return value of acpi_get_table
>> - does this actually need to be cleaned up?  Or do you just get a
>> pointer straight to the "real" ACPI table?
>
> Not sure on that.  Anyone know more about the acpi code?
>
> Alex

[PATCH] drm/udl: dpms off the crtc when disabled.

[Dave Airlie]

From: Dave Airlie 

This turns off the crtc when its been disabled,
fixes it not turning off properly the whole time.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/udl/udl_modeset.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index f5dd89e..9159d48 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -354,8 +354,7 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,

 static void udl_crtc_disable(struct drm_crtc *crtc)
 {
-
-
+   udl_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
 }

 static void udl_crtc_destroy(struct drm_crtc *crtc)
-- 
1.7.11.2

[RFC 3/5] video: panel: Add MIPI DBI bus support

[Tomi Valkeinen]

On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:

> +/* 
> -
> + * Bus operations
> + */
> +
> +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
> +{
> + dev->bus->ops->write_command(dev->bus, cmd);
> +}
> +EXPORT_SYMBOL_GPL(panel_dbi_write_command);
> +
> +void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long data)
> +{
> + dev->bus->ops->write_data(dev->bus, data);
> +}
> +EXPORT_SYMBOL_GPL(panel_dbi_write_data);
> +
> +unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
> +{
> + return dev->bus->ops->read_data(dev->bus);
> +}
> +EXPORT_SYMBOL_GPL(panel_dbi_read_data);

I'm not that familiar with how to implement bus drivers, can you
describe in pseudo code how the SoC's DBI driver would register these?


I think write/read data functions are a bit limited. Shouldn't they be
something like write_data(const u8 *buf, int size) and read_data(u8
*buf, int len)?

Something that's totally missing is configuring the DBI bus. There are a
bunch of timing related values that need to be configured. See
include/video/omapdss.h struct rfbi_timings. While the struct is OMAP
specific, if I recall right most of the values match to the MIPI DBI
spec.

And this makes me wonder, you use DBI bus for SYS-80 panel. The busses
may look similar in operation, but are they really so similar when you
take into account the timings (and perhaps something else, it's been
years since I read the MIPI DBI spec)?


Then there's the start_transfer. This is something I'm not sure what is
the best way to handle it, but the same problems that I mentioned in the
previous post related to enable apply here also. For example, what if
the panel needs to be update in two parts? This is done in Nokia N9.

[RFC 3/5] video: panel: Add MIPI DBI bus support

[Laurent Pinchart]

Hi Tomi,

Thank you for the review.

On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > +/*
> > -
> >  + * Bus operations
> > + */
> > +
> > +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long
> > cmd) +{
> > +   dev->bus->ops->write_command(dev->bus, cmd);
> > +}
> > +EXPORT_SYMBOL_GPL(panel_dbi_write_command);
> > +
> > +void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
> > data) +{
> > +   dev->bus->ops->write_data(dev->bus, data);
> > +}
> > +EXPORT_SYMBOL_GPL(panel_dbi_write_data);
> > +
> > +unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
> > +{
> > +   return dev->bus->ops->read_data(dev->bus);
> > +}
> > +EXPORT_SYMBOL_GPL(panel_dbi_read_data);
> 
> I'm not that familiar with how to implement bus drivers, can you
> describe in pseudo code how the SoC's DBI driver would register these?

Sure.

The DBI bus driver first needs to create a panel_dbi_bus_ops instance:

static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
.write_command = lcdc_dbi_write_command,
.write_data = lcdc_dbi_write_data,
.read_data = lcdc_dbi_read_data,
};

and a panel_dbi_bus instance, usually embedded in its private driver data 
structure, and initialize it by setting its dev and ops fields:

ch->dbi_bus.dev = ch->lcdc->dev;
ch->dbi_bus.ops = _mobile_lcdc_dbi_bus_ops;

In my current implementation, the panel_dbi_device is created in board code:

static struct panel_dbi_device migor_panel_device = {
.name   = "r61505",
.id = 0,
.dev= {
.platform_data  = _panel_info,
},
};

A pointer to that structure is passed to the DBI master driver, which then 
registers the device:

panel_dbi_device_register(dbi, >dbi_bus);

With a DT-based solution the DBI core will expose a function to register DBI 
devices from OF nodes.

The bus itself is currently not registered with the DBI code because there was 
no need to.

> I think write/read data functions are a bit limited. Shouldn't they be
> something like write_data(const u8 *buf, int size) and read_data(u8
> *buf, int len)?

Good point. My hardware doesn't support multi-byte read/write operations 
directly so I haven't thought about adding those.

Can your hardware group command + data writes in a single operation ? If so we 
should expose that at the API level as well.

Is DBI limited to 8-bit data transfers for commands ? Pixels can be 
transferred 16-bit at a time, commands might as well. While DCS only specifies 
8-bit command/data, DBI panels that are not DCS compliant can use 16-bit 
command/data (the R61505 panel, albeit a SYS-80 panel, does so).

> Something that's totally missing is configuring the DBI bus. There are a
> bunch of timing related values that need to be configured. See
> include/video/omapdss.h struct rfbi_timings. While the struct is OMAP
> specific, if I recall right most of the values match to the MIPI DBI
> spec.

I've left that out currently, and thought about passing that information as 
platform data to the DBI bus driver. That's the easiest solution, but I agree 
that it's a hack. Panel should expose their timing requirements to the DBI 
host. API wise that wouldn't be difficult (we only need to add timing 
information to the panel platform data and add a function to the DBI API to 
retrieve it), one of challenges might be to express it in a way that's both 
universal enough and easy to use for DBI bus drivers.

> And this makes me wonder, you use DBI bus for SYS-80 panel. The busses
> may look similar in operation, but are they really so similar when you
> take into account the timings (and perhaps something else, it's been
> years since I read the MIPI DBI spec)?

I'll have to check all the details. SYS-80 is similar to DBI-B, but supports a 
wider bus width of 18 bits. I think the interfaces are similar enough to use a 
single bus implementation, possibly with quirks and/or options (see SCCB 
support in I2C for instance, with flags to ignore acks, force a stop bit 
generation, ...). We would duplicate lots of code if we had two different 
implementations, and would prevent a DBI panel to be attached to a SYS-80 host 
and vice-versa (the format is known to work).

> Then there's the start_transfer. This is something I'm not sure what is
> the best way to handle it, but the same problems that I mentioned in the
> previous post related to enable apply here also. For example, what if
> the panel needs to be update in two parts? This is done in Nokia N9.
> From panel's perspective, it'd be best to handle it somewhat like this
> (although asynchronously, probably):
> 
> write_update_area(0, 0, xres, yres / 2);
> write_memory_start()
> start_pixel_transfer();
> 
> wait_transfer_done();
> 
> write_update_area(0, yres / 2, 

[RFC 0/5] Generic panel framework

[Tomi Valkeinen]

pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120817/2fd1cda9/attachment.pgp>

[PATCH v2 3/3] apple-gmux: Add display mux support

[Seth Forshee]

From: Andreas Heider 

Add support for the gmux display muxing functionality and register a mux
handler with vga_switcheroo.

Signed-off-by: Andreas Heider 
Signed-off-by: Seth Forshee 
---
 drivers/platform/x86/apple-gmux.c |  224 +
 1 file changed, 224 insertions(+)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index 612b6f6..c72e81e 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -2,6 +2,7 @@
  *  Gmux driver for Apple laptops
  *
  *  Copyright (C) Canonical Ltd. 
+ *  Copyright (C) 2010-2012 Andreas Heider 
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License version 2 as
@@ -19,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 

@@ -29,8 +32,17 @@ struct apple_gmux_data {
struct mutex index_lock;

struct backlight_device *bdev;
+
+   /* switcheroo data */
+   acpi_handle dhandle;
+   int gpe;
+   enum vga_switcheroo_client_id resume_client_id;
+   enum vga_switcheroo_state power_state;
+   struct completion powerchange_done;
 };

+static struct apple_gmux_data *apple_gmux_data;
+
 /*
  * gmux port offsets. Many of these are not yet used, but may be in the
  * future, and it's useful to have them documented here anyhow.
@@ -257,6 +269,146 @@ static const struct backlight_ops gmux_bl_ops = {
.update_status = gmux_update_status,
 };

+static int gmux_switchto(enum vga_switcheroo_client_id id)
+{
+   if (id == VGA_SWITCHEROO_IGD) {
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
+   } else {
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
+   gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
+   }
+
+   return 0;
+}
+
+static int gmux_set_discrete_state(struct apple_gmux_data *gmux_data,
+  enum vga_switcheroo_state state)
+{
+   INIT_COMPLETION(gmux_data->powerchange_done);
+
+   if (state == VGA_SWITCHEROO_ON) {
+   gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 1);
+   gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 3);
+   pr_debug("Discrete card powered up\n");
+   } else {
+   gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 1);
+   gmux_write8(gmux_data, GMUX_PORT_DISCRETE_POWER, 0);
+   pr_debug("Discrete card powered down\n");
+   }
+
+   gmux_data->power_state = state;
+
+   if (gmux_data->gpe >= 0 &&
+   
!wait_for_completion_interruptible_timeout(_data->powerchange_done,
+  msecs_to_jiffies(200)))
+   pr_warn("Timeout waiting for gmux switch to complete\n");
+
+   return 0;
+}
+
+static int gmux_set_power_state(enum vga_switcheroo_client_id id,
+   enum vga_switcheroo_state state)
+{
+   if (id == VGA_SWITCHEROO_IGD)
+   return 0;
+
+   return gmux_set_discrete_state(apple_gmux_data, state);
+}
+
+static int gmux_get_client_id(struct pci_dev *pdev)
+{
+   /*
+* Early Macbook Pros with switchable graphics use nvidia
+* integrated graphics. Hardcode that the 9400M is integrated.
+*/
+   if (pdev->vendor == PCI_VENDOR_ID_INTEL)
+   return VGA_SWITCHEROO_IGD;
+   else if (pdev->vendor == PCI_VENDOR_ID_NVIDIA &&
+pdev->device == 0x0863)
+   return VGA_SWITCHEROO_IGD;
+   else
+   return VGA_SWITCHEROO_DIS;
+}
+
+static enum vga_switcheroo_client_id
+gmux_active_client(struct apple_gmux_data *gmux_data)
+{
+   if (gmux_read8(gmux_data, GMUX_PORT_SWITCH_DISPLAY) == 2)
+   return VGA_SWITCHEROO_IGD;
+
+   return VGA_SWITCHEROO_DIS;
+}
+
+static struct vga_switcheroo_handler gmux_handler = {
+   .switchto = gmux_switchto,
+   .power_state = gmux_set_power_state,
+   .get_client_id = gmux_get_client_id,
+};
+
+static inline void gmux_disable_interrupts(struct apple_gmux_data *gmux_data)
+{
+   gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_ENABLE,
+   GMUX_INTERRUPT_DISABLE);
+}
+
+static inline void gmux_enable_interrupts(struct apple_gmux_data *gmux_data)
+{
+   gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_ENABLE,
+   GMUX_INTERRUPT_ENABLE);
+}
+
+static inline u8 gmux_interrupt_get_status(struct apple_gmux_data *gmux_data)
+{
+   return gmux_read8(gmux_data, GMUX_PORT_INTERRUPT_STATUS);
+}
+
+static void gmux_clear_interrupts(struct apple_gmux_data *gmux_data)
+{
+   u8 status;
+
+

[PATCH v2 2/3] vga_switcheroo: Remove assumptions about registration/unregistration ordering

[Seth Forshee]

vga_switcheroo assumes that the handler will be registered before the
last client, otherwise switching will not be enabled. Likewise it's
assumed that the handler will not be unregistered without at least one
client also being unregistered, otherwise switching will remain enabled
despite no longer having a handler. These assumptions cannot be enforced
if the handler is in a separate driver from both clients, as with the
gmux found in Apple laptops. Remove this assumption.

Signed-off-by: Seth Forshee 
---
 drivers/gpu/vga/vga_switcheroo.c |   58 +++---
 1 file changed, 36 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index ec9069d..e25cf31 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -70,27 +70,12 @@ static struct vgasr_priv vgasr_priv = {
.clients = LIST_HEAD_INIT(vgasr_priv.clients),
 };

-int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
-{
-   mutex_lock(_mutex);
-   if (vgasr_priv.handler) {
-   mutex_unlock(_mutex);
-   return -EINVAL;
-   }
-
-   vgasr_priv.handler = handler;
-   mutex_unlock(_mutex);
-   return 0;
-}
-EXPORT_SYMBOL(vga_switcheroo_register_handler);
-
-void vga_switcheroo_unregister_handler(void)
+static bool vga_switcheroo_ready(void)
 {
-   mutex_lock(_mutex);
-   vgasr_priv.handler = NULL;
-   mutex_unlock(_mutex);
+   /* we're ready if we get two clients + handler */
+   return !vgasr_priv.active &&
+  vgasr_priv.registered_clients == 2 && vgasr_priv.handler;
 }
-EXPORT_SYMBOL(vga_switcheroo_unregister_handler);

 static void vga_switcheroo_enable(void)
 {
@@ -114,6 +99,37 @@ static void vga_switcheroo_enable(void)
vgasr_priv.active = true;
 }

+int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler)
+{
+   mutex_lock(_mutex);
+   if (vgasr_priv.handler) {
+   mutex_unlock(_mutex);
+   return -EINVAL;
+   }
+
+   vgasr_priv.handler = handler;
+   if (vga_switcheroo_ready()) {
+   printk(KERN_INFO "vga_switcheroo: enabled\n");
+   vga_switcheroo_enable();
+   }
+   mutex_unlock(_mutex);
+   return 0;
+}
+EXPORT_SYMBOL(vga_switcheroo_register_handler);
+
+void vga_switcheroo_unregister_handler(void)
+{
+   mutex_lock(_mutex);
+   vgasr_priv.handler = NULL;
+   if (vgasr_priv.active) {
+   pr_info("vga_switcheroo: disabled\n");
+   vga_switcheroo_debugfs_fini(_priv);
+   vgasr_priv.active = false;
+   }
+   mutex_unlock(_mutex);
+}
+EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
+
 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
   int id, bool active)
@@ -135,9 +151,7 @@ static int register_client(struct pci_dev *pdev,
if (client_is_vga(client))
vgasr_priv.registered_clients++;

-   /* if we get two clients + handler */
-   if (!vgasr_priv.active &&
-   vgasr_priv.registered_clients == 2 && vgasr_priv.handler) {
+   if (vga_switcheroo_ready()) {
printk(KERN_INFO "vga_switcheroo: enabled\n");
vga_switcheroo_enable();
}
-- 
1.7.9.5

[PATCH v2 1/3] vga_switcheroo: Don't require handler init callback

[Seth Forshee]

This callback is a no-op in nouveau, and the upcoming apple-gmux
switcheroo support won't require it either. Rather than forcing drivers
to stub it out, just make it optional and remove the callback from
nouveau.

Signed-off-by: Seth Forshee 
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |6 --
 drivers/gpu/vga/vga_switcheroo.c   |3 ++-
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index fc841e8..26ebffe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -211,11 +211,6 @@ static int nouveau_dsm_power_state(enum 
vga_switcheroo_client_id id,
return nouveau_dsm_set_discrete_state(nouveau_dsm_priv.dhandle, state);
 }

-static int nouveau_dsm_init(void)
-{
-   return 0;
-}
-
 static int nouveau_dsm_get_client_id(struct pci_dev *pdev)
 {
/* easy option one - intel vendor ID means Integrated */
@@ -232,7 +227,6 @@ static int nouveau_dsm_get_client_id(struct pci_dev *pdev)
 static struct vga_switcheroo_handler nouveau_dsm_handler = {
.switchto = nouveau_dsm_switchto,
.power_state = nouveau_dsm_power_state,
-   .init = nouveau_dsm_init,
.get_client_id = nouveau_dsm_get_client_id,
 };

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 5b3c7d1..ec9069d 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -98,7 +98,8 @@ static void vga_switcheroo_enable(void)
struct vga_switcheroo_client *client;

/* call the handler to init */
-   vgasr_priv.handler->init();
+   if (vgasr_priv.handler->init)
+   vgasr_priv.handler->init();

list_for_each_entry(client, _priv.clients, list) {
if (client->id != -1)
-- 
1.7.9.5

[PATCH v2 0/3] Display switching support for Apple laptops

[Seth Forshee]

This series adds display switching support for Apple laptops. The first
two patches contain preparatory changes to vga_switcheroo, and the third
contains the changes to support display switching with the gmux.

While these patches will allow switching the display mux, most Macbook
owners will not be able to switch GPUs in practice until the graphics
drivers are updated to deal with missing or incorrect vbios information
on Apple machines. These patches do fix an issue seen by some users of
Linux on Macbooks, however. These users will switch to the internal GPU
in OS X and then reboot into Linux to save power, but after S3 the gmux
gets reset to the discrete GPU. Adding the display mux support will fix
this problem by restoring the gmux state during resume.

v2: Disable interrupts during suspend and re-enable them during resume
to fix timeouts waiting for switching to complete after S3

Thanks,
Seth


Andreas Heider (1):
  apple-gmux: Add display mux support

Seth Forshee (2):
  vga_switcheroo: Don't require handler init callback
  vga_switcheroo: Remove assumptions about registration/unregistration
ordering

 drivers/gpu/drm/nouveau/nouveau_acpi.c |6 -
 drivers/gpu/vga/vga_switcheroo.c   |   61 +
 drivers/platform/x86/apple-gmux.c  |  224 
 3 files changed, 262 insertions(+), 29 deletions(-)

[Bug 30102] [RADEON:KMS:RS780:CP] ring test failed

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




--- Comment #4 from Alan   2012-08-17 10:58:28 ---
If this is still seen with a modern kernel (3.2+ etc) please update/re-open

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 30052] [BISECTED]Fails to start X with intel+Ati video, whith modeset=1

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

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


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
Summary|Fails to start X with   |[BISECTED]Fails to start X
   |intel+Ati video, whith  |with intel+Ati video, whith
   |modeset=1   |modeset=1




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm/edid: limit printk when facing bad edid

[Jerome Glisse]

On Fri, Aug 17, 2012 at 3:01 AM, Jani Nikula
 wrote:
> On Thu, 16 Aug 2012, Jerome Glisse  wrote:
>> On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
>>  wrote:
>>>
>>> There's a bug [1] where the faster GMBUS transmissions fail with some
>>> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
>>> noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
>>> some measures to reduce the EDID error messages would be most welcome.
>>>
>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
>>> [2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912
>>>
>>> On Tue, 14 Aug 2012, Jerome Glisse  wrote:
 On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson  wrote:
> On 8/9/12 11:25 AM, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse 
>>
>> Limit printing bad edid information at one time per connector.
>> Connector that are connected to a bad monitor/kvm will likely
>> stay connected to the same bad monitor/kvm and it makes no
>> sense to keep printing the bad edid message.
>>>
>>> Do I understand correctly that bad_edid_counter is only reset when you
>>> reboot or reload the module? So if you have a laptop that you connect to
>>> the monitor at home, the monitor at the office, the projector in the
>>> meeting room, and to a TV somewhere else, etc, the message about bad
>>> EDID will only printed once? I don't think that's good. But please do
>>> correct me if I'm wrong.
>>
>> I wanted to reset the counter any time the connector is connected to
>> something with good edid but i did not do that in the end. I can do a
>> patch on top if you think it would be nicer. That way only thing with
>> bad edid will be printed once and assuming you don't repeatly
>> alternate btw good and bad edid device you would not get spam.
>
> IMHO this is, with or without the additional patch, overengineering the
> logic to print out error messages.
>
> For me, as a developer, this would be annoying because, to debug an EDID
> issue, I'd have to reload the module, connect to something with "good"
> EDID in between, or patch this out, to repeat a problem. I might have to
> ask a tester or a bug reporter to do the same.
>
> Also, in the referenced bug, the first problem with GMBUS would disable
> error messages, and the fallback retry with GPIO bit-banging would no
> longer produce messages even if that failed too.

If you set drm.debug=4 my patch will keep printing bad edid and
possibly spam your log. So it's not harder for developer. I restricted
the spamming to when some one is asking for debug.

>>
>>
>> Signed-off-by: Jerome Glisse 
>
>
> I guess.  I don't see why we don't just move it into DRM_DEBUG_KMS if 
> we're
> going to suppress it, but this does what it says on the box.
>
> Reviewed-by: Adam Jackson 
>
> - ajax
>

 I think there is still value in getting at least once the bad edid.
>>>
>>> I think the raw edid dumps should be DEBUG level no matter what. Perhaps
>>> some of the other messages could use WARNING/DEBUG too. And with that,
>>> and my comment above, I not sure there really needs to be all that logic
>>> to count errors and act differently further on.
>>>
>>
>> No, i do think we want bad edid as normal log at least once per
>> connector and we definitely don't want to spam bomb the log messages.
>
> Well, at least we agree on silencing the dmesg here. ;)
>
> I'd be happy with very simply adjusting the loglevel of the messages, so
> that I can also very simply adjust the amount of messages I get. Or ask
> a bug reported to do drm.debug=0xe instead of trying to ensure they
> follow a bunch of steps in between. But I'm not going to bikeshed
> further if others think the patch here is the way to go.
>

The patch aim was mostly with server where we dont want to spam bomb
error log but where we still want to be able to get bad edid without
having to ask for a reboot which on server is very much appreciated.

Cheers,
Jerome

[RFC 0/5] Generic panel framework

[Jingoo Han]

On Friday, August 17, 2012 9:50 AM Laurent Pinchart wrote:
> 
> Hi everybody,
> 
> While working on DT bindings for the Renesas Mobile SoC display controller
> (a.k.a. LCDC) I quickly realized that display panel implementation based on
> board code callbacks would need to be replaced by a driver-based panel
> framework.
> 
> Several driver-based panel support solution already exist in the kernel.
> 
> - The LCD device class is implemented in drivers/video/backlight/lcd.c and
>   exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
>   API for historical reason, uses board code callback for reset and power
>   management, and doesn't include support for standard features available in
>   today's "smart panels".
> 
> - OMAP2+ based systems use custom panel drivers available in
>   drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
>   controller) specific APIs.
> 
> - Similarly, Exynos based systems use custom panel drivers available in
>   drivers/video/exynos. Only a single driver (s6e8ax0) is currently available.
>   That driver is based on Exynos display controller specific APIs and on the
>   LCD device class API.
> 

Hi Laurent,

I am a Exynos DP maintainer and Samsung FB maintainer.

Actually, eDP (embedded display port) will be faced with this kind of problem.
According to the eDP standard, eDP panel can have their own specific registers
that handle extra operations. In this case, custom panel driver for this eDP 
panel
will be necessary.

In my opinion, the panel framework would be helpful to solve this problem.


Best regards,
Jingoo Han


> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus
> Lorentzon (working on panel support for ST/Linaro), and we agreed that a
> generic panel framework for display devices is needed. These patches implement
> a first proof of concept.
> 
> One of the main reasons for creating a new panel framework instead of adding
> missing features to the LCD framework is to avoid being tied to the FBDEV
> framework. Panels will be used by DRM drivers as well, and their API should
> thus be subsystem-agnostic. Note that the panel framework used the
> fb_videomode structure in its API, this will be replaced by a common video
> mode structure shared across subsystems (there's only so many hours per day).
> 
> Panels, as used in these patches, are defined as physical devices combining a
> matrix of pixels and a controller capable of driving that matrix.
> 
> Panel physical devices are registered as children of the control bus the panel
> controller is connected to (depending on the panel type, we can find platform
> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
> devices). The generic panel framework matches registered panel devices with
> panel drivers and call the panel drivers probe method, as done by other device
> classes in the kernel. The driver probe() method is responsible for
> instantiating a struct panel instance and registering it with the generic
> panel framework.
> 
> Display drivers are panel consumers. They register a panel notifier with the
> framework, which then calls the notifier when a matching panel is registered.
> The reason for this asynchronous mode of operation, compared to how drivers
> acquire regulator or clock resources, is that the panel can use resources
> provided by the display driver. For instance a panel can be a child of the DBI
> or DSI bus controlled by the display device, or use a clock provided by that
> device. We can't defer the display device probe until the panel is registered
> and also defer the panel device probe until the display is registered. As
> most display drivers need to handle output devices hotplug (HDMI monitors for
> instance), handling panel through a notification system seemed to be the
> easiest solution.
> 
> Note that this brings a different issue after registration, as display and
> panel drivers would take a reference to each other. Those circular references
> would make driver unloading impossible. I haven't found a good solution for
> that problem yet (hence the RFC state of those patches), and I would
> appreciate your input here. This might also be a hint that the framework
> design is wrong to start with. I guess I can't get everything right on the
> first try ;-)
> 
> Getting hold of the panel is the most complex part. Once done, display drivers
> can call abstract operations provided by panel drivers to control the panel
> operation. These patches implement three of those operations (enable, start
> transfer and get modes). More operations will be needed, and those three
> operations will likely get modified during review. Most of the panels on
> devices I own are dumb panels with no control bus, and are thus not the best
> candidates to design a framework that needs to take complex panels' needs into
> account.
> 
> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
> 

[PATCH V3 2/2] video: drm: exynos: Add device tree support

[Joonyoung Shim]

Hi,

2012/8/16 Leela Krishna Amudala :
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala 
> ---
>  Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 
> -
>  2 files changed, 173 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
>
> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
> b/Documentation/devicetree/bindings/fb/drm-fimd.txt
> new file mode 100644
> index 000..8ad8814
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
> @@ -0,0 +1,80 @@
> +* Samsung Display Controller using DRM frame work
> +
> +The display controller is used to transfer image data from memory to an
> +external LCD driver interface. It supports various color formats such as
> +rgb and yuv.
> +
> +Required properties:
> + - compatible: Should be "samsung,exynos5-drm" for fimd using DRM frame work.

Just use "samsung,exynos5-fb" and add to support exynos4-fb

> + - reg: physical base address of the controller and length of memory
> +   mapped region.
> + - interrupts: Three interrupts should be specified. The interrupts should be
> +   specified in the following order.
> +   - VSYNC interrupt
> +   - FIFO level interrupt
> +   - FIMD System Interrupt
> +
> + - samsung,fimd-display: This property should specify the phandle of the
> +   display device node which holds the video interface timing with the
> +   below mentioned properties.
> +
> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
> + horizontal timing includes four parameters in the following order.
> +
> + - horizontal back porch (in number of lcd clocks)
> + - horizontal front porch (in number of lcd clocks)
> + - hsync pulse width (in number of lcd clocks)
> + - Display panels X resolution.
> +
> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
> + vertical timing includes four parameters in the following order.
> +
> + - vertical back porch (in number of lcd lines)
> + - vertical front porch (in number of lcd lines)
> + - vsync pulse width (in number of lcd clocks)
> + - Display panels Y resolution.
> +
> +
> + - samsung,default-window: Specifies the default window number of the fimd 
> controller.
> +
> + - samsung,fimd-win-bpp: Specifies the bits per pixel.
> +
> +Optional properties:
> + - supports-mipi-panel: Specifies the lcd is mipi panel type

How is this property used?

> + - samsung,fimd-vidout-rgb: Video output format is RGB.
> + - samsung,fimd-inv-vclk: invert video clock polarity.
> + - samsung,fimd-frame-rate: Number of video frames per second.
> +
> +Example:
> +
> +   The following is an example for the fimd controller is split into
> +   two portions. The SoC specific portion can be specified in the SoC
> +   specific dts file. The board specific portion can be specified in the
> +   board specific dts file.
> +
> +   - SoC Specific portion
> +
> +   fimd {
> +   compatible = "samsung,exynos5-drm";
> +   interrupt-parent = <>;
> +   reg = <0x1440 0x4>;
> +   interrupts = <18 5>, <18 4>, <18 6>;
> +   };
> +
> +   - Board Specific portion
> +
> +   lcd_fimd0: lcd_panel0 {
> +   lcd-htiming = <4 4 4 480>;
> +   lcd-vtiming = <4 4 4 320>;
> +   supports-mipi-panel;
> +   };
> +
> +   fimd {
> +   samsung,fimd-display = <_fimd0>;
> +   samsung,fimd-vidout-rgb;
> +   samsung,fimd-inv-vclk;
> +   samsung,fimd-frame-rate = <60>;
> +   samsung,default-window = <0>;
> +   samsung,fimd-win-bpp = <32>;
> +   };
> +
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 8379c59..1753846 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -103,9 +104,18 @@ struct fimd_context {
> struct exynos_drm_panel_info *panel;
>  };
>
> +static const struct of_device_id drm_fimd_dt_match[];
> +

Please remove drm_ prefix over all.

>  static inline struct drm_fimd_driver_data *drm_fimd_get_driver_data(
> struct platform_device *pdev)
>  {
> +#ifdef CONFIG_OF
> +   if (pdev->dev.of_node) {
> +   const struct of_device_id *match;
> +   match = of_match_node(drm_fimd_dt_match, pdev->dev.of_node);

Use of_match_ptr().

> +   return (struct drm_fimd_driver_data *)match->data;
> +   }
> +#endif
> return (struct drm_fimd_driver_data *)
> platform_get_device_id(pdev)->driver_data;
>  }
> @@ -821,12 +831,79 @@ static int 

[Bug 53630] compiz + glamor = screen corruptions

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

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

--- Comment #5 from Thomas Rohloff  2012-08-17 10:25:00 
UTC ---
(In reply to comment #4)
> Does this still occur with the kernel fix from bug 45018?
Yes.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53630] compiz + glamor = screen corruptions

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

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

--- Comment #4 from Michel D?nzer  2012-08-17 10:10:45 
UTC ---
Does this still occur with the kernel fix from bug 45018?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

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

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

--- Comment #48 from gyhor at gmx.de 2012-08-17 10:09:17 UTC ---
(In reply to comment #46)
> Created attachment 65659 [details] [review]
> fix for all kernels
> 
> Here's the patch broken out which should apply to all recent kernels.

for kernel 3.5rc7 i needed additional this part in radeon_bios.c:
*** 32,37 
--- 32,40 

  #include 
  #include 
+ #ifdef CONFIG_ACPI
+ #include 
+ #endif
  /*
   * BIOS.
   */

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/edid: limit printk when facing bad edid

[Jani Nikula]

On Thu, 16 Aug 2012, Jerome Glisse  wrote:
> On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
>  wrote:
>>
>> There's a bug [1] where the faster GMBUS transmissions fail with some
>> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
>> noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
>> some measures to reduce the EDID error messages would be most welcome.
>>
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
>> [2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912
>>
>> On Tue, 14 Aug 2012, Jerome Glisse  wrote:
>>> On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson  wrote:
 On 8/9/12 11:25 AM, j.glisse at gmail.com wrote:
>
> From: Jerome Glisse 
>
> Limit printing bad edid information at one time per connector.
> Connector that are connected to a bad monitor/kvm will likely
> stay connected to the same bad monitor/kvm and it makes no
> sense to keep printing the bad edid message.
>>
>> Do I understand correctly that bad_edid_counter is only reset when you
>> reboot or reload the module? So if you have a laptop that you connect to
>> the monitor at home, the monitor at the office, the projector in the
>> meeting room, and to a TV somewhere else, etc, the message about bad
>> EDID will only printed once? I don't think that's good. But please do
>> correct me if I'm wrong.
>
> I wanted to reset the counter any time the connector is connected to
> something with good edid but i did not do that in the end. I can do a
> patch on top if you think it would be nicer. That way only thing with
> bad edid will be printed once and assuming you don't repeatly
> alternate btw good and bad edid device you would not get spam.

IMHO this is, with or without the additional patch, overengineering the
logic to print out error messages.

For me, as a developer, this would be annoying because, to debug an EDID
issue, I'd have to reload the module, connect to something with "good"
EDID in between, or patch this out, to repeat a problem. I might have to
ask a tester or a bug reporter to do the same.

Also, in the referenced bug, the first problem with GMBUS would disable
error messages, and the fallback retry with GPIO bit-banging would no
longer produce messages even if that failed too.

>
>
> Signed-off-by: Jerome Glisse 


 I guess.  I don't see why we don't just move it into DRM_DEBUG_KMS if we're
 going to suppress it, but this does what it says on the box.

 Reviewed-by: Adam Jackson 

 - ajax

>>>
>>> I think there is still value in getting at least once the bad edid.
>>
>> I think the raw edid dumps should be DEBUG level no matter what. Perhaps
>> some of the other messages could use WARNING/DEBUG too. And with that,
>> and my comment above, I not sure there really needs to be all that logic
>> to count errors and act differently further on.
>>
>
> No, i do think we want bad edid as normal log at least once per
> connector and we definitely don't want to spam bomb the log messages.

Well, at least we agree on silencing the dmesg here. ;)

I'd be happy with very simply adjusting the loglevel of the messages, so
that I can also very simply adjust the amount of messages I get. Or ask
a bug reported to do drm.debug=0xe instead of trying to ensure they
follow a bunch of steps in between. But I'm not going to bikeshed
further if others think the patch here is the way to go.


BR,
Jani.

[Bug 53630] compiz + glamor = screen corruptions

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

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

--- Comment #3 from Thomas Rohloff  2012-08-17 09:58:29 
UTC ---
Created attachment 65687
  --> https://bugs.freedesktop.org/attachment.cgi?id=65687
Compiz loading

As you see here (and at the screenshots) the colors are wrong, too (red to
blue, for example).
I tried to get the same corruption I described earlier, but was unable to do so
(well, it's basically the same but without the wrong colors).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53630] compiz + glamor = screen corruptions

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

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

--- Comment #2 from Thomas Rohloff  2012-08-17 09:55:05 
UTC ---
Created attachment 65685
  --> https://bugs.freedesktop.org/attachment.cgi?id=65685
Desktop with glamor (bad rendering)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53630] compiz + glamor = screen corruptions

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

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

--- Comment #1 from Thomas Rohloff  2012-08-17 09:53:47 
UTC ---
Created attachment 65683
  --> https://bugs.freedesktop.org/attachment.cgi?id=65683
Desktop without glamor (good rendering)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd

[Joonyoung Shim]

Hi Leela.

2012/8/16 Leela Krishna Amudala :
> The name of the exynos drm fimd device is renamed to exynos-drm-fimd
> and two device ids are created for exynos4-fb and exynos5-drm-fimd.
> Also, added driver data for exynos5 to pick the fimd version at runtime and
> to choose the VIDTCON register offsets accordingly.
>
> Signed-off-by: Leela Krishna Amudala 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   56 
> +++---
>  1 files changed, 51 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 24c0bd4..8379c59 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -57,6 +57,18 @@
>
>  #define get_fimd_context(dev)  platform_get_drvdata(to_platform_device(dev))
>
> +enum fimd_version_type {
> +   VERSION_8, /* FIMD_VERSION8 */
> +};
> +
> +struct drm_fimd_driver_data {

Don't use drm_ prefix for code consistency.

> +   enum fimd_version_type fimd_ver;

I don't prefer to check using version, it needs many if statement.
Refer s3c-fb driver and how about use changed base address?

struct fimd_driverdata {
   unsigned inttiming_base;
};

static struct fimd_driverdata exynos5_fimd_data = {
   .timing_base= 0x2,
};

> +};
> +
> +struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
> +   .fimd_ver = VERSION_8,
> +};
> +
>  struct fimd_win_data {
> unsigned intoffset_x;
> unsigned intoffset_y;
> @@ -91,6 +103,13 @@ struct fimd_context {
> struct exynos_drm_panel_info *panel;
>  };
>
> +static inline struct drm_fimd_driver_data *drm_fimd_get_driver_data(
> +   struct platform_device *pdev)
> +{
> +   return (struct drm_fimd_driver_data *)
> +   platform_get_device_id(pdev)->driver_data;
> +}
> +
>  static bool fimd_display_is_connected(struct device *dev)
>  {
> DRM_DEBUG_KMS("%s\n", __FILE__);
> @@ -194,32 +213,47 @@ static void fimd_commit(struct device *dev)
> struct fimd_context *ctx = get_fimd_context(dev);
> struct exynos_drm_panel_info *panel = ctx->panel;
> struct fb_videomode *timing = >timing;
> +   struct drm_fimd_driver_data *driver_data;
> +   struct platform_device *pdev = to_platform_device(dev);
> u32 val;
>
> +   driver_data = drm_fimd_get_driver_data(pdev);
> if (ctx->suspended)
> return;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> /* setup polarity values from machine code. */
> -   writel(ctx->vidcon1, ctx->regs + VIDCON1);
> +   if (driver_data->fimd_ver == VERSION_8)
> +   writel(ctx->vidcon1, ctx->regs + FIMD_V8_VIDCON1);
> +   else
> +   writel(ctx->vidcon1, ctx->regs + VIDCON1);
>
> /* setup vertical timing values. */
> val = VIDTCON0_VBPD(timing->upper_margin - 1) |
>VIDTCON0_VFPD(timing->lower_margin - 1) |
>VIDTCON0_VSPW(timing->vsync_len - 1);
> -   writel(val, ctx->regs + VIDTCON0);
> +   if (driver_data->fimd_ver == VERSION_8)
> +   writel(val, ctx->regs + FIMD_V8_VIDTCON0);
> +   else
> +   writel(val, ctx->regs + VIDTCON0);
>
> /* setup horizontal timing values.  */
> val = VIDTCON1_HBPD(timing->left_margin - 1) |
>VIDTCON1_HFPD(timing->right_margin - 1) |
>VIDTCON1_HSPW(timing->hsync_len - 1);
> -   writel(val, ctx->regs + VIDTCON1);
> +   if (driver_data->fimd_ver == VERSION_8)
> +   writel(val, ctx->regs + FIMD_V8_VIDTCON1);
> +   else
> +   writel(val, ctx->regs + VIDTCON1);
>
> /* setup horizontal and vertical display size. */
> val = VIDTCON2_LINEVAL(timing->yres - 1) |
>VIDTCON2_HOZVAL(timing->xres - 1);
> -   writel(val, ctx->regs + VIDTCON2);
> +   if (driver_data->fimd_ver == VERSION_8)
> +   writel(val, ctx->regs + FIMD_V8_VIDTCON2);
> +   else
> +   writel(val, ctx->regs + VIDTCON2);
>
> /* setup clock source, clock divider, enable dma. */
> val = ctx->vidcon0;
> @@ -982,6 +1016,17 @@ static int fimd_runtime_resume(struct device *dev)
>  }
>  #endif
>
> +static struct platform_device_id exynos_drm_fimd_driver_ids[] = {

Just use "fimd_driver_ids".

> +   {
> +   .name   = "exynos4-fb",
> +   }, {
> +   .name   = "exynos5-drm-fimd",

I think this name should be "exynos5-fb" because exynos5 fb driver and
clock-exynos5 also use "exynos5-fb".

> +   .driver_data= (unsigned 
> long)_drm_fimd_driver_data,
> +   },
> +   {},
> +};
> +MODULE_DEVICE_TABLE(platform, exynos_drm_fimd_driver_ids);
> +
>  static const struct dev_pm_ops fimd_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
> SET_RUNTIME_PM_OPS(fimd_runtime_suspend, 

[Bug 53632] Random rendering corruptions

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

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

Thomas Rohloff  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #6 from Thomas Rohloff  2012-08-17 09:40:15 
UTC ---
(In reply to comment #5)
> > Do I need the kernel patch, too?
> 
> Yes.
The patch seems to fix my issue. Sorry for the trouble.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v4

[Alex Deucher]

On Thu, Aug 16, 2012 at 7:13 PM, Greg KH  wrote:
> On Mon, Aug 06, 2012 at 12:56:04PM -0400, j.glisse at gmail.com wrote:
>> From: Jerome Glisse 
>>
>> Virtual address need to be fenced to know when we can safely remove it.
>> This patch also properly clear the pagetable. Previously it was
>> serouisly broken.
>>
>> v2: For to update pagetable when unbinding bo (don't bailout if
>> bo_va->valid is true).
>> v3: Fix compilation warnings
>> v4: We need a special version for 3.5 because the locking scheme
>> is different btw 3.5 and 3.6. There is no longer cs mutex in
>> 3.6 instead there is a global vm mutex.
>>
>> This version is for stable 3.5 only.
>
> Is the version that fixes this problem in the 3.6 tree, already in
> Linus's tree?  If so, what is the git commit id?  If not, I need to wait
> until it gets in there, so please tell me when it does so.

Yes:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e43b5ec05afdc232be25aa481315035c1888d389

Please apply to stable.

Alex

[PATCH] drm/udl: dpms off the crtc when disabled.

[Alex Deucher]

On Thu, Aug 16, 2012 at 10:55 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This turns off the crtc when its been disabled,
> fixes it not turning off properly the whole time.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/udl/udl_modeset.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
> b/drivers/gpu/drm/udl/udl_modeset.c
> index f5dd89e..9159d48 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -354,8 +354,7 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,
>
>  static void udl_crtc_disable(struct drm_crtc *crtc)
>  {
> -
> -
> +   udl_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
>  }
>
>  static void udl_crtc_destroy(struct drm_crtc *crtc)
> --
> 1.7.11.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] first drm-intel-next for 3.7

[Daniel Vetter]

Hi Dave,

First -next pull for 3.7. Highlights:
- hsw hdmi improvements (Paulo)
- ips/rps locking rework and cleanups
- rc6 on ilk by default again
- hw context support for hsw (Ben)
- GET_PARAM_HAS_SEMAPHORES (Chris)
- gen6+ pipe_control improvements (Chris)
- set_cacheing ioctl and assorted support code (Chris)
- cleanups around the busy/idle/pm code (Chris)
- flushing_list removal, hopefully for good (Chris)
- read_reg ioctl (Ben)
- support the ns2501 dvo (Thomas Richter)
- avoid the costly gen6+ "missed IRQ" workaround where we don't need a
  race-free seqno readback (Chris)
- various bits, mostly early patches from the modeset rework branch

As discussed on irc I'll send you a pull with 3.6-rc2 merged in, since
there's a funny conflict with mainline.

Wrt regressions nothing new popped up since my -fixes pull, and QA has
been rather happy with testing this -next pull here.

Yours, Daniel

Aside: I've frobbed the shortlog to exclude everything in -rc2.

The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92:

  Linux 3.6-rc2 (2012-08-16 14:51:24 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel for-airlied

for you to fetch changes up to a22ddff8bedfe33eeb1330bbb7ef1fbe007a42c4:

  Merge tag 'v3.6-rc2' into drm-intel-next (2012-08-17 09:01:08 +0200)



Ben Widawsky (4):
  drm/i915: add register read IOCTL
  drm/i915: Add contexts for HSW
  drm/i915: Macro to determine DPF support
  drm/i915: Expand DPF support to Haswell

Chris Wilson (17):
  drm/i915: Cleanup context switching through do_switch()
  drm/i915: Return a mask of the active rings in the high word of busy_ioctl
  drm/i915: Allow late allocation of request for i915_add_request()
  drm/i915: Remove assertion over write domain after i915_gem_object_sync()
  drm/i915: Replace the pending_gpu_write flag with an explicit seqno
  drm/i915: Remove the defunct flushing list
  drm/i915: Remove the per-ring write list
  drm/i915: Remove explicit flush from i915_gem_object_flush_fence()
  drm/i915: Remove the explicit flush of the GPU write domain
  drm/i915: Clear the pending_gpu_fenced_access flag at the start of 
execbuffer
  drm/i915: Split i915_gem_flush_ring() into seperate invalidate/flush funcs
  drm/i915: Avoid concurrent access when marking the device as idle/busy
  drm/i915: Segregate memory domains in the GTT using coloring
  drm/i915: Export ability of changing cache levels to userspace
  drm/i915: Only apply the SNB pipe control w/a to gen6
  drm/i915: Add I915_GEM_PARAM_HAS_SEMAPHORES
  drm/i915: Lazily apply the SNB+ seqno w/a

Daniel Vetter (21):
  drm/i915: group ADPA #defines together
  drm/i915: simplify possible_clones computation
  drm/i915: add port parameter to intel_hdmi_init
  drm/i915: Reserve ioctl numbers for set/get_caching
  drm/i915: create VLV_DSIPLAY_BASE #define
  drm/i915: add inte_crt->adpa_reg
  drm/i915: Replace the complex flushing logic with simple invalidate/flush 
all
  drm/i915: Only set the down rps limit when at the loweset frequency
  drm/i915: rip out sanitize_pm again
  drm/i915: fixup desired rps frequency computation
  drm/i915: dump the device info
  drm/i915: properly guard ilk ips state
  drm/i915: fixup up debugfs rps state handling
  drm/i915: use mutex_lock_interruptible for debugfs files
  drm/i915: move all rps state into dev_priv->rps
  drm/i915: kill dev_priv->mchdev_lock
  drm/i915: DE_PCU_EVENT irq is ilk-only
  drm/i915: fix up ilk drps/ips locking
  drm/i915: enable rc6 on ilk again
  drm/i915: don't grab dev->struct_mutex for userspace forcewak
  Merge tag 'v3.6-rc2' into drm-intel-next

Eugeni Dodonov (1):
  drm/i915: prevent possible pin leak on error path

Paulo Zanoni (10):
  drm/i915: move common code to intel_dp_set_link_train
  drm/i915: add port field to struct intel_dp and use it
  drm/i915: fix pipe DDI mode select
  drm/i915: set the DDI sync polarity bits
  drm/i915: correctly set the DDI_FUNC_CTL bpc field
  drm/i915: completely reset the value of DDI_FUNC_CTL
  drm/i915: reindent Haswell register definitions
  drm/i915: add parentheses around PIXCLK_GATE definitions
  drm/i915: use the correct encoder type when comparing
  drm/i915: try harder to find WR PLL clock settings

Shobhit Kumar (1):
  drm/i915: Move DP structs to shared location

Thomas Richter (1):
  drm/i915: Support for ns2501-DVO

 drivers/gpu/drm/i915/Makefile  |1 +
 drivers/gpu/drm/i915/dvo.h |1 +
 drivers/gpu/drm/i915/dvo_ns2501.c  |  582 
 drivers/gpu/drm/i915/i915_debugfs.c|  143 ---
 drivers/gpu/drm/i915/i915_dma.c|   26 +-
 drivers/gpu/drm/i915/i915_drv.c

[Bug 53632] Random rendering corruptions

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

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

Andreas Boll  changed:

   What|Removed |Added

Summary|Radmon rendering|Random rendering
   |corruptions |corruptions

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53632] Radmon rendering corruptions

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

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

--- Comment #5 from Michel D?nzer  2012-08-17 08:47:30 
UTC ---
(In reply to comment #4)
> > Can you bisect which commit exactly triggered it?
> I'm not that good at bisecting (never did it) but I could try to remove your
> patches one by one. Would that help, too?

Yes, that would be the poor man's way to isolate the commit. But you should
really learn to bisect. :)


> Do I need the kernel patch, too?

Yes.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53632] Radmon rendering corruptions

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

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

--- Comment #4 from Thomas Rohloff  2012-08-17 08:43:23 
UTC ---
(In reply to comment #1)
> Please attach files here directly.
Sorry, done.

> Can you bisect which commit exactly triggered it?
I'm not that good at bisecting (never did it) but I could try to remove your
patches one by one. Would that help, too?

> Do you have Jerome's kernel fix referenced in that report?
No. It's a 3.5 kernel without (DRI related) patches. Do I need the kernel
patch, too?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53632] Radmon rendering corruptions

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

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

--- Comment #3 from Thomas Rohloff  2012-08-17 08:40:54 
UTC ---
Created attachment 65673
  --> https://bugs.freedesktop.org/attachment.cgi?id=65673
Bad rendering

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53632] Radmon rendering corruptions

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

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

--- Comment #2 from Thomas Rohloff  2012-08-17 08:40:26 
UTC ---
Created attachment 65672
  --> https://bugs.freedesktop.org/attachment.cgi?id=65672
Good rendering

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53632] Radmon rendering corruptions

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

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

--- Comment #1 from Michel D?nzer  2012-08-17 08:28:09 
UTC ---
(In reply to comment #1)
> Good: http://img713.imageshack.us/img713/492/mcgood.png
> Bad: http://img96.imageshack.us/img96/6417/mcbad.png

Please attach files here directly.


> There are no error logs at all and this seems to be triggered by Michel 
> D?nzers
> patches to fix bug #45018 (see comment #119 there) as it wasn't there before.

Can you bisect which commit exactly triggered it?

Do you have Jerome's kernel fix referenced in that report?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge

[Keith Packard]

"Lespiau, Damien"  writes:

> On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard  wrote:
>
> @@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct
> drm_i915_private *dev_priv)
>   */
>  static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
>  unsigned int *pipe_bpp,
> -struct drm_display_mode *mode)
> +struct drm_display_mode *mode,
> +int max_fdi_bpp)
>
> There's some kernel-doc for this function, maybe add a @max_fdi_bpp
> there?

Will do

> This chunk is being moved around in a later patch in the series,
> merging the two patches in one looks like a good idea?

Or at least move this into its final position in this patch.

> I guess this does not cover the case of pipe B using 3 lanes meaning
> pipe C can use 1?

It didn't look like that was a supported mode from the docs.

> This duplicates the code just that is just a few lines away, instead
> how about moving the logic to set target_clock up in front of this
> whole if()?

It's not the same, it's the inverse -- computing bpp from lanes+clock
clock instead of computing lanes from bpp+clock. But, yeah, it would be
nice to have these merged somehow. I couldn't figure out a good way though.

> This chunk is also reworked in a later commit in this series.

I'll see if I can't avoid that as it's confusing. Thanks for your review!

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120817/d1952604/attachment.pgp>

[Bug 53632] New: Radmon rendering corruptions

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

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

 Bug #: 53632
   Summary: Radmon rendering corruptions
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: v10lator at myway.de


I get random rendering corruptions in Minecraft with a CAYMAN GPU (radeon HD
6950).
It seems like the wrong textures are selected, see:
Good: http://img713.imageshack.us/img713/492/mcgood.png
Bad: http://img96.imageshack.us/img96/6417/mcbad.png

Also water seems to (randomly) choose the wrong texture in it's animation,
resulting in flashing water. Also the game screen flashes blue sometimes.

There are no error logs at all and this seems to be triggered by Michel D?nzers
patches to fix bug #45018 (see comment #119 there) as it wasn't there before.
Please note that this has nothing to do with GLAMOR acceleration (not used when
the corruptions occur).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53630] New: compiz + glamor = screen corruptions

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

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

 Bug #: 53630
   Summary: compiz + glamor = screen corruptions
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: v10lator at myway.de


Created attachment 65668
  --> https://bugs.freedesktop.org/attachment.cgi?id=65668
dmesg ouput while compiz loads

I get screen corruptions when starting compiz while GLAMOR acceleration is
enabled. The desktop shows random white bars at the desktop right after
loading. These bars can be removed by refreshing the desktop (re-setting the
desktop background in XFCE).
While compiz loads the attached log shows up in dmesg.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11

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

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

--- Comment #9 from Michel D?nzer  2012-08-17 07:28:50 
UTC ---
(In reply to comment #8)
> Is there a way to use apitrace in combination with piglit? I'd like to trace
> the problematic test.

The first step would be to reproduce the problem by manually running the
problematic test from the piglit/bin directory. Then you should be able to
apitrace it just like any other app.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

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

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

Michel D?nzer  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #127 from Michel D?nzer  2012-08-17 07:26:52 
UTC ---
(In reply to comment #126)
> I won't say for sure the vm problem is fixed, but if it's still there, latest
> patches helped a lot since I was able to run more than twice as long as usual
> without any problem.

Great! Resolving this bug as fixed.

Any other remaining issues, in particular Thomas' glamor issues, should be
tracked in separate bug reports.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11

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

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

--- Comment #8 from Alexandre Demers  
2012-08-17 03:49:31 UTC ---
Is there a way to use apitrace in combination with piglit? I'd like to trace
the problematic test.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

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

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

--- Comment #126 from Alexandre Demers  
2012-08-17 03:18:27 UTC ---
Good news on my side: I was unable to recreate the bug until now. So I went
with running pilit tests. Sadly, for that part, it still locks (now tracked
under bug 53111).

I won't say for sure the vm problem is fixed, but if it's still there, latest
patches helped a lot since I was able to run more than twice as long as usual
without any problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

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

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

--- Comment #125 from Alexandre Demers  
2012-08-17 03:00:53 UTC ---
(In reply to comment #124)
> And there are some random rendering issues that wasn't there before the
> patches, like using the wrong texture.
> 
> Good: http://img713.imageshack.us/img713/492/mcgood.png
> Bad: http://img96.imageshack.us/img96/6417/mcbad.png
> 
> Also water in the game flashes white (seems to choose the wrong texture
> sometimes in the animation, too) and sometimes the whole game screen flashes
> blue.

I won't officially answer you question, but I think it should be tracked under
a different bug since you are using Glamor. However, if I was you, I would
create a new bug entry with a reference to this one.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[RFC 5/5] video: panel: Add R61517 panel support

[Laurent Pinchart]

The R61517 is a MIPI DBI panel controller from Renesas.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig|9 +
 drivers/video/panel/Makefile   |1 +
 drivers/video/panel/panel-r61517.c |  408 
 include/video/panel-r61517.h   |   28 +++
 4 files changed, 446 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-r61517.c
 create mode 100644 include/video/panel-r61517.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 12d7712..bd643be 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -25,4 +25,13 @@ config DISPLAY_PANEL_R61505

  If you are in doubt, say N.

+config DISPLAY_PANEL_R61517
+   tristate "Renesas R61517-based Display Panel"
+   select DISPLAY_PANEL_DBI
+   ---help---
+ Support panels based on the Renesas R61517 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N.
+
 endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index e4fb9fe..3c11d26 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DISPLAY_PANEL) += panel.o
 obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
 obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
 obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
+obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/panel/panel-r61517.c 
b/drivers/video/panel/panel-r61517.c
new file mode 100644
index 000..6e8d933
--- /dev/null
+++ b/drivers/video/panel/panel-r61517.c
@@ -0,0 +1,408 @@
+/*
+ * Renesas R61517-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on KFR2R09 LCD panel support
+ * Copyright (C) 2009 Magnus Damm
+ * Register settings based on the out-of-tree t33fb.c driver
+ * Copyright (C) 2008 Lineo Solutions, Inc.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct r61517 {
+   struct panel panel;
+   struct panel_dbi_device *dbi;
+   const struct panel_r61517_platform_data *pdata;
+};
+
+#define to_panel(p)container_of(p, struct r61517, panel)
+
+/* 
-
+ * Read, write and reset
+ */
+
+static void r61517_write_command(struct r61517 *panel, u16 reg)
+{
+   panel_dbi_write_command(panel->dbi, reg);
+}
+
+static void r61517_write_data(struct r61517 *panel, u16 data)
+{
+   panel_dbi_write_data(panel->dbi, data);
+}
+
+static void r61517_write(struct r61517 *panel, u16 reg, u16 data)
+{
+   panel_dbi_write_command(panel->dbi, reg);
+   panel_dbi_write_data(panel->dbi, data);
+}
+
+static u16 r61517_read_data(struct r61517 *panel)
+{
+   return panel_dbi_read_data(panel->dbi);
+}
+
+static void __r61517_write_array(struct r61517 *panel, const u8 *data,
+unsigned int len)
+{
+   unsigned int i;
+
+   for (i = 0; i < len; ++i)
+   r61517_write_data(panel, data[i]);
+}
+
+#define r61517_write_array(p, a) \
+   __r61517_write_array(p, a, ARRAY_SIZE(a))
+
+static void r61517_reset(struct r61517 *panel)
+{
+   gpio_set_value(panel->pdata->protect, 0);   /* PROTECT/ -> L */
+   gpio_set_value(panel->pdata->reset, 0); /* LCD_RST/ -> L */
+   gpio_set_value(panel->pdata->protect, 1);   /* PROTECT/ -> H */
+   usleep_range(1100, 1200);
+   gpio_set_value(panel->pdata->reset, 1); /* LCD_RST/ -> H */
+   usleep_range(10, 100);
+   gpio_set_value(panel->pdata->protect, 0);   /* PROTECT/ -> L */
+   msleep(20);
+}
+
+/* 
-
+ * Configuration
+ */
+
+static const u8 data_frame_if[] = {
+   0x02, /* WEMODE: 1=cont, 0=one-shot */
+   0x00, 0x00,
+   0x00, /* EPF, DFM */
+   0x02, /* RIM[1] : 1 (18bpp) */
+};
+
+static const u8 data_panel[] = {
+   0x0b,
+   0x63, /* 400 lines */
+   0x04, 0x00, 0x00, 0x04, 0x11, 0x00, 0x00,
+};
+
+static const u8 data_timing[] = {
+   0x00, 0x00, 0x13, 0x08, 0x08,
+};
+
+static const u8 data_timing_src[] = {
+   0x11, 0x01, 0x00, 0x01,
+};
+
+static const u8 data_gamma[] = {
+   0x01, 0x02, 0x08, 0x23, 0x03, 0x0c, 0x00, 0x06, 0x00, 0x00,
+   0x01, 0x00, 0x0c, 0x23, 0x03, 0x08, 0x02, 0x06, 0x00, 0x00,
+};
+
+static const u8 data_power[] = {
+   0x07, 0xc5, 0xdc, 0x02, 0x33, 0x0a,
+};
+
+static unsigned long r61517_read_device_code(struct r61517 *panel)
+{
+   /* access protect OFF */
+   r61517_write(panel, 0xb0, 0x00);
+

[RFC 4/5] video: panel: Add R61505 panel support

[Laurent Pinchart]

The R61505 is a SYS-80 bus panel controller from Renesas.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig|9 +
 drivers/video/panel/Makefile   |1 +
 drivers/video/panel/panel-r61505.c |  520 
 include/video/panel-r61505.h   |   27 ++
 4 files changed, 557 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-r61505.c
 create mode 100644 include/video/panel-r61505.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index fd0b3cf..12d7712 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -16,4 +16,13 @@ config DISPLAY_PANEL_DBI
tristate
default n

+config DISPLAY_PANEL_R61505
+   tristate "Renesas R61505-based Display Panel"
+   select DISPLAY_PANEL_DBI
+   ---help---
+ Support panels based on the Renesas R61505 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N.
+
 endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index 2ab0520..e4fb9fe 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DISPLAY_PANEL) += panel.o
 obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
 obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
+obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
diff --git a/drivers/video/panel/panel-r61505.c 
b/drivers/video/panel/panel-r61505.c
new file mode 100644
index 000..e09455e
--- /dev/null
+++ b/drivers/video/panel/panel-r61505.c
@@ -0,0 +1,520 @@
+/*
+ * Renesas R61505-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on SuperH MigoR Quarter VGA LCD Panel
+ * Copyright (C) 2008 Magnus Damm
+ * Based on lcd_powertip.c from Kenati Technologies Pvt Ltd.
+ * Copyright (c) 2007 Ujjwal Pande
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define R61505_DEVICE_CODE 0x
+#define R61505_DEVICE_CODE_VALUE   0x1505
+#define R61505_DRIVER_OUTPUT_CONTROL   0x0001
+#define R61505_DRIVER_OUTPUT_CONTROL_SM(1 << 10)
+#define R61505_DRIVER_OUTPUT_CONTROL_SS(1 << 8)
+#define R61505_LCD_WAVEFORM0x0002
+#define R61505_LCD_WAVEFORM_BC0(1 << 9)
+#define R61505_LCD_WAVEFORM_EOR(1 << 8)
+#define R61505_ENTRY_MODE  0x0003
+#define R61505_ENTRY_MODE_TRIREG   (1 << 15)
+#define R61505_ENTRY_MODE_DFM  (1 << 14)
+#define R61505_ENTRY_MODE_BGR  (1 << 12)
+#define R61505_ENTRY_MODE_HWM  (1 << 9)
+#define R61505_ENTRY_MODE_ORG  (1 << 7)
+#define R61505_ENTRY_MODE_ID1  (1 << 5)
+#define R61505_ENTRY_MODE_ID0  (1 << 4)
+#define R61505_ENTRY_MODE_AM   (1 << 3)
+#define R61505_RESIZE_CONTROL  0x0004
+#define R61505_RESIZE_CONTROL_RCV(n)   (((n) & 3) << 8)
+#define R61505_RESIZE_CONTROL_RCH(n)   (((n) & 3) << 4)
+#define R61505_RESIZE_CONTROL_RSZ_4(3 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_2(1 << 0)
+#define R61505_RESIZE_CONTROL_RSZ_1(0 << 0)
+#define R61505_DISPLAY_CONTROL10x0007
+#define R61505_DISPLAY_CONTROL1_PTDE1  (1 << 13)
+#define R61505_DISPLAY_CONTROL1_PTDE0  (1 << 12)
+#define R61505_DISPLAY_CONTROL1_BASEE  (1 << 8)
+#define R61505_DISPLAY_CONTROL1_VON(1 << 6)
+#define R61505_DISPLAY_CONTROL1_GON(1 << 5)
+#define R61505_DISPLAY_CONTROL1_DTE(1 << 4)
+#define R61505_DISPLAY_CONTROL1_COL(1 << 3)
+#define R61505_DISPLAY_CONTROL1_D1 (1 << 1)
+#define R61505_DISPLAY_CONTROL1_D0 (1 << 0)
+#define R61505_DISPLAY_CONTROL20x0008
+#define R61505_DISPLAY_CONTROL2_FP(n)  (((n) & 0xf) << 8)
+#define R61505_DISPLAY_CONTROL2_BP(n)  (((n) & 0xf) << 0)
+#define R61505_DISPLAY_CONTROL30x0009
+#define R61505_DISPLAY_CONTROL3_PTS(n) (((n) & 7) << 8)
+#define R61505_DISPLAY_CONTROL3_PTG(n) (((n) & 3) << 3)
+#define R61505_DISPLAY_CONTROL3_ICS(n) (((n) & 0xf) << 0)
+#define R61505_DISPLAY_CONTROL40x000a
+#define R61505_DISPLAY_CONTROL4_FMARKOE(1 << 3)
+#define R61505_DISPLAY_CONTROL4_FMI_6  (5 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_4  (3 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_2  (1 << 0)
+#define R61505_DISPLAY_CONTROL4_FMI_1  (0 << 0)
+#define 

[RFC 3/5] video: panel: Add MIPI DBI bus support

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig |4 +
 drivers/video/panel/Makefile|1 +
 drivers/video/panel/panel-dbi.c |  217 +++
 include/video/panel-dbi.h   |   92 +
 4 files changed, 314 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-dbi.c
 create mode 100644 include/video/panel-dbi.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 36fb9ca..fd0b3cf 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -12,4 +12,8 @@ config DISPLAY_PANEL_DUMMY

  If you are in doubt, say N.

+config DISPLAY_PANEL_DBI
+   tristate
+   default n
+
 endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index 9fc05c2..2ab0520 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DISPLAY_PANEL) += panel.o
 obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
+obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
diff --git a/drivers/video/panel/panel-dbi.c b/drivers/video/panel/panel-dbi.c
new file mode 100644
index 000..0511997
--- /dev/null
+++ b/drivers/video/panel/panel-dbi.c
@@ -0,0 +1,217 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* 
-
+ * Bus operations
+ */
+
+void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
+{
+   dev->bus->ops->write_command(dev->bus, cmd);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_command);
+
+void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long data)
+{
+   dev->bus->ops->write_data(dev->bus, data);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_data);
+
+unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
+{
+   return dev->bus->ops->read_data(dev->bus);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_read_data);
+
+/* 
-
+ * Bus type
+ */
+
+static const struct panel_dbi_device_id *
+panel_dbi_match_id(const struct panel_dbi_device_id *id,
+  struct panel_dbi_device *dev)
+{
+   while (id->name[0]) {
+   if (strcmp(dev->name, id->name) == 0) {
+   dev->id_entry = id;
+   return id;
+   }
+   id++;
+   }
+   return NULL;
+}
+
+static int panel_dbi_match(struct device *_dev, struct device_driver *_drv)
+{
+   struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+   struct panel_dbi_driver *drv = to_panel_dbi_driver(_drv);
+
+   if (drv->id_table)
+   return panel_dbi_match_id(drv->id_table, dev) != NULL;
+
+   return (strcmp(dev->name, _drv->name) == 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
+char *buf)
+{
+   struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+   int len = snprintf(buf, PAGE_SIZE, PANEL_DBI_MODULE_PREFIX "%s\n",
+  dev->name);
+
+   return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute panel_dbi_dev_attrs[] = {
+   __ATTR_RO(modalias),
+   __ATTR_NULL,
+};
+
+static int panel_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
+{
+   struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+
+   add_uevent_var(env, "MODALIAS=%s%s", PANEL_DBI_MODULE_PREFIX,
+  dev->name);
+   return 0;
+}
+
+static const struct dev_pm_ops panel_dbi_dev_pm_ops = {
+   .runtime_suspend = pm_generic_runtime_suspend,
+   .runtime_resume = pm_generic_runtime_resume,
+   .runtime_idle = pm_generic_runtime_idle,
+   .suspend = pm_generic_suspend,
+   .resume = pm_generic_resume,
+   .freeze = pm_generic_freeze,
+   .thaw = pm_generic_thaw,
+   .poweroff = pm_generic_poweroff,
+   .restore = pm_generic_restore,
+};
+
+static struct bus_type panel_dbi_bus_type = {
+   .name   = "mipi-dbi",
+   .dev_attrs  = panel_dbi_dev_attrs,
+   .match  = panel_dbi_match,
+   .uevent = panel_dbi_uevent,
+   .pm = _dbi_dev_pm_ops,
+};
+
+/* 
-
+ * Device and driver (un)registration
+ */
+
+/**
+ * panel_dbi_device_register - register a DBI device
+ * @dev: DBI device we're registering
+ */
+int panel_dbi_device_register(struct panel_dbi_device *dev,
+ struct 

[RFC 2/5] video: panel: Add dummy panel support

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/video/panel/Kconfig   |   11 
 drivers/video/panel/Makefile  |1 +
 drivers/video/panel/panel-dummy.c |  103 +
 include/video/panel-dummy.h   |   25 +
 4 files changed, 140 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/panel-dummy.c
 create mode 100644 include/video/panel-dummy.h

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 26b1787..36fb9ca 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -2,3 +2,14 @@ menuconfig DISPLAY_PANEL
tristate "Display Panel"
---help---
  Support for display panels for graphics devices.
+
+if DISPLAY_PANEL
+
+config DISPLAY_PANEL_DUMMY
+   tristate "Dummy Display Panel"
+   ---help---
+ Support dummy panels with no control bus.
+
+ If you are in doubt, say N.
+
+endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index cf5c5e2..9fc05c2 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DISPLAY_PANEL) += panel.o
+obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
diff --git a/drivers/video/panel/panel-dummy.c 
b/drivers/video/panel/panel-dummy.c
new file mode 100644
index 000..9ba1447
--- /dev/null
+++ b/drivers/video/panel/panel-dummy.c
@@ -0,0 +1,103 @@
+/*
+ * Dummy Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#include 
+
+struct panel_dummy {
+   struct panel panel;
+   const struct panel_dummy_platform_data *pdata;
+};
+
+#define to_panel_dummy(p)  container_of(p, struct panel_dummy, panel)
+
+static int panel_dummy_get_modes(struct panel *p,
+const struct fb_videomode **modes)
+{
+   struct panel_dummy *panel = to_panel_dummy(p);
+
+   *modes = panel->pdata->mode;
+   return 1;
+}
+
+static const struct panel_ops panel_dummy_ops = {
+   .get_modes = panel_dummy_get_modes,
+};
+
+static void panel_dummy_release(struct panel *p)
+{
+   struct panel_dummy *panel = to_panel_dummy(p);
+
+   kfree(panel);
+}
+
+static int panel_dummy_remove(struct platform_device *pdev)
+{
+   struct panel_dummy *panel = platform_get_drvdata(pdev);
+
+   platform_set_drvdata(pdev, NULL);
+   panel_unregister(>panel);
+
+   return 0;
+}
+
+static int __devinit panel_dummy_probe(struct platform_device *pdev)
+{
+   const struct panel_dummy_platform_data *pdata = pdev->dev.platform_data;
+   struct panel_dummy *panel;
+   int ret;
+
+   if (pdata == NULL)
+   return -ENODEV;
+
+   panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+   if (panel == NULL)
+   return -ENOMEM;
+
+   panel->pdata = pdata;
+   panel->panel.dev = >dev;
+   panel->panel.release = panel_dummy_release;
+   panel->panel.ops = _dummy_ops;
+   panel->panel.width = pdata->width;
+   panel->panel.height = pdata->height;
+
+   ret = panel_register(>panel);
+   if (ret < 0) {
+   kfree(panel);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, panel);
+
+   return 0;
+}
+
+static const struct dev_pm_ops panel_dummy_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dummy_driver = {
+   .probe = panel_dummy_probe,
+   .remove = panel_dummy_remove,
+   .driver = {
+   .name = "panel_dummy",
+   .owner = THIS_MODULE,
+   .pm = _dummy_dev_pm_ops,
+   },
+};
+
+module_platform_driver(panel_dummy_driver);
+
+MODULE_AUTHOR("Laurent Pinchart ");
+MODULE_DESCRIPTION("Dummy Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-dummy.h b/include/video/panel-dummy.h
new file mode 100644
index 000..558a297
--- /dev/null
+++ b/include/video/panel-dummy.h
@@ -0,0 +1,25 @@
+/*
+ * Dummy Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PANEL_DUMMY_H__
+#define __PANEL_DUMMY_H__
+
+#include 
+#include 
+
+struct panel_dummy_platform_data {
+   unsigned long width;/* Panel width in mm */
+   unsigned long height;   /* Panel height in mm */
+   const struct fb_videomode *mode;
+};
+
+#endif /* __PANEL_DUMMY_H__ */
-- 
1.7.8.6

[RFC 1/5] video: Add generic display panel core

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/video/Kconfig|1 +
 drivers/video/Makefile   |1 +
 drivers/video/panel/Kconfig  |4 +
 drivers/video/panel/Makefile |1 +
 drivers/video/panel/panel.c  |  269 ++
 include/video/panel.h|  111 +
 6 files changed, 387 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/panel/Kconfig
 create mode 100644 drivers/video/panel/Makefile
 create mode 100644 drivers/video/panel/panel.c
 create mode 100644 include/video/panel.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..2cc394e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2448,6 +2448,7 @@ source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/panel/Kconfig"

 if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ee8dafb..577240c 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= panel/

 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/

diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
new file mode 100644
index 000..26b1787
--- /dev/null
+++ b/drivers/video/panel/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_PANEL
+   tristate "Display Panel"
+   ---help---
+ Support for display panels for graphics devices.
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
new file mode 100644
index 000..cf5c5e2
--- /dev/null
+++ b/drivers/video/panel/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_PANEL) += panel.o
diff --git a/drivers/video/panel/panel.c b/drivers/video/panel/panel.c
new file mode 100644
index 000..cfca804
--- /dev/null
+++ b/drivers/video/panel/panel.c
@@ -0,0 +1,269 @@
+/*
+ * Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static LIST_HEAD(panel_list);
+static LIST_HEAD(panel_notifiers);
+static DEFINE_MUTEX(panel_mutex);
+
+/**
+ * panel_enable - Set the panel operation mode
+ * @panel: The panel
+ * @enable: Panel operation mode
+ *
+ * - PANEL_ENABLE_OFF turns the panel off completely, possibly including its
+ *   power supplies. Communication with a panel in that mode is not possible.
+ * - PANEL_ENABLE_BLANK turns the panel on but keep the output blanked. Full
+ *   communication with the panel is supported, including pixel data transfer.
+ * - PANEL_ENABLE_ON turns the whole panel on, including the output.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int panel_enable(struct panel *panel, enum panel_enable_mode enable)
+{
+   int ret;
+
+   if (panel->enable == enable)
+   return 0;
+
+   if (!panel->ops || !panel->ops->enable)
+   return 0;
+
+   ret = panel->ops->enable(panel, enable);
+   if (ret < 0)
+   return ret;
+
+   panel->enable = enable;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(panel_enable);
+
+/**
+ * panel_start_transfer - Start frame transfer
+ * @panel: The panel
+ *
+ * Make the panel ready to receive pixel data and start frame transfer. This
+ * operation can only be called if the panel is in BLANK or ON mode.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int panel_start_transfer(struct panel *panel)
+{
+   if (!panel->ops || !panel->ops->start_transfer)
+   return 0;
+
+   return panel->ops->start_transfer(panel);
+}
+
+/**
+ * panel_get_modes - Get video modes supported by the panel
+ * @panel: The panel
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the panel.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int panel_get_modes(struct panel *panel, const struct fb_videomode **modes)
+{
+   if (!panel->ops || !panel->ops->get_modes)
+   return 0;
+
+   return panel->ops->get_modes(panel, modes);
+}
+EXPORT_SYMBOL_GPL(panel_get_modes);
+
+static void panel_release(struct kref *ref)
+{
+   struct panel *panel = container_of(ref, struct panel, ref);
+
+   if (panel->release)
+   panel->release(panel);
+}
+
+/**
+ * panel_get - get a reference to a panel
+ * @panel: the panel
+ *
+ * 

[RFC 0/5] Generic panel framework

[Laurent Pinchart]

Hi everybody,

While working on DT bindings for the Renesas Mobile SoC display controller
(a.k.a. LCDC) I quickly realized that display panel implementation based on
board code callbacks would need to be replaced by a driver-based panel
framework.

Several driver-based panel support solution already exist in the kernel.

- The LCD device class is implemented in drivers/video/backlight/lcd.c and
  exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
  API for historical reason, uses board code callback for reset and power
  management, and doesn't include support for standard features available in
  today's "smart panels".

- OMAP2+ based systems use custom panel drivers available in
  drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
  controller) specific APIs.

- Similarly, Exynos based systems use custom panel drivers available in
  drivers/video/exynos. Only a single driver (s6e8ax0) is currently available.
  That driver is based on Exynos display controller specific APIs and on the
  LCD device class API.

I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus
Lorentzon (working on panel support for ST/Linaro), and we agreed that a
generic panel framework for display devices is needed. These patches implement
a first proof of concept.

One of the main reasons for creating a new panel framework instead of adding
missing features to the LCD framework is to avoid being tied to the FBDEV
framework. Panels will be used by DRM drivers as well, and their API should
thus be subsystem-agnostic. Note that the panel framework used the
fb_videomode structure in its API, this will be replaced by a common video
mode structure shared across subsystems (there's only so many hours per day).

Panels, as used in these patches, are defined as physical devices combining a
matrix of pixels and a controller capable of driving that matrix.

Panel physical devices are registered as children of the control bus the panel
controller is connected to (depending on the panel type, we can find platform
devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
devices). The generic panel framework matches registered panel devices with
panel drivers and call the panel drivers probe method, as done by other device
classes in the kernel. The driver probe() method is responsible for
instantiating a struct panel instance and registering it with the generic
panel framework.

Display drivers are panel consumers. They register a panel notifier with the
framework, which then calls the notifier when a matching panel is registered.
The reason for this asynchronous mode of operation, compared to how drivers
acquire regulator or clock resources, is that the panel can use resources
provided by the display driver. For instance a panel can be a child of the DBI
or DSI bus controlled by the display device, or use a clock provided by that
device. We can't defer the display device probe until the panel is registered
and also defer the panel device probe until the display is registered. As
most display drivers need to handle output devices hotplug (HDMI monitors for
instance), handling panel through a notification system seemed to be the
easiest solution.

Note that this brings a different issue after registration, as display and
panel drivers would take a reference to each other. Those circular references
would make driver unloading impossible. I haven't found a good solution for
that problem yet (hence the RFC state of those patches), and I would
appreciate your input here. This might also be a hint that the framework
design is wrong to start with. I guess I can't get everything right on the
first try ;-)

Getting hold of the panel is the most complex part. Once done, display drivers
can call abstract operations provided by panel drivers to control the panel
operation. These patches implement three of those operations (enable, start
transfer and get modes). More operations will be needed, and those three
operations will likely get modified during review. Most of the panels on
devices I own are dumb panels with no control bus, and are thus not the best
candidates to design a framework that needs to take complex panels' needs into
account.

In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
Interface, a parallel bus for panels that supports read/write transfers of
commands and data) bus support, as well as three panel drivers (dummy panels
with no control bus, and Renesas R61505- and R61517-based panels, both using
DBI as their control bus). Only the dummy panel driver has been tested as I
lack hardware for the two other drivers.

I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
you can find a clever way to solve the cyclic references issue described above
I'll buy you a beer at the next conference we will both attend. If you think
the proposed solution is too complex, or too simple, I'm all ears. I
personally 

[RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.

[Soby Mathew]

Hi Hans,
   For EDID update, it is recommended that the HPD line be toggled
after the EDID update is completed. So for the driver to detect the
EDID write is complete, probably a field mentioning the EDID write
completed would be good, so that the HPD toggling can be done by the
driver.

Best Regards
Soby Mathew

On 8/10/12, Hans Verkuil  wrote:
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/video/v4l2-compat-ioctl32.c |   57
> +
>  drivers/media/video/v4l2-ioctl.c  |   13 +++
>  drivers/media/video/v4l2-subdev.c |6 +++
>  include/media/v4l2-subdev.h   |2 +
>  4 files changed, 78 insertions(+)
>
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> b/drivers/media/video/v4l2-compat-ioctl32.c
> index 9ebd5c5..e843705 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -729,6 +730,44 @@ static int put_v4l2_event32(struct v4l2_event *kp,
> struct v4l2_event32 __user *u
>   return 0;
>  }
>
> +struct v4l2_subdev_edid32 {
> + __u32 pad;
> + __u32 start_block;
> + __u32 blocks;
> + __u32 reserved[5];
> + compat_caddr_t edid;
> +};
> +
> +static int get_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
> v4l2_subdev_edid32 __user *up)
> +{
> + u32 tmp;
> +
> + if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_subdev_edid32)) ||
> + get_user(kp->pad, >pad) ||
> + get_user(kp->start_block, >start_block) ||
> + get_user(kp->blocks, >blocks) ||
> + get_user(tmp, >edid) ||
> + copy_from_user(kp->reserved, up->reserved, 
> sizeof(kp->reserved)))
> + return -EFAULT;
> + kp->edid = compat_ptr(tmp);
> + return 0;
> +}
> +
> +static int put_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
> v4l2_subdev_edid32 __user *up)
> +{
> + u32 tmp = (u32)((unsigned long)kp->edid);
> +
> + if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_subdev_edid32)) ||
> + put_user(kp->pad, >pad) ||
> + put_user(kp->start_block, >start_block) ||
> + put_user(kp->blocks, >blocks) ||
> + put_user(tmp, >edid) ||
> + copy_to_user(kp->reserved, up->reserved, sizeof(kp->reserved)))
> + return -EFAULT;
> + return 0;
> +}
> +
> +
>  #define VIDIOC_G_FMT32   _IOWR('V',  4, struct v4l2_format32)
>  #define VIDIOC_S_FMT32   _IOWR('V',  5, struct v4l2_format32)
>  #define VIDIOC_QUERYBUF32_IOWR('V',  9, struct v4l2_buffer32)
> @@ -738,6 +777,8 @@ static int put_v4l2_event32(struct v4l2_event *kp,
> struct v4l2_event32 __user *u
>  #define VIDIOC_DQBUF32   _IOWR('V', 17, struct v4l2_buffer32)
>  #define VIDIOC_ENUMSTD32 _IOWR('V', 25, struct v4l2_standard32)
>  #define VIDIOC_ENUMINPUT32   _IOWR('V', 26, struct v4l2_input32)
> +#define VIDIOC_SUBDEV_G_EDID32   _IOWR('V', 63, struct 
> v4l2_subdev_edid32)
> +#define VIDIOC_SUBDEV_S_EDID32   _IOWR('V', 64, struct 
> v4l2_subdev_edid32)
>  #define VIDIOC_TRY_FMT32 _IOWR('V', 64, struct v4l2_format32)
>  #define VIDIOC_G_EXT_CTRLS32_IOWR('V', 71, struct v4l2_ext_controls32)
>  #define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
> @@ -765,6 +806,7 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   struct v4l2_ext_controls v2ecs;
>   struct v4l2_event v2ev;
>   struct v4l2_create_buffers v2crt;
> + struct v4l2_subdev_edid v2edid;
>   unsigned long vx;
>   int vi;
>   } karg;
> @@ -797,6 +839,8 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   case VIDIOC_S_OUTPUT32: cmd = VIDIOC_S_OUTPUT; break;
>   case VIDIOC_CREATE_BUFS32: cmd = VIDIOC_CREATE_BUFS; break;
>   case VIDIOC_PREPARE_BUF32: cmd = VIDIOC_PREPARE_BUF; break;
> + case VIDIOC_SUBDEV_G_EDID32: cmd = VIDIOC_SUBDEV_G_EDID; break;
> + case VIDIOC_SUBDEV_S_EDID32: cmd = VIDIOC_SUBDEV_S_EDID; break;
>   }
>
>   switch (cmd) {
> @@ -814,6 +858,12 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   compatible_arg = 0;
>   break;
>
> + case VIDIOC_SUBDEV_G_EDID:
> + case VIDIOC_SUBDEV_S_EDID:
> + err = get_v4l2_subdev_edid32(, up);
> + compatible_arg = 0;
> + break;
> +
>   case VIDIOC_G_FMT:
>   case VIDIOC_S_FMT:
>   case VIDIOC_TRY_FMT:
> @@ -906,6 +956,11 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
>   err = put_v4l2_event32(, up);
>   break;
>
> + case VIDIOC_SUBDEV_G_EDID:
> + case VIDIOC_SUBDEV_S_EDID:
> + err = 

X.Org Book Sprint 2012 (guide to writing graphics drivers)

[Matt Dew]

(Cross post. Yes, I know this is short notice and a short window to 
reply.   My apologies on that.)

X.Org Book Sprint 2012
Monday Sept 17 & Tuesday Sept 18.
N?rnberg (Nuremberg), Germany.

The X.Org Consortium will hold a book sprint on the Monday and
Tuesday before the Developers Conference in N?rnberg Germany.
During these two days attendees will focus on a book for graphics
drivers development.  The book will be targeted towards new
contributors but will have enough details to be useful to all
levels of graphics driver development.  Anyone interested in
helping out and contributing to the book sprint is encouraged to
get involved.


 From http://www.booksprints.net/about/

"A Book Sprint brings together a group to produce a book in 3-5 days.
There is no pre-production and the group is guided by a facilitator
from zero to published book. The books produced are high quality
content and are made available immediately at the end of the sprint
via print-on-demand services and e-book formats."

Our book sprint will be slightly different than that.  Our book sprint
is only two days and we are not starting from complete scratch. We are
starting with Marcheu's existing guide, located at:
http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf

For more information or if you would like to participate in the book
sprint, please contact:
board at foundation.x.org
marcoz at osource.org

Please contact us on or before Mon Aug 20, 2012.

More information can be found at:
http://www.x.org/wiki/Events/BookSprint2012

[PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd

[Leela Krishna Amudala]

The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two device ids are created for exynos4-fb and exynos5-drm-fimd.
Also, added driver data for exynos5 to pick the fimd version at runtime and
to choose the VIDTCON register offsets accordingly.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   56 +++---
 1 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 24c0bd4..8379c59 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@
 
 #define get_fimd_context(dev)  platform_get_drvdata(to_platform_device(dev))
 
+enum fimd_version_type {
+   VERSION_8, /* FIMD_VERSION8 */
+};
+
+struct drm_fimd_driver_data {
+   enum fimd_version_type fimd_ver;
+};
+
+struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
+   .fimd_ver = VERSION_8,
+};
+
 struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };
 
+static inline struct drm_fimd_driver_data *drm_fimd_get_driver_data(
+   struct platform_device *pdev)
+{
+   return (struct drm_fimd_driver_data *)
+   platform_get_device_id(pdev)-driver_data;
+}
+
 static bool fimd_display_is_connected(struct device *dev)
 {
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -194,32 +213,47 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx-panel;
struct fb_videomode *timing = panel-timing;
+   struct drm_fimd_driver_data *driver_data;
+   struct platform_device *pdev = to_platform_device(dev);
u32 val;
 
+   driver_data = drm_fimd_get_driver_data(pdev);
if (ctx-suspended)
return;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
/* setup polarity values from machine code. */
-   writel(ctx-vidcon1, ctx-regs + VIDCON1);
+   if (driver_data-fimd_ver == VERSION_8)
+   writel(ctx-vidcon1, ctx-regs + FIMD_V8_VIDCON1);
+   else
+   writel(ctx-vidcon1, ctx-regs + VIDCON1);
 
/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing-upper_margin - 1) |
   VIDTCON0_VFPD(timing-lower_margin - 1) |
   VIDTCON0_VSPW(timing-vsync_len - 1);
-   writel(val, ctx-regs + VIDTCON0);
+   if (driver_data-fimd_ver == VERSION_8)
+   writel(val, ctx-regs + FIMD_V8_VIDTCON0);
+   else
+   writel(val, ctx-regs + VIDTCON0);
 
/* setup horizontal timing values.  */
val = VIDTCON1_HBPD(timing-left_margin - 1) |
   VIDTCON1_HFPD(timing-right_margin - 1) |
   VIDTCON1_HSPW(timing-hsync_len - 1);
-   writel(val, ctx-regs + VIDTCON1);
+   if (driver_data-fimd_ver == VERSION_8)
+   writel(val, ctx-regs + FIMD_V8_VIDTCON1);
+   else
+   writel(val, ctx-regs + VIDTCON1);
 
/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing-yres - 1) |
   VIDTCON2_HOZVAL(timing-xres - 1);
-   writel(val, ctx-regs + VIDTCON2);
+   if (driver_data-fimd_ver == VERSION_8)
+   writel(val, ctx-regs + FIMD_V8_VIDTCON2);
+   else
+   writel(val, ctx-regs + VIDTCON2);
 
/* setup clock source, clock divider, enable dma. */
val = ctx-vidcon0;
@@ -982,6 +1016,17 @@ static int fimd_runtime_resume(struct device *dev)
 }
 #endif
 
+static struct platform_device_id exynos_drm_fimd_driver_ids[] = {
+   {
+   .name   = exynos4-fb,
+   }, {
+   .name   = exynos5-drm-fimd,
+   .driver_data= (unsigned long)exynos5_drm_fimd_driver_data,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, exynos_drm_fimd_driver_ids);
+
 static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -990,8 +1035,9 @@ static const struct dev_pm_ops fimd_pm_ops = {
 struct platform_driver fimd_driver = {
.probe  = fimd_probe,
.remove = __devexit_p(fimd_remove),
+   .id_table   = exynos_drm_fimd_driver_ids,
.driver = {
-   .name   = exynos4-fb,
+   .name   = exynos-drm-fimd,
.owner  = THIS_MODULE,
.pm = fimd_pm_ops,
},
-- 
1.7.0.4

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

[PATCH V3 2/2] video: drm: exynos: Add device tree support

[Leela Krishna Amudala]

Add device tree based discovery support for DRM-FIMD driver.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 -
 2 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..8ad8814
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be samsung,exynos5-drm for fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+   mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+   specified in the following order.
+   - VSYNC interrupt
+   - FIFO level interrupt
+   - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+   display device node which holds the video interface timing with the
+   below mentioned properties.
+
+   - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+   - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd 
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - supports-mipi-panel: Specifies the lcd is mipi panel type
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+   The following is an example for the fimd controller is split into
+   two portions. The SoC specific portion can be specified in the SoC
+   specific dts file. The board specific portion can be specified in the
+   board specific dts file.
+
+   - SoC Specific portion
+
+   fimd {
+   compatible = samsung,exynos5-drm;
+   interrupt-parent = combiner;
+   reg = 0x1440 0x4;
+   interrupts = 18 5, 18 4, 18 6;
+   };
+
+   - Board Specific portion
+
+   lcd_fimd0: lcd_panel0 {
+   lcd-htiming = 4 4 4 480;
+   lcd-vtiming = 4 4 4 320;
+   supports-mipi-panel;
+   };
+
+   fimd {
+   samsung,fimd-display = lcd_fimd0;
+   samsung,fimd-vidout-rgb;
+   samsung,fimd-inv-vclk;
+   samsung,fimd-frame-rate = 60;
+   samsung,default-window = 0;
+   samsung,fimd-win-bpp = 32;
+   };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8379c59..1753846 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
 #include linux/platform_device.h
 #include linux/clk.h
 #include linux/pm_runtime.h
+#include linux/of.h
 
 #include video/samsung_fimd.h
 #include drm/exynos_drm.h
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };
 
+static const struct of_device_id drm_fimd_dt_match[];
+
 static inline struct drm_fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
+#ifdef CONFIG_OF
+   if (pdev-dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_node(drm_fimd_dt_match, pdev-dev.of_node);
+   return (struct drm_fimd_driver_data *)match-data;
+   }
+#endif
return (struct drm_fimd_driver_data *)
platform_get_device_id(pdev)-driver_data;
 }
@@ -821,12 +831,79 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
return 0;
 }
 
+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device 
*dev)
+{
+   struct device_node *np = dev-of_node;
+   struct device_node *disp_np;
+   struct exynos_drm_fimd_pdata *pd;
+   u32 data[4];
+
+   pd = devm_kzalloc(dev,