date:20140401

This is the equivalent change in the crtc helpers as done to the i915
modeset infrastructure in

commit b0a2658acb5bf9ca86b4aab011b7106de3af0add
Author: Daniel Vetter 
Date:   Tue Dec 18 09:37:54 2012 +0100

drm/i915: don't disable disconnected outputs

This was originally introduced to make encoder sharing on radone
easier for userspace, but:

- It is policy and as such belongs into userspace. E.g. personally I'm
  fairly annoyed that a flaky cable results in permanent changes of
  the desktop layout, so I'll kick out DEs which do this. Worse if the
  kernel also tries to be clever.

- It's inconsistent: We only kill disconnected outputs on setCrtc
  (which userspace might also call when just changing the
  framebuffer), but not when e.g. we receive a hpd event or in the
  output poll worker.

- It's unexpected behaviour for the userspace driver, at least in the
  intel ddx we've had tons of bugs where the driver fell over and
  killed the X session becuase pageflips/vblanks suddenly stopped
  working. We've had to fix this by wrapping every single setCrtc int
  a big "recover kms state from the kernel again" operation.

- It's suprising for the kernel, too: It took a few mails between Rob,
  Matt and me for them to notice that little dragon wreaking havoc
  with the universal plane framebuffer refcounting.

- Userspace can cope with it and e.g. Gnome already kills disconnected
  outputs and reconfigures the desktop automatically. And since there
  have been no regression reports for the i915 change from over 1 year
  ago I think all other DEs are also ready.

Note that the lines removed in this patch go back to

commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
Author: Dave Airlie 
Date:   Mon Aug 31 15:16:30 2009 +1000

drm/kms: add explicit encoder disable function and detach harder.

Unfortunately the patch itself doesn't explain a hole lot about why it
was added ...

Cc: Matt Roper 
Cc: Rob Clark 
Cc: Dave Airlie 
Cc: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc_helper.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 8108db95e12b..003924025aa7 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -289,8 +289,6 @@ static void __drm_helper_disable_unused_functions(struct 
drm_device *dev)
list_for_each_entry(connector, >mode_config.connector_list, head) {
if (!connector->encoder)
continue;
-   if (connector->status == connector_status_disconnected)
-   connector->encoder = NULL;
}

list_for_each_entry(encoder, >mode_config.encoder_list, head) {
-- 
1.8.5.2

[PATCH 1/2] drm/crtc-helpers: fix dpms on logic

This was introduced in

commit 25f397a429dfa43f22c278d0119a60a343aa568f
Author: Daniel Vetter 
Date:   Fri Jul 19 18:57:11 2013 +0200

drm/crtc-helper: explicit DPMS on after modeset

but due to a bit of rebase fail on my side the patch actually merged
put one hunk on the wrong side of a break statement. Fix this up.

Reported-by: Dan Carpenter 
Cc: Dan Carpenter 
Cc: Dave Airlie 
Cc: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc_helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index c0f2d6266070..8108db95e12b 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -695,12 +695,13 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
if (new_encoder == NULL)
/* don't break so fail path works 
correct */
fail = 1;
-   break;

if (connector->dpms != DRM_MODE_DPMS_ON) {
DRM_DEBUG_KMS("connector dpms not on, 
full mode switch\n");
mode_changed = true;
}
+
+   break;
}
}

-- 
1.8.5.2

[Bug 72701] Screen freeze when using radeon driver

2014-04-01 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #9 from klod  ---
Well, it seems so. What can I do to find what the problem is?

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

[PATCH 7/7] exynos/drm: add DT bindings

This patch adds bindings for Exynos drm display subsystem.
The bindings describes ports containing a list of phandles
pointing to display controller, image enhancer, and display
interfaces nodes.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt

diff --git 
a/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt 
b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
new file mode 100644
index 000..6f7fae0
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
@@ -0,0 +1,32 @@
+Samsung Exynos DRM master device
+
+
+The Samsung Exynos DRM master device is a virtual device needed to list all
+display controller, image enhancer, and display interface nodes that comprise
+the graphics subsystem.
+
+Required properties:
+- compatible: Should be "samsung,exynos-display-subsystem"
+- ports: Should contain a list of phandles pointing to display controller,
+  image enhancer, and display interface ports.
+
+Examples:
+
+In case of using MIPI-DSI,
+display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <>, <>;
+};
+
+
+In case of using DisplayPort,
+display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <>, <>;
+};
+
+In case of using parallel panel,
+display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <>;
+};
-- 
1.7.9.5

[PATCH 6/7] ARM: dts: exynos4412-trats2: add super device node for exynos drm

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4412-trats2.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 53c717b..115b9ed 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -581,6 +581,11 @@
status = "okay";
};

+   display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <>, <_0>;
+   };
+
camera {
pinctrl-0 = <_port_b_clk_active>;
pinctrl-names = "default";
-- 
1.7.9.5

[PATCH 5/7] ARM: dts: exynos4210-trats: add super device node for exynos drm

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4210-trats.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 02c6768..a41c109 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -414,6 +414,11 @@
status = "okay";
};

+   display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <>, <_0>;
+   };
+
camera {
pinctrl-names = "default";
pinctrl-0 = <>;
-- 
1.7.9.5

[PATCH 4/7] ARM: dts: exynos4210-universal: add super device node for exynos drm

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4210-universal_c210.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 0a80a72..5351ac4 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -409,6 +409,11 @@
};
};

+   display-subsystem {
+   compatible = "samsung,exynos-display-subsystem";
+   ports = <>;
+   };
+
pwm at 139D {
compatible = "samsung,s5p6440-pwm";
status = "okay";
-- 
1.7.9.5

[PATCH v2 3/7] drm/exynos: register platform driver at each kms sub drivers

This patch removes platform_driver_register() calls from
exynos_drm_drv module, and calls module_platform_driver()
at each kms sub drivers instead.

Previous RFC patch,
http://www.spinics.net/lists/dri-devel/msg54672.html

Changelog since RFC patch:
- remove unnecessary platform_driver declarations to each sub driver.

Changelog v2:
- remove unnecessary platform_driver for mipi dsi driver.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   64 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |6 ---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
 drivers/gpu/drm/exynos/exynos_mixer.c|1 +
 7 files changed, 5 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index cb9aa58..bf4996f 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1362,6 +1362,7 @@ struct platform_driver dp_driver = {
.of_match_table = exynos_dp_match,
},
 };
+module_platform_driver(dp_driver);

 MODULE_AUTHOR("Jingoo Han ");
 MODULE_DESCRIPTION("Samsung SoC DP Driver");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index f065385..c2f444a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -468,33 +468,6 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);

-#ifdef CONFIG_DRM_EXYNOS_DP
-   ret = platform_driver_register(_driver);
-   if (ret < 0)
-   goto out_dp;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   ret = platform_driver_register(_driver);
-   if (ret < 0)
-   goto out_dsi;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   ret = platform_driver_register(_driver);
-   if (ret < 0)
-   goto out_fimd;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   ret = platform_driver_register(_driver);
-   if (ret < 0)
-   goto out_hdmi;
-   ret = platform_driver_register(_driver);
-   if (ret < 0)
-   goto out_mixer;
-#endif
-
 #ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -562,27 +535,6 @@ out_fimc:
 out_g2d:
 #endif

-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   platform_driver_unregister(_driver);
-out_mixer:
-   platform_driver_unregister(_driver);
-out_hdmi:
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   platform_driver_unregister(_driver);
-out_fimd:
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   platform_driver_unregister(_driver);
-out_dsi:
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DP
-   platform_driver_unregister(_driver);
-out_dp:
-#endif
return ret;
 }

@@ -609,22 +561,6 @@ static int exynos_drm_platform_remove(struct 
platform_device *pdev)
platform_driver_unregister(_driver);
 #endif

-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   platform_driver_unregister(_driver);
-   platform_driver_unregister(_driver);
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   platform_driver_unregister(_driver);
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   platform_driver_unregister(_driver);
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DP
-   platform_driver_unregister(_driver);
-#endif
component_master_del(>dev, _drm_ops);
return 0;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 25d562f..2b87eb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -356,12 +356,6 @@ int exynos_drm_probe_vidi(struct drm_device *dev);
 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);

-extern struct platform_driver dp_driver;
-extern struct platform_driver dsi_driver;
-extern struct platform_driver fimd_driver;
-extern struct platform_driver hdmi_driver;
-extern struct platform_driver mixer_driver;
-extern struct platform_driver exynos_drm_common_hdmi_driver;
 extern struct platform_driver vidi_driver;
 extern struct platform_driver g2d_driver;
 extern struct platform_driver fimc_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8f48f52..0005527 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1546,6 +1546,7 @@ struct platform_driver dsi_driver = {
   .of_match_table = exynos_dsi_of_match,
},
 };
+module_platform_driver(dsi_driver);

 MODULE_AUTHOR("Tomasz Figa ");
 MODULE_AUTHOR("Andrzej Hajda ");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c

[PATCH 2/7] drm/exynos: dpi: fix hotplug fail issue

When connector is created, if connector->polled is
DRM_CONNECTOR_POLL_CONNECT then drm_kms_helper_hotplug_event
function isn't called at drm_helper_hpd_irq_event because the
function will be called only in case of DRM_CONNECTOR_POLL_HPD.

So this patch sets always DRM_CONNECTOR_POLL_HPD flag to
connector->polled of parallel panel driver at connector creation.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index c1f4b35..ac206e7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -123,10 +123,7 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,

ctx->encoder = encoder;

-   if (ctx->panel_node)
-   connector->polled = DRM_CONNECTOR_POLL_CONNECT;
-   else
-   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;

ret = drm_connector_init(encoder->dev, connector,
 _dpi_connector_funcs,
-- 
1.7.9.5

[PATCH v2 1/7] drm/exynos: add super device support

This patch adds super device support to bind sub drivers
using device tree.

For this, you should add a super device node to each machine dt files
like belows,

In case of using MIPI-DSI,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <>, <>;
};

In case of using DisplayPort,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <>, <>;
};

In case of using Parallel panel,
display-subsystem {
compatible = "samsung,exynos-display-subsystem";
ports = <>;
};

And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.

ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI

With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.

Previous RFC patch,
 http://www.spinics.net/lists/dri-devel/msg54671.html

Changelog since RFC patch:
- Register sub drivers and probe them at load(). In case of non sub
  drivers, sub driver probe is needed.
- Enable runtime pm at fimd_probe() instead of fimd_bind(). runtime pm
  should be enabled before iommu device is attached to fimd device.
- Do not return an error with component_master_add fail.
- Remove super device support from mipi dsi driver which was in RFC.
- Add super device support to parallel driver.

Changelog v2:
- Add super device support to mipi dsi driver.
- Bind fimd driver only in case that a drm_panel for parallel panel driver
  is added to panel_list of drm_panel module.
- Change super node name to 'display-subsystem'
  . 'exynos-drm' is specific to Linux so change it to generic name.
- Change propery name of super node to 'ports'
  . crtcs and connectors propery names are also specific to Linux so
change them to generic name.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |   45 ---
 drivers/gpu/drm/exynos/exynos_drm_core.c |  216 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   17 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |   16 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  202 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   73 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   38 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   76 ---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   61 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |   45 ---
 drivers/gpu/drm/exynos/exynos_mixer.c|   54 ++--
 12 files changed, 442 insertions(+), 405 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a59bca9..cb9aa58 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -969,16 +970,6 @@ static struct drm_connector_helper_funcs 
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
 };

-static int exynos_dp_initialize(struct exynos_drm_display *display,
-   struct drm_device *drm_dev)
-{
-   struct exynos_dp_device *dp = display->ctx;
-
-   dp->drm_dev = drm_dev;
-
-   return 0;
-}
-
 static bool find_bridge(const char *compat, struct bridge_init *bridge)
 {
bridge->client = NULL;
@@ -1106,7 +1097,6 @@ static void exynos_dp_dpms(struct exynos_drm_display 
*display, int mode)
 }

 static struct exynos_drm_display_ops exynos_dp_display_ops = {
-   .initialize = exynos_dp_initialize,
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
 };
@@ -1230,8 +1220,10 @@ static int exynos_dp_dt_parse_panel(struct 
exynos_dp_device *dp)
return 0;
 }

-static int exynos_dp_probe(struct platform_device *pdev)
+static int exynos_dp_bind(struct device *dev, struct device *master, void 
*data)
 {
+   struct platform_device *pdev = to_platform_device(dev);
+   struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;

@@ -1293,21 +1285,40 @@ static int exynos_dp_probe(struct platform_device *pdev)
}
disable_irq(dp->irq);

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

platform_set_drvdata(pdev, _dp_display);
-   exynos_drm_display_register(_dp_display);

-   return 0;
+   return exynos_drm_create_enc_conn(drm_dev, _dp_display);
 }

-static int exynos_dp_remove(struct platform_device *pdev)
+static void exynos_dp_unbind(struct device *dev, struct device *master,
+   void *data)
 {

[PATCH v2 0/7] drm/exynos: more cleanup with super device support

This patch series cleans up exynos drm framework and kms sub drivers
using the component framework[1].

And this patch series had been posted for RFC[2].

Thanks,
Inki Dae

[1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html
[2] http://comments.gmane.org/gmane.comp.video.dri.devel/101200


Inki Dae (7):
  drm/exynos: add super device support
  drm/exynos: dpi: fix hotplug fail issue
  drm/exynos: register platform driver at each kms sub drivers
  ARM: dts: exynos4210-universal: add super device node for exynos drm
  ARM: dts: exynos4210-trats: add super device node for exynos drm
  ARM: dts: exynos4412-trats2: add super device node for exynos drm
  exynos/drm: add DT bindings

 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 +++
 arch/arm/boot/dts/exynos4210-trats.dts |5 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts|5 +
 arch/arm/boot/dts/exynos4412-trats2.dts|5 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|   46 ++--
 drivers/gpu/drm/exynos/exynos_drm_core.c   |  216 +++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   17 ++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c|   21 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  256 
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   79 +++---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   77 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |   61 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   46 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |   55 -
 16 files changed, 490 insertions(+), 474 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt

-- 
1.7.9.5

[PATCH v3 00/12] Add DSI display support for Exynos based boards

Hi Andrzej,



2014-03-28 20:52 GMT+09:00 Andrzej Hajda :
> Hi,
>
> This patchset adds drivers and bindings to the following devices:
> - Exynos DSI master,
> - S6E8AA0 DSI panel,
>
> It adds also display support in DTS files for the following boards:
> - Exynos4210/Trats,
> - Exynos4412/Trats2.
>
> The patchset is based on exynos_drm_next branch.
>
> It is the 3rd iteration of the patches, main changes:
> - based on exynos_drm_next branch,
> - added video interface bindings between DSI host and slave,
>   it seems to me to be redundand, and I hope when video interface bindings
>   will be stabilized it can become optional,
> - GPIOs implemented using gpiod framework,
> - removed controversial stuff (toshiba bridge implementation and arndale 
> support),
>   it will be send in another set of patches
>
> Other changes are described in individual patches.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (12):
>   drm/mipi_dsi: add flags to DSI messages
>   drm/mipi_dsi: create dsi devices only for nodes with reg property
>   drm/exynos: disallow fbdev initialization if no device is connected
>   exynos/dsim: add DT bindings
>   drm/exynos: add DSIM driver
>   panel/s6e8aa0: add DT bindings
>   drm/panel: add S6E8AA0 driver
>   ARM: dts: exynos4: add MIPI DSI Master node
>   ARM: dts: exynos4210-trats: add panel node
>   ARM: dts: exynos4412-trats2: add panel node
>   ARM: dts: exynos4210-trats: enable exynos/fimd node
>   ARM: dts: exynos4412-trats2: enable exynos/fimd node

Picked up this patch series.

Thanks for your contribution,
Inki Dae

>
>  .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   56 +
>  .../devicetree/bindings/video/exynos_dsim.txt  |   80 +
>  arch/arm/boot/dts/exynos4.dtsi |   14 +
>  arch/arm/boot/dts/exynos4210-trats.dts |   61 +
>  arch/arm/boot/dts/exynos4412-trats2.dts|   70 +
>  drivers/gpu/drm/drm_mipi_dsi.c |6 +-
>  drivers/gpu/drm/exynos/Kconfig |9 +
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   15 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1525 
> 
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   21 +
>  drivers/gpu/drm/panel/Kconfig  |7 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1069 ++
>  include/drm/drm_mipi_dsi.h |6 +
>  16 files changed, 2941 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
>  create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
>  create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c
>
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

2014-04-01 Thread Vandana Kannan

Populate PAR in infoframe structure. PAR is taken from CEA mode list if
VIC is found. Else, PAR is NONE as per initialization.

v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.

v3: Removed calculation of PAR for non-CEA modes as per discussion with
Ville.

v4: Added description for the param video_code. Absence of the description
led to a warning while executing "make htmldocs", as reported by
Wu, Fengguang.
Modified commit message.

A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.

Signed-off-by: Vandana Kannan 
Cc: Jesse Barnes 
Cc: Vijay Purushothaman 
Cc: Ville Syrj?l? 
Cc: intel-gfx at lists.freedesktop.org
Cc: Wu, Fengguang 
Reviewed-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_edid.c | 22 ++
 include/drm/drm_crtc.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d4e3f9d..b8d6c51 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2452,6 +2452,22 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);

+/**
+ * drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
+ * the input VIC from the CEA mode list
+ * @video_code: ID given to each of the CEA modes
+ *
+ * Returns picture aspect ratio
+ */
+enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code)
+{
+   /* return picture aspect ratio for video_code - 1 to access the
+* right array element
+   */
+   return edid_cea_modes[video_code-1].picture_aspect_ratio;
+}
+EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
+
 /*
  * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
  * specific block).
@@ -3613,6 +3629,12 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
frame->video_code = drm_match_cea_mode(mode);

frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+
+   /* Populate picture aspect ratio from CEA mode list */
+   if (frame->video_code > 0)
+   frame->picture_aspect = drm_get_cea_aspect_ratio(
+   frame->video_code);
+
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 27f828c..50dc55a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -983,6 +983,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device *dev,
 extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
+extern enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
 extern bool drm_detect_hdmi_monitor(struct edid *edid);
 extern bool drm_detect_monitor_audio(struct edid *edid);
 extern bool drm_rgb_quant_range_selectable(struct edid *edid);
-- 
1.9.1

[Bug 73911] Color Banding on radeon

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #93321|0   |1
is obsolete||

--- Comment #20 from Alex Deucher  ---
Created attachment 96751
  --> https://bugs.freedesktop.org/attachment.cgi?id=96751=edit
testing patch

Does this patch help?

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

[Bug 76884] Dithering not enabled on 6-bit per channel display

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

Alex Deucher  changed:

   What|Removed |Added

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

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


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

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

[Bug 73911] Color Banding on radeon

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

Alex Deucher  changed:

   What|Removed |Added

 CC||paula at parashep.com

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

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

[Bug 73911] Color Banding on radeon

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

Alex Deucher  changed:

   What|Removed |Added

Summary|Color Banding on R600   |Color Banding on radeon
   |(7660G + 7670M) |

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

[Bug 76919] Random junk at the bottom of non-multiple-of-4 compressed textures (original or mipmapped)

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

Darren Salt  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)
Version|unspecified |10.1

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

[Bug 76919] New: Random junk at the bottom of non-multiple-of-4 compressed textures (original or mipmapped)

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

Priority: medium
Bug ID: 76919
Assignee: dri-devel at lists.freedesktop.org
Summary: Random junk at the bottom of non-multiple-of-4
compressed textures (original or mipmapped)
Severity: normal
Classification: Unclassified
OS: All
Reporter: bugspam at moreofthesa.me.uk
Hardware: Other
Status: NEW
Version: unspecified
Component: Drivers/Gallium/r600
Product: Mesa

Created attachment 96745
--> https://bugs.freedesktop.org/attachment.cgi?id=96745=edit
Example image (with mipmaps), the height of which triggers the problem

There seems to be a problem with some compressed textures. When the height of
the image (more specifically, of the mipmap level used) is not a multiple of 4,
it appears that the bottom part of the image ? as rendered ? contains random
junk, apparently set at image load time.

The example image will show the problem at its original size. I've also played
with its height (initially 570px): increasing it to a multiple of 4 would
remove the problem if it's rendered using the full-size version, but since when
reduced by one level the height is again not a multiple of 4, the problem
re-appears. Setting the full-size height to 576px moves the problem down
further.

(We're using http://crunch.googlecode.com/svn/trunk/ for image
(de)compression.)

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

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

2014-04-01 Thread Laurent Pinchart

Hi Jean-Fran?ois,

Sorry for the late reply.

On Thursday 27 March 2014 12:34:49 Jean-Francois Moine wrote:
> On Wed, 26 Mar 2014 18:33:09 +0100 Laurent Pinchart wrote:
> > That could work in your case, but I don't really like that.
> > 
> > We need to describe the hardware topology, that might be the only point we
> > all agree on. There are various hardware topologies we need to support
> > with different levels of complexity, and several ways to describe them,
> > also with a wide range of complexities and features.
> > 
> > The more complex the hardware topology, the more complex its description
> > needs to be, and the more complex the code that will parse the
> > description and handle the hardware will be. I don't think there's any
> > doubt here.
>
> But also, the simpler is the topology and the simpler should be its
> description.

I wouldn't put it so strongly. I believe we can slightly relax our 
requirements regarding DT bindings complexity as long as drivers remain 
simple. There's of course no reason to use more complex bindings just for the 
sake of it.

> In your approach, the connections between endpoints are described in the
> components themselves, which makes hard for the DT maintainers to have a
> global understanding of the video subsystem.
> 
> Having the topology described in the master device is clearer, even if it is
> complex.

First of all, let's clarify what a "master device" is. In the "simple-video-
card" example you've proposed the master device is a logical device (with a DT 
node that has no corresponding hardware device). The second approach I can 
think of is to make the IP core that implements the CRTC (which I usually call 
display controller) be the master device. Let's note that the second case 
makes both the link and "global description" DT binding styles possible.

My concern with the "global description" bindings style is that the approach 
only applies to simple hardware and can't be generalized. Now, I'm not too 
concerned about using that approach for simple hardware and a link-based 
approach for more complex hardware. The "slave" components, however, need to 
use a single DT bindings style, regardless of the DT bindings used by the 
master device. That's why I believe we should try to standardize one DT 
bindings style for master devices, even if it results in a slightly more 
complex DT description than strictly needed in some cases.

> > A given device can be integrated in a wide variety of hardware with
> > different complexities. A driver can't thus always assume that the whole
> > composite display device will match a given class of topologies. This is
> > especially true for encoders and connectors, they can be hooked up
> > directly at the output of a very simple display controller, or can be
> > part of a very complex graph. Encoder and connector drivers can't assume
> > much about how they will be integrated. I want to avoid a situation where
> > using an HDMI encoder already supported in mainline with a different SoC
> > will result in having to rewrite the HDMI encoder driver.
> 
> The tda998x chips are simple enough for being used in many boards: one video
> input and one serial digital output. I don't see in which circumstance the
> driver should be rewritten.

It shouldn't, that's the whole point ;-) I wasn't talking about the tda998x 
only, but about encoder drivers in general. I have a display controller in a 
Renesas SoC that has two LVDS encoders that output LVDS signals out of the 
SoC. One LVDS port is connected to an LVDS panel (a connector from a DRM point 
of view), the second one to an LVDS receiver that outputs parallel RGB data to 
an HDMI encoder. The LVDS encoder can't thus assume any particular downstream 
topology and its driver thus can't create DRM encoder and connector instances. 
The same could be true for an HDMI encoder in theory, although an HDMI encoder 
connected on the same board directly to an HDMI decoder that outputs RGB data 
to a panel is probably a case that will be rarely seen in practice.

In the general case an encoder driver can't assume any specific upstream or 
downstream topology. As long as DRM can't expose the real hardware topology to 
userspace, someone needs to decide on how to map the hardware topology to the 
DRM topology exposed to userspace. Encoder drivers can't take that role and 
thus shouldn't create DRM encoder and connector instances themselves.

> > The story is a bit different for display controllers. While the hardware
> > topology outside (and sometimes inside as well) of the SoC can vary, a
> > display controller often approximately implies a given level of
> > complexity. A cheap SoC with a simple display controller will likely not
> > be used to drive a 4k display requiring 4 encoders running in parallel
> > for instance. While I also want to avoid having to make significant
> > changes to a display controller driver when using the SoC on a different
> > board, I believe the

[PATCH v3] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

2014-04-01 Thread Vandana Kannan

Populate PAR in infoframe structure. If there is a user setting for PAR, then
that value is set. Else, value is taken from CEA mode list if VIC is found.
Else, PAR is calculated from resolution. If none of these conditions are
satisfied, PAR is NONE as per initialization.

v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.

v3: Removed calculation of PAR for non-CEA modes as per discussion with
Ville.

A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.

Signed-off-by: Vandana Kannan 
Cc: Jesse Barnes 
Cc: Vijay Purushothaman 
Cc: Ville Syrj?l? 
Cc: intel-gfx at lists.freedesktop.org
Reviewed-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_edid.c | 21 +
 include/drm/drm_crtc.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d4e3f9d..09ece10 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2452,6 +2452,21 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);

+/**
+ * drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
+ * the input VIC from the CEA mode list
+ *
+ * Returns picture aspect ratio
+ */
+enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code)
+{
+   /* return picture aspect ratio for video_code - 1 to access the
+* right array element
+   */
+   return edid_cea_modes[video_code-1].picture_aspect_ratio;
+}
+EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
+
 /*
  * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
  * specific block).
@@ -3613,6 +3628,12 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
frame->video_code = drm_match_cea_mode(mode);

frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+
+   /* Populate picture aspect ratio from CEA mode list */
+   if (frame->video_code > 0)
+   frame->picture_aspect = drm_get_cea_aspect_ratio(
+   frame->video_code);
+
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 27f828c..50dc55a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -983,6 +983,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device *dev,
 extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
+extern enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
 extern bool drm_detect_hdmi_monitor(struct edid *edid);
 extern bool drm_detect_monitor_audio(struct edid *edid);
 extern bool drm_rgb_quant_range_selectable(struct edid *edid);
-- 
1.9.1

[Bug 72701] Screen freeze when using radeon driver

2014-04-01 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #8 from Alex Deucher  ---
(In reply to klod from comment #7)
> I think those patches are applied in 3.14 and 3.13.8, but i still need to
> use radeon.runpm=0 in order to boot with my discrete card.

You have a PX system so those patches are not relevant for you.  It seems runpm
is not working properly on your system. Booting with radeon.runpm=0 reverts
back to the 3.12 behavior (PX dGPUs are not dynamically powered down).

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

[Bug 72701] Screen freeze when using radeon driver

2014-04-01 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #7 from klod  ---
I think those patches are applied in 3.14 and 3.13.8, but i still need to use
radeon.runpm=0 in order to boot with my discrete card.

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

[PATCH v4] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Tue, Apr 01, 2014 at 09:07:50PM +0530, Vandana Kannan wrote:
> Populate PAR in infoframe structure. PAR is taken from CEA mode list if
> VIC is found. Else, PAR is NONE as per initialization.
> 
> v2: Removed the part which sets PAR according to user input, based on
> Daniel's review comments.
> 
> v3: Removed calculation of PAR for non-CEA modes as per discussion with
> Ville.
> 
> v4: Added description for the param video_code. Absence of the description
> led to a warning while executing "make htmldocs", as reported by
> Wu, Fengguang.
> Modified commit message.
> 
> A separate patch will be submitted to create a property that would enable a
> user space app to set aspect ratio for AVI infoframe.
> 
> Signed-off-by: Vandana Kannan 
> Cc: Jesse Barnes 
> Cc: Vijay Purushothaman 
> Cc: Ville Syrj?l? 
> Cc: intel-gfx at lists.freedesktop.org
> Cc: Wu, Fengguang 
> Reviewed-by: Jesse Barnes 

Applied. btw if I've merged a patch already I prefer a small fixup patch
on top of what I have to squash into the main patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_edid.c | 22 ++
>  include/drm/drm_crtc.h |  1 +
>  2 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d4e3f9d..b8d6c51 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2452,6 +2452,22 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match)
>  }
>  EXPORT_SYMBOL(drm_match_cea_mode);
>  
> +/**
> + * drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
> + * the input VIC from the CEA mode list
> + * @video_code: ID given to each of the CEA modes
> + *
> + * Returns picture aspect ratio
> + */
> +enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code)
> +{
> + /* return picture aspect ratio for video_code - 1 to access the
> +  * right array element
> + */
> + return edid_cea_modes[video_code-1].picture_aspect_ratio;
> +}
> +EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
> +
>  /*
>   * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
>   * specific block).
> @@ -3613,6 +3629,12 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> hdmi_avi_infoframe *frame,
>   frame->video_code = drm_match_cea_mode(mode);
>  
>   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> +
> + /* Populate picture aspect ratio from CEA mode list */
> + if (frame->video_code > 0)
> + frame->picture_aspect = drm_get_cea_aspect_ratio(
> + frame->video_code);
> +
>   frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
>   frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 27f828c..50dc55a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -983,6 +983,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device 
> *dev,
>  extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
>   void *data, struct drm_file *file_priv);
>  extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> +extern enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 
> video_code);
>  extern bool drm_detect_hdmi_monitor(struct edid *edid);
>  extern bool drm_detect_monitor_audio(struct edid *edid);
>  extern bool drm_rgb_quant_range_selectable(struct edid *edid);
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH v3] drm/edid: Fill PAR in AVI infoframe based on CEA mode list