search

SolidRun / linux-fslc

Linux kernel source tree
Other
12 stars 27 forks source link

Fix and optimise IPU deinterlacing code #57

Closed warped-rudi closed 6 years ago

warped-rudi commented 6 years ago

The primary motivation for this patch set is that when the IPU is used for deinterlacing (Kodi 17), there are certain files where the kernel log gets spammed massively with messages: imx-ipuv3 2x00000.ipu: [0xXXXXXXXX] vdi_save_line error This happens because _vdi_savelines == 0 is treated as an error which it is not. The problem also exists in 3.14, but I did not notice it until recently. While analysing the the code, I stumbled over some more glitches which were addressed in the three following patches.

P.S.: It might be possible to get rid of that ugly vdi_split_process() function by reordering the stripe processing. However, I did not do this because I don't overlook the consequences when this is combined with flipping or rotation and I don't have enough test cases to verify that it fully works.

jnettlet commented 6 years ago

Will look at this today. Sorry about the delay.

warped-rudi commented 6 years ago

Please don't merge this right now. I'm seeing a strange crash here in the function that is modified by the patch. Even though it doesn't look like it is caused by this modification. Please take a look at ipu_device.c, line 2480. For some reason, page_address() will return zero with the recent kernel. Do you have any idea why? Actually I got some more strange things going on here: /proc/meminfo reports very low free CMA. So I'm wondering what consumes more than 300M when the system has just booted into Kodi with not a single video played. Furthermore I get memory alloc failures when trying to play HD videos (the message suggest to set a larger 'vmalloc=...' on kernel command line, which actually helped). But VmallocUsed as shown by /proc/meminfo is 0.

warped-rudi commented 6 years ago

I've added a patch that spits out "Failed get virtual address" messages instead of crashing. Of course this doesn't cure the reason for the misbehaviour.

jnettlet commented 6 years ago

I have been sorting through this over the weekend. In the newer 4.x kernels there is a balance between CMA, VMALLOC, and lowmem that needs to be addressed. We use a 3/1 Highmem/Lowmem split which means that VMALLOC, and CMA both sit in that initial 1GB of memory. Which is fine, but by ramping up CMA to 512MB you can quickly starve the kernel of memory.

Instead of just allocating one big CMA area I am looking into allocating different CMA pools that I can put different drivers in. Hopefully this will help compartmentalize the memory usage. I also see that NXP has added a new CMA memory allocator for the galcore driver that I think needs some work.

warped-rudi commented 6 years ago

I'm closing this pull request as it is trying to fix a problem in a piece of code that is an ugly hack by itself and does not work correctly on newer 4.9.x kernels.