Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Denis,
Thanks for the patch.
On 03/13/2014 06:17 PM, Denis Carikli wrote:
> We need a way to pass signal polarity informations
> between DRM panels, and the display drivers.
>
> To do that, a pol_flags field was added to drm_display_mode.
>
> Signed-off-by: Denis Carikli
> ---
> ChangeLog v10->v11:
> - Since the imx-drm won't be able to retrive its regulators
> from the device tree when using display-timings nodes,
> and that I was told that the drm simple-panel driver
> already supported that, I then, instead, added what was
> lacking to make the eukrea displays work with the
> drm-simple-panel driver.
>
> That required a way to get back the display polarity
> informations from the imx-drm driver without affecting
> userspace.
> ---
> include/drm/drm_crtc.h |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f764654..61a4fe1 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -131,6 +131,13 @@ enum drm_mode_status {
>
> #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
>
> +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
> +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
> +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> +#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
Could you add some description to these flags.
What are *_PRESERVE flags for?
Are those flags 1:1 compatible with respective 'videomode:flags'?
I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
right?
Regards
Andrzej
> +
> struct drm_display_mode {
> /* Header */
> struct list_head head;
> @@ -183,6 +190,7 @@ struct drm_display_mode {
> int vrefresh; /* in Hz */
> int hsync; /* in kHz */
> enum hdmi_picture_aspect picture_aspect_ratio;
> + unsigned int pol_flags;
> };
>
> static inline bool drm_mode_is_stereo(const struct drm_display_mode *mode)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hello,
On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > We need a way to pass signal polarity informations
> > between DRM panels, and the display drivers.
> >
> > To do that, a pol_flags field was added to drm_display_mode.
> >
> > Signed-off-by: Denis Carikli
> > ---
> > ChangeLog v10->v11:
> > - Since the imx-drm won't be able to retrive its regulators
> >
> > from the device tree when using display-timings nodes,
> > and that I was told that the drm simple-panel driver
> > already supported that, I then, instead, added what was
> > lacking to make the eukrea displays work with the
> > drm-simple-panel driver.
> >
> > That required a way to get back the display polarity
> > informations from the imx-drm driver without affecting
> > userspace.
> >
> > ---
> >
> > include/drm/drm_crtc.h |8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index f764654..61a4fe1 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -131,6 +131,13 @@ enum drm_mode_status {
> >
> > #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> >
> > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
> > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
> > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > +#define DRM_MODE_FLAG_POL_DE_PRESERVE BIT(6)
>
> Could you add some description to these flags.
> What are *_PRESERVE flags for?
> Are those flags 1:1 compatible with respective 'videomode:flags'?
> I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
> right?
Possibly nitpicking, I wouldn't call the clock edge on which data signals are
generated/sampled "data polarity". This is clock polarity information.
Have you seen cases where pixel data and DE are geenrated or need to be
sampled on different edges ?
> > +
> > struct drm_display_mode {
> > /* Header */
> > struct list_head head;
> > @@ -183,6 +190,7 @@ struct drm_display_mode {
> > int vrefresh; /* in Hz */
> > int hsync; /* in kHz */
> > enum hdmi_picture_aspect picture_aspect_ratio;
> > + unsigned int pol_flags;
> > };
> >
> > static inline bool drm_mode_is_stereo(const struct drm_display_mode
> > *mode)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
> Hello,
>
> On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > We need a way to pass signal polarity informations
> > > between DRM panels, and the display drivers.
> > >
> > > To do that, a pol_flags field was added to drm_display_mode.
> > >
> > > Signed-off-by: Denis Carikli
> > > ---
> > > ChangeLog v10->v11:
> > > - Since the imx-drm won't be able to retrive its regulators
> > >
> > > from the device tree when using display-timings nodes,
> > > and that I was told that the drm simple-panel driver
> > > already supported that, I then, instead, added what was
> > > lacking to make the eukrea displays work with the
> > > drm-simple-panel driver.
> > >
> > > That required a way to get back the display polarity
> > > informations from the imx-drm driver without affecting
> > > userspace.
> > >
> > > ---
> > >
> > > include/drm/drm_crtc.h |8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index f764654..61a4fe1 100644
> > > --- a/include/drm/drm_crtc.h
> > > +++ b/include/drm/drm_crtc.h
> > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > >
> > > #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > >
> > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
> > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
> > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > +#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
> >
> > Could you add some description to these flags.
> > What are *_PRESERVE flags for?
> > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
> > right?
>
> Possibly nitpicking, I wouldn't call the clock edge on which data signals are
> generated/sampled "data polarity". This is clock polarity information.
>
> Have you seen cases where pixel data and DE are geenrated or need to be
> sampled on different edges ?
>
DE is not a clock signal, but an 'Enable' signal whose value (high or
low) defines the window in which the pixel data is valid.
The flag defines whether data is valid during the HIGH or LOW period of
DE.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Lothar,
On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> Laurent Pinchart wrote:
> > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > > We need a way to pass signal polarity informations
> > > > between DRM panels, and the display drivers.
> > > >
> > > > To do that, a pol_flags field was added to drm_display_mode.
> > > >
> > > > Signed-off-by: Denis Carikli
> > > > ---
> > > > ChangeLog v10->v11:
> > > > - Since the imx-drm won't be able to retrive its regulators
> > > >
> > > > from the device tree when using display-timings nodes,
> > > > and that I was told that the drm simple-panel driver
> > > > already supported that, I then, instead, added what was
> > > > lacking to make the eukrea displays work with the
> > > > drm-simple-panel driver.
> > > >
> > > > That required a way to get back the display polarity
> > > > informations from the imx-drm driver without affecting
> > > > userspace.
> > > >
> > > > ---
> > > >
> > > > include/drm/drm_crtc.h |8
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > index f764654..61a4fe1 100644
> > > > --- a/include/drm/drm_crtc.h
> > > > +++ b/include/drm/drm_crtc.h
> > > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > > >
> > > > #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > >
> > > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
> > > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
> > > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > > +#define DRM_MODE_FLAG_POL_DE_PRESERVE BIT(6)
> > >
> > > Could you add some description to these flags.
> > > What are *_PRESERVE flags for?
> > > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
> > > right?
> >
> > Possibly nitpicking, I wouldn't call the clock edge on which data signals
> > are generated/sampled "data polarity". This is clock polarity
> > information.
> >
> > Have you seen cases where pixel data and DE are geenrated or need to be
> > sampled on different edges ?
>
> DE is not a clock signal, but an 'Enable' signal whose value (high or
> low) defines the window in which the pixel data is valid.
> The flag defines whether data is valid during the HIGH or LOW period of
> DE.
The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed new
DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges, not
active levels.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
> Hi Lothar,
>
> On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> > Laurent Pinchart wrote:
> > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > > > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > > > We need a way to pass signal polarity informations
> > > > > between DRM panels, and the display drivers.
> > > > >
> > > > > To do that, a pol_flags field was added to drm_display_mode.
> > > > >
> > > > > Signed-off-by: Denis Carikli
> > > > > ---
> > > > > ChangeLog v10->v11:
> > > > > - Since the imx-drm won't be able to retrive its regulators
> > > > >
> > > > > from the device tree when using display-timings nodes,
> > > > > and that I was told that the drm simple-panel driver
> > > > > already supported that, I then, instead, added what was
> > > > > lacking to make the eukrea displays work with the
> > > > > drm-simple-panel driver.
> > > > >
> > > > > That required a way to get back the display polarity
> > > > > informations from the imx-drm driver without affecting
> > > > > userspace.
> > > > >
> > > > > ---
> > > > >
> > > > > include/drm/drm_crtc.h |8
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > > index f764654..61a4fe1 100644
> > > > > --- a/include/drm/drm_crtc.h
> > > > > +++ b/include/drm/drm_crtc.h
> > > > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > > > >
> > > > > #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > >
> > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
> > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
> > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > > > +#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
> > > >
> > > > Could you add some description to these flags.
> > > > What are *_PRESERVE flags for?
> > > > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > > > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH), am I
> > > > right?
> > >
> > > Possibly nitpicking, I wouldn't call the clock edge on which data signals
> > > are generated/sampled "data polarity". This is clock polarity
> > > information.
> > >
> > > Have you seen cases where pixel data and DE are geenrated or need to be
> > > sampled on different edges ?
> >
> > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > low) defines the window in which the pixel data is valid.
> > The flag defines whether data is valid during the HIGH or LOW period of
> > DE.
>
> The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed new
> DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges,
> not
> active levels.
>
The current naming of the flags gives the impression that they describe
the sampling edges of a clock signal. But the DE signal in fact is not
a clock signal but a level sensitive gating signal.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
On Tue, Mar 18, 2014 at 08:50:30AM +0100, Lothar Waßmann wrote: > Hi, > > Laurent Pinchart wrote: > > Hi Lothar, > > > > On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote: > > > DE is not a clock signal, but an 'Enable' signal whose value (high or > > > low) defines the window in which the pixel data is valid. > > > The flag defines whether data is valid during the HIGH or LOW period of > > > DE. > > > > The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed > > new > > DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock edges, > > not > > active levels. > > > The current naming of the flags gives the impression that they describe > the sampling edges of a clock signal. But the DE signal in fact is not > a clock signal but a level sensitive gating signal. +1 -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Lothar,
On Tuesday 18 March 2014 08:50:30 Lothar Waßmann wrote:
> Laurent Pinchart wrote:
> > On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> > > Laurent Pinchart wrote:
> > > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > > > > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > > > > We need a way to pass signal polarity informations
> > > > > > between DRM panels, and the display drivers.
> > > > > >
> > > > > > To do that, a pol_flags field was added to drm_display_mode.
> > > > > >
> > > > > > Signed-off-by: Denis Carikli
> > > > > > ---
> > > > > > ChangeLog v10->v11:
> > > > > > - Since the imx-drm won't be able to retrive its regulators
> > > > > >
> > > > > > from the device tree when using display-timings nodes,
> > > > > > and that I was told that the drm simple-panel driver
> > > > > > already supported that, I then, instead, added what was
> > > > > > lacking to make the eukrea displays work with the
> > > > > > drm-simple-panel driver.
> > > > > >
> > > > > > That required a way to get back the display polarity
> > > > > > informations from the imx-drm driver without affecting
> > > > > > userspace.
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > include/drm/drm_crtc.h |8
> > > > > > 1 file changed, 8 insertions(+)
> > > > > >
> > > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > > > index f764654..61a4fe1 100644
> > > > > > --- a/include/drm/drm_crtc.h
> > > > > > +++ b/include/drm/drm_crtc.h
> > > > > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > > > > >
> > > > > > #define DRM_MODE_FLAG_3D_MAX
> > > > > > DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > > >
> > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
> > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
> > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > > > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > > > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > > > > +#define DRM_MODE_FLAG_POL_DE_PRESERVE BIT(6)
> > > > >
> > > > > Could you add some description to these flags.
> > > > > What are *_PRESERVE flags for?
> > > > > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > > > > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH),
> > > > > am I right?
> > > >
> > > > Possibly nitpicking, I wouldn't call the clock edge on which data
> > > > signals are generated/sampled "data polarity". This is clock polarity
> > > > information.
> > > >
> > > > Have you seen cases where pixel data and DE are geenrated or need to
> > > > be sampled on different edges ?
> > >
> > > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > > low) defines the window in which the pixel data is valid.
> > > The flag defines whether data is valid during the HIGH or LOW period of
> > > DE.
> >
> > The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed
> > new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock
> > edges, not active levels.
>
> The current naming of the flags gives the impression that they describe
> the sampling edges of a clock signal. But the DE signal in fact is not
> a clock signal but a level sensitive gating signal.
That's not my point. I *know* that DE is a data gating signal with a polarity
already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
signals it gets generated on a clock edge and is sampled on a clock edge. The
DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe just
that, *not* the signal polarity. I thus want to know whether there are systems
where the data signals and the DE signal need to be sampled on different edges
of the pixel clock.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: > Hi Lothar, > > That's not my point. I *know* that DE is a data gating signal with a polarity > already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other > signals it gets generated on a clock edge and is sampled on a clock edge. The > DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe > just > that, *not* the signal polarity. I thus want to know whether there are > systems > where the data signals and the DE signal need to be sampled on different > edges > of the pixel clock. That's not relevant to this patch series though. This patch series is about adding configuration which will allow iMX6 SoCs to be properly configured for their displays. iMX has the ability to: - define the polarity of the clock signal - define the polarity of the other signals It does not have the ability to define which clock edge individual signals like vsync (frame clock), hsync (line clock), disable enable change on independently. So, it doesn't make sense _here_ for the display enable to be defined by an edge - it's not something that can be changed here. What can only be changed is it's active level. Of course, there may be some which can do this, and that's a separate problem that would need to be addressed when there's hardware that does support it. The objection which Lothar is raising is that _this_ definition does not match the _hardware_ capabilities which it is intended to be used with, which is a very valid objection. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi Russell, On Tuesday 18 March 2014 12:56:23 Russell King - ARM Linux wrote: > On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: > > Hi Lothar, > > > > That's not my point. I *know* that DE is a data gating signal with a > > polarity already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. > > Like all other signals it gets generated on a clock edge and is sampled > > on a clock edge. The DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above > > describe seem to describe just that, *not* the signal polarity. I thus > > want to know whether there are systems where the data signals and the DE > > signal need to be sampled on different edges of the pixel clock. > > That's not relevant to this patch series though. This patch series is > about adding configuration which will allow iMX6 SoCs to be properly > configured for their displays. > > iMX has the ability to: > > - define the polarity of the clock signal > - define the polarity of the other signals > > It does not have the ability to define which clock edge individual signals > like vsync (frame clock), hsync (line clock), disable enable change on > independently. > > So, it doesn't make sense _here_ for the display enable to be defined by > an edge - it's not something that can be changed here. What can only be > changed is it's active level. > > Of course, there may be some which can do this, and that's a separate > problem that would need to be addressed when there's hardware that does > support it. > > The objection which Lothar is raising is that _this_ definition does not > match the _hardware_ capabilities which it is intended to be used with, > which is a very valid objection. Thank you for the clarification. That absolutely makes sense. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags
Hi,
Laurent Pinchart wrote:
> Hi Lothar,
>
> On Tuesday 18 March 2014 08:50:30 Lothar Waßmann wrote:
> > Laurent Pinchart wrote:
> > > On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> > > > Laurent Pinchart wrote:
> > > > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote:
> > > > > > On 03/13/2014 06:17 PM, Denis Carikli wrote:
> > > > > > > We need a way to pass signal polarity informations
> > > > > > > between DRM panels, and the display drivers.
> > > > > > >
> > > > > > > To do that, a pol_flags field was added to drm_display_mode.
> > > > > > >
> > > > > > > Signed-off-by: Denis Carikli
> > > > > > > ---
> > > > > > > ChangeLog v10->v11:
> > > > > > > - Since the imx-drm won't be able to retrive its regulators
> > > > > > >
> > > > > > > from the device tree when using display-timings nodes,
> > > > > > > and that I was told that the drm simple-panel driver
> > > > > > > already supported that, I then, instead, added what was
> > > > > > > lacking to make the eukrea displays work with the
> > > > > > > drm-simple-panel driver.
> > > > > > >
> > > > > > > That required a way to get back the display polarity
> > > > > > > informations from the imx-drm driver without affecting
> > > > > > > userspace.
> > > > > > >
> > > > > > > ---
> > > > > > >
> > > > > > > include/drm/drm_crtc.h |8
> > > > > > > 1 file changed, 8 insertions(+)
> > > > > > >
> > > > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > > > > index f764654..61a4fe1 100644
> > > > > > > --- a/include/drm/drm_crtc.h
> > > > > > > +++ b/include/drm/drm_crtc.h
> > > > > > > @@ -131,6 +131,13 @@ enum drm_mode_status {
> > > > > > >
> > > > > > > #define DRM_MODE_FLAG_3D_MAX
> > > > > > > DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > > > >
> > > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGEBIT(1)
> > > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGEBIT(2)
> > > > > > > +#define DRM_MODE_FLAG_POL_PIXDATA_PRESERVE BIT(3)
> > > > > > > +#define DRM_MODE_FLAG_POL_DE_NEGEDGE BIT(4)
> > > > > > > +#define DRM_MODE_FLAG_POL_DE_POSEDGE BIT(5)
> > > > > > > +#define DRM_MODE_FLAG_POL_DE_PRESERVEBIT(6)
> > > > > >
> > > > > > Could you add some description to these flags.
> > > > > > What are *_PRESERVE flags for?
> > > > > > Are those flags 1:1 compatible with respective 'videomode:flags'?
> > > > > > I guess DE flags should be rather DRM_MODE_FLAG_POL_DE_(LOW|HIGH),
> > > > > > am I right?
> > > > >
> > > > > Possibly nitpicking, I wouldn't call the clock edge on which data
> > > > > signals are generated/sampled "data polarity". This is clock polarity
> > > > > information.
> > > > >
> > > > > Have you seen cases where pixel data and DE are geenrated or need to
> > > > > be sampled on different edges ?
> > > >
> > > > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > > > low) defines the window in which the pixel data is valid.
> > > > The flag defines whether data is valid during the HIGH or LOW period of
> > > > DE.
> > >
> > > The DRM_MODE_FLAG_POL_DE_(LOW|HIGH) do, by my impression of the proposed
> > > new DRM_MODE_FLAG_POL_DE_*EDGE flags is that they define sampling clock
> > > edges, not active levels.
> >
> > The current naming of the flags gives the impression that they describe
> > the sampling edges of a clock signal. But the DE signal in fact is not
> > a clock signal but a level sensitive gating signal.
>
> That's not my point. I *know* that DE is a data gating signal with a polarity
> already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
> signals it gets generated on a clock edge and is sampled on a clock edge. The
> DRM_MODE_FLAG_POL_DE_*EDGE flags proposed above describe seem to describe
> just
>
The important word here is 'seem'.
Lothar Waßann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
