1. 18 Aug, 2013 28 commits
  2. 01 Aug, 2013 4 commits
  3. 31 Jul, 2013 5 commits
    • Srinivas Kandagatla's avatar
      [media] media: lirc: Allow lirc dev to talk to rc device · ca7a722d
      Srinivas Kandagatla authored
      The use case is simple, if any rc device has allowed protocols =
      RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never
      called. The reason for this is, all of the key maps except lirc have some
      KEYS in there map, so during rc_register_device process these keys are
      matched against the input drivers and open is performed, so for the case
      of RC_MAP_EMPTY, a vt/keyboard is matched and the driver open is
      performed.
      In case of lirc, there is no match and result is that there is no open
      performed, however the lirc-dev will go ahead and create a /dev/lirc0
      node. Now when lircd/mode2 opens this device, no data is available
      because the driver was never opened.
      Other case pointed by Sean Young, As rc device gets opened via the
      input interface. If the input device is never opened (e.g. embedded with
      no console) then the rc open is never called and lirc will not work
      either. So that's another case.
      lirc_dev seems to have no link with actual rc device w.r.t open/close.
      This patch adds rc_dev pointer to lirc_driver structure for cases like
      this, so that it can do the open/close of the real driver in accordance
      to lircd/mode2 open/close.
      Without this patch its impossible to open a rc device which has
      RC_TYPE_LIRC ad RC_MAP_LIRC set.
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@st.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      ca7a722d
    • Srinivas Kandagatla's avatar
      [media] media: rc: Add rc_open/close and use count to rc_dev · 8b2ff320
      Srinivas Kandagatla authored
      This patch adds user count to rc_dev structure, the reason to add this
      new member is to allow other code like lirc to open rc device directly.
      In the existing code, rc device is only opened by input subsystem which
      works ok if we have any input drivers to match. But in case like lirc
      where there will be no input driver, rc device will be never opened.
      Having this user count variable will be usefull to allow rc device to be
      opened from code other than rc-main.
      This patch also adds rc_open and rc_close functions for other drivers
      like lirc to open and close rc devices. This functions safely increment
      and decrement the user count. Other driver wanting to open rc device
      should call rc_open and rc_close, rather than directly modifying the
      rc_dev structure.
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@st.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      8b2ff320
    • Philipp Zabel's avatar
      [media] coda: add CODA7541 decoding support · 918c66fd
      Philipp Zabel authored
      This patch enables decoding of h.264 and mpeg4 streams on CODA7541.
      Queued output buffers are immediately copied into the bitstream
      ringbuffer. A device_run can be scheduled whenever there is either
      enough compressed bitstream data, or the CODA is in stream end mode.
      Each successful device_run, data is read from the bitstream ringbuffer
      and a frame is decoded into a free internal framebuffer. Depending on
      reordering, a possibly previously decoded frame is marked as display
      frame, and at the same time the display frame from the previous run
      is copied out into a capture buffer by the rotator hardware.
      The dequeued capture buffers are counted to send the EOS signal to
      userspace with the last frame. When userspace sends the decoder stop
      command or enqueues an empty output buffer, the stream end flag is
      set to allow decoding the remaining frames in the bitstream
      ringbuffer.
      The enum_fmt/try_fmt functions return fixed capture buffer sizes
      while the output queue is streaming, to allow better autonegotiation
      in userspace.
      A per-context buffer mutex is used to lock the picture run against
      buffer dequeueing: if a job gets queued, then streamoff dequeues
      the last buffer, and then device_run is called, bail out. For that
      the interrupt handler has to be threaded.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarKamil Debski <k.debski@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      918c66fd
    • Philipp Zabel's avatar
      [media] coda: split encoder specific parts out of device_run and irq_handler · 477c1cfe
      Philipp Zabel authored
      Add coda_prepare_encode() and coda_finish_encode() functions. They are called
      from coda_device_run() and coda_irq_handler(), respectively, before and after
      the hardware picture run. This should make the following decoder support patch
      easier to read, which will add the coda_prepare/finish_decode() equivalents.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarKamil Debski <k.debski@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      477c1cfe
    • Philipp Zabel's avatar
      [media] coda: dynamic IRAM setup for decoder · 8358e76c
      Philipp Zabel authored
      This sets up IRAM areas used as temporary memory for the different
      hardware units depending on the frame size.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarKamil Debski <k.debski@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      8358e76c
  4. 30 Jul, 2013 3 commits