From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 2/2] drm/i915/dp: check eDP display control capability registers Date: Tue, 19 Nov 2013 09:37:04 +0100 Message-ID: <20131119083703.GB31504@ulmo.nvidia.com> References: <1384520511-24267-1-git-send-email-jani.nikula@intel.com> <1384520511-24267-2-git-send-email-jani.nikula@intel.com> <20131118142755.GF26046@ulmo.nvidia.com> <20131118152616.GK26046@ulmo.nvidia.com> <20131118162054.GC8203@phenom.ffwll.local> <20131118163119.GA30396@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0145646204==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter Cc: Alex Deucher , Jani Nikula , Intel Graphics Development , Maling list - DRI developers List-Id: intel-gfx@lists.freedesktop.org --===============0145646204== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MfFXiAuoTsnnDAfZ" Content-Disposition: inline --MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 05:38:18PM +0100, Daniel Vetter wrote: > On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding > wrote: > >> Note that there's already a bit of abstraction for i2c over dp aux, but > >> imo that's at the wrong level. At least reading through i915, gma500 a= nd > >> radeon code there's a lot more we could share with just a dp aux helper > >> library (which then implements useful stuff on top of it). > > > > I have some difficulty envisioning how the helper code can work without > > some sort of driver-specific ops implementation. Currently the helpers > > only use a snapshot of the DPCD to extract information. Eventually we'll > > be bound to modify the DPCD, so some method of writing it back (or a > > subset of it) will be needed. Otherwise the scope of the helper library > > will be somewhat limited. > > > > Once we have the callbacks, the current helpers could be reworked to not > > use a buffer, but rather an "AUX channel object" and access the > > registers directly. If there are concerns about performance, it could > > possibly be implemented as a sort of cache, too. That would make it fast > > to query the status. I don't think it'll be worth the added complexity, > > though. >=20 > Oh, my idea is that the dp aux driver callback would at the level of > the intel_dp_aux_ch function in i915/intel_dp.c (gma500 and radeon > have something very similar). That alone would allow us to share a > considerable amount of code. Should have been a bit clearer, I've > discussed this in a bit more detail with Alex many moons ago ... Yeah, that's similar to what I had in mind. I think we may need something slightly more complex, though. We want to support both AUX as well as I2C over AUX transactions, so we'll probably need to add a mode argument. I was thinking about adding a dp_aux_msg structure in order to keep the argument list to a reasonable length. Thierry --MfFXiAuoTsnnDAfZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSiyMvAAoJEN0jrNd/PrOhMsQP/1sbEcvsCmQQ01qLRkvP8hA1 HYZM3NcKpYyN1vxQ8ym5EVG2Qriib23LShu14b4As+niEcCktlm+uHqHge7K4Ysc mP6du04njaNM3AxJgwcuIOl1XBdGvCPNDVUivnfmEgwjWhNcmz3ytVVVnjnLQUcy zIhmHkIzmfBzmycd8TH0FwwIhP1bRST/wn6y4J9CcIIpCr/axvTmtqqJyr3aJ1n4 Nb1wIN1UEL7SPPBunm/qqLyO/zUdsm2SCY3gU7BPxWUaxZGwVfohe8LFOi6kjtGK v0v2K1OdrLBi7FF0SWgVA/SeLdoUYfGJmtv1me6erG/TIz6hGx+wq5yiQG+rBClv 13s5xUjtl7WjEd4igg7WB4KAkgCsPgIyJUZp3qn6eD5YNbZWoxBkRBgclG691H0j 9EFj5DyuI3nMsCdrpZksOVj2jCjr41HqLNqYBw5o79+1DFWXWG3ZhrMSOejq47ti 7e5CNkkEkZNRWnBflyCJ4US3+YfTpPVkv5WrtGSeiQnB7WvMB7Z/k7Z22URGKQxJ YhfOcX53O0XA9ex0PkUURrsDBl1PxWFkxG71D6AZl9NoOl3rbe4KL0VPV0wr3gby ypvCmkeGezmK3S42VwmDosZKbeqc0r/npLehcAXmMUM0cchIsMQAZoMYYdsm6Okp hZk2IWRPl5fHUfEmLLD8 =hvAa -----END PGP SIGNATURE----- --MfFXiAuoTsnnDAfZ-- --===============0145646204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0145646204==--