Mailing List Archive: ivtv: devel

cx18: CX23418 handles and releasing MDLs

Index | Next | Previous | View Threaded

awalls at radix

Aug 23, 2008, 8:52 AM

Post #1 of 4 (2121 views)
Permalink

cx18: CX23418 handles and releasing MDLs

Hans,

A few questions:

1. The handle member in struct cx18_stream is initialized and cleared
to 0xffffffff to indicated non-use. BTW, the CX23418 appears to begin
assigning task handles starting with 0. So what is
cx18_streams:cx18_find_handle() really trying to do? Find the first
used handle or first unused handle?

u32 cx18_find_handle(struct cx18 *cx)
{
int i;

/* find first available handle to be used for global settings */
for (i = 0; i < CX18_MAX_STREAMS; i++) {
struct cx18_stream *s = &cx->streams[i];

if (s->v4l2dev && s->handle)
return s->handle;
}
return 0;
}

The above code will reject handle 0 and likely return either 0xffffffff
or 1 in the most common cases.

2. The CX23418 appears to reuse handles:

Aug 23 11:01:02 morgan kernel: cx18-0 info: Start feed: pid = 0x31 index = 0
Aug 23 11:01:02 morgan kernel: cx18-0 info: Starting Transport DMA
Aug 23 11:01:02 morgan kernel: cx18-0 info: Start encoder stream TS
Aug 23 11:01:02 morgan kernel: cx18-0 info: Stream TS task given handle 0 by CX23418
[...]
Aug 23 11:01:09 morgan kernel: cx18-0 info: Stopping Transport DMA
Aug 23 11:01:09 morgan kernel: cx18-0 info: Stop Capture
Aug 23 11:01:09 morgan kernel: cx180 irq: SW1: 10000 SW2: 0 HW2: 0
Aug 23 11:01:09 morgan kernel: cx180 irq: queue_get_buf_irq enter
Aug 23 11:01:09 morgan kernel: cx180 irq: queue_get_buf_irq normal exit
Aug 23 11:01:09 morgan kernel: cx18-0 info: Stop Capture mbox command sent
Aug 23 11:01:09 morgan kernel: cx18-0 info: Destroy task mbox command sent
Aug 23 11:01:09 morgan kernel: cx18-0 info: DSP0 interrupt mask altered
Aug 23 11:26:22 morgan kernel: cx18-0 info: Start encoder stream encoder MPEG
Aug 23 11:26:22 morgan kernel: cx18-0 info: Stream encoder MPEG task given handle 0 by CX23418

So without asking the CX23418 to release the MDLs at the end of a
capture, the CX23418 can later return a data buffer with a buffer id in
the wrong range for a stream type. cx18_queue_get_buf_irq() will gripe
when this happens and the data in that buffer will be wrongly dropped.

In cx23418.h, CX18_CPU_DE_ReleaseMDL is commented out. Is there a
problem with it, or is it OK to uncomment and use?

Regards,
Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

hverkuil at xs4all

Aug 23, 2008, 9:14 AM

Post #2 of 4 (1992 views)
Permalink

Re: cx18: CX23418 handles and releasing MDLs [In reply to]

On Saturday 23 August 2008 17:52:05 Andy Walls wrote:
> Hans,
>
> A few questions:
>
> 1. The handle member in struct cx18_stream is initialized and
> cleared to 0xffffffff to indicated non-use. BTW, the CX23418 appears
> to begin assigning task handles starting with 0. So what is
> cx18_streams:cx18_find_handle() really trying to do? Find the first
> used handle or first unused handle?
>
> u32 cx18_find_handle(struct cx18 *cx)
> {
> int i;
>
> /* find first available handle to be used for global settings
> */ for (i = 0; i < CX18_MAX_STREAMS; i++) {
> struct cx18_stream *s = &cx->streams[i];
>
> if (s->v4l2dev && s->handle)
> return s->handle;
> }
> return 0;
> }
>
> The above code will reject handle 0 and likely return either
> 0xffffffff or 1 in the most common cases.

Yuck. That should have been:

if (s->v4l2dev && s->handle != 0xffffffff)

And while we're at it: a #define for that 0xffffffff wouldn't be amiss
either :-)

In most cases when you call a firmware function it is for a specific
task and you know which task handle to pass. Sometimes you do not have
a specific task though and you just want to find any valid handle. I
think it is probably better if find_handle returns 0xffffffff if it
can't find a valid handle and that the caller should check. It is not
something that would normally happen, but it's a bit dubious to just
return 0 here and hope for the best. It's called in only three places,
so it's easy to add some error checking.

Regards,

Hans

>
>
>
> 2. The CX23418 appears to reuse handles:
>
> Aug 23 11:01:02 morgan kernel: cx18-0 info: Start feed: pid = 0x31
> index = 0 Aug 23 11:01:02 morgan kernel: cx18-0 info: Starting
> Transport DMA Aug 23 11:01:02 morgan kernel: cx18-0 info: Start
> encoder stream TS Aug 23 11:01:02 morgan kernel: cx18-0 info: Stream
> TS task given handle 0 by CX23418 [...]
> Aug 23 11:01:09 morgan kernel: cx18-0 info: Stopping Transport DMA
> Aug 23 11:01:09 morgan kernel: cx18-0 info: Stop Capture
> Aug 23 11:01:09 morgan kernel: cx180 irq: SW1: 10000 SW2: 0 HW2: 0
> Aug 23 11:01:09 morgan kernel: cx180 irq: queue_get_buf_irq enter
> Aug 23 11:01:09 morgan kernel: cx180 irq: queue_get_buf_irq normal
> exit Aug 23 11:01:09 morgan kernel: cx18-0 info: Stop Capture mbox
> command sent Aug 23 11:01:09 morgan kernel: cx18-0 info: Destroy task
> mbox command sent Aug 23 11:01:09 morgan kernel: cx18-0 info: DSP0
> interrupt mask altered Aug 23 11:26:22 morgan kernel: cx18-0 info:
> Start encoder stream encoder MPEG Aug 23 11:26:22 morgan kernel:
> cx18-0 info: Stream encoder MPEG task given handle 0 by CX23418
>
> So without asking the CX23418 to release the MDLs at the end of a
> capture, the CX23418 can later return a data buffer with a buffer id
> in the wrong range for a stream type. cx18_queue_get_buf_irq() will
> gripe when this happens and the data in that buffer will be wrongly
> dropped.
>
> In cx23418.h, CX18_CPU_DE_ReleaseMDL is commented out. Is there a
> problem with it, or is it OK to uncomment and use?
>
> Regards,
> Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

hverkuil at xs4all

Aug 23, 2008, 9:20 AM

Post #3 of 4 (1984 views)
Permalink

Re: cx18: CX23418 handles and releasing MDLs [In reply to]

On Saturday 23 August 2008 17:52:05 Andy Walls wrote:
> Hans,
>
> A few questions:
>
> 1. The handle member in struct cx18_stream is initialized and
> cleared to 0xffffffff to indicated non-use. BTW, the CX23418 appears
> to begin assigning task handles starting with 0. So what is
> cx18_streams:cx18_find_handle() really trying to do? Find the first
> used handle or first unused handle?
>
> u32 cx18_find_handle(struct cx18 *cx)
> {
> int i;
>
> /* find first available handle to be used for global settings
> */ for (i = 0; i < CX18_MAX_STREAMS; i++) {
> struct cx18_stream *s = &cx->streams[i];
>
> if (s->v4l2dev && s->handle)
> return s->handle;
> }
> return 0;
> }
>
> The above code will reject handle 0 and likely return either
> 0xffffffff or 1 in the most common cases.
>
>
>
> 2. The CX23418 appears to reuse handles:

Oops, missed this one.

>
> Aug 23 11:01:02 morgan kernel: cx18-0 info: Start feed: pid = 0x31
> index = 0 Aug 23 11:01:02 morgan kernel: cx18-0 info: Starting
> Transport DMA Aug 23 11:01:02 morgan kernel: cx18-0 info: Start
> encoder stream TS Aug 23 11:01:02 morgan kernel: cx18-0 info: Stream
> TS task given handle 0 by CX23418 [...]
> Aug 23 11:01:09 morgan kernel: cx18-0 info: Stopping Transport DMA
> Aug 23 11:01:09 morgan kernel: cx18-0 info: Stop Capture
> Aug 23 11:01:09 morgan kernel: cx180 irq: SW1: 10000 SW2: 0 HW2: 0
> Aug 23 11:01:09 morgan kernel: cx180 irq: queue_get_buf_irq enter
> Aug 23 11:01:09 morgan kernel: cx180 irq: queue_get_buf_irq normal
> exit Aug 23 11:01:09 morgan kernel: cx18-0 info: Stop Capture mbox
> command sent Aug 23 11:01:09 morgan kernel: cx18-0 info: Destroy task
> mbox command sent Aug 23 11:01:09 morgan kernel: cx18-0 info: DSP0
> interrupt mask altered Aug 23 11:26:22 morgan kernel: cx18-0 info:
> Start encoder stream encoder MPEG Aug 23 11:26:22 morgan kernel:
> cx18-0 info: Stream encoder MPEG task given handle 0 by CX23418
>
> So without asking the CX23418 to release the MDLs at the end of a
> capture, the CX23418 can later return a data buffer with a buffer id
> in the wrong range for a stream type. cx18_queue_get_buf_irq() will
> gripe when this happens and the data in that buffer will be wrongly
> dropped.
>
> In cx23418.h, CX18_CPU_DE_ReleaseMDL is commented out. Is there a
> problem with it, or is it OK to uncomment and use?

I was never certain whether is was needed or not. The driver code I have
didn't use it and the documentation is for all practical purposes
non-existent. By all means, see if it fixes this issue. It was always
my impression that the cx23418 automatically released all MDLs after
the capture was stopped and the task destroyed. But I probably never
have tested this particular scenario.

Regards,

Hans

>
> Regards,
> Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

awalls at radix

Aug 23, 2008, 9:26 AM

Post #4 of 4 (1989 views)
Permalink

Re: cx18: CX23418 handles and releasing MDLs [In reply to]

On Sat, 2008-08-23 at 18:20 +0200, Hans Verkuil wrote:
> On Saturday 23 August 2008 17:52:05 Andy Walls wrote:
> > So without asking the CX23418 to release the MDLs at the end of a
> > capture, the CX23418 can later return a data buffer with a buffer id
> > in the wrong range for a stream type. cx18_queue_get_buf_irq() will
> > gripe when this happens and the data in that buffer will be wrongly
> > dropped.
> >
> > In cx23418.h, CX18_CPU_DE_ReleaseMDL is commented out. Is there a
> > problem with it, or is it OK to uncomment and use?
>
> I was never certain whether is was needed or not. The driver code I have
> didn't use it and the documentation is for all practical purposes
> non-existent. By all means, see if it fixes this issue. It was always
> my impression that the cx23418 automatically released all MDLs after
> the capture was stopped and the task destroyed. But I probably never
> have tested this particular scenario.

I can't get it to happen, but Brandon did:

[65288.817420] cx18-0: Cannot find buffer 58 for stream TS
[65288.817440] cx18-0: Could not find buf 58 for stream TS
[65840.130797] cx18-0: Cannot find buffer 17 for stream TS
[65840.130797] cx18-0: Could not find buf 17 for stream TS
[65861.882721] cx18-0: Cannot find buffer 48 for stream TS
[65861.882741] cx18-0: Could not find buf 48 for stream TS
[66151.627392] cx18-0: Cannot find buffer 107 for stream encoder MPEG
[66151.627392] cx18-0: Could not find buf 107 for stream encoder MPEG
[67632.953680] cx18-0: Cannot find buffer 99 for stream encoder MPEG
[67632.953680] cx18-0: Could not find buf 99 for stream encoder MPEG
[67795.527911] cx18-0: Cannot find buffer 106 for stream encoder MPEG
[67795.527911] cx18-0: Could not find buf 106 for stream encoder MPEG

Note the buffer id's are in the wrong range for the stream types

Regards,
Andy

> Regards,
>
> Hans
>
> >
> > Regards,
> > Andy
>
>

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads