aio / ioctl / sideband informations
Hi, I'm currently converting my windows driver for a broadcast video card to Linux. This conversion raised a lot of questions/issues, and I believe I solved most of them. Yet, I still have some issues and would like some advice. In windows video data acquisition and playing were done through asynchronous IOCTL calls. I used METHOD_NEITHER for reference. The whole mechanism is simple, let's take an example for play : - User mode has a Video Buffer, an Audio Buffer and an Ancillary data buffer (Timecode, and other smpte's stuff). - User mode create a struct that gives 3 pointers to the buffers (Audio/Video/Anc) and also various sideband info (Nb of audio samples, size of buffers? ...), and call my IOCTL : IOCTL_PLAY_NEW_FRAME - In my driver, I store sideband info in an internal structure, I map all 3 buffers into Physical Memory, then I start a Dma Transfer to the Board (using SG I/O). - The card trig an Interrupt and I complete the request. Now on Linux : I first though that I would simply use ioctl capability to achieve that kind of functionnality. Using flag O_DIRECT, I had the feeling that it was possible. BUT if you have been attentive to the previous parts, you'll see that I've mentioned the fact that these ioctls were asynchronous. And that is my issue. I don't think that ioctl can be managed as aio read/write. I need the async functionnality to allow user mode post many play buffer, and to have the driver accumulate them in a fifo until that fifo is full. I see that there are aio_write facilities that match perfectly my async scenario, but I can't find a way to supply multiple buffers (all part of the same frame) along a description of what is in these buffers. I think of a workaround that would be for a single play frame: BASIC_PLAY_FRAME_OPERATION - Use io_submit to submit a write op to the driver. In the buffer, have in fact a structure representing the frame I want to send including the 3 usermode buffers. I assume that if I do not set O_DIRECT Flag, the buffer will be copied into kernel space so that I can access it with __copy_from_user. - The driver then maps and lock the 3 buffers in physical memory and trig a SG DMA transfer. - Once the transfer is done (interrupt driven), complete the aio. END_OF_BASIC_PLAY_FRAME_OPERATION To achieve the final goal, submit multiple BASIC_PLAY_FRAME_OPERATION. So my questions : - Do you believe that my proposed workaround will work ? - Are there other simpler alternatives ? Thanks for you answers/comments. Regards, Fred.
Hi Fred, On Tue, Oct 9, 2012 at 7:56 AM, EVS Hardware Dpt <hardware.evs@gmail.com> wrote:
Hi,
I'm currently converting my windows driver for a broadcast video card to Linux. This conversion raised a lot of questions/issues, and I believe I solved most of them. Yet, I still have some issues and would like some advice.
What device are you working on? Ezequiel
Hi Ezequiel, It's our own HD Sdi board. As far as I understand, being professional broadcast oriented, it doesn't fall into V4L usage. Best Regards, Fred. 2012/10/10 Ezequiel Garcia <elezegarcia@gmail.com>
Hi Fred,
On Tue, Oct 9, 2012 at 7:56 AM, EVS Hardware Dpt <hardware.evs@gmail.com> wrote:
Hi,
I'm currently converting my windows driver for a broadcast video card to Linux. This conversion raised a lot of questions/issues, and I believe I solved most of them. Yet, I still have some issues and would like some advice.
What device are you working on?
Ezequiel
Hi Fred, On Thu, Oct 11, 2012 at 10:08 AM, EVS Hardware Dpt <hardware.evs@gmail.com> wrote:
Hi Ezequiel,
It's our own HD Sdi board. As far as I understand, being professional broadcast oriented, it doesn't fall into V4L usage.
Wow, you read my mind, I was going to suggest you to look into V4L2 framework :-) If you've already considered and discarded that path, then that's fine. Let me just say V4L2 has evolved a lot and it's nowadays quite mature. If you ever plan to try to mainline your driver (which has an endless amount of benefits) then you should start by RFCing something to the linux-media list. If you implement a whole bunch of APIs out of tree, you may end with some weird implementation, which may be impossible to mainline and improbable to get support from developers around here. Of course, this is not necessarily your case. Hope this helps and good luck! Ezequiel
Hi Ezequiel, I'll double check if V4L2 is suitable for my needs or if some minor modifications would make it more appropriate. Best Regards, Fred. 2012/10/11 Ezequiel Garcia <elezegarcia@gmail.com>
Hi Fred,
On Thu, Oct 11, 2012 at 10:08 AM, EVS Hardware Dpt <hardware.evs@gmail.com> wrote:
Hi Ezequiel,
It's our own HD Sdi board. As far as I understand, being professional broadcast oriented, it doesn't fall into V4L usage.
Wow, you read my mind, I was going to suggest you to look into V4L2 framework :-) If you've already considered and discarded that path, then that's fine.
Let me just say V4L2 has evolved a lot and it's nowadays quite mature. If you ever plan to try to mainline your driver (which has an endless amount of benefits) then you should start by RFCing something to the linux-media list.
If you implement a whole bunch of APIs out of tree, you may end with some weird implementation, which may be impossible to mainline and improbable to get support from developers around here.
Of course, this is not necessarily your case.
Hope this helps and good luck!
Ezequiel
participants (2)
-
EVS Hardware Dpt -
Ezequiel Garcia