1. 29 10月, 2013 14 次提交
    • P
      [media] coda: add compressed flag to format enumeration output · baf70211
      Philipp Zabel 提交于
      Correctly flag compressed formats in the ENUM_FMT ioctl output.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      baf70211
    • P
      [media] coda: only set buffered input queue for decoder · eb107516
      Philipp Zabel 提交于
      Allow device_run with no buffers queued after streamoff only when
      the current instance is a decoder.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      [k.debski@samsung.com: Add commit description]
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      eb107516
    • P
      [media] coda: allow more than four instances on CODA7541 · 0cddc7e9
      Philipp Zabel 提交于
      With the new firmware, there are not anymore four register sets,
      but a single register set, which the driver has to conserve across
      context switches. This allows to handle more than four instances
      at the same time.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      0cddc7e9
    • S
      [media] v4l2-mem2mem: Don't schedule the context if abort job is called · 2ad5389b
      Shaik Ameer Basha 提交于
      When the current context is running,
      1] If release is called, it waits until the job is finished.
      2] As soon as the job is finished, v4l2_mem_ctx_release()tries to
         release the vb2 queues.
      3] But if the current context can be scheduled in the v4l2_m2m_job_finish()
         it schedules the context and tries to call device_run().
      4] As the release() and device_run() sequence can't be predicted sometimes
         device_run() may get empty vb2 buffers.
      
      This patch adds the ABORT state to the job_flags. Once the job_abort() or
      release() is called on the context, the same context will not be scheduled in
      the v4l2_m2m_job_finish().
      Signed-off-by: NShaik Ameer Basha <shaik.ameer@samsung.com>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      2ad5389b
    • S
      [media] exynos-gsc: Handle ctx job finish when aborted · d9315160
      Shaik Ameer Basha 提交于
      When the current context is running,
      1] If release() or streamoff() is called on the current context,
         it waits until the job is aborted or finished.
      2] If the job is finished, driver will call the v4l2_m2m_job_finish().
      3] If the job is aborted inside device_run callback, then driver
         has to inform the v4l2 mem2mem framework about the same by calling
         v4l2_m2m_job_finish() with VB2_BUF_STATE_ERROR.
      
      The current code doesn't call v4l2_m2m_job_finish() in the case, where
      the job is aborted from the device_run callback. This scenerio is
      producing a hang as the other queued contexts are not getting scheduled.
      
      By adding the ABORT state, driver can understand the current job
      is aborted and not finished. By checking this flag, driver can call
      v4l2_m2m_job_finish() with VB2_BUF_STATE_ERROR.
      Signed-off-by: NShaik Ameer Basha <shaik.ameer@samsung.com>
      Signed-off-by: NAvnd Kiran <avnd.kiran@samsung.com>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      d9315160
    • P
      [media] v4l2-mem2mem: clear m2m queue ready counter in v4l2_m2m_streamoff · 84e68098
      Philipp Zabel 提交于
      v4l2_m2m_streamoff drops the list of ready buffers but failed to reset the
      num_rdy counter to zero. This would lead to v4l2_m2m_num_src/dst_bufs_ready
      reporting wrong values after streamoff.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      84e68098
    • P
      [media] v4l2-mem2mem: fix context removal from job queue in v4l2_m2m_streamoff · d7bb0ce8
      Philipp Zabel 提交于
      Just clearing the m2m_ctx->queue list_head will leave the m2m_dev->job_queue
      in a broken state and can cause scheduling of device_runs after streamoff was
      called.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      d7bb0ce8
    • J
      [media] mem2mem_testdev: Remove casting the return value which is a void pointer · ede79413
      Jingoo Han 提交于
      Casting the return value which is a void pointer is redundant.
      The conversion from void pointer to any other pointer type is
      guaranteed by the C programming language.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      ede79413
    • J
      [media] m2m-deinterlace: Remove casting the return value which is a void pointer · 825143d3
      Jingoo Han 提交于
      Casting the return value which is a void pointer is redundant.
      The conversion from void pointer to any other pointer type is
      guaranteed by the C programming language.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      825143d3
    • J
      [media] s5p-g2d: Remove casting the return value which is a void pointer · 4e3eff61
      Jingoo Han 提交于
      Casting the return value which is a void pointer is redundant.
      The conversion from void pointer to any other pointer type is
      guaranteed by the C programming language.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NKamil Debski <k.debski@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      4e3eff61
    • A
      [media] v4l: ti-vpe: Add de-interlacer support in VPE · 585e6f01
      Archit Taneja 提交于
      Add support for the de-interlacer block in VPE. For de-interlacer to
      work, we need to enable 2 more sets of VPE input ports which fetch data
      from the 'last' and 'last to last' fields of the interlaced video. Apart
      from that, we need to enable the Motion vector output and input ports,
      and also allocate DMA buffers for them.
      
      We need to make sure that two most recent fields in the source queue are
      available and in the 'READY' state. Once a mem2mem context gets access
      to the VPE HW(in device_run), it extracts the addresses of the 3
      buffers, and provides it to the data descriptors for the 3 sets of input
      ports((LUMA1, CHROMA1), (LUMA2, CHROMA2), and (LUMA3, CHROMA3))
      respectively for the 3 consecutive fields. The motion vector and output
      port descriptors are configured and the list is submitted to VPDMA.
      
      Once the transaction is done, the v4l2 buffer corresponding to the
      oldest field(the 3rd one) is changed to the state 'DONE', and the
      buffers corresponding to 1st and 2nd fields become the 2nd and 3rd field
      for the next de-interlace operation. This way, for each deinterlace
      operation, we have the 3 most recent fields. After each transaction, we
      also swap the motion vector buffers, the new input motion vector buffer
      contains the resultant motion information of all the previous frames,
      and the new output motion vector buffer will be used to hold the updated
      motion vector to capture the motion changes in the next field. The
      motion vector buffers are allocated using the DMA allocation API.
      
      The de-interlacer is removed from bypass mode, it requires some extra
      default configurations which are now added. The chrominance upsampler
      coefficients are added for interlaced frames. Some VPDMA parameters like
      frame start event and line mode are configured for the 2 extra sets of
      input ports.
      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>
      585e6f01
    • 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
    • A
      [media] v4l: ti-vpe: Add helpers for creating VPDMA descriptors · 213b8ee4
      Archit Taneja 提交于
      Create functions which the VPE driver can use to create a VPDMA
      descriptor and add it to a VPDMA descriptor list. These functions take a
      pointer to an existing list, and append the configuration/data/control
      descriptor header to the list.
      
      In the case of configuration descriptors, the creation of a payload
      block may be required(the payloads can hold VPE MMR values, or scaler
      coefficients). The allocation of the payload buffer and it's content is
      left to the VPE driver. However, the VPDMA library provides helper
      macros to create payload in the correct format.
      
      Add debug functions to dump the descriptors in a way such that it's easy
      to see the values of different fields in the descriptors.
      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>
      213b8ee4
    • A
      [media] v4l: ti-vpe: Create a vpdma helper library · 9262e5a2
      Archit Taneja 提交于
      The primary function of VPDMA is to move data between external memory
      and internal processing modules(in our case, VPE) that source or sink
      data. VPDMA is capable of buffering this data and then delivering the
      data as demanded to the modules as programmed. The modules that source
      or sink data are referred to as clients or ports. A channel is setup
      inside the VPDMA to connect a specific memory buffer to a specific
      client. The VPDMA centralizes the DMA control functions and buffering
      required to allow all the clients to minimize the effect of long latency
      times.
      
      Add the following to the VPDMA helper:
      
      - A data struct which describe VPDMA channels. For now, these channels
        are the ones used only by VPE, the list of channels will increase when
        VIP(Video Input Port) also uses the VPDMA library. This channel
        information will be used to populate fields required by data
        descriptors.
      
      - Data structs which describe the different data types supported by
        VPDMA. This data type information will be used to populate fields
        required by data descriptors and used by the VPE driver to map a V4L2
        format to the corresponding VPDMA data type.
      
      - Provide VPDMA register offset definitions, functions to read, write
        and modify VPDMA registers.
      
      - Functions to create and submit a VPDMA list. A list is a group of
        descriptors that makes up a set of DMA transfers that need to be
        completed. Each descriptor will either perform a DMA transaction to
        fetch input buffers and write to output buffers(data descriptors), or
        configure the MMRs of sub blocks of VPE(configuration descriptors), or
        provide control information to VPDMA (control descriptors).
      
      - Functions to allocate, map and unmap buffers needed for the descriptor
        list, payloads containing MMR values and scaler coefficients. These use
        the DMA mapping APIs to ensure exclusive access to VPDMA.
      
      - Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt
        on the VPE interrupt line when a descriptor list is parsed completely
        and the DMA transactions are completed. This requires masking the events
        in VPDMA registers and configuring some top level VPE interrupt
        registers.
      
      - Enable some VPDMA specific parameters: frame start event(when to start
        DMA for a client) and line mode(whether each line fetched should be
        mirrored or not).
      
      - Function to load firmware required by VPDMA. VPDMA requires a firmware
        for it's internal list manager. We add the required request_firmware
        apis to fetch this firmware from user space.
      
      - Function to dump VPDMA registers.
      
      - A function to initialize and create a VPDMA instance, this will be
        called by the VPE driver with it's platform device pointer, this
        function will take care of loading VPDMA firmware and returning a
        vpdma_data instance back to the VPE driver. The VIP driver will also
        call the same init function to initialize it's own VPDMA instance.
      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>
      9262e5a2
  2. 17 10月, 2013 26 次提交