1. 18 5月, 2010 3 次提交
    • J
      S5P6442: DMA: Add platform devices for PL330 DMACs · d460f5b0
      Jassi Brar 提交于
      Samsung's Soc S5P6442 has two PL330 DMACs. First is dedicated for
      Memory->Memory data transfer while the second is meant for data
      transfer with peripherals.
      Define and add the peripheral PL330 DMAC as platform device on the
      S5P6442 platform.
      Signed-off-by: NJassi Brar <jassi.brar@samsung.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      d460f5b0
    • J
      S5P6440: DMA: Add platform devices for PL330 DMACs · d8b5065b
      Jassi Brar 提交于
      Samsung's Soc S5P6440 has one PL330 DMAC.
      Define and add the PL330 DMAC as platform device on the
      S5P6440 platform.
      Signed-off-by: NJassi Brar <jassi.brar@samsung.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      d8b5065b
    • J
      S3C: DMA: Add api driver for PL330 · d800edeb
      Jassi Brar 提交于
      Latest Samsung SoCs have one or more PL330 as their DMACs. This patch
      implements the S3C DMA API for PL330 core driver.
      
      The design has been kept as generic as possible while keeping effort to
      add support for new SoCs to the minimum possible level.
      
      Some of the salient features of this driver are:-
       o  Automatic scheduling of client requests onto DMAC if more than
          one DMAC can reach the peripheral. Factors, such as current load
          and number of exclusive but inactive peripherals that are
          supported by the DMAC, are used to decide suitability of a DMAC
          for a particular client.
       o  CIRCULAR buffer option is supported.
       o  The driver scales transparently with the number of DMACs and total
          peripherals in the platform, since all peripherals are added to
          the peripheral pool and DMACs to the controller pool.
      
      For most conservative use of memory, smallest driver size and best
      performance, we don't employ legacy data structures of the S3C DMA API.
      That should not have any affect since those data structures are completely
      invisible to the DMA clients.
      Signed-off-by: NJassi Brar <jassi.brar@samsung.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      d800edeb
  2. 05 5月, 2010 1 次提交
  3. 03 5月, 2010 2 次提交
  4. 01 5月, 2010 25 次提交
  5. 30 4月, 2010 2 次提交
    • L
      x86: Fix 'reservetop=' functionality · e67a807f
      Liang Li 提交于
      When specifying the 'reservetop=0xbadc0de' kernel parameter,
      the kernel will stop booting due to a early_ioremap bug that
      relates to commit 8827247f.
      
      The root cause of boot failure problem is the value of
      'slot_virt[i]' was initialized in setup_arch->early_ioremap_init().
      But later in setup_arch, the function 'parse_early_param' will
      modify 'FIXADDR_TOP' when 'reservetop=0xbadc0de' being specified.
      
      The simplest fix might be use __fix_to_virt(idx0) to get updated
      value of 'FIXADDR_TOP' in '__early_ioremap' instead of reference
      old value from slot_virt[slot] directly.
      
      Changelog since v0:
      
      -v1: When reservetop being handled then FIXADDR_TOP get
           adjusted, Hence check prev_map then re-initialize slot_virt and
           PMD based on new FIXADDR_TOP.
      
      -v2: place fixup_early_ioremap hence call early_ioremap_init in
           reserve_top_address  to re-initialize slot_virt and
           corresponding PMD when parse_reservertop
      
      -v3: move fixup_early_ioremap out of reserve_top_address to make
           sure other clients of reserve_top_address like xen/lguest won't
           broken
      Signed-off-by: NLiang Li <liang.li@windriver.com>
      Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Wang Chen <wangchen@cn.fujitsu.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <1272621711-8683-1-git-send-email-liang.li@windriver.com>
      [ fixed three small cleanliness details in fixup_early_ioremap() ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e67a807f
    • W
      kgdb: don't needlessly skip PAGE_USER test for Fsl booke · 56151e75
      Wufei 提交于
      The bypassing of this test is a leftover from 2.4 vintage
      kernels, and is no longer appropriate, or even used by KGDB.
      Currently KGDB uses probe_kernel_write() for all access to
      memory via the KGDB core, so it can simply be deleted.
      
      This fixes CVE-2010-1446.
      
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: Paul Mackerras <paulus@samba.org>
      CC: Kumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NWufei <fei.wu@windriver.com>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      56151e75
  6. 29 4月, 2010 2 次提交
  7. 28 4月, 2010 4 次提交
  8. 27 4月, 2010 1 次提交
    • K
      powerpc/fsl-booke: Fix CONFIG_RELOCATABLE support on FSL Book-E ppc32 · dbc9632a
      Kumar Gala 提交于
      The following commit broke CONFIG_RELOCATABLE support on FSL Book-E
      parts:
      
      commit 549e8152
      Author: Paul Mackerras <paulus@samba.org>
      Date:   Sat Aug 30 11:43:47 2008 +1000
      
          powerpc: Make the 64-bit kernel as a position-independent executable
      
      The change to __va and __pa to use PAGE_OFFSET & MEMORY_START causes
      problems on the Book-E parts because we don't know MEMORY_START until
      after we parse the device tree.  We need __va to work properly to even
      parse the device tree so we have a chicken an egg.  So go back to using
      he other definition of __va/__pa on CONFIG_BOOKE and use the
      PAGE_OFFSET/MEMORY_START version on "Classic" PPC64.
      
      Also updated casts to handle phys_addr_t being a different size from
      unsigned long (ie 36-bit physical on PPC32).
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      dbc9632a