From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Tomi Valkeinen <tomi.valkeinen@ti.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>, 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 0/5] Generic panel framework Date: Tue, 21 Aug 2012 11:23:34 +0200 [thread overview] Message-ID: <3648908.jA5PYymWxV@avalon> (raw) In-Reply-To: <1345528197.15491.8.camel@lappyti> Hi Tomi, On Tuesday 21 August 2012 08:49:57 Tomi Valkeinen wrote: > On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote: > > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > > > Hi Tomi, > > > > > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it > > > > can be used for non-panel devices (at least in theory). The future > > > > mipi-dsi-bus certainly will. > > > > > > They are both display busses. So while they could be used for anything, > > > I find it quite unlikely as there are much better alternatives for > > > generic bus needs. > > > > My point is that they could be used for display devices other than panels. > > This is especially true for DSI, as there are DSI to HDMI converters. > > Technically speaking that's also true for DBI, as DBI chips convert from > > DBI to DPI, but we can group both the DBI-to-DPI chip and the panel in a > > single panel object. > > Ah, ok. I thought "panels" would include these buffer/converter chips. > > I think we should have one driver for one indivisible hardware entity. > So if you've got a panel module that contains DBI receiver, buffer > memory and a DPI panel, let's just have one "DBI panel" driver for it. > > If we get lots of different panel modules containing the same DBI RX IP, > we could have the DBI IP part as a common library, but still have one > panel driver per panel module. Sounds good to me. > But how do you see the case for separate converter/buffer chips? Are > they part of the generic panel framework? I guess they kinda have to be. > On one side they use the "panel" API control the bus they are connected > to, and on the other they offer an API for the connected panel to use > the bus they provide. The DBI/DSI APIs will not be panel-specific (they won't contain any reference to "panel") I'm thus thinking of moving them from drivers/video/panel/ to drivers/video/. Furthermore, a DSI-to-HDMI converter chip is not a panel, but needs to expose display-related operations in a way similar to panels. I was thus wondering if we shouldn't replace the panel structure with some kind of video entity structure that would expose operations similar to panels. We could then extend that structure with converter-specific operations later. The framework would become a bit more generic, while remaining display-specific. > Did you just mean we should have a separate directory for them, while > still part of the same framework, or...? -- Regards, Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Tomi Valkeinen <tomi.valkeinen@ti.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>, 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 0/5] Generic panel framework Date: Tue, 21 Aug 2012 09:23:34 +0000 [thread overview] Message-ID: <3648908.jA5PYymWxV@avalon> (raw) In-Reply-To: <1345528197.15491.8.camel@lappyti> Hi Tomi, On Tuesday 21 August 2012 08:49:57 Tomi Valkeinen wrote: > On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote: > > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > > > Hi Tomi, > > > > > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it > > > > can be used for non-panel devices (at least in theory). The future > > > > mipi-dsi-bus certainly will. > > > > > > They are both display busses. So while they could be used for anything, > > > I find it quite unlikely as there are much better alternatives for > > > generic bus needs. > > > > My point is that they could be used for display devices other than panels. > > This is especially true for DSI, as there are DSI to HDMI converters. > > Technically speaking that's also true for DBI, as DBI chips convert from > > DBI to DPI, but we can group both the DBI-to-DPI chip and the panel in a > > single panel object. > > Ah, ok. I thought "panels" would include these buffer/converter chips. > > I think we should have one driver for one indivisible hardware entity. > So if you've got a panel module that contains DBI receiver, buffer > memory and a DPI panel, let's just have one "DBI panel" driver for it. > > If we get lots of different panel modules containing the same DBI RX IP, > we could have the DBI IP part as a common library, but still have one > panel driver per panel module. Sounds good to me. > But how do you see the case for separate converter/buffer chips? Are > they part of the generic panel framework? I guess they kinda have to be. > On one side they use the "panel" API control the bus they are connected > to, and on the other they offer an API for the connected panel to use > the bus they provide. The DBI/DSI APIs will not be panel-specific (they won't contain any reference to "panel") I'm thus thinking of moving them from drivers/video/panel/ to drivers/video/. Furthermore, a DSI-to-HDMI converter chip is not a panel, but needs to expose display-related operations in a way similar to panels. I was thus wondering if we shouldn't replace the panel structure with some kind of video entity structure that would expose operations similar to panels. We could then extend that structure with converter-specific operations later. The framework would become a bit more generic, while remaining display-specific. > Did you just mean we should have a separate directory for them, while > still part of the same framework, or...? -- Regards, Laurent Pinchart
next prev parent reply other threads:[~2012-08-21 9:23 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 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 [this message] 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=3648908.jA5PYymWxV@avalon \ --to=laurent.pinchart@ideasonboard.com \ --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=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.