From: Sascha Hauer <s.hauer@pengutronix.de> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org, linux-media@vger.kernel.org, Bryan Wu <bryan.wu@canonical.com>, Richard Purdie <rpurdie@rpsys.net>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Marcus Lorentzon <marcus.lorentzon@linaro.org>, Sumit Semwal <sumit.semwal@ti.com>, Archit Taneja <archit@ti.com>, Sebastien Guiriec <s-guiriec@ti.com>, Inki Dae <inki.dae@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com> Subject: Re: [RFC 1/5] video: Add generic display panel core Date: Thu, 13 Sep 2012 13:29:54 +0200 [thread overview] Message-ID: <20120913112954.GI6180@pengutronix.de> (raw) In-Reply-To: <224585745.5E32B1Gv1v@avalon> On Thu, Sep 13, 2012 at 03:40:40AM +0200, Laurent Pinchart wrote: > Hi Sascha, > > > > +int panel_get_modes(struct panel *panel, const struct fb_videomode > > > **modes) > > > +{ > > > + if (!panel->ops || !panel->ops->get_modes) > > > + return 0; > > > + > > > + return panel->ops->get_modes(panel, modes); > > > +} > > > +EXPORT_SYMBOL_GPL(panel_get_modes); > > > > You have seen my of videomode helper proposal. One result there was that > > we want to have ranges for the margin/synclen fields. Does it make sense > > to base this new panel framework on a more sophisticated internal > > reprentation of the panel parameters? > > I think it does, yes. We need a common video mode structure, and the panel > framework should use it. I'll try to rebase my patches on top of your > proposal. Have you posted the latest version ? V2 is the newest version. I'd like to implement ranges for the display timings which then makes for a new common video mode structure, which then could be used by drm and fbdev, probably with helper functions to convert from common videomode to drm/fbdev specific variants. > > > This could then be converted to struct fb_videomode / struct > > drm_display_mode as needed. This would also make it more suitable for drm > > drivers which are not interested in struct fb_videomode. > > > > Related to this I suggest to change the API to be able to iterate over > > the different modes, like: > > > > struct videomode *panel_get_mode(struct panel *panel, int num); > > > > This was we do not have to have an array of modes in memory, which may > > be a burden for some panel drivers. > > I currently have mixed feelings about this. Both approaches have pros and > cons. Iterating over the modes would be more complex for drivers that use > panels, and would be race-prone if the modes can change at runtime (OK, this > isn't supported by the current panel API proposal). I just remember that the array approach was painful when I worked on an fbdev driver some time ago. There some possible modes came from platform_data, other modes were default modes in the driver and all had to be merged into a single array. I don't remember the situation exactly, but it would have been simpler if it had been a list instead of an array. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org, linux-media@vger.kernel.org, Bryan Wu <bryan.wu@canonical.com>, Richard Purdie <rpurdie@rpsys.net>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Marcus Lorentzon <marcus.lorentzon@linaro.org>, Sumit Semwal <sumit.semwal@ti.com>, Archit Taneja <archit@ti.com>, Sebastien Guiriec <s-guiriec@ti.com>, Inki Dae <inki.dae@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com> Subject: Re: [RFC 1/5] video: Add generic display panel core Date: Thu, 13 Sep 2012 11:29:54 +0000 [thread overview] Message-ID: <20120913112954.GI6180@pengutronix.de> (raw) In-Reply-To: <224585745.5E32B1Gv1v@avalon> On Thu, Sep 13, 2012 at 03:40:40AM +0200, Laurent Pinchart wrote: > Hi Sascha, > > > > +int panel_get_modes(struct panel *panel, const struct fb_videomode > > > **modes) > > > +{ > > > + if (!panel->ops || !panel->ops->get_modes) > > > + return 0; > > > + > > > + return panel->ops->get_modes(panel, modes); > > > +} > > > +EXPORT_SYMBOL_GPL(panel_get_modes); > > > > You have seen my of videomode helper proposal. One result there was that > > we want to have ranges for the margin/synclen fields. Does it make sense > > to base this new panel framework on a more sophisticated internal > > reprentation of the panel parameters? > > I think it does, yes. We need a common video mode structure, and the panel > framework should use it. I'll try to rebase my patches on top of your > proposal. Have you posted the latest version ? V2 is the newest version. I'd like to implement ranges for the display timings which then makes for a new common video mode structure, which then could be used by drm and fbdev, probably with helper functions to convert from common videomode to drm/fbdev specific variants. > > > This could then be converted to struct fb_videomode / struct > > drm_display_mode as needed. This would also make it more suitable for drm > > drivers which are not interested in struct fb_videomode. > > > > Related to this I suggest to change the API to be able to iterate over > > the different modes, like: > > > > struct videomode *panel_get_mode(struct panel *panel, int num); > > > > This was we do not have to have an array of modes in memory, which may > > be a burden for some panel drivers. > > I currently have mixed feelings about this. Both approaches have pros and > cons. Iterating over the modes would be more complex for drivers that use > panels, and would be race-prone if the modes can change at runtime (OK, this > isn't supported by the current panel API proposal). I just remember that the array approach was painful when I worked on an fbdev driver some time ago. There some possible modes came from platform_data, other modes were default modes in the driver and all had to be merged into a single array. I don't remember the situation exactly, but it would have been simpler if it had been a list instead of an array. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2012-09-13 11:30 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-17 0:49 [RFC 0/5] Generic panel framework Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 1/5] video: Add generic display panel core Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-09-04 9:24 ` Sascha Hauer 2012-09-04 9:24 ` Sascha Hauer 2012-09-13 1:40 ` Laurent Pinchart 2012-09-13 1:40 ` Laurent Pinchart 2012-09-13 11:29 ` Sascha Hauer [this message] 2012-09-13 11:29 ` Sascha Hauer 2012-09-13 19:32 ` Robert Schwebel 2012-09-13 19:32 ` Robert Schwebel 2012-08-17 0:49 ` [RFC 2/5] video: panel: Add dummy panel support Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 3/5] video: panel: Add MIPI DBI bus support Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 9:03 ` Tomi Valkeinen 2012-08-17 9:03 ` Tomi Valkeinen 2012-08-17 10:02 ` Laurent Pinchart 2012-08-17 10:02 ` Laurent Pinchart 2012-08-17 10:51 ` Tomi Valkeinen 2012-08-17 10:51 ` Tomi Valkeinen 2012-08-17 12:33 ` Laurent Pinchart 2012-08-17 12:33 ` Laurent Pinchart 2012-08-17 13:06 ` Tomi Valkeinen 2012-08-17 13:06 ` Tomi Valkeinen 2012-08-17 14:06 ` Laurent Pinchart 2012-08-17 14:06 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 4/5] video: panel: Add R61505 panel support Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 0:49 ` [RFC 5/5] video: panel: Add R61517 " Laurent Pinchart 2012-08-17 0:49 ` Laurent Pinchart 2012-08-17 1:33 ` [RFC 0/5] Generic panel framework Jingoo Han 2012-08-17 1:33 ` Jingoo Han 2012-08-17 8:38 ` Tomi Valkeinen 2012-08-17 8:38 ` Tomi Valkeinen 2012-08-17 11:10 ` Laurent Pinchart 2012-08-17 11:10 ` Laurent Pinchart 2012-08-17 11:42 ` Tomi Valkeinen 2012-08-17 11:42 ` Tomi Valkeinen 2012-08-18 1:16 ` Laurent Pinchart 2012-08-18 1:16 ` Laurent Pinchart 2012-08-18 1:16 ` Laurent Pinchart 2012-08-20 11:39 ` Tomi Valkeinen 2012-08-20 11:39 ` Tomi Valkeinen 2012-08-20 23:29 ` Laurent Pinchart 2012-08-20 23:29 ` Laurent Pinchart 2012-08-20 23:29 ` Laurent Pinchart 2012-08-21 5:49 ` Tomi Valkeinen 2012-08-21 5:49 ` Tomi Valkeinen 2012-08-21 9:23 ` Laurent Pinchart 2012-08-21 9:23 ` Laurent Pinchart 2012-08-23 6:23 ` Jun Nie 2012-08-23 6:23 ` Jun Nie 2012-09-04 8:20 ` Zhou Zhu 2012-09-04 8:20 ` Zhou Zhu 2012-10-30 16:35 ` Laurent Pinchart 2012-10-30 16:35 ` Laurent Pinchart 2012-10-30 16:23 ` Laurent Pinchart 2012-10-30 16:23 ` Laurent Pinchart 2012-10-20 14:18 ` Inki Dae 2012-10-20 14:18 ` Inki Dae 2012-09-19 11:45 ` Tomi Valkeinen 2012-09-19 11:45 ` Tomi Valkeinen 2012-10-31 13:13 ` Laurent Pinchart 2012-10-31 13:13 ` Laurent Pinchart 2012-10-31 14:20 ` Tomi Valkeinen 2012-10-31 14:20 ` Tomi Valkeinen 2012-10-31 14:20 ` Tomi Valkeinen 2012-10-20 13:10 ` Inki Dae 2012-10-20 13:10 ` Inki Dae 2012-10-20 14:22 ` Inki Dae 2012-10-20 14:22 ` Inki Dae 2012-10-31 13:28 ` Laurent Pinchart 2012-10-31 13:28 ` Laurent Pinchart
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=20120913112954.GI6180@pengutronix.de \ --to=s.hauer@pengutronix.de \ --cc=archit@ti.com \ --cc=bryan.wu@canonical.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=inki.dae@samsung.com \ --cc=kyungmin.park@samsung.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-leds@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=marcus.lorentzon@linaro.org \ --cc=rpurdie@rpsys.net \ --cc=s-guiriec@ti.com \ --cc=sumit.semwal@ti.com \ --cc=tomi.valkeinen@ti.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: linkBe 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.