On Monday 22 January 2007 00:36, 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
Can you put in a debug message in ivtv-irq to check whether it is indeed
the culprit? I'm not convinced but it is easy to check.
Hans
>
> 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
