1. 22 11月, 2014 1 次提交
  2. 15 11月, 2014 2 次提交
  3. 03 11月, 2014 1 次提交
  4. 30 10月, 2014 1 次提交
  5. 24 10月, 2014 1 次提交
  6. 21 10月, 2014 1 次提交
    • H
      [media] em28xx: fix uninitialized variable warning · 430e3572
      Hans Verkuil 提交于
      Fix this daily build warning:
      
      In file included from build/media_build/v4l/em28xx-core.c:35:0:
      build/media_build/v4l/em28xx-core.c: In function 'em28xx_audio_setup':
      build/media_build/v4l/em28xx.h:798:2: warning: 'vid' may be used uninitialized in this function [-Wmaybe-uninitialized]
        printk(KERN_INFO "%s: "fmt,\
        ^
      build/media_build/v4l/em28xx-core.c:507:6: note: 'vid' was declared here
        u32 vid;
            ^
      
      As far as I can tell 'vid' can not really be used uninitialized here, but the code
      is sufficiently complex that apparently gcc can't figure that out.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      430e3572
  7. 29 9月, 2014 1 次提交
  8. 26 9月, 2014 3 次提交
  9. 24 9月, 2014 5 次提交
  10. 23 9月, 2014 1 次提交
  11. 22 9月, 2014 4 次提交
  12. 04 9月, 2014 1 次提交
  13. 03 9月, 2014 3 次提交
  14. 22 8月, 2014 2 次提交
    • F
      [media] em28xx-v4l: fix video buffer field order reporting in progressive mode · 662c97cf
      Frank Schaefer 提交于
      The correct field order in progressive mode is V4L2_FIELD_NONE, not V4L2_FIELD_INTERLACED.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      662c97cf
    • F
      [media] em28xx-v4l: give back all active video buffers to the vb2 core properly on streaming stop · 627530c3
      Frank Schaefer 提交于
      When a new video frame is started, the driver takes the next video buffer from
      the list of active buffers and moves it to dev->usb_ctl.vid_buf / dev->usb_ctl.vbi_buf
      for further processing.
      
      On streaming stop we currently only give back the pending buffers from the list
      but not the ones which are currently processed.
      
      This causes the following warning from the vb2 core since kernel 3.15:
      
      ...
       ------------[ cut here ]------------
       WARNING: CPU: 1 PID: 2284 at drivers/media/v4l2-core/videobuf2-core.c:2115 __vb2_queue_cancel+0xed/0x150 [videobuf2_core]()
       [...]
       Call Trace:
        [<c0769c46>] dump_stack+0x48/0x69
        [<c0245b69>] warn_slowpath_common+0x79/0x90
        [<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
        [<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
        [<c0245bfd>] warn_slowpath_null+0x1d/0x20
        [<f925e4ad>] __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
        [<f925fa35>] vb2_internal_streamoff+0x35/0x90 [videobuf2_core]
        [<f925fac5>] vb2_streamoff+0x35/0x60 [videobuf2_core]
        [<f925fb27>] vb2_ioctl_streamoff+0x37/0x40 [videobuf2_core]
        [<f8e45895>] v4l_streamoff+0x15/0x20 [videodev]
        [<f8e4925d>] __video_do_ioctl+0x23d/0x2d0 [videodev]
        [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]
        [<f8e48c63>] video_usercopy+0x203/0x5a0 [videodev]
        [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]
        [<c039d0e7>] ? fsnotify+0x1e7/0x2b0
        [<f8e49012>] video_ioctl2+0x12/0x20 [videodev]
        [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]
        [<f8e4461e>] v4l2_ioctl+0xee/0x130 [videodev]
        [<f8e44530>] ? v4l2_open+0xf0/0xf0 [videodev]
        [<c0378de2>] do_vfs_ioctl+0x2e2/0x4d0
        [<c0368eec>] ? vfs_write+0x13c/0x1c0
        [<c0369a8f>] ? vfs_writev+0x2f/0x50
        [<c0379028>] SyS_ioctl+0x58/0x80
        [<c076fff3>] sysenter_do_call+0x12/0x12
       ---[ end trace 5545f934409f13f4 ]---
      ...
      
      Many thanks to Hans Verkuil, whose recently added check in the vb2 core unveiled
      this long standing issue and who has investigated it further.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      627530c3
  15. 27 7月, 2014 5 次提交
  16. 26 7月, 2014 6 次提交
  17. 24 7月, 2014 1 次提交
    • D
      [media] rc-core: document the protocol type · 120703f9
      David Härdeman 提交于
      Right now the protocol information is not preserved, rc-core gets handed a
      scancode but has no idea which protocol it corresponds to.
      
      This patch (which required reading through the source/keymap for all drivers,
      not fun) makes the protocol information explicit which is important
      documentation and makes it easier to e.g. support multiple protocols with one
      decoder (think rc5 and rc-streamzap). The information isn't used yet so there
      should be no functional changes.
      
      [m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
      Signed-off-by: NDavid Härdeman <david@hardeman.nu>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      120703f9
  18. 22 7月, 2014 1 次提交