From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4 Date: Tue, 12 Mar 2013 16:29:14 +0200 Message-ID: <513F3BBA.6010209@ti.com> References: <1362493070-17706-1-git-send-email-archit@ti.com> <1362493070-17706-5-git-send-email-archit@ti.com> <513DCE08.20404@ti.com> <513EC63A.5060707@ti.com> <513F05A0.6040204@ti.com> <513F2639.5060008@ti.com> <513F2F82.2040604@ti.com> <513F354F.40701@ti.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB65E5AFC24E8D399F24AF28B" Return-path: Received: from arroyo.ext.ti.com ([192.94.94.40]:49094 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753694Ab3CLO3S (ORCPT ); Tue, 12 Mar 2013 10:29:18 -0400 In-Reply-To: <513F354F.40701@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Archit Taneja Cc: robdclark@gmail.com, linux-omap@vger.kernel.org, dri-devel@lists.freedesktop.org --------------enigB65E5AFC24E8D399F24AF28B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-03-12 16:01, Archit Taneja wrote: > On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote: >> So, I don't disagree with you. But I don't quite understand why we cou= ld >> not use the fixed channels for now? They should work in all the boards= >> we have, right? Or is there something with DRM that forces the driver = to >> select the channel dynamically? >=20 > I think we can use fixed channels, but if the number of different fixed= > channels crosses the number of crtcs the kernel wants, then we would > need to atleast change the channels of some of the outputs. >=20 > For example, suppose omapdrm is asked to use only 2 crtcs, and it picks= > up LCD2 and TV managers. Now if there is some panel which says it's > recommended channel is LCD, then things won't work. Are you saying omapdrm picks the managers for the crtcs before knowing what panels there are? That can't work right... We need to know what outputs are to be used before we can select the managers. Or, we always need crtcs for all the managers. If we do know the panels, and thus outputs, then the managers to be used are found easily from output->dispc_channel. But, of course, the crtc to manager mapping could be changed (if omapdrm supports this). If omapdrm is asked to use only 1 crtc, but there are two panels, then only one panel can be used at a time, and the manager for the crtc needs to be changed when the panel to be used is changed. But even in this case used manager is clear, it comes from output->dispc_channel. > At the moment, omapdrm maps a crtc with a manger using a function calle= d > pipe2chan() which just selects a manager with the biggest channel no. S= o > if the kernel is configured to have num_crtcs as 1. The single crtc wil= l > be mapped to LCD2. This method is wrong, as it doesn't even look at the= > type of panels at all. For an omap5 panda, the most suitable manager to= > map to the crtc would be TV(for hdmi). >=20 > I think what we probably need to do is to combine both the methods. I.e= , > make each output connectible to only one channel, and also iterate > through the panels in omapdrm to find the most suitable channels. So in= > my patch, instead of looking at all the supported managers for an > output(checking with dss_feat_get_supported_outputs() on each manager),= > I just look at the recommended channel, and try to map that manager. I don't know, I feel like I'm not understanding something here =3D). Tomi --------------enigB65E5AFC24E8D399F24AF28B 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/ iQIcBAEBAgAGBQJRPzu6AAoJEPo9qoy8lh716UoQAKZAqFkgbsiifm6jI4RhjDKp xTquaWTgrsF+cfWzc6k6bcUY4yBPa2MScIGT9IMNyzCBdX6Z16aNjH0pF+1umeFe byafQ4XxmyTVbYB+aIH0XspHDT4dDjzSuSfg/kWva1V7SxqNj4rnCYESeoh6yfbz hxc0LlPY4xYZ3gSq9n0bbhxBH37LMJpt7C8kHgJ+NKdFDXfCrRB2MaA+n7mGIhya dEXdg6xJVxcXrHqGUAdOobIXaz4jgAuXjJ5adRdhBfNeUf3Ve1IPe/nL4IGuxbZO W7b7qE/UwVQGpqVkBRz6fwa7+SD0P3ehaeOqUllTiEYZUOxAalBLl3ADXhZSAUW5 pUVAIrMYsZ0t1/ujyih/mbfmydp3TErFQyn3XePWl0yYdgtGyphbdGrJYqrl680e zH3b5PSQwP0hllD/cihRFeRQQwMEYPXEDCuHjCi6/ZyyoUHkAVBWkDliTJkEtrp5 /QVsMF90HPJeHXHEOiOMZo5gP3xrKsJjyw/FmK42kIdGmWHSqjTPPwW4p51Q/6qD n9wysD8EF17stGoFvBoxsi3YLKSjaG7YebWV75PCKdBOuwcGoWH/oDhHO65nJKuG xa3unk/rpKfuLw79rksAYjib04TwuGT9dVR38SK4bPYKiEu/42MSiEHgx+aI2xFy FiRpFZScJG6g1F0B4P3n =UD54 -----END PGP SIGNATURE----- --------------enigB65E5AFC24E8D399F24AF28B--