Hi Hans,
On Mon, Jan 22, 2018 at 03:48:17PM +0100, Hans Verkuil wrote:
> 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.
>
Uh, I'm sorry, that's different from the series that was on patchwork
yesterday! I'll rebase and test with CEU.
Thanks
j
