From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jyri Sarha <jsarha@ti.com>
Cc: tomi.valkeinen@ti.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/drm_bridge: adjust bridge module's refcount
Date: Wed, 30 Nov 2016 11:30:12 +0200 [thread overview]
Message-ID: <9141562.dZ90ZYOVl1@avalon> (raw)
In-Reply-To: <4a502ab4-1f89-15b3-fbd9-5f582999faac@ti.com>
Hi Jyri,
On Wednesday 30 Nov 2016 11:13:41 Jyri Sarha wrote:
> On 11/30/16 11:03, Laurent Pinchart wrote:
> >>> This would require combining lookup and attach in all cases. I'm not
> >>> sure
> >>>
> >>>>> that would be very convenient for drivers. Keeping the two
> >>>>> operations separate would be more flexible.
> >>>
> >>> That could be avoided if of_drm_find_bridge() would copy the content of
> >>> bridge object, in stead of providing a pointer.
> >
> > /me shivers
> >
> >>> The attach call could then search for the bridge object again before
> >>> continuing. But still in the end the impact to individual drivers would
> >>> be equal to adding a simple drm_bridge_put() call. Probably better to go
> >>> forward with your suggestion.
> >
> > Please :-)
>
> Ok :). But first I'll make a pull request of all accumulated tilcdc
> patches, as all problems I have found in them are to be fixed outside
> tilcdc.
Sure.
> >>> Even adding the drm_bridge_put() would not be necessary in most cases
> >>> if we would add a devm version of getting the bridge object. In 99% of
> >>> cases the device probe will fail if the bridge attach fails, and bridge
> >>> object refcount would return to zero automatically.
> >
> > devm_* is evil in most cases, especially the devm_kzalloc() function as it
> > ties object lifetime to devices, releasing memory at unbind time when the
> > object can still be referenced elsewhere. Regarding bridges, a
> > devm_of_drm_find_bridge() might make sense as the bridge seems at first
> > glance to (nearly) always be a resource that can be released at DRM
> > unbind time.
>
> But the devm is not at all as evil when the object is refcounted,
> because every piece of code that wants to keep a reference to the object
> can keep it.
devm_* is fine when allocating a resources that is release at device unbind
time. I/O regions, IRQ, and most probably bridges (I'd have to sleep over that
last one) should fall in that category, at least most of the time.
devm_kzalloc() is evil in the sense that many driver authors use it as a
solution to world hunger without thinking twice, while memory allocated by
drivers for objects that are registered and must outlive the lifetime of the
device binding is not a resource consumed by the driver that can be released
at unbind time.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-11-30 9:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20161129211315epcas3p2a805abe8449509312f481ab7dcea96ef@epcas3p2.samsung.com>
2016-11-29 21:12 ` [PATCH] drm/drm_bridge: adjust bridge module's refcount Jyri Sarha
2016-11-29 21:30 ` Jyri Sarha
2016-11-29 22:06 ` Laurent Pinchart
2016-11-30 8:13 ` Daniel Vetter
2016-11-30 8:25 ` Laurent Pinchart
2016-11-30 9:12 ` Daniel Vetter
2016-11-30 9:56 ` Laurent Pinchart
2016-11-30 10:55 ` Daniel Vetter
2016-11-30 11:03 ` Laurent Pinchart
2016-11-30 13:09 ` Daniel Vetter
2016-12-01 7:07 ` Andrzej Hajda
2016-12-01 7:18 ` Daniel Vetter
2016-12-01 13:22 ` Andrzej Hajda
2016-12-01 15:12 ` Daniel Vetter
2016-12-02 6:49 ` Andrzej Hajda
2016-11-30 8:32 ` Jyri Sarha
2016-11-30 8:37 ` Laurent Pinchart
2016-11-30 8:55 ` Jyri Sarha
2016-11-30 9:03 ` Laurent Pinchart
2016-11-30 9:13 ` Jyri Sarha
2016-11-30 9:30 ` Laurent Pinchart [this message]
2016-11-30 8:11 ` Andrzej Hajda
2016-11-30 8:16 ` Laurent Pinchart
2016-11-30 9:26 ` Andrzej Hajda
2016-11-30 9:39 ` Laurent Pinchart
2016-12-01 6:50 ` 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=9141562.dZ90ZYOVl1@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=tomi.valkeinen@ti.com \
/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.