lkml.org 
[lkml]   [2016]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
From
Date
On 02/16/2016 07:37 AM, tiffany lin wrote:
>>> +static int fops_vcodec_open(struct file *file)
>>> +{
>>> + struct video_device *vfd = video_devdata(file);
>>> + struct mtk_vcodec_dev *dev = video_drvdata(file);
>>> + struct mtk_vcodec_ctx *ctx = NULL;
>>> + int ret = 0;
>>> +
>>> + mutex_lock(&dev->dev_mutex);
>>> +
>>> + ctx = devm_kzalloc(&dev->plat_dev->dev, sizeof(*ctx), GFP_KERNEL);
>>> + if (!ctx) {
>>> + ret = -ENOMEM;
>>> + goto err_alloc;
>>> + }
>>> +
>>> + if (dev->num_instances >= MTK_VCODEC_MAX_ENCODER_INSTANCES) {
>>> + mtk_v4l2_err("Too many open contexts\n");
>>> + ret = -EBUSY;
>>> + goto err_no_ctx;
>>
>> Hmm. I never like it if you can't open a video node because of a reason like this.
>>
>> I.e. a simple 'v4l2-ctl -D' (i.e. calling QUERYCAP) should never fail.
>>
>> If there are hardware limitation that prevent more than X instances from running at
>> the same time, then those limitations typically kick in when you start to stream
>> (or possibly when calling REQBUFS). But before that it should always be possible to
>> open the device.
>>
>> Having this check at open() is an indication of a poor design.
>>
>> Is this is a hardware limitation at all?
>>
> This is to make sure performance meet requirements, such as bitrate and
> framerate.

Is it the driver's job to make enforce this? What if the application only
deals with low-res video, but wants to encode a lot of those? Or is encoding
a video off-line?

The driver generally doesn't know the use-case, so if this is an artificial
limitation as opposed to a hardware limitation, then I would just drop this.

Regards,

Hans

> We got your point. We will remove this and move limitation control to
> start_streaming or REQBUFS.
> Appreciated for your suggestion.:)
>
>
>>> + }

\
 
 \ /
  Last update: 2016-02-17 09:01    [W:0.155 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site