On Sat, 2008-11-22 at 10:32 -0500, Al McIntosh wrote:
> Andy, I am trying to record from SVIDEO 1, something I did not think > to mention. > > $ v4l2-ctl --get-input > Video input : 1 (S-Video 1) > $ v4l2-ctl --get-tuner > Tuner: > Capabilities : 62.5 kHz multi-standard stereo lang1 > lang2 > Frequency range : 44.0 MHz - 958.0 MHz > Signal strength : 99% > Current audio mode : lang1 > Available subchannels: mono > You mentioned that before actually. It shouldn't matter. Analog video is analog video as far as the encoder and encoder firmware is concerned. It's all digitized at the 13.5 Mpixel/sec rate when it gets it. The harder you make the encoder work to compress video (MPEG bitrates), the slower it will finish and the smaller data sets it will have to put into buffers. The larger buffers you give to the encoder for it to fill, the slower it will perform DMAs and send notifications that it's done. > Here is the output: > > > $ sudo v4l2-dbg -d /dev/video0 -R > type=host,min=0x2c40488,max=0x2c4048f > > ioctl: VIDIOC_DBG_G_REGISTER > > 00 04 08 0C 10 14 > 18 1C > 02c40480: f825451d 001020dc That was for Dmitry's separate analog problem. I didn't need this for this problem. > I am quite suprised how great the system requirements are for this > card. When I first tried to boot the computer it wouldn't boot, I had > to raise vmalloc to 192M it's currently consuming about 120M+/-. vmalloc space is not real memory, it's a pool of addresses to be used for mapping in IO memory and register space and dynamically allocated pages of "real" memory. The CX23418 MMIO memory space is 32 MB large and we map it all in (I suppose we could do less), but it's not real system memory. The CX23418 MMIO register space is also 32 MB and very sparsely populated, so we do have to map most of the 32 MB in, but again it's not real system memory. The hard requirement, I've learned in the past two weeks, is the interrupt service latency: the time from when the hardware signals an interrupt to the time we grab a copy of the mailbox is critical. I've got the time from when the kernel calls the cx18_irq_handler() to the time we collect all the data we need and send back an ack for the mailbox, down to below 50 microseconds. Delays outside of that 50 us timeline are a system issue that the cx18 driver can't do much about. I don't know what the firmware's actual required response time from interrupt to ack interrupt is - I'm guessing not more than a few hundred microseconds. > The card worked well in my dual core amd64 Because when interrupts are disabled locally on one core, the other core can still service interrupts and let the cx18 driver stay on the timeline that the firmware imposes. It should be a rare event that both cores have interrupts disabled. It's a hard thing to stay on a realtime schedule with a PCI bus and a non-RT OS. > but I will need an IR Blaster in order to migrate everything to that > machine. On my todo list - but sorta low priority. > Thanks for all of the energy you're putting into this... I really do > appreciate this. No problem. Regards, Andy > Al _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
