1. 21 10月, 2016 1 次提交
  2. 12 9月, 2016 1 次提交
    • H
      [media] pxa_camera: merge soc_mediabus.c into pxa_camera.c · 34b27b13
      Hans Verkuil 提交于
      Linking soc_mediabus into this driver causes multiple definition linker warnings
      if soc_camera is also enabled:
      
         drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_image_size+0x0): multiple definition of `__ksymtab_soc_mbus_image_size'
         drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_image_size+0x0): first defined here
      >> drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0): multiple definition of `__ksymtab_soc_mbus_samples_per_pixel'
         drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0): first defined here
         drivers/media/platform/soc_camera/built-in.o: In function `soc_mbus_config_compatible':
         (.text+0x3840): multiple definition of `soc_mbus_config_compatible'
         drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x134): first defined here
      
      Since we really don't want to have to use any of the soc-camera code this patch
      copies the relevant code and data structures from soc_mediabus and renames it to pxa_mbus_*.
      
      The large table of formats has been culled a bit, removing formats that are not supported
      by this driver.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Cc: Robert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      34b27b13
  3. 09 9月, 2016 2 次提交
  4. 24 8月, 2016 1 次提交
  5. 22 8月, 2016 1 次提交
  6. 09 7月, 2016 2 次提交
  7. 28 6月, 2016 2 次提交
  8. 17 6月, 2016 1 次提交
  9. 16 6月, 2016 1 次提交
  10. 19 2月, 2016 1 次提交
  11. 01 2月, 2016 1 次提交
  12. 12 8月, 2015 1 次提交
  13. 11 8月, 2015 1 次提交
    • M
      [media] V4L2: platform: Add Renesas R-Car JPEG codec driver · 2c42cdba
      Mikhail Ulyanov 提交于
      Here's the driver for the Renesas R-Car JPEG processing unit.
      
      The driver is implemented within the V4L2 framework as a memory-to-memory
      device.  It presents two video nodes to userspace, one for the encoding part,
      and one for the decoding part.
      
      It was found that the only working mode for encoding is no markers output, so we
      generate markers with software. In the current version of driver we also use
      software JPEG header parsing because with hardware parsing performance is lower
      than desired.
      
      >From a userspace point of view the process is typical (S_FMT, REQBUF,
      optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and destination
      queues. STREAMON can return -EINVAL in case of mismatch of output and capture
      queues format. Also during decoding driver can return buffers if queued
      buffer with JPEG image contains image with inappropriate subsampling (e.g.
      4:2:0 in JPEG and 4:2:2 in capture).  If JPEG image and queue format dimensions
      differ driver will return buffer on QBUF with VB2_BUF_STATE_ERROR flag.
      
      During encoding the available formats are: V4L2_PIX_FMT_NV12M,
      V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, V4L2_PIX_FMT_NV16M for source and
      V4L2_PIX_FMT_JPEG for destination.
      
      During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and
      V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_NV16M, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16
      for destination.
      
      Performance of current version:
      1280x800 NV12 image encoding/decoding
      	decoding ~122 FPS
      	encoding ~191 FPS
      Signed-off-by: NMikhail Ulyanov <mikhail.ulyanov@cogentembedded.com>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      2c42cdba
  14. 10 6月, 2015 1 次提交
  15. 03 4月, 2015 1 次提交
  16. 23 12月, 2014 1 次提交
  17. 17 12月, 2014 1 次提交
  18. 28 10月, 2014 1 次提交
  19. 22 9月, 2014 1 次提交
  20. 03 9月, 2014 2 次提交
  21. 27 8月, 2014 1 次提交
  22. 22 8月, 2014 1 次提交
  23. 20 12月, 2013 1 次提交
    • H
      [media] omap24xx/tcm825x: move to staging for future removal · a03636cb
      Hans Verkuil 提交于
      The omap24xx driver and the tcm825x sensor driver are the only two
      remaining drivers to still use the old deprecated v4l2-int-device API.
      
      Nobody maintains these drivers anymore. But unfortunately the v4l2-int-device
      API is used by out-of-tree drivers (MXC platform). This is a very bad situation
      since as long as this deprecated API stays in the kernel there is no reason for
      those out-of-tree drivers to convert.
      
      This patch moves v4l2-int-device and the two drivers that depend on it to
      staging in preparation for their removal.
      
      If someone would be interested in getting these drivers to work, then start with
      this since it's not very far from the state where they used to work:
      
      <URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux-omap/.git;a=summary>
      
      The branch is n800-cam. Porting to up-to-date APIs can then be done. David
      might have done some work in that area, so check with him first.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Cc: Sakari Ailus <sakari.ailus@iki.fi>
      Cc: David Cohen <dacohen@gmail.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      a03636cb
  24. 29 10月, 2013 1 次提交
    • A
      [media] v4l: ti-vpe: Add VPE mem to mem driver · 45719127
      Archit Taneja 提交于
      VPE is a block which consists of a single memory to memory path which
      can perform chrominance up/down sampling, de-interlacing, scaling, and
      color space conversion of raster or tiled YUV420 coplanar, YUV422
      coplanar or YUV422 interleaved video formats.
      
      We create a mem2mem driver based primarily on the mem2mem-testdev
      example. The de-interlacer, scaler and color space converter are all
      bypassed for now to keep the driver simple. Chroma up/down sampler
      blocks are implemented, so conversion beteen different YUV formats is
      possible.
      
      Each mem2mem context allocates a buffer for VPE MMR values which it will
      use when it gets access to the VPE HW via the mem2mem queue, it also
      allocates a VPDMA descriptor list to which configuration and data
      descriptors are added.
      
      Based on the information received via v4l2 ioctls for the source and
      destination queues, the driver configures the values for the MMRs, and
      stores them in the buffer. There are also some VPDMA parameters like
      frame start and line mode which needs to be configured, these are
      configured by direct register writes via the VPDMA helper functions.
      
      The driver's device_run() mem2mem op will add each descriptor based on
      how the source and destination queues are set up for the given ctx, once
      the list is prepared, it's submitted to VPDMA, these descriptors when
      parsed by VPDMA will upload MMR registers, start DMA of video buffers on
      the various input and output clients/ports.
      
      When the list is parsed completely(and the DMAs on all the output ports
      done), an interrupt is generated which we use to notify that the source
      and destination buffers are done. The rest of the driver is quite
      similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as
      the HW support coplanar formats.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      45719127
  25. 18 8月, 2013 1 次提交
  26. 31 3月, 2013 1 次提交
  27. 21 12月, 2012 1 次提交
  28. 28 11月, 2012 1 次提交
  29. 16 9月, 2012 1 次提交
  30. 15 9月, 2012 2 次提交
  31. 22 8月, 2012 1 次提交
  32. 21 8月, 2012 2 次提交
  33. 16 8月, 2012 2 次提交