From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Shuah Khan <shuahkh@osg.samsung.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Greg KH <greg@kroah.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>
Subject: Re: [PATCH RFC] omap3isp: prevent releasing MC too early
Date: Thu, 15 Dec 2016 10:57:16 -0200 [thread overview]
Message-ID: <20161215105716.30186ff5@vento.lan> (raw)
In-Reply-To: <e4f884d2-9746-a728-3f75-1aa211721f5e@osg.samsung.com>
Em Thu, 15 Dec 2016 09:42:35 -0300
Javier Martinez Canillas <javier@osg.samsung.com> escreveu:
> Hello Mauro,
>
> On 12/15/2016 09:37 AM, Mauro Carvalho Chehab wrote:
>
> [snip]
>
> >
> > What happens is that omap3isp driver calls media_device_unregister()
> > too early. Right now, it is called at omap3isp_video_device_release(),
> > with happens when a driver unbind is ordered by userspace, and not after
> > the last usage of all /dev/video?? devices.
> >
> > There are two possible fixes:
> >
> > 1) at omap3isp_video_device_release(), streamoff all streams and mark
> > that the media device will be gone.
I actually meant to say: isp_unregister_entities() here.
> >
> > 2) instead of using video_device_release_empty for the video->video.release,
> > create a omap3isp_video_device_release() that will call
> > media_device_unregister() when destroying the last /dev/video?? devnode.
> >
>
> There's also option (3), to have a proper refcounting to make sure that
> the media device node is not freed until all references to it are gone.
Yes, that's another alternative.
> I understand that's what Sakari's RFC patches do. I'll try to make some
> time tomorrow to test and review his patches.
The biggest problem with Sakari's patches is that it starts by
reverting 3 patches, and this will cause regressions on existing
devices.
Development should be incremental.
I didn't review carefully his series (as it started the wrong way),
but I guess there's another problem on it: as OMAP3 remove entities
at isp_unregister_entities(), while adding a kref to media_device
will prevent an oops, the streamoff logic won't work anymore, as
the entities that were supposed to be at the graph will have been
removed by then.
Ok, we can roll the snow ball and add kref's to entities and links,
but IMHO, we're trying to kill a fly with a death star: instead,
the better is to just fix the driver in a way that it would be
streaming off everything at isp_unregister_entities(), before
dropping the entities and the media controller.
Regards,
Mauro
next prev parent reply other threads:[~2016-12-15 12:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 15:14 [PATCH RFC] omap3isp: prevent releasing MC too early Mauro Carvalho Chehab
2016-12-15 12:13 ` Laurent Pinchart
2016-12-15 12:31 ` Greg KH
2016-12-15 15:07 ` Laurent Pinchart
2016-12-15 16:58 ` Mauro Carvalho Chehab
2016-12-15 12:37 ` Mauro Carvalho Chehab
2016-12-15 12:42 ` Javier Martinez Canillas
2016-12-15 12:57 ` Mauro Carvalho Chehab [this message]
2016-12-15 13:44 ` Greg KH
2016-12-15 14:17 ` Mauro Carvalho Chehab
2016-12-16 8:21 ` Sakari Ailus
2016-12-16 11:44 ` Sakari Ailus
2016-12-15 14:04 ` Laurent Pinchart
2016-12-16 11:18 ` Mauro Carvalho Chehab
2016-12-16 16:06 ` Laurent Pinchart
2016-12-15 13:24 ` Laurent Pinchart
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=20161215105716.30186ff5@vento.lan \
--to=mchehab@s-opensource.com \
--cc=greg@kroah.com \
--cc=javier@osg.samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=sakari.ailus@linux.intel.com \
--cc=shuahkh@osg.samsung.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.