hverkuil, mchehab, pinchartl, sailus: Hi :)
anyone willing to take a look at the OV5645 sensor driver?
http://www.mail-archive.com/linux-media@vger.kernel.org/msg99395.html
ttomov: Hello!!!
How do you do? :-)
It's been some time...
sailus: it would be great if you could review it. Laurent is away for another week I think.
hverkuil: Sure. I'll do that later today.
I noticed I need to rework the RFC v2 set of my media reference patchset quite a lot.
I liked v2 much better than v1.
:-)
Then you'll be positively surprised of v3 I hope. :-)
sailus: note that the way video_device_alloc/register works in V4L2 is also wrong: it should use the same sequence as cec and your patches do.
We need to fix that in the future as well.
v4l-subdevX probably has the same issues as well.
Let me see if I could reasonably fit it into this set. I'm not sure currently. It's pretty big already.
No, don't combine it. One thing at a time :-)
With the current set, the omap3isp driver releases video device memory when the media device goes away. I think it might just work as such correctly. I haven't checked that thoroughly, I have to say.
How come writing patches is so difficult?
because building a custom kernel for the first time is really time consuming, perhaps.
awalls: This is on a mainline kernel.
Perhaps it is because my mother tongue is not C?
I would be concerned if it were. :)
I'm still waiting for a computer language/compiler that know what I intended, not what I wrote.
*knows
It already exists and it's known as Perl.
:)
Well that's bad news for me.  Years ago, when I collected personal metrics, between Ada, Perl, and C++ my defect rate was highest with Perl and the defects were found later in the development cycle. :(
:-o
s/I intended/Perl intended/
hverkuil: Speaking of references.
I've changed the patches to take a reference to struct device (struct media_device.dev) in order to keep it around. It may be used e.g. for debug prints once the actual physical device has disappeared, so it's the right thing to do.
So this brings the interesting possibility of using that struct device for driver's resource management: when the managed resources are released, the media_device is long gone by then.
managed resources are not coupled to the device lifetime
they are release on remove()
not on release()
larsc: If you have a driver, yes.
Uh, yes, indeed.
So we do rely on release() then.