Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2, so, this seems a
great opportunity to me:-)
On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
You're going to hate me for this, but eventually we want to actually
reference clock objects in our DT bindings. For now, even if you don't
want to actually add clock phandles and stuff here, I think, using the
standard "clock-frequency" property would be much better!
+
+optional properties:
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
For the above two we also considered using bool properties but eventually
settled down with integer ones:
- hsync-active = <1>
for active-high and 0 for active low. This has the added advantage of
being able to omit this property in the .dts, which then doesn't mean,
that the polarity is active low, but rather, that the hsync line is not
used on this hardware. So, maybe it would be good to use the same binding
here too?
+ - de-active-high (bool): Data-Enable pulse is active high
+ - pixelclk-inverted (bool): pixelclock is inverted
We don't (yet) have a de-active property in V4L, don't know whether we'll
ever have to distingsuish between what some datasheets call "HREF" and
HSYNC in DT, but maybe similarly to the above an integer would be
preferred. As for pixclk, we call the property "pclk-sample" and it's also
an integer.
+ - interlaced (bool)
Is "interlaced" a property of the hardware, i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive? BTW, I'm not very familiar with display
interfaces, but for interlaced you probably sometimes use a field signal,
whose polarity you also want to specify here? We use a "field-even-active"
integer property for it.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
From: Robert Schwebel <hidden> Date: 2012-10-05 07:17:40
On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
quoted
+optional properties:
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
For the above two we also considered using bool properties but eventually
settled down with integer ones:
- hsync-active = <1>
for active-high and 0 for active low. This has the added advantage of
being able to omit this property in the .dts, which then doesn't mean,
that the polarity is active low, but rather, that the hsync line is not
used on this hardware. So, maybe it would be good to use the same binding
here too?
Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.
rsc
--
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 |
From: Stephen Warren <hidden> Date: 2012-10-05 16:17:55
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2, so, this seems a
great opportunity to me:-)
On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
You're going to hate me for this, but eventually we want to actually
reference clock objects in our DT bindings. For now, even if you don't
want to actually add clock phandles and stuff here, I think, using the
standard "clock-frequency" property would be much better!
In a definition of a display timing, we will never need to use the clock
binding; the clock binding would be used by the HW module that is
generating a timing, not by the timing definition itself.
That said, your comment about renaming the property to avoid any kind of
conceptual conflict is still quite valid. This is bike-shedding, but
"pixel-clock" might be more in line with typical video mode terminology,
although there's certainly preference in DT for using the generic term
clock-frequency that you proposed. Either is fine by me.
quoted
+optional properties:
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
For the above two we also considered using bool properties but eventually
settled down with integer ones:
- hsync-active = <1>
for active-high and 0 for active low. This has the added advantage of
being able to omit this property in the .dts, which then doesn't mean,
that the polarity is active low, but rather, that the hsync line is not
used on this hardware. So, maybe it would be good to use the same binding
here too?
I agree. This also covers the case where analog display connectors often
use polarity to differentiate similar modes, yet digital connectors
often always use a fixed polarity since the receiving device can
"measure" the signal in more complete ways.
If the board HW inverts these lines, the same property names can exist
in the display controller itself, and the two values XORd together to
yield the final output polarity.
quoted
+ - de-active-high (bool): Data-Enable pulse is active high
+ - pixelclk-inverted (bool): pixelclock is inverted
We don't (yet) have a de-active property in V4L, don't know whether we'll
ever have to distingsuish between what some datasheets call "HREF" and
HSYNC in DT, but maybe similarly to the above an integer would be
preferred. As for pixclk, we call the property "pclk-sample" and it's also
an integer.
Thinking about this more: de-active-high is likely to be a
board-specific property and hence something in the display controller,
not in the mode definition?
quoted
+ - interlaced (bool)
Is "interlaced" a property of the hardware, i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive?
Interlace is a property of a display mode. It's quite possible for a
particular display controller to switch between interlace and
progressive output at run-time. For example, reconfiguring the output
between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
a built-in LCD display, you're probably always going to be driving the
single mode required by the panel, and that mode will likely always be
progressive. However, since this binding attempts to describe any
display timing, I think we still need this property per mode.
BTW, I'm not very familiar with display
interfaces, but for interlaced you probably sometimes use a field signal,
whose polarity you also want to specify here? We use a "field-even-active"
integer property for it.
I think that's a property of the display controller itself, rather than
an individual mode, although I'm not 100% certain. My assertion is that
the physical interface that the display controller is driving will
determine whether embedded or separate sync is used, and in the separate
sync case, how the field signal is defined, and that all interlace modes
driven over that interface will use the same field signal definition.
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
quoted
Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2, so, this seems a
great opportunity to me:-)
On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
You're going to hate me for this, but eventually we want to actually
reference clock objects in our DT bindings. For now, even if you don't
want to actually add clock phandles and stuff here, I think, using the
standard "clock-frequency" property would be much better!
In a definition of a display timing, we will never need to use the clock
binding; the clock binding would be used by the HW module that is
generating a timing, not by the timing definition itself.
You mean clock consumer bindings will be in the display device DT node?
And the display-timings node will be its child?
That said, your comment about renaming the property to avoid any kind of
conceptual conflict is still quite valid. This is bike-shedding, but
"pixel-clock" might be more in line with typical video mode terminology,
although there's certainly preference in DT for using the generic term
clock-frequency that you proposed. Either is fine by me.
quoted
quoted
+optional properties:
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
For the above two we also considered using bool properties but eventually
settled down with integer ones:
- hsync-active = <1>
for active-high and 0 for active low. This has the added advantage of
being able to omit this property in the .dts, which then doesn't mean,
that the polarity is active low, but rather, that the hsync line is not
used on this hardware. So, maybe it would be good to use the same binding
here too?
I agree. This also covers the case where analog display connectors often
use polarity to differentiate similar modes, yet digital connectors
often always use a fixed polarity since the receiving device can
"measure" the signal in more complete ways.
If the board HW inverts these lines, the same property names can exist
in the display controller itself, and the two values XORd together to
yield the final output polarity.
quoted
quoted
+ - de-active-high (bool): Data-Enable pulse is active high
+ - pixelclk-inverted (bool): pixelclock is inverted
We don't (yet) have a de-active property in V4L, don't know whether we'll
ever have to distingsuish between what some datasheets call "HREF" and
HSYNC in DT, but maybe similarly to the above an integer would be
preferred. As for pixclk, we call the property "pclk-sample" and it's also
an integer.
Thinking about this more: de-active-high is likely to be a
board-specific property and hence something in the display controller,
not in the mode definition?
quoted
quoted
+ - interlaced (bool)
Is "interlaced" a property of the hardware, i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive?
Interlace is a property of a display mode. It's quite possible for a
particular display controller to switch between interlace and
progressive output at run-time. For example, reconfiguring the output
between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
a built-in LCD display, you're probably always going to be driving the
single mode required by the panel, and that mode will likely always be
progressive. However, since this binding attempts to describe any
display timing, I think we still need this property per mode.
But why do you need this in the DT then at all? If it's fixed, as required
per display controller, then its driver will know it. If it's runtime
configurable, then it's a purely software parameter and doesn't depend on
the board?
quoted
BTW, I'm not very familiar with display
interfaces, but for interlaced you probably sometimes use a field signal,
whose polarity you also want to specify here? We use a "field-even-active"
integer property for it.
I think that's a property of the display controller itself, rather than
an individual mode, although I'm not 100% certain. My assertion is that
the physical interface that the display controller is driving will
determine whether embedded or separate sync is used, and in the separate
sync case, how the field signal is defined, and that all interlace modes
driven over that interface will use the same field signal definition.
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver and doesn't need to be present in timings DT. We did have some of
these parameters in board data previously, because we didn't have proper
display controller drivers... (2) is board specific configuration, and is
such it has to be present in DT.
In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
to be present in DT?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
From: Tomi Valkeinen <hidden> Date: 2012-10-08 09:01:18
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver and doesn't need to be present in timings DT. We did have some of
these parameters in board data previously, because we didn't have proper
display controller drivers... (2) is board specific configuration, and is
such it has to be present in DT.
In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
to be present in DT?
As I see it, this DT data is about the display (most commonly LCD
panel), i.e. what video mode(s) the panel supports. If things were done
my way, the panel's supported timings would be defined in the driver for
the panel, and DT would be left to describe board specific data, but
this approach has its benefits.
Thus, if you connect an interlaced panel to your board, you need to tell
the display controller that this panel requires interlace signal. Also,
pixel clock source doesn't make sense in this context, as this doesn't
describe the actual used configuration, but only what the panel
supports.
Of course, if this is about describing the hardware, the default-mode
property doesn't really fit in...
Tomi
Hi Tomi,
On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
quoted
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver and doesn't need to be present in timings DT. We did have some of
these parameters in board data previously, because we didn't have proper
display controller drivers... (2) is board specific configuration, and is
such it has to be present in DT.
In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
to be present in DT?
As I see it, this DT data is about the display (most commonly LCD
panel), i.e. what video mode(s) the panel supports. If things were done
my way, the panel's supported timings would be defined in the driver for
the panel, and DT would be left to describe board specific data, but
this approach has its benefits.
What about dumb DPI panels ? They will all be supported by a single driver,
would you have the driver contain information about all known DPI panels ? DT
seems a good solution to me in this case.
For complex panels where the driver will support a single (or very few) model
I agree that specifying the timings in DT isn't needed.
Thus, if you connect an interlaced panel to your board, you need to tell
the display controller that this panel requires interlace signal. Also,
pixel clock source doesn't make sense in this context, as this doesn't
describe the actual used configuration, but only what the panel
supports.
Of course, if this is about describing the hardware, the default-mode
property doesn't really fit in...
Maybe we should rename it to native-mode then ?
--
Regards,
Laurent Pinchart
From: Tomi Valkeinen <hidden> Date: 2012-10-08 12:20:16
On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
Hi Tomi,
On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
quoted
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
quoted
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver and doesn't need to be present in timings DT. We did have some of
these parameters in board data previously, because we didn't have proper
display controller drivers... (2) is board specific configuration, and is
such it has to be present in DT.
In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
to be present in DT?
As I see it, this DT data is about the display (most commonly LCD
panel), i.e. what video mode(s) the panel supports. If things were done
my way, the panel's supported timings would be defined in the driver for
the panel, and DT would be left to describe board specific data, but
this approach has its benefits.
What about dumb DPI panels ? They will all be supported by a single driver,
would you have the driver contain information about all known DPI panels ? DT
seems a good solution to me in this case.
Yes, I would have a table in the driver for all the devices it supports,
which would describe the device specific parameters.
But I don't have a problem with DT solution. Both methods have their
pros and cons, and perhaps DT based solution is more practical.
For complex panels where the driver will support a single (or very few) model
I agree that specifying the timings in DT isn't needed.
quoted
Thus, if you connect an interlaced panel to your board, you need to tell
the display controller that this panel requires interlace signal. Also,
pixel clock source doesn't make sense in this context, as this doesn't
describe the actual used configuration, but only what the panel
supports.
Of course, if this is about describing the hardware, the default-mode
property doesn't really fit in...
Maybe we should rename it to native-mode then ?
Hmm, right, if it means native mode, then it is describing the hardware.
But would it make sense to require that the native mode is the first
mode in the list, then? This would make the separate
default-mode/native-mode property not needed.
Tomi
From: Stephen Warren <hidden> Date: 2012-10-08 16:10:31
On 10/08/2012 02:25 AM, Guennadi Liakhovetski wrote:
On Fri, 5 Oct 2012, Stephen Warren wrote:
quoted
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
quoted
Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2, so, this seems a
great opportunity to me:-)
On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
You're going to hate me for this, but eventually we want to actually
reference clock objects in our DT bindings. For now, even if you don't
want to actually add clock phandles and stuff here, I think, using the
standard "clock-frequency" property would be much better!
In a definition of a display timing, we will never need to use the clock
binding; the clock binding would be used by the HW module that is
generating a timing, not by the timing definition itself.
You mean clock consumer bindings will be in the display device DT node?
And the display-timings node will be its child?
Yes
...
quoted
quoted
quoted
+ - interlaced (bool)
Is "interlaced" a property of the hardware, i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive?
Interlace is a property of a display mode. It's quite possible for a
particular display controller to switch between interlace and
progressive output at run-time. For example, reconfiguring the output
between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
a built-in LCD display, you're probably always going to be driving the
single mode required by the panel, and that mode will likely always be
progressive. However, since this binding attempts to describe any
display timing, I think we still need this property per mode.
But why do you need this in the DT then at all?
Because the driver for the display controller has no idea what display
or panel will be connected to it.
If it's fixed, as required
per display controller, then its driver will know it. If it's runtime
configurable, then it's a purely software parameter and doesn't depend on
the board?
interlace-vs-progressive isn't "fixed, as required per display
controller", but is a property of the mode being sent by the display
controller, and the requirements for that mode are driven by the
panel/display connected to the display controller, not the display
controller, in general.
...
quoted
quoted
BTW, I'm not very familiar with display
interfaces, but for interlaced you probably sometimes use a field signal,
whose polarity you also want to specify here? We use a "field-even-active"
integer property for it.
I think that's a property of the display controller itself, rather than
an individual mode, although I'm not 100% certain. My assertion is that
the physical interface that the display controller is driving will
determine whether embedded or separate sync is used, and in the separate
sync case, how the field signal is defined, and that all interlace modes
driven over that interface will use the same field signal definition.
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver and doesn't need to be present in timings DT. We did have some of
these parameters in board data previously, because we didn't have proper
display controller drivers...
Yes, there probably is data of that kind, but the display mode timings
binding is only address standardized display timings information, not
controller-specific information, and hence doesn't cover this case.
(2) is board specific configuration, and is
such it has to be present in DT.
Certainly, yes.
In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
to be present in DT?
From: Stephen Warren <hidden> Date: 2012-10-08 16:12:27
On 10/08/2012 06:20 AM, Tomi Valkeinen wrote:
On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
quoted
On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
quoted
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski
wrote:
...
quoted
quoted
Of course, if this is about describing the hardware, the
default-mode property doesn't really fit in...
Maybe we should rename it to native-mode then ?
Hmm, right, if it means native mode, then it is describing the
hardware. But would it make sense to require that the native mode
is the first mode in the list, then? This would make the separate
default-mode/native-mode property not needed.
I'm not sure if device-tree guarantees that the nodes enumerate in a
specific order. If it does, then that may be a reasonable solution.
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
quoted
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver and doesn't need to be present in timings DT. We did have some of
these parameters in board data previously, because we didn't have proper
display controller drivers... (2) is board specific configuration, and is
such it has to be present in DT.
In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
to be present in DT?
As I see it, this DT data is about the display (most commonly LCD
panel), i.e. what video mode(s) the panel supports. If things were done
my way, the panel's supported timings would be defined in the driver for
the panel, and DT would be left to describe board specific data, but
this approach has its benefits.
Thus, if you connect an interlaced panel to your board,
Do interlaced panels exist? I have never seen one.
you need to tell
the display controller that this panel requires interlace signal. Also,
pixel clock source doesn't make sense in this context, as this doesn't
describe the actual used configuration, but only what the panel
supports.
Of course, if this is about describing the hardware, the default-mode
property doesn't really fit in...
Tomi
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Hi Stephen,
On Monday 08 October 2012 10:10:31 Stephen Warren wrote:
On 10/08/2012 02:25 AM, Guennadi Liakhovetski wrote:
quoted
On Fri, 5 Oct 2012, Stephen Warren wrote:
quoted
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
quoted
Hi Steffen
Sorry for chiming in so late in the game, but I've long been wanting to
have a look at this and compare with what we do for V4L2, so, this seems
a great opportunity to me:-)
On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
You're going to hate me for this, but eventually we want to actually
reference clock objects in our DT bindings. For now, even if you don't
want to actually add clock phandles and stuff here, I think, using the
standard "clock-frequency" property would be much better!
In a definition of a display timing, we will never need to use the clock
binding; the clock binding would be used by the HW module that is
generating a timing, not by the timing definition itself.
You mean clock consumer bindings will be in the display device DT node?
And the display-timings node will be its child?
Yes
...
quoted
quoted
quoted
quoted
+ - interlaced (bool)
Is "interlaced" a property of the hardware, i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive?
Interlace is a property of a display mode. It's quite possible for a
particular display controller to switch between interlace and
progressive output at run-time. For example, reconfiguring the output
between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
a built-in LCD display, you're probably always going to be driving the
single mode required by the panel, and that mode will likely always be
progressive. However, since this binding attempts to describe any
display timing, I think we still need this property per mode.
But why do you need this in the DT then at all?
Because the driver for the display controller has no idea what display
or panel will be connected to it.
That's right, but with the current common panel framework (WIP, I plan to
resume working on it this week) the display controller will be able to query
the panel for bus configuration parameters (or the other way around, the panel
driver will set the display controller bus configuration). The panel driver
will still need to receive timing information from DT, but it will be possible
to communicate display bus configuration parameters between the panel driver
and the display controller driver.
This being said, I agree that interlaced is a property of the display mode,
not of the display bus (even though the display bus will then be configured
for interlaced data).
quoted
If it's fixed, as required per display controller, then its driver will
know it. If it's runtime configurable, then it's a purely software
parameter and doesn't depend on the board?
interlace-vs-progressive isn't "fixed, as required per display
controller", but is a property of the mode being sent by the display
controller, and the requirements for that mode are driven by the
panel/display connected to the display controller, not the display
controller, in general.
...
quoted
quoted
quoted
BTW, I'm not very familiar with display interfaces, but for interlaced
you probably sometimes use a field signal, whose polarity you also want
to specify here? We use a "field-even-active" integer property for it.
I think that's a property of the display controller itself, rather than
an individual mode, although I'm not 100% certain. My assertion is that
the physical interface that the display controller is driving will
determine whether embedded or separate sync is used, and in the separate
sync case, how the field signal is defined, and that all interlace modes
driven over that interface will use the same field signal definition.
In general, I might be misunderstanding something, but don't we have to
distinguish between 2 types of information about display timings: (1) is
defined by the display controller requirements, is known to the display
driver and doesn't need to be present in timings DT. We did have some of
these parameters in board data previously, because we didn't have proper
display controller drivers...
Yes, there probably is data of that kind, but the display mode timings
binding is only address standardized display timings information, not
controller-specific information, and hence doesn't cover this case.
quoted
(2) is board specific configuration, and is
such it has to be present in DT.
Certainly, yes.
quoted
In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
to be present in DT?