All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: kernel@pengutronix.de, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/panel: Add display_timing support
Date: Tue, 3 Feb 2015 14:30:16 +0100	[thread overview]
Message-ID: <20150203133015.GH15068@ulmo.nvidia.com> (raw)
In-Reply-To: <1418319166-23357-1-git-send-email-p.zabel@pengutronix.de>


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

On Thu, Dec 11, 2014 at 06:32:44PM +0100, Philipp Zabel wrote:
> Many panel data sheets additionally to typical values list allowed ranges for
> timings such as hsync/vsync lengths, porches, and the pixel clock rate. These
> can be stored in a struct display_timing, to be used by an encoder mode_fixup
> callback to clamp user provided timing values or to validate workarounds for
> clock source limitations.
> 
> This patch adds a new drm_panel_funcs callback that returns the panels'
> available display_timing entries.
> 
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
>  include/drm/drm_panel.h | 5 +++++
>  1 file changed, 5 insertions(+)

Sorry for taking so long to get back on this. I generally like the idea,
though a couple of things are unclear to me.

In struct display_timing we have:

	struct timing_entry hactive;
	...
	struct timing_entry vactive;

I wonder if that really makes sense. Are there really datasheets that
provide a valid range for the number of horizontal and vertical active
pixels?

> 
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 1fbcc96..13ff44b 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -29,6 +29,7 @@
>  struct drm_connector;
>  struct drm_device;
>  struct drm_panel;
> +struct display_timing;
>  
>  /**
>   * struct drm_panel_funcs - perform operations on a given panel
> @@ -38,6 +39,8 @@ struct drm_panel;
>   * @enable: enable panel (turn on back light, etc.)
>   * @get_modes: add modes to the connector that the panel is attached to and
>   * return the number of modes added
> + * @get_timings: copy display timings into the provided array and return
> + * the number of display timings available
>   *
>   * The .prepare() function is typically called before the display controller
>   * starts to transmit video data. Panel drivers can use this to turn the panel
> @@ -68,6 +71,8 @@ struct drm_panel_funcs {
>  	int (*prepare)(struct drm_panel *panel);
>  	int (*enable)(struct drm_panel *panel);
>  	int (*get_modes)(struct drm_panel *panel);
> +	int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
> +			   struct display_timing *timings);

Also are there even panels that support more than one set of timings?
I've never heard of panels that are actually able to do more than one
mode, so I'm wondering if num_timings isn't overdoing it a little here.
I guess it doesn't hurt all that much, though.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

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

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

  parent reply	other threads:[~2015-02-03 13:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-11 17:32 [PATCH 1/3] drm/panel: Add display_timing support Philipp Zabel
2014-12-11 17:32 ` [PATCH 2/3] drm/panel: Add display_timing support to simple panel driver Philipp Zabel
2014-12-11 17:32 ` [PATCH 3/3] drm/panel: Add display_timing entry for the HannStar HSD070PWW1 panel Philipp Zabel
2015-02-03 13:30 ` Thierry Reding [this message]
2015-02-03 16:56   ` [PATCH 1/3] drm/panel: Add display_timing support Philipp Zabel
2015-02-23 14:04   ` Philipp Zabel
2015-02-26 13:51     ` Boris Brezillon
2015-02-26 18:33       ` Philipp Zabel
2015-03-03 11:49     ` Philipp Zabel
2015-03-24 11:34       ` Thierry Reding
2015-03-24 11:52         ` Philipp Zabel
2015-03-24 12:40           ` Thierry Reding
2015-03-24 16:36             ` Philipp Zabel

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=20150203133015.GH15068@ulmo.nvidia.com \
    --to=thierry.reding@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@pengutronix.de \
    --cc=p.zabel@pengutronix.de \
    /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.