From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge. Date: Tue, 20 Jun 2017 10:31:19 +0300 Message-ID: <1625582.5PxmiBkabx@avalon> References: <20170615204130.19255-1-eric@anholt.net> <871sqkouvr.fsf@eliezer.anholt.net> <8e148170-b626-b426-3c94-b93d2746f4ce@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <8e148170-b626-b426-3c94-b93d2746f4ce@codeaurora.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Archit Taneja Cc: Mark Rutland , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , Thierry Reding , dri-devel@lists.freedesktop.org List-Id: devicetree@vger.kernel.org SGkgQXJjaGl0LAoKT24gVHVlc2RheSAyMCBKdW4gMjAxNyAwOToxODowMCBBcmNoaXQgVGFuZWph IHdyb3RlOgo+IE9uIDA2LzE2LzIwMTcgMDg6MTMgUE0sIEVyaWMgQW5ob2x0IHdyb3RlOgo+ID4g QXJjaGl0IFRhbmVqYSA8YXJjaGl0dEBjb2RlYXVyb3JhLm9yZz4gd3JpdGVzOgo+ID4+IE9uIDA2 LzE2LzIwMTcgMDI6MTEgQU0sIEVyaWMgQW5ob2x0IHdyb3RlOgo+ID4+PiBJZiB0aGUgcGFuZWwt YnJpZGdlIGlzIGJlaW5nIHNldCB1cCBhZnRlciB0aGUgZHJtX21vZGVfY29uZmlnX3Jlc2V0KCks Cj4gPj4+IHRoZW4gdGhlIGNvbm5lY3RvcidzIHN0YXRlIHdvdWxkIG5ldmVyIGdldCBpbml0aWFs aXplZCwgYW5kIHdlJ2QKPiA+Pj4gZGVyZWZlcmVuY2UgdGhlIE5VTEwgaW4gdGhlIGhvdHBsdWcg cGF0aC4gIFdlIGFsc28gbmVlZCB0byByZWdpc3Rlcgo+ID4+PiB0aGUgY29ubmVjdG9yLCBzbyB0 aGF0IHVzZXJzcGFjZSBjYW4gZ2V0IGF0IGl0Lgo+ID4+IAo+ID4+IFNob3VsZG4ndCB0aGUgS01T IGRyaXZlciBtYWtlIHN1cmUgdGhlIHBhbmVsLWJyaWRnZSBpcyBzZXQgdXAgYmVmb3JlCj4gPj4g ZHJtX21vZGVfY29uZmlnX3Jlc2V0PyBJcyBpdCB0aGUgY2FzZSB3aGVuIHdlJ3JlIGluc2VydGlu ZyB0aGUKPiA+PiBwYW5lbC1icmlkZ2UgZHJpdmVyIGFzIGEgbW9kdWxlPwo+ID4+IAo+ID4+IAo+ ID4+IEFsbCB0aGUgY29ubmVjdG9ycyB0aGF0IGhhdmUgYmVlbiBhZGRlZCBhcmUgcmVnaXN0ZXJl ZCBhdXRvbWF0aWNhbGx5Cj4gPj4gd2hlbiBkcm1fZGV2X3JlZ2lzdGVyKCkgaXMgY2FsbGVkIGJ5 IHRoZSBLTVMgZHJpdmVyLiBSZWdpc3RlcmluZyBhCj4gPj4gY29ubmVjdG9yIGluIHRoZSBtaWRk bGUgb2Ygc2V0dGluZyB1cCBvdXIgZHJpdmVyIGlzIHByb25lIHRvIHJhY2UKPiA+PiBjb25kaXRp b25zIGlmIHRoZSB1c2Vyc3BhY2UgZGVjaWRlcyB0byB1c2UgdGhlbSBpbW1lZGlhdGVseS4KPiA+ IAo+ID4gWWVhaCwgdGhpcyBpcyBmaXhpbmcgaW5pdGlhbGl6aW5nIHBhbmVsX2JyaWRnZSBhdCBE U0kgaG9zdF9hdHRhY2ggdGltZSwKPiA+IHdoaWNoIGluIHRoZSBjYXNlIG9mIGEgcGFuZWwgbW9k dWxlIHRoYXQgY3JlYXRlcyB0aGUgRFNJIGRldmljZQo+ID4gKGFkdjc1MzMtc3R5bGUsIGxpa2Ug eW91IHNhaWQgSSBzaG91bGQgdXNlIGFzIGEgcmVmZXJlbmNlKSB3aWxsIGJlIGFmdGVyCj4gPiBk cm1fbW9kZV9jb25maWdfcmVzZXQoKSBhbmQgZHJtX2Rldl9yZWdpc3RlcigpLgo+IAo+IE9rYXku IEluIHRoZSBjYXNlIG9mIHRoZSBtc20ga21zIGRyaXZlciwgd2UgZGVmZXIgcHJvYmUgdW50aWwg dGhlCj4gYWR2NzUzMyBtb2R1bGUgaXMgaW5zZXJ0ZWQsIG9ubHkgdGhlbiB3ZSBwcm9jZWVkIHRv IGRybV9tb2RlX2NvbmZpZ19yZXNldCgpCj4gYW5kIGRybV9kZXZfcmVnaXN0ZXIoKS4gSSBhc3N1 bWVkIHRoaXMgd2FzIHRoZSBnZW5lcmFsIHByYWN0aWNlIGZvbGxvd2VkIGJ5Cj4gbW9zdCBrbXMg ZHJpdmVycy4gSS4sZSB0aGUga21zIGRyaXZlciBkZWZlcnMgcHJvYmUgdW50aWwgYWxsIGNvbm5l Y3Rvcgo+IHJlbGF0ZWQgbW9kdWxlcyBhcmUgaW5zZXJ0ZWQsIGFuZCBvbmx5IHRoZW4gcHJvY2Vl ZCB0byBjcmVhdGUgYSBkcm0gZGV2aWNlLgoKSSdkIGxvdmUgdG8gc2VlIHN1cHBvcnQgZm9yIGEg bW9yZSBkeW5hbWljIGFwcHJvYWNoIHRoYXQgd291bGQgYWxsb3cgCnJlZ2lzdGVyaW5nIG91dHB1 dHMgYXQgcnVudGltZS4gVW50aWwgdGhhdCdzIGltcGxlbWVudGVkLCBob3dldmVyLCBJIGFncmVl IAp3aXRoIHlvdXIgc3RhdGVtZW50LCBkcml2ZXJzIHNob3VsZCB3YWl0IHVudGlsIGFsbCBjb21w b25lbnRzIGFyZSBhdmFpbGFibGUgCmJlZm9yZSByZWdpc3RlcmluZyB0aGUgRFJNIGRldmljZS4K Cj4gRmVlZGJhY2sgZnJvbSBvdGhlcnMgb24gdGhpcyB3b3VsZCBiZSBhcHByZWNpYXRlZCwgdGhv dWdoLgoKLS0gClJlZ2FyZHMsCgpMYXVyZW50IFBpbmNoYXJ0CgpfX19fX19fX19fX19fX19fX19f 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 S1751146AbdFTHar (ORCPT ); Tue, 20 Jun 2017 03:30:47 -0400 Received: from galahad.ideasonboard.com ([185.26.127.97]:49301 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbdFTHap (ORCPT ); Tue, 20 Jun 2017 03:30:45 -0400 From: Laurent Pinchart To: Archit Taneja Cc: Eric Anholt , dri-devel@lists.freedesktop.org, Andrzej Hajda , Thierry Reding , Rob Herring , Mark Rutland , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge. Date: Tue, 20 Jun 2017 10:31:19 +0300 Message-ID: <1625582.5PxmiBkabx@avalon> User-Agent: KMail/4.14.10 (Linux/4.9.16-gentoo; KDE/4.14.32; x86_64; ; ) In-Reply-To: <8e148170-b626-b426-3c94-b93d2746f4ce@codeaurora.org> References: <20170615204130.19255-1-eric@anholt.net> <871sqkouvr.fsf@eliezer.anholt.net> <8e148170-b626-b426-3c94-b93d2746f4ce@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Archit, On Tuesday 20 Jun 2017 09:18:00 Archit Taneja wrote: > On 06/16/2017 08:13 PM, Eric Anholt wrote: > > Archit Taneja writes: > >> On 06/16/2017 02:11 AM, Eric Anholt wrote: > >>> If the panel-bridge is being set up after the drm_mode_config_reset(), > >>> then the connector's state would never get initialized, and we'd > >>> dereference the NULL in the hotplug path. We also need to register > >>> the connector, so that userspace can get at it. > >> > >> Shouldn't the KMS driver make sure the panel-bridge is set up before > >> drm_mode_config_reset? Is it the case when we're inserting the > >> panel-bridge driver as a module? > >> > >> > >> All the connectors that have been added are registered automatically > >> when drm_dev_register() is called by the KMS driver. Registering a > >> connector in the middle of setting up our driver is prone to race > >> conditions if the userspace decides to use them immediately. > > > > Yeah, this is fixing initializing panel_bridge at DSI host_attach time, > > which in the case of a panel module that creates the DSI device > > (adv7533-style, like you said I should use as a reference) will be after > > drm_mode_config_reset() and drm_dev_register(). > > Okay. In the case of the msm kms driver, we defer probe until the > adv7533 module is inserted, only then we proceed to drm_mode_config_reset() > and drm_dev_register(). I assumed this was the general practice followed by > most kms drivers. I.,e the kms driver defers probe until all connector > related modules are inserted, and only then proceed to create a drm device. I'd love to see support for a more dynamic approach that would allow registering outputs at runtime. Until that's implemented, however, I agree with your statement, drivers should wait until all components are available before registering the DRM device. > Feedback from others on this would be appreciated, though. -- Regards, Laurent Pinchart