Hans Verkuil <hverkuil@xxxxxxxxx> writes:
> On 08/02/2016 08:03 PM, Robert Jarzmik wrote:
>> Hans Verkuil <hverkuil@xxxxxxxxx> writes:
>> [ 1509.773051] pxa27x-camera pxa27x-camera.0: s_fmt_vid_cap(pix=48x32:56595559)
>> [ 1509.777213] pxa27x-camera pxa27x-camera.0: current_fmt->fourcc: 0x56595559
>> RJK: Here we switch to 48x32 format
>>
>> [ 1509.777386] pxa27x-camera pxa27x-camera.0: pxac_vb2_queue_setup(vq=c312f290 nbufs=3 num_planes=0 size=614400)
>
> But this debug line indicates that pcdev->current_pix.sizeimage is still the old value: this
> should have been updated by the S_FMT call. You'd have to debug that a bit more, it looks like
> there is a bug somewhere in the driver.
>
> I suspect this line in pxac_vidioc_try_fmt_vid_cap:
> pix->sizeimage = max_t(u32, pix->sizeimage, ret);
>
> This should just be pix->sizeimage = ret.
Hi Hans and Laurent,
Thanks for pinpointing this one, that's exactly where the problem comes
from. I'm rerunning my capture tests as well as v4l2-compliance -s and
v4l2-compliance -f to be sure.
That leads me to a question for Laurent :
- in the commit bed8d8033037 ("[media] soc-camera: Honor user-requested
bytesperline and sizeimage")
- in the hunk
@@ -177,22 +178,22 @@ static int soc_camera_try_fmt(struct soc_camera_device *icd,
- you added this:
pix->sizeimage = max_t(u32, pix->sizeimage, ret);
As I blindly copied it from soc_camera.c to pxa_camera.c, I didn't pay attention
to it. I'd like to understand what this is for, why using the maximum of the
computed image size and imagesize instead of using directly the computed
imagesize, and if it is applicable to the pxa_camera case.
Thanks in advance.
--
Robert
--
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
