Re: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

Le 2014-10-08 06:24, Kamil Debski a écrit :
> Hi,
>
> This patch seems complicated and I do not understand your motives.
>
> Could you explain what is the problem with the current aligning of the
> values?
> Is this a hardware problem? Which MFC version does it affect?
> Is it a software problem? If so, maybe the user space application should
> take extra care on what value it passes/receives to try_fmt?
This looks like something I wanted to bring here as an RFC but never 
manage to get the time. In an Odroid Integration we have started using 
the following simple patch to work around this:

https://github.com/dsd/linux-odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6

The context is that right now we have decided that alignment in s_fmt 
shall be done with a closest rounding. So the format returned may be 
bigger, or smaller, that's basically random. I've been digging through a 
lot, and so far I have found no rational that explains this choice other 
that this felt right.

In real life, whenever the resulting format is smaller then request, 
there is little we can do other then fail or try again blindly other 
sizes. But with bigger raw buffers, we can use zero-copy  cropping 
techniques to keep going. Here's a example:

image_generator -> hw_converter -> display

As hw_converter is a V4L2 M2M, an ideal use case here would be for 
image_generator to use buffers from the hw_converter. For the scenario, 
it is likely that a fixed video size is wanted, but this size is also 
likely not to match HW requirement. If hw_converter decide to give back 
something smaller, there is nothing image_generator can do. It would 
have to try again with random size to find out that best match. It's a 
bit silly to force that on application, as the hw_converter know the 
closest best match, which is simply the next valid bigger size if that 
exist.

hope that helps,
Nicolas