Well, after some more testing, it seems that DMA doesn't work on 0.9
for PPC, it just backs down and attempts to get the data via PIO when
DMA doesn't work.
Anything I can do to get the new DMA code to work on PPC?
- Rick
On Jan 21, 2007, at 6:36 PM, Ricardo Lugo wrote:
> Hi Hans, Chris, any other developers working on the new DMA code,
>
> I tried the trunk on my PPC ivtv machine and can't get it to capture
> anything. MythTV complains that the driver has stopped recording, and
> I get the following kernel message:
>
> ivtv0 warning: encoder MPEG: Couldn't find start of buffer within
> the first 256 bytes
>
> Fortunately, ivtv-0.9.x works just fine on my PPC machine, so it must
> be a new change in the trunk. I think the cause is the buffer
> (pointer?) being byteswapped and the DMA_MAGIC_COOKIE never gets
> found.... This could be a result of using a char instead of a
> v4l2_buffer in ivtv_buffer in ivtv-driver.h. Typecasting chars to
> pointers always result in endian issues....
>
> trunk ivtv-irq.c 218: u32buf = (u32 *)buf->buf;
> 0.9 ivtv-irq.c 296: (u32 *)(buf->buffer.m.userptr)
>
> trunk struct ivtv_buffer {
> struct list_head list;
> dma_addr_t dma_handle;
> unsigned long b_flags;
> char *buf; // leads to
> endian issues...
>
> u32 bytesused;
> u32 readpos;
> };
>
> 0.9 struct ivtv_buffer {
> size_t readpos;
> dma_addr_t dma_handle;
> struct v4l2_buffer buffer; // conversion handled by
> v4l2_buffer!
> struct list_head list;
> unsigned long ts;
> unsigned long b_flags;
> unsigned long *page;
> unsigned char **vpage;
> };
>
> The "0.9" way of doing the buffer looks much safer to me... hope this
> helps.
>
> - Rick
>
> _______________________________________________
> 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
