[PATCHv15 0/7] of: add display helper

[PATCHv15 0/7] of: add display helper

[Steffen Trumtrar]

Hi!

Changes since v14:
	- fix "const struct *" warning
		(reported by: Leela Krishna Amudala <l.krishna@samsung.com>)
	- return -EINVAL when htotal or vtotal are zero
	- remove unreachable code in of_get_display_timings
	- include headers in .c files and not implicit in .h
	- sort includes alphabetically
	- fix lower/uppercase in binding documentation
	- rebase onto v3.7-rc7

Changes since v13:
	- fix "const struct *" warning
		(reported by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>)
	- prevent division by zero in fb_videomode_from_videomode

Changes since v12:
	- rename struct display_timing to via_display_timing in via subsystem
	- fix refreshrate calculation
	- fix "const struct *" warnings
		(reported by: Manjunathappa, Prakash <prakash.pm@ti.com>)
	- some CodingStyle fixes
	- rewrite parts of commit messages and display-timings.txt
	- let display_timing_get_value get all values instead of just typical

Changes since v11:
	- make pointers const where applicable
	- add reviewed-by Laurent Pinchart

Changes since v10:
	- fix function name (drm_)display_mode_from_videomode
	- add acked-by, reviewed-by, tested-by

Changes since v9:
	- don't leak memory when previous timings were correct
	- CodingStyle fixes
	- move blank lines around

Changes since v8:
	- fix memory leaks
	- change API to be more consistent (foo_from_bar(struct bar, struct foo))
	- include headers were necessary
	- misc minor bufixe

Changes since v7:
	- move of_xxx to drivers/video
	- remove non-binding documentation from display-timings.txt
	- squash display_timings and videomode in one patch
	- misc minor fixes

Changes since v6:
	- get rid of some empty lines etc.
	- move functions to their subsystems
	- split of_ from non-of_ functions
	- add at least some kerneldoc to some functions

Changes since v5:
	- removed all display stuff and just describe timings

Changes since v4:
	- refactored functions

Changes since v3:
	- print error messages
	- free alloced memory
	- general cleanup

Changes since v2:
	- use hardware-near property-names
	- provide a videomode structure
	- allow ranges for all properties (<min,typ,max>)
	- functions to get display_mode or fb_videomode


Steffen Trumtrar (7):
  viafb: rename display_timing to via_display_timing
  video: add display_timing and videomode
  video: add of helper for display timings/videomode
  fbmon: add videomode helpers
  fbmon: add of_videomode helpers
  drm_modes: add videomode helpers
  drm_modes: add of_videomode helpers

 .../devicetree/bindings/video/display-timing.txt   |  107 ++++++++++
 drivers/gpu/drm/drm_modes.c                        |   70 +++++++
 drivers/video/Kconfig                              |   21 ++
 drivers/video/Makefile                             |    4 +
 drivers/video/display_timing.c                     |   24 +++
 drivers/video/fbmon.c                              |   93 +++++++++
 drivers/video/of_display_timing.c                  |  219 ++++++++++++++++++++
 drivers/video/of_videomode.c                       |   54 +++++
 drivers/video/via/hw.c                             |    6 +-
 drivers/video/via/hw.h                             |    2 +-
 drivers/video/via/lcd.c                            |    2 +-
 drivers/video/via/share.h                          |    2 +-
 drivers/video/via/via_modesetting.c                |    8 +-
 drivers/video/via/via_modesetting.h                |    6 +-
 drivers/video/videomode.c                          |   44 ++++
 include/drm/drmP.h                                 |   13 ++
 include/linux/display_timing.h                     |  104 ++++++++++
 include/linux/fb.h                                 |   12 ++
 include/linux/of_display_timing.h                  |   20 ++
 include/linux/of_videomode.h                       |   18 ++
 include/linux/videomode.h                          |   54 +++++
 21 files changed, 870 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/of_display_timing.h
 create mode 100644 include/linux/of_videomode.h
 create mode 100644 include/linux/videomode.h

-- 
1.7.10.4

[PATCHv15 1/7] viafb: rename display_timing to via_display_timing

[Steffen Trumtrar]

The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, that is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 drivers/video/via/hw.c              |    6 +++---
 drivers/video/via/hw.h              |    2 +-
 drivers/video/via/lcd.c             |    2 +-
 drivers/video/via/share.h           |    2 +-
 drivers/video/via/via_modesetting.c |    8 ++++----
 drivers/video/via/via_modesetting.h |    6 +++---
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
 	via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
 }
 
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
 	u16 cxres, u16 cyres)
 {
-	struct display_timing timing;
+	struct via_display_timing timing;
 	u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;
 
 	timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
 void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
 	u16 cxres, u16 cyres, int iga)
 {
-	struct display_timing crt_reg = var_to_timing(var,
+	struct via_display_timing crt_reg = var_to_timing(var,
 		cxres ? cxres : var->xres, cyres ? cyres : var->yres);
 
 	if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
 extern int viafb_DVI_ON;
 extern int viafb_hotplug;
 
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
 	u16 cxres, u16 cyres);
 void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
 	u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
 	int panel_hres = plvds_setting_info->lcd_panel_hres;
 	int panel_vres = plvds_setting_info->lcd_panel_vres;
 	u32 clock;
-	struct display_timing timing;
+	struct via_display_timing timing;
 	struct fb_var_screeninfo panel_var;
 	const struct fb_videomode *mode_crt_table, *panel_crt_table;
 
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
 	int refresh_rate;
 	int h_sync_polarity;
 	int v_sync_polarity;
-	struct display_timing crtc;
+	struct via_display_timing crtc;
 };
 
 struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
 #include "debug.h"
 
 
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
 {
-	struct display_timing raw;
+	struct via_display_timing raw;
 
 	raw.hor_total = timing->hor_total / 8 - 5;
 	raw.hor_addr = timing->hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing *timing)
 	via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
 }
 
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
 {
-	struct display_timing raw;
+	struct via_display_timing raw;
 
 	raw.hor_total = timing->hor_total - 1;
 	raw.hor_addr = timing->hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
 #define VIA_PITCH_MAX	0x3FF8
 
 
-struct display_timing {
+struct via_display_timing {
 	u16 hor_total;
 	u16 hor_addr;
 	u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
 };
 
 
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing *timing);
 void via_set_primary_address(u32 addr);
 void via_set_secondary_address(u32 addr);
 void via_set_primary_pitch(u32 pitch);
-- 
1.7.10.4

[PATCHv15 2/7] video: add display_timing and videomode

[Steffen Trumtrar]

Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.

Also, add helper functions to convert from display timings to a generic videomode
structure.

The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
	- ranges for signals that may have min-, max- and typical values
	- single integers for signals that can be on, off or are ignored
	- booleans for signals that are either on or off

As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.

Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.

The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.

This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/Kconfig          |    6 +++
 drivers/video/Makefile         |    2 +
 drivers/video/display_timing.c |   24 ++++++++++
 drivers/video/videomode.c      |   44 +++++++++++++++++
 include/linux/display_timing.h |  104 ++++++++++++++++++++++++++++++++++++++++
 include/linux/videomode.h      |   54 +++++++++++++++++++++
 6 files changed, 234 insertions(+)
 create mode 100644 drivers/video/display_timing.c
 create mode 100644 drivers/video/videomode.c
 create mode 100644 include/linux/display_timing.h
 create mode 100644 include/linux/videomode.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
 	  This framework adds support for low-level control of the video 
 	  output switch.
 
+config DISPLAY_TIMING
+       bool
+
+config VIDEOMODE
+       bool
+
 menuconfig FB
 	tristate "Support for frame buffer devices"
 	---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
 
 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 0000000..ac9bbbc
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/display_timing.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+
+void display_timings_release(struct display_timings *disp)
+{
+	if (disp->timings) {
+		unsigned int i;
+
+		for (i = 0; i < disp->num_timings; i++)
+			kfree(disp->timings[i]);
+		kfree(disp->timings);
+	}
+	kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 0000000..784eaad
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,44 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/display_timing.h>
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/videomode.h>
+
+int videomode_from_timing(const struct display_timings *disp,
+			  struct videomode *vm, unsigned int index)
+{
+	struct display_timing *dt;
+
+	dt = display_timings_get(disp, index);
+	if (!dt)
+		return -EINVAL;
+
+	vm->pixelclock = display_timing_get_value(&dt->pixelclock, TE_TYP);
+	vm->hactive = display_timing_get_value(&dt->hactive, TE_TYP);
+	vm->hfront_porch = display_timing_get_value(&dt->hfront_porch, TE_TYP);
+	vm->hback_porch = display_timing_get_value(&dt->hback_porch, TE_TYP);
+	vm->hsync_len = display_timing_get_value(&dt->hsync_len, TE_TYP);
+
+	vm->vactive = display_timing_get_value(&dt->vactive, TE_TYP);
+	vm->vfront_porch = display_timing_get_value(&dt->vfront_porch, TE_TYP);
+	vm->vback_porch = display_timing_get_value(&dt->vback_porch, TE_TYP);
+	vm->vsync_len = display_timing_get_value(&dt->vsync_len, TE_TYP);
+
+	vm->vah = dt->vsync_pol_active;
+	vm->hah = dt->hsync_pol_active;
+	vm->de = dt->de_pol_active;
+	vm->pixelclk_pol = dt->pixelclk_pol;
+
+	vm->interlaced = dt->interlaced;
+	vm->doublescan = dt->doublescan;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_from_timing);
diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h
new file mode 100644
index 0000000..4986364
--- /dev/null
+++ b/include/linux/display_timing.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_DISPLAY_TIMING_H
+#define __LINUX_DISPLAY_TIMING_H
+
+#include <linux/types.h>
+
+/*
+ * A single signal can be specified via a range with a typical value, that lies
+ * somewhere inbetween. Do not use an array, to prevent any confusion about the
+ * meaning of every entry.
+ */
+struct timing_entry {
+	u32 min;
+	u32 typ;
+	u32 max;
+};
+
+enum timing_entry_index {
+	TE_MIN = 0,
+	TE_TYP = 1,
+	TE_MAX = 2,
+};
+
+/*
+ * Single "mode" entry. This describes one set of signal timings a display can
+ * have in one setting. This struct can later be converted to struct videomode
+ * (see include/linux/videomode.h). As each timing_entry can be defined as a
+ * range, one struct display_timing may become multiple struct videomodes.
+ */
+struct display_timing {
+	struct timing_entry pixelclock;
+
+	struct timing_entry hactive;
+	struct timing_entry hfront_porch;
+	struct timing_entry hback_porch;
+	struct timing_entry hsync_len;
+
+	struct timing_entry vactive;
+	struct timing_entry vfront_porch;
+	struct timing_entry vback_porch;
+	struct timing_entry vsync_len;
+
+	unsigned int vsync_pol_active;
+	unsigned int hsync_pol_active;
+	unsigned int de_pol_active;
+	unsigned int pixelclk_pol;
+	bool interlaced;
+	bool doublescan;
+};
+
+/*
+ * This describes all timing settings a display provides.
+ * The native_mode is the default setting for this display. It can be specified
+ * in the devicetree or will be the first that is provided. Drivers that can
+ * handle multiple videomode should work with this struct and convert each entry
+ * to the desired end result.
+ */
+struct display_timings {
+	unsigned int num_timings;
+	unsigned int native_mode;
+
+	struct display_timing **timings;
+};
+
+/* get value specified by index from struct timing_entry */
+static inline u32 display_timing_get_value(const struct timing_entry *te,
+					   enum timing_entry_index index)
+{
+	switch (index) {
+	case TE_MIN:
+		return te->min;
+		break;
+	case TE_TYP:
+		return te->typ;
+		break;
+	case TE_MAX:
+		return te->max;
+		break;
+	default:
+		return te->typ;
+	}
+}
+
+/* get one entry from struct display_timings */
+static inline struct display_timing *display_timings_get(const struct
+							 display_timings *disp,
+							 unsigned int index)
+{
+	if (disp->num_timings > index)
+		return disp->timings[index];
+	else
+		return NULL;
+}
+
+void display_timings_release(struct display_timings *disp);
+
+#endif
diff --git a/include/linux/videomode.h b/include/linux/videomode.h
new file mode 100644
index 0000000..562f490
--- /dev/null
+++ b/include/linux/videomode.h
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * generic videomode description
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_VIDEOMODE_H
+#define __LINUX_VIDEOMODE_H
+
+#include <linux/types.h>
+
+struct display_timings;
+
+/*
+ * Subsystem independent description of a videomode.
+ * Can be generated from struct display_timing.
+ */
+struct videomode {
+	u32 pixelclock;		/* pixelclock in Hz */
+
+	u32 hactive;
+	u32 hfront_porch;
+	u32 hback_porch;
+	u32 hsync_len;
+
+	u32 vactive;
+	u32 vfront_porch;
+	u32 vback_porch;
+	u32 vsync_len;
+
+	u32 hah;		/* hsync active high */
+	u32 vah;		/* vsync active high */
+	u32 de;			/* data enable */
+	u32 pixelclk_pol;
+
+	bool interlaced;
+	bool doublescan;
+};
+
+/**
+ * videomode_from_timing - convert display timing to videomode
+ * @disp: structure with all possible timing entries
+ * @vm: return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function converts a struct display_timing to a struct videomode.
+ */
+int videomode_from_timing(const struct display_timings *disp,
+			  struct videomode *vm, unsigned int index);
+
+#endif
-- 
1.7.10.4

[PATCHv15 3/7] video: add of helper for display timings/videomode

[Steffen Trumtrar]

This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.

If no native mode is specified, the first subnode will be used.

For cases where the graphics driver knows there can be only one
mode description or where the driver only supports one mode, a helper
function of_get_videomode is added, that gets a struct videomode from DT.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 .../devicetree/bindings/video/display-timing.txt   |  107 ++++++++++
 drivers/video/Kconfig                              |   15 ++
 drivers/video/Makefile                             |    2 +
 drivers/video/of_display_timing.c                  |  219 ++++++++++++++++++++
 drivers/video/of_videomode.c                       |   54 +++++
 include/linux/of_display_timing.h                  |   20 ++
 include/linux/of_videomode.h                       |   18 ++
 7 files changed, 435 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
 create mode 100644 drivers/video/of_display_timing.c
 create mode 100644 drivers/video/of_videomode.c
 create mode 100644 include/linux/of_display_timing.h
 create mode 100644 include/linux/of_videomode.h

diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
new file mode 100644
index 0000000..e238f27
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timing.txt
@@ -0,0 +1,107 @@
+display-timing bindings
+=======================
+
+display-timings node
+--------------------
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+		provided. When omitted, assume the first node is the native.
+
+timing subnode
+--------------
+
+required properties:
+ - hactive, vactive: display resolution
+ - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
+   in pixels
+   vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
+   lines
+ - clock-frequency: display clock in Hz
+
+optional properties:
+ - hsync-active: hsync pulse is active low/high/ignored
+ - vsync-active: vsync pulse is active low/high/ignored
+ - de-active: data-enable pulse is active low/high/ignored
+ - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
+				non-inverted (active on rising edge)/
+				     ignored (ignore property)
+ - interlaced (bool): boolean to enable interlaced mode
+ - doublescan (bool): boolean to enable doublescan mode
+ - doubleclk (bool)
+
+All the optional properties that are not bool follow the following logic:
+    <1>: high active
+    <0>: low active
+    omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The devicetree
+representation corresponds to the one commonly found in datasheets for displays.
+If a display supports multiple signal timings, the native-mode can be specified.
+
+The parameters are defined as
+
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ↑                            |          |       |
+  |          |                |vback_porch                 |          |       |
+  |          |                ↓                            |          |       |
+  +----------###############################################----------+-------+
+  |          #                ↑                            #          |       |
+  |          #                |                            #          |       |
+  |  hback   #                |                            #  hfront  | hsync |
+  |   porch  #                |       hactive              #  porch   |  len  |
+  |<-------->#<---------------+--------------------------->#<-------->|<----->|
+  |          #                |                            #          |       |
+  |          #                |vactive                     #          |       |
+  |          #                |                            #          |       |
+  |          #                ↓                            #          |       |
+  +----------###############################################----------+-------+
+  |          |                ↑                            |          |       |
+  |          |                |vfront_porch                |          |       |
+  |          |                ↓                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ↑                            |          |       |
+  |          |                |vsync_len                   |          |       |
+  |          |                ↓                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+
+
+Example:
+
+	display-timings {
+		native-mode = <&timing0>;
+		timing0: 1080p24 {
+			/* 1920x1080p24 */
+			clock-frequency = <52000000>;
+			hactive = <1920>;
+			vactive = <1080>;
+			hfront-porch = <25>;
+			hback-porch = <25>;
+			hsync-len = <25>;
+			vback-porch = <2>;
+			vfront-porch = <2>;
+			vsync-len = <2>;
+			hsync-active = <1>;
+		};
+	};
+
+Every required property also supports the use of ranges, so the commonly used
+datasheet description with <min typ max>-tuples can be used.
+
+Example:
+
+	timing1: timing {
+		/* 1920x1080p24 */
+		clock-frequency = <148500000>;
+		hactive = <1920>;
+		vactive = <1080>;
+		hsync-len = <0 44 60>;
+		hfront-porch = <80 88 95>;
+		hback-porch = <100 148 160>;
+		vfront-porch = <0 4 6>;
+		vback-porch = <0 36 50>;
+		vsync-len = <0 5 6>;
+	};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2a23b18..c000f5a 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -39,6 +39,21 @@ config DISPLAY_TIMING
 config VIDEOMODE
        bool
 
+config OF_DISPLAY_TIMING
+	bool "Enable device tree display timing support"
+	depends on OF
+	select DISPLAY_TIMING
+	help
+	  helper to parse display timings from the devicetree
+
+config OF_VIDEOMODE
+	bool "Enable device tree videomode support"
+	depends on OF
+	select VIDEOMODE
+	select OF_DISPLAY_TIMING
+	help
+	  helper to get videomodes from the devicetree
+
 menuconfig FB
 	tristate "Support for frame buffer devices"
 	---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index fc30439..b936b00 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -168,4 +168,6 @@ obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
 #video output switch sysfs driver
 obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
 obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_OF_DISPLAY_TIMING) += of_display_timing.o
 obj-$(CONFIG_VIDEOMODE) += videomode.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
new file mode 100644
index 0000000..b6c549e
--- /dev/null
+++ b/drivers/video/of_display_timing.c
@@ -0,0 +1,219 @@
+/*
+ * OF helpers for parsing display timings
+ *
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * based on of_videomode.c by Sascha Hauer <s.hauer@pengutronix.de>
+ *
+ * This file is released under the GPLv2
+ */
+#include <linux/display_timing.h>
+#include <linux/export.h>
+#include <linux/of.h>
+#include <linux/of_display_timing.h>
+#include <linux/slab.h>
+
+/**
+ * parse_property - parse timing_entry from device_node
+ * @np: device_node with the property
+ * @name: name of the property
+ * @result: will be set to the return value
+ *
+ * DESCRIPTION:
+ * Every display_timing can be specified with either just the typical value or
+ * a range consisting of min/typ/max. This function helps handling this
+ **/
+static int parse_property(const struct device_node *np, const char *name,
+			  struct timing_entry *result)
+{
+	struct property *prop;
+	int length, cells, ret;
+
+	prop = of_find_property(np, name, &length);
+	if (!prop) {
+		pr_err("%s: could not find property %s\n", __func__, name);
+		return -EINVAL;
+	}
+
+	cells = length / sizeof(u32);
+	if (cells == 1) {
+		ret = of_property_read_u32(np, name, &result->typ);
+		result->min = result->typ;
+		result->max = result->typ;
+	} else if (cells == 3) {
+		ret = of_property_read_u32_array(np, name, &result->min, cells);
+	} else {
+		pr_err("%s: illegal timing specification in %s\n", __func__,
+			name);
+		return -EINVAL;
+	}
+
+	return ret;
+}
+
+/**
+ * of_get_display_timing - parse display_timing entry from device_node
+ * @np: device_node with the properties
+ **/
+static struct display_timing *of_get_display_timing(const struct device_node
+						    *np)
+{
+	struct display_timing *dt;
+	int ret = 0;
+
+	dt = kzalloc(sizeof(*dt), GFP_KERNEL);
+	if (!dt) {
+		pr_err("%s: could not allocate display_timing struct\n",
+			__func__);
+		return NULL;
+	}
+
+	ret |= parse_property(np, "hback-porch", &dt->hback_porch);
+	ret |= parse_property(np, "hfront-porch", &dt->hfront_porch);
+	ret |= parse_property(np, "hactive", &dt->hactive);
+	ret |= parse_property(np, "hsync-len", &dt->hsync_len);
+	ret |= parse_property(np, "vback-porch", &dt->vback_porch);
+	ret |= parse_property(np, "vfront-porch", &dt->vfront_porch);
+	ret |= parse_property(np, "vactive", &dt->vactive);
+	ret |= parse_property(np, "vsync-len", &dt->vsync_len);
+	ret |= parse_property(np, "clock-frequency", &dt->pixelclock);
+
+	of_property_read_u32(np, "vsync-active", &dt->vsync_pol_active);
+	of_property_read_u32(np, "hsync-active", &dt->hsync_pol_active);
+	of_property_read_u32(np, "de-active", &dt->de_pol_active);
+	of_property_read_u32(np, "pixelclk-inverted", &dt->pixelclk_pol);
+	dt->interlaced = of_property_read_bool(np, "interlaced");
+	dt->doublescan = of_property_read_bool(np, "doublescan");
+
+	if (ret) {
+		pr_err("%s: error reading timing properties\n", __func__);
+		kfree(dt);
+		return NULL;
+	}
+
+	return dt;
+}
+
+/**
+ * of_get_display_timings - parse all display_timing entries from a device_node
+ * @np: device_node with the subnodes
+ **/
+struct display_timings *of_get_display_timings(struct device_node *np)
+{
+	struct device_node *timings_np;
+	struct device_node *entry;
+	struct device_node *native_mode;
+	struct display_timings *disp;
+
+	if (!np) {
+		pr_err("%s: no devicenode given\n", __func__);
+		return NULL;
+	}
+
+	timings_np = of_find_node_by_name(np, "display-timings");
+	if (!timings_np) {
+		pr_err("%s: could not find display-timings node\n", __func__);
+		return NULL;
+	}
+
+	disp = kzalloc(sizeof(*disp), GFP_KERNEL);
+	if (!disp) {
+		pr_err("%s: could not allocate struct disp'\n", __func__);
+		goto dispfail;
+	}
+
+	entry = of_parse_phandle(timings_np, "native-mode", 0);
+	/* assume first child as native mode if none provided */
+	if (!entry)
+		entry = of_get_next_child(np, NULL);
+	/* if there is no child, it is useless to go on */
+	if (!entry) {
+		pr_err("%s: no timing specifications given\n", __func__);
+		goto entryfail;
+	}
+
+	pr_info("%s: using %s as default timing\n", __func__, entry->name);
+
+	native_mode = entry;
+
+	disp->num_timings = of_get_child_count(timings_np);
+	if (disp->num_timings == 0) {
+		/* should never happen, as entry was already found above */
+		pr_err("%s: no timings specified\n", __func__);
+		goto entryfail;
+	}
+
+	disp->timings = kzalloc(sizeof(struct display_timing *) * disp->num_timings,
+				GFP_KERNEL);
+	if (!disp->timings) {
+		pr_err("%s: could not allocate timings array\n", __func__);
+		goto entryfail;
+	}
+
+	disp->num_timings = 0;
+	disp->native_mode = 0;
+
+	for_each_child_of_node(timings_np, entry) {
+		struct display_timing *dt;
+
+		dt = of_get_display_timing(entry);
+		if (!dt) {
+			/*
+			 * to not encourage wrong devicetrees, fail in case of
+			 * an error
+			 */
+			pr_err("%s: error in timing %d\n", __func__,
+			       disp->num_timings + 1);
+			goto timingfail;
+		}
+
+		if (native_mode == entry)
+			disp->native_mode = disp->num_timings;
+
+		disp->timings[disp->num_timings] = dt;
+		disp->num_timings++;
+	}
+	of_node_put(timings_np);
+	/*
+	 * native_mode points to the device_node returned by of_parse_phandle
+	 * therefore call of_node_put on it
+	 */
+	of_node_put(native_mode);
+
+	pr_info("%s: got %d timings. Using timing #%d as default\n",
+		__func__, disp->num_timings, disp->native_mode + 1);
+
+	return disp;
+
+timingfail:
+	if (native_mode)
+		of_node_put(native_mode);
+	display_timings_release(disp);
+entryfail:
+	if (disp)
+		kfree(disp);
+dispfail:
+	of_node_put(timings_np);
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(of_get_display_timings);
+
+/**
+ * of_display_timings_exists - check if a display-timings node is provided
+ * @np: device_node with the timing
+ **/
+int of_display_timings_exists(struct device_node *np)
+{
+	struct device_node *timings_np;
+
+	if (!np)
+		return -EINVAL;
+
+	timings_np = of_parse_phandle(np, "display-timings", 0);
+	if (!timings_np)
+		return -EINVAL;
+
+	of_node_put(timings_np);
+	return 1;
+}
+EXPORT_SYMBOL_GPL(of_display_timings_exists);
diff --git a/drivers/video/of_videomode.c b/drivers/video/of_videomode.c
new file mode 100644
index 0000000..38d4a64
--- /dev/null
+++ b/drivers/video/of_videomode.c
@@ -0,0 +1,54 @@
+/*
+ * generic videomode helper
+ *
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+#include <linux/display_timing.h>
+#include <linux/errno.h>
+#include <linux/export.h>
+#include <linux/of.h>
+#include <linux/of_display_timing.h>
+#include <linux/of_videomode.h>
+#include <linux/videomode.h>
+
+/**
+ * of_get_videomode - get the videomode #<index> from devicetree
+ * @np - devicenode with the display_timings
+ * @vm - set to return value
+ * @index - index into list of display_timings
+ *	    (Set this to OF_USE_NATIVE_MODE to use whatever mode is
+ *	     specified as native mode in the DT.)
+ *
+ * DESCRIPTION:
+ * Get a list of all display timings and put the one
+ * specified by index into *vm. This function should only be used, if
+ * only one videomode is to be retrieved. A driver that needs to work
+ * with multiple/all videomodes should work with
+ * of_get_display_timings instead.
+ **/
+int of_get_videomode(struct device_node *np, struct videomode *vm,
+		     int index)
+{
+	struct display_timings *disp;
+	int ret;
+
+	disp = of_get_display_timings(np);
+	if (!disp) {
+		pr_err("%s: no timings specified\n", __func__);
+		return -EINVAL;
+	}
+
+	if (index == OF_USE_NATIVE_MODE)
+		index = disp->native_mode;
+
+	ret = videomode_from_timing(disp, vm, index);
+	if (ret)
+		return ret;
+
+	display_timings_release(disp);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_videomode);
diff --git a/include/linux/of_display_timing.h b/include/linux/of_display_timing.h
new file mode 100644
index 0000000..31e9695
--- /dev/null
+++ b/include/linux/of_display_timing.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * display timings of helpers
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_DISPLAY_TIMING_H
+#define __LINUX_OF_DISPLAY_TIMING_H
+
+struct device_node;
+struct display_timings;
+
+#define OF_USE_NATIVE_MODE -1
+
+struct display_timings *of_get_display_timings(struct device_node *np);
+int of_display_timings_exists(struct device_node *np);
+
+#endif
diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
new file mode 100644
index 0000000..a07efcc
--- /dev/null
+++ b/include/linux/of_videomode.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * videomode of-helpers
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_VIDEOMODE_H
+#define __LINUX_OF_VIDEOMODE_H
+
+struct device_node;
+struct videomode;
+
+int of_get_videomode(struct device_node *np, struct videomode *vm,
+		     int index);
+
+#endif /* __LINUX_OF_VIDEOMODE_H */
-- 
1.7.10.4

[PATCHv15 4/7] fbmon: add videomode helpers

[Steffen Trumtrar]

Add a function to convert from the generic videomode to a fb_videomode.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 drivers/video/fbmon.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/fb.h    |    6 ++++++
 2 files changed, 57 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..733553b 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -30,6 +30,7 @@
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/slab.h>
+#include <linux/videomode.h>
 #include <video/edid.h>
 #ifdef CONFIG_PPC_OF
 #include <asm/prom.h>
@@ -1373,6 +1374,56 @@ int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_inf
 	kfree(timings);
 	return err;
 }
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+				struct fb_videomode *fbmode)
+{
+	unsigned int htotal, vtotal;
+
+	fbmode->xres = vm->hactive;
+	fbmode->left_margin = vm->hback_porch;
+	fbmode->right_margin = vm->hfront_porch;
+	fbmode->hsync_len = vm->hsync_len;
+
+	fbmode->yres = vm->vactive;
+	fbmode->upper_margin = vm->vback_porch;
+	fbmode->lower_margin = vm->vfront_porch;
+	fbmode->vsync_len = vm->vsync_len;
+
+	/* prevent division by zero in KHZ2PICOS macro */
+	fbmode->pixclock = vm->pixelclock ? KHZ2PICOS(vm->pixelclock / 1000) : 0;
+
+	fbmode->sync = 0;
+	fbmode->vmode = 0;
+	if (vm->hah)
+		fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+	if (vm->vah)
+		fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+	if (vm->interlaced)
+		fbmode->vmode |= FB_VMODE_INTERLACED;
+	if (vm->doublescan)
+		fbmode->vmode |= FB_VMODE_DOUBLE;
+	fbmode->flag = 0;
+
+	htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
+		 vm->hsync_len;
+	vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
+		 vm->vsync_len;
+	/* prevent division by zero */
+	if (htotal && vtotal)
+		fbmode->refresh = vm->pixelclock / (htotal * vtotal);
+	/* a mode must have htotal and vtotal != 0 or it is invalid */
+	else {
+		fbmode->refresh = 0;
+		return -EINVAL;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..4404ec2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
 struct fb_info;
 struct device;
 struct file;
+struct videomode;
 
 /* Definitions below are used in the parsed monitor specs */
 #define FB_DPMS_ACTIVE_OFF	1
@@ -714,6 +715,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
 
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+				       struct fb_videomode *fbmode);
+#endif
+
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
 extern void fb_var_to_videomode(struct fb_videomode *mode,
-- 
1.7.10.4

[PATCHv15 5/7] fbmon: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get fb_videomode from devicetree.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 drivers/video/fbmon.c |   42 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/fb.h    |    6 ++++++
 2 files changed, 48 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 733553b..4a8484d 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -28,6 +28,7 @@
  */
 #include <linux/fb.h>
 #include <linux/module.h>
+#include <linux/of_videomode.h>
 #include <linux/pci.h>
 #include <linux/slab.h>
 #include <linux/videomode.h>
@@ -1424,6 +1425,47 @@ int fb_videomode_from_videomode(const struct videomode *vm,
 EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
 #endif
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+	pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u %u\n",
+		 m->xres, m->yres, m->refresh, m->pixclock, m->left_margin,
+		 m->right_margin, m->upper_margin, m->lower_margin,
+		 m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+			int index)
+{
+	struct videomode vm;
+	int ret;
+
+	ret = of_get_videomode(np, &vm, index);
+	if (ret)
+		return ret;
+
+	fb_videomode_from_videomode(&vm, fb);
+
+	pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+		vm.vactive, np->name);
+	dump_fb_videomode(fb);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
 #else
 int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
 {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 4404ec2..c2d933d 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
 struct device;
 struct file;
 struct videomode;
+struct device_node;
 
 /* Definitions below are used in the parsed monitor specs */
 #define FB_DPMS_ACTIVE_OFF	1
@@ -715,6 +716,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
 extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
 extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_fb_videomode(struct device_node *np,
+			       struct fb_videomode *fb,
+			       int index);
+#endif
 #if IS_ENABLED(CONFIG_VIDEOMODE)
 extern int fb_videomode_from_videomode(const struct videomode *vm,
 				       struct fb_videomode *fbmode);
-- 
1.7.10.4

[PATCHv15 6/7] drm_modes: add videomode helpers

[Steffen Trumtrar]

Add conversion from videomode to drm_display_mode

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 drivers/gpu/drm/drm_modes.c |   37 +++++++++++++++++++++++++++++++++++++
 include/drm/drmP.h          |    7 +++++++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..8263ea1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -33,6 +33,7 @@
 #include <linux/list.h>
 #include <linux/list_sort.h>
 #include <linux/export.h>
+#include <linux/videomode.h>
 #include <drm/drmP.h>
 #include <drm/drm_crtc.h>
 
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int vdisplay, int vrefresh,
 }
 EXPORT_SYMBOL(drm_gtf_mode);
 
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+				    struct drm_display_mode *dmode)
+{
+	dmode->hdisplay = vm->hactive;
+	dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+	dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+	dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+	dmode->vdisplay = vm->vactive;
+	dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+	dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+	dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+	dmode->clock = vm->pixelclock / 1000;
+
+	dmode->flags = 0;
+	if (vm->hah)
+		dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+	else
+		dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+	if (vm->vah)
+		dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+	else
+		dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+	if (vm->interlaced)
+		dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+	if (vm->doublescan)
+		dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+	drm_mode_set_name(dmode);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..2194e97 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
 struct drm_file;
 struct drm_device;
 
+struct videomode;
+
 #include <drm/drm_os_linux.h>
 #include <drm/drm_hashtab.h>
 #include <drm/drm_mm.h>
@@ -1454,6 +1456,11 @@ extern struct drm_display_mode *
 drm_mode_create_from_cmdline_mode(struct drm_device *dev,
 				  struct drm_cmdline_mode *cmd);
 
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+					   struct drm_display_mode *dmode);
+#endif
+
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
 extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

[PATCHv15 7/7] drm_modes: add of_videomode helpers

[Steffen Trumtrar]

Add helper to get drm_display_mode from devicetree.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/gpu/drm/drm_modes.c |   33 +++++++++++++++++++++++++++++++++
 include/drm/drmP.h          |    6 ++++++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 8263ea1..3568f0a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -33,6 +33,7 @@
 #include <linux/list.h>
 #include <linux/list_sort.h>
 #include <linux/export.h>
+#include <linux/of_videomode.h>
 #include <linux/videomode.h>
 #include <drm/drmP.h>
 #include <drm/drm_crtc.h>
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode *vm,
 EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
 #endif
 
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+			    struct drm_display_mode *dmode, int index)
+{
+	struct videomode vm;
+	int ret;
+
+	ret = of_get_videomode(np, &vm, index);
+	if (ret)
+		return ret;
+
+	drm_display_mode_from_videomode(&vm, dmode);
+
+	pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
+		vm.vactive, np->name);
+	drm_mode_debug_printmodeline(dmode);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
 /**
  * drm_mode_set_name - set the name on a mode
  * @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2194e97..1784e55 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
 struct drm_file;
 struct drm_device;
 
+struct device_node;
 struct videomode;
 
 #include <drm/drm_os_linux.h>
@@ -1460,6 +1461,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
 extern int drm_display_mode_from_videomode(const struct videomode *vm,
 					   struct drm_display_mode *dmode);
 #endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_drm_display_mode(struct device_node *np,
+				   struct drm_display_mode *dmode,
+				   int index);
+#endif
 
 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
-- 
1.7.10.4

Re: [PATCHv15 2/7] video: add display_timing and videomode

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

On 2012-11-26 11:07, Steffen Trumtrar wrote:

> +/*
> + * Subsystem independent description of a videomode.
> + * Can be generated from struct display_timing.
> + */
> +struct videomode {
> +	u32 pixelclock;		/* pixelclock in Hz */

I don't know if this is of any importance, but the linux clock framework
manages clock rates with unsigned long. Would it be better to use the
same type here?

> +	u32 hactive;
> +	u32 hfront_porch;
> +	u32 hback_porch;
> +	u32 hsync_len;
> +
> +	u32 vactive;
> +	u32 vfront_porch;
> +	u32 vback_porch;
> +	u32 vsync_len;
> +
> +	u32 hah;		/* hsync active high */
> +	u32 vah;		/* vsync active high */
> +	u32 de;			/* data enable */
> +	u32 pixelclk_pol;

What values will these 4 have? Aren't these booleans?

The data enable comment should be "data enable active high".

The next patch says in the devtree binding documentation that the values
may be on/off/ignored. Is that represented here somehow, i.e. values are
0/1/2 or so? If not, what does it mean if the value is left out from
devtree data, meaning "not used on hardware"?

There's also a "doubleclk" value mentioned in the devtree bindings doc,
but not shown here.

I think this videomode struct is the one that display drivers are going
to use (?), in addition to the display_timing, so it would be good to
document it well.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 6243 bytes --]

Hi,

On 2012-11-26 11:07, Steffen Trumtrar wrote:
> This adds support for reading display timings from DT into a struct
> display_timings. The of_display_timing implementation supports multiple
> subnodes. All children are read into an array, that can be queried.
> 
> If no native mode is specified, the first subnode will be used.
> 
> For cases where the graphics driver knows there can be only one
> mode description or where the driver only supports one mode, a helper
> function of_get_videomode is added, that gets a struct videomode from DT.
> 
> Signed-off-by: Steffen Trumtrar <s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
> Acked-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
> Tested-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
> Tested-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Acked-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> ---
>  .../devicetree/bindings/video/display-timing.txt   |  107 ++++++++++
>  drivers/video/Kconfig                              |   15 ++
>  drivers/video/Makefile                             |    2 +
>  drivers/video/of_display_timing.c                  |  219 ++++++++++++++++++++
>  drivers/video/of_videomode.c                       |   54 +++++
>  include/linux/of_display_timing.h                  |   20 ++
>  include/linux/of_videomode.h                       |   18 ++
>  7 files changed, 435 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
>  create mode 100644 drivers/video/of_display_timing.c
>  create mode 100644 drivers/video/of_videomode.c
>  create mode 100644 include/linux/of_display_timing.h
>  create mode 100644 include/linux/of_videomode.h
> 
> diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
> new file mode 100644
> index 0000000..e238f27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timing.txt
> @@ -0,0 +1,107 @@
> +display-timing bindings
> +=======================
> +
> +display-timings node
> +--------------------
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - native-mode: The native mode for the display, in case multiple modes are
> +		provided. When omitted, assume the first node is the native.
> +
> +timing subnode
> +--------------
> +
> +required properties:
> + - hactive, vactive: display resolution
> + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
> +   in pixels
> +   vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
> +   lines
> + - clock-frequency: display clock in Hz
> +
> +optional properties:
> + - hsync-active: hsync pulse is active low/high/ignored
> + - vsync-active: vsync pulse is active low/high/ignored
> + - de-active: data-enable pulse is active low/high/ignored
> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> +				non-inverted (active on rising edge)/
> +				     ignored (ignore property)

I think hsync-active and vsync-active are clear, and commonly used, and
they are used for both drm and fb mode conversions in later patches.

de-active is not used in drm and fb mode conversions, but I think it's
also clear.

pixelclk-inverted is not used in the mode conversions. It's also a bit
unclear to me. What does it mean that pix clock is "active on rising
edge"? The pixel data is driven on rising edge? How about the sync
signals and DE, when are they driven? Does your HW have any settings
related to those?

OMAP has the invert pclk setting, but it also has a setting to define
when the sync signals are driven. The options are:
- syncs are driven on rising edge of pclk
- syncs are driven on falling edge of pclk
- syncs are driven on the opposite edge of pclk compared to the pixel data

For DE there's no setting, except the active high/low.

And if I'm not mistaken, if the optional properties are not defined,
they are not ignored, but left to the default 0. Which means active low,
or active on rising edge(?). I think it would be good to have a
"undefined" value for the properties.

> + - interlaced (bool): boolean to enable interlaced mode
> + - doublescan (bool): boolean to enable doublescan mode
> + - doubleclk (bool)

As I mentioned in the other mail, doubleclk is not used nor documented here.

> +All the optional properties that are not bool follow the following logic:
> +    <1>: high active
> +    <0>: low active
> +    omitted: not used on hardware
> +
> +There are different ways of describing the capabilities of a display. The devicetree
> +representation corresponds to the one commonly found in datasheets for displays.
> +If a display supports multiple signal timings, the native-mode can be specified.

I have some of the same concerns for this series than with the
interpreted power sequences (on fbdev): when you publish the DT
bindings, it's somewhat final version then, and fixing it later will be
difficult. Of course, video modes are much clearer than the power
sequences, so it's possible there won't be any problems with the DT
bindings.

However, I'd still feel safer if the series would be split to non-DT and
DT parts. The non-DT parts could be merged quite easily, and people
could start using them in their kernels. This should expose
bugs/problems related to the code.

The DT part could be merged later, when there's confidence that the
timings are good for all platforms.

Or, alternatively, all the non-common bindings (de-active, pck
invert,...) that are not used for fbdev or drm currently could be left
out for now. But I'd stil prefer merging it in two parts.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCHv15 2/7] video: add display_timing and videomode

[Steffen Trumtrar]

On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
> On 2012-11-26 11:07, Steffen Trumtrar wrote:
> 
> > +/*
> > + * Subsystem independent description of a videomode.
> > + * Can be generated from struct display_timing.
> > + */
> > +struct videomode {
> > +	u32 pixelclock;		/* pixelclock in Hz */
> 
> I don't know if this is of any importance, but the linux clock framework
> manages clock rates with unsigned long. Would it be better to use the
> same type here?
> 

Hm, I don't know. Anyone? u32 should be large enough for a pixelclock.

> > +	u32 hactive;
> > +	u32 hfront_porch;
> > +	u32 hback_porch;
> > +	u32 hsync_len;
> > +
> > +	u32 vactive;
> > +	u32 vfront_porch;
> > +	u32 vback_porch;
> > +	u32 vsync_len;
> > +
> > +	u32 hah;		/* hsync active high */
> > +	u32 vah;		/* vsync active high */
> > +	u32 de;			/* data enable */
> > +	u32 pixelclk_pol;
> 
> What values will these 4 have? Aren't these booleans?
> 
> The data enable comment should be "data enable active high".
> 
> The next patch says in the devtree binding documentation that the values
> may be on/off/ignored. Is that represented here somehow, i.e. values are
> 0/1/2 or so? If not, what does it mean if the value is left out from
> devtree data, meaning "not used on hardware"?
>

Hm, I think you might be right here. It is no problem in the DT part of the code.
The properties are optional, left out means "not used on hardware".
But this does not propagate correctly to the videomode. I should set the fields
to -EINVAL in case they are omitted, than everything should work nicely.

> There's also a "doubleclk" value mentioned in the devtree bindings doc,
> but not shown here.
> 

Argh. That slipped through. I have patches that add this property to all
structs and the devicetree binding. But it is not supposed to be in this
series, because I want to at least have the binding stable for now.

> I think this videomode struct is the one that display drivers are going
> to use (?), in addition to the display_timing, so it would be good to
> document it well.
> 

Yes. Maybe I have to put more of the devicetree documentation in the code.

Regards,
Steffen


-- 
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-5555 |

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Steffen Trumtrar]

Hi,

On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
> Hi,
> 
> On 2012-11-26 11:07, Steffen Trumtrar wrote:
> > This adds support for reading display timings from DT into a struct
> > display_timings. The of_display_timing implementation supports multiple
> > subnodes. All children are read into an array, that can be queried.
> > 
> > If no native mode is specified, the first subnode will be used.
> > 
> > For cases where the graphics driver knows there can be only one
> > mode description or where the driver only supports one mode, a helper
> > function of_get_videomode is added, that gets a struct videomode from DT.
> > 
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Acked-by: Stephen Warren <swarren@nvidia.com>
> > Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
> > Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
> > Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
> > Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> >  .../devicetree/bindings/video/display-timing.txt   |  107 ++++++++++
> >  drivers/video/Kconfig                              |   15 ++
> >  drivers/video/Makefile                             |    2 +
> >  drivers/video/of_display_timing.c                  |  219 ++++++++++++++++++++
> >  drivers/video/of_videomode.c                       |   54 +++++
> >  include/linux/of_display_timing.h                  |   20 ++
> >  include/linux/of_videomode.h                       |   18 ++
> >  7 files changed, 435 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
> >  create mode 100644 drivers/video/of_display_timing.c
> >  create mode 100644 drivers/video/of_videomode.c
> >  create mode 100644 include/linux/of_display_timing.h
> >  create mode 100644 include/linux/of_videomode.h
> > 
> > diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
> > new file mode 100644
> > index 0000000..e238f27
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/display-timing.txt
> > @@ -0,0 +1,107 @@
> > +display-timing bindings
> > +=======================
> > +
> > +display-timings node
> > +--------------------
> > +
> > +required properties:
> > + - none
> > +
> > +optional properties:
> > + - native-mode: The native mode for the display, in case multiple modes are
> > +		provided. When omitted, assume the first node is the native.
> > +
> > +timing subnode
> > +--------------
> > +
> > +required properties:
> > + - hactive, vactive: display resolution
> > + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
> > +   in pixels
> > +   vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
> > +   lines
> > + - clock-frequency: display clock in Hz
> > +
> > +optional properties:
> > + - hsync-active: hsync pulse is active low/high/ignored
> > + - vsync-active: vsync pulse is active low/high/ignored
> > + - de-active: data-enable pulse is active low/high/ignored
> > + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> > +				non-inverted (active on rising edge)/
> > +				     ignored (ignore property)
> 
> I think hsync-active and vsync-active are clear, and commonly used, and
> they are used for both drm and fb mode conversions in later patches.
> 
> de-active is not used in drm and fb mode conversions, but I think it's
> also clear.
> 
> pixelclk-inverted is not used in the mode conversions. It's also a bit
> unclear to me. What does it mean that pix clock is "active on rising
> edge"? The pixel data is driven on rising edge? How about the sync
> signals and DE, when are they driven? Does your HW have any settings
> related to those?
> 

Those are properties commonly found in display specs. That is why they are here.
If the GPU does not support the property it can be omitted.

> OMAP has the invert pclk setting, but it also has a setting to define
> when the sync signals are driven. The options are:
> - syncs are driven on rising edge of pclk
> - syncs are driven on falling edge of pclk
> - syncs are driven on the opposite edge of pclk compared to the pixel data
> 
> For DE there's no setting, except the active high/low.
> 
> And if I'm not mistaken, if the optional properties are not defined,
> they are not ignored, but left to the default 0. Which means active low,
> or active on rising edge(?). I think it would be good to have a
> "undefined" value for the properties.
> 

Yes. As mentioned in my other mail, the intention of the omitted properties do
not propagate properly. Omitted must be a value < 0, so it is clear in a later
stage, that this property shall not be used. And isn't unintentionally considered
to be active low.

> > + - interlaced (bool): boolean to enable interlaced mode
> > + - doublescan (bool): boolean to enable doublescan mode
> > + - doubleclk (bool)
> 
> As I mentioned in the other mail, doubleclk is not used nor documented here.
> 

Yes. Rebase mistake I overlooked.

> > +All the optional properties that are not bool follow the following logic:
> > +    <1>: high active
> > +    <0>: low active
> > +    omitted: not used on hardware
> > +
> > +There are different ways of describing the capabilities of a display. The devicetree
> > +representation corresponds to the one commonly found in datasheets for displays.
> > +If a display supports multiple signal timings, the native-mode can be specified.
> 
> I have some of the same concerns for this series than with the
> interpreted power sequences (on fbdev): when you publish the DT
> bindings, it's somewhat final version then, and fixing it later will be
> difficult. Of course, video modes are much clearer than the power
> sequences, so it's possible there won't be any problems with the DT
> bindings.
> 

The binding is pretty much at the bare minimum after a lot of discussion about
the properties. Even if the binding changes, I think it will rather grow than
shrink. Take the doubleclock property for example. It got here mistakingly,
because we had a display that has this feature.

> However, I'd still feel safer if the series would be split to non-DT and
> DT parts. The non-DT parts could be merged quite easily, and people
> could start using them in their kernels. This should expose
> bugs/problems related to the code.
> 
> The DT part could be merged later, when there's confidence that the
> timings are good for all platforms.
> 
> Or, alternatively, all the non-common bindings (de-active, pck
> invert,...) that are not used for fbdev or drm currently could be left
> out for now. But I'd stil prefer merging it in two parts.

I don't say that I'm against it, but the whole reason for the series was
getting the display timings from a DT into a graphics driver. And I think
I remember seeing some other attempts at achieving this, but all specific
to one special case. There is even already a mainline driver that uses an older
version of the DT bindings (vt8500-fb).

Regards,
Steffen

-- 
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-5555 |

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 5578 bytes --]

On 2012-11-26 18:10, Steffen Trumtrar wrote:
> Hi,
> 
> On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:

>>> +optional properties:
>>> + - hsync-active: hsync pulse is active low/high/ignored
>>> + - vsync-active: vsync pulse is active low/high/ignored
>>> + - de-active: data-enable pulse is active low/high/ignored
>>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
>>> +				non-inverted (active on rising edge)/
>>> +				     ignored (ignore property)
>>
>> I think hsync-active and vsync-active are clear, and commonly used, and
>> they are used for both drm and fb mode conversions in later patches.
>>
>> de-active is not used in drm and fb mode conversions, but I think it's
>> also clear.
>>
>> pixelclk-inverted is not used in the mode conversions. It's also a bit
>> unclear to me. What does it mean that pix clock is "active on rising
>> edge"? The pixel data is driven on rising edge? How about the sync
>> signals and DE, when are they driven? Does your HW have any settings
>> related to those?
>>
> 
> Those are properties commonly found in display specs. That is why they are here.
> If the GPU does not support the property it can be omitted.

So what does the pixelclk-inverted mean? Normally the SoC drives pixel
data on rising edge, and the panel samples it at falling edge? And
vice-versa for inverted? Or the other way around?

When is hsync/vsync set? On rising or falling edge of pclk?

My point here is that the pixelclk-inverted is not crystal clear thing,
like the hsync/vsync/de-active values are.

And while thinking about this, I realized that the meaning of
pixelclk-inverted depends on what component is it applied to. Presuming
normal pixclk means "pixel data on rising edge", the meaning of that
depends on do we consider the SoC or the panel. The panel needs to
sample the data on the other edge from the one the SoC uses to drive the
data.

Does the videomode describe the panel, or does it describe the settings
programmed to the SoC?

>> OMAP has the invert pclk setting, but it also has a setting to define
>> when the sync signals are driven. The options are:
>> - syncs are driven on rising edge of pclk
>> - syncs are driven on falling edge of pclk
>> - syncs are driven on the opposite edge of pclk compared to the pixel data
>>
>> For DE there's no setting, except the active high/low.
>>
>> And if I'm not mistaken, if the optional properties are not defined,
>> they are not ignored, but left to the default 0. Which means active low,
>> or active on rising edge(?). I think it would be good to have a
>> "undefined" value for the properties.
>>
> 
> Yes. As mentioned in my other mail, the intention of the omitted properties do
> not propagate properly. Omitted must be a value < 0, so it is clear in a later
> stage, that this property shall not be used. And isn't unintentionally considered
> to be active low.

Ok. Just note that the values are currently stored into u32, and I don't
think using negative error values with u32 is a good idea.

>> I have some of the same concerns for this series than with the
>> interpreted power sequences (on fbdev): when you publish the DT
>> bindings, it's somewhat final version then, and fixing it later will be
>> difficult. Of course, video modes are much clearer than the power
>> sequences, so it's possible there won't be any problems with the DT
>> bindings.
>>
> 
> The binding is pretty much at the bare minimum after a lot of discussion about
> the properties. Even if the binding changes, I think it will rather grow than
> shrink. Take the doubleclock property for example. It got here mistakingly,
> because we had a display that has this feature.

Right. That's why I would leave the pixelclock-inverted out for now, if
we're not totally sure how it's defined. Of course, it could be just me
who is not understanding the pixclk-inverted =).

>> However, I'd still feel safer if the series would be split to non-DT and
>> DT parts. The non-DT parts could be merged quite easily, and people
>> could start using them in their kernels. This should expose
>> bugs/problems related to the code.
>>
>> The DT part could be merged later, when there's confidence that the
>> timings are good for all platforms.
>>
>> Or, alternatively, all the non-common bindings (de-active, pck
>> invert,...) that are not used for fbdev or drm currently could be left
>> out for now. But I'd stil prefer merging it in two parts.
> 
> I don't say that I'm against it, but the whole reason for the series was
> getting the display timings from a DT into a graphics driver. And I think
> I remember seeing some other attempts at achieving this, but all specific
> to one special case. There is even already a mainline driver that uses an older
> version of the DT bindings (vt8500-fb).

I think it'd be very useful even without DT bindings. But yes, I
understand your need for it.

You're now in v15 of the series. Are you sure v16 will be good enough to
freeze the DT bindings, if 15 previous versions weren't? =). Perhaps I'm
just overly cautious with DT bindings. APIs that are exposed outside the
kernel scare me, as they should be just and not almost right.

However, I want to also point out that where ever you're going to use
the videomode DT bindings, when the common display framework is merged
and presuming you'll use it, you may need to change the DT stuff again
(for the SoC/gfx card, not the videomode bindings).

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [PATCHv15 0/7] of: add display helper

[Leela Krishna Amudala]

Hello Steffen,

Any update on version 16 ?

Best Wishes,
Leela Krishna Amudala.

On Mon, Nov 26, 2012 at 2:37 PM, Steffen Trumtrar
<s.trumtrar@pengutronix.de> wrote:
> Hi!
>
> Changes since v14:
>         - fix "const struct *" warning
>                 (reported by: Leela Krishna Amudala <l.krishna@samsung.com>)
>         - return -EINVAL when htotal or vtotal are zero
>         - remove unreachable code in of_get_display_timings
>         - include headers in .c files and not implicit in .h
>         - sort includes alphabetically
>         - fix lower/uppercase in binding documentation
>         - rebase onto v3.7-rc7
>
> Changes since v13:
>         - fix "const struct *" warning
>                 (reported by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>)
>         - prevent division by zero in fb_videomode_from_videomode
>
> Changes since v12:
>         - rename struct display_timing to via_display_timing in via subsystem
>         - fix refreshrate calculation
>         - fix "const struct *" warnings
>                 (reported by: Manjunathappa, Prakash <prakash.pm@ti.com>)
>         - some CodingStyle fixes
>         - rewrite parts of commit messages and display-timings.txt
>         - let display_timing_get_value get all values instead of just typical
>
> Changes since v11:
>         - make pointers const where applicable
>         - add reviewed-by Laurent Pinchart
>
> Changes since v10:
>         - fix function name (drm_)display_mode_from_videomode
>         - add acked-by, reviewed-by, tested-by
>
> Changes since v9:
>         - don't leak memory when previous timings were correct
>         - CodingStyle fixes
>         - move blank lines around
>
> Changes since v8:
>         - fix memory leaks
>         - change API to be more consistent (foo_from_bar(struct bar, struct foo))
>         - include headers were necessary
>         - misc minor bufixe
>
> Changes since v7:
>         - move of_xxx to drivers/video
>         - remove non-binding documentation from display-timings.txt
>         - squash display_timings and videomode in one patch
>         - misc minor fixes
>
> Changes since v6:
>         - get rid of some empty lines etc.
>         - move functions to their subsystems
>         - split of_ from non-of_ functions
>         - add at least some kerneldoc to some functions
>
> Changes since v5:
>         - removed all display stuff and just describe timings
>
> Changes since v4:
>         - refactored functions
>
> Changes since v3:
>         - print error messages
>         - free alloced memory
>         - general cleanup
>
> Changes since v2:
>         - use hardware-near property-names
>         - provide a videomode structure
>         - allow ranges for all properties (<min,typ,max>)
>         - functions to get display_mode or fb_videomode
>
>
> Steffen Trumtrar (7):
>   viafb: rename display_timing to via_display_timing
>   video: add display_timing and videomode
>   video: add of helper for display timings/videomode
>   fbmon: add videomode helpers
>   fbmon: add of_videomode helpers
>   drm_modes: add videomode helpers
>   drm_modes: add of_videomode helpers
>
>  .../devicetree/bindings/video/display-timing.txt   |  107 ++++++++++
>  drivers/gpu/drm/drm_modes.c                        |   70 +++++++
>  drivers/video/Kconfig                              |   21 ++
>  drivers/video/Makefile                             |    4 +
>  drivers/video/display_timing.c                     |   24 +++
>  drivers/video/fbmon.c                              |   93 +++++++++
>  drivers/video/of_display_timing.c                  |  219 ++++++++++++++++++++
>  drivers/video/of_videomode.c                       |   54 +++++
>  drivers/video/via/hw.c                             |    6 +-
>  drivers/video/via/hw.h                             |    2 +-
>  drivers/video/via/lcd.c                            |    2 +-
>  drivers/video/via/share.h                          |    2 +-
>  drivers/video/via/via_modesetting.c                |    8 +-
>  drivers/video/via/via_modesetting.h                |    6 +-
>  drivers/video/videomode.c                          |   44 ++++
>  include/drm/drmP.h                                 |   13 ++
>  include/linux/display_timing.h                     |  104 ++++++++++
>  include/linux/fb.h                                 |   12 ++
>  include/linux/of_display_timing.h                  |   20 ++
>  include/linux/of_videomode.h                       |   18 ++
>  include/linux/videomode.h                          |   54 +++++
>  21 files changed, 870 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
>  create mode 100644 drivers/video/display_timing.c
>  create mode 100644 drivers/video/of_display_timing.c
>  create mode 100644 drivers/video/of_videomode.c
>  create mode 100644 drivers/video/videomode.c
>  create mode 100644 include/linux/display_timing.h
>  create mode 100644 include/linux/of_display_timing.h
>  create mode 100644 include/linux/of_videomode.h
>  create mode 100644 include/linux/videomode.h
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv15 0/7] of: add display helper

[Steffen Trumtrar]

Hi Leela,

unfortunately, nothing new as of yet. I have to work on other stuff at the moment.

Regards,
Steffen


On Wed, Dec 05, 2012 at 01:25:30PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
> 
> Any update on version 16 ?
> 
> Best Wishes,
> Leela Krishna Amudala.
> 
> On Mon, Nov 26, 2012 at 2:37 PM, Steffen Trumtrar
> <s.trumtrar@pengutronix.de> wrote:
> > Hi!
> >
> > Changes since v14:
> >         - fix "const struct *" warning
> >                 (reported by: Leela Krishna Amudala <l.krishna@samsung.com>)
> >         - return -EINVAL when htotal or vtotal are zero
> >         - remove unreachable code in of_get_display_timings
> >         - include headers in .c files and not implicit in .h
> >         - sort includes alphabetically
> >         - fix lower/uppercase in binding documentation
> >         - rebase onto v3.7-rc7
> >
> > Changes since v13:
> >         - fix "const struct *" warning
> >                 (reported by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>)
> >         - prevent division by zero in fb_videomode_from_videomode
> >
> > Changes since v12:
> >         - rename struct display_timing to via_display_timing in via subsystem
> >         - fix refreshrate calculation
> >         - fix "const struct *" warnings
> >                 (reported by: Manjunathappa, Prakash <prakash.pm@ti.com>)
> >         - some CodingStyle fixes
> >         - rewrite parts of commit messages and display-timings.txt
> >         - let display_timing_get_value get all values instead of just typical
> >
> > Changes since v11:
> >         - make pointers const where applicable
> >         - add reviewed-by Laurent Pinchart
> >
> > Changes since v10:
> >         - fix function name (drm_)display_mode_from_videomode
> >         - add acked-by, reviewed-by, tested-by
> >
> > Changes since v9:
> >         - don't leak memory when previous timings were correct
> >         - CodingStyle fixes
> >         - move blank lines around
> >
> > Changes since v8:
> >         - fix memory leaks
> >         - change API to be more consistent (foo_from_bar(struct bar, struct foo))
> >         - include headers were necessary
> >         - misc minor bufixe
> >
> > Changes since v7:
> >         - move of_xxx to drivers/video
> >         - remove non-binding documentation from display-timings.txt
> >         - squash display_timings and videomode in one patch
> >         - misc minor fixes
> >
> > Changes since v6:
> >         - get rid of some empty lines etc.
> >         - move functions to their subsystems
> >         - split of_ from non-of_ functions
> >         - add at least some kerneldoc to some functions
> >
> > Changes since v5:
> >         - removed all display stuff and just describe timings
> >
> > Changes since v4:
> >         - refactored functions
> >
> > Changes since v3:
> >         - print error messages
> >         - free alloced memory
> >         - general cleanup
> >
> > Changes since v2:
> >         - use hardware-near property-names
> >         - provide a videomode structure
> >         - allow ranges for all properties (<min,typ,max>)
> >         - functions to get display_mode or fb_videomode
> >
> >
> > Steffen Trumtrar (7):
> >   viafb: rename display_timing to via_display_timing
> >   video: add display_timing and videomode
> >   video: add of helper for display timings/videomode
> >   fbmon: add videomode helpers
> >   fbmon: add of_videomode helpers
> >   drm_modes: add videomode helpers
> >   drm_modes: add of_videomode helpers
> >
> >  .../devicetree/bindings/video/display-timing.txt   |  107 ++++++++++
> >  drivers/gpu/drm/drm_modes.c                        |   70 +++++++
> >  drivers/video/Kconfig                              |   21 ++
> >  drivers/video/Makefile                             |    4 +
> >  drivers/video/display_timing.c                     |   24 +++
> >  drivers/video/fbmon.c                              |   93 +++++++++
> >  drivers/video/of_display_timing.c                  |  219 ++++++++++++++++++++
> >  drivers/video/of_videomode.c                       |   54 +++++
> >  drivers/video/via/hw.c                             |    6 +-
> >  drivers/video/via/hw.h                             |    2 +-
> >  drivers/video/via/lcd.c                            |    2 +-
> >  drivers/video/via/share.h                          |    2 +-
> >  drivers/video/via/via_modesetting.c                |    8 +-
> >  drivers/video/via/via_modesetting.h                |    6 +-
> >  drivers/video/videomode.c                          |   44 ++++
> >  include/drm/drmP.h                                 |   13 ++
> >  include/linux/display_timing.h                     |  104 ++++++++++
> >  include/linux/fb.h                                 |   12 ++
> >  include/linux/of_display_timing.h                  |   20 ++
> >  include/linux/of_videomode.h                       |   18 ++
> >  include/linux/videomode.h                          |   54 +++++
> >  21 files changed, 870 insertions(+), 13 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
> >  create mode 100644 drivers/video/display_timing.c
> >  create mode 100644 drivers/video/of_display_timing.c
> >  create mode 100644 drivers/video/of_videomode.c
> >  create mode 100644 drivers/video/videomode.c
> >  create mode 100644 include/linux/display_timing.h
> >  create mode 100644 include/linux/of_display_timing.h
> >  create mode 100644 include/linux/of_videomode.h
> >  create mode 100644 include/linux/videomode.h
> >
> > --
> > 1.7.10.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
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-5555 |

Re: [PATCHv15 2/7] video: add display_timing and videomode

[Grant Likely]

On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar <s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
> > On 2012-11-26 11:07, Steffen Trumtrar wrote:
> > 
> > > +/*
> > > + * Subsystem independent description of a videomode.
> > > + * Can be generated from struct display_timing.
> > > + */
> > > +struct videomode {
> > > +	u32 pixelclock;		/* pixelclock in Hz */
> > 
> > I don't know if this is of any importance, but the linux clock framework
> > manages clock rates with unsigned long. Would it be better to use the
> > same type here?
> > 
> 
> Hm, I don't know. Anyone? u32 should be large enough for a pixelclock.

4GHz is a pretty large pixel clock. I have no idea how conceivable it is
that hardware will get to that speed. However, if it will ever be
larger, then you'll need to account for that in the DT binding so that
the pixel clock can be specified using 2 cells.

g.

Re: [PATCHv15 2/7] video: add display_timing and videomode

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1286 bytes --]

On 2012-12-06 12:07, Grant Likely wrote:
> On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar <s.trumtrar@pengutronix.de> wrote:
>> On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
>>> On 2012-11-26 11:07, Steffen Trumtrar wrote:
>>>
>>>> +/*
>>>> + * Subsystem independent description of a videomode.
>>>> + * Can be generated from struct display_timing.
>>>> + */
>>>> +struct videomode {
>>>> +	u32 pixelclock;		/* pixelclock in Hz */
>>>
>>> I don't know if this is of any importance, but the linux clock framework
>>> manages clock rates with unsigned long. Would it be better to use the
>>> same type here?
>>>
>>
>> Hm, I don't know. Anyone? u32 should be large enough for a pixelclock.
> 
> 4GHz is a pretty large pixel clock. I have no idea how conceivable it is
> that hardware will get to that speed. However, if it will ever be
> larger, then you'll need to account for that in the DT binding so that
> the pixel clock can be specified using 2 cells.

I didn't mention the type because of the size of the field, but only
because to me it makes sense to use the same type for clock rates all
around the kernel. In many cases the value will be passed to clk_set_rate().

I can't see any real issues with u32, though.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Philipp Zabel]

Hi,

Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
> On 2012-11-26 18:10, Steffen Trumtrar wrote:
> > Hi,
> > 
> > On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
> 
> >>> +optional properties:
> >>> + - hsync-active: hsync pulse is active low/high/ignored
> >>> + - vsync-active: vsync pulse is active low/high/ignored
> >>> + - de-active: data-enable pulse is active low/high/ignored
> >>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> >>> +				non-inverted (active on rising edge)/
> >>> +				     ignored (ignore property)
> >>
> >> I think hsync-active and vsync-active are clear, and commonly used, and
> >> they are used for both drm and fb mode conversions in later patches.
> >>
> >> de-active is not used in drm and fb mode conversions, but I think it's
> >> also clear.
> >>
> >> pixelclk-inverted is not used in the mode conversions. It's also a bit
> >> unclear to me. What does it mean that pix clock is "active on rising
> >> edge"? The pixel data is driven on rising edge? How about the sync
> >> signals and DE, when are they driven? Does your HW have any settings
> >> related to those?
> >>
> > 
> > Those are properties commonly found in display specs. That is why they are here.
> > If the GPU does not support the property it can be omitted.
> 
> So what does the pixelclk-inverted mean? Normally the SoC drives pixel
> data on rising edge, and the panel samples it at falling edge? And
> vice-versa for inverted? Or the other way around?
>
> When is hsync/vsync set? On rising or falling edge of pclk?
>
> My point here is that the pixelclk-inverted is not crystal clear thing,
> like the hsync/vsync/de-active values are.
>
> And while thinking about this, I realized that the meaning of
> pixelclk-inverted depends on what component is it applied to. Presuming
> normal pixclk means "pixel data on rising edge", the meaning of that
> depends on do we consider the SoC or the panel. The panel needs to
> sample the data on the other edge from the one the SoC uses to drive the
> data.
> 
> Does the videomode describe the panel, or does it describe the settings
> programmed to the SoC?

How about calling this property pixelclk-active, active high meaning
driving pixel data on rising edges and sampling on falling edges (the
pixel clock is high between driving and sampling the data), and active
low meaning driving on falling edges and sampling on rising edges?
It is the same from the SoC perspective and from the panel perspective,
and it mirrors the usage of the other *-active properties.

[...]

regards
Philipp

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Steffen Trumtrar]

Hi,

On Fri, Dec 07, 2012 at 03:12:48PM +0100, Philipp Zabel wrote:
> Hi,
> 
> Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
> > On 2012-11-26 18:10, Steffen Trumtrar wrote:
> > > Hi,
> > > 
> > > On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
> > 
> > >>> +optional properties:
> > >>> + - hsync-active: hsync pulse is active low/high/ignored
> > >>> + - vsync-active: vsync pulse is active low/high/ignored
> > >>> + - de-active: data-enable pulse is active low/high/ignored
> > >>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> > >>> +				non-inverted (active on rising edge)/
> > >>> +				     ignored (ignore property)
> > >>
> > >> I think hsync-active and vsync-active are clear, and commonly used, and
> > >> they are used for both drm and fb mode conversions in later patches.
> > >>
> > >> de-active is not used in drm and fb mode conversions, but I think it's
> > >> also clear.
> > >>
> > >> pixelclk-inverted is not used in the mode conversions. It's also a bit
> > >> unclear to me. What does it mean that pix clock is "active on rising
> > >> edge"? The pixel data is driven on rising edge? How about the sync
> > >> signals and DE, when are they driven? Does your HW have any settings
> > >> related to those?
> > >>
> > > 
> > > Those are properties commonly found in display specs. That is why they are here.
> > > If the GPU does not support the property it can be omitted.
> > 
> > So what does the pixelclk-inverted mean? Normally the SoC drives pixel
> > data on rising edge, and the panel samples it at falling edge? And
> > vice-versa for inverted? Or the other way around?
> >
> > When is hsync/vsync set? On rising or falling edge of pclk?
> >
> > My point here is that the pixelclk-inverted is not crystal clear thing,
> > like the hsync/vsync/de-active values are.
> >
> > And while thinking about this, I realized that the meaning of
> > pixelclk-inverted depends on what component is it applied to. Presuming
> > normal pixclk means "pixel data on rising edge", the meaning of that
> > depends on do we consider the SoC or the panel. The panel needs to
> > sample the data on the other edge from the one the SoC uses to drive the
> > data.
> > 
> > Does the videomode describe the panel, or does it describe the settings
> > programmed to the SoC?
> 
> How about calling this property pixelclk-active, active high meaning
> driving pixel data on rising edges and sampling on falling edges (the
> pixel clock is high between driving and sampling the data), and active
> low meaning driving on falling edges and sampling on rising edges?
> It is the same from the SoC perspective and from the panel perspective,
> and it mirrors the usage of the other *-active properties.
> 

I think, this would not be a bad idea. I would include Philipps description in the
display-timing.txt, as it makes the meaning pretty clear; at least to me.

What do the others think about this?

Regards,
Steffen

-- 
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-5555 |

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1660 bytes --]

On 2012-12-07 16:12, Philipp Zabel wrote:
> Hi,
> 
> Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:

>> So what does the pixelclk-inverted mean? Normally the SoC drives pixel
>> data on rising edge, and the panel samples it at falling edge? And
>> vice-versa for inverted? Or the other way around?
>>
>> When is hsync/vsync set? On rising or falling edge of pclk?
>>
>> My point here is that the pixelclk-inverted is not crystal clear thing,
>> like the hsync/vsync/de-active values are.
>>
>> And while thinking about this, I realized that the meaning of
>> pixelclk-inverted depends on what component is it applied to. Presuming
>> normal pixclk means "pixel data on rising edge", the meaning of that
>> depends on do we consider the SoC or the panel. The panel needs to
>> sample the data on the other edge from the one the SoC uses to drive the
>> data.
>>
>> Does the videomode describe the panel, or does it describe the settings
>> programmed to the SoC?
> 
> How about calling this property pixelclk-active, active high meaning
> driving pixel data on rising edges and sampling on falling edges (the
> pixel clock is high between driving and sampling the data), and active
> low meaning driving on falling edges and sampling on rising edges?
> It is the same from the SoC perspective and from the panel perspective,
> and it mirrors the usage of the other *-active properties.

This sounds good to me. It's not quite correct, as neither pixelclock or
pixel data are not really "active" when the clock is high/low, but it
still makes sense and is clear (at least with a short description).

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss