[PATCH v7 2/8] of: add helper to parse display timings

2012-11-04 Thread Steffen Trumtrar 
Hi!

On Fri, Nov 02, 2012 at 10:49:47PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
> 
> On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
> > +static int parse_property(struct device_node *np, char *name,
> > +   struct timing_entry *result)
> > +{
> > +   struct property *prop;
> > +   int length;
> > +   int cells;
> > +   int ret;
> > +
> > +   prop = of_find_property(np, name, );
> > +   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_array(np, name, >typ, 
> > cells);
> 
> As you are reading only one vaue, you can use of_property_read_u32 instead.
> 

Yes, thats copypasta, no need for _array here.

> > +   result->min = result->typ;
> > +   result->max = result->typ;
> > +   } else if (cells == 3) {
> > +   ret = of_property_read_u32_array(np, name, >min, 
> > cells);
> 
> You are considering only min element, what about typ and max elements?
> 

I start at the address of result->min and read three u32-values, therefore all
three (min,typ,max) are filled with values.

> > +
> > +/**
> > + * 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;
> > +   struct device_node *default_np;
> > +
> > +   if (!np)
> > +   return -EINVAL;
> > +
> > +   timings_np = of_parse_phandle(np, "display-timings", 0);
> > +   if (!timings_np)
> > +   return -EINVAL;
> > +
> > +   return -EINVAL;
> 
> Here it should return success instead of -EINVAL.
> 

Yes.

> And one query.. are the binding properties names and "display-timings"
> node structure template  finalized..?
> 

I sure hope so. There actually is one error in the examples though.
The property clock is called clock-frequency. I included it correctly
at the top of display-timings.txt, but overlooked it in the examples.

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

[PATCH v7 2/8] of: add helper to parse display timings

2012-11-04 Thread Steffen Trumtrar 
On Thu, Nov 01, 2012 at 09:15:10PM +0100, Thierry Reding wrote:
> On Wed, Oct 31, 2012 at 10:28:02AM +0100, Steffen Trumtrar wrote:
> [...]
> > diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> > b/Documentation/devicetree/bindings/video/display-timings.txt
> [...]
> > @@ -0,0 +1,139 @@
> > +display-timings bindings
> > +==
> > +
> > +display-timings-node
> > +
> 
> Maybe extend the underline to the length of the section and subsection
> titles respectively?
> 
> > +struct display_timing
> > +===
> 
> Same here.
> 
> > +config OF_DISPLAY_TIMINGS
> > +   def_bool y
> > +   depends on DISPLAY_TIMING
> 
> Maybe this should be called OF_DISPLAY_TIMING to match DISPLAY_TIMING,
> or rename DISPLAY_TIMING to DISPLAY_TIMINGS for the sake of consistency?
> 

Yes, to all three above.

> > +/**
> > + * of_get_display_timing_list - parse all display_timing entries from a 
> > device_node
> > + * @np: device_node with the subnodes
> > + **/
> > +struct display_timings *of_get_display_timing_list(struct device_node *np)
> 
> Perhaps this would better be named of_get_display_timings() to match the
> return type?
> 

Hm, I'm not really sure about that. I found it to error prone, to have a 
function
of_get_display_timing and of_get_display_timings. That's why I chose
of_get_display_timing_list. But you are correct, that it doesn't match the 
return
value. Maybe I should just make the first function static and change the name 
as you
suggested.

> > +   disp = kzalloc(sizeof(*disp), GFP_KERNEL);
> 
> Shouldn't you be checking this for allocation failures?
> 
> > +   disp->timings = kzalloc(sizeof(struct display_timing 
> > *)*disp->num_timings,
> > +   GFP_KERNEL);
> 
> Same here.
> 

Yes, to both.

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

Re: [PATCH v7 2/8] of: add helper to parse display timings

2012-11-04 Thread Steffen Trumtrar 
On Thu, Nov 01, 2012 at 09:15:10PM +0100, Thierry Reding wrote:
 On Wed, Oct 31, 2012 at 10:28:02AM +0100, Steffen Trumtrar wrote:
 [...]
  diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
  b/Documentation/devicetree/bindings/video/display-timings.txt
 [...]
  @@ -0,0 +1,139 @@
  +display-timings bindings
  +==
  +
  +display-timings-node
  +
 
 Maybe extend the underline to the length of the section and subsection
 titles respectively?
 
  +struct display_timing
  +===
 
 Same here.
 
  +config OF_DISPLAY_TIMINGS
  +   def_bool y
  +   depends on DISPLAY_TIMING
 
 Maybe this should be called OF_DISPLAY_TIMING to match DISPLAY_TIMING,
 or rename DISPLAY_TIMING to DISPLAY_TIMINGS for the sake of consistency?
 

Yes, to all three above.

  +/**
  + * of_get_display_timing_list - parse all display_timing entries from a 
  device_node
  + * @np: device_node with the subnodes
  + **/
  +struct display_timings *of_get_display_timing_list(struct device_node *np)
 
 Perhaps this would better be named of_get_display_timings() to match the
 return type?
 

Hm, I'm not really sure about that. I found it to error prone, to have a 
function
of_get_display_timing and of_get_display_timings. That's why I chose
of_get_display_timing_list. But you are correct, that it doesn't match the 
return
value. Maybe I should just make the first function static and change the name 
as you
suggested.

  +   disp = kzalloc(sizeof(*disp), GFP_KERNEL);
 
 Shouldn't you be checking this for allocation failures?
 
  +   disp-timings = kzalloc(sizeof(struct display_timing 
  *)*disp-num_timings,
  +   GFP_KERNEL);
 
 Same here.
 

Yes, to both.

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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 2/8] of: add helper to parse display timings

2012-11-04 Thread Steffen Trumtrar 
Hi!

On Fri, Nov 02, 2012 at 10:49:47PM +0530, Leela Krishna Amudala wrote:
 Hello Steffen,
 
 On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
  +static int parse_property(struct device_node *np, char *name,
  +   struct timing_entry *result)
  +{
  +   struct property *prop;
  +   int length;
  +   int cells;
  +   int 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_array(np, name, result-typ, 
  cells);
 
 As you are reading only one vaue, you can use of_property_read_u32 instead.
 

Yes, thats copypasta, no need for _array here.

  +   result-min = result-typ;
  +   result-max = result-typ;
  +   } else if (cells == 3) {
  +   ret = of_property_read_u32_array(np, name, result-min, 
  cells);
 
 You are considering only min element, what about typ and max elements?
 

I start at the address of result-min and read three u32-values, therefore all
three (min,typ,max) are filled with values.

  +
  +/**
  + * 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;
  +   struct device_node *default_np;
  +
  +   if (!np)
  +   return -EINVAL;
  +
  +   timings_np = of_parse_phandle(np, display-timings, 0);
  +   if (!timings_np)
  +   return -EINVAL;
  +
  +   return -EINVAL;
 
 Here it should return success instead of -EINVAL.
 

Yes.

 And one query.. are the binding properties names and display-timings
 node structure template  finalized..?
 

I sure hope so. There actually is one error in the examples though.
The property clock is called clock-frequency. I included it correctly
at the top of display-timings.txt, but overlooked it in the examples.

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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 2/8] of: add helper to parse display timings

2012-11-02 Thread Leela Krishna Amudala 
Hello Steffen,

On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
 wrote:
> Signed-off-by: Steffen Trumtrar 
> ---
>  .../devicetree/bindings/video/display-timings.txt  |  139 +++
>  drivers/of/Kconfig |6 +
>  drivers/of/Makefile|1 +
>  drivers/of/of_display_timings.c|  185 
> 
>  include/linux/of_display_timings.h |   20 +++
>  5 files changed, 351 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/display-timings.txt
>  create mode 100644 drivers/of/of_display_timings.c
>  create mode 100644 include/linux/of_display_timings.h
>
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 000..04c94a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,139 @@
> +display-timings 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.
> +
> +timings-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: displayclock 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/non-inverted/ignored
> + - interlaced (bool)
> + - doublescan (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
> +
> +struct display_timing
> +===
> +
> +  
> +--+-+--+---+
> +  |  |?|  |  
>  |
> +  |  ||vback_porch |  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--###--+---+
> +  |  #?#  |  
>  |
> +  |  #|#  |  
>  |
> +  |  hback   #|#  hfront  | 
> hsync |
> +  |   porch  #|   hactive  #  porch   |  len 
>  |
> +  
> |<>#<---+--->#<>|<->|
> +  |  #|#  |  
>  |
> +  |  #|vactive #  |  
>  |
> +  |  #|#  |  
>  |
> +  |  #?#  |  
>  |
> +  
> +--###--+---+
> +  |  |?|  |  
>  |
> +  |  ||vfront_porch|  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--+-+--+---+
> +  |  |?|  |  
>  |
> +  |  ||vsync_len   |  |  
>  |
> +  |  |?|  |  
>  |
> +  
> +--+-+--+---+
> +
> +
> +Example:
> +
> +   display-timings {
> +   native-mode = <>;
> +   timing0: 1920p24 {
> +   /* 1920x1080p24 */
> +   clock = <5200>;
> +   hactive = <1920>;
> +   vactive = <1080>;
> +   hfront-porch = <25>;
> +   hback-porch = <25>;
> +   hsync-len = <25>;
> +   vback-porch = <2>;
> +

Re: [PATCH v7 2/8] of: add helper to parse display timings

2012-11-02 Thread Leela Krishna Amudala 
Hello Steffen,

On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:
 Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
 ---
  .../devicetree/bindings/video/display-timings.txt  |  139 +++
  drivers/of/Kconfig |6 +
  drivers/of/Makefile|1 +
  drivers/of/of_display_timings.c|  185 
 
  include/linux/of_display_timings.h |   20 +++
  5 files changed, 351 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/video/display-timings.txt
  create mode 100644 drivers/of/of_display_timings.c
  create mode 100644 include/linux/of_display_timings.h

 diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
 b/Documentation/devicetree/bindings/video/display-timings.txt
 new file mode 100644
 index 000..04c94a3
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/display-timings.txt
 @@ -0,0 +1,139 @@
 +display-timings 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.
 +
 +timings-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: displayclock 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/non-inverted/ignored
 + - interlaced (bool)
 + - doublescan (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
 +
 +struct display_timing
 +===
 +
 +  
 +--+-+--+---+
 +  |  |↑|  |  
  |
 +  |  ||vback_porch |  |  
  |
 +  |  |↓|  |  
  |
 +  
 +--###--+---+
 +  |  #↑#  |  
  |
 +  |  #|#  |  
  |
 +  |  hback   #|#  hfront  | 
 hsync |
 +  |   porch  #|   hactive  #  porch   |  len 
  |
 +  
 |#---+---#|-|
 +  |  #|#  |  
  |
 +  |  #|vactive #  |  
  |
 +  |  #|#  |  
  |
 +  |  #↓#  |  
  |
 +  
 +--###--+---+
 +  |  |↑|  |  
  |
 +  |  ||vfront_porch|  |  
  |
 +  |  |↓|  |  
  |
 +  
 +--+-+--+---+
 +  |  |↑|  |  
  |
 +  |  ||vsync_len   |  |  
  |
 +  |  |↓|  |  
  |
 +  
 +--+-+--+---+
 +
 +
 +Example:
 +
 +   display-timings {
 +   native-mode = timing0;
 +   timing0: 1920p24 {
 +   /* 1920x1080p24 */
 +   clock = 5200;
 +   hactive = 1920;
 +   vactive = 1080;
 +   hfront-porch = 25;
 +   hback-porch = 25;
 +   hsync-len = 25;
 +   vback-porch = 2;
 +   vfront-porch = 2;
 +   vsync-len = 2;
 +

[PATCH v7 2/8] of: add helper to parse display timings

2012-11-01 Thread Thierry Reding 
On Wed, Oct 31, 2012 at 10:28:02AM +0100, Steffen Trumtrar wrote:
[...]
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt
[...]
> @@ -0,0 +1,139 @@
> +display-timings bindings
> +==
> +
> +display-timings-node
> +

Maybe extend the underline to the length of the section and subsection
titles respectively?

> +struct display_timing
> +===

Same here.

> +config OF_DISPLAY_TIMINGS
> + def_bool y
> + depends on DISPLAY_TIMING

Maybe this should be called OF_DISPLAY_TIMING to match DISPLAY_TIMING,
or rename DISPLAY_TIMING to DISPLAY_TIMINGS for the sake of consistency?

> +/**
> + * of_get_display_timing_list - parse all display_timing entries from a 
> device_node
> + * @np: device_node with the subnodes
> + **/
> +struct display_timings *of_get_display_timing_list(struct device_node *np)

Perhaps this would better be named of_get_display_timings() to match the
return type?

> + disp = kzalloc(sizeof(*disp), GFP_KERNEL);

Shouldn't you be checking this for allocation failures?

> + disp->timings = kzalloc(sizeof(struct display_timing 
> *)*disp->num_timings,
> + GFP_KERNEL);

Same here.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:

[PATCH v7 2/8] of: add helper to parse display timings

2012-11-01 Thread Stephen Warren 
On 10/31/2012 03:28 AM, Steffen Trumtrar wrote:

Patch description? The patch defines the DT binding as well, which isn't
mentioned in the patch subject.

> new file mode 100644
> index 000..04c94a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt

> +Usage in backend
> +

Everything before this point in the binding docs looks reasonable to me.
Everything after this point is Linux-specific/internal implementation
detail, and hence shouldn't be in the binding document.

I only read the DT binding.

Re: [PATCH v7 2/8] of: add helper to parse display timings

2012-11-01 Thread Stephen Warren 
On 10/31/2012 03:28 AM, Steffen Trumtrar wrote:

Patch description? The patch defines the DT binding as well, which isn't
mentioned in the patch subject.

 new file mode 100644
 index 000..04c94a3
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/display-timings.txt

 +Usage in backend
 +

Everything before this point in the binding docs looks reasonable to me.
Everything after this point is Linux-specific/internal implementation
detail, and hence shouldn't be in the binding document.

I only read the DT binding.

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

[PATCH v7 2/8] of: add helper to parse display timings

2012-10-31 Thread Steffen Trumtrar 
Signed-off-by: Steffen Trumtrar 
---
 .../devicetree/bindings/video/display-timings.txt  |  139 +++
 drivers/of/Kconfig |6 +
 drivers/of/Makefile|1 +
 drivers/of/of_display_timings.c|  185 
 include/linux/of_display_timings.h |   20 +++
 5 files changed, 351 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/of/of_display_timings.c
 create mode 100644 include/linux/of_display_timings.h

diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
index 000..04c94a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,139 @@
+display-timings 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.
+
+timings-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: displayclock 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/non-inverted/ignored
+ - interlaced (bool)
+ - doublescan (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
+
+struct display_timing
+===
+
+  +--+-+--+---+
+  |  |?|  |   |
+  |  ||vback_porch |  |   |
+  |  |?|  |   |
+  +--###--+---+
+  |  #?#  |   |
+  |  #|#  |   |
+  |  hback   #|#  hfront  | hsync |
+  |   porch  #|   hactive  #  porch   |  len  |
+  |<>#<---+--->#<>|<->|
+  |  #|#  |   |
+  |  #|vactive #  |   |
+  |  #|#  |   |
+  |  #?#  |   |
+  +--###--+---+
+  |  |?|  |   |
+  |  ||vfront_porch|  |   |
+  |  |?|  |   |
+  +--+-+--+---+
+  |  |?|  |   |
+  |  ||vsync_len   |  |   |
+  |  |?|  |   |
+  +--+-+--+---+
+
+
+Example:
+
+   display-timings {
+   native-mode = <>;
+   timing0: 1920p24 {
+   /* 1920x1080p24 */
+   clock = <5200>;
+   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 -tuples can be used.
+
+Example:
+
+   timing1: timing {
+   /* 1920x1080p24 */
+

[PATCH v7 2/8] of: add helper to parse display timings

2012-10-31 Thread Steffen Trumtrar 
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
 .../devicetree/bindings/video/display-timings.txt  |  139 +++
 drivers/of/Kconfig |6 +
 drivers/of/Makefile|1 +
 drivers/of/of_display_timings.c|  185 
 include/linux/of_display_timings.h |   20 +++
 5 files changed, 351 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
 create mode 100644 drivers/of/of_display_timings.c
 create mode 100644 include/linux/of_display_timings.h

diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
index 000..04c94a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,139 @@
+display-timings 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.
+
+timings-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: displayclock 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/non-inverted/ignored
+ - interlaced (bool)
+ - doublescan (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
+
+struct display_timing
+===
+
+  +--+-+--+---+
+  |  |↑|  |   |
+  |  ||vback_porch |  |   |
+  |  |↓|  |   |
+  +--###--+---+
+  |  #↑#  |   |
+  |  #|#  |   |
+  |  hback   #|#  hfront  | hsync |
+  |   porch  #|   hactive  #  porch   |  len  |
+  |#---+---#|-|
+  |  #|#  |   |
+  |  #|vactive #  |   |
+  |  #|#  |   |
+  |  #↓#  |   |
+  +--###--+---+
+  |  |↑|  |   |
+  |  ||vfront_porch|  |   |
+  |  |↓|  |   |
+  +--+-+--+---+
+  |  |↑|  |   |
+  |  ||vsync_len   |  |   |
+  |  |↓|  |   |
+  +--+-+--+---+
+
+
+Example:
+
+   display-timings {
+   native-mode = timing0;
+   timing0: 1920p24 {
+   /* 1920x1080p24 */
+   clock = 5200;
+   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 */
+