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
