On 11/06/2014 10:48 AM, Thierry Reding wrote: > On Wed, Nov 05, 2014 at 05:00:47PM +0100, Andrzej Hajda wrote: >> 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 <treding at nvidia.com> >>>>> >>>>> 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. > > Like you say yourself, that's something that work only for DSI. Any > other type of panel can't do this.
But it means that if we want to make panels safe we just need add registration/deregistration notifications to panels, nothing more. > >> My point is we do not need to make the whole tricky double refcounting, > > There's no double refcounting. We have no refcounting at all at the > moment. For me registry_record.kref and try_module_get sounds like refcounting. > >> with total redesign of panels, revoke, zombies, etc.... It is enough to > > It's not a total redesign. It just makes it more mature and implements > features that I think are useful (and needed) but that were left out for > the sake of simplicity. Now it turns out that this is actually quite > fragile and easy to get wrong. And I try to convince you we can still keep simplicity and make it safe. > >> 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. > > That's something that this object registry could easily implement as > well. But instead of passing around void * and type IDs as in the > interface tracker it could deal with real objects for proper type- > safety. It is not a problem to add type-safe helpers to interface tracker. Regards Andrzej > > Thierry > > > > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
