- 09 3月, 2011 1 次提交
-
-
由 Paul Walmsley 提交于
Commit 3cf32bba ("OMAP: McBSP: Convert McBSP to platform device model") breaks compilation with non-multi-OMAP1 configs: CC arch/arm/mach-omap1/mcbsp.o arch/arm/mach-omap1/mcbsp.c: In function 'omap1_mcbsp_init': arch/arm/mach-omap1/mcbsp.c:384: warning: dereferencing 'void *' pointer arch/arm/mach-omap1/mcbsp.c:387: error: invalid use of void expression arch/arm/mach-omap1/mcbsp.c:390: warning: dereferencing 'void *' pointer arch/arm/mach-omap1/mcbsp.c:393: error: invalid use of void expression Fix by avoiding NULL dereferences. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: NJarkko Nikula <jhnikula@gmail.com> [tony@atomide.com: updated description not to remove unnecessary branch name] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 05 3月, 2011 1 次提交
-
-
由 Benoit Cousson 提交于
The following commit: 38698bef: OMAP2+: clockevent: set up GPTIMER clockevent hwmod right before timer init Fixed properly the issue with early init for the timer1 So reverts commit 3b03b58d that is now generated a warning at boot time. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Reviewed-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 03 3月, 2011 5 次提交
-
-
由 Ilkka Koskinen 提交于
twl4030_codec_audio and twl4030_codec_vibra_data has unused field. In order to remove it, corresponding settings needs to be removed from board files. Signed-off-by: NIlkka Koskinen <ilkka.koskinen@nokia.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Ilkka Koskinen 提交于
Add support for vibra Signed-off-by: NIlkka Koskinen <ilkka.koskinen@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Guy Eilam 提交于
Added the KIM (Kernel initialization module for the Shared Transport driver) device entry in the board file Only the Blutooth enable GPIO is set for now Signed-off-by: NGuy Eilam <guy@wizery.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
On the OMAP3430LDP board, the ads7846 touchscreen controller is powered by VAUX1 regulator (supplying 3.0v). Fix this mapping in the board file, and hence prevent the ads7846 driver init to fail with the below error.. ads7846 spi1.0: unable to get regulator: -19 Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Ming Lei 提交于
WARNING: arch/arm/plat-omap/built-in.o(.data+0x6d4): Section mismatch in reference from the variable omap_driver to the function .init.text:omap_cpu_init() The variable omap_driver references the function __init omap_cpu_init() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, Signed-off-by: NMing Lei <tom.leiming@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 02 3月, 2011 8 次提交
-
-
由 Kishore Kadiyala 提交于
Modifying the device & driver name from "mmci-omap-hs" to "omap_hsmmc". Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Benoit Cousson<b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishore Kadiyala 提交于
OMAP2420 platform consists of mmc block as in omap1 and not the hsmmc block as present in omap2430, omap3, omap4 platforms. Removing all base address macro defines except keeping one for OMAP2420 and adapting only hsmmc device registration and driver to hwmod framework. Changes involves: 1) Remove controller reset in devices.c which is taken care of by hwmod framework. 2) Using omap-device layer to register device and utilizing data from hwmod data file for base address, dma channel number, Irq_number, device attribute. 3) Update the driver to use dev_attr to find whether controller supports dual volt cards Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Reviewed-by: NBalaji T K <balajitk@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> CC: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishore Kadiyala 提交于
Moving the definition of mux setting API from devices.c to hsmmc.c and renaming it from "omap2_mmc_mux" to "omap_hsmmc_mux". Also calling "omap_hsmmc_mux" from omap2_hsmmc_init. Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Cc: Chris Ball <cjb@laptop.org Cc: Tony Lindgren <tony@atomide.com Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishore Kadiyala 提交于
Add a device attribute to hwmod data of omap2430, omap3, omap4. Currently the device attribute holds information regarding dual volt MMC card support by the controller which will be later passed to the host driver via platform data. Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Benoit Cousson<b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Anand Gadiyar 提交于
Enabling hsmmc hwmod for OMAP4 Signed-off-by: NAnand Gadiyar <gadiyar@ti.com> Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Benoit Cousson<b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
Update the omap3 hwmod data with the HSMMC info. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
Update the omap2430 hwmod data with the HSMMC info. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Anand Gadiyar 提交于
The MMC controller on the OMAP2420 is different from those on the OMAP2430, OMAP3 and OMAP4 families - all of the latter are identical. The one on the OMAP2420 is closer to that on OMAP1 chips. Currently, the n8x0 is the only OMAP2420 platform supported in mainline which registers the MMC controller. Upcoming changes to register the controllers using hwmod data are potentially invasive. To reduce the risk, separate out the 2420 controller registration from the common init function and update its only user. Also seperating out mux settings for OMAP2420. Signed-off-by: NAnand Gadiyar <gadiyar@ti.com> Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: Chris Ball <cjb@laptop.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 01 3月, 2011 8 次提交
-
-
由 Eyal Reizer 提交于
This patch is again current omap-for-linus branch Adds platform initialization for working with the WLAN module attached to the omap3evm. The patch includes MMC2 initialization, SDIO and control pins muxing and platform device registration. Signed-off-by: NEyal Reizer <eyalr@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
On non-OMAP2 and non-OMAP3 kernel configs, turn omap2_sdrc_init() into a no-op. Otherwise, compilation breaks on an OMAP4-only config with the current omap-for-linus branch: arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_devices': ../mach-omap2/io.c:421: undefined reference to `omap2_sdrc_init' Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for suggesting the use of a empty static inline function rather than a macro. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com> [tony@atomide.com: updated not to use __init for inline omap2_sdrc_init] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
Set up the GPTIMER hwmod used for the clockevent source immediately before it is used. This avoids the need to set up all of the hwmods until the boot process is further along. (In general, we want to defer as much as possible until late in the boot process.) This second version fixes a bug pointed out by Santosh Shilimkar <santosh.shilimkar@ti.com>, that would cause the kernel to use an incorrect timer hwmod name if the selected GPTIMER was not 1 or 12 - thanks Santosh. Also, Tarun Kanti DebBarma <tarun.kanti@ti.com> pointed out that the original patch did not apply cleanly; this has now been fixed. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
-
由 Paul Walmsley 提交于
Add omap_hwmod_setup_one(), which is intended for use early in boot to selectively setup the hwmods needed for system clocksources and clockevents, and any other hwmod that is needed in early boot. omap_hwmod_setup_all() can then be called later in the boot process. The point is to minimize the amount of code that needs to be run early. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
Previously, if a hwmod had already been set up, and the code attempted to set up the hwmod again, an error would be returned. This is not really useful behavior if we wish to allow the OMAP core code to setup the hwmods needed for the Linux clocksources and clockevents before the rest of the hwmods are setup. So, instead of generating errors, just ignore the attempt to re-setup the hwmod. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
-
由 Paul Walmsley 提交于
Move the code that looks for the MPU initiator hwmod to run during the individual hwmod _register() function. (Previously, it ran after all hwmods were registered in the omap_hwmod_late_init() function.) This is done so code can late-initialize a few individual hwmods -- for example, for the system timer -- before the entire set of hwmods is initialized later in boot via omap_hwmod_late_init(). Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
-
由 Paul Walmsley 提交于
Rename omap_hwmod_init() to omap_hwmod_register(). Rename omap_hwmod_late_init() to omap_hwmod_setup_all(). Also change all of the callers to reflect the new names. While here, update some copyrights. Suggested by Tony Lindgren <tony@atomide.com>. N.B. The comment in mach-omap2/serial.c may no longer be correct, given recent changes in init order. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
由 Paul Walmsley 提交于
There's no longer any reason why we should prevent multiple calls to omap_hwmod_init(). It is now simply used to register an array of hwmods. This should allow a subset of hwmods (e.g., hwmods handling the system clocksource and clockevents) to be registered earlier than the remaining mass of hwmods. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
-
- 28 2月, 2011 4 次提交
-
-
由 Don Zickus 提交于
A customer of ours, complained that when setting the reset vector back to 0, it trashed other data and hung their box. They noticed when only 4 bytes were set to 0 instead of 8, everything worked correctly. Mathew pointed out: | | We're supposed to be resetting trampoline_phys_low and | trampoline_phys_high here, which are two 16-bit values. | Writing 64 bits is definitely going to overwrite space | that we're not supposed to be touching. | So limit the area modified to u32. Signed-off-by: NDon Zickus <dzickus@redhat.com> Acked-by: NMatthew Garrett <mjg@redhat.com> Cc: <stable@kernel.org> LKML-Reference: <1297139100-424-1-git-send-email-dzickus@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Thara Gopinath 提交于
Add dmtimer data. Signed-off-by: NThara Gopinath <thara@ti.com> Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: NBenoit Cousson <b-cousson@ti.com>
-
由 Thara Gopinath 提交于
Add dmtimer data. Signed-off-by: NThara Gopinath <thara@ti.com> Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: NBenoit Cousson <b-cousson@ti.com>
-
由 Thara Gopinath 提交于
Add dmtimer data. Signed-off-by: NThara Gopinath <thara@ti.com> Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: NBenoit Cousson <b-cousson@ti.com>
-
- 26 2月, 2011 5 次提交
-
-
由 Santosh Shilimkar 提交于
CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base. The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power domain control register Fix the same. The autogen scripts is fixed thanks to Benoit Cousson With the old value, the clockdomain code would access the *_PWRSTCTRL.POWERSTATE field when it thought it was accessing the *_CLKSTCTRL.CLKTRCTRL field. In the worst case, this could cause system power management to behave incorrectly. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: added second paragraph to commit message] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Tony Lindgren 提交于
We should only call init_common_infrastructure and init_common_devices from init_early. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Radek Pilař (Mrkva) 提交于
init_early hook runs too early for omap3_mux_init(), so the board won't boot. Moved to init_machine, then it works just fine. Signed-off-by: NRadek Pilar <mrkva@mrkva.eu> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
Add SI4713 FM transmitter supplies, platform data and setup to RX-51/N900. It is connected to line output signals of TLV320AIC34 codec A part. Driver can be either built-in or a module. It can be tuned with v4l2-ctl from ivtv-utils. Following examples illustrate the use of it: v4l2-ctl -d /dev/radio0 --set-ctrl=mute=0 (power up) v4l2-ctl -d /dev/radio0 -f 107900 (tune 107.9 MHz) v4l2-ctl -d /dev/radio0 --set-ctrl=mute=1 (power down) Signed-off-by: NJarkko Nikula <jhnikula@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Fix compile if MTD_NAND_OMAP2 is not selected Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 25 2月, 2011 8 次提交
-
-
由 David Cohen 提交于
Add support to register an isr for IOMMU fault situations and adapt it to allow such (*isr)() to be used as fault callback. Drivers using IOMMU module might want to be informed when errors happen in order to debug it or react. Signed-off-by: NDavid Cohen <dacohen@gmail.com> Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 David Cohen 提交于
IOMMU upper layer and user are responsible to handle a fault and to define whether it will end up as an error or not. OMAP2+ specific layer should not print anything in such case. Signed-off-by: NDavid Cohen <dacohen@gmail.com> Acked-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishon Vijay Abraham I 提交于
Information like base address and DMA channel nubers should no longer be obtained using macros. These information should be obtained from hwmod database. Hence the macros that define the base address are removed. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NCharulatha V <charu@ti.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NJarkko Nikula <jhnikula@gmail.com> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishon Vijay Abraham I 提交于
After McBSP driver is hwmod adapted, the information about the hw would be obtained from the hwmod database by the mcbsp driver. Since DMA programming is handled by the client driver, APIs are provided to pass the DMA channel number and base address of data register required by the client driver for DMA programming. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NCharulatha V <charu@ti.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NJarkko Nikula <jhnikula@gmail.com> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishon Vijay Abraham I 提交于
Add pm runtime support for McBSP driver. Reference to fclk is not removed because it is required when the functional clock is switched from one source to another. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NJarkko Nikula <jhnikula@gmail.com> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishon Vijay Abraham I 提交于
McBSP2/3 in OMAP3 has sidetone feature which requires autoidle to be disabled before starting the sidetone. Also SYSCONFIG register has to be set with smart idle or no idle depending on the dma op mode (threshold or element sync). For doing these operations dynamically at runtime, omap_device APIs are used to modify SYSCONFIG register. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NJarkko Nikula <jhnikula@gmail.com> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> [tony@atomide.com: updated to compile without omap_device idle calls] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishon Vijay Abraham I 提交于
Modify OMAP2+ McBSP to use omap hwmod framework APIs Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NCharulatha V <charu@ti.com> Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NJarkko Nikula <jhnikula@gmail.com> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishon Vijay Abraham I 提交于
Since the sidetone block is tightly coupled to the mcbsp, sidetone information is directly added to mcbsp2 & 3 hwmod dev_attr. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-