1. 14 6月, 2017 1 次提交
  2. 24 3月, 2017 1 次提交
  3. 30 1月, 2017 5 次提交
  4. 25 1月, 2016 1 次提交
    • H
      [media] media: rc: raw: improve FIFO handling · 464254e5
      Heiner Kallweit 提交于
      The FIFO is used for ir_raw_event records, however for some historic
      reason the FIFO is used on a per byte basis. IMHO this adds unneeded
      complexity. Therefore set up the FIFO for ir_raw_event records.
      
      This also allows to define the FIFO statically as part of
      ir_raw_event_ctrl instead of having to allocate the FIFO dynamically.
      In addition:
      
      - When writing into the FIFO and it's full return ENOSPC instead of
        ENOMEM thus making it easier to tell between "FIFO full" and
        "Dynamic memory allocation failed" when the error is propagated to
        a higher level.
        Also add an error message.
      
      - When reading from the FIFO check whether it's empty.
        This is not strictly needed here but kfifo_out is annotated
        "must check" anyway.
      
      Successfully tested it with the nuvoton-cir driver.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      464254e5
  5. 04 12月, 2015 1 次提交
  6. 19 11月, 2015 1 次提交
  7. 19 8月, 2015 3 次提交
  8. 15 5月, 2015 3 次提交
  9. 27 7月, 2014 1 次提交
  10. 26 7月, 2014 1 次提交
  11. 07 2月, 2014 1 次提交
  12. 06 2月, 2014 1 次提交
  13. 05 2月, 2014 1 次提交
  14. 23 3月, 2013 1 次提交
  15. 28 12月, 2012 1 次提交
  16. 08 3月, 2012 1 次提交
    • J
      [media] rc/ir-raw: use kfifo_rec_ptr_1 instead of kfifo · df1caa58
      James Hogan 提交于
      Raw IR events are passed to the raw event thread through a kfifo. The
      size of the event struct is 12 bytes, and space for 512 events is
      reserved in the kfifo (6144 bytes), however this is rounded down to 4096
      bytes (the next power of 2) by __kfifo_alloc().
      
      4096 bytes is not divisible by 12 therefore if the fifo fills up a third
      of a record will be written in the end of the kfifo by
      ir_raw_event_store() because the recsize of the fifo is 0 (it doesn't
      have records). When this is read by ir_raw_event_thread() a corrupted or
      partial record will be read, and in the case of a partial record the
      BUG_ON(retval != sizeof(ev)) gets hit too.
      
      According to samples/kfifo/record-example.c struct kfifo_rec_ptr_1 can
      handle records of a length between 0 and 255 bytes, so change struct
      ir_raw_event_ctrl to use that instead of struct kfifo.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      df1caa58
  17. 24 11月, 2011 1 次提交
  18. 24 9月, 2011 1 次提交
    • P
      [media] media, rc: Use static inline functions to kill warnings · 600836cc
      Pekka Enberg 提交于
      This patch converts some ifdef'd wrapper functions from macros to static inline
      functions to kill the following warnings issued by GCC:
      
          CC [M]  drivers/media/rc/ir-raw.o
        drivers/media/rc/ir-raw.c: In function ‘init_decoders’:
        drivers/media/rc/ir-raw.c:353:2: warning: statement with no effect [-Wunused-value]
        drivers/media/rc/ir-raw.c:354:2: warning: statement with no effect [-Wunused-value]
        drivers/media/rc/ir-raw.c:355:2: warning: statement with no effect [-Wunused-value]
        drivers/media/rc/ir-raw.c:356:2: warning: statement with no effect [-Wunused-value]
        drivers/media/rc/ir-raw.c:357:2: warning: statement with no effect [-Wunused-value]
        drivers/media/rc/ir-raw.c:359:2: warning: statement with no effect [-Wunused-value]
      
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: "David Härdeman" <david@hardeman.nu>
      Cc: Jarod Wilson <jarod@redhat.com>
      Cc: <linux-media@vger.kernel.org>
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      600836cc
  19. 28 7月, 2011 1 次提交
    • J
      [media] rc-core support for Microsoft IR keyboard/mouse · f5f2cc64
      Jarod Wilson 提交于
      This is a custom IR protocol decoder, for the RC-6-ish protocol used by
      the Microsoft Remote Keyboard, apparently developed internally at
      Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and
      transceiver requirements and specifications document, which also touches
      on this IR keyboard/mouse device.
      
      Its a standard keyboard with embedded thumb stick mouse pointer and
      mouse buttons, along with a number of media keys. The media keys are
      standard RC-6, identical to the signals from the stock MCE remotes, and
      will be handled as such. The keyboard and mouse signals will be decoded
      and delivered to the system by an input device registered specifically
      by this driver.
      
      Successfully tested with multiple mceusb-driven transceivers, as well as
      with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware
      with enough sampling resolution should be able to use this decoder,
      nothing about it is at all receiver-hardware-specific.
      
      This work is inspired by lirc_mod_mce:
      
      The documentation there and code aided in understanding and decoding the
      protocol, but the bulk of the code is actually borrowed more from the
      existing in-kernel decoders than anything. I did recycle the keyboard
      keycode table, a few defines, and some of the keyboard and mouse data
      parsing bits from lirc_mod_mce though.
      
      Special thanks to James Meyer for providing the hardware, and being
      patient with me as I took forever to get around to writing this.
      
      callback routine to ensure we don't get any stuck keys, and used
      symbolic names for the keytable. Also cc'ing Florian this time, who I
      believe is the original mod-mce author...
      
      CC: Florian Demski <fdemski@users.sourceforge.net>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      f5f2cc64
  20. 29 12月, 2010 6 次提交
  21. 21 10月, 2010 4 次提交
    • M
      [media] IR: extend ir_raw_event and do refactoring · 4651918a
      Maxim Levitsky 提交于
      Add new event types for timeout & carrier report
      Move timeout handling from ir_raw_event_store_with_filter to
      ir-lirc-codec, where it is really needed.
      Now lirc bridge ensures proper gap handling.
      Extend lirc bridge for carrier & timeout reports
      
      Note: all new ir_raw_event variables now should be initialized
      like that: DEFINE_IR_RAW_EVENT(ev);
      
      To clean an existing event, use init_ir_raw_event(&ev);
      Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Acked-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      4651918a
    • M
      [media] IR: make sure we register the input device when it is safe to do so · 58b3dd44
      Maxim Levitsky 提交于
      As soon as input device is registered, it might be accessed (and it is)
      This can trigger a hardware interrupt that can access
      not yet initialized ir->raw, (by sending a sample)
      
      This can be reproduced by holding down a remote button and reloading the module.
      And this always crashes the systems where hardware decides to send an interrupt
      right at the moment it is enabled.
      Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Acked-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      58b3dd44
    • M
      [media] IR: plug races in IR raw thread · c6ef1e7f
      Maxim Levitsky 提交于
      Unfortunelly (my fault) the kernel thread that now handles IR processing
      has classical races in regard to wakeup and stop.
      This patch hopefully closes them all.
      Tested with module reload running in a loop, while receiver is blasted
      with IR data for 10 minutes.
      Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Acked-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c6ef1e7f
    • J
      V4L/DVB: IR/streamzap: functional in-kernel decoding · 7a569f52
      Jarod Wilson 提交于
      This patch makes in-kernel decoding with the stock Streamzap PC Remote
      work out of the box. There are quite a few things going on in this
      patch, all related to getting this working:
      
      1) I had to enable reporting of a long space at the end of each signal,
         or I had weird buffering and keybounce issues.
      
      2) The keymap has been reworked slightly to match actual decoded values,
         the first edition was missing the pre-data bits present in the lirc
         config file for this remote.
      
      3) There's a whole new decoder included, specifically for the
         not-quite-RC5 15-bit protocol variant used by the Streamzap PC
         Remote. The decoder, while usable with other recievers (tested with
         an mceusb receiver), will only be loaded by the streamzap driver, as
         its likely not of use in almost all other situations. This can be
         revisited if/when all keytable loading (and disabling of unneeded
         protocol decoder engines) is moved to userspace, but for now, I think
         this makes the most sense.
      
      Note that I did try to enable handling the streamzap RC5-ish protocol in
      the current RC5 decoder, but there's no particularly easy way to tell if
      its 14-bit RC5 or 15-bit Streamzap until we see bit 14, and even then,
      in testing an attempted decoder merge, only 2/3 of the keys were
      properly recognized as being the 15-bit variant and decoded correctly,
      the rest were close enough to compliant with 14-bit that they were
      decoded as such (but they have overlap with one another, and thus we
      can't just shrug and use the 14-bit decoded values).
      
      Also of note in this patch is the removal of the streamzap driver's
      internal delay buffer. Per discussion w/Christoph, it shouldn't be
      needed by lirc any longer anyway, and it doesn't seem to make any
      difference to the in-kernel decoder engine. That being the case, I'm
      yanking it all out, as it greatly simplifies the driver code.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      7a569f52
  22. 09 8月, 2010 3 次提交