From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support Date: Fri, 6 Sep 2013 18:43:57 +0300 Message-ID: <5229F83D.1010400@ti.com> References: <1376068510-30363-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> <1376068510-30363-9-git-send-email-laurent.pinchart+renesas@ideasonboard.com> <521B37BA.50706@ti.com> <9919519.TaAubJ8jzD@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1749351972==" Return-path: Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by gabe.freedesktop.org (Postfix) with ESMTP id ACFE5E5C28 for ; Fri, 6 Sep 2013 08:44:27 -0700 (PDT) In-Reply-To: <9919519.TaAubJ8jzD@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, dri-devel@lists.freedesktop.org, Jesse Barnes , Benjamin Gaignard , Laurent Pinchart , Tom Gall , Kyungmin Park , linux-media@vger.kernel.org, Stephen Warren , Mark Zhang , Alexandre Courbot , Ragesh Radhakrishnan , Thomas Petazzoni , Sunil Joshi , Maxime Ripard , Vikas Sajjan , Marcus Lorentzon List-Id: dri-devel@lists.freedesktop.org --===============1749351972== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RLwIDxacTXOoOUDbUi9BrOORV0BSJ8bGi" --RLwIDxacTXOoOUDbUi9BrOORV0BSJ8bGi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/09/13 17:09, Laurent Pinchart wrote: > Hi Tomi, >=20 > On Monday 26 August 2013 14:10:50 Tomi Valkeinen wrote: >> On 09/08/13 20:14, Laurent Pinchart wrote: >>> MIPI DBI is a configurable-width parallel display bus that transmits >>> commands and data. >>> >>> Add a new DBI Linux bus type that implements the usual bus >>> infrastructure (including devices and drivers (un)registration and >>> matching, and bus configuration and access functions). >> >> This has been discussed before, but I don't remember that the issue wo= uld >> have been cleared, so I'm bringing it up again. >> >> What benefit does a real Linux DBI (or DSI) bus give us, compared to >> representing the DBI the same way as DPI? DBI & DSI are in practice po= int- >> to-point buses, and they do not support probing. Is it just that becau= se DBI >> and DSI can be used to control a device, they have to be Linux buses? >=20 > The idea was to reuse the Linux bus infrastructure to benefit from feat= ures=20 > such as power management. Implementing DBI/DSI control functions using = a=20 > DBI/DSI bus is also pretty easy, and would allow controlling DBI/DSI en= tities=20 > much like we control I2C entities. I don't like the idea of using an I2= C bus=20 > with I2C access functions on one side, and embedding the DBI/DSI access= =20 > functions as part of CDF entity operations on the other side very much.= While I somewhat like the thought of having DBI and DSI as Linux buses, I just don't see how it would work. Well, I'm mostly thinking about DSI here, I have not used DBI for years. Also, I might remember wrong, but I think I saw Linus expressing his opinion at some point that he doesn't really like the idea of having a Linux bus for simple point-to-point buses, which don't have probing support, and so there isn't much "bus" to speak of, just a point to point link. And I think we get the same power management with just having a device as a child device of another. > This being said, this isn't the part of CDF that matters the most to me= (it's=20 > actually not part of CDF strictly speaking). If your model works well e= nough=20 > it won't be too hard to convince me :-) >=20 >> How do you see handling the devices where DBI or DSI is used for video= only, >> and the control is handled via, say, i2c? The module has to register t= wo >> drivers, and try to keep those in sync? I feel that could get rather h= acky. >=20 > If DBI or DSI is used for video only you don't need DBI/DSI control=20 > operations, right ? So the entity driver will just be a regular I2C dev= ice=20 > driver. Well, DSI can't be used just like that. You need to configure it. The thing is, DSI is used for both control and video. They are really the same thing, both are sent as DSI packets. Both need similar kind of configuration for the bus. If the DSI peripheral sits on a DSI bus, I imagine this configuration is done via the DSI bus support. But if there's no DSI bus, how is the configuration done? I guess a possibility is to have a fixed configuration that cannot be changed dynamically. But I have a feeling that it'll be a bit limiting for some cases. And even with fixed configuration, I think the configuration would somehow be passed as DSI bus parameters from the board files or in the DT data (the same way as, say i2c bus speed). If there's no DSI bus, as the DSI peripheral sits on the i2c bus, where are the parameters? Tomi --RLwIDxacTXOoOUDbUi9BrOORV0BSJ8bGi 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.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKfhBAAoJEPo9qoy8lh7167EP/1rlyktV9FVNVv4Znd9B7l61 XEsoJuc77w3hypP9qqOKpj5sRft1bO+MhmriFlInMPhX+FL9CjN8f73HfLzQXZlT w/HhBb1gv++M7QXocy1G86FgvU9hnzHpbvTw9rtZlTVZfBHBcMnwPTWv6ETUzcZ3 WZkYDkdmcpZfMKwR9letB2BpAM/WhhQsFSwE8sqDTPUB4a1iAO/CY/HEjPCB8e8k iohnAyN5PT2i8bgDO60QqeD3kMYm66aJZQwoa7X4wWWphOK4F9H8Vhv4LmfDubzJ qWyshBKtte/SG9erMYROBw4RDwPSF84MnPPby62IHQ9DzKHywm8HjyOc3rZ8Ic2Y +gkZqEHHATKjvMJk0AP6MrrDhOaYd/PT1NED2PKOO5GbQ9jL35nCAKr0tPeBQyV2 82yqWlbR8R5EuLucprHCZEdm358cXNaIwdLlLSJC8z8Lqo5InT4hS9pt1H/Z91kj 69I6FKBMZJb0gtTCnuP/+GAb6r9mveWHtne6ec0hHBOxsYoCh0F2282WuMCEOh2j 4LoyzaYKMJtQ59td8OQhmzZz3mco5/Z0vcxkLd4tmAV26ocPpS7clCdRtwdqFNX0 NaprDvIV/RHjCgCYM/fgS/9yZQCkQ6jUb6Oj1xggwbHvM6uFbZIBZWmPwRDuTo5Z RcP9SgHqYuaq0aWwqp8D =QQEX -----END PGP SIGNATURE----- --RLwIDxacTXOoOUDbUi9BrOORV0BSJ8bGi-- --===============1749351972== 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 --===============1749351972==--