From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: DRM i2c module or bridge ? Date: Thu, 12 Nov 2015 14:18:17 +0100 Message-ID: <20151112131817.GE31671@ulmo> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1243988006==" Return-path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by gabe.freedesktop.org (Postfix) with ESMTPS id B9E386ECEE for ; Thu, 12 Nov 2015 05:18:21 -0800 (PST) Received: by wmww144 with SMTP id w144so87990853wmw.0 for ; Thu, 12 Nov 2015 05:18:20 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Emil Velikov Cc: ML dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1243988006== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y2zxS2PfCDLh6JVG" Content-Disposition: inline --y2zxS2PfCDLh6JVG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2015 at 12:48:51PM +0000, Emil Velikov wrote: > Hello Thierry, all, >=20 > Inspired by a recent discussion I was started wondering - where is the > cut between DRM i2c modules (most of which encoders/transmitters) and > bridge drivers (again some of which i2c encoders) ? Does anyone has > some pointers on the topic ? DRM bridge is a superset of I2C encoders, so everything that I2C encoder drivers do they should be able to do with DRM bridges, and more. There isn't a strict guideline here, but I think there's general agreement that new drivers should be using the DRM bridge framework. The primary reason is that bridges integrate seamlessly with the driver model, that is, the drivers that implement them are regular drivers that register with the corresponding bus and get bound to a device, whereas the I2C encoder infrastructure is mostly about manually instantiating devices. For existing drivers I guess they could all be converted, but doing so may require a bit of work. They also tend to work as-is, so finding volunteers to do the conversion is probably going to be difficult given the lack of motivation. Thierry > Based on the above I did a very quick search for third party IP > modules in the DRM subsystem: >=20 > * i915 > dvo_ch7017.c > dvo_ch7xxx.c > dvo_ivch.c > dvo_ns2501.c > dvo_sil164.c > dvo_tfp410.c It looks like these use some framework that's custom to the i915 driver but could otherwise easily be DRM bridges. > * gma500 > tc35876x-dsi-lvds.c This seems to be some sort of hybrid bridge and panel driver. > * sti > sti_hdmi_tx3g0c55phy.c > sti_hdmi_tx3g4c28phy.c These seem to implement some sort of PHY interface, but from a quick look moving these to the PHY framework seems overkill. They seem no good fit for DRM bridge because they are not separate devices, but rather the SoC generation specific bits of the STi HDMI driver. > (and for posterity) > * i2c > adv7511.c > ch7006_drv.c > sil164_drv.c > tda998x_drv.c >=20 >=20 > * bridge > dw_hdmi.c > nxp-ptn3460.c > parade-ps8622.c >=20 >=20 > By the looks of it, we can move rework (some of?) the above into > i2c/bridge modules and in other cases (sil164) just use the existing > one ? I'm neither volunteering nor suggesting people must work of > these, merely curious. My take on this is that it's probably best to keep the above in their current form. If they need to be shared across multiple hardware setups it might make sense to convert them to DRM bridge drivers. For new drivers it's probably best to make them bridge drivers from the start. Thierry --y2zxS2PfCDLh6JVG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWRJGWAAoJEN0jrNd/PrOhi5QP/0GvWGQdTAYg/f3Ob9v/H1Cx eGERczgyZMF8VwvqTCcv8GYo6eRRJAVTq05BvyNWa/qGb4HsCcJcKr8HvAxG/4oD LlRVQQkV+uKUmfd4Dq8YNQslR0Rb0j74qazjSN7oz25gzsiBHnQb7+K3AsZVA8Me Ebb+3F2pArXL3heactdOpjw2IIhUoyJV3pBaDELgvP4epmQmKZOhOKhMq553ireF cnfAD6yynYg3FyQ0NeLdDRXZMhGrHs4V+vwn3oKNod5gJ/37m8vT93kuPx3luoiX 0rYFPQVsdGgqcIn6lVM78s3DdPBPXVyFR/Sk7QCYdBAqKYMxj0cDL+TMXGC4kmmK cvJeO7JI1AG/jmA9VITm6/YzWQg3Rclc42S4T7xN0Fl/RgWMBiYxr0JBsqC/QZy4 yXkCOfyJW0gALqhbclVW8kQGFAFEUqtZOIbyp51b7PpHJn0bcDZleZGcftzg8ODE Qd4tbBvRJii4J2QQ+nwY+ZEhlxWDulUfchMsdwvSReZkO8ciGHYl8t9sbNHk2mXl HDpSNK22PRC3o7d2Ya/goycUYEMTssNXqtevea3g5m9zpASazk6GPxcHGl+85C04 /GvWlfJ2DJZGV6C+MHSpNQa5K3W6PC/rXodANPYVsQJpvCFjQxVoCKB1++DVe4uZ EnBYZ7+l78Tqwn6yqaCy =Y0HC -----END PGP SIGNATURE----- --y2zxS2PfCDLh6JVG-- --===============1243988006== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1243988006==--