1. 07 7月, 2012 1 次提交
  2. 18 6月, 2012 1 次提交
    • S
      [media] s5p-fimc: Add missing static storage class specifiers · 7e566be2
      Sachin Kamat 提交于
      Fixes the following sparse warnings:
      
      drivers/media/video/s5p-fimc/fimc-lite-reg.c:218:6: warning: symbol
      'flite_hw_set_out_order' was not declared. Should it be static?
      
      drivers/media/video/s5p-fimc/fimc-mdevice.c:183:5: warning: symbol '__fimc_pipeline_shutdown' was not declared. Should it be static?
      drivers/media/video/s5p-fimc/fimc-mdevice.c:1013:12: warning: symbol 'fimc_md_init' was not declared. Should it be static?
      drivers/media/video/s5p-fimc/fimc-mdevice.c:1024:13: warning: symbol 'fimc_md_exit' was not declared. Should it be static?
      
      drivers/media/video/s5p-fimc/fimc-core.c:466:5: warning: symbol 'fimc_set_color_effect' was not declared. Should it be static?
      
      drivers/media/video/s5p-fimc/fimc-capture.c:1163:5: warning: symbol 'enclosed_rectangle' was not declared. Should it be static?
      Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
      Acked-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      7e566be2
  3. 20 5月, 2012 9 次提交
  4. 14 5月, 2012 2 次提交
    • S
      [media] s5p-fimc: Fix locking in subdev set_crop op · 5be4fe63
      Sylwester Nawrocki 提交于
      When setting TRY crop on the sub-device the mutex was erroneously acquired
      rather than released on exit path. This bug is present in kernels starting
      from v3.2.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5be4fe63
    • H
      [media] v4l2-dev: add flag to have the core lock all file operations · 5126f259
      Hans Verkuil 提交于
      This used to be the default if the lock pointer was set, but now that lock is by
      default only used for ioctl serialization. Those drivers that already used
      core locking have this flag set explicitly, except for some drivers where
      it was obvious that there was no need to serialize any file operations other
      than ioctl.
      
      The drivers that didn't need this flag were:
      
      drivers/media/radio/dsbr100.c
      drivers/media/radio/radio-isa.c
      drivers/media/radio/radio-keene.c
      drivers/media/radio/radio-miropcm20.c
      drivers/media/radio/radio-mr800.c
      drivers/media/radio/radio-tea5764.c
      drivers/media/radio/radio-timb.c
      drivers/media/video/vivi.c
      sound/i2c/other/tea575x-tuner.c
      
      The other drivers that use core locking and where it was not immediately
      obvious that this flag wasn't needed were changed so that the flag is set
      together with a comment that that driver needs work to avoid having to
      set that flag. This will often involve taking the core lock in the fops
      themselves.
      
      Eventually this flag should go and it should not be used in new drivers.
      
      There are a few reasons why we want to avoid core locking of non-ioctl
      fops: in the case of mmap this can lead to a deadlock in rare situations
      since when mmap is called the mmap_sem is held and it is possible for
      other parts of the code to take that lock as well (copy_from_user()/copy_to_user()
      perform a down_read(&mm->mmap_sem) when a page fault occurs).
      
      It is very unlikely that that happens since the core lock serializes all
      fops, but the kernel warns about it if lock validation is turned on.
      
      For poll it is also undesirable to take the core lock as that can introduce
      increased latency. The same is true for read/write.
      
      While it was possible to make flags or something to turn on/off taking the
      core lock for each file operation, in practice it is much simpler to just
      not take it at all except for ioctl and leave it to the driver to take the
      lock. There are only a handful fops compared to the zillion ioctls we have.
      
      I also wanted to make it obvious which drivers still take the lock for all
      fops, so that's why I chose to have drivers set it explicitly.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5126f259
  5. 08 5月, 2012 2 次提交
  6. 11 4月, 2012 2 次提交
  7. 08 3月, 2012 2 次提交
  8. 18 1月, 2012 1 次提交
  9. 31 12月, 2011 1 次提交
    • S
      [media] s5p-fimc: Add support for alpha component configuration · dafb9c70
      Sylwester Nawrocki 提交于
      On Exynos SoCs the FIMC IP allows to configure globally the alpha
      component of all pixels for V4L2_PIX_FMT_RGB32, V4L2_PIX_FMT_RGB555
      and V4L2_PIX_FMT_RGB444 image formats. This patch adds a v4l2 control
      in order to let the applications control the alpha component value.
      
      The alpha value range depends on the pixel format, for RGB32 it's
      0..255 (8-bits), for RGB555 - 0..1 (1-bit) and for RGB444 - 0..15
      (4-bits). The v4l2 control range is always 0..255 and the alpha
      component data width is determined by currently set format on the
      V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE buffer queue. The applications
      need to match the alpha channel value range and the pixel format
      since the driver will clamp the alpha component. Depending on
      fourcc the valid alpha bits are:
      
       - V4L2_PIX_FMT_RGB555  [0]
       - V4L2_PIX_FMT_RGB444  [3:0]
       - V4L2_PIX_FMT_RGB32   [7:0]
      
      When switching to a pixel format with smaller alpha component width
      the currently set alpha value will be clamped to maximum value valid
      for current format. When switching to a format with wider alpha the
      alpha value remains unchanged.
      
      The variant description data structure is extended with a new entry
      so an additional control is created only where really supported by
      the hardware.
      
      V4L2_PIX_FMT_RGB555 and V4L2_PIX_FMT_RGB444 formats are only valid
      for V4L2_BUF_TYPE_VIDEO_CAPTURE buffer queue.
      Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      dafb9c70
  10. 11 12月, 2011 1 次提交
  11. 25 11月, 2011 3 次提交
  12. 04 11月, 2011 1 次提交
  13. 07 9月, 2011 14 次提交