1. 02 9月, 2020 1 次提交
  2. 16 4月, 2020 1 次提交
  3. 15 4月, 2020 1 次提交
  4. 27 12月, 2019 1 次提交
  5. 02 8月, 2018 2 次提交
  6. 25 7月, 2018 1 次提交
  7. 04 7月, 2018 1 次提交
  8. 28 6月, 2018 1 次提交
  9. 05 6月, 2018 1 次提交
  10. 29 5月, 2018 3 次提交
  11. 11 5月, 2018 1 次提交
  12. 04 5月, 2018 1 次提交
  13. 26 3月, 2018 1 次提交
  14. 23 3月, 2018 1 次提交
    • M
      media: v4l2-ioctl: fix some "too small" warnings · 912d2f82
      Mauro Carvalho Chehab 提交于
      While the code there is right, it produces three false positives:
      	drivers/media/v4l2-core/v4l2-ioctl.c:2868 video_usercopy() error: copy_from_user() 'parg' too small (128 vs 16383)
      	drivers/media/v4l2-core/v4l2-ioctl.c:2868 video_usercopy() error: copy_from_user() 'parg' too small (128 vs 16383)
      	drivers/media/v4l2-core/v4l2-ioctl.c:2876 video_usercopy() error: memset() 'parg' too small (128 vs 16383)
      
      Store the ioctl size on a cache var, in order to suppress those.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      912d2f82
  15. 22 3月, 2018 1 次提交
  16. 23 2月, 2018 1 次提交
  17. 30 1月, 2018 2 次提交
  18. 05 1月, 2018 1 次提交
  19. 04 1月, 2018 1 次提交
  20. 29 12月, 2017 1 次提交
  21. 24 9月, 2017 1 次提交
  22. 27 8月, 2017 1 次提交
  23. 23 6月, 2017 1 次提交
  24. 20 6月, 2017 2 次提交
    • T
      [media] v4l2-core: Use kvmalloc() for potentially big allocations · 758d90e1
      Tomasz Figa 提交于
      There are multiple places where arrays or otherwise variable sized
      buffer are allocated through V4L2 core code, including things like
      controls, memory pages, staging buffers for ioctls and so on. Such
      allocations can potentially require an order > 0 allocation from the
      page allocator, which is not guaranteed to be fulfilled and is likely to
      fail on a system with severe memory fragmentation (e.g. a system with
      very long uptime).
      
      Since the memory being allocated is intended to be used by the CPU
      exclusively, we can consider using vmalloc() as a fallback and this is
      exactly what the recently merged kvmalloc() helpers do. A kmalloc() call
      is still attempted, even for order > 0 allocations, but it is done
      with __GFP_NORETRY and __GFP_NOWARN, with expectation of failing if
      requested memory is not available instantly. Only then the vmalloc()
      fallback is used. This should give us fast and more reliable allocations
      even on systems with higher memory pressure and/or more fragmentation,
      while still retaining the same performance level on systems not
      suffering from such conditions.
      
      While at it, replace explicit array size calculations on changed
      allocations with kvmalloc_array().
      
      Purposedly not touching videobuf1, as it is deprecated, has only few
      users remaining and would rather be seen removed instead.
      Signed-off-by: NTomasz Figa <tfiga@chromium.org>
      Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      758d90e1
    • R
      [media] media: Add new SDR formats PC16, PC18 & PC20 · c28f2118
      Ramesh Shanmugasundaram 提交于
      This patch adds support for the three new SDR formats. These formats
      were prefixed with "planar" indicating I & Q data are not interleaved
      as in other formats. Here, I & Q data constitutes the top half and bottom
      half of the received buffer respectively.
      
      V4L2_SDR_FMT_PCU16BE - 14-bit complex (I & Q) unsigned big-endian sample
      inside 16-bit. V4L2 FourCC: PC16
      
      V4L2_SDR_FMT_PCU18BE - 16-bit complex (I & Q) unsigned big-endian sample
      inside 18-bit. V4L2 FourCC: PC18
      
      V4L2_SDR_FMT_PCU20BE - 18-bit complex (I & Q) unsigned big-endian sample
      inside 20-bit. V4L2 FourCC: PC20
      Signed-off-by: NRamesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
      Signed-off-by: NHans Verkuil <hansverk@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      c28f2118
  25. 06 6月, 2017 1 次提交
  26. 15 4月, 2017 3 次提交
  27. 10 4月, 2017 1 次提交
  28. 24 11月, 2016 2 次提交
  29. 22 10月, 2016 1 次提交
  30. 21 10月, 2016 3 次提交