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: Sat, 7 Sep 2013 12:35:36 +0300 Message-ID: <522AF368.7040806@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> <5229F83D.1010400@ti.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0374225304==" Return-path: Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by gabe.freedesktop.org (Postfix) with ESMTP id 3F84EE6341 for ; Sat, 7 Sep 2013 02:36:02 -0700 (PDT) In-Reply-To: <5229F83D.1010400@ti.com> 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 --===============0374225304== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1gqBD1qtd6OFTV7dQSTO52NXKFnigstCi" --1gqBD1qtd6OFTV7dQSTO52NXKFnigstCi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/09/13 18:43, Tomi Valkeinen wrote: > On 06/09/13 17:09, Laurent Pinchart wrote: >> Hi Tomi, >> >> 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 w= ould >>> 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 p= oint- >>> to-point buses, and they do not support probing. Is it just that beca= use DBI >>> and DSI can be used to control a device, they have to be Linux buses?= >> >> The idea was to reuse the Linux bus infrastructure to benefit from fea= tures=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 e= ntities=20 >> much like we control I2C entities. I don't like the idea of using an I= 2C bus=20 >> with I2C access functions on one side, and embedding the DBI/DSI acces= s=20 >> functions as part of CDF entity operations on the other side very much= =2E >=20 > 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. >=20 > 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. >=20 > And I think we get the same power management with just having a device > as a child device of another. >=20 >> This being said, this isn't the part of CDF that matters the most to m= e (it's=20 >> actually not part of CDF strictly speaking). If your model works well = enough=20 >> it won't be too hard to convince me :-) >> >>> How do you see handling the devices where DBI or DSI is used for vide= o only, >>> and the control is handled via, say, i2c? The module has to register = two >>> drivers, and try to keep those in sync? I feel that could get rather = hacky. >> >> 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 de= vice=20 >> driver. >=20 > Well, DSI can't be used just like that. You need to configure it. >=20 > 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? >=20 > 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. >=20 > 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? Continuing my thoughts on the bus issue, I think there's a fundamental difference between "real" buses like i2c and DSI/DBI: i2c peripherals are designed with the mind set that there are other peripherals on the bus, whereas DSI/DBI peripherals are known to be alone, and the DSI/DBI peripheral may thus require the bus parameters to be changed according to the whims of the peripheral. Some examples coming to my mind from the hardware I know are the need to change the DBI bus width depending on what is being sent, changing the DSI bus clock speed, changing DSI return packet size. It's ok for the DBI/DSI peripheral HW designers to require things like that, because the spec doesn't say those can't be done, and the peripheral is alone on the bus. We can support those kinds of operations both with the bus model you have, and my no-bus model. But with your bus model, I believe at least some of those operations may be needed even when the peripheral is controlled via i2c/spi. This also is related to the control model. I'm not sure of the details of the pipeline controller, but I fear that having the controller be the entity that knows about the strange needs of individual video peripherals will lead to lots of customized controllers for individual boards. That said, I agree that it's difficult to embed all the information into individual device drivers (although that's where it should be), because sometimes a wider view of the pipeline is needed to properly configure things. Tomi --1gqBD1qtd6OFTV7dQSTO52NXKFnigstCi 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/ iQIcBAEBAgAGBQJSKvNsAAoJEPo9qoy8lh71htcP+wXn3qlUCL2+LPZyQWl9CaI9 lSy2qC/h1h1ELgo8wivoakaoQfXcavZxIkq/cq2iPgZ65drL6D++CO/suGamzKR8 3+MxaY3Y3B84GOdvtUF4DJDVvtlA9rQBnOK7KTy3F32RuY+eEpGQp1dRp9YFCM7m fDmRMAenVRI03NmDWxfsQ1qFBOs7JzqQKzwQEEv/Z4d5Uuf5rsNsGf9x2ApMN83L fJfKvr9zXnWSD2xouUU6bb+M7lYDMF2J6vujLFl/5NWOM3nScb8jdgk8FiksL/fr DkReBIcNcjCr17VJrSWNqLCbBYf0Bglap2vU0NHUxz54y/e9N8rJWhCAogD7IEkL dDryPhLzmZQHx+9YADArnSMkBNsYKPwEQsHh3b4H3nq9J9nzAL9TrZWRUU3MKpsJ flO7fKkfYae55NvWFf1HKVnB4wSfwabtsMyaUmfeM08+h4hnEgm5iZXTxhuqARhW ogYTHWbxbdKP0f9+O/H8ifIA6myNxgd8jqq7afRqayYjTseNAAjso7D5/4Ak1aCT qvZALEZjrbnJFg0JGjz1LHziLX+uoshBAmFy3fOM4exr//gfIRBPZeqX9ueQ+9PN ZT41CeyFwUXEFE5DzGo0DmyHhf3/n3W0VHhLI+x5U3kM42BCgSyrS6VNVo0KAXWC 8W7EXt1xcOBCo6uNwydK =rxG6 -----END PGP SIGNATURE----- --1gqBD1qtd6OFTV7dQSTO52NXKFnigstCi-- --===============0374225304== 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 --===============0374225304==--