[02:47] *** lfam has left "Leaving"
[10:12] <pinchartl> javier__: can I assume that the tvp5150 patches that come from me have not been modified, or should I review them too ?
[10:21] <javier__> pinchartl: yes, they have not been modified besides simple changes to fix build issues due API changes
[10:21] <pinchartl> javier__: I'll trust you on that :-)
[10:21] <pinchartl> thank you
[10:22] <javier__> pinchartl: thanks to you
[12:29] *** zahari has quit IRC (Quit: WeeChat 1.3)
[15:29] <ndufresne> pinchartl: I started working on fixing bad stride with planar formats in uvc driver, I'd be interested to know if that approach is acceptable or not, http://paste.fedoraproject.org/307811/94120145/
[17:29] *** benjiG has left 
[18:45] *** tharvey has quit IRC (Ping timeout: 250 seconds)
[19:14] *** awalls has left 
[20:59] <pinchartl> ndufresne: yes that looks good to me
[21:01] <ndufresne> ok, will give it proper testing and then submit
[21:02] <ndufresne> pinchartl: about the probing performance, in the end the vendor provided us a new firmware, it take 200ms now to start, so not a priority anymore ;-P
[21:03] <pinchartl> I'd make the two parameters const
[21:03] <pinchartl> :-)
[21:03] <pinchartl> that's good because I don't remember the details of the issue ;-)
[21:03] <ndufresne> ok, taking note
[21:03] <ndufresne> pinchartl: haha
[21:04] <ndufresne> (for the record, when doing TRY_FMT with different parameter, we endup asking the same thing to the HW multiple time, because UVC parameteres are a subset of v4l2 parameters, solution could be more enumeration types in v4l2, or caching ...
[21:50] <javier__> pinchartl: I'm waiting for your answer to my latest comments about the delay / sleep API usage before posting a v2
[21:53] <pinchartl> javier__: no strong opinion, I'll let you decide
[21:54] <shuah> pinchartl
[21:55] <pinchartl> shuah: hi
[21:55] <javier__> pinchartl: Ok, I'll post the patches tomorrow then. Thanks a lot for your feedback!
[21:55] <shuah> We discussed this (I think before) - Managed media API need to hold struct device reference I think
[21:55] <pinchartl> shuah: yes, I wanted to discuss that with you. the current implementation is broken I believe
[21:55] <pinchartl> as media_device will be freed when the last device is unbound
[21:56] <pinchartl> which will race with userspace
[21:56] <shuah> I vaguely recall talking about it in Finland and I ran into it while I was testing the patch series I sent out
[21:56] <pinchartl> I think we'll have to do without devm_* and manage the reference count explicitly
[21:57] <shuah> We have to solve two issues I would think - one when media device is a non-devm resource
[21:57] <shuah> We need to be devm resource for alsa and media drivers to share it
[21:57] <pinchartl> why ?
[21:58] <pinchartl> can't we have a central media_device allocator/registry without devm ?
[21:58] <shuah> because ALSA and au0828 don't share any data structures
[21:58] <shuah> take a look at the patch series I just sent out and see what you think
[21:59] <pinchartl> which patch in particular ?
[22:00] <shuah> patch 18
[22:01] <shuah> and 26
[22:01] <pinchartl> ok, let me prototype what I'm talking about otherwise we'll spend hours discussing it without understanding each other :-)
[22:02] <pinchartl> (I have a feeling the night will be long...)
[22:02] <shuah> right - I will send you my current work in progress for you to check as well
[22:02] <shuah> It might be late for you so - we don't have to talk about it now