1. 19 Apr, 2012 4 commits
  2. 18 Apr, 2012 3 commits
  3. 17 Apr, 2012 4 commits
    • Paul Walmsley's avatar
      ARM: OMAP1: DMTIMER: fix broken timer clock source selection · 6aaec67d
      Paul Walmsley authored
      DMTIMER source selection on OMAP1 is broken.  omap1_dm_timer_set_src()
      tries to use __raw_{read,write}l() to read from and write to physical
      addresses, but those functions take virtual addresses.
      
      sparse caught this:
      
      arch/arm/mach-omap1/timer.c:50:13: warning: incorrect type in argument 1 (different base types)
      arch/arm/mach-omap1/timer.c:50:13:    expected void const volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap1/timer.c:50:13:    got unsigned int
      arch/arm/mach-omap1/timer.c:52:9: warning: incorrect type in argument 1 (different base types)
      arch/arm/mach-omap1/timer.c:52:9:    expected void const volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap1/timer.c:52:9:    got unsigned int
      
      Fix by using omap_{read,writel}(), just like the other users of the
      MOD_CONF_CTRL_1 register in the OMAP1 codebase.  Of course, in the long term,
      removing omap_{read,write}l() is the appropriate thing to do; but
      this will take some work to do this cleanly.
      
      Looks like this was caused by 97933d6c (ARM: OMAP1: dmtimer: conversion
      to platform devices) that dangerously moved code and changed it in
      the same patch.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
      Cc: stable@vger.kernel.org
      [tony@atomide.com: updated comments to include the breaking commit]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      6aaec67d
    • Santosh Shilimkar's avatar
      ARM: OMAP: serial: Fix the ocp smart idlemode handling bug · 5ae256dc
      Santosh Shilimkar authored
      The current serial UART code, while fidling with ocp idlemode bits,
      forget about the smart idle wakeup bit even if it is supported by
      UART IP block. This will lead to missing the module wakeup on OMAP's
      where the smart idle wakeup is supported.
      
      This was the root cause of the console sluggishness issue, I have been
      observing on OMAP4 devices and also can be potential reason for some
      other UART wakeup issues.
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      Acked-by: default avatarGovindraj.R <govindraj.raja@ti.com>
      Reviewed-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      5ae256dc
    • Govindraj.R's avatar
      ARM: OMAP2+: UART: Fix incorrect population of default uart pads · bce492c0
      Govindraj.R authored
      Commit (7496ba30  ARM: OMAP2+: UART: Add default mux for all uarts)
      wrongly added muxing of default pads for all uarts. This causes
      breakage on multiple boards using uart pins for alternate functions.
      
      For example, on zoom3 random oopses can be seen with nfsroot as
      the smsc911x ethernet FIFO timings on GPMC bus are controlled
      by gpmc_wait2 and gpmc_wait3 pins. This means we can't mux these
      pads to uart4 functionality as commit 7496ba30 was doing.
      
      Not all boards tend to use all uarts and most of unused uart pins
      are muxed for other purpose. This commit breaks the modules which
      where trying to use unused uart pins on their boards.
      
      So remove the default pad muxing. Note that this is not a complete
      fix, as we now rely on bootloader set muxing for the uart wake-up
      events. Further patching is needed to enable wake-up events for
      uarts that are already muxed to uart mode.
      
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Acked-by: default avatarRuss Dill <russ.dill@gmail.com>
      Reported-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGovindraj.R <govindraj.raja@ti.com>
      [tony@atomide.com: updated comments to describe oops on zoom3]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      bce492c0
    • Grazvydas Ignotas's avatar
      ARM: OMAP: sram: fix BUG in dpll code for !PM case · 63878acf
      Grazvydas Ignotas authored
      _omap3_sram_configure_core_dpll is called when SDRC is reprogrammed,
      which is done regardless of CONFIG_PM setting, so we always need it's
      setup code too. Without this, we hit a BUG() on OMAP3 when kernel is
      built without CONFIG_PM:
      
      Reprogramming SDRC clock to 332000000 Hz
      ------------[ cut here ]------------
      kernel BUG at arch/arm/plat-omap/sram.c:342!
      Internal error: Oops - BUG: 0 [#1] ARM
      ...
      [<c001c694>] (omap3_configure_core_dpll+0x68/0x6c) from [<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x1)
      [<c001b2dc>] (omap3_core_dpll_m2_set_rate+0x138/0x1b0) from [<c001a478>] (omap2_clk_set_rate+0x14/0x2)
      [<c001a478>] (omap2_clk_set_rate+0x14/0x20) from [<c001c9dc>] (clk_set_rate+0x54/0x74)
      [<c001c9dc>] (clk_set_rate+0x54/0x74) from [<c022b9c8>] (omap_sdrc_init+0x70/0x90)
      [<c022b9c8>] (omap_sdrc_init+0x70/0x90) from [<c022f178>] (omap3pandora_init+0x11c/0x164)
      [<c022f178>] (omap3pandora_init+0x11c/0x164) from [<c022849c>] (customize_machine+0x20/0x28)
      [<c022849c>] (customize_machine+0x20/0x28) from [<c0225810>] (do_one_initcall+0xa0/0x16c)
      [<c0225810>] (do_one_initcall+0xa0/0x16c) from [<c02259e0>] (kernel_init+0x104/0x1ac)
      [<c02259e0>] (kernel_init+0x104/0x1ac) from [<c0009cec>] (kernel_thread_exit+0x0/0x8)
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      63878acf
  4. 16 Apr, 2012 5 commits
    • Linus Walleij's avatar
      ARM: ux500: update defconfig · f27962ac
      Linus Walleij authored
      Some new drivers and changed Kconfig dependencies for the v3.4
      kernel affecting the U8500 defconfig:
      
      - The SOC config options are now brought in by default
      - No need to explicitly select misc devices anymore
      - I2C is selected by default
      - We now have support for charging from the AB8500 so compile
        in this
      - The regulator framework needs to be explictly selected
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f27962ac
    • Lee Jones's avatar
      ARM: ux500: Fix unmet direct dependency · 97b3b7a0
      Lee Jones authored
      A recent change to a Kconfig configuration saw MACH_U8500
      remove TPS6105X selection. In doing so Kconfig stopped
      selecting REGULATORS, which is still required. This patch
      sees UX500_SOC_DB8500 explicitly select it instead.
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      97b3b7a0
    • Linus Torvalds's avatar
      Linux 3.4-rc3 · e816b57a
      Linus Torvalds authored
      e816b57a
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · 9a8e5d41
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Nothing too disasterous, the biggest thing being the removal of the
        regulator support for vcore in the AMBA driver; only one SoC was using
        this and it got broken during the last merge window, which then
        started causing problems for other people.  Mutual agreement was
        reached for it to be removed."
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: 7386/1: jump_label: fixup for rename to static_key
        ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
        ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU
        ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus
        ARM: 7383/1: nommu: populate vectors page from paging_init
        ARM: 7381/1: nommu: fix typo in mm/Kconfig
        ARM: 7380/1: DT: do not add a zero-sized memory property
        ARM: 7379/1: DT: fix atags_to_fdt() second call site
        ARM: 7366/3: amba: Remove AMBA level regulator support
        ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler
        ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented
      9a8e5d41
    • Linus Torvalds's avatar
      x86-32: fix up strncpy_from_user() sign error · 12e993b8
      Linus Torvalds authored
      The 'max' range needs to be unsigned, since the size of the user address
      space is bigger than 2GB.
      
      We know that 'count' is positive in 'long' (that is checked in the
      caller), so we will truncate 'max' down to something that fits in a
      signed long, but before we actually do that, that comparison needs to be
      done in unsigned.
      
      Bug introduced in commit 92ae03f2 ("x86: merge 32/64-bit versions of
      'strncpy_from_user()' and speed it up").  On x86-64 you can't trigger
      this, since the user address space is much smaller than 63 bits, and on
      x86-32 it works in practice, since you would seldom hit the strncpy
      limits anyway.
      
      I had actually tested the corner-cases, I had only tested them on
      x86-64.  Besides, I had only worried about the case of a pointer *close*
      to the end of the address space, rather than really far away from it ;)
      
      This also changes the "we hit the user-specified maximum" to return
      'res', for the trivial reason that gcc seems to generate better code
      that way.  'res' and 'count' are the same in that case, so it really
      doesn't matter which one we return.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      12e993b8
  5. 15 Apr, 2012 12 commits
  6. 14 Apr, 2012 12 commits