On 01/25/2017 08:15 PM, Niklas Söderlund wrote:
> Hi Hans,
>
> I have noticed an odd printout when running v4l2-compliance while
> testing the rcar-vin driver. When testing (v4l2-compliance -d 0) on
> ARM64 I see the following messages:
>
> [ 1411.016069] compat_ioctl32: unexpected VIDIOC_FMT1 type 0
> [ 1411.022981] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> [ 1411.033152] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
> [ 1411.043283] compat_ioctl32: unexpected VIDIOC_FMT1 type 128
>
> Running the same rcar-vin driver on ARM and I see no such messages.
> There can of course be problems with my driver but after digging around
> a bit I'm a bit confused, maybe you can help me understand where the
> true problem is.
>
> In the kernel the messages originate from __get_v4l2_format32() in
> drivers/media/v4l2-core/v4l2-compat-ioctl32.c and they are printed if
> the format type is unknown, that is is not one of the specified ones in
> a switch statement. That is all entries of enum v4l2_buf_type except
> V4L2_BUF_TYPE_PRIVATE.
>
> enum v4l2_buf_type {
> V4L2_BUF_TYPE_VIDEO_CAPTURE = 1,
> V4L2_BUF_TYPE_VIDEO_OUTPUT = 2,
> V4L2_BUF_TYPE_VIDEO_OVERLAY = 3,
> V4L2_BUF_TYPE_VBI_CAPTURE = 4,
> V4L2_BUF_TYPE_VBI_OUTPUT = 5,
> V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6,
> V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7,
> V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10,
> V4L2_BUF_TYPE_SDR_CAPTURE = 11,
> V4L2_BUF_TYPE_SDR_OUTPUT = 12,
> /* Deprecated, do not use */
> V4L2_BUF_TYPE_PRIVATE = 0x80,
> };
>
>
> In v4l2-compliance the message is trigged inside testGetFormats() from
> utils/v4l2-compliance/v4l2-test-formats.cpp by:
>
> for (type = 0; type <= V4L2_BUF_TYPE_LAST; type++) {
> createInvalidFmt(fmt, clip, type);
> ret = doioctl(node, VIDIOC_G_FMT, &fmt);
>
> ....
> }
>
> Here V4L2_BUF_TYPE_LAST is defined to V4L2_BUF_TYPE_SDR_OUTPUT and the
> enum struct is the same as in the kernel since it's included from
> include/linux/videodev2.h. One format is created with type = 0 and one
> with type = 128 which is why the messages gets printed by the kernel.
>
> Is this something I should somehow handle in my driver (I can't see how
> I could even do that)? Or is it expected that v4l2-compliance
> should provoke this messages in order to test the API and I should not
> worry about the messages when using v4l2-compliance?
>
Those messages really should be pr_debug instead of pr_info. The idea is
that when a new format type is added, then that should also be supported
in the 32-bit compat code. The warning helps identifying this.
However, the compliance test has a few tests with incorrect type values to
check that the driver handle those correctly (returns EINVAL), so those
tests trigger the compat code messages.
It's harmless, and you only get them when running a 32-bit v4l2-compliance
on a 64-bit system.
Regards,
Hans
--
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
