On Tuesday 23 January 2007 19:57, Tim Harvey wrote:
> > ----- Original Message ----
> > From: Ricardo Lugo <[EMAIL PROTECTED]>
> > To: Discussion list for development of the IVTV driver
> > <[email protected]> Sent: Sunday, January 21, 2007 7:13:42
> > PM
> > Subject: Re: [ivtv-devel] trunk on PPC - "couldn't find start of
> > buffer"
> >
> > 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?
>
> looks like this is the same issue I'm having on my ARM (big-endian)
> platform. The attached patch fixes endian issues for me regarding
> the DMA_MAGIC_COOKIE check as well as endian issues with DMA setup
> that I found, however I'm still working with Hans to find a dma
> memory/sync issue that appears on my platform - so I'm not sure this
> will fix the PPC DMA or not. Please test this and if it doesn't work
> show us a log with ivtv_debug=79
I've just merged this patch into the svn trunk of ivtv. Please check if
PIO is now working at the very least.
Tim, thank you for your good work! I hope we can figure out what's
causing the remaining DMA issues, whether it's a driver bug and/or an
ARM bug. My gut feeling is that it is a driver bug which simply never
surfaces on i386/x86_64.
Thanks,
Hans
> If this does not solve your issue then perhaps its similar to my
> issue I'm still working on regarding dma memory sync. There is
> definitely some issues in ivtv-svn (and most likely past versions)
> with regards to sync'ing memory between device/cpu. I'm still
> working with Hans on the issue and don't have an elegant solution yet
> that works on my ARM big-endian platform, but I can work around the
> issue by changing the allocation of the SGarray in ivtv-queue.c as
> follows:
>
> Index: driver/ivtv-queue.c
> ===================================================================
> --- driver/ivtv-queue.c (revision 3739)
> +++ driver/ivtv-queue.c (working copy)
> @@ -225,13 +225,14 @@
>
> /* Allocate DMA SG Arrays */
> if (s->dma != PCI_DMA_NONE) {
> - s->SGarray = (struct ivtv_SG_element
> *)kzalloc(SGsize, GFP_KERNEL); +// s->SGarray =
> (struct ivtv_SG_element *)kzalloc(SGsize, GFP_KERNEL); +
> s->SGarray = (struct ivtv_SG_element
> *)pci_alloc_consistent(itv->dev, SGsize, &s->SG_handle); if
> (s->SGarray == NULL) {
> IVTV_ERR("Could not allocate SGarray for %s
> stream\n", s->name); return -ENOMEM;
> }
> s->SG_length = 0;
> - s->SG_handle = pci_map_single(itv->dev, s->SGarray,
> SGsize, s->dma); +// s->SG_handle =
> pci_map_single(itv->dev, s->SGarray, SGsize, s->dma); }
>
> /* allocate stream buffers. Initially all buffers are in
> q_free. */
>
> You might want to try this as well. The above patch is only for the
> MPEG stream, so I believe there would be other changes for YUV etc
> but again this patch is not intended to be the permanent fix.
>
> Tim
>
> > - 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
>
> [EMAIL PROTECTED] ivtv-svn]$
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
