dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>,
	dri-devel@lists.freedesktop.org, kernel@pengutronix.de
Subject: Re: [PATCH 1/3] drm/panel: Add display_timing support
Date: Tue, 03 Mar 2015 12:49:43 +0100	[thread overview]
Message-ID: <1425383383.3146.53.camel@pengutronix.de> (raw)
In-Reply-To: <1424700272.3623.7.camel@pengutronix.de>

Hi Thierry,

Am Montag, den 23.02.2015, 15:04 +0100 schrieb Philipp Zabel:
> Hi Thierry,
> 
> do you have any further thoughts on this?

[...]
> > 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?
> 
> I could send a patch to change hactive/vactive to a single value
> and change Documentation/devicetree/bindings/video/display-timing.txt
> to clarify ranges are not allowed for these properties until somebody
> digs out a panel that actually needs this.
> Adding Steffen to Cc: in case there was a reason other than symmetry.

That seems not to be the case so far.

[...]
> > >  /**
> > >   * 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.
> 
> Would you prefer
> 	struct display_timing *(*get_timing)(struct drm_panel *panel);
> ?

I'd like to resend this. Please let me know if you want me to change
this function prototype.

regards
Philipp

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

  parent reply	other threads:[~2015-03-03 11:49 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 ` [PATCH 1/3] drm/panel: Add display_timing support Thierry Reding
2015-02-03 16:56   ` 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 [this message]
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=1425383383.3146.53.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@pengutronix.de \
    --cc=s.trumtrar@pengutronix.de \
    --cc=thierry.reding@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox