1. 28 6月, 2013 1 次提交
    • G
      lib: Move fonts from drivers/video/console/ to lib/fonts/ · ee89bd6b
      Geert Uytterhoeven 提交于
      Several drivers need font support independent of CONFIG_VT, cfr. commit
      9cbce8d7e1dae0744ca4f68d62aa7de18196b6f4, "console/font: Refactor font
      support code selection logic").
      Hence move the fonts and their support logic from drivers/video/console/ to
      its own library directory lib/fonts/.
      This also allows to limit processing of drivers/video/console/Makefile to
      CONFIG_VT=y again.
      
      [Kevin Hilman <khilman@linaro.org>: Update arch/arm/boot/compressed/Makefile]
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      ee89bd6b
  2. 08 6月, 2013 1 次提交
  3. 06 6月, 2013 1 次提交
  4. 01 6月, 2013 3 次提交
    • M
      powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions · 2b3f8e87
      Michael Neuling 提交于
      When in an active transaction that takes a signal, we need to be careful with
      the stack.  It's possible that the stack has moved back up after the tbegin.
      The obvious case here is when the tbegin is called inside a function that
      returns before a tend.  In this case, the stack is part of the checkpointed
      transactional memory state.  If we write over this non transactionally or in
      suspend, we are in trouble because if we get a tm abort, the program counter
      and stack pointer will be back at the tbegin but our in memory stack won't be
      valid anymore.
      
      To avoid this, when taking a signal in an active transaction, we need to use
      the stack pointer from the checkpointed state, rather than the speculated
      state.  This ensures that the signal context (written tm suspended) will be
      written below the stack required for the rollback.  The transaction is aborted
      becuase of the treclaim, so any memory written between the tbegin and the
      signal will be rolled back anyway.
      
      For signals taken in non-TM or suspended mode, we use the
      normal/non-checkpointed stack pointer.
      
      Tested with 64 and 32 bit signals
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2b3f8e87
    • M
      powerpc/tm: Abort on emulation and alignment faults · 6ce6c629
      Michael Neuling 提交于
      If we are emulating an instruction inside an active user transaction that
      touches memory, the kernel can't emulate it as it operates in transactional
      suspend context.  We need to abort these transactions and send them back to
      userspace for the hardware to rollback.
      
      We can service these if the user transaction is in suspend mode, since the
      kernel will operate in the same suspend context.
      
      This adds a check to all alignment faults and to specific instruction
      emulations (only string instructions for now).  If the user process is in an
      active (non-suspended) transaction, we abort the transaction go back to
      userspace allowing the HW to roll back the transaction and tell the user of the
      failure.  This also adds new tm abort cause codes to report the reason of the
      persistent error to the user.
      
      Crappy test case here http://neuling.org/devel/junkcode/aligntm.cSigned-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6ce6c629
    • M
      powerpc/tm: Update cause codes documentation · 24b92375
      Michael Neuling 提交于
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # 3.9 only
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      24b92375
  5. 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
  6. 15 5月, 2013 2 次提交
  7. 14 5月, 2013 4 次提交
  8. 09 5月, 2013 1 次提交
  9. 08 5月, 2013 3 次提交
  10. 07 5月, 2013 1 次提交
  11. 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
  12. 02 5月, 2013 4 次提交
  13. 01 5月, 2013 3 次提交
  14. 30 4月, 2013 12 次提交