diff options
author | Trent Piepho <xyzzy@speakeasy.org> | 2007-07-17 18:29:42 -0300 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@infradead.org> | 2007-07-30 16:26:23 -0300 |
commit | c812b67ca4ed13fa5ec60f06c4ed8f648722a186 (patch) | |
tree | f01921a78e2f0a46d2a154430b8e7afc42ef277b /drivers/acpi/utilities/utcopy.c | |
parent | 9c837fb692b005203765d8a569a2fe43fdff9df1 (diff) | |
download | kernel-crypto-c812b67ca4ed13fa5ec60f06c4ed8f648722a186.tar.gz kernel-crypto-c812b67ca4ed13fa5ec60f06c4ed8f648722a186.tar.xz kernel-crypto-c812b67ca4ed13fa5ec60f06c4ed8f648722a186.zip |
V4L/DVB (5886): zr36067: Fix problem setting norms
The zr36067 driver doesn't make a distinction between the different sub-types
of NTSC, PAL, or SECAM norms. For example, when the enum std ioctl returns
the PAL standard it returns PAL_BG|PAL_DK|PAL_H|PAL_I.
When setting the norm, it required the bitmask to match exactly the set of
norms used during the enumeration. If just one norm was specified, for
example PAL_BG or NTSC_M, it would fail. This violates the V4L2 spec,
"VIDIOC_S_STD accepts *one* or more flags..."
The key thing to realize is that V4L2_STD_PAL is not one bit, it is multiple
bits. It's ok to call S_STD with any *one* of those bits, but the driver was
requiring *all* of them.
This fixes the S_STD function so that it will accept any set of one or more
PAL norms as PAL, and the same for NTSC and SECAM.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Acked-by: Ronald S. Bultje <rbultje@ronald.bitfreak.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Diffstat (limited to 'drivers/acpi/utilities/utcopy.c')
0 files changed, 0 insertions, 0 deletions