Hi all,
Jean Delvare has stated repeatedly that the I2C driver IDs will have to go.
However, one major user inside V4L2 are the VIDIOC_G_CHIP_IDENT and
VIDIOC_DBG_G/S_REGISTER ioctls.
These ioctls are meant as debugging and testing ioctls and (in the case of
G_CHIP_IDENT) for internal use in the kernel (e.g. a bridge driver that
needs to know which I2C chip variant is present).
These ioctls should not be used in applications and luckily this is indeed
the case. I scanned the major applications and did a google search and
everything came up clean.
I made the following changes:
#define V4L2_CHIP_MATCH_HOST 0 /* Match against chip ID on host (0
for the host) */
#define V4L2_CHIP_MATCH_I2C_DRIVER 1 /* Match against I2C driver name */
#define V4L2_CHIP_MATCH_I2C_ADDR 2 /* Match against I2C 7-bit address */
struct v4l2_match_info {
__u32 type; /* Match type */
union {
__u32 addr;
char name[32];
};
} __attribute__ ((packed));
struct v4l2_register {
struct v4l2_match_info match;
__u64 reg;
__u64 val;
} __attribute__ ((packed));
/* VIDIOC_DBG_G_CHIP_IDENT */
struct v4l2_chip_ident {
struct v4l2_match_info match;
__u32 ident;
__u32 revision;
} __attribute__ ((packed));
So the match will now be done against either a chip address or a driver
name.
I also added additional comments in videodev2.h, warning against ever using
it in applications:
#if 1 /*KEEP*/
/* Experimental, meant for debugging, testing and internal use.
Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
You must be root to use these ioctls. Never use these in applications! */
#define VIDIOC_DBG_S_REGISTER _IOW('V', 79, struct v4l2_register)
#define VIDIOC_DBG_G_REGISTER _IOWR('V', 80, struct v4l2_register)
/* Experimental, meant for debugging, testing and internal use.
Never use this ioctl in applications! */
#define VIDIOC_DBG_G_CHIP_IDENT _IOWR('V', 81, struct v4l2_chip_ident)
#endif
And VIDIOC_G_CHIP_IDENT was renamed to VIDIOC_DBG_G_CHIP_IDENT, again to
clearly mark this as a debugging API.
All this is available in this tree:
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-drvid
Now, the main question I have is whether I should keep the old
VIDIOC_G_CHIP_IDENT around for 2.6.29 with a big warning if someone tries
to use it, or do we just change it since 1) it is marked experimental and
for debugging purposes only, and 2) I cannot find a single application that
uses it and even Google throws up only a handful of pages.
Another question I have is for the omap developers: is it used in any omap
applications that I don't know about? I doubt it since the chip-ident
header is internal to the kernel so that's another reason why this ioctl is
very unlikely to be used in applications.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html