All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Steffen Trumtrar <s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Mohammed,
	Afzal" <afzal-l0cyMroinI0@public.gmane.org>,
	Dave Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Florian Tobias Schandinat
	<FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	Guennady Liakhovetski
	<g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>,
	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v17 2/7] video: add display_timing and videomode
Date: Wed, 27 Feb 2013 16:13:49 +0000	[thread overview]
Message-ID: <512E30BD.7010603@ti.com> (raw)
In-Reply-To: <20130227160540.GA10491-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

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

On 2013-02-27 18:05, Steffen Trumtrar wrote:
> Ah, sorry. Forgot to answer this.
> 
> On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
>> Ping.
>>
>> On 2013-02-18 16:09, Tomi Valkeinen wrote:
>>> Hi Steffen,
>>>
>>> On 2013-01-25 11:01, Steffen Trumtrar wrote:
>>>
>>>> +/* VESA display monitor timing parameters */
>>>> +#define VESA_DMT_HSYNC_LOW		BIT(0)
>>>> +#define VESA_DMT_HSYNC_HIGH		BIT(1)
>>>> +#define VESA_DMT_VSYNC_LOW		BIT(2)
>>>> +#define VESA_DMT_VSYNC_HIGH		BIT(3)
>>>> +
>>>> +/* display specific flags */
>>>> +#define DISPLAY_FLAGS_DE_LOW		BIT(0)	/* data enable flag */
>>>> +#define DISPLAY_FLAGS_DE_HIGH		BIT(1)
>>>> +#define DISPLAY_FLAGS_PIXDATA_POSEDGE	BIT(2)	/* drive data on pos. edge */
>>>> +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE	BIT(3)	/* drive data on neg. edge */
>>>> +#define DISPLAY_FLAGS_INTERLACED	BIT(4)
>>>> +#define DISPLAY_FLAGS_DOUBLESCAN	BIT(5)
>>>
>>> <snip>
>>>
>>>> +	unsigned int dmt_flags;	/* VESA DMT flags */
>>>> +	unsigned int data_flags; /* video data flags */
>>>
>>> Why did you go for this approach? To be able to represent
>>> true/false/not-specified?
>>>
> 
> We decided somewhere between v3 and v8 (I think), that those flags can be
> high/low/ignored.

Okay. Why aren't they enums, though? That always makes more clear which
defines are to be used with which fields.

>>> Would it be simpler to just have "flags" field? What does it give us to
>>> have those two separately?
>>>
> 
> I decided to split them, so it is clear that some flags are VESA defined and
> the others are "invented" for the display-timings framework and may be
> extended.

Hmm... Okay. Is it relevant that they are VESA defined? It just feels to
complicate handling the flags =).

>>> Should the above say raising edge/falling edge instead of positive
>>> edge/negative edge?
>>>
> 
> Hm, I used posedge/negedge because it is shorter (and because of my Verilog past
> pretty natural to me :-) ). I don't know what others are thinking though.

I guess it's quite clear, but it's still different terms than used
elsewhere, e.g. documentation for videomodes.

Another thing I noticed while using the new videomode, display_timings.h
has a few names that are quite short and generic. Like "TE_MIN", which
is now a global define. And "timing_entry". Either name could be well
used internally in some .c file, and could easily clash.

 Tomi



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

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
To: Steffen Trumtrar <s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Mohammed,
	Afzal" <afzal-l0cyMroinI0@public.gmane.org>,
	Dave Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Florian Tobias Schandinat
	<FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	Guennady Liakhovetski
	<g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>,
	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v17 2/7] video: add display_timing and videomode
Date: Wed, 27 Feb 2013 18:13:49 +0200	[thread overview]
Message-ID: <512E30BD.7010603@ti.com> (raw)
In-Reply-To: <20130227160540.GA10491-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>


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

On 2013-02-27 18:05, Steffen Trumtrar wrote:
> Ah, sorry. Forgot to answer this.
> 
> On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
>> Ping.
>>
>> On 2013-02-18 16:09, Tomi Valkeinen wrote:
>>> Hi Steffen,
>>>
>>> On 2013-01-25 11:01, Steffen Trumtrar wrote:
>>>
>>>> +/* VESA display monitor timing parameters */
>>>> +#define VESA_DMT_HSYNC_LOW		BIT(0)
>>>> +#define VESA_DMT_HSYNC_HIGH		BIT(1)
>>>> +#define VESA_DMT_VSYNC_LOW		BIT(2)
>>>> +#define VESA_DMT_VSYNC_HIGH		BIT(3)
>>>> +
>>>> +/* display specific flags */
>>>> +#define DISPLAY_FLAGS_DE_LOW		BIT(0)	/* data enable flag */
>>>> +#define DISPLAY_FLAGS_DE_HIGH		BIT(1)
>>>> +#define DISPLAY_FLAGS_PIXDATA_POSEDGE	BIT(2)	/* drive data on pos. edge */
>>>> +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE	BIT(3)	/* drive data on neg. edge */
>>>> +#define DISPLAY_FLAGS_INTERLACED	BIT(4)
>>>> +#define DISPLAY_FLAGS_DOUBLESCAN	BIT(5)
>>>
>>> <snip>
>>>
>>>> +	unsigned int dmt_flags;	/* VESA DMT flags */
>>>> +	unsigned int data_flags; /* video data flags */
>>>
>>> Why did you go for this approach? To be able to represent
>>> true/false/not-specified?
>>>
> 
> We decided somewhere between v3 and v8 (I think), that those flags can be
> high/low/ignored.

Okay. Why aren't they enums, though? That always makes more clear which
defines are to be used with which fields.

>>> Would it be simpler to just have "flags" field? What does it give us to
>>> have those two separately?
>>>
> 
> I decided to split them, so it is clear that some flags are VESA defined and
> the others are "invented" for the display-timings framework and may be
> extended.

Hmm... Okay. Is it relevant that they are VESA defined? It just feels to
complicate handling the flags =).

>>> Should the above say raising edge/falling edge instead of positive
>>> edge/negative edge?
>>>
> 
> Hm, I used posedge/negedge because it is shorter (and because of my Verilog past
> pretty natural to me :-) ). I don't know what others are thinking though.

I guess it's quite clear, but it's still different terms than used
elsewhere, e.g. documentation for videomodes.

Another thing I noticed while using the new videomode, display_timings.h
has a few names that are quite short and generic. Like "TE_MIN", which
is now a global define. And "timing_entry". Either name could be well
used internally in some .c file, and could easily clash.

 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

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: <devicetree-discuss@lists.ozlabs.org>,
	Dave Airlie <airlied@linux.ie>,
	Rob Herring <robherring2@gmail.com>,
	<linux-fbdev@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Thierry Reding <thierry.reding@avionic-design.de>,
	Guennady Liakhovetski <g.liakhovetski@gmx.de>,
	<linux-media@vger.kernel.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Florian Tobias Schandinat <FlorianSchandinat@gmx.de>,
	Rob Clark <robdclark@gmail.com>,
	Leela Krishna Amudala <leelakrishna.a@gmail.com>,
	"Mohammed, Afzal" <afzal@ti.com>, <kernel@pengutronix.de>
Subject: Re: [PATCH v17 2/7] video: add display_timing and videomode
Date: Wed, 27 Feb 2013 18:13:49 +0200	[thread overview]
Message-ID: <512E30BD.7010603@ti.com> (raw)
In-Reply-To: <20130227160540.GA10491@pengutronix.de>

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

On 2013-02-27 18:05, Steffen Trumtrar wrote:
> Ah, sorry. Forgot to answer this.
> 
> On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
>> Ping.
>>
>> On 2013-02-18 16:09, Tomi Valkeinen wrote:
>>> Hi Steffen,
>>>
>>> On 2013-01-25 11:01, Steffen Trumtrar wrote:
>>>
>>>> +/* VESA display monitor timing parameters */
>>>> +#define VESA_DMT_HSYNC_LOW		BIT(0)
>>>> +#define VESA_DMT_HSYNC_HIGH		BIT(1)
>>>> +#define VESA_DMT_VSYNC_LOW		BIT(2)
>>>> +#define VESA_DMT_VSYNC_HIGH		BIT(3)
>>>> +
>>>> +/* display specific flags */
>>>> +#define DISPLAY_FLAGS_DE_LOW		BIT(0)	/* data enable flag */
>>>> +#define DISPLAY_FLAGS_DE_HIGH		BIT(1)
>>>> +#define DISPLAY_FLAGS_PIXDATA_POSEDGE	BIT(2)	/* drive data on pos. edge */
>>>> +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE	BIT(3)	/* drive data on neg. edge */
>>>> +#define DISPLAY_FLAGS_INTERLACED	BIT(4)
>>>> +#define DISPLAY_FLAGS_DOUBLESCAN	BIT(5)
>>>
>>> <snip>
>>>
>>>> +	unsigned int dmt_flags;	/* VESA DMT flags */
>>>> +	unsigned int data_flags; /* video data flags */
>>>
>>> Why did you go for this approach? To be able to represent
>>> true/false/not-specified?
>>>
> 
> We decided somewhere between v3 and v8 (I think), that those flags can be
> high/low/ignored.

Okay. Why aren't they enums, though? That always makes more clear which
defines are to be used with which fields.

>>> Would it be simpler to just have "flags" field? What does it give us to
>>> have those two separately?
>>>
> 
> I decided to split them, so it is clear that some flags are VESA defined and
> the others are "invented" for the display-timings framework and may be
> extended.

Hmm... Okay. Is it relevant that they are VESA defined? It just feels to
complicate handling the flags =).

>>> Should the above say raising edge/falling edge instead of positive
>>> edge/negative edge?
>>>
> 
> Hm, I used posedge/negedge because it is shorter (and because of my Verilog past
> pretty natural to me :-) ). I don't know what others are thinking though.

I guess it's quite clear, but it's still different terms than used
elsewhere, e.g. documentation for videomodes.

Another thing I noticed while using the new videomode, display_timings.h
has a few names that are quite short and generic. Like "TE_MIN", which
is now a global define. And "timing_entry". Either name could be well
used internally in some .c file, and could easily clash.

 Tomi



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

  parent reply	other threads:[~2013-02-27 16:13 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25  9:01 [PATCH v17 0/7] of: add display helper Steffen Trumtrar
2013-01-25  9:01 ` Steffen Trumtrar
2013-01-25  9:01 ` [PATCH v17 1/7] viafb: rename display_timing to via_display_timing Steffen Trumtrar
2013-01-25  9:01   ` Steffen Trumtrar
2013-01-25  9:01 ` [PATCH v17 2/7] video: add display_timing and videomode Steffen Trumtrar
2013-01-25  9:01   ` Steffen Trumtrar
2013-02-18 14:09   ` Tomi Valkeinen
2013-02-18 14:09     ` Tomi Valkeinen
     [not found]     ` <51223615.4090709-X3B1VOXEql0@public.gmane.org>
2013-02-27 15:45       ` Tomi Valkeinen
2013-02-27 15:45         ` Tomi Valkeinen
2013-02-27 15:45         ` Tomi Valkeinen
2013-02-27 16:05         ` Steffen Trumtrar
2013-02-27 16:05           ` Steffen Trumtrar
     [not found]           ` <20130227160540.GA10491-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2013-02-27 16:13             ` Tomi Valkeinen [this message]
2013-02-27 16:13               ` Tomi Valkeinen
2013-02-27 16:13               ` Tomi Valkeinen
     [not found]               ` <512E30BD.7010603-l0cyMroinI0@public.gmane.org>
2013-03-05  9:24                 ` Steffen Trumtrar
2013-03-05  9:24                   ` Steffen Trumtrar
2013-03-05  9:24                   ` Steffen Trumtrar
2013-01-25  9:01 ` =?UTF-8?q?=5BPATCH=20v17=203/7=5D=20video=3A=20add=20of=20helper=20for=20display=20timings/videomode Steffen Trumtrar
2013-01-25  9:01   ` [PATCH v17 3/7] video: add of helper for display timings/videomode Steffen Trumtrar
2013-01-25  9:01 ` [PATCH v17 4/7] fbmon: add videomode helpers Steffen Trumtrar
2013-01-25  9:01   ` Steffen Trumtrar
2013-02-01  9:29   ` Jingoo Han
2013-02-01  9:29     ` Jingoo Han
2013-02-01  9:29     ` Jingoo Han
     [not found]     ` <003401ce005e$af665c50$0e3314f0$%han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-02-05 18:29       ` Steffen Trumtrar
2013-02-05 18:29         ` Steffen Trumtrar
2013-02-05 18:29         ` Steffen Trumtrar
2013-01-25  9:01 ` [PATCH v17 5/7] fbmon: add of_videomode helpers Steffen Trumtrar
2013-01-25  9:01   ` Steffen Trumtrar
2013-01-25  9:01 ` [PATCH v17 6/7] drm_modes: add videomode helpers Steffen Trumtrar
2013-01-25  9:01   ` Steffen Trumtrar
2013-01-25  9:01 ` [PATCH v17 7/7] drm_modes: add of_videomode helpers Steffen Trumtrar
2013-01-25  9:01   ` Steffen Trumtrar
  -- strict thread matches above, loose matches on Subject: below --
2013-02-01  9:33 [PATCH v17 4/7] fbmon: add videomode helpers Jingoo Han
2013-02-01  9:33 ` Jingoo Han
2013-02-01  9:33 ` Jingoo Han

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=512E30BD.7010603@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org \
    --cc=afzal-l0cyMroinI0@public.gmane.org \
    --cc=airlied-cv59FeDIM0c@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=g.liakhovetski-Mmb7MZpHnFY@public.gmane.org \
    --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.