1. 19 9月, 2013 5 次提交
    • A
      ARM: OMAP4 SMP: Corrected a typo fucntions to functions · b6b24852
      Anoop Thomas Mathew 提交于
      Corrected the functions spelling mistake in the OMAP4 SMP source file.
      Signed-off-by: NAnoop Thomas Mathew <atm@profoundis.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b6b24852
    • V
      ARM: OMAP4: cpuidle: fix: call cpu_cluster_pm_exit conditionally · 78350271
      Vladimir Murzin 提交于
      We call cpu_cluster_pm_enter for dev->cpu == 0 only, but
      cpu_cluster_pm_exit called without that check.
      
      Because of that unhandled page fault may happen:
      
      [    3.803405] Unable to handle kernel paging request at virtual address 00002500
      [    3.810974] pgd = c0004000
      [    3.813812] [00002500] *pgd=00000000
      [    3.817596] Internal error: Oops: 5 [#1] SMP ARM
      [    3.822418] Modules linked in:
      [    3.825653] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc6+ #21
      [    3.832397] task: ed86ef40 ti: ed896000 task.ti: ed896000
      [    3.838073] PC is at irq_notifier+0x234/0x25c
      [    3.842651] LR is at irq_notifier+0x218/0x25c
      [    3.847229] pc : [<c0029ed8>]    lr : [<c0029ebc>]    psr: 80000193
      [    3.847229] sp : ed897ee8  ip : 00000005  fp : 00000001
      [    3.859283] r10: c0b395f0  r9 : c0b30594  r8 : c0b8c2ac
      [    3.864776] r7 : ffffffff  r6 : 00000000  r5 : 00000005  r4 : 00000000
      [    3.871643] r3 : 00002500  r2 : 00000000  r1 : 00000005  r0 : 44302244
      [    3.878479] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [    3.886260] Control: 10c5387d  Table: 8000404a  DAC: 00000015
      [    3.892272] Process swapper/1 (pid: 0, stack limit = 0xed896240)
      [    3.898590] Stack: (0xed897ee8 to 0xed898000)
      [    3.903167] 7ee0:                   c0979c3a 00000001 ed897ef8 ed896000 c0014f7c 00000000
      [    3.911743] 7f00: 00000005 00000000 ffffffff c0b8c2ac c0b395f0 c077c04c c0c94b48 c0b3953c
      [    3.920318] 7f20: c0bcd928 00000002 c0b39524 c00cfad8 00000000 ffffffff 00000000 c00cfb10
      [    3.928924] 7f40: c14e62c0 c002c1c8 c002c0ac c14e62c0 00000002 e251c37d 00000000 c0b39548
      [    3.937499] 7f60: c0b395f0 c05a1bc4 e251c37d 00000000 00000005 c05a3870 edc90380 edc90380
      [    3.946105] 7f80: edc90394 c14e62c0 c0b39548 00000002 c0784064 c05a3c78 c0b395e0 c14e62c0
      [    3.954681] 7fa0: 00000002 c0b39548 c0bc9db8 00000000 00000001 c05a1dc0 ed896000 00000015
      [    3.963287] 7fc0: c0bc9db8 ed896000 8000406a c0b30594 c0784064 c000e504 00000746 c007a528
      [    3.971862] 7fe0: 00000001 0000001d 600001d3 c0bcc004 00000000 800086c4 ee0aa6a7 d2aabaa9
      [    3.980499] [<c0029ed8>] (irq_notifier+0x234/0x25c) from [<c077c04c>] (notifier_call_chain+0x38/0x68)
      [    3.990173] [<c077c04c>] (notifier_call_chain+0x38/0x68) from [<c00cfad8>] (cpu_pm_notify+0x20/0x38)
      [    3.999786] [<c00cfad8>] (cpu_pm_notify+0x20/0x38) from [<c00cfb10>] (cpu_cluster_pm_exit+0x20/0x50)
      [    4.009399] [<c00cfb10>] (cpu_cluster_pm_exit+0x20/0x50) from [<c002c1c8>] (omap_enter_idle_coupled+0x11c/0x14c)
      [    4.020111] [<c002c1c8>] (omap_enter_idle_coupled+0x11c/0x14c) from [<c05a1bc4>] (cpuidle_enter_state+0x40/0xec)
      [    4.030822] [<c05a1bc4>] (cpuidle_enter_state+0x40/0xec) from [<c05a3c78>] (cpuidle_enter_state_coupled+0x1f4/0x240)
      [    4.041870] [<c05a3c78>] (cpuidle_enter_state_coupled+0x1f4/0x240) from [<c05a1dc0>] (cpuidle_idle_call+0x150/0x228)
      [    4.052947] [<c05a1dc0>] (cpuidle_idle_call+0x150/0x228) from [<c000e504>] (arch_cpu_idle+0x8/0x38)
      [    4.062499] [<c000e504>] (arch_cpu_idle+0x8/0x38) from [<c007a528>] (cpu_startup_entry+0x178/0x1e4)
      [    4.071990] [<c007a528>] (cpu_startup_entry+0x178/0x1e4) from [<800086c4>] (0x800086c4)
      [    4.080383] Code: e5922288 03a03b0a 13a03c25 e0823003 (e5932000)
      [    4.086791] ---[ end trace d83954a84a6fa69e ]---
      
      It is supposed that sar_base is initialized in irq_save_context, which
      is called on CPU_CLUSTER_PM_ENTER notification. If this notification
      has been missed and CPU_CLUSTER_PM_EXIT is received sar_base is NULL.
      
      Fix it by calling CPU_CLUSTER_PM_{ENTER,EXIT} under the same condition.
      Signed-off-by: NVladimir Murzin <murzin.v@gmail.com>
      Acked-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      78350271
    • F
      ARM: mach-omap2: gpmc: Fix warning when CONFIG_ARM_LPAE=y · f70bf2a3
      Fabio Estevam 提交于
      When CONFIG_ARM_LPAE=y the following build warning is generated:
      
      arch/arm/mach-omap2/gpmc.c:1495:4: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat]
      
      According to Documentation/printk-formats.txt '%pa' can be used to properly
      print 'resource_size_t'.
      Reported-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Acked-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f70bf2a3
    • W
      ARM: OMAP: fix return value check in omap_device_build_from_dt() · 4cf9cf89
      Wei Yongjun 提交于
      In case of error, the function omap_device_alloc() returns ERR_PTR()
      and never returns NULL. The NULL test in the return value check
      should be replaced with IS_ERR().
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Acked-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      4cf9cf89
    • T
      ARM: OMAP4: Fix clock_get error for GPMC during boot · 2cfeed31
      Tony Lindgren 提交于
      Looks like we still have the legacy clock alias name for
      omap4 GPMC (General Purpose Memory Controller), so let's
      fix it for the device tree naming. There's no need to keep
      the legacy naming as omap4 is DT only nowadays.
      
      Without this fix we get the following error while booting:
      
      [    0.440399] omap-gpmc 50000000.gpmc: error: clk_get
      Reported-by: NOlof Johansson <olof@lixom.net>
      Cc: stable@vger.kernel.org # v3.11
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2cfeed31
  2. 13 9月, 2013 8 次提交
  3. 12 9月, 2013 1 次提交
    • N
      mm: migrate: check movability of hugepage in unmap_and_move_huge_page() · 83467efb
      Naoya Horiguchi 提交于
      Currently hugepage migration works well only for pmd-based hugepages
      (mainly due to lack of testing,) so we had better not enable migration of
      other levels of hugepages until we are ready for it.
      
      Some users of hugepage migration (mbind, move_pages, and migrate_pages) do
      page table walk and check pud/pmd_huge() there, so they are safe.  But the
      other users (softoffline and memory hotremove) don't do this, so without
      this patch they can try to migrate unexpected types of hugepages.
      
      To prevent this, we introduce hugepage_migration_support() as an
      architecture dependent check of whether hugepage are implemented on a pmd
      basis or not.  And on some architecture multiple sizes of hugepages are
      available, so hugepage_migration_support() also checks hugepage size.
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83467efb
  4. 11 9月, 2013 1 次提交
  5. 10 9月, 2013 3 次提交
  6. 09 9月, 2013 3 次提交
  7. 07 9月, 2013 1 次提交
  8. 05 9月, 2013 3 次提交
    • P
      ARM: PCI: versatile: Fix SMAP register offsets · 99f2b130
      Peter Maydell 提交于
      The SMAP register offsets in the versatile PCI controller code were
      all off by four.  (This didn't have any observable bad effects
      because on this board PHYS_OFFSET is zero, and (a) writing zero to
      the flags register at offset 0x10 has no effect and (b) the reset
      value of the SMAP register is zero anyway, so failing to write SMAP2
      didn't matter.)
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NKevin Hilman <khilman@linaro.org>
      99f2b130
    • P
      ARM: PCI: versatile: Fix PCI I/O · 829f9fed
      Peter Maydell 提交于
      The versatile PCI controller code was confused between the
      PCI I/O window (at 0x43000000) and the first PCI memory
      window (at 0x44000000). Pass the correct base address to
      pci_remap_io() so that PCI I/O accesses work.
      
      Since the first PCI memory window isn't used at all (it's
      an odd size), rename the associated variables and labels
      so that it's clear that it isn't related to the I/O window.
      
      This has been tested and confirmed to fix PCI I/O accesses
      both on physical PB926+PCI backplane hardware and on QEMU.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NKevin Hilman <khilman@linaro.org>
      829f9fed
    • P
      ARM: PCI: versatile: Fix map_irq function to match hardware · f9b71fef
      Peter Maydell 提交于
      The PCI controller code for the Versatile board has never had the
      correct IRQ mapping for hardware.  For many years it had an odd
      mapping ("all interrupts are int 27") which aligned with the
      equivalent bug in QEMU.  However as of commit 1bc39ac5
      the mapping changed and no longer matched either hardware or QEMU,
      with the result that any PCI card beyond the first in QEMU would
      not have functioning interrupts; for example a boot with a SCSI
      controller would time out as follows:
      
       ------------
       sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92
       sym0: SCSI BUS has been reset.
       scsi0 : sym-2.2.3
       [...]
       scsi 0:0:0:0: ABORT operation started
       scsi 0:0:0:0: ABORT operation timed-out.
       scsi 0:0:0:0: DEVICE RESET operation started
       scsi 0:0:0:0: DEVICE RESET operation timed-out.
       scsi 0:0:0:0: BUS RESET operation started
       scsi 0:0:0:0: BUS RESET operation timed-out.
       scsi 0:0:0:0: HOST RESET operation started
       sym0: SCSI BUS has been reset
       ------------
      
      Fix the mapping so that it matches real hardware (checked against the
      schematics for PB926 and backplane, and tested against the hardware).
      This allows PCI cards using interrupts to work on hardware for the
      first time; this change will also work with QEMU 1.5 or later, where
      the equivalent bugs in the modelling of the hardware have been fixed.
      
      Although QEMU will attempt to autodetect whether the kernel is
      expecting the long-standing "everything is int 27" mapping or the one
      hardware has, for certainty we force it into "definitely behave like
      hardware mode"; this will avoid unexpected surprises later if we
      implement sparse irqs. This is harmless on hardware.
      
      Thanks to Paul Gortmaker for bisecting the problem and finding an initial
      solution, to Russell King for providing the correct interrupt mapping,
      and to Guenter Roeck for providing an initial version of this patch
      and prodding me into relocating the hardware and retesting everything.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NKevin Hilman <khilman@linaro.org>
      f9b71fef
  9. 04 9月, 2013 1 次提交
  10. 03 9月, 2013 3 次提交
  11. 02 9月, 2013 7 次提交
  12. 31 8月, 2013 4 次提交