On 22/01/18 15:45, jacopo mondi wrote:
> Hi Hans,
>
> On Mon, Jan 22, 2018 at 11:18:50AM +0100, Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@xxxxxxxxx>
>>
>>
>
> [snip]
>
>> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
>> index 34676409ca08..92d695b29fa9 100644
>> --- a/drivers/media/platform/atmel/atmel-isc.c
>> +++ b/drivers/media/platform/atmel/atmel-isc.c
>> @@ -1417,20 +1417,14 @@ static int isc_g_parm(struct file *file, void *fh, struct v4l2_streamparm *a)
>> {
>> struct isc_device *isc = video_drvdata(file);
>>
>> - if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>> - return -EINVAL;
>> -
>> - return v4l2_subdev_call(isc->current_subdev->sd, video, g_parm, a);
>> + return v4l2_g_parm_cap(video_devdata(file), isc->current_subdev->sd, a);
>> }
>
> As I've reported in a comment to the CEU patch series, after having
> re-based my in-review driver on this series, I noticed I need to set
> a->parm.capture.readbuffers to 0, as my driver does not support
> CAP_READWRITE, and v4l2-compliance checks for (readbuffers == 0) if
> that's the case.
>
> As atmel-isc (and I suspect other drivers modified by this patch) does
> not support CAP_READWRITE, don't you need to set capturebuffers to 0
> as well in order not to v4l2-compliance unhappy?
See the v4l2_g_parm_cap code in the first patch: I test if CAP_READWRITE is
set and if not, then readbuffers is initialized to 0.
Regards,
Hans
>
> (I would have tested myself, but I don't have any of these platforms)
>
> Thanks
> j
>
