From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: CDF meeting @FOSDEM report Date: Wed, 6 Feb 2013 14:54:42 +0200 Message-ID: <51125292.5000409@ti.com> References: <1990856.qS9uisuiVF@avalon> <51123A5F.9050604@ti.com> <876225prq7.fsf@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1029486961==" Return-path: Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by gabe.freedesktop.org (Postfix) with ESMTP id DC935435AB for ; Wed, 6 Feb 2013 04:55:03 -0800 (PST) In-Reply-To: <876225prq7.fsf@intel.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: Jani Nikula Cc: linux-fbdev@vger.kernel.org, Sebastien Guiriec , dri-devel@lists.freedesktop.org, Jesse Barnes , Laurent Pinchart , Sumit Semwal , Tom Gall , Kyungmin Park , linux-media@vger.kernel.org, Stephen Warren , Mark Zhang , Thierry Reding , 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 --===============1029486961== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6DD7406C9503EA6AA2744577" --------------enig6DD7406C9503EA6AA2744577 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-02-06 14:11, Jani Nikula wrote: > On Wed, 06 Feb 2013, Tomi Valkeinen wrote: >>> 6. Miscellaneous >>> ---------------- >>> >>> - 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= be=20 >>> killed as it prevents lockdep from working correctly (reference neede= d ;-)). >=20 > [...] >=20 >> 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 c= ase. >=20 > The problem is that lockdep does not support semaphores out of the > box. I'm not sure how hard it would be to manually lockdep annotate the= > bus lock, and whether it would really work. In any case, as I think we > learned in the past, getting locking right in a DSI command mode panel > driver with an asynchronous update callback, DSI bus lock, and a driver= > data specific mutex can be a PITA. Lockdep would be extremely useful > there. >=20 > AFAICS simply replacing the semaphore with a mutex would work for all > other cases except DSI command mode display update, unless you're > prepared to wait in the call until the next tearing effect interrupt > plus framedone. Which would suck. I think you and I have talked about > this part in the past... Mutex requires locking and unlocking to happen from the same thread. But I guess that's what you meant that the problem would be with display update, where the framedone callback is used to release the bus lock. The semaphore could probably be changed to use wait queues, but isn't that more or less what a semaphore already does? And I want to point out to those not familiar with omapdss, that the DSI bus lock in question does not protect any data in memory, but is an indication that the DSI bus is currently in use. The bus lock can be used to wait until the bus is free again. I guess one option would be to disallow any waiting for the bus lock. If the panel driver would try acquire bus lock, and the lock is already taken, the call would fail. This would move the handling of exclusivity to the user of the panel (drm driver, I guess), which already should handle the framedone event. The above would require that everything the panel does should be managed by the drm driver. Currently this is not the case for OMAP, as the panel driver can get calls via sysfs, or via backlight driver, or via (gpio) interrupts. I don't really know what would be the best option here. On one hand requiring all panel calls to be managed by drm would be nice and simple. But it is a bit limiting when thinking about complex display chips. Will that work for all cases? I'm not sure. Tomi --------------enig6DD7406C9503EA6AA2744577 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/ iQIcBAEBAgAGBQJRElKSAAoJEPo9qoy8lh71y2EP/0hHDwpiorn4HF/oVTSoybEQ OKvD+8tfNo/PGHjU2zSgyhlRPRLuOQGG8hevGVNXa5b5ltgxSd82loCDA7xoOHsZ S1yOAfUK6eYmi5Soocw0w7iX7SKq19M8BD5GVvSFQj4gByrkLfCwO3LL76oGX1H+ L3CD5tOO/O1z+aUtojJFcoDlfGUV1HGNIRCKdLP/g/4z/Diy1ae9/OMrgDxRvtmq Ojr9lnchkR5CmNntqjAcsMZb3x5IoT1njgI8NLEciqcT2Hk0CsLL3i5nnR41xwXx X/8Rb0XzpzYkYpldGNlpIbadDjH0IKRyemYxeyuNMxR5ZUCauzhoe+G7J34n2/+S gbxQ+gpbfTei/LlD5APN6cyejabmT+eZsM1PdyK179jzu68PFIBIX6arK/q4iYPG gGwr+PKN4PUDawOp0018tn7KKEalvW0k4SLb9zqAI6itMsd9dQvLX/0PmSITKr6R XNc1ApJ7BpADOUI3eNwd/wdOJfTqzD4MW0Ne3EXu+F3S4Ja2Ji5gcK52k+hi3q1F i75RnzTxr2HoDgmXqNNuB8g7kCRalrHDE16OEKuZiv4okk8FT8HIfW9uYFtcG2Dd egnA9QKQ3Ps5Vlz0Tym4kiSKYruN/2ACOnTLD5twGGTmXxOHE2XC+qfzspBrA5UI GIN5xkyHeRMnkQqjVAB7 =L8BX -----END PGP SIGNATURE----- --------------enig6DD7406C9503EA6AA2744577-- --===============1029486961== 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 --===============1029486961==--