Hi Mauro, On Thursday 15 Dec 2016 15:08:26 Mauro Carvalho Chehab wrote: > Em Thu, 15 Dec 2016 16:26:19 +0100 Hans Verkuil escreveu: > >> Should all the entities stick around until all references to media > >> device are gone? If an application has /dev/media open, does that > >> mean all entities should not be free'd until this app. exits? What > >> should happen if an app. is streaming? Should the graph stay intact > >> until the app. exits? > > > > Yes, everything must stay around until the last user has disappeared. > > > > In general unplugs can happen at any time. So applications can be in the > > middle of an ioctl, and removing memory during that time is just > > impossible. > > > > On unplug you: > > > > 1) stop any HW DMA (highly device dependent) > > 2) wake up any filehandles that wait for an event > > 3) unregister any device nodes > > > > Then just sit back and wait for refcounts to go down as filehandles are > > closed by the application. > > > > Note: the v4l2/media/cec/IR/whatever core is typically responsible for > > rejecting any ioctls/mmap/etc. once the device node has been > > unregistered. The only valid file operation is release(). > > Agreed. The problem on OMAP3 is that it doesn't stop HW DMA when > struct media_devnode is released. It tries to do it later, when the > V4L2 core is unbind, by trying to dig into the media controller > struct that the driver removed before.
Note that stopping the hardware doesn't mean updating the pipeline state to mark it as stopped. Unlike stopping the hardware that is mandatory at unbind time as hardware access is not allowed after the unbind handler returns, how we handle the software state is entirely up to us. I'm not saying it can't be done at unbind time, but I'm not sure yet whether it should either. > That's said, for OMAP3 and all other drivers that don't support hot unplug, > I would just use suppress_bind_attrs, as I fail to see any need to allow > unbinding them. That's akin to breaking the thermometer to cure the patient from fever. I'm not completely opposed to making drivers non-unbindable in a case-by-case basis (and based on the author's will), but if a driver author wants to make a driver unbindable the core should allow that to be implemented. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
