1. 17 12月, 2015 3 次提交
  2. 03 12月, 2015 6 次提交
  3. 17 11月, 2015 3 次提交
  4. 10 11月, 2015 1 次提交
  5. 07 11月, 2015 2 次提交
    • M
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman 提交于
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      reserves.
      
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      
      This patch then converts a number of sites
      
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: NMel Gorman <mgorman@techsingularity.net>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0164adc
    • S
      Revert "ARM: dts: twl4030: Add iio properties for bci subnode" · 829a7da0
      Sebastian Reichel 提交于
      This reverts commit af19161a,
      which breaks the omap3 device tree build due to a wrong reference.
      
      I accidently queued this change via the power supply subsystem while
      telling Marek at the same time, that it should go through Tony.
      Following that I did miss Stephen's messages about the build failure in
      linux-next and since he switched to merging an older snapshot nobody
      else noticed the problem in my tree. I didn't notice myself, since I
      did not build any device tree files assuming none have changed by me.
      Signed-off-by: NSebastian Reichel <sre@kernel.org>
      Reported-by: NFelipe Balbi <balbi@ti.com>
      Tested-by: NFelipe Balbi <balbi@ti.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Acked-by: NTony Lindgren <tony@atomide.com>
      829a7da0
  6. 06 11月, 2015 1 次提交
    • A
      uaccess: reimplement probe_kernel_address() using probe_kernel_read() · 0ab32b6f
      Andrew Morton 提交于
      probe_kernel_address() is basically the same as the (later added)
      probe_kernel_read().
      
      The return value on EFAULT is a bit different: probe_kernel_address()
      returns number-of-bytes-not-copied whereas probe_kernel_read() returns
      -EFAULT.  All callers have been checked, none cared.
      
      probe_kernel_read() can be overridden by the architecture whereas
      probe_kernel_address() cannot.  parisc, blackfin and um do this, to insert
      additional checking.  Hence this patch possibly fixes obscure bugs,
      although there are only two probe_kernel_address() callsites outside
      arch/.
      
      My first attempt involved removing probe_kernel_address() entirely and
      converting all callsites to use probe_kernel_read() directly, but that got
      tiresome.
      
      This patch shrinks mm/slab_common.o by 218 bytes.  For a single
      probe_kernel_address() callsite.
      
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ab32b6f
  7. 03 11月, 2015 4 次提交
  8. 02 11月, 2015 2 次提交
  9. 31 10月, 2015 2 次提交
  10. 29 10月, 2015 1 次提交
  11. 28 10月, 2015 2 次提交
  12. 27 10月, 2015 5 次提交
    • P
      ARM: DTS: am437x: Use the new DT bindings for the eDMA3 · e3faf2b8
      Peter Ujfalusi 提交于
      Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
      enable the DMA even crossbar with ti,am335x-edma-crossbar.
      With the new bindings boards can customize and tweak the DMA channel
      priority to match their needs. With the new binding the memcpy is safe
      to be used since with the old binding it was not possible for a driver
      to know which channel is allowed to be used as non HW triggered channel.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      e3faf2b8
    • P
      ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 · d871cd2e
      Peter Ujfalusi 提交于
      Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
      enable the DMA even crossbar with ti,am335x-edma-crossbar.
      With the new bindings boards can customize and tweak the DMA channel
      priority to match their needs. With the new binding the memcpy is safe
      to be used since with the old binding it was not possible for a driver
      to know which channel is allowed to be used as non HW triggered channel.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      d871cd2e
    • M
      ARM: dts: uniphier: add outer cache controller nodes · 7c62f299
      Masahiro Yamada 提交于
      Add L2 cache controller nodes for all the UniPhier SoC DTSI.
      Also, add an L3 cache controller node for PH1-Pro5 DTSI.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      7c62f299
    • M
      ARM: uniphier: rework SMP operations to use trampoline code · b1e4006a
      Masahiro Yamada 提交于
      The complexity of the boot sequence of UniPhier SoC family is
      a PITA due to the following hardware limitations:
      
      [1] No dedicated on-chip SRAM
      SoCs in general have small SRAM, on which a tiny firmware or a boot
      loader can run before SDRAM is initialized.  As UniPhier SoCs do not
      have any dedicated SRAM accessible from CPUs, the locked outer cache
      is used instead.  Due to the ARM specification, to have access to
      the outer cache, the MMU must be enabled.  This is done for all CPU
      cores by the program hard-wired in the boot ROM.  The boot ROM code
      loads a small amount of program (this is usually SPL of U-Boot) from
      a non-volatile device onto the locked outer cache, and the primary
      CPU jumps to it.  The secondary CPUs stay in the boot ROM until they
      are kicked by the primary CPU.
      
      [2] CPUs can not directly jump to SDRAM address space
      As mentioned above, the MMU is enable for all the CPUs with the page
      table hard-wired in the boot ROM.  Unfortunately, the page table only
      has minimal sets of valid sections; all the sections of SDRAM address
      space are zero-filled.  That means all the CPUs, including secondary
      ones, can not jump directly to SDRAM address space.  So, the primary
      CPU must bring up secondary CPUs to accessible address mapped onto
      the outer cache, then again kick them to SDRAM address space.
      
      Before this commit, this complex task was done with help of a boot
      loader (U-Boot); U-Boot SPL brings up the secondary CPUs to the entry
      of U-Boot SPL and they stay there until they are kicked by Linux.
      This is not nice because a boot loader must put the secondary CPUs
      into a certain state expected by the kernel.  It makes difficult to
      port another boot loader because the boot loader and the kernel must
      work in sync to wake up the secondary CPUs.
      
      This commit reworks the SMP operations so that they do not rely on
      particular boot loader implementation; the SMP operations (platsmp.c)
      put trampoline code (headsmp.S) on a locked way of the outer cache.
      The secondary CPUs jump from the boot ROM to secondary_entry via the
      trampoline code.  The boot loader no longer needs to take care of SMP.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      b1e4006a
    • M
      ARM: uniphier: add outer cache support · e7ecbc05
      Masahiro Yamada 提交于
      This commit adds support for UniPhier outer cache controller.
      All the UniPhier SoCs are equipped with the L2 cache, while the L3
      cache is currently only integrated on PH1-Pro5 SoC.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      e7ecbc05
  13. 26 10月, 2015 7 次提交
  14. 24 10月, 2015 1 次提交