From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: CDF meeting @FOSDEM report Date: Wed, 6 Feb 2013 13:11:27 +0200 Message-ID: <51123A5F.9050604@ti.com> References: <1990856.qS9uisuiVF@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0424666259==" Return-path: Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by gabe.freedesktop.org (Postfix) with ESMTP id C80D6E5CB8 for ; Wed, 6 Feb 2013 03:17:08 -0800 (PST) In-Reply-To: <1990856.qS9uisuiVF@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Laurent Pinchart Cc: linux-fbdev@vger.kernel.org, Sebastien Guiriec , dri-devel@lists.freedesktop.org, Jesse Barnes , Benjamin Gaignard , Sumit Semwal , Tom Gall , Kyungmin Park , linux-media@vger.kernel.org, Stephen Warren , Thierry Reding , Mark Zhang , linaro-mm-sig@lists.linaro.org, =?ISO-8859-1?Q?St=E9phane_Marc?= =?ISO-8859-1?Q?hesin?= , Alexandre Courbot , Ragesh Radhakrishnan , Thomas Petazzoni , Sunil Joshi , Maxime Ripard , Vikas Sajjan List-Id: dri-devel@lists.freedesktop.org --===============0424666259== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4AD98CA9679BB4E45ABADAA4" --------------enig4AD98CA9679BB4E45ABADAA4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 2013-02-06 00:27, Laurent Pinchart wrote: > Hello, >=20 > We've hosted a CDF meeting at the FOSDEM on Sunday morning. Here's a su= mmary=20 > of the discussions. Thanks for the summary. I've been on a longish leave, and just got back, so I haven't read the recent CDF discussions on lists yet. I thought I'll start by replying to this summary first =3D). > 0. Abbreviations > ---------------- >=20 > DBI - Display Bus Interface, a parallel video control and data bus that= =20 > transmits data using parallel data, read/write, chip select and address= =20 > signals, similarly to 8051-style microcontroller parallel busses. This = is a=20 > mixed video control and data bus. >=20 > DPI - Display Pixel Interface, a parallel video data bus that transmits= data=20 > using parallel data, h/v sync and clock signals. This is a video data b= us=20 > only. >=20 > DSI - Display Serial Interface, a serial video control and data bus tha= t=20 > transmits data using one or more differential serial lines. This is a m= ixed=20 > video control and data bus. In case you'll re-use these abbrevs in later posts, I think it would be good to mention that DPI is a one-way bus, whereas DBI and DSI are two-way (perhaps that's implicit with control bus, though). > 1. Goals > -------- >=20 > The meeting started with a brief discussion about the CDF goals. >=20 > Tomi Valkeinin and Tomasz Figa have sent RFC patches to show their view= s of=20 > what CDF could/should be. Many others have provided very valuable feedb= ack.=20 > Given the early development stage propositions were sometimes contradic= tory,=20 > and focused on different areas of interest. We have thus started the me= eting=20 > with a discussion about what CDF should try to achieve, and what it sho= uldn't. >=20 > CDF has two main purposes. The original goal was to support display pan= els in=20 > a platform- and subsystem-independent way. While mostly useful for embe= dded=20 > systems, the emergence of platforms such as Intel Medfield and ARM-base= d PCs=20 > that blends the embedded and PC worlds makes panel support useful for t= he PC=20 > world as well.=20 >=20 > The second purpose is to provide a cross-subsystem interface to support= video=20 > encoders. The idea originally came from a generalisation of the origina= l RFC=20 > that supported panels only. While encoder support is considered as lowe= r=20 > priority than display panel support by developers focussed on display=20 > controller driver (Intel, Renesas, ST Ericsson, TI), companies that pro= duce=20 > video encoders (Analog Devices, and likely others) don't share that poi= nt of=20 > view and would like to provide a single encoder driver that can be used= in=20 > both KMS and V4L2 drivers. What is an encoder? Something that takes a video signal in, and lets the CPU store the received data to memory? Isn't that a decoder? Or do you mean something that takes a video signal in, and outputs a video signal in another format? (transcoder?) If the latter, I don't see them as lower priority. If we use CDF also for SoC internal components (which I think would be great), then every OMAP board has transcoders. I'm not sure about the vocabulary on this area, but a normal OMAP scenario could have a following video pipeline: 1. encoder (OMAP's DISPC, reads pixels from memory and outputs parallel R= GB) 2. transcoder (OMAP's DSI, gets parallel RGB and outputs DSI) 3. transcoder (external DSI-to-LVDS chip) 4. panel (LVDS panel) Even in the case where a panel would be connected directly to the OMAP, there would be the internal transcoder. > 2. Subsystems > ------------- >=20 > Display panels are used in conjunction with FBDEV and KMS drivers. Ther= e was=20 > to the audience knowledge no V4L2 driver that needs to explicitly handl= e=20 > display panels. Even though at least one V4L2 output drivers (omap_vout= ) can=20 > output video to a display panel, it does so in conjunction with the KMS= and/or=20 > FBDEV APIs that handle panel configuration. Panels are thus not exposed= to=20 > V4L2 drivers. Hmm, I'm no expert on omap_vout, but it doesn't use KMS nor omapfb. It uses omapdss directly, and thus accesses the panels. That said, I'm fine with leaving omap_vout out from the equation. > 3. KMS Extensions > ----------------- >=20 > The usefulness of V4L2 for output devices was questioned, and the possi= bility=20 > of using KMS for complex video devices usually associated with V4L2 was= =20 > raised. The TI DaVinci 8xxx family is an example of chips that could be= nefit=20 > from KMS support. >=20 > The KMS API is lacking support for deep-pipelining ("framebuffers" that= are=20 > sourced from a data stream instead of a memory buffer) today. Extending= the=20 > KMS API with deep-pipelining support was considered as a sensible goal = that=20 > would mostly require the creation of a new KMS source object. Exposing = the=20 > topology of the whole device would then be handled by the Media Control= ler=20 > API. Isn't there also the problem that KSM doesn't support arbitrarily long chains of display devices? That actually sounds more like "deep-pipelining" than what you said, getting the source data from a data stream. > 5. Bus Model > ------------ >=20 > Display panels are connected to a video bus that transmits video data a= nd=20 > optionally to a control bus. Those two busses can be separate physical = > interfaces or combined into a single physical interface. >=20 > The Linux device model represents the system as a tree of devices (not = to be=20 > confused by the device tree, abreviated as DT). The tree is organized a= round=20 > control busses, with every device being a child of its control bus mast= er. For=20 > instance an I2C device will be a child of its I2C controller device, wh= ich can=20 > itself be a child of its parent PCI device. >=20 > Display panels will be represented as Linux devices. They will have a s= ingle=20 > parent from the Linux device model point of view, but will be potential= ly=20 > connected to multiple physical busses. CDF thus needs to define what bu= s to=20 > select as the Linux parent bus. >=20 > In theory any physical bus that the device is attached to can be select= ed as=20 > the parent bus. However, selecting a video data bus would depart from t= he=20 > traditional Linux device model that uses control busses only. This caus= ed=20 > concern among several people who argued that not presenting the device = to the=20 > kernel as attached to its control bus would bring issues in embedded sy= stem.=20 > Unlike on PC systems where the control bus master is usually the same p= hysical=20 > device as the data bus master, embedded systems are made of a potential= ly=20 > complex assembly of completely unrelated devices. Not representing an I= 2C- > controlled panel as a child of its I2C master in DT was thus frown upon= , even=20 > though no clear agreement was reached on the subject. I've been thinking that a good rule of thumb would be that the device must be somewhat usable after the parent bus is ready. So for, say, DPI+SPI panel, when the SPI is set up the driver can send messages to the panel, perhaps read an ID or such, even if the actual video cannot be shown yet (presuming DPI bus is still missing). Of course there are the funny cases, as always. Say, a DSI panel, controlled via i2c, and the panel gets its functional clock from the DSI bus's clock. In that case both busses need to be up and running before the panel can do anything. > - Combined video and control busses >=20 > When the two busses are combined in a single physical bus the panel dev= ice=20 > will obviously be represented as a child of that single physical bus.=20 >=20 > In such cases the control bus could expose video bus control methods. T= his=20 > would remove the need for a video source as proposed by Tomi Valkeinen = in his=20 > CDF model. However, if the bus can be used for video data transfer in=20 > combination with a different control bus, a video source corresponding = to the=20 > data bus will be needed. I think this is always the case. If a bus can be used for control and video data, you can always use it only for video data. > No decision has been taken on whether to use a video source in addition= to the=20 > control bus in the combined busses case. Experimentation will be needed= , and=20 > the right solution might depend on the bus type. >=20 > - Multiple control busses >=20 > One panel was mentioned as being connected to a DSI bus and an I2C bus.= The=20 > DSI bus is used for both control and video, and the I2C bus for control= only.=20 > configuring the panel requires sending commands through both DSI and I2= C. The=20 I have luckily not encountered such a device. However, many of the DSI devices do have i2c control as an option. From the device's point of view, both can be used at the same time, but I think usually it's saner to just pick one and use it. The driver for the device should support both control busses, though. Probably 99% of the driver code is common for both cases. > 6. Miscellaneous > ---------------- >=20 > - If the OMAP3 DSS driver is used as a model for the DSI support=20 > implementation, Daniel Vetter requested the DSI bus lock semaphore to b= e=20 > killed as it prevents lockdep from working correctly (reference needed = ;-)). I don't think OMAP DSS should be used as a model. It has too much legacy crap that should be rewritten. However, it can be used as a reference to see what kind of features are needed, as it does support both video and command mode DSI modes, and has been used with many different kinds of DSI panels and DSI transcoders. As for the semaphore, sure, it can be removed, although I'm not aware of this lockdep problem. If there's a problem it should be fixed in any case= =2E > - Do we need to support chaining several encoders ? We can come up with= =20 > several theoretical use cases, some of them probably exist in real hard= ware,=20 > but the details are still a bit fuzzy. If encoder means the same as the "transcoder" term I used earlier, then yes, I think so. As I wrote, I'd like to model the OMAP DSS internal components with CDF. The internal IP blocks are in no way different than external IP blocks, they just happen to be integrated into OMAP. The same display IPs are used with multiple different TI SoCs. Also, the IPs vary between TI SoCs (for ex, omap2 doesn't have DSI, omap3 has one DSI, omap4 has two DSIs), so we'll anyway need to have some kind of dynamic system inside omapdss driver. If I can't use CDF for that, I'll need to implement a custom one, which I believe would resemble CDF in many ways. I'm guessing that having multiple external transcoders is quite rare on production hardware, but is a very useful feature with development boards. It's not just once or twice that we've used a transcoder or two between a SoC and a panel, because we haven't had the final panel yet. Also, sometimes there are small simple chips in the video pipeline, that do things like level shifting or ESD protection. In some cases these chips just work automatically, but in some cases one needs to setup regulators and gpios to get them up and running (for example, http://www.ti.com/product/tpd12s015). And if that's the case, then I believe having a CDF "transcoder" driver for the chip is the easiest solution. Tomi --------------enig4AD98CA9679BB4E45ABADAA4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJREjpfAAoJEPo9qoy8lh71hfIP/jmDoiC7mMI6ZMZgYrEPgv1k oodiV1+7/21ZWbzUlk9MwZzE13NPIamMyg0wmEo01NvF6GRzpN/9FNZm+5cXqm+a aTzcV3Kbsw62FnpLbvnkGu1/qnY2c/coK4F8czqbavv44P/UOMZXDmZuXpc16c60 JJXkIfbqT/F2ESRNygLKQuuZDeFrpWx48ikqJtraasv6Q91h4IqQua6dozaE0tQw wluXDXZWF3ivDH72ELW1Jkab1nnwTLekiNOd8RDee9/vGte4wlLikIBtBgQ0bC1B DJnu5PNBNBkoJtOeyJT66KPGHNKPB07ueJrfiAmAXqJBTR9f87KiY13o+DbWmoxJ kL78fDVfAzy7PXnPuDGANECs/BTRs9o5AbWqGIGPe12KJcFiyciszL9W0DwANpIv N83Uz5rvxTyNPNAyvlDBmbRjSA3w8Nc4SjsHy5waGQGsZDXO8mskXzUpvALuRste 6Lmi7Y9AP1nv+qMuz+qlLOOHiM4FZX6OcgYBIkqGeH3wPwoq1WcTSpAwXDBeaNmf 8tE8RVEVNvq3nRP+Qp+4B5z5Yfjc7elEEegeKOonEmg6xAGIOj96slBt+ZNgAuzI ZnqYlS98bMo8uE0XKzA5SicAnbUcQEYCyuweYzbOE1tfagS1S4EeM3mGbKKu7bSD RsbsC+RBL2U5Yp4MiTIN =/Fh6 -----END PGP SIGNATURE----- --------------enig4AD98CA9679BB4E45ABADAA4-- --===============0424666259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0424666259==--