The code in em28xx_vbi_copy can be simplified a lot.
Also rename some variables to something more meaningful and fix+add the
function descriptions.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx_urb_data_copy() actually consists of two parts:
USB urb processing (checks, data extraction) and frame data packet processing.
Move the latter to a separate function and call it from em28xx_urb_data_copy()
for each data packet.
The em25xx, em2760, em2765 (and likely em277x) chip variants are using a
different frame data format, for which support will be added later with
another function.
This reduces the size of em28xx_urb_data_copy() and makes the code much more
readable. While we're at it, clean up the code a bit (rename some variables to
something more meaningful, improve some comments etc.)
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reduce code duplication by moving the duplicate code for dev->capture_type=0
(vbi start) and dev->capture_type=2 (video start) to a function.
The same function will also be called by the (not yet existing) em25xx frame
data processing code.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the current code em28xx_urb_data_copy() caches the pointer to the vmalloc
memory in videobuf locally.
The alternative would be to call videobuf_to_vmalloc() for each processed USB
data packet (isoc USB transfers => 64 times per URB) in the em28xx_copy_*()
functions.
With the next commits, the data processing code will be split into functions
for serveral reasons:
- em28xx_urb_data_copy() is generally way to long, making it less readable
- there is code duplication between VBI and video data processing
- support for em25xx data processing (uses a different header and frame
end signaling mechanism) will be added
This would require extensive usage of pointer-pointers, which usually makes the
code less readable and prone to bugs.
The better solution is to cache the pointer in struct em28xx_buffer.
This also improves consistency, because we already track the buffer fill count there.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When a new frame header is detected in em28xx_urb_data_copy() and the data
packet contains both, VBI data and video data, the prevoius VBI buffer doesn't
get finished and is overwritten with the new VBI data.
This bug is not triggered with isochronous USB transfers, because the data
packetes are much smaller than the VBI data size.
But when using USB bulk transfers, the whole data of an URB is treated as
single packet, which is usually much larger then the VBI data size.
Refactor the VBI data processing code to fix this bug, but also to simplify the
code and make it similar to the video data processing code part (which allows
further code abstraction/unification in the future).
The changes have been tested with device "Hauppauge HVR-900".
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This field is used to keep track of the current memory position in the buffer,
not in the dma queue, so move it to right place.
This also allows us to get rid of the struct em28xx_dmaqueue pointer parameter
in functions em28xx_copy_video() and em28xx_copy_vbi().
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
get_next_buf() and vbi_get_next_buf() do exactly the same just with a
different dma queue and buffer. Saving the new buffer pointer back to the
device struct in em28xx_urb_data_copy() instead of doing this from inside
these functions makes it possible to get rid of one of them.
Also refactor the function parameters and return type:
- pass a pointer to struct em28xx as parameter (instead of obtaining the
pointer from the dma queue pointer with the container_of macro) like we do
it in all other functions
- instead of using a pointer-pointer, return the pointer to the new buffer
as return value of the function
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx_urb_data_copy_vbi() is actually an extended version of
em28xx_urb_data_copy(). With the preceding fixes and improvements, it works
fine with both, vbi and non-vbi data streams without performance impacts.
So rename em28xx_urb_data_copy_vbi() to em28xx_urb_data_copy(), delete the
the old implementation of em28xx_urb_data_copy() and change the code to use
this function for both data stream types.
Tested with "SilverCrest 1.3 MPix webcam" (progressive, non-vbi) and
"Hauppauge HVR-900 (65008/A1C0)" (interlaced, vbi enabled and disabled).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Set capture type to 1 (video start) when the video frame start header is
detected. This bug didn't cause any trouble, because this type of header is
never received in vbi mode.
Fix it, because we want to use this function with disabled vbi in the future.
Also start with capture type -1 to avoid processing of corrupted/incomplete
frame data which is usually received at streaming start (especially when
USB bulk transfers are used).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The header check/removal code at the end of function em28xx_urb_data_copy_vbi()
is obsolete, because this is already done earlier in this function.
In fact it is incomplete (doesn't check for vbi header) and causes trouble
when the first data bytes are the same as header bytes (which is fortunately
very unlikely).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
By default, isoc transfers are used if possible.
With the new module parameter, bulk can be selected as the
preferred USB transfer type.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The current enpoint logic ignores all bulk endpoints and uses
a fixed mapping between endpint addresses and the supported
data stream types (analog/audio/DVB):
Ep 0x82, isoc => analog
Ep 0x83, isoc => audio
Ep 0x84, isoc => DVB
Now that the code can also do bulk transfers, the endpoint
logic has to be extended to also consider bulk endpoints.
The new logic preserves backwards compatibility and reflects
the endpoint configurations we have seen so far:
Ep 0x82, isoc => analog
Ep 0x82, bulk => analog
Ep 0x83, isoc* => audio
Ep 0x84, isoc => digital
Ep 0x84, bulk => analog or digital**
(*: audio should always be isoc)
(**: analog, if ep 0x82 is isoc, otherwise digital)
[mchehab@redhat.com: Fix a CodingStyle issue: don't break strings
into separate lines]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Extend function em28xx_set_alternate:
- use alternate setting 0 for bulk transfers as default
- respect module parameter 'alt'=0 for bulk transfers
- set max_packet_size to 512 bytes for bulk transfers
[mchehab@redhat.com: Fix a CodingStyle issue: don't break strings
into separate lines]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The URB data processing for DVB bulk transfers is very similar to
what is done with isoc transfers, so create a common function that
works with both transfer types based on the existing isoc function.
Tested with device Hauppauge HVR-930c.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The URB data processing for bulk transfers is very similar to what
is done with isoc transfers, so create a common function that works
with both transfer types based on the existing isoc function.
[mchehab@redhat.com: Fix a CodingStyle issue: don't break strings
into separate lines]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The URB data processing for bulk transfers is very similar to what
is done with isoc transfers, so create a common function that works
with both transfer types based on the existing isoc function.
[mchehab@redhat.com: Fix a CodingStyle issue: don't break strings
into separate lines]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This check is already done in the URB handler
em28xx_irq_callback before calling these functions.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[mchehab@redhat.com: Fix a CodingStyle issue: don't break strings
into separate lines]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- rename em28xx_init_isoc to em28xx_init_usb_xfer
- add parameter for isoc/bulk transfer selection which is passed to em28xx_alloc_urbs
- rename local variable isoc_buf to usb_bufs
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rename the existing function for isoc transfers em28xx_init_isoc
to em28xx_init_usb_xfer and extend it.
URB allocation and setup is now done depending on the USB
transfer type, which is selected with a new function parameter.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This function will be used to uninitialize USB bulk transfers, too.
Also rename the local variable isoc_bufs to usb_bufs.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx_irq_callback can be used for isoc and bulk transfers.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It isn't used anymore and uses constants which no longer exist.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Also rename the corresponding field isoc_ctl in struct em28xx
to usb_ctl.
We will use this struct for USB bulk transfers, too.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It will be used for USB bulk transfers, too.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rename EM28XX_NUM_PACKETS to EM28XX_NUM_ISOC_PACKETS and
EM28XX_DVB_MAX_PACKETS to EM28XX_DVB_NUM_ISOC_PACKETS to
clarify that these values are used only for isoc usb transfers.
Also use the term num_packets instead of max_packets, as this
is how these values are used and called in struct urb.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx_copy_video uses a wrong offset for the target buffer
when copying the data from an USB isoc packet. This happens
only for the second and all following lines in the packet.
The reason why this bug doesn't cause image corruption with
my test device (SilverCrest Webcam 1.3 MPix) is, that this
device never sends any packets that cross the end of a line.
I don't know if all devices behave like this, so this patch
should be considered for stable.
With the upcoming patches to add support for USB bulk transfers,
em28xx_copy_video will be called once per URB, which will
always trigger this bug.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When em28xx_ir_init() fails due to an configuration error, it frees the memory
of struct em28xx_IR *ir, but doesn't set the corresponding pointer in the
device struct to NULL.
On device removal, em28xx_ir_fini() gets called, which then calls
rc_unregister_device() with a pointer to freed memory.
Fixes bug 26572 (http://bugzilla.kernel.org/show_bug.cgi?id=26572)
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Newer em28xx chipsets (em2874 and upper) are capable of supporting
RC6 codes, on both mode 0 (command mode, 16 bits payload size, similar
to RC5, also called "Philips mode") and mode 6a (OEM command mode,
with offers a few alternatives with regards to the payload size).
I don't have any mode 6a control ATM to test it, so, I opted to add
support only to mode 0.
After this patch, adding support to mode 6a should not be hard.
Tested with a Philips television remote controller.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
By disabling the NEC parity check, it is possible to handle all 3 NEC
protocol variants (32, 24 or 16 bits).
Change the driver in order to handle all of them.
Unfortunately, em2860/em2863 provide only 16 bits for the IR scancode,
even when NEC parity is disabled. So, this change should affect only
em2874 and newer devices, with provides up to 32 bits for the scancode.
Tested with one NEC-16, one NEC-24 and one RC5 IR.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I noticed that the EM28XX DVB driver doesn't auto select all of the
appropriate DVB tuner modules required. In particular I needed
DVB_LGDT3305 for my a340, but it looks like DVB_MT352 + DVB_S5H1409 were
missing as well.
Signed-Off-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
dvb_unregister_frontend has to be called before detach. Otherwise the
unregister call will segfault. This made tm6000-dvb module unload unusable.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This should fix a potential race condition, when the irq handler
triggers while rc_register_device is still setting up the rdev->raw
device.
This crash has not been observed in practice, but there should be a very
small window where it could occur. Since ir_raw_event_store_with_filter
checks if rdev->raw is not NULL before using it, this bug is not
triggered if the request_irq triggers a pending irq directly (since
rdev->raw will still be NULL then).
This commit was tested on nuvoton-cir only.
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Härdeman <david@hardeman.nu>
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fixes a problem in fintek-cir and nuvoton-cir where the
irq handler would trigger during module load before the rdev member was
set, causing a NULL pointer crash.
It seems this crash is very reproducible (just bombard the receiver with
IR signals during module load), probably because when request_irq is
called, any pending intterupt is handled immediately, before
request_irq returns and rdev can be set.
This same crash was supposed to be fixed by commit
9ef449c6b3 ("[media] rc: Postpone ISR
registration"), but the crash was still observed on the nuvoton-cir
driver.
This commit was tested on nuvoton-cir only.
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before, labels were simply numbered. Now, the labels are named after the
cleanup action they'll perform (first), based on how the winbond-cir
driver does it. This makes the code a bit more clear and makes changes
in the ordering of labels easier to review.
This change is applied only to the rc drivers that do significant
cleanup in their probe functions: ati-remote, ene-ir, fintek-cir,
gpio-ir-recv, ite-cir, nuvoton-cir.
This commit should not change any code, it just renames goto labels.
[mchehab@redhat.com: removed changes at gpio-ir-recv.c, due to
merge conflicts]
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I've noticed that vivi takes a lot of CPU to produce its frames.
For example for 8 devices and 8 simple programs running, where each
captures YUY2 640x480 and displays it to X via SDL, profile timing is as
follows:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
# Samples: 82K of event 'cycles'
# Event count (approx.): 31551930117
#
# Overhead Command Shared Object Symbol
# ........ ............... ....................
#
49.48% vivi-* [vivi] [k] gen_twopix
10.79% vivi-* [kernel.kallsyms] [k] memcpy
10.02% rawv libc-2.13.so [.] __memcpy_ssse3
8.35% vivi-* [vivi] [k] gen_text.constprop.6
5.06% Xorg [unknown] [.] 0xa73015f8
2.32% rawv [vivi] [k] gen_twopix
1.22% rawv [vivi] [k] precalculate_line
1.20% vivi-* [vivi] [k] vivi_fillbuff
(rawv is display program, vivi-* is a combination of vivi-000 through vivi-007)
so a lot of time is spent in gen_twopix() which as the follwing
call-graph profile shows ...
49.48% vivi-* [vivi] [k] gen_twopix
|
--- gen_twopix
|
|--96.30%-- gen_text.constprop.6
| vivi_fillbuff
| vivi_thread
| kthread
| ret_from_kernel_thread
|
--3.70%-- vivi_fillbuff
vivi_thread
kthread
ret_from_kernel_thread
... is called mostly from gen_text().
If we'll look at gen_text(), in the inner loop, we'll see
if (chr & (1 << (7 - i)))
gen_twopix(dev, pos + j * dev->pixelsize, WHITE, (x+y) & 1);
else
gen_twopix(dev, pos + j * dev->pixelsize, TEXT_BLACK, (x+y) & 1);
which calls gen_twopix() for every character pixel, and that is very
expensive, because gen_twopix() branches several times.
Now, let's note, that we operate on only two colors - WHITE and
TEXT_BLACK, and that pixel for that colors could be precomputed and
gen_twopix() moved out of the inner loop. Also note, that for black
and white colors even/odd does not make a difference for all supported
pixel formats, so we could stop doing that `odd` gen_twopix() parameter
game.
So the first thing we are doing here is
1) moving gen_twopix() calls out of gen_text() into vivi_fillbuff(),
to pregenerate black and white colors, just before printing
starts.
what we have next is that gen_text's font rendering loop, even with
gen_twopix() calls moved out, was inefficient and branchy, so let's
2) rewrite gen_text() loop so it uses less variables + unroll char
horizontal-rendering loop + instantiate 3 code paths for pixelsizes 2,3
and 4 so that in all inner loops we don't have to branch or make
indirections (*).
Done all above reworks, for gen_text() we get nice, non-branchy
streamlined code (showing loop for pixelsize=2):
? cmp $0x2,%eax
? ? jne 26
? mov -0x18(%ebp),%eax
? mov -0x20(%ebp),%edi
? imul -0x20(%ebp),%eax
? movzwl 0x3ffc(%ebx),%esi
0,08 ? movzwl 0x4000(%ebx),%ecx
0,04 ? add %edi,%edi
? mov 0x0,%ebx
0,51 ? mov %edi,-0x1c(%ebp)
? mov %ebx,-0x14(%ebp)
? movl $0x0,-0x10(%ebp)
? lea 0x20(%edx,%eax,2),%eax
? mov %eax,-0x18(%ebp)
? xchg %ax,%ax
0,04 ? a0: mov 0x8(%ebp),%ebx
? mov -0x18(%ebp),%eax
0,04 ? movzbl (%ebx),%edx
0,16 ? test %dl,%dl
0,04 ? ? je 128
0,08 ? lea 0x0(%esi),%esi
1,61 ? b0:???shl $0x4,%edx
1,02 ? ? mov -0x14(%ebp),%edi
2,04 ? ? add -0x10(%ebp),%edx
2,24 ? ? lea 0x1(%ebx),%ebx
0,27 ? ? movzbl (%edi,%edx,1),%edx
9,92 ? ? mov %esi,%edi
0,39 ? ? test %dl,%dl
2,04 ? ? cmovns %ecx,%edi
4,63 ? ? test $0x40,%dl
0,55 ? ? mov %di,(%eax)
3,76 ? ? mov %esi,%edi
0,71 ? ? cmove %ecx,%edi
3,41 ? ? test $0x20,%dl
0,75 ? ? mov %di,0x2(%eax)
2,43 ? ? mov %esi,%edi
0,59 ? ? cmove %ecx,%edi
4,59 ? ? test $0x10,%dl
0,67 ? ? mov %di,0x4(%eax)
2,55 ? ? mov %esi,%edi
0,78 ? ? cmove %ecx,%edi
4,31 ? ? test $0x8,%dl
0,67 ? ? mov %di,0x6(%eax)
5,76 ? ? mov %esi,%edi
1,80 ? ? cmove %ecx,%edi
4,20 ? ? test $0x4,%dl
0,86 ? ? mov %di,0x8(%eax)
2,98 ? ? mov %esi,%edi
1,37 ? ? cmove %ecx,%edi
4,67 ? ? test $0x2,%dl
0,20 ? ? mov %di,0xa(%eax)
2,78 ? ? mov %esi,%edi
0,75 ? ? cmove %ecx,%edi
3,92 ? ? and $0x1,%edx
0,75 ? ? mov %esi,%edx
2,59 ? ? mov %di,0xc(%eax)
0,59 ? ? cmove %ecx,%edx
3,10 ? ? mov %dx,0xe(%eax)
2,39 ? ? add $0x10,%eax
0,51 ? ? movzbl (%ebx),%edx
2,86 ? ? test %dl,%dl
2,31 ? ???jne b0
0,04 ?128: addl $0x1,-0x10(%ebp)
4,00 ? mov -0x1c(%ebp),%eax
0,04 ? add %eax,-0x18(%ebp)
0,08 ? cmpl $0x10,-0x10(%ebp)
? ? jne a0
which almost goes away from the profile:
# cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
# Samples: 49K of event 'cycles'
# Event count (approx.): 16799780016
#
# Overhead Command Shared Object Symbol
# ........ ............... ....................
#
27.51% rawv libc-2.13.so [.] __memcpy_ssse3
23.77% vivi-* [kernel.kallsyms] [k] memcpy
9.96% Xorg [unknown] [.] 0xa76f5e12
4.94% vivi-* [vivi] [k] gen_text.constprop.6
4.44% rawv [vivi] [k] gen_twopix
3.17% vivi-* [vivi] [k] vivi_fillbuff
2.45% rawv [vivi] [k] precalculate_line
1.20% swapper [kernel.kallsyms] [k] read_hpet
i.e. gen_twopix() overhead dropped from 49% to 4% and gen_text() loops
from ~8% to ~4%, and overal cycles count dropped from 31551930117 to
16799780016 which is ~1.9x whole workload speedup.
(*) for RGB24 rendering I've introduced x24, which could be thought as
synthetic u24 for simplifying the code. That's done because for
memcpy used for conditional assignment, gcc generates suboptimal code
with more indirections.
Fortunately, in C struct assignment is builtin and that's all we
need from pixeltype for font rendering.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Commits e666a44fa3 ("[media] tda18212:
silence compiler warning") and e0e52d4e9f
("[media] tda18218: silence compiler warning") silenced warnings
equivalent to these:
drivers/media/tuners/tda18212.c: In function ‘tda18212_attach’:
drivers/media/tuners/tda18212.c:299:2: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/media/tuners/tda18218.c: In function ‘tda18218_attach’:
drivers/media/tuners/tda18218.c:305:2: warning: ‘val’ may be used uninitialized in this function [-Wmaybe-uninitialized]
But in both cases 'val' will still be used uninitialized if the calls
of tda18212_rd_reg() or tda18218_rd_reg() fail. Fix this by only
printing the "chip id" if the calls of those functions were successful.
This allows to drop the uninitialized_var() stopgap measure.
Also stop printing the return values of tda18212_rd_reg() or
tda18218_rd_reg(), as these are not interesting.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Building budget-av.o triggers this GCC warning:
In file included from drivers/media/pci/ttpci/budget-av.c:44:0:
drivers/media/dvb-frontends/tda8261_cfg.h: In function ‘tda8261_get_bandwidth’:
drivers/media/dvb-frontends/tda8261_cfg.h:68:21: warning: ‘t_state.bandwidth’ may be used uninitialized in this function [-Wuninitialized]
Move the printk() that uses t_state.bandwith to the location where it
should be initialized to fix this.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
4x gain ceiling is not enough to capture a decent image in conditions
of total darkness and only a LED light source. Allow a maximum gain
of 32x instead.
This doesn't have any drawback since the image quality in 'normal'
light conditions is the same.
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
