1. 12 4月, 2013 19 次提交
  2. 09 4月, 2013 6 次提交
  3. 02 4月, 2013 4 次提交
  4. 01 4月, 2013 3 次提交
  5. 26 3月, 2013 1 次提交
    • S
      ARM: imx: fix sync issue between imx_cpu_die and imx_cpu_kill · 2f3edfd7
      Shawn Guo 提交于
      There is a sync issue with hotplug operation.  It's possible that when
      imx_cpu_kill gets running on primary core, the imx_cpu_die execution
      on the core which is to be killed hasn't been finished yet.  The problem
      will very likely be hit when running suspend without no_console_suspend
      setting on kernel cmdline.
      
      It uses cpu jumping argument register to sync imx_cpu_die and
      imx_cpu_kill.  The register will be set in imx_cpu_die and imx_cpu_kill
      will wait for the register being cleared to actually kill the cpu.
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: <stable@vger.kernel.org>
      2f3edfd7
  6. 15 3月, 2013 1 次提交
    • S
      ARM: i.MX35: enable MAX clock · 5dc2eb7d
      Sascha Hauer 提交于
      The i.MX35 has two bits per clock gate which are decoded as follows:
            0b00 -> clock off
            0b01 -> clock is on in run mode, off in wait/doze
            0b10 -> clock is on in run/wait mode, off in doze
            0b11 -> clock is always on
      
      The reset value for the MAX clock is 0b10.
      
      The MAX clock is needed by the SoC, yet unused in the Kernel, so the
      common clock framework will disable it during late init time. It will
      only disable clocks though which it detects as being turned on. This
      detection is made depending on the lower bit of the gate. If the reset
      value has been altered by the bootloader to 0b11 the clock framework
      will detect the clock as turned on, yet unused, hence it will turn it
      off and the system locks up.
      
      This patch turns the MAX clock on unconditionally making the Kernel
      independent of the bootloader.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      5dc2eb7d
  7. 14 3月, 2013 1 次提交
  8. 11 3月, 2013 1 次提交
  9. 04 3月, 2013 1 次提交
    • N
      ARM: mach-imx: move early resume code out of the .data section · b4e61537
      Nicolas Pitre 提交于
      Building the kernel with allyesconfig fails because the i.mx early
      resume code located in the .data section is unable to fixup the bl
      relocation as the branch target gets too far away.
      
      The idea of having code in the .data section allows for easy access to
      nearby data using relative addressing while the MMU is off. However it
      is probably best to move the code back to the .text section where it
      belongs and fixup the data access instead.  This solves the bl reloc
      issue (at least until this becomes a general problem) and simplifies
      the code as well.
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      b4e61537
  10. 16 2月, 2013 1 次提交
    • A
      ARM: imx: MACH_MX31ADS_WM1133_EV1 needs REGULATOR_WM8350 · 69eb383a
      Arnd Bergmann 提交于
      MACH_MX31ADS_WM1133_EV1 already depends on REGULATOR_WM8350,
      but that still allows REGULATOR_WM8350 to be a loadable
      module. Depending on REGULATOR_WM8350 to be built-in
      ensures we cannot create a broken configuration.
      
      Without this patch, building allmodconfig results in:
      
      arch/arm/mach-imx/built-in.o: In function `mx31_wm8350_init':
      arch/arm/mach-imx/mach-mx31ads.c:461: undefined reference to `wm8350_register_regulator'
      arch/arm/mach-imx/mach-mx31ads.c:471: undefined reference to `wm8350_dcdc_set_slot'
      arch/arm/mach-imx/mach-mx31ads.c:473: undefined reference to `wm8350_isink_set_flash'
      arch/arm/mach-imx/mach-mx31ads.c:480: undefined reference to `wm8350_dcdc25_set_mode'
      arch/arm/mach-imx/mach-mx31ads.c:485: undefined reference to `wm8350_register_led'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Axel Lin <axel.lin@gmail.com>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      69eb383a
  11. 12 2月, 2013 1 次提交
  12. 10 2月, 2013 1 次提交