Documentation issues with some MBUS flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sylwester/Sakari,

While checking the docs for the V4L2 framework, I noticed something weird
Related to those two flags:

#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX                (1U << 0)
#define V4L2_MBUS_FRAME_DESC_FL_BLOB           (1U << 1)

They were originally introduced by this changeset:

commit 291031192426bfc6ad4ab2eb9fa986025a926598
Author: Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx>
Date:   Thu May 17 14:33:30 2012 -0300

    [media] V4L: Add [get/set]_frame_desc subdev callbacks
    
    Add subdev callbacks for setting up parameters of the frame on media bus
    that are not exposed to user space directly. This is just an initial,
    mostly stub implementation. struct v4l2_mbus_frame_desc is intended
    to be extended with sub-structures specific to a particular hardware media
    bus. For now these new callbacks are used only to query or specify maximum
    size of a compressed or hybrid (container) media bus frame in octets.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx>
    Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>

And the comments were modified by this one:

commit 174d6a39b07f51212c23a8e30a0440598d18392c
Author: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
Date:   Wed Dec 18 08:40:28 2013 -0300

    [media] v4l: V4L2_MBUS_FRAME_DESC_FL_BLOB is about 1D DMA
    
    V4L2_MBUS_FRAME_DESC_FL_BLOB intends to say the receiver must use 1D DMA to
    receive the image, as the format does not have line offsets. This typically
    includes all compressed formats.
    
    Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
    Cc: Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>

The problem is that the description of V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
says that:
	Indicates the @length field specifies maximum data length.

But the description of the @length field says otherwise:
	* @length: number of octets per frame, valid if V4L2_MBUS_FRAME_DESC_FL_BLOB

So, I decided to take a look on what the heck is that:

	$ git grep V4L2_MBUS_FRAME_DESC_FL_BLOB
	include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_BLOB                (1U << 1)
	include/media/v4l2-subdev.h: *                    %V4L2_MBUS_FRAME_DESC_FL_BLOB.
	include/media/v4l2-subdev.h: * @length: number of octets per frame, valid if V4L2_MBUS_FRAME_DESC_FL_BLOB

(nobody is using it)

And:

	$ git grep V4L2_MBUS_FRAME_DESC_FL_LEN_MAX
	drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
	drivers/media/i2c/m5mols/m5mols_core.c: fd->entry[0].flags = V4L2_MBUS_FRAME_DESC_FL_LEN_MAX;
	include/media/v4l2-subdev.h:#define V4L2_MBUS_FRAME_DESC_FL_LEN_MAX             (1U << 0)

Only one driver is using it.

So, I'm thinking if are there any reason why to keep the
V4L2_MBUS_FRAME_DESC_FL_BLOB, and what's the expected behavior
when V4L2_MBUS_FRAME_DESC_FL_LEN_MAX is found.

Could you shed some light?

Thanks!
Mauro

Thanks,
Mauro
--
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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux