Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 5月, 2012 1 次提交
  3. 04 4月, 2012 1 次提交
  5. 28 3月, 2012 1 次提交
  7. 08 3月, 2012 1 次提交
    • T
      ARM: OMAP2+: Fix section warnings for hsmmc_init_one · 6028505c
      由 Tony Lindgren 提交于 
      Otherwise we can get the following error depending on
the compiler:

WARNING: arch/arm/mach-omap2/built-in.o(.text+0xafe0):
Section mismatch in reference from the function omap_hsmmc_init_one()
to the function .init.text:omap_hsmmc_pdata_init()
The function omap_hsmmc_init_one() references
the function __init omap_hsmmc_pdata_init().
This is often because omap_hsmmc_init_one lacks a __init
annotation or the annotation of omap_hsmmc_pdata_init is wrong.
Signed-off-by: NTony Lindgren <tony@atomide.com>
      6028505c
  9. 25 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init · d1589f09
      由 Tony Lindgren 提交于 
      Now that omap hsmmc init is split into two functions, it's safe
to mark omap_hsmmc_init and omap_mux related functions to __init.

This basically reverts the following fixes for the case where
TWL was compiled as a module:

a98f77bb (ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup())
8930b4e3 (ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c)

Additionally it fixes up the remaining section warnings for
all callers of omap_mux functions.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      d1589f09
  11. 21 2月, 2012 2 次提交
    • T
      ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins · 3b972bf0
      由 Tony Lindgren 提交于 
      Otherwise omap_device_build() and omap_mux related functions
can't be marked as __init when twl is build as a module.

If a board is using GPIO pins or regulators configured by an
external chip, such as TWL PMIC on I2C bus, the board must
mark those MMC controllers as deferred. Additionally both
omap_hsmmc_init() and omap_hsmmc_late_init() must be called
by the board.

For MMC controllers using internal GPIO pins for card
detect and regulators the slots don't need to be marked
deferred. In this case calling omap_hsmmc_init() is sufficient.

Only mark the MMC slots using gpio_cd or gpio_wd as deferred
as noted by Igor Grinberg <grinberg@compulab.co.il>.

Note that this patch does not change the behaviour for
board-4430sdp.c board-omap4panda.c. These boards wrongly
rely on the omap_hsmmc.c init function callback to configure
the PMIC GPIO interrupt lines on external chip. If the PMIC
interrupt lines are not configured during init, they will
fail.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      3b972bf0
    • T
      ARM: OMAP: Fix kernel panic with HSMMC when twl4030_gpio is a module · 97899e55
      由 Tony Lindgren 提交于 
      On some omaps twl4030_gpio has a callback to try to initialize
the MMC controller. If twl4030_gpio is compiled as a module,
bad things can happen because the callback function starts
calling functions that are supposed to be marked __init:

Kernel panic - not syncing: Attempted to kill the idle task!
twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules
gpiochip_add: registered GPIOs 192 to 209 on device: twl4030
Unable to handle kernel paging request at virtual address b82a4c74
...

Additionally if this does not fail, warnings are produced
about trying to register the MMC multiple times.

Fix this by removing __init from omap_mux_get_by_name,
and add checks if omap2_hsmmc_init() is getting called more
than once.

Note that this will get fixed properly later on by splitting
omap2_hsmmc_init into two functions.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      97899e55
  13. 13 2月, 2012 1 次提交
    • R
      ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup() · a98f77bb
      由 Russell King 提交于 
      WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.

sdp3430_twl_gpio_setup() is called via platform data from the
gpio-twl4030 module, which can be inserted and removed at runtime.
This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
it being marked with an __init annotation.

As it calls omap2_hsmmc_init() unconditionally, the only resolution to
this warning is to remove the __init markings from omap2_hsmmc_init()
and its called functions.  This addresses the functions in hsmmc.c.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a98f77bb
  15. 27 1月, 2012 2 次提交
  17. 10 12月, 2011 3 次提交
  19. 09 12月, 2011 1 次提交
  21. 05 11月, 2011 2 次提交
  23. 05 10月, 2011 1 次提交
  25. 01 10月, 2011 1 次提交
  27. 16 9月, 2011 1 次提交
    • K
      OMAP: omap_device: when building return platform_device instead of omap_device · 3528c58e
      由 Kevin Hilman 提交于 
      All of the device init and device driver interaction with omap_device
is done using platform_device pointers.  To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.

All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.

This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
      3528c58e
  29. 04 7月, 2011 1 次提交
  31. 01 6月, 2011 2 次提交
  33. 31 3月, 2011 1 次提交
  35. 02 3月, 2011 3 次提交
  37. 23 2月, 2011 1 次提交
  39. 09 10月, 2010 1 次提交
    • P
      OMAP: control: move plat-omap/control.h to mach-omap2/control.h · 4814ced5
      由 Paul Walmsley 提交于 
      Only OMAP2+ platforms have the System Control Module (SCM) IP block.
In the past, we've kept the SCM header file in plat-omap.  This has
led to abuse - device drivers including it; includes being added that
create implicit dependencies on OMAP2+ builds; etc.

In response, move the SCM headers into mach-omap2/.

As part of this, remove the direct SCM access from the OMAP UDC
driver.  It was clearly broken.  The UDC code needs an indepth review for
use on OMAP2+ chips.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Cory Maccarrone <darkstar6262@gmail.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
      4814ced5
  41. 02 10月, 2010 2 次提交
  43. 28 9月, 2010 2 次提交
  45. 11 8月, 2010 1 次提交
  47. 21 5月, 2010 2 次提交
  49. 16 2月, 2010 5 次提交