From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Hajda Subject: Re: [RFC 1/2] core: Add generic object registry implementation Date: Wed, 05 Nov 2014 17:00:47 +0100 Message-ID: <545A49AF.9080901@samsung.com> References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.com> <545A19C8.6090508@samsung.com> <20141105140418.GA18067@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by gabe.freedesktop.org (Postfix) with ESMTP id 2170F6E97F for ; Wed, 5 Nov 2014 08:00:54 -0800 (PST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NEK006OEPY84I00@mailout1.w1.samsung.com> for dri-devel@lists.freedesktop.org; Wed, 05 Nov 2014 16:03:44 +0000 (GMT) In-reply-to: <20141105140418.GA18067@ulmo> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter List-Id: dri-devel@lists.freedesktop.org T24gMTEvMDUvMjAxNCAwMzowNCBQTSwgVGhpZXJyeSBSZWRpbmcgd3JvdGU6Cj4gT24gV2VkLCBO b3YgMDUsIDIwMTQgYXQgMDE6MzY6MjRQTSArMDEwMCwgQW5kcnplaiBIYWpkYSB3cm90ZToKPj4g T24gMTEvMDQvMjAxNCAwNToyOSBQTSwgVGhpZXJyeSBSZWRpbmcgd3JvdGU6Cj4+PiBGcm9tOiBU aGllcnJ5IFJlZGluZyA8dHJlZGluZ0BudmlkaWEuY29tPgo+Pj4KPj4+IEFkZCBhIGdlbmVyaWMg aW1wbGVtZW50YXRpb24gb2YgYW4gb2JqZWN0IHJlZ2lzdHJ5LiBUaGlzIHRhcmdldHMgZHJpdmVy cwo+Pj4gYW5kIHN1YnN5c3RlbXMgdGhhdCBwcm92aWRlIGF1eGlsaWFyeSBvYmplY3RzIHRoYXQg b3RoZXIgZHJpdmVycyBuZWVkIHRvCj4+PiBsb29rIHVwLiBUaGUgZ29hbCBpcyB0byBwdXQgdGhl IGRpZmZpY3VsdCBwYXJ0cyAoa2VlcCBvYmplY3QgcmVmZXJlbmNlcywKPj4+IG1vZHVsZSB1c2Fn ZSBjb3VudCwgLi4uKSBpbnRvIGNvcmUgY29kZSBzbyB0aGF0IGluZGl2aWR1YWwgc3Vic3lzdGVt cyBkbwo+Pj4gbm90IGhhdmUgdG8gZGVhbCB3aXRoIHRoZW0uCj4+Pgo+Pj4gVGhlIGludGVudGlv biBpcyBmb3Igc3Vic3lzdGVtcyB0byBpbnN0YW50aWF0ZSBhIHN0cnVjdCByZWdpc3RyeSBhbmQg dXNlCj4+PiBhIHN0cnVjdCByZWdpc3RyeV9yZWNvcmQgZW1iZWRkZWQgaW50byBhIHN1YnN5c3Rl bS1zcGVjaWZpYyBzdHJ1Y3R1cmUgdG8KPj4+IHByb3ZpZGUgYSBzdWJzeXN0ZW0tc3BlY2lmaWMg QVBJIGFyb3VuZCB0aGF0Lgo+Pgo+Pgo+PiBBcyBJIHVuZGVyc3RhbmQgeW91IHdhbnQgdG8gdXNl IHRoaXMgcmVnaXN0cnkgZm9yIHBhbmVscyBhbmQgYnJpZGdlcy4KPj4gQ291bGQgeW91IGV4cGxh aW4gdGhlIGlkZWEgYW5kIGRlc2NyaWJlIGV4YW1wbGUgc2NlbmFyaW8gd2hlbiB0aGVzZQo+PiBy ZWZjb3VudGluZ3MgYXJlIHVzZWZ1bC4gSSBndWVzcyBpdCBzaG91bGQgYmUgd2hlbiBwYW5lbCBh dHRhY2hlZCB0bwo+PiBkcm1kcnYgd2FudCB0byBkaXNhcHBlYXIuCj4gCj4gQ29ycmVjdC4gV2hl biBhIHBhbmVsIGRyaXZlciBpcyB1bmxvYWRlZCBpdCBmcmVlcyBtZW1vcnkgYXNzb2NpYXRlZCB3 aXRoCj4gdGhlIHBhbmVsLiBUaGUgZ29hbCBvZiB0aGlzIHJlZ2lzdHJ5IGlzIGZvciB0aGUgcGFu ZWwgb2JqZWN0IHRvIHN0YXkKPiBhcm91bmQgdW50aWwgYWxsIHJlZmVyZW5jZXMgYXJlIGdvbmUu Cj4gCj4+IFJlYWwgbGlmZXRpbWUgb2YgcGFuZWwgaXMgbGltaXRlZCBieSBwcm9iZS9yZW1vdmUg Y2FsbGJhY2tzIG9mIHBhbmVsCj4+IGRyaXZlciwgZG8geW91IHdhbnQgdG8gcHJvbG9uZyBpdCBi ZWhpbmQgdGhlc2UgbGltaXRzPwo+IAo+IFllcy4KPiAKPj4gRG8geW91IHdhbnQgdG8gaGF2ZSB6 b21iaWUgcGFuZWxzLCB3aXRob3V0IGhhcmR3YXJlIHRoZXkgYWJzdHJhY3Q/IEZvcgo+PiB3aGF0 IHB1cnBvc2U/Cj4gCj4gU28gdGhhdCBkaXNwbGF5IGRyaXZlcnMgZG9uJ3QgdHJ5IHRvIGFjY2Vz cyBvYmplY3RzIHRoYXQgaGF2ZSBiZWVuCj4gZnJlZWQuCgpXaHkgZG8gbm90IGp1c3QgcmVsZWFz ZSBwYW5lbCByZWZlcmVuY2VzIGZyb20gZHJtX2RldiwgSSBoYXZlCnN1Y2Nlc3NmdWxseSBpbXBs ZW1lbnRlZCBkc2kgcGFuZWxzIHRoaXMgd2F5LCB0aGFua3MgdG8gZHNpIGJ1cyBzcGVjaWZpYwph dHRhY2gvZGV0YWNoIGNhbGxiYWNrcyBhbmQgZHJtIGhvdHBsdWcgbWVjaGFuc2ltLgoKTXkgcG9p bnQgaXMgd2UgZG8gbm90IG5lZWQgdG8gbWFrZSB0aGUgd2hvbGUgdHJpY2t5IGRvdWJsZSByZWZj b3VudGluZywKd2l0aCB0b3RhbCByZWRlc2lnbiBvZiBwYW5lbHMsIHJldm9rZSwgem9tYmllcywg ZXRjLi4uLiBJdCBpcyBlbm91Z2ggdG8KaGF2ZSBqdXN0IGhvdCBwbHVnL3VucGx1ZyBjYWxsYmFj a3MuIFRoaXMgaXMgd2h5IEkgaGF2ZSBwcm9wb3NlZCBmZXcKbW9udGhzIGFnbyBpbnRlcmZhY2Vf dHJhY2tlciBmcmFtZXdvcmsuIEl0IGNhbiBhZGQgaG90KHVuKXBsdWcKY2FwYWJpbGl0eSBpbiBh IGdlbmVyaWMgd2F5IHRvIGFueSBmcmFtZXdvcmsuCgpSZWdhcmRzCkFuZHJ6ZWoKCgo+IAo+PiBX aGF0IGRvIHlvdSB3YW50IHRvIGRvIHdpdGggcGFuZWwgb3BzPyBEbyB0aGV5IG5lZWQgc3VwcG9y dCBib3RoIGxpZmUKPj4gc3RhdGVzPwo+IAo+IFRoYXQncyBhIHNsaWdodGx5IHNlcGFyYXRlIGlz c3VlIGZvciB3aGljaCBEYXZpZCBIZXJybWFubiBoYWQgYSBzb2x1dGlvbgo+IGluIG1pbmQuIEFz IEkgdW5kZXJzdGFuZCBpdCwgdGhlIGlkZWEgd291bGQgYmUgZm9yIHRoZXNlIG9iamVjdHMgdG8g Z2Fpbgo+IHJldm9rZSBzdXBwb3J0LiBUaGUgZ29hbCBpcyB0aGF0IG9uY2UgdGhlIHVuZGVybHlp bmcgb2JqZWN0IGRpc2FwcGVhcnMsCj4gY2FsbGluZyBhbnkgb2YgdGhlIG9wZXJhdGlvbnMgaW52 b2x2ZWQgd291bGQgZmFpbCAod2l0aCBzb21ldGhpbmcgbGlrZSBhCj4gLUVOT0RFVikuIEl0J3Mg YSBsaXR0bGUgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoYXQgYmVjYXVzZSB0aGUgZGV2aWNlCj4g Y291bGQgZGlzYXBwZWFyIHJpZ2h0IGluIHRoZSBtaWRkbGUgb2Ygc3VjaCBhbiBvcGVyYXRpb24s IGJ1dCB0aGF0J3MKPiBwcmVjaXNlbHkgd2hhdCByZXZva2Ugc2hvdWxkIGFsbG93IHVzIHRvIGRv LiBSZWFkZGluZyBEYXZpZCBmb3IKPiB2aXNpYmlsaXR5Lgo+IAo+PiBBbnl3YXkgaW1wbGVtZW50 YXRpb24gY3VycmVudGx5IHNlZW1zIHRvIGJlIGJyb2tlbiwKPiAKPiBEUk0gcGFuZWxzIGFyZSBj dXJyZW50bHkgY29tcGxldGVseSBicm9rZW4uIElmIHlvdSByZW1vdmUgdGhlIGRyaXZlciBmb3IK PiBhIHBhbmVsIHRoZSBkaXNwbGF5IGRyaXZlciB0aGF0IHVzZXMgdGhpcyBwYW5lbCB3aWxsIHNp bXBseSBjcmFzaCB0aGUKPiBuZXh0IHRpbWUgaXQgdHJpZXMgdG8gZG8gYW55dGhpbmcgd2l0aCB0 aGUgcGFuZWwuIFRoaXMgdHlwZSBvZiByZWdpc3RyeQo+IGlzIHRoZSBmaXJzdCBzdGVwIGluIHRy eWluZyB0byBmaXggdGhpcy4KPiAKPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHlvdSB0cnkgdG8gcmVmY291bnQKPj4gb2JqZWN0cyB3aGljaCBh cmUgdXN1YWxseSBlbWJlZGRlZCBpbiBkcml2ZXIgcHJpdiBkYXRhLCB3aGljaCBkaXNhcHBlYXJz Cj4+IGR1cmluZyByZW1vdmUgY2FsbGJhY2sgb2YgdGhlIGRyaXZlci4KPiAKPiBBIHNlY29uZCBz dGVwIGluIGZpeGluZyB0aGlzIHdpbGwgYmUgdG8gY29udmVydCBkcml2ZXJzIHRvIG5vIGxvbmdl cgo+IGZyZWUgdGhlIHBhbmVsIGJ1dCByYXRoZXIgZHJvcCB0aGVpciByZWZlcmVuY2UgdG8gdGhl IHBhbmVsIHRoYXQgdGhleSd2ZQo+IHJlZ2lzdGVyZWQuIFRoaXMgd2lsbCBtYWtlIHN1cmUgdGhh dCBtZW1vcnkgZG9lc24ndCBnZXQgZnJlZWQgdW50aWwgYWxsCj4gcmVmZXJlbmNlcyBhcmUgZ29u ZS4KPiAKPiBOb3RlIHRoYXQgdGhpcyBtZWFucyB0aGF0IGRyaXZlcnMgd2lsbCBhbHNvIG5lZWQg dG8gYmUgY29udmVydGVkIG5vdCB0bwo+IHVzZSBkZXZtXyogaGVscGVycyBzaW5jZSB0aGF0IGNv bmZsaWN0cyB3aXRoIHRoZSByZWZlcmVuY2UgY291bnRlZCBsaWZlLQo+IHRpbWVzIG9mIHRoZXNl IHJlY29yZCBvYmplY3RzLgo+IAo+IFRoaWVycnkKPiAKPiAKPiAKPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QK PiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cDovL2xpc3RzLmZyZWVkZXNr dG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo+IAoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmkt ZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcv 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 S1754896AbaKEQA4 (ORCPT ); Wed, 5 Nov 2014 11:00:56 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:48807 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754004AbaKEQAx (ORCPT ); Wed, 5 Nov 2014 11:00:53 -0500 X-AuditID: cbfec7f5-b7f956d000005ed7-8d-545a49b2891a Message-id: <545A49AF.9080901@samsung.com> Date: Wed, 05 Nov 2014 17:00:47 +0100 From: Andrzej Hajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-version: 1.0 Newsgroups: gmane.comp.video.dri.devel,gmane.linux.kernel To: Thierry Reding Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter Subject: Re: [RFC 1/2] core: Add generic object registry implementation References: <1415118568-18771-1-git-send-email-thierry.reding@gmail.com> <545A19C8.6090508@samsung.com> <20141105140418.GA18067@ulmo> In-reply-to: <20141105140418.GA18067@ulmo> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsVy+t/xK7qbPKNCDE43GVssfHiX2eLK1/ds Fs2L17NZXN41h83i5655LA6sHnu/LWDx2DnrLrvH/rlr2D3udx9n8vi8SS6ANYrLJiU1J7Ms tUjfLoErY9vP58wF2+Qqnn/uYm5g7JDoYuTgkBAwkbjaa9HFyAlkiklcuLeerYuRi0NIYCmj xIPmRmaQhJDAJ0aJWZssQWxeAS2Jth+P2EFsFgFVie3nN7OA2GwCmhJ/N99kA7FFBSIkrqyZ wwhRLyjxY/I9sBo+AUuJY0s6wXpFBHQl/p9+wwKyjFlgHqPEvsMPwIqEBdwl7q28xghxRTuj xLmvcxlBLuUE2jy9JQLEZBZQl5gyJReknFlAXmLzmrfMExgFZyFZNwuhahaSqgWMzKsYRVNL kwuKk9JzjfSKE3OLS/PS9ZLzczcxQoL86w7GpcesDjEKcDAq8fB6NEWGCLEmlhVX5h5ilOBg VhLh5XSOChHiTUmsrEotyo8vKs1JLT7EyMTBKdXAuEOlWIy94P7tdu/Vu/YKS2969H35wU6d oKbqy7OUYzbVpdjXMRT6X82sm80+79vXgG2WE7YuWqASmzHb8oXqthObVU5N9dGKe/KkIKP2 hpL91MZH787+3rXMZPnq00Usx1p/znurbGU6Zfuf0psT73/8xrXezvJg7L7mq+tVSotf7rz0 Zaek4yElluKMREMt5qLiRAAFqbVVUAIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/05/2014 03:04 PM, Thierry Reding wrote: > On Wed, Nov 05, 2014 at 01:36:24PM +0100, Andrzej Hajda wrote: >> On 11/04/2014 05:29 PM, Thierry Reding wrote: >>> From: Thierry Reding >>> >>> Add a generic implementation of an object registry. This targets drivers >>> and subsystems that provide auxiliary objects that other drivers need to >>> look up. The goal is to put the difficult parts (keep object references, >>> module usage count, ...) into core code so that individual subsystems do >>> not have to deal with them. >>> >>> The intention is for subsystems to instantiate a struct registry and use >>> a struct registry_record embedded into a subsystem-specific structure to >>> provide a subsystem-specific API around that. >> >> >> As I understand you want to use this registry for panels and bridges. >> Could you explain the idea and describe example scenario when these >> refcountings are useful. I guess it should be when panel attached to >> drmdrv want to disappear. > > Correct. When a panel driver is unloaded it frees memory associated with > the panel. The goal of this registry is for the panel object to stay > around until all references are gone. > >> Real lifetime of panel is limited by probe/remove callbacks of panel >> driver, do you want to prolong it behind these limits? > > Yes. > >> Do you want to have zombie panels, without hardware they abstract? For >> what purpose? > > So that display drivers don't try to access objects that have been > freed. Why do not just release panel references from drm_dev, I have successfully implemented dsi panels this way, thanks to dsi bus specific attach/detach callbacks and drm hotplug mechansim. My point is we do not need to make the whole tricky double refcounting, with total redesign of panels, revoke, zombies, etc.... It is enough to have just hot plug/unplug callbacks. This is why I have proposed few months ago interface_tracker framework. It can add hot(un)plug capability in a generic way to any framework. Regards Andrzej > >> What do you want to do with panel ops? Do they need support both life >> states? > > That's a slightly separate issue for which David Herrmann had a solution > in mind. As I understand it, the idea would be for these objects to gain > revoke support. The goal is that once the underlying object disappears, > calling any of the operations involved would fail (with something like a > -ENODEV). It's a little more complicated than that because the device > could disappear right in the middle of such an operation, but that's > precisely what revoke should allow us to do. Readding David for > visibility. > >> Anyway implementation currently seems to be broken, > > DRM panels are currently completely broken. If you remove the driver for > a panel the display driver that uses this panel will simply crash the > next time it tries to do anything with the panel. This type of registry > is the first step in trying to fix this. > >> you try to refcount >> objects which are usually embedded in driver priv data, which disappears >> during remove callback of the driver. > > A second step in fixing this will be to convert drivers to no longer > free the panel but rather drop their reference to the panel that they've > registered. This will make sure that memory doesn't get freed until all > references are gone. > > Note that this means that drivers will also need to be converted not to > use devm_* helpers since that conflicts with the reference counted life- > times of these record objects. > > Thierry > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >