All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [RFC 1/2] core: Add generic object registry implementation
Date: Thu, 6 Nov 2014 10:48:22 +0100	[thread overview]
Message-ID: <20141106094820.GH26297@ulmo> (raw)
In-Reply-To: <545A49AF.9080901@samsung.com>


[-- Attachment #1.1: Type: text/plain, Size: 2891 bytes --]

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@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.

> 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.

> 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.

> 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.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [RFC 1/2] core: Add generic object registry implementation
Date: Thu, 6 Nov 2014 10:48:22 +0100	[thread overview]
Message-ID: <20141106094820.GH26297@ulmo> (raw)
In-Reply-To: <545A49AF.9080901@samsung.com>

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

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@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.

> 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.

> 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.

> 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.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-11-06  9:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04 16:29 [RFC 1/2] core: Add generic object registry implementation Thierry Reding
2014-11-04 16:29 ` Thierry Reding
2014-11-04 16:29 ` [RFC 2/2] drm/panel: Use generic object registry Thierry Reding
2014-11-04 16:29   ` Thierry Reding
2014-11-04 16:38 ` [RFC 1/2] core: Add generic object registry implementation Greg Kroah-Hartman
2014-11-04 16:38   ` Greg Kroah-Hartman
2014-11-05  9:13   ` Thierry Reding
2014-11-05  9:13     ` Thierry Reding
2014-11-06  2:18     ` Greg Kroah-Hartman
2014-11-06  2:18       ` Greg Kroah-Hartman
2014-11-06 10:25       ` Thierry Reding
2014-11-06 10:25         ` Thierry Reding
2014-11-06 16:13         ` Thierry Reding
2014-11-06 16:13           ` Thierry Reding
2014-11-07 16:31           ` Greg Kroah-Hartman
2014-11-07 16:31             ` Greg Kroah-Hartman
2014-11-05 12:36 ` Andrzej Hajda
2014-11-05 12:36   ` Andrzej Hajda
2014-11-05 14:04   ` Thierry Reding
2014-11-05 14:04     ` Thierry Reding
2014-11-05 16:00     ` Andrzej Hajda
2014-11-05 16:00       ` Andrzej Hajda
2014-11-06  9:48       ` Thierry Reding [this message]
2014-11-06  9:48         ` Thierry Reding
2014-11-07  9:10         ` Andrzej Hajda
2014-11-07  9:10           ` Andrzej Hajda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141106094820.GH26297@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=a.hajda@samsung.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.