| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | sailus: drivers/staging/media/ipu3/ipu3-css-pool.h:24: warning: Function parameter or member 'pages' not described in 'imgu_css_map'
Can you make a patch if that hasn't been done already? | [07:32] |
| ...... (idle for 29mn) | ||
| *** | hverkuil has left | [08:01] |
| ..... (idle for 23mn) | ||
| tomba | I'm trying to understand how the buffers are supposed to be dequeued. If I queue, say, 6 buffers, then start the stream, how many buffers is the userspace supposed to be able to dequeue? At least this HW needs a buffer while the DMA is enabled, so the driver can't return all 6 buffers. Or is the driver supposed to automatically stop the DMA when it runs out of buffers? | [08:24] |
| sailus | hverkuil: Thanks, I'll look into this. | [08:34] |
| mripard | tomba: in your example, it could be anywhere between 0 and 6 | [08:36] |
| sailus | tomba: I don't think this has been very accurately specified. Ideally the user space queued back the buffers once it's done with them to avoid losing frames. | [08:37] |
| mripard | tomba: sun4i-csi was in a similar situation, so I did a scratch buffer to switch to it if there's no queued buffer | [08:37] |
| sailus | mripard: Don't you think it should return at least one? :-) | [08:38] |
| tomba | mripard: so does that mean there's no way for the userspace to capture exactly N buffers consecutive, without re-queuing any? | [08:38] |
| sailus | The driver shouldn't allow starting streaming with too few buffers allocated. | [08:38] |
| mripard | sailus: I meant when the driver runs out of buffer | [08:38] |
| sailus | Ah, right.
I wonder if this could be more of a problem for codecs which may need previous frames? | [08:39] |
| mripard | but what I meant was that you would have 0 buffer to dequeue if there's no frame that came between the period where the stream started, and the time where you call dequeue
dequeue is blocking, but from the driver's PoV there's nothing to dequeue at that time and I'm not sure codec are an issue there, the timing is in userspace's control | [08:40] |
| tomba | I'm testing with yavta, and trying to understand if my driver is behaving correctly. At the moment I either need to allocate one extra buffer (with --nbufs) or use --requeue-last to get it exit cleanly, as otherwise it stalls when waiting for the last buffer, which the driver doesn't release as the streaming is on
The scratch-buffer method would fix it, but... I wonder if it's worth the effort. Or, well, it's definitely worth the effort if that is the expected behavior. But is it =) | [08:44] |
| .............. (idle for 1h5mn) | ||
| sailus | tomba: If yavta stalls, then other applications are likely to stall as well.
tomba: What kind of hardware do you have? | [09:50] |
| tomba | It's a CSI-2 capture IP. Its DMA continues writing to the given buffer, until you change the address (the updated address is taken into use at the next frame-start).
Or until you stop the DMA (will be stopped at the end of the frame) | [09:51] |
| sailus | tomba: Yeah, those are not unforeseen.
Can it be stopped? The omap3isp blocks can be stopped but I believe some other drivers use dummy buffers (or pages). | [09:57] |
| tomba | Yes, I believe I could stop the DMA (while keeping the pipeline otherwise enabled) if the driver runs out of buffers. And then start dma again when the userspace re-queues. | [09:58] |
| hverkuil | sailus: can I take ipu3 outreachy patches once you are OK with them? It might be easier if they go through me. | [10:09] |
| sailus | hverkuil: I was about to apply them to my tree, but you can take them, too.
I expect v3 from Mitali btw. As long as we both know which one of us does it. :-) | [10:14] |
| hverkuil | Just Ack those you want merged, and I'll pick them up.
Do you want to review atomisp patches from outreachy candidates as well? | [10:15] |
| sailus | hverkuil: Oh dear.
I've acked some, but frankly improving the coding style on that code is like putting lipstick on a pig. I guess it's not wrong, but is it useful? Perhaps from practice point of view it is. The code has to be fully reworked in order to get out of staging anyway. | [10:15] |
| hverkuil | For the outreachy candidates, yes, as it gives them experience in how to submit patches. For the driver itself not so much :-) | [10:17] |
| sailus | Ack. Sounds good.
There's probably less to improve in the IPU3 ImgU driver there. In that sense the atomisp driver is a good target indeed. :-) hverkuil: I'll ack such patches for the two drivers then. So you can apply them. | [10:18] |
| hverkuil | Thanks! | [10:22] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |