| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| tfiga_ | Hi pinchartl, are you online? | [08:41] |
| headless | tfiga_: gone till 3/26, /whois says
he called that holidays :-) | [08:44] |
| tfiga_ | headless: mhm, I see, thanks :) | [08:46] |
| ....... (idle for 33mn) | ||
| hverkuil | sailus: ping | [09:19] |
| .... (idle for 17mn) | ||
| sailus: ping (sorry, need your help with the atmel-isi driver and of behavior.) | [09:36] | |
| benjiG | hverkuil: hello, may I ask you what is the status of CEC patches ? | [09:44] |
| hverkuil | Waiting for me to have time to rework them, as requested by Daniel Vetter.
I had hoped to start working on that today, but I'm not sure if I'll get around to that. | [09:46] |
| benjiG | thanks for the status :-) | [09:47] |
| hverkuil | I'm now reading through the v4l2-mc mailstorm :-( | [09:48] |
| .................................... (idle for 2h59mn) | ||
| sailus | hverkuil: Pong! | [12:47] |
| hverkuil | sailus: let me mail you my latest atmel-isi.c code and then I'll ask a question about that.
sent. | [12:50] |
| sailus | Received. | [12:53] |
| hverkuil | My question is this: isi_graph_parse finds an entity and sets isi->entity.node to 'remote'.
in isi_graph_init it calls isi_graph_parse, then devm_kzalloc. On error of devm_kcalloc, do I need to call of_node_put(isi->entity.node)? Same for any other error path and also in atmel_isi_remove? It's not entirely clear to me if this has to be done and what happens if you don't. | [12:53] |
| sailus | I think you do need that.
If you get a reference to a node in the device tree you need to put it at some point. I believe a large number of drivers are somehow broken in this respect. And my understanding is that a number of people (including Rob) think this is not a very neat way to manage the references. | [12:56] |
| hverkuil | There doesn't seem to be any visible consequence of not putting the reference.
My main issue with this is actually that I need to do an of_node_put in the atmel_isi_remove function, which looks really weird. | [12:58] |
| sailus | I think it'd be the correct thing to do.
But I don't think any other drivers do that. | [13:02] |
| hverkuil | hence my problem: should I be bug-compatible with the rest of the world, or try to be best-of-the-class :-)
I'm in inclined to drop the put in the remove(). | [13:02] |
| larsc | hverkuil: For built-in devicetrees the node is statically allocated, so of_node_put() will do nothing. But for overlays they are dynamically allocated | [13:13] |
| hverkuil | sailus: I feel this put should really happen in v4l2-async, but the node field is const in struct v4l2_async_subdev, thus you can't call of_node_put on it. | [13:14] |
| larsc | but I've heard that since so many people get the reference counting for of nodes wrong, the node are never freed either way
but that might be outdated information usually you wouldn't keep the references to the nodes around, just use it for matching and be done with it | [13:14] |
| sailus | hverkuil: The V4L2 OF framework (soon hopefully V4L2 fwnode framework) will store the node to the endpoint.
That should be explicitly released. I think we should address these matters in a coordinated effort. I'm not very concerned about one particular driver. | [13:26] |
| larsc | hverkuil: I belive your isi_graph_init() has too many of_node_put() calls | [13:29] |
| hverkuil | larsc: oh? | [13:41] |
| larsc | sorry, the graph_parse()
get_next_endpoint() will already drop the current endpoint best might be to use for_each_endpoint_of_node() | [13:44] |
| hverkuil | are you looking at the v5 or v4 patch?
I suspect v4 (which was indeed wrong) | [13:46] |
| larsc | ah, ok
the best would probably be if the reference is gifted to the notifier and the notifier drops it when it no longer needs it | [13:47] |
| sailus | It's not only up to the notifier. The endpoint node is stashed in struct v4l2_of_endpoint. | [13:53] |
| larsc | it should probably take another reference if it stores the pointer | [13:59] |
| .... (idle for 15mn) | ||
| sailus | larsc: Yes, it should. | [14:14] |
| (If anyone is willing to fix that, I'd prefer that'd be done on top of the V4L2 fwnode patchset.) | [14:19] | |
| ............... (idle for 1h14mn) | ||
| headless | mchehab: hi! so what's your general attitude to the Renesas IMR driver?
(I saw the patchwork updates as I released the new versions but no feedback) if you have any, that is :-) | [15:33] |
| ..... (idle for 21mn) | ||
| CarlFK | looking to hook 4 ntsc over composite cameras to a linux box. how current is https://linuxtv.org/wiki/index.php/Hardware_device_information | [15:54] |
| ..... (idle for 24mn) | ||
| mchehab | headless: I usually wait for a sub-maintainer to review V4L2 drivers before I look in to them
that's specially true for new drivers | [16:18] |
| headless | mchehab: it's not obvious who doi you mean in this case :-)
*do | [16:23] |
| mchehab | if such driver is related to vsp1 driver, then I guess pinchartl is the one that should be reviewing it... otherwise, hverkuil will likely review it | [16:24] |
| headless | get_maintainer.pl diesn't give me any submaintainers
*doesn 't no, we're not related to VSP1, at least not yet oops, not related to it at all may be related to VIN OK, hverkuil then, TY | [16:24] |
| ..... (idle for 20mn) | ||
| hverkuil | headless: delegated the patch to me, so it is in my queue at least. | [16:47] |
| headless | hverkuil: OK, TY | [16:53] |
| mchehab | headless: get_maintainer.pl gives the subsystem ML, with is the place patches should be sent | [16:56] |
| headless | mchehab: sure, I followed that | [16:57] |
| nmschulte | I wish to use a Raspberry Pi 3 with its CSI attached camera, as a sort of "IP camera" for use with zoneminder. I'm looking for guidance in configuring the hardware so I don't need to run ZoneMinder on the Raspberry Pi itself -- https://www.raspberrypi.org/documentation/raspbian/applications/camera.md
What is the optimal way to stream video from the RPi3/cam over the network for pairing with a ZoneMinder server (as a camera/video/feed source)? I know there is a v4l2 interface, and I've been playing with it via ffmpeg and mplayer etc, but getting the bits to stream properly is somewhat of a challenge. It's not clear how the raspicam/raspivid tooling compares to e.g. the v4l2 device. | [17:08] |
| hverkuil | v4l2 just gets the video frames into memory. Transporting video over the network is out of scope of V4L2. In addition, these raspberry camera tools do not use V4L2.
There is work-in-progress to make a proper v4l2 driver for the rpi3, but that has just started. | [17:13] |
| nmschulte | hverkuil: can you help me understand what the bcmNNNN driver does (providing the v4l2 iface) vs the raspicam/vid binaries? | [17:14] |
| *** | benjiG has left | [17:14] |
| nmschulte | is that the WIP driver you're referring to? the bcxnnnn driver? | [17:15] |
| hverkuil | bcm2835. Appeared in linux-4.11-rc1, but it seems to be removed again (some issues with vc04_services apparently).
As I said, it's early days and I don't think there is anything usable right now with a v4l2 API. the rpi camera tools use some closed source openmax library if I understand it correctly. | [17:17] |
| ....... (idle for 34mn) | ||
| nmschulte | hverkuil: I've had some success w/ that driver; I didn't realize how new it was though. I appreciate your help. Yes, the rpi tooling has some proprietary bits in the stack; IIUC, the broadcom folks are cooperating w/ the devs to help expose most/all of the features, but I don't believe it'll be OSS.
I appreciate the information. | [17:52] |
| I see now, OpenMAX (OMX) is non-proprietary; that's awesome. RPi 3 cam binaries use MMAL which ifaces atop OMX APIs -- I wonder what bits are proprietary other than the hardware, then. | [18:01] | |
| hverkuil | nmschulte: I don't know the details of the rpi3. I know currently nothing for video capture is in the kernel, and it is only with 4.11 that we see some improvement there, but it looks to be early days. | [18:07] |
| ................................ (idle for 2h36mn) | ||
| headless | headless sends IMR-LSX3 support patch
hverkuil: more for you :-) | [20:43] |
| ...... (idle for 27mn) | ||
| night | [21:10] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |