1. 18 9月, 2012 1 次提交
    • A
      ARM: shmobile: use __iomem pointers for MMIO · 0a4b04dc
      Arnd Bergmann 提交于
      ARM is moving to stricter checks on readl/write functions,
      so we need to use the correct types everywhere.
      
      This patch is a bit ugly for shmobile, which is the only platform
      that just uses integer literals all over the place, but I can't
      see a better way to do this.
      Acked-by: NSimon Horman <horms@verge.net.au>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      0a4b04dc
  2. 23 8月, 2012 8 次提交
    • A
      ARM: ux500: don't select LEDS_GPIO for snowball · db43b184
      Arnd Bergmann 提交于
      Using 'select' in Kconfig is hard, a platform cannot just
      enable a driver without also making sure that its subsystem
      is there. Also, there is no actual code dependency between
      the platform and the gpio leds driver.
      
      Without this patch, building without LEDS_CLASS esults in:
      
      drivers/built-in.o: In function `create_gpio_led.part.2':
      governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
      drivers/built-in.o: In function `gpio_led_remove':
      governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
      
      This reverts 8733f53c "ARM: ux500: Kconfig: Compile in leds-gpio
      support for Snowball" that introduced the regression and did not
      provide a helpful explanation.
      
      In order to leave the GPIO LED code still present in normal
      builds, this also enables the symbol in u8500_defconfig, in addition
      to the other LED drivers that are already selected there.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Lee Jones <lee.jones@linaro.org>
      db43b184
    • A
      ARM: imx: build i.MX6 functions only when needed · 1fc593fe
      Arnd Bergmann 提交于
      The head-v7.S contains a call to the generic cpu_suspend function,
      which is only available when selected by the i.MX6 code. As
      pointed out by Shawn Guo, i.MX5 does not actually use any
      functions defined in head-v7.S. It is also needed only for
      the i.MX6 power management code and for the SMP code, so
      we can restrict building this file to situations in which
      at least one of those two is present.
      
      Finally, other platforms with a similar file call it headsmp.S,
      so we can rename it to the same for consistency.
      
      Without this patch, building imx5 standalone results in:
      
      arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
      arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: Eric Miao <eric.miao@linaro.org>
      Cc: stable@vger.kernel.org
      1fc593fe
    • A
      ARM: imx: select CPU_FREQ_TABLE when needed · f637c4c9
      Arnd Bergmann 提交于
      The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
      so it needs to select that code to be built. This problem has
      apparently existed since the i.MX cpufreq code was first merged
      in v2.6.37.
      
      Building IMX without CPU_FREQ_TABLE results in:
      
      arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
      arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
      arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
      arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
      arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
      arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
      arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
      arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
      arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Yong Shen <yong.shen@linaro.org>
      Cc: stable@vger.kernel.org
      f637c4c9
    • A
      ARM: imx: fix ksz9021rn_phy_fixup · 9f9ba0fd
      Arnd Bergmann 提交于
      The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
      set up an ethernet phy if they can. They do check whether
      phylib is enabled, but unfortunately the functions can only
      be called from platform code if phylib is builtin, not
      if it is a module
      
      Without this patch, building with a modular phylib results in:
      
      arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
      arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
      arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in
      
      The bug was originally reported by Artem Bityutskiy but only
      partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
      CONFIG_PHYLIB is enabled".
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      9f9ba0fd
    • A
      ARM: imx: build pm-imx5 code only when PM is enabled · a28eecef
      Arnd Bergmann 提交于
      This moves the imx5 pm code out of the list of unconditionally
      compiled files for imx5, mirroring what we already do for imx6
      and how it was done before the code was move from mach-mx5 to
      mach-imx in v3.3.
      
      Without this patch, building with CONFIG_PM disabled results in:
      
      arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
      arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
      arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
      arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: stable@vger.kernel.org
      a28eecef
    • A
      ARM: omap: allow building omap44xx without SMP · c7a9b09b
      Arnd Bergmann 提交于
      The new omap4 cpuidle implementation currently requires
      ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
      
      This patch makes it possible to build a non-SMP kernel
      for that platform. This is not normally desired for
      end-users but can be useful for testing.
      
      Without this patch, building rand-0y2jSKT results in:
      
      drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
      drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
      
      It's not clear if this patch is the best solution for
      the problem at hand. I have made sure that we can now
      build the kernel in all configurations, but that does
      not mean it will actually work on an OMAP44xx.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      c7a9b09b
    • S
      ARM: dts: imx51-babbage: fix esdhc cd/wp properties · a46d2619
      Shawn Guo 提交于
      The binding doc and dts use properties "fsl,{cd,wp}-internal" while
      esdhc driver uses "fsl,{cd,wp}-controller".  Fix binding doc and dts
      to get them match driver code.
      Reported-by: NChris Ball <cjb@laptop.org>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: <stable@vger.kernel.org>
      Acked-by: NChris Ball <cjb@laptop.org>
      a46d2619
    • S
      ARM: imx6: spin the cpu until hardware takes it down · c944b0b9
      Shawn Guo 提交于
      Though commit 602bf409 (ARM: imx6: exit coherency when shutting down
      a cpu) improves the stability of imx6q cpu hotplug a lot, there are
      still hangs seen with a more stressful hotplug testing.
      
      It's expected that once imx_enable_cpu(cpu, false) is called, the cpu
      will be taken down by hardware immediately, and the code after that
      will not get any chance to execute.  However, this is not always the
      case from the testing.  The cpu could possibly be alive for a few
      cycles before hardware actually takes it down.  So rather than letting
      cpu execute some code that could cause a hang in these cycles, let's
      make the cpu spin there and wait for hardware to take it down.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      c944b0b9
  3. 17 8月, 2012 3 次提交
  4. 15 8月, 2012 4 次提交
  5. 14 8月, 2012 1 次提交
    • A
      ARM: mv78xx0: fix win_cfg_base prototype · e18287d3
      Arnd Bergmann 提交于
      Patch b6d1c33a "ARM: Orion: Consolidate the address map setup" tried
      to merge the address map for the four orion platforms, but apparently
      got it wrong for mv78xx0. Admittedly I don't understand what this
      code actually does, but it's clear that the current version is
      wrong.
      
      Without this patch, building mv78xx0_defconfig results in:
      
      arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from incompatible pointer type [enabled by default]
      arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NAndrew Lunn <andrew@lunn.ch>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Nicolas Pitre <nico@linaro.org>
      e18287d3
  6. 13 8月, 2012 2 次提交
  7. 11 8月, 2012 7 次提交
  8. 10 8月, 2012 4 次提交
    • Y
      ARM: mmp: fix potential NULL dereference · c0db19da
      Yuanhan Liu 提交于
      Fix the wrong logic: we should use || instead of &&
      
      Cc: Leo Yan <leoy@marvell.com>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Signed-off-by: NYuanhan Liu <yliu.null@gmail.com>
      Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      c0db19da
    • A
      ARM: davinci: remove broken ntosd2_init_i2c · de923430
      Arnd Bergmann 提交于
      ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
      be populated with at least one member. gcc correctly warns about
      the out-of-bounds access here.
      
      Since this can not possibly work, it's better to disable i2c
      support entirely on this board.
      
      Without this patch, building davinci_all_defconfig results in:
      
      arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
      arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSekhar Nori <nsekhar@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Andrey Porodko <panda@chelcom.ru>
      de923430
    • A
      ARM: s3c24xx: enable CONFIG_BUG for tct_hammer · 15b5eb2d
      Arnd Bergmann 提交于
      Disabling CONFIG_BUG creates an insane amount of build warnings, which
      makes it useless to check for building defconfigs to see if new
      warnings show up.
      
      Without this patch, building tct_hammer_defconfig results in:
      
      net/packet/af_packet.c: In function 'tpacket_rcv':
      net/packet/af_packet.c:1889:30: warning: 'hdrlen' may be used uninitialized in this function [-Wuninitialized]
      net/core/ethtool.c: In function 'ethtool_get_feature_mask':
      net/core/ethtool.c:213:1: warning: control reaches end of non-void function [-Wreturn-type]
      block/cfq-iosched.c: In function 'cfq_async_queue_prio':
      block/cfq-iosched.c:2914:1: warning: control reaches end of non-void function [-Wreturn-type]
      mm/bootmem.c: In function 'mark_bootmem':
      mm/bootmem.c:352:1: warning: control reaches end of non-void function [-Wreturn-type]
      net/core/dev.c: In function 'skb_warn_bad_offload':
      net/core/dev.c:1904:33: warning: unused variable 'null_features' [-Wunused-variable]
      drivers/mtd/chips/cfi_probe.c: In function 'cfi_chip_setup':
      include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
      include/linux/mtd/map.h:394:11: note: 'r.x[0]' was declared here
      include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
      (and many more)
      
      The size of vmlinux increases by 1.78% because of this:
      
      size obj-arm/vmlinux.nobug
         text    data     bss     dec     hex filename
         2108474  116916   55352 2280742  22cd26 obj-arm/vmlinux
      size obj-arm/vmlinux.bug
         text    data     bss     dec     hex filename
         2150804  116916   53696 2321416  236c08 obj-arm/vmlinux
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NKukjin Kim <kgene.kim@samsung.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      15b5eb2d
    • A
      ARM: exynos: exynos_pm_add_dev_to_genpd may be unused · 8ab08c0c
      Arnd Bergmann 提交于
      exynos_pm_add_dev_to_genpd is used if one or more out of a large
      number of Kconfig symbols are enabled. However the new
      exynos_defconfig selects none of those, so the function becomes
      unused. Marking it so lets the compiler automatically discard
      it.
      
      Without this patch, building exynos_defconfig results in:
      
      arch/arm/mach-exynos/pm_domains.c:118:123: warning: 'exynos_pm_add_dev_to_genpd' defined but not used [-Wunused-function]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NThomas Abraham <thomas.abraham@linaro.org>
      Acked-by: NKukjin Kim <kgene.kim@samsung.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      8ab08c0c
  9. 09 8月, 2012 10 次提交
    • R
      ARM: OMAP4: Register the OPP table only for 4430 device · 196449de
      Rajendra Nayak 提交于
      The 4430 OPP table was being registered for all other OMAP4 variants
      too, like 4460 and 4470 causing issues with cpufreq driver
      enabled. 4460 and 4470 devices have different OPPs as compared to
      4430, and they should be populated seperately. As long as that
      happens, let the OPP table registeration happen only on 4430 device.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      196449de
    • S
      ARM: OMAP4: sleep: Save the complete used register stack frame · 5b6e3eb5
      Santosh Shilimkar 提交于
      OMAP4 sleep entry code even though itself don't use many CPU registers
      makes call to the v7_flush_dcache_all() which uses them. Since
      v7_flush_dcache_all() doesn't make use of stack, the caller must take
      care of the stack frame. Otherwise it will lead to corrupted stack frame.
      
      Fix it by saving used registers.
      Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      5b6e3eb5
    • A
      ARM: imx: gpmi-nand depends on mxs-dma · a3349377
      Arnd Bergmann 提交于
      It is not currently possible to build the gpmi-nand driver without
      also building the mxs-dma driver. Clarify this Kconfig and enable
      both in the defconfig file so we can build it again with both enabled.
      
      drivers/built-in.o: In function `gpmi_dma_filter':
      clk-fixed-factor.c:(.text+0xafc18): undefined reference to `mxs_dma_is_apbh'
      make[1]: *** [vmlinux] Error 1
      make: *** [sub-make] Error 2
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NDirk Behme <dirk.behme@de.bosch.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      a3349377
    • A
      ARM: integrator: include <linux/export.h> · b434f5c9
      Arnd Bergmann 提交于
      Without this patch, building integrator_defconfig results in:
      
      arch/arm/mach-integrator/core.c:150:1: warning: data definition has no type or storage class [enabled by default]
      arch/arm/mach-integrator/core.c:150:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
      arch/arm/mach-integrator/core.c:150:1: warning: parameter names (without types) in function declaration [enabled by default]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      b434f5c9
    • A
      ARM: s3c24xx: use new PWM driver · 35e79061
      Arnd Bergmann 提交于
      The samsung PWM driver has moved to the new PWM subsystem, which
      changed the Kconfig symbol for that driver, but the rx1950 and
      gta02 boards still uses the old one.
      
      Without this patch, building s3c2410_defconfig results in:
      
      arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_lcd_power':
      arch/arm/mach-s3c24xx/mach-rx1950.c:430: undefined reference to `pwm_config'
      arch/arm/mach-s3c24xx/mach-rx1950.c:431: undefined reference to `pwm_disable'
      arch/arm/mach-s3c24xx/mach-rx1950.c:437: undefined reference to `pwm_config'
      arch/arm/mach-s3c24xx/mach-rx1950.c:438: undefined reference to `pwm_enable'
      arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_backlight_exit':
      arch/arm/mach-s3c24xx/mach-rx1950.c:504: undefined reference to `pwm_free'
      arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_backlight_init':
      arch/arm/mach-s3c24xx/mach-rx1950.c:487: undefined reference to `pwm_request'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reported-by: NTushar Behera <tushar.behera@linaro.org>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      35e79061
    • A
      ARM: sa1100: include linux/io.h in hackkit leds code · 9c97738c
      Arnd Bergmann 提交于
      The sa1100 definition of the io_p2v macro has changed in v3.6, and this one
      file stopped working because of that.
      
      Without this patch, building hackkit_defconfig results in:
      
      arch/arm/mach-sa1100/leds-hackkit.c: In function 'hackkit_leds_event':
      arch/arm/mach-sa1100/leds-hackkit.c:39:4: error: implicit declaration of function 'IOMEM' [-Werror=implicit-function-declaration]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      9c97738c
    • A
      Input: eeti_ts: pass gpio value instead of IRQ · 4eef6cbf
      Arnd Bergmann 提交于
      The EETI touchscreen asserts its IRQ line as soon as it has data in its
      internal buffers. The line is automatically deasserted once all data has
      been read via I2C. Hence, the driver has to monitor the GPIO line and
      cannot simply rely on the interrupt handler reception.
      
      In the current implementation of the driver, irq_to_gpio() is used to
      determine the GPIO number from the i2c_client's IRQ value.
      
      As irq_to_gpio() is not available on all platforms, this patch changes
      this and makes the driver ignore the passed in IRQ. Instead, a GPIO is
      added to the platform_data struct and gpio_to_irq is used to derive the
      IRQ from that GPIO. If this fails, bail out. The driver is only able to
      work in environments where the touchscreen GPIO can be mapped to an
      IRQ.
      
      Without this patch, building raumfeld_defconfig results in:
      
      drivers/input/touchscreen/eeti_ts.c: In function 'eeti_ts_irq_active':
      drivers/input/touchscreen/eeti_ts.c:65:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: stable@vger.kernel.org (v3.2+)
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Sven Neumann <s.neumann@raumfeld.com>
      Cc: linux-input@vger.kernel.org
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      4eef6cbf
    • S
      ARM: tegra: more regulator fixes for Harmony · 798bd59c
      Stephen Warren 提交于
      Commit 3d55c29f "ARM: tegra: harmony: add regulator supply name and its
      input supply" was supposed to fix all the problems with regulators on
      Harmony. However, it appears that I only tested it when booting using
      board files, not when booting using device tree. This change fixes two
      problems with regulators when booting using device tree:
      
      1) That patch only created the vdd_sys regulator when booting using a
         board file. Since this is the root of the whole regulator tree, this
         caused no regulators to successfully initialize when booting using
         device tree. The registration of vdd_sys is moved to fix this.
      
      2) When booting use DT, the regulator core sets has_full_constraints,
         which in turn causes the core to turn off any regulators not marked
         as always on. Some of the affected regulators are required for basic
         system operation. To solve this, add always on constraints to all
         relevant regulators. This doesn't affect booting using a board file
         since nothing sets has_full_constraints in that case.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      798bd59c
    • A
      ARM: dma-mapping: fix incorrect freeing of atomic allocations · d9e0d149
      Aaro Koskinen 提交于
      Commit e9da6e99 (ARM: dma-mapping:
      remove custom consistent dma region) changed the way atomic allocations
      are handled. However, arm_dma_free() was not modified accordingly, and
      as a result freeing of atomic allocations does not work correctly when
      CMA is disabled. Memory is leaked and following WARNINGs are seen:
      
      [   57.698911] ------------[ cut here ]------------
      [   57.753518] WARNING: at arch/arm/mm/dma-mapping.c:263 arm_dma_free+0x88/0xe4()
      [   57.811473] trying to free invalid coherent area: e0848000
      [   57.867398] Modules linked in: sata_mv(-)
      [   57.921373] [<c000d270>] (unwind_backtrace+0x0/0xf0) from [<c0015430>] (warn_slowpath_common+0x50/0x68)
      [   58.033924] [<c0015430>] (warn_slowpath_common+0x50/0x68) from [<c00154dc>] (warn_slowpath_fmt+0x30/0x40)
      [   58.152024] [<c00154dc>] (warn_slowpath_fmt+0x30/0x40) from [<c000dc18>] (arm_dma_free+0x88/0xe4)
      [   58.219592] [<c000dc18>] (arm_dma_free+0x88/0xe4) from [<c008fa30>] (dma_pool_destroy+0x100/0x148)
      [   58.345526] [<c008fa30>] (dma_pool_destroy+0x100/0x148) from [<c019a64c>] (release_nodes+0x144/0x218)
      [   58.475782] [<c019a64c>] (release_nodes+0x144/0x218) from [<c0197e10>] (__device_release_driver+0x60/0xb8)
      [   58.614260] [<c0197e10>] (__device_release_driver+0x60/0xb8) from [<c0198608>] (driver_detach+0xd8/0xec)
      [   58.756527] [<c0198608>] (driver_detach+0xd8/0xec) from [<c0197c54>] (bus_remove_driver+0x7c/0xc4)
      [   58.901648] [<c0197c54>] (bus_remove_driver+0x7c/0xc4) from [<c004bfac>] (sys_delete_module+0x19c/0x220)
      [   59.051447] [<c004bfac>] (sys_delete_module+0x19c/0x220) from [<c0009140>] (ret_fast_syscall+0x0/0x2c)
      [   59.207996] ---[ end trace 0745420412c0325a ]---
      [   59.287110] ------------[ cut here ]------------
      [   59.366324] WARNING: at arch/arm/mm/dma-mapping.c:263 arm_dma_free+0x88/0xe4()
      [   59.450511] trying to free invalid coherent area: e0847000
      [   59.534357] Modules linked in: sata_mv(-)
      [   59.616785] [<c000d270>] (unwind_backtrace+0x0/0xf0) from [<c0015430>] (warn_slowpath_common+0x50/0x68)
      [   59.790030] [<c0015430>] (warn_slowpath_common+0x50/0x68) from [<c00154dc>] (warn_slowpath_fmt+0x30/0x40)
      [   59.972322] [<c00154dc>] (warn_slowpath_fmt+0x30/0x40) from [<c000dc18>] (arm_dma_free+0x88/0xe4)
      [   60.070701] [<c000dc18>] (arm_dma_free+0x88/0xe4) from [<c008fa30>] (dma_pool_destroy+0x100/0x148)
      [   60.256817] [<c008fa30>] (dma_pool_destroy+0x100/0x148) from [<c019a64c>] (release_nodes+0x144/0x218)
      [   60.445201] [<c019a64c>] (release_nodes+0x144/0x218) from [<c0197e10>] (__device_release_driver+0x60/0xb8)
      [   60.634148] [<c0197e10>] (__device_release_driver+0x60/0xb8) from [<c0198608>] (driver_detach+0xd8/0xec)
      [   60.823623] [<c0198608>] (driver_detach+0xd8/0xec) from [<c0197c54>] (bus_remove_driver+0x7c/0xc4)
      [   61.013268] [<c0197c54>] (bus_remove_driver+0x7c/0xc4) from [<c004bfac>] (sys_delete_module+0x19c/0x220)
      [   61.203472] [<c004bfac>] (sys_delete_module+0x19c/0x220) from [<c0009140>] (ret_fast_syscall+0x0/0x2c)
      [   61.393390] ---[ end trace 0745420412c0325b ]---
      
      The patch fixes this.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      d9e0d149
    • A
      ARM: dma-mapping: fix atomic allocation alignment · e4ea6918
      Aaro Koskinen 提交于
      The alignment mask is calculated incorrectly. Fixing the calculation
      makes strange hangs/lockups disappear during the boot with Amstrad E3
      and 3.6-rc1 kernel.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      e4ea6918