Sorry I meant to say PIO mode with ivtv-svn on __x86__ fails. Tim
----- Original Message ---- From: Tim Harvey <[EMAIL PROTECTED]> To: Discussion list for development of the IVTV driver <[email protected]> Sent: Thursday, January 18, 2007 6:06:06 PM Subject: Re: [ivtv-devel] ivtv on ARM I should also mention that I get the same results below using ivtv-svn with PIO mode - the encoder thread is starved as no ENC START CAP interrupts occur other than the initial one Tim ----- Original Message ---- From: Tim Harvey <[EMAIL PROTECTED]> To: Discussion list for development of the IVTV driver <[email protected]> Sent: Thursday, January 18, 2007 1:52:49 PM Subject: Re: [ivtv-devel] ivtv on ARM Sorry, somehow I didn't get CONFIG_VIDEO_CX25840 defined - once I did that I see the cx25840 fine. I'm still having issues with DMA and unlike ivtv-0.8.2 I'm now also having issues with PIO. Looks like there has been a lot of changes since 0.8.2. I notice that there is now read_enc/write_enc and read_dec/write_dec functions for accessing data from the enc/dec buffers directly. At first glance I figured I should make these endian-safe but that fixed some issues and caused others so instead I just fixed the endienness issues around DMA_MAGIC_COOKIE. With that in place and using PIO I never get the IVTV_IRQ_ENC_DMA_COMPLETE interrupts that I would get with ivtv-0.8.2 PIO (Note I'm using ivtv_debug=75 and have added the pid to the debug print to show the thread): # dd if=/dev/video0 of=/mnt/tmp/test_capture.mpg bs=1024 count=512 [807] ivtv0 info: ivtv start v4l2 stream [807] ivtv0 info: Setup VBI API header 0x0000bd03 pkts 1 buffs 4 ln 24 sz 1456 [807] ivtv0 info: Setup VBI start 0x002fea04 frames 4 fpi 1 lines 0x00000140 [807] ivtv0 info: ENC: PGM Index at 0x00180150 with 400 elements [0] ivtv0 irq: ENC START CAP 0: 000dd700 00007fc0 [0] ivtv0 dma: PIO encoder MPEG: 0x00007fc0 bytes at 0x000dd700 [0] ivtv0 dma: PIO encoder MPEG completed (dd700) [807] ivtv0 info: ENC: read(1024), got 1024 [807] ivtv0 info: ENC: read(1024), got 1024 [807] ivtv0 info: ENC: read(1024), got 1024 .... eventually the enc thread ([807]) stalls when it runs out of data. I never see an IVTV_IRQ_ENC_DMA_COMPLETE to queue up more data. For DMA: # dd if=/dev/video0 of=/mnt/tmp/test_capture.mpg bs=1024 count=512 [807] ivtv0 info: ivtv start v4l2 stream [807] ivtv0 info: Setup VBI API header 0x0000bd03 pkts 1 buffs 4 ln 24 sz 1456 [807] ivtv0 info: Setup VBI start 0x002fea04 frames 4 fpi 1 lines 0x00000140 [807] ivtv0 info: ENC: PGM Index at 0x00180150 with 400 elements [0] ivtv0 irq: ENC START CAP 0: 000dd700 00008fc0 [0] ivtv0 dma: DMA encoder MPEG: 0x00008fc0 bytes at 0x000dd700 [0] ivtv0 dma: start DMA for encoder MPEG (hangs at this point) Here is my IVTV init: Linux video capture interface: v2.00 ivtv: ==================== START INIT IVTV ==================== ivtv: version 0.10.0 (development revision 3718M) loading ivtv: Linux version: 2.6.19 mod_unload ARMv5 ivtv: In case of problems please include the debug info between ivtv: the START INIT IVTV and END INIT IVTV lines, along with ivtv: any module options, when mailing the ivtv-users mailinglist. ivtv0: Autodetected Yuan MPC622 card (cx23416 based) [766] ivtv0 info: base addr: 0x48000000 [766] ivtv0 info: Enabling pci device PCI: enabling device 0000:00:02.0 (0140 -> 0142) [766] ivtv0 info: Attempting to enable Bus Mastering [766] ivtv0 info: Bus Mastering Enabled. ivtv0: Unreasonably low latency timer, setting to 64 (was 0) [766] ivtv0 info: 22 (rev 1) at 00:02.0, irq: 27, latency: 64, memory: 0x48000000 [766] ivtv0 info: attempting ioremap at 0x48000000 len 0x00800000 [766] ivtv0 info: attempting ioremap at 0x4a000000 len 0x00010000 [766] ivtv0 info: Preparing for firmware halt. [766] ivtv0 info: Stopping VDM [766] ivtv0 info: Stopping AO [766] ivtv0 info: pinging (?) APU [766] ivtv0 info: Stopping VPU [766] ivtv0 info: Resetting Hw Blocks [766] ivtv0 info: Stopping SPU [766] ivtv0 info: init Encoder SDRAM pre-charge [766] ivtv0 info: init Encoder SDRAM refresh to 1us [766] ivtv0 info: Sleeping for 600ms (600 recommended) [766] ivtv0 info: Loading encoder image ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes) [766] ivtv0 info: Getting firmware version.. ivtv0: Encoder revision: 0x02050032 [766] ivtv0 info: GPIO initial dir: 0000c000 out: 00000000 [766] ivtv0 info: activating i2c... [766] ivtv0 info: Active card count: 1. tuner 0-004b: chip found @ 0x96 (ivtv i2c driver #0) [766] ivtv0 info: Loaded module tuner cx25840 0-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0) cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes) [766] ivtv0 info: Loaded module cx25840 ivtv0: Registered device video0 for encoder MPEG (4 MB) [766] ivtv0 info: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096kB total) ivtv0: Registered device video32 for encoder YUV (2 MB) [766] ivtv0 info: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2046kB total) ivtv0: Registered device vbi0 for encoder VBI (1 MB) [766] ivtv0 info: Allocate DMA encoder VBI stream: 60 x 17472 buffers (1023kB total) ivtv0: Registered device video24 for encoder PCM audio (1 MB) [766] ivtv0 info: Allocate DMA encoder PCM audio stream: 227 x 4608 buffers (1021kB total) [766] ivtv0 info: Starting Threads [766] ivtv0 irq: Masking interrupts tuner 0-004b: setting tuner address to 61 tuner 0-004b: type set to tda8290+75a [766] ivtv0 info: Changing input from 1 to 0 [766] ivtv0 info: Mute [766] ivtv0 info: Unmute [766] ivtv0 info: Switching standard to 1000. [766] ivtv0 info: Mute [766] ivtv0 info: v4l2 ioctl: set frequency 1076 [766] ivtv0 info: Unmute ivtv0: Initialized Yuan MPC622, card #0 ivtv: ==================== END INIT IVTV ==================== So it would seem that in both PIO and DMA cases my issue is that I'm not continuing to get interrupts after the IVTV_IRQ_ENC_START_CAP interrupt. Tim > > >----- Original Message ---- >From: Tim Harvey <[EMAIL PROTECTED]> >To: Discussion list for development of the IVTV driver ><[email protected]> >Sent: Wednesday, January 17, 2007 4:31:34 PM >Subject: Re: [ivtv-devel] ivtv on ARM > >Fair enough - I've updated to 2.6.19 and ivtv-svn. With ivtv-svn however, I'm >not getting as far as I was because the cx25840 is not being detected on the >i2c bus (however the tda8290 tuner is being detected on the same bus). I've >tried both newi2c=0 and 1. > >I had this same situation occur on a board with a 266MHz cpu with the 0.8.2 >code so I'm guessing its timing related. I guess I'll have to add some >debugging to the i2c layer? > >Tim > > >----- Original Message ---- >From: Hans Verkuil <[EMAIL PROTECTED]> >To: Tim Harvey <[EMAIL PROTECTED]>; Discussion list for development of the >IVTV driver <[email protected]> >Sent: Wednesday, January 17, 2007 1:14:18 PM >Subject: Re: [ivtv-devel] ivtv on ARM > >Hi Tim, > >Sorry for not answering your original mail, I'll try to do so in this >mail. > >On Wednesday 17 January 2007 21:37, Tim Harvey wrote: >> >Greetings, >> > >> >has anyone ever successfully run ivtv on an ARM processor? I'm >> > running linux 2.6.18.6 on an IXP425 xscale CPU and a YUAN MPC622 >> > card (cx23416) and am having issues with DMA. I'm not sure the >> > arm-linux architecture supports the scatter-gather DMA being used. >> > I've tried to force using PIO via #define IVTV_ENC_PIO 1 but that >> > seems to fail as well. > >The pci_map_sg etc. dma scatter gather functions from the kernel are >only used by the PVR350 (cx23415-based), not be a cx23416-based card. >So this shouldn't be a problem. I see no reason why it would fail to >work, except for endianness problems. > >> > >> >Before I post a question to the arm-linux list any suggestions or >> > explanations of what ivtv is using for DMA (looks like >> > scatter-gather dma list?). > >All known documentation of the cx23415/6 is in the >Documentation/video4linux/cx2341x directory of the linux kernel >(starting from 2.6.18). Including how the DMA is programmed. > >BTW: I recommend that you use the ivtv-trunk as the basis for your ARM >port. It will replace the current ivtv sources for 2.6.18 and 2.6.19 >when done. I hope to finish a few minor issues this weekend and make >release candidates available for testing, so it should be a solid base >to work from. Note that the current trunk requires a 2.6.19 kernel. > >One very good reason for using the trunk is that the DMA code is much >more centralized (almost everything is in ivtv-irq.c). That should make >it much easier for you to fix the endianness issues. > >> I've determined from the source that ivtv is not big-endian safe but >> after fixing a couple of obvious endian issues regarding (looking at >> the buffer to ensure it starts with 0x0000001fe in >> ivtv_FROM_DMA_done) I'm able to get it to run on my ARM big-endian >> platform using PIO, but not DMA. >> >> Here are some follow-up questions for the list: >> >> - any areas I should be looking at for endianess issues? I believe >> readl/writel should be byteswapped for arm-linux so register >> read/writes should be ok, correct? > >Doesn't readl/writel already byteswap for ARM? > >> - I've only been able to get the driver to work using PIO >> (IVTV_USE_PIO=1) - when I use DMA the DMA transfer never appears to >> start and I get the following errors: ivtv0 warning: ENC: REG_DMAXFER >> 2 wait failed >> ivtv0 warning: ENC: (0) DMA Error 0x00000001 00000001 >> ivtv0 warning: ENC: REG_DMAXFER 2 wait failed >> ivtv0 warning: ENC: (1) DMA Error 0x00000001 00000001 >> ivtv0 warning: ENC: REG_DMAXFER 2 wait failed >> ivtv0 warning: ENC: (2) DMA Error 0x00000001 00000001 >> ivtv0 warning: ENC: REG_DMAXFER 2 wait failed >> ivtv0 warning: ENC: (3) DMA Error 0x00000001 00000001 >> ivtv0 warning: ENC: REDO DMA took too many tries. >> ivtv0 warning: Error Encoder DMA > >Again, use the trunk code. Error reporting is much better there. I >recommend to either load ivtv with ivtv_debug=79 or run 'ivtvctl -D79' >to turn on the most relevant debugging for interrupt and DMA handling. > >> - using PIO I occasionally get interrupts for IVTV_IRQ_DEC_DMA_2 and >> IVTV_IRQ_DEC_DMA_0 (bit 0 and bit 2). It appears that these may only >> come when I'm loading the system heavily with debugging output - what >> do these mean? > >Again, move to the trunk code. > >> - is there a software development manual anywhere for the cx23416 >> which details its registers? > >As mentioned above, it's in the kernel documentation directory. > >> - there is a DYNAMIC_MEMORY_ALLOC defined in ivtv-driver.h for >> __powerpc__ but its not used anywhere. I see the point in needing it >> for an embedded platform and I assume the thought was that instead of >> the driver allocating DMA buffers on init it would allocate them when >> needed (ie, no need to have YUV buffers if your not using YUV mode) - >> was any work ever done on this? > >No, dynamic allocation gave more problems than it solved. It's >completely dropped in the trunk code. > >Basically the moral of my email is that you should use the trunk code. >If it is a problem for you to also update to the 2.6.19 kernel >(recommend 2.6.19.2 or up), then you can also wait until this weekend. >I want to release trunk-based beta versions for 2.6.18 as well. > >Regards, > > Hans > > > > >_______________________________________________ >ivtv-devel mailing list >[email protected] >http://ivtvdriver.org/mailman/listinfo/ivtv-devel > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
