1. 26 7月, 2014 1 次提交
  2. 05 7月, 2014 1 次提交
  3. 12 3月, 2014 1 次提交
  4. 05 2月, 2014 1 次提交
  5. 31 10月, 2013 1 次提交
  6. 22 8月, 2013 2 次提交
  7. 19 3月, 2013 1 次提交
  8. 12 1月, 2013 1 次提交
    • T
      ARM: OMAP2+: Disable code that currently does not work with multiplaform · a62a6e98
      Tony Lindgren 提交于
      We still need to fix up few places for multiplatform support,
      but that can proceed separately. Fix the issue by making the
      problem drivers depends !ARCH_MULTIPLATFORM for now.
      
      The remaining pieces that are not multiplatform compatible
      for omap2+ SoCs are:
      
      1. Some drivers are using custom omap_dm_timer calls
      
      There are two drivers that are directly usign omap hardware
      timers for PWM and DSP clocking: drivers/media/rc/ir-rx51.c and
      drivers/staging/tidspbridge/core/dsp-clock.c. These can be
      fixed for multiplatform by allowing a minimal set of hardware
      timers to be accessed, and for some functionality by using the
      hrtimer framework.
      
      2. Hardware OMAP4_ERRATA_I688 needs to be fixed up
      
      This can't be enabled for multiplatform configurations in
      it's current form. It may be possible to fix it up to do
      instruction replacement early on during init. Luckily it
      looks like this errata does not seem to get hit with
      mainline kernel code alone at least currently.
      
      3. Legacy header needed for omap-sham.c
      
      Looks like it still needs mach/irqs.h for omap1 that
      does not exist for multiplatform systems. Just ifdef
      it for now.
      
      4. Mailbox is waiting to get moved to drivers
      
      Disable it for now to avoid adding a dependency to the
      mailbox patches.
      
      Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
      Cc: Sean Young <sean@mess.org>
      Cc: "Víctor Manuel Jáquez Leal" <vjaquez@igalia.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      [tony@atomide.com: updated to disable mailbox]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a62a6e98
  9. 16 9月, 2012 2 次提交
  10. 15 9月, 2012 1 次提交
  11. 14 8月, 2012 4 次提交
  12. 12 8月, 2012 1 次提交
  13. 31 7月, 2012 1 次提交
  14. 06 7月, 2012 3 次提交
  15. 15 5月, 2012 1 次提交
  16. 08 3月, 2012 1 次提交
  17. 24 11月, 2011 1 次提交
  18. 22 9月, 2011 3 次提交
  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. 26 5月, 2011 1 次提交
    • J
      [media] fintek-cir: new driver for Fintek LPC SuperIO CIR function · 9bdc79ea
      Jarod Wilson 提交于
      This is a new driver for the Fintek LPC SuperIO CIR function, in the
      Fintek F71809 chip. Hardware and datasheets were provided by Fintek, so
      thanks go to them for supporting this effort.
      
      This driver started out as a copy of the nuvoton-cir driver, and was
      then modified as needed for the Fintek chip. The two share many
      similaries, though the buffer handling for the Fintek chip is actually
      nearly identical to the mceusb buffer handling, so the parser routine is
      almost a drop-in copy of the mceusb buffer parser (a candidate for being
      abstracted out into shared code at some point).
      
      This initial code drop *only* supports receive, but the hardware does
      support transmit as well. I really haven't even started to look at
      what's required, but my guess is that its also pretty similar to mceusb.
      Most people are probably only really interested in RX anyway though, so
      I think its good to get this out there even with only RX.
      
      (Nb: there are also Fintek-made mceusb receivers, which presumably, this
      chip shares CIR hardware with).
      
      This hardware can be found on at least Jetway NC98 boards and derivative
      systems, and likely others as well. Functionality was tested with an
      NC98 development board, in-kernel decode of RC6 (mce), RC5 (hauppauge)
      and NEC-ish (tivo) remotes all successful, as was lirc userspace decode
      of the RC6 remote.
      
      CC: Aaron Huang <aaron_huang@fintek.com.tw>
      CC: Tom Tsai <tom_tsai@fintek.com.tw>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      9bdc79ea
  21. 21 5月, 2011 1 次提交
    • J
      [media] redrat3: new rc-core IR transceiver device driver · 2154be65
      Jarod Wilson 提交于
      This is a new rc-core device driver for the IR transceivers made by
      RedRat Ltd. (http://redrat.co.uk/). It started out life as an
      out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge,
      by Stephen Cox. He started porting it to what was then ir-core, and I
      finally picked it up about two week ago and did a fairly large overhaul
      on it, and its now into a state where I'm fairly comfortable submitting
      it here for review and inclusion in the kernel. I'm claiming authorship
      of this driver, since while it started out as Stephen's work, its
      definitely a derivative work now, at 876 lines added and 1698 lines
      removed since grabbing it from sourceforge. Stephen's name is retained
      as secondary author though, and credited in the headers. Those
      interested in seeing how the changes evolved can (at least for now) look
      at this branch in my git tree:
      
      http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3
      
      That won't be around forever though, and I'm doing this as a single
      commit to go into mainline. Anyway...
      
      I've successfully tested in-kernel decode of rc5, rc6 and nec remotes,
      as well as lirc userspace decode of rc5 and rc6. There are still some
      quirks here to sort out with rc5 lirc userspace decode, but I'm working
      with the RedRat folks themselves to figure out what's going on there
      (rc5 lirc decode works, but you only get an event on key release --
      in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of
      rc6 is working perfectly. Transmit is also working, tested by pointing
      the redrat3 at an mceusb transceiver, which happily picked up the
      transmitted signals and properly decoded them.
      
      There's no default remote for this hardware, so its somewhat arbitrarily
      set to use the Hauppauge RC5 keymap by default. Easily changed out by
      way of ir-keytable and irrelevant if you're using lircd for decode.
      
      CC: Chris Dodge <chris@redrat.co.uk>
      CC: Andrew Vincer <Andrew.Vincer@redrat.co.uk>
      CC: Stephen Cox <scox_nz@yahoo.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      2154be65
  22. 23 3月, 2011 2 次提交
  23. 29 12月, 2010 6 次提交
  24. 21 10月, 2010 2 次提交