1. 11 6月, 2013 1 次提交
  2. 05 6月, 2013 7 次提交
  3. 28 5月, 2013 4 次提交
  4. 25 5月, 2013 2 次提交
    • S
      drivers/video: implement a simple framebuffer driver · 26549c8d
      Stephen Warren 提交于
      A simple frame-buffer describes a raw memory region that may be rendered
      to, with the assumption that the display hardware has already been set
      up to scan out from that buffer.
      
      This is useful in cases where a bootloader exists and has set up the
      display hardware, but a Linux driver doesn't yet exist for the display
      hardware.
      
      Examples use-cases include:
      
      * The built-in LCD panels on the Samsung ARM chromebook, and Tegra
        devices, and likely many other ARM or embedded systems.  These cannot
        yet be supported using a full graphics driver, since the panel control
        should be provided by the CDF (Common Display Framework), which has been
        stuck in design/review for quite some time.  One could support these
        panels using custom SoC-specific code, but there is a desire to use
        common infra-structure rather than having each SoC vendor invent their
        own code, hence the desire to wait for CDF.
      
      * Hardware for which a full graphics driver is not yet available, and
        the path to obtain one upstream isn't yet clear.  For example, the
        Raspberry Pi.
      
      * Any hardware in early stages of upstreaming, before a full graphics
        driver has been tackled.  This driver can provide a graphical boot
        console (even full X support) much earlier in the upstreaming process,
        thus making new SoC or board support more generally useful earlier.
      
      [akpm@linux-foundation.org: make simplefb_formats[] static]
      Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Cc: Rob Clark <robclark@gmail.com>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Tomasz Figa <tomasz.figa@gmail.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26549c8d
    • A
      rapidio: documentation update for enumeration changes · 5eeb9293
      Alexandre Bounine 提交于
      Update RapidIO documentation to reflect changes made to
      enumeration/discovery build configuration and user space triggering
      mechanism.
      Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Li Yang <leoli@freescale.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Andre van Herk <andre.van.herk@Prodrive.nl>
      Cc: Micha Nelissen <micha.nelissen@Prodrive.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5eeb9293
  5. 15 5月, 2013 2 次提交
  6. 14 5月, 2013 4 次提交
  7. 09 5月, 2013 1 次提交
  8. 08 5月, 2013 3 次提交
  9. 07 5月, 2013 1 次提交
  10. 04 5月, 2013 2 次提交
    • J
      hwmon: (lm75) Add support for the Dallas/Maxim DS7505 · 3fbc81e3
      Jean Delvare 提交于
      Basically it's the same as the original DS75 but much faster.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      3fbc81e3
    • J
      hwmon: (lm75) Tune resolution and sample time per chip · 0cd2c72d
      Jean Delvare 提交于
      Most LM75-compatible chips can either sample much faster or with a
      much better resolution than the original LM75 chip. So far the lm75
      driver did not let the user take benefit of these improvements. Do it
      now.
      
      I decided to almost always configure the chip to use the best
      resolution possible, which also means the longest sample time. The
      only chips for which I didn't are the DS75, DS1775 and STDS75, because
      they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
      so I went for 11-bit mode as a more reasonable tradeoff. This choice is
      dictated by the fact that the hwmon subsystem is meant for system
      monitoring, it has never been supposed to be ultra-fast, and as a
      matter of fact we do cache the sampled values in almost all drivers.
      
      If anyone isn't pleased with these default settings, they can always
      introduce a platform data structure or DT support for the lm75. That
      being said, it seems nobody ever complained that the driver wouldn't
      refresh the value faster than every 1.5 second, and the change made
      it faster for all chips even in 12-bit mode, so I don't expect any
      complaint.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      0cd2c72d
  11. 02 5月, 2013 4 次提交
  12. 01 5月, 2013 3 次提交
  13. 30 4月, 2013 6 次提交