#v4l 2017-03-10,Fri

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***prabhakarlad has left [10:10]
....... (idle for 33mn)
larscneg: do you know waht happend to this patch https://patchwork.kernel.org/patch/9201075/ [10:43]
.... (idle for 19mn)
neglarsc: still in prototype stage I'm afraid, it needs some more work to model the different CSI-2 transmitters as two subdevices but controlled by the same instance of the driver and some cleanups before it is ready for upstream
And reworking it to expose more then one subdevice will requier some work to the async framework to allow two different downstream drivers to be able to find and bind to the two subdevices from the DT graph
The patch is not abandoned and I think someone (not me probobly) will take up that patch and continue to work on in the near future
[11:02]
hverkuilsailus: ping [11:13]
larscneg: ok thanks [11:21]
neglarsc: do you have a use-case for the driver or other interest? [11:24]
hverkuilsailus: mailed a follow up to the atmel-isi of handling. Please take a look. [11:26]
larscneg: maybe
neg: somebody asked about it
[11:33]
...... (idle for 29mn)
sailushverkuil: Btw. on patch "[media] v4l2-mc: add a function to inherit controls from a pipeline" which you commented --- the entities in the pipeline are dynamic whereas the controls are present in the control handler as long as the handler exists.
Also, sub-devices should be powered up first before the controls in them are accessed. Well, you just get an error as a result, but the user space should expect things just to work.
Besides that, I question whether this is the right thing to do in the first place on devices with MC interface. Other drivers do not do that, and there are reasons for it.
[12:02]
hverkuilreading up on the v4 comments for this patch. [12:08]
sailushverkuil: Leaving the office now, have a nice week-end! :-) [12:16]
.................... (idle for 1h37mn)
***prabhakarlad has left [13:53]
pinchartlhverkuil: I second Sakari's opinion here, we shouldn't merge that without carefully and thoroughly thinking about it
(and not before I have a chance to participate in the discussion when I'll be back on the 26th please)
[13:57]
...................... (idle for 1h48mn)
memekasorry ndufresne
how to trace videobuf? i have CONFIG_VIDEO_ADV_DEBUG
[15:45]
ndufresneecho 0xff > /sys/module/videobuf2_core/parameters/debug [15:48]
memekandufresne: http://paste.debian.net/919145/ [15:51]
ndufresnememeka: can't you read you own logs ? [15:52]
memekandufresne: i can't see anything wrong [15:53]
ndufresnememeka: so then it's not failing in videobuf2
must be returning EINVAL somewhere in GSC driver then
memeka: 10 cent trick, just grep the code for EINVAL
[15:55]
memeka-22
k
[15:56]
ndufresneEINVAL == 22, and driver would return -EINVAL [15:57]
memeka[15553.718446] video2: VIDIOC_QUERYCTRL: error -22: id=0x80980929, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000 [15:59]
.... (idle for 15mn)
ndufresne(unrelated, that probably the result of the probing process) [16:14]
......... (idle for 43mn)
syoungmchehab: my rc pull request will cause conflicts with the recent fixes, please do not pull it yet. I'll rebase it once those fixes have made it into linuxtv/master [16:57]
................... (idle for 1h31mn)
mchehabsyoung: better to change its status then at patchwork ;) [18:28]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)