Re: cx18: YUV frame alignment improvements
On Sun, Nov 1, 2009 at 6:15 PM, Andy Walls awa...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
On Tue, 2009-11-03 at 12:06 -0500, Brandon Jenkins wrote: On Sun, Nov 1, 2009 at 6:15 PM, Andy Walls awa...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
On Sun, Nov 1, 2009 at 7:37 AM, Andy Walls awa...@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 awa...@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 awa...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
On Sun, 2009-11-01 at 13:10 -0500, Brandon Jenkins wrote: On Sun, Nov 1, 2009 at 7:37 AM, Andy Walls awa...@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 awa...@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 awa...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx18: YUV frame alignment improvements
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls awa...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote: On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls awa...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: YUV frame alignment improvements
On Sat, 2009-10-31 at 16:28 -0400, Devin Heitmueller wrote: On Sat, Oct 31, 2009 at 4:16 PM, Andy Walls awa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
