From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer Date: Wed, 16 May 2018 11:31:10 +0200 Message-ID: <20180516093110.GC3438@phenom.ffwll.local> References: <20180504135212.26977-1-peda@axentia.se> <20180504135212.26977-27-peda@axentia.se> <20180514162828.GE28661@phenom.ffwll.local> <73fa1ca3-28e4-96c5-1fc6-23e9c0cebb49@axentia.se> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline 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: Peter Rosin Cc: Martyn Welch , David Airlie , dri-devel , Laurent Pinchart , linux-samsung-soc , Kyungmin Park , Krzysztof Kozlowski , "open list:ARM/Rockchip SoC..." , Kukjin Kim , Peter Senna Tschudin , Martin Donnelly , linux-arm-msm , Jyri Sarha , Matthias Brugger , Vincent Abriou , Linux ARM , Seung-Woo Kim , Linux Kernel Mailing List , "open list:DRM DRIVERS FOR RENESAS" List-Id: linux-arm-msm@vger.kernel.org T24gVHVlLCBNYXkgMTUsIDIwMTggYXQgMDE6MDk6NTlQTSArMDIwMCwgUGV0ZXIgUm9zaW4gd3Jv dGU6Cj4gT24gMjAxOC0wNS0xNSAxMjoyMiwgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+IE9uIE1v biwgTWF5IDE0LCAyMDE4IGF0IDEwOjQwIFBNLCBQZXRlciBSb3NpbiA8cGVkYUBheGVudGlhLnNl PiB3cm90ZToKPiA+PiBPbiAyMDE4LTA1LTE0IDE4OjI4LCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ ID4+PiBPbiBGcmksIE1heSAxMSwgMjAxOCBhdCAwOTozNzo0N0FNICswMjAwLCBQZXRlciBSb3Np biB3cm90ZToKPiA+Pj4+IE9uIDIwMTgtMDUtMTAgMTA6MTAsIEFuZHJ6ZWogSGFqZGEgd3JvdGU6 Cj4gPj4+Pj4gT24gMDQuMDUuMjAxOCAxNTo1MiwgUGV0ZXIgUm9zaW4gd3JvdGU6Cj4gPj4+Pj4+ IElmIHRoZSBicmlkZ2Ugc3VwcGxpZXIgaXMgdW5ib3VuZCwgdGhpcyB3aWxsIGJyaW5nIHRoZSBi cmlkZ2UgY29uc3VtZXIKPiA+Pj4+Pj4gZG93biBhbG9uZyB3aXRoIHRoZSBicmlkZ2UuIFRodXMs IHRoZXJlIHdpbGwgbm8gbG9uZ2VyIGxpbmdlciBhbnkKPiA+Pj4+Pj4gZGFuZ2xpbmcgcG9pbnRl cnMgZnJvbSB0aGUgYnJpZGdlIGNvbnN1bWVyICh0aGUgZHJtX2RldmljZSkgdG8gc29tZQo+ID4+ Pj4+PiBub24tZXhpc3RlbnQgYnJpZGdlIHN1cHBsaWVyLgo+ID4+Pj4+Pgo+ID4+Pj4+PiBTaWdu ZWQtb2ZmLWJ5OiBQZXRlciBSb3NpbiA8cGVkYUBheGVudGlhLnNlPgo+ID4+Pj4+PiAtLS0KPiA+ Pj4+Pj4gIGRyaXZlcnMvZ3B1L2RybS9kcm1fYnJpZGdlLmMgfCAxOCArKysrKysrKysrKysrKysr KysKPiA+Pj4+Pj4gIGluY2x1ZGUvZHJtL2RybV9icmlkZ2UuaCAgICAgfCAgMiArKwo+ID4+Pj4+ PiAgMiBmaWxlcyBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCspCj4gPj4+Pj4+Cj4gPj4+Pj4+IGRp ZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vZHJtX2JyaWRnZS5jIGIvZHJpdmVycy9ncHUvZHJt L2RybV9icmlkZ2UuYwo+ID4+Pj4+PiBpbmRleCA3OGQxODZiNjgzMWIuLjAyNTlmMGEzZmYyNyAx MDA2NDQKPiA+Pj4+Pj4gLS0tIGEvZHJpdmVycy9ncHUvZHJtL2RybV9icmlkZ2UuYwo+ID4+Pj4+ PiArKysgYi9kcml2ZXJzL2dwdS9kcm0vZHJtX2JyaWRnZS5jCj4gPj4+Pj4+IEBAIC0yNiw2ICsy Niw3IEBACj4gPj4+Pj4+ICAjaW5jbHVkZSA8bGludXgvbXV0ZXguaD4KPiA+Pj4+Pj4KPiA+Pj4+ Pj4gICNpbmNsdWRlIDxkcm0vZHJtX2JyaWRnZS5oPgo+ID4+Pj4+PiArI2luY2x1ZGUgPGRybS9k cm1fZGV2aWNlLmg+Cj4gPj4+Pj4+ICAjaW5jbHVkZSA8ZHJtL2RybV9lbmNvZGVyLmg+Cj4gPj4+ Pj4+Cj4gPj4+Pj4+ICAjaW5jbHVkZSAiZHJtX2NydGNfaW50ZXJuYWwuaCIKPiA+Pj4+Pj4gQEAg LTEyNywxMiArMTI4LDI1IEBAIGludCBkcm1fYnJpZGdlX2F0dGFjaChzdHJ1Y3QgZHJtX2VuY29k ZXIgKmVuY29kZXIsIHN0cnVjdCBkcm1fYnJpZGdlICpicmlkZ2UsCj4gPj4+Pj4+ICAgIGlmIChi cmlkZ2UtPmRldikKPiA+Pj4+Pj4gICAgICAgICAgICByZXR1cm4gLUVCVVNZOwo+ID4+Pj4+Pgo+ ID4+Pj4+PiArICBpZiAoZW5jb2Rlci0+ZGV2LT5kZXYgIT0gYnJpZGdlLT5vZGV2KSB7Cj4gPj4+ Pj4KPiA+Pj4+PiBJIHdvbmRlciB3aHkgZGV2aWNlX2xpbmtfYWRkIGRvZXMgbm90IGhhbmRsZSB0 aGlzIGNhc2UgKHNlbGYgZGVwZW5kZW5jeSkKPiA+Pj4+PiBzaWxlbnRseSBhcyBub29wLCBhcyBp dCBzZWVtcyB0byBiZSBhIGNvcnJlY3QgYmVoYXZpb3IuCj4gPj4+Pgo+ID4+Pj4gSXQncyBraW5k LW9mIGEgc2lsbHkgY29ybmVyLWNhc2UgdGhvdWdoLCBzbyBwZXJmZWN0bHkgdW5kZXJzdGFuZGFi bGUKPiA+Pj4+IHRoYXQgaXQgaXNuJ3QgaGFuZGxlZC4KPiA+Pj4+Cj4gPj4+Pj4+ICsgICAgICAg ICAgYnJpZGdlLT5saW5rID0gZGV2aWNlX2xpbmtfYWRkKGVuY29kZXItPmRldi0+ZGV2LAo+ID4+ Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBicmlkZ2UtPm9k ZXYsIDApOwo+ID4+Pj4+PiArICAgICAgICAgIGlmICghYnJpZGdlLT5saW5rKSB7Cj4gPj4+Pj4+ ICsgICAgICAgICAgICAgICAgICBkZXZfZXJyKGJyaWRnZS0+b2RldiwgImZhaWxlZCB0byBsaW5r IGJyaWRnZSB0byAlc1xuIiwKPiA+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgZGV2 X25hbWUoZW5jb2Rlci0+ZGV2LT5kZXYpKTsKPiA+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgIHJl dHVybiAtRUlOVkFMOwo+ID4+Pj4+PiArICAgICAgICAgIH0KPiA+Pj4+Pj4gKyAgfQo+ID4+Pj4+ PiArCj4gPj4+Pj4+ICAgIGJyaWRnZS0+ZGV2ID0gZW5jb2Rlci0+ZGV2Owo+ID4+Pj4+PiAgICBi cmlkZ2UtPmVuY29kZXIgPSBlbmNvZGVyOwo+ID4+Pj4+Pgo+ID4+Pj4+PiAgICBpZiAoYnJpZGdl LT5mdW5jcy0+YXR0YWNoKSB7Cj4gPj4+Pj4+ICAgICAgICAgICAgcmV0ID0gYnJpZGdlLT5mdW5j cy0+YXR0YWNoKGJyaWRnZSk7Cj4gPj4+Pj4+ICAgICAgICAgICAgaWYgKHJldCA8IDApIHsKPiA+ Pj4+Pj4gKyAgICAgICAgICAgICAgICAgIGlmIChicmlkZ2UtPmxpbmspCj4gPj4+Pj4+ICsgICAg ICAgICAgICAgICAgICAgICAgICAgIGRldmljZV9saW5rX2RlbChicmlkZ2UtPmxpbmspOwo+ID4+ Pj4+PiArICAgICAgICAgICAgICAgICAgYnJpZGdlLT5saW5rID0gTlVMTDsKPiA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgIGJyaWRnZS0+ZGV2ID0gTlVMTDsKPiA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgIGJyaWRnZS0+ZW5jb2RlciA9IE5VTEw7Cj4gPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICByZXR1cm4gcmV0Owo+ID4+Pj4+PiBAQCAtMTU5LDYgKzE3MywxMCBAQCB2b2lkIGRybV9icmlk Z2VfZGV0YWNoKHN0cnVjdCBkcm1fYnJpZGdlICpicmlkZ2UpCj4gPj4+Pj4+ICAgIGlmIChicmlk Z2UtPmZ1bmNzLT5kZXRhY2gpCj4gPj4+Pj4+ICAgICAgICAgICAgYnJpZGdlLT5mdW5jcy0+ZGV0 YWNoKGJyaWRnZSk7Cj4gPj4+Pj4+Cj4gPj4+Pj4+ICsgIGlmIChicmlkZ2UtPmxpbmspCj4gPj4+ Pj4+ICsgICAgICAgICAgZGV2aWNlX2xpbmtfZGVsKGJyaWRnZS0+bGluayk7Cj4gPj4+Pj4+ICsg IGJyaWRnZS0+bGluayA9IE5VTEw7Cj4gPj4+Pj4+ICsKPiA+Pj4+Pj4gICAgYnJpZGdlLT5kZXYg PSBOVUxMOwo+ID4+Pj4+PiAgfQo+ID4+Pj4+Pgo+ID4+Pj4+PiBkaWZmIC0tZ2l0IGEvaW5jbHVk ZS9kcm0vZHJtX2JyaWRnZS5oIGIvaW5jbHVkZS9kcm0vZHJtX2JyaWRnZS5oCj4gPj4+Pj4+IGlu ZGV4IGI2NTZlNTA1ZDExZS4uODA0MTg5YzYzYTRjIDEwMDY0NAo+ID4+Pj4+PiAtLS0gYS9pbmNs dWRlL2RybS9kcm1fYnJpZGdlLmgKPiA+Pj4+Pj4gKysrIGIvaW5jbHVkZS9kcm0vZHJtX2JyaWRn ZS5oCj4gPj4+Pj4+IEBAIC0yNjEsNiArMjYxLDcgQEAgc3RydWN0IGRybV9icmlkZ2VfdGltaW5n cyB7Cj4gPj4+Pj4+ICAgKiBAbGlzdDogdG8ga2VlcCB0cmFjayBvZiBhbGwgYWRkZWQgYnJpZGdl cwo+ID4+Pj4+PiAgICogQHRpbWluZ3M6IHRoZSB0aW1pbmcgc3BlY2lmaWNhdGlvbiBmb3IgdGhl IGJyaWRnZSwgaWYgYW55IChtYXkKPiA+Pj4+Pj4gICAqIGJlIE5VTEwpCj4gPj4+Pj4+ICsgKiBA bGluazogZHJtIGNvbnN1bWVyIDwtPiBicmlkZ2Ugc3VwcGxpZXIKPiA+Pj4+Pgo+ID4+Pj4+IE5p dHBpY2s6ICI8LT4iIHN1Z2dlc3RzIHN5bW1ldHJ5LCBtYXliZSAiZGV2aWNlIGxpbmsgZnJvbSBk cm0gY29uc3VtZXIKPiA+Pj4+PiB0byB0aGUgYnJpZGdlIiB3b3VsZCBiZSBiZXR0ZXIuCj4gPj4+ Pgo+ID4+Pj4gSSBtZWFudCAiPC0+IiB0byBpbmRpY2F0ZSB0aGF0IHRoZSBsaW5rIGlzIGJpZGly ZWN0aW9uYWwsIG5vdCB0aGF0IHRoZQo+ID4+Pj4gcmVsYXRpb25zaGlwIGlzIGluIGFueSB3YXkg c3ltbWV0cmljLiBJIHdhc24ndCBhd2FyZSBvZiBhbnkgaW1wbGljYXRpb24KPiA+Pj4+IG9mIGEg c3ltbWV0cmljIHJlbGF0aW9uc2hpcCB3aGVuIHVzaW5nICI8LT4iLCBkbyB5b3UgaGF2ZSBhIHJl ZmVyZW5jZT8KPiA+Pj4+IEJ1dCBJIGd1ZXNzIHRoZSBkaWZmZXJlbnQgYXJyb3cgbm90YXRpb25z IGluIG1hdGggYXJlIHNvbWV3aGF0IG92ZXJsb2FkZWQKPiA+Pj4+IGFuZCB0aGF0IHNvbWVvbmUg YXQgc29tZSBwb2ludCBtdXN0IGhhdmUgdXNlZCAiPC0+IiB0byBpbmRpY2F0ZSBhCj4gPj4+PiBz eW1tZXRyaWMgcmVsYXRpb25zaGlwLi4uCj4gPj4+Cj4gPj4+IFllYWggSSBhZ3JlZSB3aXRoIEFu ZHJ6ZWogaGVyZSwgZm9yIG1lIDwtPiBpbXBsaWVzIGEgc3ltbWV0cmljCj4gPj4+IHJlbGF0aW9u c2hpcC4gU3BlbGxpbmcgaXQgb3V0IGxpa2UgQW5kcnplaiBzdWdnZXN0ZWQgc291bmRzIGxpa2Ug dGhlCj4gPj4+IGJldHRlciBpZGVhLgo+ID4+PiAtRGFuaWVsCj4gPj4KPiA+PiBPaywgSSBndWVz cyB0aGF0IG1lYW5zIEkgaGF2ZSB0byBkbyBhIHYzIGFmdGVyIGFsbC4gT3IgY2FuIHRoaXMKPiA+ PiB0cml2aWFsIGRvY3VtZW50YXRpb24gdXBkYXRlIGJlIGRvbmUgYnkgdGhlIGNvbW1pdHRlcj8g SSBoYXRlIHRvCj4gPj4gc3BhbSBldmVyeW9uZSB3aXRoIGFub3RoZXIgdm9sbGV5Li4uCj4gPj4K PiA+PiBPciBwZXJoYXBzIEkgc2hvdWxkIHNxdWFzaCBwYXRjaGVzIDItMjMgdGhhdCBhcmUgYWxs IHJhdGhlciBzaW1pbGFyCj4gPj4gYW5kIG1lY2hhbmljPyBJIHNlcGFyYXRlZCB0aGVtIHRvIGFs bG93IGZvciBlYXNpZXIgcmV2aWV3IGZyb20KPiA+PiBpbmRpdmlkdWFsIGRyaXZlciBtYWludGFp bmVycywgYnV0IHRoYXQgZGlkbid0IHNlZW0gdG8gaGFwcGVuCj4gPj4gYW55d2F5Li4uCj4gPiAK PiA+IERvIGFub3RoZXIgdm9sbGV5IG9mIHRoZSBmdWxsIHNldCwgb3IgaW4tcmVwbHktdG8gdG8g anVzdCByZXBsYWNlIHRoZQo+ID4gcGF0Y2ggdGhhdCBuZWVkcyB0byBiZSByZXNwdW4gKGJ1dCBz b21lIHBlb3BsZSBkb24ndCBsaWtlIHRoYXQpLgo+ID4gCj4gPiBXaGVuIHJlc2VuZGluZyBqdXN0 IG1ha2Ugc3VyZSB5b3UncmUgcGlja2luZyB1cCBhbGwgdGhlIGFja3Mvci1icyB5b3UKPiA+IGhh dmUgYWxyZWFkeS4KPiAKPiBSaWdodCwgSSBhbHdheXMgdHJ5IHRvIGRvIHRoYXQuIE9uZSBBY2sg dGhhdCBJIGRpZCBub3QgaW5jbHVkZSBpbiB2Mgo+IHdhcyB0aGUgb25lIHlvdSBoYWQgb24gdjEg MjQvMjQgKGkuZS4gdGhpcyBwYXRjaCkuIFRoZSByZWFzb24gSSBkaWQKPiBub3QgYWRkIHlvdXIg QWNrIGZvciB2MiBldmVuIG9uIHRoZSBwYXRjaCB3aGVyZSBpdCBvYnZpb3VzbHkgYXBwbGllZAo+ IHdhcyB0aGF0IEkgZGlkbid0IGtub3cgaWYgeW91J2QgYmFyZiBvbiB0aGUgb2RldiBuYW1lLgo+ IAo+IEJ1dCBpdCB3YXMgKGFuZCBzdGlsbCBpcykgYSBiaXQgdW5jbGVhciBpZiB0aGF0IHdhcyBv biBBY2sgb24gdGhlCj4gbGFzdCBwYXRjaCBvbmx5LCBvciBpZiBpdCB3YXMgZm9yIHRoZSB3aG9s ZSBzZXJpZXM/IEkgdGhpbmsgaXQgbWlnaHQKPiBoYXZlIGJlZW4gZm9yIHRoZSB3aG9sZSBzZXJp ZXMsIGJ1dCBJJ20gbm90IHN1cmUgYW5kIEkgaGF0ZSB0byBiZSBhCj4gcHJlc3VtcHR1b3VzIGlk aW90Li4uCgpBY2sgb24gdGhlIG92ZXJhbGwgY29uY2VwdCwgYW5kIEknbSBvayB3aXRoIG9kZXYg dG9vLiBCdXQgZGVmaW5pdGVseSBnZXQKYWNrcyBmcm9tIHJlbGV2YW50IHBlb3BsZSAoYnJpZGdl L2RyaXZlciBtYWludGFpbmVycykuIEluIHRlcm1zIG9mCnBhdGNoZXMsIEknZCBzYXkgcGF0Y2gg MSArIDI0LTI2IGhhdmUgbXkKCkFja2VkLWJ5OiBEYW5pZWwgVmV0dGVyIDxkYW5pZWwudmV0dGVy QGZmd2xsLmNoPgoKLURhbmllbAoKPiAKPiBDaGVlcnMsCj4gUGV0ZXIKPiAKPiA+IC1EYW5pZWwK PiA+PiBDaGVlcnMsCj4gPj4gUGV0ZXIKPiA+Pgo+ID4+Pgo+ID4+Pj4KPiA+Pj4+PiBBbnl3YXk6 Cj4gPj4+Pj4gUmV2aWV3ZWQtYnk6IEFuZHJ6ZWogSGFqZGEgPGEuaGFqZGFAc2Ftc3VuZy5jb20+ Cj4gPj4+Pgo+ID4+Pj4gVGhhbmtzIQo+ID4+Pj4KPiA+Pj4+IENoZWVycywKPiA+Pj4+IFBldGVy Cj4gPj4+Pgo+ID4+Pj4+ICAtLQo+ID4+Pj4+IFJlZ2FyZHMKPiA+Pj4+PiBBbmRyemVqCj4gPj4+ Pj4KPiA+Pj4+Pj4gICAqIEBmdW5jczogY29udHJvbCBmdW5jdGlvbnMKPiA+Pj4+Pj4gICAqIEBk cml2ZXJfcHJpdmF0ZTogcG9pbnRlciB0byB0aGUgYnJpZGdlIGRyaXZlcidzIGludGVybmFsIGNv bnRleHQKPiA+Pj4+Pj4gICAqLwo+ID4+Pj4+PiBAQCAtMjcxLDYgKzI3Miw3IEBAIHN0cnVjdCBk cm1fYnJpZGdlIHsKPiA+Pj4+Pj4gICAgc3RydWN0IGRybV9icmlkZ2UgKm5leHQ7Cj4gPj4+Pj4+ ICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlzdDsKPiA+Pj4+Pj4gICAgY29uc3Qgc3RydWN0IGRybV9i cmlkZ2VfdGltaW5ncyAqdGltaW5nczsKPiA+Pj4+Pj4gKyAgc3RydWN0IGRldmljZV9saW5rICps aW5rOwo+ID4+Pj4+Pgo+ID4+Pj4+PiAgICBjb25zdCBzdHJ1Y3QgZHJtX2JyaWRnZV9mdW5jcyAq ZnVuY3M7Cj4gPj4+Pj4+ICAgIHZvaWQgKmRyaXZlcl9wcml2YXRlOwo+ID4+Pj4+Cj4gPj4+Pj4K PiA+Pj4+Cj4gPj4+Cj4gPj4KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+ID4+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKPiA+PiBkcmktZGV2ZWxA bGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gPj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcv bWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwKPiA+IAo+ID4gCj4gPiAKPiAKCi0tIApEYW5pZWwg VmV0dGVyClNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgpodHRwOi8vYmxvZy5m ZndsbC5jaApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpk cmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0 cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752101AbeEPJbV (ORCPT ); Wed, 16 May 2018 05:31:21 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:37678 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751395AbeEPJbP (ORCPT ); Wed, 16 May 2018 05:31:15 -0400 X-Google-Smtp-Source: AB8JxZrskyQc7sWDiW7E8jyiIh8074NDD32A7Av14DFAAs3nzi8H5jJq/rxMUroofVFkEM5UsaK7GA== Date: Wed, 16 May 2018 11:31:10 +0200 From: Daniel Vetter To: Peter Rosin Cc: Daniel Vetter , Andrzej Hajda , Linux Kernel Mailing List , Archit Taneja , Laurent Pinchart , David Airlie , Peter Senna Tschudin , Martin Donnelly , Martyn Welch , Gustavo Padovan , Maarten Lankhorst , Sean Paul , Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Kukjin Kim , Krzysztof Kozlowski , CK Hu , Philipp Zabel , Matthias Brugger , Rob Clark , Sandy Huang , Heiko =?iso-8859-1?Q?St=FCbner?= , Benjamin Gaignard , Vincent Abriou , dri-devel , Linux ARM , linux-samsung-soc , "moderated list:ARM/Mediatek SoC support" , linux-arm-msm , freedreno , "open list:DRM DRIVERS FOR RENESAS" , "open list:ARM/Rockchip SoC..." , Jyri Sarha Subject: Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer Message-ID: <20180516093110.GC3438@phenom.ffwll.local> Mail-Followup-To: Peter Rosin , Andrzej Hajda , Linux Kernel Mailing List , Archit Taneja , Laurent Pinchart , David Airlie , Peter Senna Tschudin , Martin Donnelly , Martyn Welch , Gustavo Padovan , Maarten Lankhorst , Sean Paul , Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Kukjin Kim , Krzysztof Kozlowski , CK Hu , Philipp Zabel , Matthias Brugger , Rob Clark , Sandy Huang , Heiko =?iso-8859-1?Q?St=FCbner?= , Benjamin Gaignard , Vincent Abriou , dri-devel , Linux ARM , linux-samsung-soc , "moderated list:ARM/Mediatek SoC support" , linux-arm-msm , freedreno , "open list:DRM DRIVERS FOR RENESAS" , "open list:ARM/Rockchip SoC..." , Jyri Sarha References: <20180504135212.26977-1-peda@axentia.se> <20180504135212.26977-27-peda@axentia.se> <20180514162828.GE28661@phenom.ffwll.local> <73fa1ca3-28e4-96c5-1fc6-23e9c0cebb49@axentia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.15.0-3-amd64 User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 15, 2018 at 01:09:59PM +0200, Peter Rosin wrote: > On 2018-05-15 12:22, Daniel Vetter wrote: > > On Mon, May 14, 2018 at 10:40 PM, Peter Rosin wrote: > >> On 2018-05-14 18:28, Daniel Vetter wrote: > >>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote: > >>>> On 2018-05-10 10:10, Andrzej Hajda wrote: > >>>>> On 04.05.2018 15:52, Peter Rosin wrote: > >>>>>> If the bridge supplier is unbound, this will bring the bridge consumer > >>>>>> down along with the bridge. Thus, there will no longer linger any > >>>>>> dangling pointers from the bridge consumer (the drm_device) to some > >>>>>> non-existent bridge supplier. > >>>>>> > >>>>>> Signed-off-by: Peter Rosin > >>>>>> --- > >>>>>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++ > >>>>>> include/drm/drm_bridge.h | 2 ++ > >>>>>> 2 files changed, 20 insertions(+) > >>>>>> > >>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > >>>>>> index 78d186b6831b..0259f0a3ff27 100644 > >>>>>> --- a/drivers/gpu/drm/drm_bridge.c > >>>>>> +++ b/drivers/gpu/drm/drm_bridge.c > >>>>>> @@ -26,6 +26,7 @@ > >>>>>> #include > >>>>>> > >>>>>> #include > >>>>>> +#include > >>>>>> #include > >>>>>> > >>>>>> #include "drm_crtc_internal.h" > >>>>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge, > >>>>>> if (bridge->dev) > >>>>>> return -EBUSY; > >>>>>> > >>>>>> + if (encoder->dev->dev != bridge->odev) { > >>>>> > >>>>> I wonder why device_link_add does not handle this case (self dependency) > >>>>> silently as noop, as it seems to be a correct behavior. > >>>> > >>>> It's kind-of a silly corner-case though, so perfectly understandable > >>>> that it isn't handled. > >>>> > >>>>>> + bridge->link = device_link_add(encoder->dev->dev, > >>>>>> + bridge->odev, 0); > >>>>>> + if (!bridge->link) { > >>>>>> + dev_err(bridge->odev, "failed to link bridge to %s\n", > >>>>>> + dev_name(encoder->dev->dev)); > >>>>>> + return -EINVAL; > >>>>>> + } > >>>>>> + } > >>>>>> + > >>>>>> bridge->dev = encoder->dev; > >>>>>> bridge->encoder = encoder; > >>>>>> > >>>>>> if (bridge->funcs->attach) { > >>>>>> ret = bridge->funcs->attach(bridge); > >>>>>> if (ret < 0) { > >>>>>> + if (bridge->link) > >>>>>> + device_link_del(bridge->link); > >>>>>> + bridge->link = NULL; > >>>>>> bridge->dev = NULL; > >>>>>> bridge->encoder = NULL; > >>>>>> return ret; > >>>>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge) > >>>>>> if (bridge->funcs->detach) > >>>>>> bridge->funcs->detach(bridge); > >>>>>> > >>>>>> + if (bridge->link) > >>>>>> + device_link_del(bridge->link); > >>>>>> + bridge->link = NULL; > >>>>>> + > >>>>>> bridge->dev = NULL; > >>>>>> } > >>>>>> > >>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > >>>>>> index b656e505d11e..804189c63a4c 100644 > >>>>>> --- a/include/drm/drm_bridge.h > >>>>>> +++ b/include/drm/drm_bridge.h > >>>>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings { > >>>>>> * @list: to keep track of all added bridges > >>>>>> * @timings: the timing specification for the bridge, if any (may > >>>>>> * be NULL) > >>>>>> + * @link: drm consumer <-> bridge supplier > >>>>> > >>>>> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer > >>>>> to the bridge" would be better. > >>>> > >>>> I meant "<->" to indicate that the link is bidirectional, not that the > >>>> relationship is in any way symmetric. I wasn't aware of any implication > >>>> of a symmetric relationship when using "<->", do you have a reference? > >>>> But I guess the different arrow notations in math are somewhat overloaded > >>>> and that someone at some point must have used "<->" to indicate a > >>>> symmetric relationship... > >>> > >>> Yeah I agree with Andrzej here, for me <-> implies a symmetric > >>> relationship. Spelling it out like Andrzej suggested sounds like the > >>> better idea. > >>> -Daniel > >> > >> Ok, I guess that means I have to do a v3 after all. Or can this > >> trivial documentation update be done by the committer? I hate to > >> spam everyone with another volley... > >> > >> Or perhaps I should squash patches 2-23 that are all rather similar > >> and mechanic? I separated them to allow for easier review from > >> individual driver maintainers, but that didn't seem to happen > >> anyway... > > > > Do another volley of the full set, or in-reply-to to just replace the > > patch that needs to be respun (but some people don't like that). > > > > When resending just make sure you're picking up all the acks/r-bs you > > have already. > > Right, I always try to do that. One Ack that I did not include in v2 > was the one you had on v1 24/24 (i.e. this patch). The reason I did > not add your Ack for v2 even on the patch where it obviously applied > was that I didn't know if you'd barf on the odev name. > > But it was (and still is) a bit unclear if that was on Ack on the > last patch only, or if it was for the whole series? I think it might > have been for the whole series, but I'm not sure and I hate to be a > presumptuous idiot... Ack on the overall concept, and I'm ok with odev too. But definitely get acks from relevant people (bridge/driver maintainers). In terms of patches, I'd say patch 1 + 24-26 have my Acked-by: Daniel Vetter -Daniel > > Cheers, > Peter > > > -Daniel > >> Cheers, > >> Peter > >> > >>> > >>>> > >>>>> Anyway: > >>>>> Reviewed-by: Andrzej Hajda > >>>> > >>>> Thanks! > >>>> > >>>> Cheers, > >>>> Peter > >>>> > >>>>> -- > >>>>> Regards > >>>>> Andrzej > >>>>> > >>>>>> * @funcs: control functions > >>>>>> * @driver_private: pointer to the bridge driver's internal context > >>>>>> */ > >>>>>> @@ -271,6 +272,7 @@ struct drm_bridge { > >>>>>> struct drm_bridge *next; > >>>>>> struct list_head list; > >>>>>> const struct drm_bridge_timings *timings; > >>>>>> + struct device_link *link; > >>>>>> > >>>>>> const struct drm_bridge_funcs *funcs; > >>>>>> void *driver_private; > >>>>> > >>>>> > >>>> > >>> > >> > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel@ffwll.ch (Daniel Vetter) Date: Wed, 16 May 2018 11:31:10 +0200 Subject: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer In-Reply-To: References: <20180504135212.26977-1-peda@axentia.se> <20180504135212.26977-27-peda@axentia.se> <20180514162828.GE28661@phenom.ffwll.local> <73fa1ca3-28e4-96c5-1fc6-23e9c0cebb49@axentia.se> Message-ID: <20180516093110.GC3438@phenom.ffwll.local> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, May 15, 2018 at 01:09:59PM +0200, Peter Rosin wrote: > On 2018-05-15 12:22, Daniel Vetter wrote: > > On Mon, May 14, 2018 at 10:40 PM, Peter Rosin wrote: > >> On 2018-05-14 18:28, Daniel Vetter wrote: > >>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote: > >>>> On 2018-05-10 10:10, Andrzej Hajda wrote: > >>>>> On 04.05.2018 15:52, Peter Rosin wrote: > >>>>>> If the bridge supplier is unbound, this will bring the bridge consumer > >>>>>> down along with the bridge. Thus, there will no longer linger any > >>>>>> dangling pointers from the bridge consumer (the drm_device) to some > >>>>>> non-existent bridge supplier. > >>>>>> > >>>>>> Signed-off-by: Peter Rosin > >>>>>> --- > >>>>>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++ > >>>>>> include/drm/drm_bridge.h | 2 ++ > >>>>>> 2 files changed, 20 insertions(+) > >>>>>> > >>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > >>>>>> index 78d186b6831b..0259f0a3ff27 100644 > >>>>>> --- a/drivers/gpu/drm/drm_bridge.c > >>>>>> +++ b/drivers/gpu/drm/drm_bridge.c > >>>>>> @@ -26,6 +26,7 @@ > >>>>>> #include > >>>>>> > >>>>>> #include > >>>>>> +#include > >>>>>> #include > >>>>>> > >>>>>> #include "drm_crtc_internal.h" > >>>>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge, > >>>>>> if (bridge->dev) > >>>>>> return -EBUSY; > >>>>>> > >>>>>> + if (encoder->dev->dev != bridge->odev) { > >>>>> > >>>>> I wonder why device_link_add does not handle this case (self dependency) > >>>>> silently as noop, as it seems to be a correct behavior. > >>>> > >>>> It's kind-of a silly corner-case though, so perfectly understandable > >>>> that it isn't handled. > >>>> > >>>>>> + bridge->link = device_link_add(encoder->dev->dev, > >>>>>> + bridge->odev, 0); > >>>>>> + if (!bridge->link) { > >>>>>> + dev_err(bridge->odev, "failed to link bridge to %s\n", > >>>>>> + dev_name(encoder->dev->dev)); > >>>>>> + return -EINVAL; > >>>>>> + } > >>>>>> + } > >>>>>> + > >>>>>> bridge->dev = encoder->dev; > >>>>>> bridge->encoder = encoder; > >>>>>> > >>>>>> if (bridge->funcs->attach) { > >>>>>> ret = bridge->funcs->attach(bridge); > >>>>>> if (ret < 0) { > >>>>>> + if (bridge->link) > >>>>>> + device_link_del(bridge->link); > >>>>>> + bridge->link = NULL; > >>>>>> bridge->dev = NULL; > >>>>>> bridge->encoder = NULL; > >>>>>> return ret; > >>>>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge) > >>>>>> if (bridge->funcs->detach) > >>>>>> bridge->funcs->detach(bridge); > >>>>>> > >>>>>> + if (bridge->link) > >>>>>> + device_link_del(bridge->link); > >>>>>> + bridge->link = NULL; > >>>>>> + > >>>>>> bridge->dev = NULL; > >>>>>> } > >>>>>> > >>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > >>>>>> index b656e505d11e..804189c63a4c 100644 > >>>>>> --- a/include/drm/drm_bridge.h > >>>>>> +++ b/include/drm/drm_bridge.h > >>>>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings { > >>>>>> * @list: to keep track of all added bridges > >>>>>> * @timings: the timing specification for the bridge, if any (may > >>>>>> * be NULL) > >>>>>> + * @link: drm consumer <-> bridge supplier > >>>>> > >>>>> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer > >>>>> to the bridge" would be better. > >>>> > >>>> I meant "<->" to indicate that the link is bidirectional, not that the > >>>> relationship is in any way symmetric. I wasn't aware of any implication > >>>> of a symmetric relationship when using "<->", do you have a reference? > >>>> But I guess the different arrow notations in math are somewhat overloaded > >>>> and that someone at some point must have used "<->" to indicate a > >>>> symmetric relationship... > >>> > >>> Yeah I agree with Andrzej here, for me <-> implies a symmetric > >>> relationship. Spelling it out like Andrzej suggested sounds like the > >>> better idea. > >>> -Daniel > >> > >> Ok, I guess that means I have to do a v3 after all. Or can this > >> trivial documentation update be done by the committer? I hate to > >> spam everyone with another volley... > >> > >> Or perhaps I should squash patches 2-23 that are all rather similar > >> and mechanic? I separated them to allow for easier review from > >> individual driver maintainers, but that didn't seem to happen > >> anyway... > > > > Do another volley of the full set, or in-reply-to to just replace the > > patch that needs to be respun (but some people don't like that). > > > > When resending just make sure you're picking up all the acks/r-bs you > > have already. > > Right, I always try to do that. One Ack that I did not include in v2 > was the one you had on v1 24/24 (i.e. this patch). The reason I did > not add your Ack for v2 even on the patch where it obviously applied > was that I didn't know if you'd barf on the odev name. > > But it was (and still is) a bit unclear if that was on Ack on the > last patch only, or if it was for the whole series? I think it might > have been for the whole series, but I'm not sure and I hate to be a > presumptuous idiot... Ack on the overall concept, and I'm ok with odev too. But definitely get acks from relevant people (bridge/driver maintainers). In terms of patches, I'd say patch 1 + 24-26 have my Acked-by: Daniel Vetter -Daniel > > Cheers, > Peter > > > -Daniel > >> Cheers, > >> Peter > >> > >>> > >>>> > >>>>> Anyway: > >>>>> Reviewed-by: Andrzej Hajda > >>>> > >>>> Thanks! > >>>> > >>>> Cheers, > >>>> Peter > >>>> > >>>>> -- > >>>>> Regards > >>>>> Andrzej > >>>>> > >>>>>> * @funcs: control functions > >>>>>> * @driver_private: pointer to the bridge driver's internal context > >>>>>> */ > >>>>>> @@ -271,6 +272,7 @@ struct drm_bridge { > >>>>>> struct drm_bridge *next; > >>>>>> struct list_head list; > >>>>>> const struct drm_bridge_timings *timings; > >>>>>> + struct device_link *link; > >>>>>> > >>>>>> const struct drm_bridge_funcs *funcs; > >>>>>> void *driver_private; > >>>>> > >>>>> > >>>> > >>> > >> > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel at lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch