- 06 3月, 2012 13 次提交
-
-
由 Jean Pihet 提交于
Fix the code to correctly use IS_ERR and PTR_ERR on the return values pointers Reported-by: NSergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Jean Pihet 提交于
The debugfs_create_* API returns a return code or NULL in the return ptr in case of problem. Fix the smartreflex code to take this into account. Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Felipe Balbi 提交于
val && (val != 1) == val > 1 Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Felipe Balbi 提交于
There are no functional changes here, only misc cleanups in general: - re-organize variable declarations, - converting if {} else if {} else {} into switch statements, - correct comments typos, - add/remove white lines to improve readability, - etc. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com> -
由 Felipe Balbi 提交于
no functional changes, trivial patch. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Felipe Balbi 提交于
That's very useful to fetch the correct struct sr_info from the PM handlers. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Nishanth Menon 提交于
Add OMAP3 SmartReflex IRQs in hwmod structures. Without these IRQs being registered the SmartReflex driver will be unable to get the IRQ numbers to handle notifications. Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Nishanth Menon 提交于
The VPBOUNDINTST field of the ERRCONFIG register has an additional functional meaning of force clearing the SR internal signal with VP (sr_interruptz). This can result in scenarios where the VP->SR protocol is violated because the SR internal signal with VP is already high and VP will never clear the vpirqclr signal. Therefore during the next force update to reset to nominal voltage, VP cannot pulse vpirqclr, so the PRCM HW cannot generate the tranxdone IRQ and the situation is not recoverable until a cold reset is invoked. To prevent this situation, check if status is set before clearing it as this needs to be done only on a need basis. Reported-by: NVincent Bour <v-bour@ti.com> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Nishanth Menon 提交于
ERRCONFIG register has status bits that were intended not to be destroyed by bad modification. We cleanup and simplify the handling the status in the modify path. Reported-by: NVincent Bour <v-bour@ti.com> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Nishanth Menon 提交于
SmartReflex fix for erratum ID i724. Since OMAP's VP and PRM modules do not get reset by warm reset, we should ensure that proper shutdown procedure is followed prior to allowing the kernel to reboot back up. Without this, Smartreflex module might be left active or system might be caught in an indeterminate sequence when software controlled reboot is triggered, leaving the next reboot behavior to be unpredictable. In the case of hardware controlled warm reset such as that by watchdog timer, prevention of this scenario is not possible. Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Nishanth Menon 提交于
SmartReflex AVS Errorgen module supplies signals to Voltage Processor. It is suggested that by disabling Errorgen module before we disable VP, we might be able to ensure lesser chances of race condition to occur in the system. Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Nishanth Menon 提交于
sr_modify_mask takes mask, value as parameters, the usage currently is value, mask which is wrong, as a result vpboundint_st which was supposed to have been disabled, does not get disabled. Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Shweta Gulati 提交于
To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. The value of the field must match the voltage domain names for the binding to be effective. Tested on OMAP3630 SDP, OMAP3530 Beagleboard and OMAP4430 SDP Board. Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NShweta Gulati <shweta.gulati@ti.com> Acked by: Nishanth Menon <nm@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 27 2月, 2012 1 次提交
-
-
由 Ohad Ben-Cohen 提交于
omap3isp depends on omap's iommu and will fail to probe if initialized before it (which always happen if they are builtin). Make omap's iommu subsys_initcall as an interim solution until the probe deferral mechanism is merged. Reported-by: NJames <angweiyang@gmail.com> Debugged-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Cc: stable <stable@vger.kernel.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Hiroshi Doyu <hdoyu@nvidia.com> Cc: Joerg Roedel <Joerg.Roedel@amd.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
- 25 2月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
Otherwise we get: `omap_sr_remove' referenced in section `.data' of arch/arm/mach-omap2/built-in.o: defined in discarded section `.devexit.text' of arch/arm/mach-omap2/built-in.o Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 24 2月, 2012 7 次提交
-
-
由 Tony Lindgren 提交于
Otherwise we get: arch/arm/mach-omap2/board-zoom-display.c:64: undefined reference to `twl_i2c_read_u8' arch/arm/mach-omap2/board-zoom-display.c:65: undefined reference to `twl_i2c_read_u8' arch/arm/mach-omap2/board-zoom-display.c:84: undefined reference to `twl_i2c_write_u8' arch/arm/mach-omap2/board-zoom-display.c:86: undefined reference to `twl_i2c_write_u8' arch/arm/mach-omap2/board-zoom-display.c:91: undefined reference to `twl_i2c_write_u8' arch/arm/mach-omap2/board-zoom-display.c:92: undefined reference to `twl_i2c_write_u8' arch/arm/mach-omap2/board-zoom-display.c:72: undefined reference to `twl_i2c_write_u8' Signed-off-by: NTony Lindgren <tony@atomide.com> -
由 Tony Lindgren 提交于
Otherwise we can get: arch/arm/mach-omap2/mux.h:249:31: error: board_mux causes a section type conflict Signed-off-by: NTony Lindgren <tony@atomide.com> -
由 Tony Lindgren 提交于
If CONFIG_SOC_OMAP3430 is not set and CONFIG_HDQ_MASTER_OMAP is selected for w1 driver we get the following error: arch/arm/mach-omap2/devices.c:662:13: error: 'OMAP_HDQ_BASE' undeclared here (not in a function) Looks like OMAP_HDQ_BASE is valid for all omaps except 2420, so we can remove the ifdef and not register the device on 2420. Signed-off-by: NTony Lindgren <tony@atomide.com> -
由 Tony Lindgren 提交于
Otherwise we get: warning: (ARCH_OMAP3 && ARCH_OMAP4) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) Signed-off-by: NTony Lindgren <tony@atomide.com> -
由 Paul Walmsley 提交于
During kernel init, we reset all IP blocks on the OMAP that we can, even if there is no driver compiled for that IP block. Unlike most IP blocks, the I2C block requires some extra programming for this to work. This reset code is incorrectly omitted when the I2C driver is deselected. In this circumstance, the build breaks. Fix by compiling the I2C reset code unconditionally. Problem reported by Russell King <linux@arm.linux.org.uk>. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Russell King <linux@arm.linux.org.uk> Tested-by: NShubhrajyoti <shubhrajyoti@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Ohad Ben-Cohen 提交于
Fix this: arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe': arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first use in this function) arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is reported only once arch/arm/mach-omap2/mailbox.c:354: error: for each function it appears in.) Which happens on CONFIG_ARCH_OMAP2 && !CONFIG_SOC_OMAP2420, due to missing omap2_mboxes declaration. In addition, make sure we declare the right mailbox instances for 2430. Reported-by: NRussell King <linux@arm.linux.org.uk> Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Cc: Hiroshi Doyu <hdoyu@nvidia.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Matt Porter 提交于
This fixes smsc911x support on platforms using gpmc_smsc911x_init(). Commit c7e963f6 (net/smsc911x: Add regulator support) added the requirement that platforms provide vdd33a and vddvario supplies. Signed-off-by: NMatt Porter <mporter@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 22 2月, 2012 1 次提交
-
-
Otherwise we can get the following warning on some compilers: arch/arm/mach-omap2/board-omap3evm.c:384:11: warning: array subscript is above array bounds The omap3evm BSP enables a GPIO LED on the twl4030 chip. However, the static gpio_leds array doesn't have an entry for it. This is most likely a copy-and-paste error, because it has been in there since the first commit of the omap3evm BSP (53c5ec31). Signed-off-by: NArnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [tony@atomide.com: updated comments with the warning] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 21 2月, 2012 3 次提交
-
-
由 Russell King 提交于
The voltage domain code wants the voltage tables, which are in the opp*.c files. These files aren't built when PM_OPP is disabled, causing the following build errors at link time: twl-common.c:(.init.text+0x2e48): undefined reference to `omap34xx_vddmpu_volt_data' twl-common.c:(.init.text+0x2e4c): undefined reference to `omap34xx_vddcore_volt_data' twl-common.c:(.init.text+0x2e5c): undefined reference to `omap36xx_vddmpu_volt_data' twl-common.c:(.init.text+0x2e60): undefined reference to `omap36xx_vddcore_volt_data' twl-common.c:(.init.text+0x2830): undefined reference to `omap44xx_vdd_mpu_volt_data' twl-common.c:(.init.text+0x283c): undefined reference to `omap44xx_vdd_iva_volt_data' twl-common.c:(.init.text+0x2844): undefined reference to `omap44xx_vdd_core_volt_data' Acked-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Tony Lindgren 提交于
Otherwise we get the following error: arch/arm/mach-omap2/built-in.o: In function `n8x0_mmc_callback': twl-common.c:(.text+0x108a0): undefined reference to `omap_mmc_notify_cover_event' Fix this by warning about unusable MMC cover events. The long term fix needs to change the MMC drivers to register board specific callbacks directly with PMIC. Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 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>
-
- 16 2月, 2012 1 次提交
-
-
由 Grant Likely 提交于
irq_domain_add_simple() was a stop-gap measure until complete irq_domain support was complete. This patch removes the irq_domain_add_simple() interface. This patch also drops the explicit irq_domain initialization performed by the mach-versatile code because the versatile interrupt controller already has irq_domain support built into it. This was a bug that was hanging around quietly for a while, but with the full irq_domain which actually verifies that irq_domain ranges are available it would cause the registration to fail and the system wouldn't boot. v4: Fixed number of irqs in mx5 gpio code v2: Updated to pass in host_data pointer on irq_domain allocation. Signed-off-by: NGrant Likely <grant.likely@secretlab.ca> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Milton Miller <miltonm@bga.com> Cc: Russell King <linux@arm.linux.org.uk> Tested-by: NOlof Johansson <olof@lixom.net>
-
- 15 2月, 2012 4 次提交
-
-
由 Felipe Balbi 提交于
when commit 3528c58e (OMAP: omap_device: when building return platform_device instead of omap_device) started returning a platform_device instead of a omap_device pointer when building a device, it failed to convert all users introducing a compile warning when building arch/arm/mach-omap2/usb-host.c. This patch fixes that warning. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Santosh Shilimkar 提交于
arm_memblock_steal() is not suppose to be used outside ->reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken. Move the allocation as part of ->reserve callback to fix the it. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Santosh Shilimkar 提交于
OMAP4 cpuidle driver is reporting the state requested by governor rather than the actually attempted one. This is obviously misleading sysfs and powertop cpuidle statistics. Fix it so that stats are reported correctly. Reported-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> [khilman@ti.com: minor changelog edits] Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 NeilBrown 提交于
opp_find_freq_ceil and opp_get_voltage are documented as requiring rcu_lock to be held. So hold it. Signed-off-by: NNeilBrown <neilb@suse.de> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 13 2月, 2012 9 次提交
-
-
由 Russell King 提交于
It's useful to print the error code when a called function fails so a diagnosis of why it failed is possible. In this case, it fails because we try to register some data for the wl12xx driver, but as the driver is not configured, a stub function is used which simply returns -ENOSYS. Let's do the simple thing for -rc and print the error code. Also, the return code from platform_register_device() at each of these sites was not being checked. Add some checking, and again print the error code. This should be fixed properly for the next merge window so we don't issue error messages merely because a driver is not configured. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
While trying to debug my OMAP platforms, they emitted this message: omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state The following backtrace said it was from a function called '_enable', which didn't provide much clue. Grepping didn't find it either. The message is wrapped, so unwrap the message so grep can find it. Do the same for three other messages in this file. Acked-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
The previous commit causes new section mismatch warnings: WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio() The function omap_init_hsmmc() references the function __init omap_mux_init_gpio(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_gpio is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio() The function omap_init_hsmmc() references the function __init omap_mux_init_gpio(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_gpio is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. Again, as for omap2_hsmmc_init(), these functions are callable at runtime via the gpio-twl4030.c driver, and so these can't be marked __init. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 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>
-
由 Russell King 提交于
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init() The function omap_4430sdp_display_init() references the function __init omap_display_init(). This is often because omap_4430sdp_display_init lacks a __init annotation or the annotation of omap_display_init is wrong. Fix this by adding __init to omap_4430sdp_display_init(). Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup() The function omap_secondary_startup() references the function __cpuinit secondary_startup(). This is often because omap_secondary_startup lacks a __cpuinit annotation or the annotation of secondary_startup is wrong. Unfortunately, fixing this causes a new warning which is harder to solve: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup() The function omap4_hotplug_cpu() references the function __cpuinit omap_secondary_startup(). This is often because omap4_hotplug_cpu lacks a __cpuinit annotation or the annotation of omap_secondary_startup is wrong. because omap4_hotplug_cpu() is used by power management code as well, which may not end up using omap_secondary_startup(). Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Found by review. omap4_sdp4430_wifi_mux_init() is called by an __init marked function, and only calls omap_mux_init_gpio() and omap_mux_init_signal() which are both also an __init marked functions. The only reason this doesn't issue a warning is because the compiler inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init(). So, lets add the __init annotation to ensure this remains safe should the compiler choose not to inline. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal() The function omap_mux_init_signals() references the function __init omap_mux_init_signal(). This is often because omap_mux_init_signals lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
On my OMAP4 platform, I'm getting this error message repeated several times at boot: omap_vc_i2c_init: I2C config for all channels must match. omap_vc_i2c_init: I2C config for all channels must match. This doesn't help identify what the problem is. Fix this message to be more informative: omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0). This allows us to identify which voltage domains have a problem, and what the I2C configuration state (a boolean, i2c_high_speed) setting being used actually is. From this we find that omap4_core_pmic has i2c_high_speed false, but omap4_iva_pmic and omap4_mpu_pmic both have it set true. Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-