1. 24 12月, 2014 2 次提交
  2. 23 12月, 2014 1 次提交
  3. 05 12月, 2014 1 次提交
  4. 26 9月, 2014 1 次提交
  5. 24 9月, 2014 1 次提交
    • F
      [media] em28xx: get rid of field has_audio in struct em28xx_audio_mode · 920f1e4a
      Frank Schaefer 提交于
      Field has_audio in struct em28xx_audio_mode is used together with value
      EM28XX_NO_AC97 of field ac97 to determine the internal type of audio
      (none/i2s/ac97). This makes the code difficult to understand:
      
        !audio_mode.has_audio && audio_mode.ac97 == EM28XX_NO_AC97 => no audio
        !audio_mode.has_audio && audio_mode.ac97 != EM28XX_NO_AC97 => BUG
        audio_mode.has_audio  && audio_mode.ac97 == EM28XX_NO_AC97 => AC97 audio
        audio_mode.has_audio  && audio_mode.ac97 != EM28XX_NO_AC97 => I2S audio
      
      Simplify the whole thing by introducing an enum em28xx_int_audio_type
      which describes the internal audio type (none, ac97, i2s) and is hooked
      directly to the device struct. Then get rid of field has_audio in struct
      em28xx_audio_mode.
      
      A follow-up patch will then remove struct em28xx_ac97_mode and finally
      the whole struct em28xx_audio_mode.
      Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      920f1e4a
  6. 22 9月, 2014 2 次提交
  7. 04 9月, 2014 1 次提交
  8. 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
  9. 27 7月, 2014 4 次提交
  10. 05 7月, 2014 1 次提交
  11. 25 5月, 2014 1 次提交
  12. 24 5月, 2014 18 次提交
  13. 23 5月, 2014 2 次提交
  14. 23 4月, 2014 1 次提交
  15. 11 3月, 2014 1 次提交
  16. 06 3月, 2014 1 次提交