From mboxrd@z Thu Jan 1 00:00:00 1970 From: boris.brezillon@bootlin.com (Boris Brezillon) Date: Wed, 18 Apr 2018 10:41:28 +0200 Subject: [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder In-Reply-To: <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se> References: <20180417131052.16336-1-peda@axentia.se> <20180417131052.16336-6-peda@axentia.se> <20180418093649.2c304f29@bbrezillon> <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se> Message-ID: <20180418104128.6747ad47@bbrezillon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, 18 Apr 2018 10:02:12 +0200 Peter Rosin wrote: > On 2018-04-18 09:36, Boris Brezillon wrote: > > On Tue, 17 Apr 2018 15:10:51 +0200 > > Peter Rosin wrote: > > > >> When the of-graph points to a tda998x-compatible HDMI encoder, register > >> as a component master and bind to the encoder/connector provided by > >> the tda998x driver. > > > > Can't we do the opposite: make the tda998x driver expose its devices as > > drm bridges. I'd rather not add another way to connect external > > encoders (or bridges) to display controller drivers, especially since, > > when I asked DRM maintainers/devs what was the good approach to > > represent such external encoders they pointed me to the drm_bridge > > interface. > > From the cover letter: > > "However, I don't know if the tilcdc driver is interfacing with the > tda998x driver in a sane and modern way" > > So, which way is the future? Should bridges become components or should > existing bridge-like components no longer be components? Are there others? Well, what I've been told a while ago is that drm_bridge will take over drm_encoder_slave and custom drm_encoder/drm_connector implementations when it comes to representing bridges. AFAIU, using the component framework to bind all elements of the pipeline to the display controller is orthogonal to how you represent elements in the pipeline. I mean, you could have a bridge that registers as a component so that display controllers drivers who want to use the component framework don't have to re-code the component-to-bridge glue every time, and those who don't use the component framework can still get access to the bridge. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Subject: Re: [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder Date: Wed, 18 Apr 2018 10:41:28 +0200 Message-ID: <20180418104128.6747ad47@bbrezillon> References: <20180417131052.16336-1-peda@axentia.se> <20180417131052.16336-6-peda@axentia.se> <20180418093649.2c304f29@bbrezillon> <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Peter Rosin Cc: Mark Rutland , Boris Brezillon , Alexandre Belloni , devicetree@vger.kernel.org, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Nicolas Ferre , Rob Herring , Laurent Pinchart , Daniel Vetter , Russell King - ARM Linux , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org T24gV2VkLCAxOCBBcHIgMjAxOCAxMDowMjoxMiArMDIwMApQZXRlciBSb3NpbiA8cGVkYUBheGVu dGlhLnNlPiB3cm90ZToKCj4gT24gMjAxOC0wNC0xOCAwOTozNiwgQm9yaXMgQnJlemlsbG9uIHdy b3RlOgo+ID4gT24gVHVlLCAxNyBBcHIgMjAxOCAxNToxMDo1MSArMDIwMAo+ID4gUGV0ZXIgUm9z aW4gPHBlZGFAYXhlbnRpYS5zZT4gd3JvdGU6Cj4gPiAgIAo+ID4+IFdoZW4gdGhlIG9mLWdyYXBo IHBvaW50cyB0byBhIHRkYTk5OHgtY29tcGF0aWJsZSBIRE1JIGVuY29kZXIsIHJlZ2lzdGVyCj4g Pj4gYXMgYSBjb21wb25lbnQgbWFzdGVyIGFuZCBiaW5kIHRvIHRoZSBlbmNvZGVyL2Nvbm5lY3Rv ciBwcm92aWRlZCBieQo+ID4+IHRoZSB0ZGE5OTh4IGRyaXZlci4gIAo+ID4gCj4gPiBDYW4ndCB3 ZSBkbyB0aGUgb3Bwb3NpdGU6IG1ha2UgdGhlIHRkYTk5OHggZHJpdmVyIGV4cG9zZSBpdHMgZGV2 aWNlcyBhcwo+ID4gZHJtIGJyaWRnZXMuIEknZCByYXRoZXIgbm90IGFkZCBhbm90aGVyIHdheSB0 byBjb25uZWN0IGV4dGVybmFsCj4gPiBlbmNvZGVycyAob3IgYnJpZGdlcykgdG8gZGlzcGxheSBj b250cm9sbGVyIGRyaXZlcnMsIGVzcGVjaWFsbHkgc2luY2UsCj4gPiB3aGVuIEkgYXNrZWQgRFJN IG1haW50YWluZXJzL2RldnMgd2hhdCB3YXMgdGhlIGdvb2QgYXBwcm9hY2ggdG8KPiA+IHJlcHJl c2VudCBzdWNoIGV4dGVybmFsIGVuY29kZXJzIHRoZXkgcG9pbnRlZCBtZSB0byB0aGUgZHJtX2Jy aWRnZQo+ID4gaW50ZXJmYWNlLiAgCj4gCj4gRnJvbSB0aGUgY292ZXIgbGV0dGVyOgo+IAo+ICJI b3dldmVyLCBJIGRvbid0IGtub3cgaWYgdGhlIHRpbGNkYyBkcml2ZXIgaXMgaW50ZXJmYWNpbmcg d2l0aCB0aGUKPiB0ZGE5OTh4IGRyaXZlciBpbiBhIHNhbmUgYW5kIG1vZGVybiB3YXkiCj4gCj4g U28sIHdoaWNoIHdheSBpcyB0aGUgZnV0dXJlPyBTaG91bGQgYnJpZGdlcyBiZWNvbWUgY29tcG9u ZW50cyBvciBzaG91bGQKPiBleGlzdGluZyBicmlkZ2UtbGlrZSBjb21wb25lbnRzIG5vIGxvbmdl ciBiZSBjb21wb25lbnRzPyBBcmUgdGhlcmUgb3RoZXJzPwoKV2VsbCwgd2hhdCBJJ3ZlIGJlZW4g dG9sZCBhIHdoaWxlIGFnbyBpcyB0aGF0IGRybV9icmlkZ2Ugd2lsbCB0YWtlIG92ZXIKZHJtX2Vu Y29kZXJfc2xhdmUgYW5kIGN1c3RvbSBkcm1fZW5jb2Rlci9kcm1fY29ubmVjdG9yIGltcGxlbWVu dGF0aW9ucwp3aGVuIGl0IGNvbWVzIHRvIHJlcHJlc2VudGluZyBicmlkZ2VzLgoKQUZBSVUsIHVz aW5nIHRoZSBjb21wb25lbnQgZnJhbWV3b3JrIHRvIGJpbmQgYWxsIGVsZW1lbnRzIG9mIHRoZQpw aXBlbGluZSB0byB0aGUgZGlzcGxheSBjb250cm9sbGVyIGlzIG9ydGhvZ29uYWwgdG8gaG93IHlv dSByZXByZXNlbnQKZWxlbWVudHMgaW4gdGhlIHBpcGVsaW5lLiBJIG1lYW4sIHlvdSBjb3VsZCBo YXZlIGEgYnJpZGdlIHRoYXQKcmVnaXN0ZXJzIGFzIGEgY29tcG9uZW50IHNvIHRoYXQgZGlzcGxh eSBjb250cm9sbGVycyBkcml2ZXJzIHdobyB3YW50CnRvIHVzZSB0aGUgY29tcG9uZW50IGZyYW1l d29yayBkb24ndCBoYXZlIHRvIHJlLWNvZGUgdGhlCmNvbXBvbmVudC10by1icmlkZ2UgZ2x1ZSBl dmVyeSB0aW1lLCBhbmQgdGhvc2Ugd2hvIGRvbid0IHVzZSB0aGUKY29tcG9uZW50IGZyYW1ld29y ayBjYW4gc3RpbGwgZ2V0IGFjY2VzcyB0byB0aGUgYnJpZGdlLgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1k ZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcv bWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753664AbeDRIld (ORCPT ); Wed, 18 Apr 2018 04:41:33 -0400 Received: from mail.bootlin.com ([62.4.15.54]:55668 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752514AbeDRIlb (ORCPT ); Wed, 18 Apr 2018 04:41:31 -0400 Date: Wed, 18 Apr 2018 10:41:28 +0200 From: Boris Brezillon To: Peter Rosin Cc: linux-kernel@vger.kernel.org, David Airlie , Rob Herring , Mark Rutland , Nicolas Ferre , Alexandre Belloni , Boris Brezillon , Daniel Vetter , Gustavo Padovan , Sean Paul , Laurent Pinchart , Russell King - ARM Linux , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder Message-ID: <20180418104128.6747ad47@bbrezillon> In-Reply-To: <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se> References: <20180417131052.16336-1-peda@axentia.se> <20180417131052.16336-6-peda@axentia.se> <20180418093649.2c304f29@bbrezillon> <0155b3cc-29ce-fa43-5588-b465c6ee064a@axentia.se> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 Apr 2018 10:02:12 +0200 Peter Rosin wrote: > On 2018-04-18 09:36, Boris Brezillon wrote: > > On Tue, 17 Apr 2018 15:10:51 +0200 > > Peter Rosin wrote: > > > >> When the of-graph points to a tda998x-compatible HDMI encoder, register > >> as a component master and bind to the encoder/connector provided by > >> the tda998x driver. > > > > Can't we do the opposite: make the tda998x driver expose its devices as > > drm bridges. I'd rather not add another way to connect external > > encoders (or bridges) to display controller drivers, especially since, > > when I asked DRM maintainers/devs what was the good approach to > > represent such external encoders they pointed me to the drm_bridge > > interface. > > From the cover letter: > > "However, I don't know if the tilcdc driver is interfacing with the > tda998x driver in a sane and modern way" > > So, which way is the future? Should bridges become components or should > existing bridge-like components no longer be components? Are there others? Well, what I've been told a while ago is that drm_bridge will take over drm_encoder_slave and custom drm_encoder/drm_connector implementations when it comes to representing bridges. AFAIU, using the component framework to bind all elements of the pipeline to the display controller is orthogonal to how you represent elements in the pipeline. I mean, you could have a bridge that registers as a component so that display controllers drivers who want to use the component framework don't have to re-code the component-to-bridge glue every time, and those who don't use the component framework can still get access to the bridge.