From: Philipp Zabel <p.zabel@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>,
Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: dri-devel@lists.freedesktop.org, kernel@pengutronix.de
Subject: Re: [PATCH 1/3] drm/panel: Add display_timing support
Date: Mon, 23 Feb 2015 15:04:32 +0100 [thread overview]
Message-ID: <1424700272.3623.7.camel@pengutronix.de> (raw)
In-Reply-To: <20150203133015.GH15068@ulmo.nvidia.com>
Hi Thierry,
do you have any further thoughts on this?
Am Dienstag, den 03.02.2015, 14:30 +0100 schrieb Thierry Reding:
> 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?
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.
> > 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.
Would you prefer
struct display_timing *(*get_timing)(struct drm_panel *panel);
?
regards
Philipp
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-02-23 14:04 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 [this message]
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=1424700272.3623.7.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