Hi,
Guennadi Liakhovetski wrote:
> On Wed, 18 May 2011, Laurent Pinchart wrote:
>
>> On Friday 13 May 2011 09:45:51 Guennadi Liakhovetski wrote:
>
> [snip]
>
>>> 2. Both these flags should not be passed with CREATE, but with SUBMIT
>>> (which will be renamed to PREPARE or something similar). It should be
>>> possible to prepare the same buffer with different cacheing attributes
>>> during a running operation. Shall these flags be added to values, taken by
>>> struct v4l2_buffer::flags, since that is the struct, that will be used as
>>> the argument for the new version of the SUBMIT ioctl()?
>>
>> Do you have a use case for per-submit cache handling ?
>
> This was Sakari's idea, I think, ask him;) But I think, he suggested a
> case, when not all buffers have to be processed in the user-space. In
> principle, I can imagine such a case too. E.g., if most of the buffers you
> pass directly to output / further processing, and only some of them you
> analyse in software, perhaps, for some WB, exposure, etc.
Yes; I think I mentioned this. It's possible that some rather
CPU-intensive processing is only done on the CPU on every n:th image,
for example. In this case flushing the cache on images that won't be
touched by the CPU is not necessary.
>>>> +
>>>> +/* VIDIOC_CREATE_BUFS */
>>>> +struct v4l2_create_buffers {
>>>> + __u32 index; /* output: buffers index...index + count - 1 have
>> been
>>>> created */ + __u32 count;
>>>> + __u32 flags; /* V4L2_BUFFER_FLAG_* */
>>>> + enum v4l2_memory memory;
>>>> + __u32 size; /* Explicit size, e.g., for compressed streams */
>>>> + struct v4l2_format format; /* "type" is used always, the rest if
>> size
>>>> == 0 */ +};
>>>
>>> 1. Care must be taken to keep index <= V4L2_MAX_FRAME
>>
>> Does that requirement still make sense ?
>
> Don't know, again, not my idea. videobuf2-core still uses it. At one
> location it seems to be pretty arbitrary, at another it is the size of an
> array in struct vb2_fileio_data, but maybe we could allocate that one
> dynamically too. So, do I understand it right, that this would affect our
> case, if we would CREATE our buffers and then the user would decide to do
> read() / write() on them?
My issue with this number, as I gave it a little more thought, is that
it is actually quite low. The devices will have more memory in the
future and 32 might become a real limitation. I think it would be wise
to define the API so that the number of simultaneous buffers allocated
on a device is not limited by this number.
Kind regards,
--
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
