Mailing List Archive: cx18: YUV frame alignment improvements

cx18: YUV frame alignment improvements

Oct 31, 2009, 1:16 PM

Post #1 of 11 (6325 views)

All,

At

http://linuxtv.org/hg/~awalls/cx18-yuv

I have checked in some improvements to YUV handling in the cx18
driver.

There was a problem in that a lost/dropped buffer between the cx18
driver and the CX23418 firmware would cause the video frame alignment to
be lost with no easy way to recover.

These changes do the following:

1. Force YUV buffer sizes to be large enough to hold either 1 full 525
line system frame or 1 full 625 line system frame with new module
options and defaults. That makes the YUV buffers quite large, but
allows for "1 frame per buffer" for full sized video frames.

2. Not being able to allocate the now large YUV buffers is non-fatal.
The driver will still load and work for other stream types, even if it
can't get the YUV buffers. A warning is blurted out in the log, in case
YUV buffers can't be allocated.

3. __GFP_REPEAT has been added when trying to make the initial video
buffer allocations. After I added this, I never had the large YUV
buffers fail to be allocated.

4. We now lie to the firmware about the actual YUV buffer size, so that
the firmware always thinks the buffers are exactly large enough to hold
exactly an integral number of YUV frames based on the image height.
This means that dropped/lost YUV buffers between the cx18 driver and the
CX23418 firmware will only drop whole frames and no misalignment should
occur.

# modinfo cx18
[...]
parm: enc_yuv_buffers:Encoder YUV buffer memory (MB). (enc_yuv_bufs can override)
Default: 3 (int)
parm: enc_yuv_bufsize:Size of an encoder YUV buffer (kB)
Allowed values:
0 (do not allocate YUV buffers)
507 (when never capturing 625 line systems)
608 (when capturing 625 and/or 525 line systems)
Default: 608 (int)
parm: enc_yuv_bufs:Number of encoder YUV buffers
Default is computed from other enc_yuv_* parameters (int)
[...]

# modprobe cx18
# mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc

You can add 'debug=264' to the modprobe line to watch the size of the
payloads coming back from the firmware to make sure they are an integral
number of frames, but logging stats on every noticably degrades
performance.

Regards,
Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

dheitmueller at kernellabs

Oct 31, 2009, 1:28 PM

Post #2 of 11 (6197 views)

Permalink

On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls@radix.net> wrote:
> All,
>
> At
>
> http://linuxtv.org/hg/~awalls/cx18-yuv
>
> I have checked in some improvements to YUV handling in the cx18
> driver.
>
> There was a problem in that a lost/dropped buffer between the cx18
> driver and the CX23418 firmware would cause the video frame alignment to
> be lost with no easy way to recover.
>
> These changes do the following:
>
> 1. Force YUV buffer sizes to be large enough to hold either 1 full 525
> line system frame or 1 full 625 line system frame with new module
> options and defaults. That makes the YUV buffers quite large, but
> allows for "1 frame per buffer" for full sized video frames.
>
> 2. Not being able to allocate the now large YUV buffers is non-fatal.
> The driver will still load and work for other stream types, even if it
> can't get the YUV buffers. A warning is blurted out in the log, in case
> YUV buffers can't be allocated.
>
> 3. __GFP_REPEAT has been added when trying to make the initial video
> buffer allocations. After I added this, I never had the large YUV
> buffers fail to be allocated.
>
> 4. We now lie to the firmware about the actual YUV buffer size, so that
> the firmware always thinks the buffers are exactly large enough to hold
> exactly an integral number of YUV frames based on the image height.
> This means that dropped/lost YUV buffers between the cx18 driver and the
> CX23418 firmware will only drop whole frames and no misalignment should
> occur.
>
>
> # modinfo cx18
> [...]
> parm: enc_yuv_buffers:Encoder YUV buffer memory (MB). (enc_yuv_bufs can override)
> Default: 3 (int)
> parm: enc_yuv_bufsize:Size of an encoder YUV buffer (kB)
> Allowed values:
> 0 (do not allocate YUV buffers)
> 507 (when never capturing 625 line systems)
> 608 (when capturing 625 and/or 525 line systems)
> Default: 608 (int)
> parm: enc_yuv_bufs:Number of encoder YUV buffers
> Default is computed from other enc_yuv_* parameters (int)
> [...]
>
> # modprobe cx18
> # mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc
>
>
> You can add 'debug=264' to the modprobe line to watch the size of the
> payloads coming back from the firmware to make sure they are an integral
> number of frames, but logging stats on every noticably degrades
> performance.
>
> Regards,
> Andy

Hi Andy,

How does this code work if the cx23418 scaler is used (resulting in
the size of the frames to be non-constant)? Or is the scaler not
currently supported in the driver?

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

awalls at radix

Oct 31, 2009, 5:38 PM

Post #3 of 11 (6188 views)

Permalink

On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls@radix.net> wrote:
> > All,
> >
> > At
> >
> > http://linuxtv.org/hg/~awalls/cx18-yuv
> >
> > I have checked in some improvements to YUV handling in the cx18
> > driver.

> > Andy
>
> Hi Andy,
>
> How does this code work if the cx23418 scaler is used (resulting in
> the size of the frames to be non-constant)? Or is the scaler not
> currently supported in the driver?

It is designed to fit as many integral frames as possible into the YUV
buffers. It should work with the scaler. I have not tested it though.
I also have note tested scaling to much aside from down to 480x480 with
MPEG as this is the MythTV default.

Please note that with the HM12 macroblock format, the height must be a
multiple of 32 lines (IIRC) so you'll have full blocks to decode. See
the README.hm12 under Documentation somewhere.

Regards,
Andy

> Devin

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

awalls at radix

Oct 31, 2009, 5:41 PM

Post #4 of 11 (6183 views)

Permalink

On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls@radix.net> wrote:

>
> Hi Andy,
>
> How does this code work if the cx23418 scaler is used (resulting in
> the size of the frames to be non-constant)? Or is the scaler not
> currently supported in the driver?

I also forgot to mention, changing size while the encoder has an analog
stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
So this change works just fine as it computes the buffer size to use
just as it sets up to start the capture.

Regards,
Andy

>
> Devin
>

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

bcjenkins at tvwhere

Oct 31, 2009, 7:25 PM

Post #5 of 11 (6175 views)

Permalink

On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls <awalls@radix.net> wrote:
> On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
>> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls@radix.net> wrote:
>
>>
>> Hi Andy,
>>
>> How does this code work if the cx23418 scaler is used (resulting in
>> the size of the frames to be non-constant)? Or is the scaler not
>> currently supported in the driver?
>
> I also forgot to mention, changing size while the encoder has an analog
> stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
> So this change works just fine as it computes the buffer size to use
> just as it sets up to start the capture.
>
> Regards,
> Andy
>
>>
>> Devin
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Hi Andy,

I tried to pull your changes and received an error on a missing .hg.
Subsequently, I downloaded the bz2 file and upon reboot I received a
kernel panic due to DMA issues.

Brandon

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

awalls at radix

Nov 1, 2009, 4:37 AM

Post #6 of 11 (6160 views)

Permalink

On Sat, 2009-10-31 at 22:25 -0400, Brandon Jenkins wrote:
> On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls <awalls@radix.net> wrote:
> > On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> >> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls@radix.net> wrote:
> >
> >>
> >> Hi Andy,
> >>
> >> How does this code work if the cx23418 scaler is used (resulting in
> >> the size of the frames to be non-constant)? Or is the scaler not
> >> currently supported in the driver?
> >
> > I also forgot to mention, changing size while the encoder has an analog
> > stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
> > So this change works just fine as it computes the buffer size to use
> > just as it sets up to start the capture.
> >
> > Regards,
> > Andy

> Hi Andy,

Hi Brandon,

> I tried to pull your changes and received an error on a missing .hg.

Sorry, I can't help there. The following should work:

hg clone http://linuxtv.org/hg/~awalls/cx18-yuv

> Subsequently, I downloaded the bz2 file and upon reboot I received a
> kernel panic due to DMA issues.

Did it fail on MPEG or Digital TS captures or on a YUV capture?

Did you try setting enc_yuv_bufs=0, to inhibit YUV buffer allocation, to
see if the panic went away?

Could you provide the panic to me? Off-list is fine.

If I can't get this large buffer scheme to work for the general case to
mainatin YUV frame alignment, I'll have to figure out what will likely
be a much more complex scheme to ensure alignment is maintained in for
YUV streams. :(

Oh, well.

Regards,
Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

bcjenkins at tvwhere

Nov 1, 2009, 10:10 AM

Post #7 of 11 (6167 views)

Permalink

On Sun, Nov 1, 2009 at 7:37 AM, Andy Walls <awalls@radix.net> wrote:
> On Sat, 2009-10-31 at 22:25 -0400, Brandon Jenkins wrote:
>> On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls <awalls@radix.net> wrote:
>> > On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
>> >> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls@radix.net> wrote:
>> >
>> >>
>> >> Hi Andy,
>> >>
>> >> How does this code work if the cx23418 scaler is used (resulting in
>> >> the size of the frames to be non-constant)? Or is the scaler not
>> >> currently supported in the driver?
>> >
>> > I also forgot to mention, changing size while the encoder has an analog
>> > stream running (MPEG, VBI, YUV, IDX) is not permitted by the firmware.
>> > So this change works just fine as it computes the buffer size to use
>> > just as it sets up to start the capture.
>> >
>> > Regards,
>> > Andy
>
>> Hi Andy,
>
> Hi Brandon,
>
>> I tried to pull your changes and received an error on a missing .hg.
>
> Sorry, I can't help there. The following should work:
>
> hg clone http://linuxtv.org/hg/~awalls/cx18-yuv
>
>
>> Subsequently, I downloaded the bz2 file and upon reboot I received a
>> kernel panic due to DMA issues.
>
> Did it fail on MPEG or Digital TS captures or on a YUV capture?
>
> Did you try setting enc_yuv_bufs=0, to inhibit YUV buffer allocation, to
> see if the panic went away?
>
> Could you provide the panic to me? Off-list is fine.
>
> If I can't get this large buffer scheme to work for the general case to
> mainatin YUV frame alignment, I'll have to figure out what will likely
> be a much more complex scheme to ensure alignment is maintained in for
> YUV streams. :(
>
> Oh, well.
>
> Regards,
> Andy
>
>
>
Hi Andy,

The panic happens upon reboot and it is only 1 line of text oddly shifted.

Kernel panic - not syncing: DMA: Memory would be corrupted

If I switch back to the current v4l-dvb drivers no issue. To switch
back I have to boot from a USB drive.

Brandon

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

awalls at radix

Nov 1, 2009, 2:59 PM

Post #8 of 11 (6169 views)

Permalink

On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote:
> On Sun, Nov 1, 2009 at 7:37 AM, Andy Walls <awalls@radix.net> wrote:
> > On Sat, 2009-10-31 at 22:25 -0400, Brandon Jenkins wrote:
> >> On Sat, Oct 31, 2009 at 8:41 PM, Andy Walls <awalls@radix.net> wrote:
> >> > On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote:
> >> >> On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls <awalls@radix.net> wrote:

> > Could you provide the panic to me? Off-list is fine.
> >
> > If I can't get this large buffer scheme to work for the general case to
> > mainatin YUV frame alignment, I'll have to figure out what will likely
> > be a much more complex scheme to ensure alignment is maintained in for
> > YUV streams. :(
> >
> > Oh, well.
> >
> > Regards,
> > Andy
> >
> >
> >
> Hi Andy,
>
> The panic happens upon reboot and it is only 1 line of text oddly shifted.
>
> Kernel panic - not syncing: DMA: Memory would be corrupted
>
> If I switch back to the current v4l-dvb drivers no issue. To switch
> back I have to boot from a USB drive.

Brandon,

Eww. OK. Nevermind performing any more data collection. I'm going to
use a new strategy (when I find the time).

(Thinking out loud ...)
Working under the assumptions that:

1. The encoder always returns 720 pixels worth of data per line (no
matter what the scaling)

2. The software HM12 decoders can only deal with full, not partial,
16x8x2 UV macroblocks at 4:2:0, so scaled YUV height needs to be in
multiples of 32 lines

3. The CX23418 actually can handle Memory Descriptor Lists (MDLs) with
more than one buffer per list

I'm going to use the MDLs to actually hold buffer lists with multiple
buffers, where individual buffers are 720 * 32 * 3 / 2 = 33.75 kB each.
That way I can build up buffer lists to hold precisely one frame of YUV
data at a time, no matter what the scaling, and then know that if the
cx18 driver misses an incoming MDL notification, the YUV frames will
stay aligned. The 33.75 kB buffers should be no problem from a DMA
perspective, compared to 607.5 kB buffers.

The pain is that the cx18 driver right now has the hard-coded assumption
that there is only one buffer per MDL. It will take a bit of effort to
fix that assumption in the driver and generalize it to having 1 or more
buffers per MDL.

Anyway, thanks for the testing.

Regards,
Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

awalls at radix

Nov 1, 2009, 3:15 PM

Post #9 of 11 (6147 views)

Permalink

On Sun, 2009-11-01 at 17:59 -0500, Andy Walls wrote:
> On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote:
> > Hi Andy,
> >
> > The panic happens upon reboot and it is only 1 line of text oddly shifted.
> >
> > Kernel panic - not syncing: DMA: Memory would be corrupted
> >
> > If I switch back to the current v4l-dvb drivers no issue. To switch
> > back I have to boot from a USB drive.
>
> Brandon,
>
> Eww. OK. Nevermind performing any more data collection. I'm going to
> use a new strategy (when I find the time).

I forgot to mention that the panic you are running into is in the
Software IO Memory Managment Unit Translate Look-aside Buffer (SW IOMMU
TLB) in

linux/lib/swiotlb.c

Your machine must not have a hardware IO MMU (and mine must).

The software IOMMU is trying to allocate a bounce buffer for DMA and it
can't get one of the needed size (i.e. 607.5 kB) and the fallback static
buffer isn't big enough either (it is only 32 kB). That's why the panic
happens.

This certainly means that, in the general linux user case, very large
DMA buffers are bad.

So now I know....

Regards,
Andy

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

bcjenkins at tvwhere

Nov 3, 2009, 9:06 AM

Post #10 of 11 (6129 views)

Permalink

On Sun, Nov 1, 2009 at 6:15 PM, Andy Walls <awalls@radix.net> wrote:
> On Sun, 2009-11-01 at 17:59 -0500, Andy Walls wrote:
>> On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote:
>> > Hi Andy,
>> >
>> > The panic happens upon reboot and it is only 1 line of text oddly shifted.
>> >
>> > Kernel panic - not syncing: DMA: Memory would be corrupted
>> >
>> > If I switch back to the current v4l-dvb drivers no issue. To switch
>> > back I have to boot from a USB drive.
>>
>> Brandon,
>>
>> Eww. OK. Nevermind performing any more data collection. I'm going to
>> use a new strategy (when I find the time).
>
> I forgot to mention that the panic you are running into is in the
> Software IO Memory Managment Unit Translate Look-aside Buffer (SW IOMMU
> TLB) in
>
> linux/lib/swiotlb.c
>
> Your machine must not have a hardware IO MMU (and mine must).
>
> The software IOMMU is trying to allocate a bounce buffer for DMA and it
> can't get one of the needed size (i.e. 607.5 kB) and the fallback static
> buffer isn't big enough either (it is only 32 kB). That's why the panic
> happens.
>
> This certainly means that, in the general linux user case, very large
> DMA buffers are bad.
>
> So now I know....
>
>
> Regards,
> Andy
>
>
Hi Andy,

How would I know if I have/don't have a HW IO MMU and maybe isn't
enabled correctly? Separately, I also have three cards running too.

Brandon

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Re: cx18: YUV frame alignment improvements [ In reply to ]

awalls at radix

Nov 3, 2009, 6:52 PM

Post #11 of 11 (6103 views)

Permalink

On Tue, 2009-11-03 at 12:06 -0500, Brandon Jenkins wrote:
> On Sun, Nov 1, 2009 at 6:15 PM, Andy Walls <awalls@radix.net> wrote:
> > On Sun, 2009-11-01 at 17:59 -0500, Andy Walls wrote:
> >> On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote:
> >> > Hi Andy,
> >> >
> >> > The panic happens upon reboot and it is only 1 line of text oddly shifted.
> >> >
> >> > Kernel panic - not syncing: DMA: Memory would be corrupted
> >> >
> >> > If I switch back to the current v4l-dvb drivers no issue. To switch
> >> > back I have to boot from a USB drive.
> >>
> >> Brandon,
> >>
> >> Eww. OK. Nevermind performing any more data collection. I'm going to
> >> use a new strategy (when I find the time).
> >
> > I forgot to mention that the panic you are running into is in the
> > Software IO Memory Managment Unit Translate Look-aside Buffer (SW IOMMU
> > TLB) in
> >
> > linux/lib/swiotlb.c
> >
> > Your machine must not have a hardware IO MMU (and mine must).
> >
> > The software IOMMU is trying to allocate a bounce buffer for DMA and it
> > can't get one of the needed size (i.e. 607.5 kB) and the fallback static
> > buffer isn't big enough either (it is only 32 kB). That's why the panic
> > happens.
> >
> > This certainly means that, in the general linux user case, very large
> > DMA buffers are bad.
> >
> > So now I know....
> >
> >
> > Regards,
> > Andy
> >
> >
> Hi Andy,
>
> How would I know if I have/don't have a HW IO MMU and maybe isn't
> enabled correctly?

There's no simple way AFAICT, except for believing that kernel couldn't
find one.

You'll have to research your motherboard's chipset and determine if the
chipset has one. Chip vendors have IOMMU's as part of larger
specifications:

http://en.wikipedia.org/wiki/IOMMU

Linux has some detection code on startup for IOMMU's it knows about,
provided you've configured the IOMMU support in the kernel. Check your
kernel config I guess.

Also check your BIOS for anymention of an IOMMU there.

> Separately, I also have three cards running too.

3 times as many buffer allocations would exacerbate the ability to find
large contiguous memory buffers in PCI device DMA-able memory.

The CX23418 firmware is smart enough to use scatter gather type lists of
buffers (called MDLs by the firmware); I just need to fix the cx18
driver to use them as such.

Regards,
Andy

> Brandon

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel