- 29 3月, 2012 1 次提交
-
-
由 David Howells 提交于
Disintegrate asm/system.h for ARM. Signed-off-by: NDavid Howells <dhowells@redhat.com> cc: Russell King <linux@arm.linux.org.uk> cc: linux-arm-kernel@lists.infradead.org
-
- 17 3月, 2012 1 次提交
-
-
由 Felipe Balbi 提交于
This patch allows us to drop the OMAP dependency from the OMAP4 keypad driver. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NSourav Poddar <sourav.poddar@ti.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
- 12 3月, 2012 6 次提交
-
-
由 Peter Ujfalusi 提交于
The McBSP driver stack has been moved to ASoC. The CONFIG_OMAP_MCBSP will be removed since the CONFIG_SND_OMAP_SOC_MCBSP will trigger to build the McBSP (audio) drivers. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NLiam Girdwood <lrg@ti.com>
-
由 Peter Ujfalusi 提交于
On OMAP2/3 McBSP1 port has 6 pin setup, while on OMAP4 the port is McBSP4. Implement the CLKR/FSR clock mux selection for OMAP4, and make sure that we add the correct callback for the correct port across supported OMAP versions. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NLiam Girdwood <lrg@ti.com>
-
由 Peter Ujfalusi 提交于
The driver for omap-mcbsp-dai no longer exist since it has been merged with the omap-mcbsp driver. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Tested-by: NGrazvydas Ignotas <notasas@gmail.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: NLiam Girdwood <lrg@ti.com>
-
由 Peter Ujfalusi 提交于
The OMAP McBSP driver stack used to contain two different drivers. One of them was used as kind low-level access to the IP, while the other driver was the ASoC DAI driver. There were global, shared structures, in different places, the McBSP instances are reffered with id numbers (sometimes 0 based, in other cases 1 based id numbers). Create one single driver for OMAP McBSP with name: omap-mcbsp. Convert the old omap-mcbsp driver initially to be a library for the omap-mcbsp DAI driver. With this change we can get rid of all global variables, structures. Further cleanup is coming... Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NGrazvydas Ignotas <notasas@gmail.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: NLiam Girdwood <lrg@ti.com>
-
由 Peter Ujfalusi 提交于
Convert the plat-omap/mcbsp.c driver to be proper platform driver. Remove the omap_mcbsp_init function call which was called from mach-omap1/2/mcbsp.c to register the platform driver for the just created platform device in the same function. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Tested-by: NGrazvydas Ignotas <notasas@gmail.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: NLiam Girdwood <lrg@ti.com>
-
由 Peter Ujfalusi 提交于
The cpu_is_omap4430() macro always return with 0. Use the correct cpu_is_omap443x() to check for Panda revision. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NLiam Girdwood <lrg@ti.com>
-
- 06 3月, 2012 1 次提交
-
-
由 R Sricharan 提交于
While building modules with randconfig the below errors are observed. ERROR: "omap_bus_sync" [drivers/watchdog/sp805_wdt.ko] undefined! ERROR: "omap_bus_sync" [drivers/watchdog/dw_wdt.ko] undefined! ERROR: "omap_bus_sync" [drivers/virtio/virtio_ring.ko] undefined! ERROR: "omap_bus_sync" [drivers/video/sm501fb.ko] undefined! ERROR: "omap_bus_sync" [drivers/usb/mon/usbmon.ko] undefined! ERROR: "omap_bus_sync" [drivers/usb/host/sl811-hcd.ko] undefined! ERROR: "omap_bus_sync" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "omap_bus_sync" [drivers/usb/host/isp1760.ko] undefined! ERROR: "omap_bus_sync" [drivers/usb/host/isp1362-hcd.ko] undefined! ERROR: "omap_bus_sync" [drivers/usb/host/isp116x-hcd.ko] undefined! ERROR: "omap_bus_sync" [drivers/usb/core/usbcore.ko] undefined! ERROR: "omap_bus_sync" [drivers/tty/serial/altera_uart.ko] undefined! ERROR: "omap_bus_sync" [drivers/tty/serial/altera_jtaguart.ko] undefined! ERROR: "omap_bus_sync" [drivers/tty/serial/8250/8250_dw.ko] undefined! ERROR: "omap_bus_sync" [drivers/ssb/ssb.ko] undefined! ERROR: "omap_bus_sync" [drivers/rtc/rtc-cmos.ko] undefined! ERROR: "omap_bus_sync" [drivers/rtc/rtc-bq4802.ko] undefined! ERROR: "omap_bus_sync" [drivers/mtd/nand/tmio_nand.ko] undefined! ERROR: "omap_bus_sync" [drivers/mtd/nand/omap2.ko] undefined! Signed-off-by: NR Sricharan <r.sricharan@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 05 3月, 2012 1 次提交
-
-
由 Ohad Ben-Cohen 提交于
For some weird (freudian?) reason, commit 435792d9 "ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp" unintentionally changed the mailbox's initcall instead of the iommu's. Fix that. Reported-by: NFernando Guzman Lugo <fernando.lugo@ti.com> Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Joerg Roedel <Joerg.Roedel@amd.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
- 01 3月, 2012 1 次提交
-
-
由 Vaibhav Hiremath 提交于
Add missing break statement in the function omap3xxx_check_revision. The commit id 4390f5b2 [ARM: OMAP: TI814X: Add cpu type macros and detection support], removed the 'break' statement from the function omap3xxx_check_revision(), resulting into wrong omap/cpu_revision initialization for AM335x devices. Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> [tony@atomide.com: refreshed to apply after changes to cpu_rev] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 29 2月, 2012 1 次提交
-
-
由 Rajendra Nayak 提交于
VUSB is a fixed regulator, so get rid of the apply_uV constraint for it, which fixes the following error seen at boot on omap4 SDP and PANDA boards. machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint twl_reg twl_reg.46: can't register VUSB, -22 twl_reg: probe of twl_reg.46 failed with error -22 Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.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>
-
- 24 2月, 2012 2 次提交
-
-
由 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>
-
- 23 2月, 2012 1 次提交
-
-
由 Tomi Valkeinen 提交于
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-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 11 次提交
-
-
由 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>
-
由 Russell King 提交于
While testing on my OMAP3430 platform, this error message was emitted: omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise: omap_vc_init_channel: No PMIC info for vdd_core While we're here, fix a simple spelling error in a comment. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
When CONFIG_OF is disabled, the compile fails with: arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function) Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 10 2月, 2012 3 次提交
-
-
由 Paul Walmsley 提交于
On OMAP2420-based systems, the PM code ignores the state of the UART functional clocks when determining what idle state to enter. This breaks the serial port now that the UART driver's clock behavior can be controlled via the PM autosuspend timeout. To fix, remove the special-case idle handling for the UARTs in the OMAP2420/2430 PM idle code added by commit 4af4016c ("OMAP3: PM: UART: disable clocks when idle and off-mode support"). Tested on Nokia N800. This patch is a collaboration between Tony Lindgren <tony@atomide.com> and Paul Walmsley <paul@pwsan.com>. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
Prevent OMAP UARTs from going idle while they are still transferring data in PIO mode. This works around an oversight in the OMAP UART hardware present in OMAP34xx and earlier: an idle UART won't send a wakeup when the TX FIFO threshold is reached. This causes long delays during data transmission when the MPU powerdomain enters a low-power mode. The MPU interrupt controller is not able to respond to interrupts when it's in a low-power state, so the TX buffer is not refilled until another wakeup event occurs. This fix changes the erratum i291 DMA idle workaround. Rather than toggling between force-idle and no-idle, it will toggle between smart-idle and no-idle. The important part of the workaround is the no-idle part, so this shouldn't result in any change in behavior. This fix should work on all OMAP UARTs. Future patches intended for the 3.4 merge window will make this workaround conditional on a "feature" flag, and will use the OMAP36xx+ TX event wakeup support. Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291 workaround, which led to the development of this approach. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Russell King 提交于
When the PMIC is not found, voltdm->pmic will be NULL. vp.c's initialization function tries to dereferences this, which causes an oops: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT Modules linked in: CPU: 0 Not tainted (3.3.0-rc2+ #204) PC is at omap_vp_init+0x5c/0x15c LR is at omap_vp_init+0x58/0x15c pc : [<c03db880>] lr : [<c03db87c>] psr: 60000013 sp : c181ff30 ip : c181ff68 fp : c181ff64 r10: c0407808 r9 : c040786c r8 : c0407814 r7 : c0026868 r6 : c00264fc r5 : c040ad6c r4 : 00000000 r3 : 00000040 r2 : 000032c8 r1 : 0000fa00 r0 : 000032c8 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 00000015 Process swapper (pid: 1, stack limit = 0xc181e2e8) Stack: (0xc181ff30 to 0xc1820000) ff20: c0381d00 c02e9c6d c0383582 c040786c ff40: c040ad6c c00264fc c0026868 c0407814 00000000 c03d9de4 c181ff8c c181ff68 ff60: c03db448 c03db830 c02e982c c03fdfb8 c03fe004 c0039988 00000013 00000000 ff80: c181ff9c c181ff90 c03d9df8 c03db390 c181ffdc c181ffa0 c0008798 c03d9df0 ffa0: c181ffc4 c181ffb0 c0055a44 c0187050 c0039988 c03fdfb8 c03fe004 c0039988 ffc0: 00000013 00000000 00000000 00000000 c181fff4 c181ffe0 c03d1284 c0008708 ffe0: 00000000 c03d1208 00000000 c181fff8 c0039988 c03d1214 1077ce40 01f7ee08 Backtrace: [<c03db824>] (omap_vp_init+0x0/0x15c) from [<c03db448>] (omap_voltage_late_init+0xc4/0xfc) [<c03db384>] (omap_voltage_late_init+0x0/0xfc) from [<c03d9df8>] (omap2_common_pm_late_init+0x14/0x54) r8:00000000 r7:00000013 r6:c0039988 r5:c03fe004 r4:c03fdfb8 [<c03d9de4>] (omap2_common_pm_late_init+0x0/0x54) from [<c0008798>] (do_one_initcall+0x9c/0x164) [<c00086fc>] (do_one_initcall+0x0/0x164) from [<c03d1284>] (kernel_init+0x7c/0x120) [<c03d1208>] (kernel_init+0x0/0x120) from [<c0039988>] (do_exit+0x0/0x2cc) r5:c03d1208 r4:00000000 Code: e5ca300b e5900034 ebf69027 e5994024 (e5941000) ---[ end trace aed617dddaf32c3d ]--- Kernel panic - not syncing: Attempted to kill init! Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 08 2月, 2012 1 次提交
-
-
由 Igor Grinberg 提交于
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8): Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown) The function cm_t35_init_usbh() references the (unknown reference) __initdata (unknown). This is often because cm_t35_init_usbh lacks a __initdata annotation or the annotation of (unknown) is wrong. Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Signed-off-by: NTony Lindgren <tony@atomide.com>
-