From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 1/3] drm/panel: Add display_timing support Date: Tue, 3 Feb 2015 14:30:16 +0100 Message-ID: <20150203133015.GH15068@ulmo.nvidia.com> References: <1418319166-23357-1-git-send-email-p.zabel@pengutronix.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0817960384==" Return-path: Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by gabe.freedesktop.org (Postfix) with ESMTP id 2091D6E4FC for ; Tue, 3 Feb 2015 05:30:21 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id bj1so96418539pad.1 for ; Tue, 03 Feb 2015 05:30:20 -0800 (PST) In-Reply-To: <1418319166-23357-1-git-send-email-p.zabel@pengutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Philipp Zabel Cc: kernel@pengutronix.de, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0817960384== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="poemUeGtc2GQvHuH" Content-Disposition: inline --poemUeGtc2GQvHuH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. T= hese > can be stored in a struct display_timing, to be used by an encoder mode_f= ixup > callback to clamp user provided timing values or to validate workarounds = for > clock source limitations. >=20 > This patch adds a new drm_panel_funcs callback that returns the panels' > available display_timing entries. >=20 > Signed-off-by: Philipp Zabel > --- > 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? >=20 > 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; > =20 > /** > * 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 contro= ller > * 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 --poemUeGtc2GQvHuH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0M1mAAoJEN0jrNd/PrOhxJAQAIMd7J7+nGdQEcfKp4MOGFYr 8AoGqLGZsXh5s4xpQHSh3NvFeMpObrCvPJBJjr8BGug4Jkg0IseWF8SfNfyW2ec0 B5ThfLUL+71vhB18onWupHqgCMvrXb3xtQUL84WFLRl49rp3Fwl7ssA9tuocnwMW nrnKiAUMr4uMicox0sFR8GPSaJ/HC3jTEBri/KSJJldqFe5b/xuQmo3S0e9P8MkV uXj+MTTmi1IGwviDMXHeK5m6Oq9lKd7FwhOftUBEK1IxwXuZVaxE8YX2YNwXXSs2 A31ArklJCS7I7WHBIxta7oNs0R5Q0UxEGoTdKN/Ty0ocYkwAz9ox2Khdik0DFhit hIX94ImId+fTkVeShZvczffoZgFwEB7T5JilRo1/d+PxIWufIGl7FkTtvZ1VvUBm p4n2s7h2NH7qvNEztGFtlfj7QNRJAdcU1Z8MBFN3WXcRYE8CHpgY75jxCQH+J7Xs qmB/F6WmMmPMHFix3cvv7qU8BZCKbOP2gb4TbB/rUl+rcAfUuJbx/GIgU0domgVg AU7WhB4ZiRt8GBCJaaQpbE1yiNkV61+OK2bf01W06QoYWccywnkIEWx4z/4bBxdL nJiMj8VrJ5IpjeA/KgKlcPZZeEseRfoAUE3xFss7brvyIJQrZDaiUZSawOz4bFaM 2EkMLMesGNgRJNxs+sgz =hIMN -----END PGP SIGNATURE----- --poemUeGtc2GQvHuH-- --===============0817960384== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0817960384==--