Re: [PATCH 1/3] drm/panel: Add display_timing support

[Philipp Zabel <p.zabel@pengutronix.de>]

Hi Thierry,

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 often see datasheets that give minimum, typical and maximum values
also for the horizontal and vertical active pixels, but those are
usually the same value. I don't know if there are any panels that really
have documented ranges here. 

[...]
> > @@ -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.

I have not seen any yet that reasonably should be driven by the
simple-panel driver. I was thinking about the Pixel Qi panel, but it
turns out those just have a single timing and use the subpixels in B/W
reflective mode.

regards
Philipp

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