Commit Graph

336589 Commits

Author SHA1 Message Date
Matthijs Kooijman
70ef69915b [media] rc: Make probe cleanup goto labels more verbose
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>
2012-12-21 18:26:08 -02:00
Kirill Smelkov
d40fbf8d52 [media] vivi: Optimize precalculate_line()
precalculate_line() is not very high on profile, but it calls expensive
gen_twopix(), so let's polish it too:
    call gen_twopix() only once for every color bar and then distribute
    the result.
before:
    # cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
    #
    # Samples: 46K of event 'cycles'
    # Event count (approx.): 15574200568
    #
    # Overhead          Command         Shared Object
    # ........  ...............  ....................
    #
        27.99%             rawv  libc-2.13.so          [.] __memcpy_ssse3
        23.29%           vivi-*  [kernel.kallsyms]     [k] memcpy
        10.30%             Xorg  [unknown]             [.] 0xa75c98f8
         5.34%           vivi-*  [vivi]                [k] gen_text.constprop.6
         4.61%             rawv  [vivi]                [k] gen_twopix
         2.64%             rawv  [vivi]                [k] precalculate_line
         1.37%          swapper  [kernel.kallsyms]     [k] read_hpet
after:
    # cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
    #
    # Samples: 45K of event 'cycles'
    # Event count (approx.): 15561769214
    #
    # Overhead          Command         Shared Object
    # ........  ...............  ....................
    #
        30.73%             rawv  libc-2.13.so          [.] __memcpy_ssse3
        26.78%           vivi-*  [kernel.kallsyms]     [k] memcpy
        10.68%             Xorg  [unknown]             [.] 0xa73015e9
         5.55%           vivi-*  [vivi]                [k] gen_text.constprop.6
         1.36%          swapper  [kernel.kallsyms]     [k] read_hpet
         0.96%             Xorg  [kernel.kallsyms]     [k] read_hpet
         ...
         0.16%             rawv  [vivi]                [k] precalculate_line
         ...
         0.14%             rawv  [vivi]                [k] gen_twopix
(i.e. gen_twopix and precalculate_line overheads are almost gone)

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>
2012-12-21 18:25:57 -02:00
Kirill Smelkov
13908f330f [media] vivi: Move computations out of vivi_fillbuf linecopy loop
The "dev->mvcount % wmax" thing was showing high in profiles (we do it
for each line which ~ 500 per frame)
           ?     000010c0 <vivi_fillbuff>:
                 ...
      0,39 ? 70:???mov    0x3ff4(%edi),%esi
      0,22 ? 76:?  mov    0x2a0(%edi),%eax
      0,30 ?    ?  mov    -0x84(%ebp),%ebx
      0,35 ?    ?  mov    %eax,%edx
      0,04 ?    ?  mov    -0x7c(%ebp),%ecx
      0,35 ?    ?  sar    $0x1f,%edx
      0,44 ?    ?  idivl  -0x7c(%ebp)
     21,68 ?    ?  imul   %esi,%ecx
      0,70 ?    ?  imul   %esi,%ebx
      0,52 ?    ?  add    -0x88(%ebp),%ebx
      1,65 ?    ?  mov    %ebx,%eax
      0,22 ?    ?  imul   %edx,%esi
      0,04 ?    ?  lea    0x3f4(%edi,%esi,1),%edx
      2,18 ?    ?? call   vivi_fillbuff+0xa6
      0,74 ?    ?  addl   $0x1,-0x80(%ebp)
     62,69 ?    ?  mov    -0x7c(%ebp),%edx
      1,18 ?    ?  mov    -0x80(%ebp),%ecx
      0,35 ?    ?  add    %edx,-0x84(%ebp)
      0,61 ?    ?  cmp    %ecx,-0x8c(%ebp)
      0,22 ?    ???jne    70
so since all variables stay the same for all iterations let's move
computations out of the loop: the abovementioned division and
"width*pixelsize" too
before:
    # cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
    #
    # Samples: 49K of event 'cycles'
    # Event count (approx.): 16475832370
    #
    # Overhead          Command           Shared Object
    # ........  ...............  ......................
    #
        29.07%             rawv  libc-2.13.so            [.] __memcpy_ssse3
        20.57%           vivi-*  [kernel.kallsyms]       [k] memcpy
        10.20%             Xorg  [unknown]               [.] 0xa7301494
         5.16%           vivi-*  [vivi]                  [k] gen_text.constprop.6
         4.43%             rawv  [vivi]                  [k] gen_twopix
         4.36%           vivi-*  [vivi]                  [k] vivi_fillbuff
         2.42%             rawv  [vivi]                  [k] precalculate_line
         1.33%          swapper  [kernel.kallsyms]       [k] read_hpet
after:
    # cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
    #
    # Samples: 46K of event 'cycles'
    # Event count (approx.): 15574200568
    #
    # Overhead          Command         Shared Object
    # ........  ...............  ....................
    #
        27.99%             rawv  libc-2.13.so          [.] __memcpy_ssse3
        23.29%           vivi-*  [kernel.kallsyms]     [k] memcpy
        10.30%             Xorg  [unknown]             [.] 0xa75c98f8
         5.34%           vivi-*  [vivi]                [k] gen_text.constprop.6
         4.61%             rawv  [vivi]                [k] gen_twopix
         2.64%             rawv  [vivi]                [k] precalculate_line
         1.37%          swapper  [kernel.kallsyms]     [k] read_hpet
         0.79%             Xorg  [kernel.kallsyms]     [k] read_hpet
         0.64%             Xorg  [kernel.kallsyms]     [k] unix_poll
         0.45%             Xorg  [kernel.kallsyms]     [k] fget_light
         0.43%             rawv  libxcb.so.1.1.0       [.] 0x0000aae9
         0.40%            runsv  [kernel.kallsyms]     [k] ext2_try_to_allocate
         0.36%             Xorg  [kernel.kallsyms]     [k] _raw_spin_lock_irqsave
         0.31%           vivi-*  [vivi]                [k] vivi_fillbuff
(i.e. vivi_fillbuff own overhead is almost gone)

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>
2012-12-21 18:25:43 -02:00
Kirill Smelkov
10ce844158 [media] vivi: vivi_dev->line[] was not aligned
Though dev->line[] is u8 array we work with it as with u16, u24 or u32
pixels, and also pass it to memcpy() and it's better to align it to at
least 4.
Before the patch, on x86 offsetof(vivi_dev, line) was 1003 and after
patch it is 1004.
There is slight performance increase, but I think is is slight, only
because we start copying not from line[0]:
    ---- 8< ---- drivers/media/platform/vivi.c
    static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
    {
            ...
            for (h = 0; h < hmax; h++)
                    memcpy(vbuf + h * wmax * dev->pixelsize,
                           dev->line + (dev->mv_count % wmax) * dev->pixelsize,
                           wmax * dev->pixelsize);
before:
    # 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
    # ........  ...............  ....................
    #
        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
    23.77%           vivi-*  [kernel.kallsyms]     [k] memcpy
                     |
                     --- memcpy
                        |
                        |--99.28%-- vivi_fillbuff
                        |          vivi_thread
                        |          kthread
                        |          ret_from_kernel_thread
                         --0.72%-- [...]
after:
    # cmdline : /home/kirr/local/perf/bin/perf record -g -a sleep 20
    #
    # Samples: 49K of event 'cycles'
    # Event count (approx.): 16475832370
    #
    # Overhead          Command           Shared Object
    # ........  ...............  ......................
    #
        29.07%             rawv  libc-2.13.so            [.] __memcpy_ssse3
        20.57%           vivi-*  [kernel.kallsyms]       [k] memcpy
        10.20%             Xorg  [unknown]               [.] 0xa7301494
         5.16%           vivi-*  [vivi]                  [k] gen_text.constprop.6
         4.43%             rawv  [vivi]                  [k] gen_twopix
         4.36%           vivi-*  [vivi]                  [k] vivi_fillbuff
         2.42%             rawv  [vivi]                  [k] precalculate_line
         1.33%          swapper  [kernel.kallsyms]       [k] read_hpet

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>
2012-12-21 18:25:34 -02:00
Kirill Smelkov
e3a8b4d22b [media] vivi: Optimize gen_text()
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>
2012-12-21 18:25:21 -02:00
YAMANE Toshiaki
011b2aad58 [media] staging/media: Use dev_ printks in cxd2099/cxd2099.[ch]
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...  to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(...  to printk(KERN_INFO ...
- WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(...  to printk(KERN_WARNING ...

Signed-off-by: YAMANE Toshiaki <yamanetoshi@gmail.com>
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 18:25:16 -02:00
Paul Bolle
ed2e330114 [media] tda18212: tda18218: use 'val' if initialized
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>
2012-12-21 18:25:13 -02:00
Paul Bolle
cb31c74875 [media] budget-av: only use t_state if initialized
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>
2012-12-21 18:25:11 -02:00
Masanari Iida
6dc8f3823e [media] staging: media: Fix minor typo in staging/media
Correct spelling typo in comment witin staging/media.

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 18:25:10 -02:00
Javier Martin
c01b7429e2 [media] media: ov7670: Allow 32x maximum gain for yuv422
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>
2012-12-21 18:25:09 -02:00
Javier Martin
2027240968 [media] media: m2m-deinterlace: Do not set debugging flag to true
Default value should be 'debugging disabled'.

Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 18:25:07 -02:00
Peter Senna Tschudin
37e310edf3 [media] drivers/media/pci/saa7134/saa7134-dvb.c: Test if videobuf_dvb_get_frontend return NULL
Based on commit: e66131cee5
Not testing videobuf_dvb_get_frontend output may cause OOPS if it return
NULL. This patch fixes this issue.
The semantic patch that found this issue is(http://coccinelle.lip6.fr/):
// <smpl>
@@
identifier i,a,b;
statement S, S2;
@@
i = videobuf_dvb_get_frontend(...);
... when != if (!i) S
* if (i->a.b)
S2
// </smpl>

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 17:43:22 -02:00
Javier Martin
832fbb5aec [media] media: coda: Fix H.264 header alignment - v2
Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.
In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.

[mchehab@redhat.com: applied only v2 diff here, as v1 ended by mistakenly
 being applied]
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 16:56:31 -02:00
Javier Martin
3f3f5c7f63 [media] media: coda: Fix H.264 header alignment
Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.
In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.

[mchehab@redhat.com: Fix a few CodingStyle issues]
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 16:39:03 -02:00
Jesper Juhl
bbe2a1d32f [media] rc: Fix double free in gpio_ir_recv_remove()
Since rc_unregister_device() frees its argument there's no need to
subsequently call rc_free_device() on the same variable - in fact it's
a double free bug.
Easily fixed by just removing the rc_free_device() call.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 16:28:58 -02:00
Jesper Juhl
e5d85b9ac3 [media] rc: Fix double free in gpio_ir_recv_probe()
At the 'err_request_irq' label, rc_unregister_device(rcdev) frees its
argument. So when we fall through to the 'err_gpio_request' label
further down and call rc_free_device(rcdev) then that's a double free.
Fix that by moving 'rcdev = NULL' from after the call to
rc_free_device() to after rc_unregister_device(). That fixes the
problem since rc_free_device() just does nothing if passed NULL and
there's no further use of 'rcdev' after the call to rc_free_device()
so it's not needed there.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 16:27:01 -02:00
Mauro Carvalho Chehab
1c12bf8de7 [media] tda10071: fix a warning introduced by changeset 41f55d5755
The two new tests don't set the returned value.

Cc: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:43:41 -02:00
Michael Krufky
41f55d5755 [media] tda10071: make sure both tuner and demod i2c addresses are specified
display an error message if either tuner_i2c_addr or demod_i2c_addr
are not specified in the tda10071_config structure

Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:36:54 -02:00
Andy Shevchenko
bb9e31f392 [media] or51211: apply pr_fmt and use pr_* macros instead of printk
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:30:19 -02:00
Andy Shevchenko
aa735ee9dd [media] ix2505v: use %*ph[N] to dump small buffers
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:27:02 -02:00
Andy Shevchenko
870f31cbf0 [media] or51211: use %*ph[N] to dump small buffers
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:26:28 -02:00
Wei Yongjun
cc91de5fad [media] davinci: vpbe: remove unused variable in vpbe_initialize()
The variable 'output_index' is initialized but never used
otherwise, so remove the unused variable.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Prabhakar Lad <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:23:09 -02:00
Wei Yongjun
e276f03b4f [media] media: davinci: vpbe: return error code on error in vpbe_display_g_crop()
We have assigned error code to 'ret' if crop->type is not
V4L2_BUF_TYPE_VIDEO_OUTPUT, but never use it.
We'd better return the error code on this error.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Prabhakar Lad <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:22:30 -02:00
Wei Yongjun
4d22f1086d [media] media: davinci: vpbe: fix return value check in vpbe_display_reqbufs()
In case of error, the function vb2_dma_contig_init_ctx() returns
ERR_PTR() and never returns NULL. The NULL test in the return value
check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Prabhakar Lad <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:21:46 -02:00
Lad, Prabhakar
cfe9dbd8a7 [media] media: davinci: vpbe: enable building of vpbe driver for DM355 and DM365
This patch allows enabling building of VPBE display driver for DM365
and DM355. This also removes unnecessary entry VIDEO_DM644X_VPBE
in Kconfig, which could have been done with single entry, and
appropriate changes in Makefile for building.

Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:21:01 -02:00
Lad, Prabhakar
caff80c35f [media] davinci: vpbe: pass different platform names to handle different ip's
The vpbe driver can handle different platforms DM644X, DM36X and
DM355. To differentiate between this platforms venc_type/vpbe_type
was passed as part of platform data which was incorrect. The correct
way to differentiate to handle this case is by passing different
platform names.
This patch creates platform_device_id[] array supporting different
platforms and assigns id_table to the platform driver, and finally
in the probe gets the actual device by using platform_get_device_id()
and gets the appropriate driver data for that platform.
Taking this approach will also make the DT transition easier.

Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:18:50 -02:00
Manjunath Hadli
5a89fac7e9 [media] davinci: vpfe: Add documentation and TODO
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements. This patch also includes
the TODO's to fit into drivers/media/ folder.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:16:18 -02:00
Manjunath Hadli
44261e3805 [media] davinci: vpfe: dm365: add build infrastructure for capture driver
add build infrastructure for dm365 specific modules for VPFE
capture driver.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:14:20 -02:00
Manjunath Hadli
45e46b3bbe [media] davinci: vpfe: dm365: resizer driver based on media framework
Add the video resizer driver with the v4l2 media controller framework
which takes care of resizing the video frames with both up-scaling
downscaling facility. The driver supports both continuous and
single shot operations.The driver supports resizer as a subdevice
and a media entity. It has support for 2 resizers - resizerA
and resizerB.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:14:11 -02:00
Manjunath Hadli
26c0e9992c [media] davinci: vpfe: dm365: add IPIPE hardware layer support
IPIPE is the hardware IP which implements the functionality
required for resizer, ipipe(colorspace converter) and
the associated hardware support. This patch implements hardware
setup including coefficient programming for various hardware
filters, gamma, cfa and clock enabling.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:14:01 -02:00
Manjunath Hadli
da43b6ccad [media] davinci: vpfe: dm365: add IPIPE support for media controller driver
Add the IPIPE subdevice to the DM365 vpfe driver. The IPIPE is the
major sub IP in the DM365 capture VPFE hardware and implements
black clamping, color space conversion, edge enhancements etc.
the block is exposed as a subdevice and implements media controller
based setup and a private IOCTL for fine grain control.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:13:53 -02:00
Manjunath Hadli
6a630533c4 [media] davinci: vpfe: dm365: add ISIF driver based on media framework
add support for ISIF as a subdevice for dm365 vpfe capture driver.
ISIF is responsible for capturing video data both in raw bayer format
on sync seperate signals and YUV through BT656/1120 interfaces.
ISIF is exposed as a subdev for the vpfe driver and allows users to
use the driver through standard media controller interface.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:13:39 -02:00
Manjunath Hadli
f7fa454dc1 [media] davinci: vpfe: dm365: add IPIPEIF driver based on media framework
add support for dm365 IPIPEIF driver based on media framework.
The IPIPEIF is exposed as a subdev, and it supports features
like fault pixel correction, dark frame subtraction and other
necessary hardware setup.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:13:30 -02:00
Manjunath Hadli
622897da67 [media] davinci: vpfe: add v4l2 video driver support
Add a generic video driver functionality to be used by all the vpfe
drivers for davinci SoCs. The functionality includes all the
standard v4l2 interfaces including streaming. The video node
interface can be used both as an input and output node for both
continuous and single shot modes. Also supports dv_presets to include
HD modes, wth support for both user pointer IO and mmap. The buffering
mechanism is based on videobuf2 interface.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:12:59 -02:00
Manjunath Hadli
91825400ba [media] davinci: vpfe: add v4l2 capture driver with media interface
Add the vpfe capture driver which implements media controller
interface. The driver supports the DM365 sub ip units for capture
namely - ISIF, IPIPE, IPIPEIF, Resizer. This file represents the main
driver which does isr registration, v4l2 device registration,
media registration and platform driver registrations.
It calls the appropriate subdevs from here to create subdevices
and media entities.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:10:05 -02:00
Manjunath Hadli
d31c100250 [media] davinci/vpss: add helper functions for setting hw params
Add vpss helper functions to be used in the main driver for setting
hardware parameters.

Add interface functions to set sync polarity, interrupt completion and
pageframe size in vpss to be used by the main driver.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:07:20 -02:00
Manjunath Hadli
3de939419c [media] davinci: vpss: dm365: set vpss clk ctrl
request_mem_region for VPSS_CLK_CTRL register and ioremap.
and enable clocks appropriately.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:04:50 -02:00
Manjunath Hadli
c1819fc5db [media] davinci: vpss: dm365: enable ISP registers
enable the clocks required for VPFE to work in PCCR register,
and enbale ISIF out on BCR to get the correct operation from ISIF.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 14:02:02 -02:00
Sylwester Nawrocki
47800bc43e [media] s5p-fimc: Improved pipeline try format routine
Make the pipeline try format routine more generic to support any
number of subdevs in the pipeline, rather than hard coding it for
only a sensor, MIPI-CSIS and FIMC subdevs and the FIMC video node.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:58:31 -02:00
Hans de Goede
2bffebc1e6 [media] gspca_sonixj: Add a small delay after i2c_w1
We already have the same delay in i2c_w8, but it was missing from i2c_w1,
adding this delay fixes the Microsoft VX-3000 camera often (but not always)
streaming video data with a very green-ish tint.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:40:19 -02:00
Hans de Goede
18fa0d36ad [media] gspca_sonixb: Properly wait between i2c writes
We must wait for the previous i2c write to complete before starting a new
one. Sofar we were getting away with this, but it seems that some parts
of the usb-subsystem has been sped up making us go to fast :)
This fixes streaming on sn9c103 based cams not working with an
"i2c_w error" error.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:39:50 -02:00
Hans de Goede
8547fd18e9 [media] gspca_t613: Fix compiling with GSPCA_DEBUG defined
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:38:39 -02:00
Erik Andrén
d83fcb793b [media] gspca_stv06xx: Disable flip controls for vv6410 sensor
Disable the hardware VFLIP and HFLIP controls for now as we lack a
mechanism to adjust the frame offset, thus rending a bayerimage not
compliant with the announced format.

Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:38:09 -02:00
Sachin Kamat
e52ec68015 [media] gspca: Use module_usb_driver macro
module_usb_driver eliminates a lot of boilerplate by replacing
module_init() and module_exit() calls.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:37:11 -02:00
Jacob Schloss
c307538888 [media] gspca_kinect: add Kinect for Windows USB id
Add the USB ID for the Kinect for Windows RGB camera so it can be used
with the gspca_kinect driver.

Signed-off-by: Jacob Schloss <jacob.schloss@unlimitedautomata.com>
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:36:42 -02:00
Hans de Goede
23e8321624 [media] Documentation/media: Remove docs for obsoleted and removed v4l1 drivers
When the v4l1 drivers were removed, there docs were forgotten.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:35:58 -02:00
Hans de Goede
7a29ee2e37 [media] stk-webcam: Add an upside down dmi table, and add the Asus G1 to it
The stk-webcam module is inserted upside-down in some webcams, so we
need to de hflip and vflip by default on some models.
Note that this patch inverts the value of the controls as reported by
the control API in this case so that for the user they still make sense
(iow not doing any flipping from the ctrl API pov results in an upright
image).

Reported-by: Jose Gómez <adler@dreamcoder.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 13:34:30 -02:00
Hans de Goede
143dd34597 [media] gspca-pac207: Add a led_invert module parameter
Some cams have their led connected in such a way that on = off and visa versa
unfortunately we cannot tell this from the driver in any way, so add a module
parameter for this.

Reported-by: Yuri Glushkov <yglushkov@yahoo.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 12:41:29 -02:00
Jean-François Moine
0488112734 [media] gspca - stv06xx: Fix a regression with the bridge/sensor vv6410
Setting the H and V flip controls at webcam connection time prevents
the webcam to work correctly.
This patch checks if the webcam is streaming before setting the flips.
It does not set the flips (nor other controls) at webcam start time.

Tested-by: Philippe ROUBACH <philippe.roubach@free.fr>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 12:40:20 -02:00
Andrzej Hajda
1c9f5bd7cb [media] s5p-fimc: Add support for sensors with multiple pads
Some sensors can have more than one pad (case of S5C73M3).
In such cases FIMC assumes the last pad of the sensor is
the source pad.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-12-21 12:26:55 -02:00