- 01 Mar, 2011 7 commits
-
-
Anand Gadiyar authored
Enabling hsmmc hwmod for OMAP4 Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Benoit Cousson<b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Update the omap3 hwmod data with the HSMMC info. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
Update the omap2430 hwmod data with the HSMMC info. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Anand Gadiyar authored
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: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Kishore 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: Tony Lindgren <tony@atomide.com>
-
Eyal Reizer authored
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: Eyal Reizer <eyalr@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
-
Paul Walmsley authored
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: Paul 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: Tony Lindgren <tony@atomide.com>
-
- 28 Feb, 2011 9 commits
-
-
Paul Walmsley authored
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: Paul 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: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
-
Paul Walmsley authored
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: Paul 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 authored
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: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
-
Paul Walmsley authored
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: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
-
Paul Walmsley authored
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: Paul 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 authored
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: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
-
Thara Gopinath authored
Add dmtimer data. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
-
Thara Gopinath authored
Add dmtimer data. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
-
Thara Gopinath authored
Add dmtimer data. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
-
- 23 Feb, 2011 8 commits
-
-
git://gitorious.org/linux-omap-dss2/linuxTony Lindgren authored
Conflicts: arch/arm/mach-omap2/board-3430sdp.c
-
Tony Lindgren authored
-
Senthilvadivu Guruswamy authored
This patch updated board files to replace platform_device_register or platform_add_devices of DSS with omap_display_init(). This moves away registration of DSS from board files into a common place. Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Sumit Semwal authored
A new file display.c is introduced for display driver init, which adds a function omap_display_init to do the DSS driver registration. This is the first step in moving away registration of DSS from board files into a common place. Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Senthilvadivu Guruswamy authored
Use driver name in regulator inits needed for display instead of using device structure name. Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Senthilvadivu Guruswamy authored
Hwmod needs database of all IPs in a system. This patch generates the hwmod database for Display Sub System applicable for OMAP3430 and OMAP36xx. DSS is also considered as an IP as DISPC, RFBI and named as dss_core. For all the IP modules in DSS, same clock is needed for enabling. Hwmod sees DSS IPs as independent IPs, so same clock has to be repeated for .main_clk in each IP. This patch defines separate hwmod databases for OMAP3430ES1 and (OMAP3430ES2 and OMAP36xx) as OMAP3430ES1 does not have IDLEST bit to poll on for dss IP, and also the firewall regions are different between 3430es1 and later. Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Senthilvadivu Guruswamy authored
Hwmod needs database of all IPs in a system. This patch generates the hwmod database for OMAP2430 Display Sub System. Since DSS is also considered as an IP as DISPC, RFBI, name it as dss_core. Acked-by: Benoit Cousson <b-cousson@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Senthilvadivu Guruswamy authored
Hwmod needs database of all IPs in a system. This patch generates the hwmod database for OMAP2420 Display Sub System,. Since DSS is also considered as an IP as DISPC, RFBI, name it as dss_core. Acked-by: Benoit Cousson <b-cousson@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
- 22 Feb, 2011 10 commits
-
-
git://gitorious.org/usb/usbTony Lindgren authored
Conflicts: arch/arm/mach-omap2/omap_hwmod_2430_data.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
-
Benoit Cousson authored
Since the timer1 is now started before the hwmod_init, we cannot reset it and idle it anymore. Add the appropriate flags to prevent the hwmod framework to do that. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Kishore Kadiyala authored
OMAP4 supports up to 5 MMC controllers, but only 3 of these were initialized. MMC5 is used by wl12xx chip. So initialize MMC4 and MMC5. Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Panduranga Mallireddy authored
Add MMC5 support on PANDA, which has the wl1271 device hardwired to. The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ line, and power-controlled by a GPIO-based fixed regulator. Based on the patch for mmc3/wl1271 device support for zoom by Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Panduranga Mallireddy authored
Add a fixed regulator vmmc device to enable power control of the wl1271 wlan device. Based on the patch for zoom by Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Panduranga Mallireddy authored
Power to the wl12xx wlan device is controlled by a fixed regulator. Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE. Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Panduranga Mallireddy authored
Add board muxing to support the wlan wl1271 chip that is hardwired to mmc5 (fifth mmc controller) on the PANDA. Based on the wlan board muxing for zoom3 by Ohad Ben-Cohen <ohadb@ti.com> Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Balaji T K authored
Signed-off-by: Balaji T K <balajitk@ti.com> Tested-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Balaji T K authored
Fixed regulators in twl6030 do not have set_voltage hook. Regulator core returns -22 if set_voltage is NULL and apply_uV is set while applying the constraint to set voltage resulting in failure during probe of these regulators. Do not set apply_uV for fixed regulators which don't have set_voltage. machine_constraints_voltage: VANA: failed to apply 2100000uV constraint twl_reg twl_reg.43: can't register VANA, -22 twl_reg: probe of twl_reg.43 failed with error -22 machine_constraints_voltage: VCXIO: failed to apply 1800000uV constraint twl_reg twl_reg.44: can't register VCXIO, -22 twl_reg: probe of twl_reg.44 failed with error -22 machine_constraints_voltage: VDAC: failed to apply 1800000uV constraint twl_reg twl_reg.45: can't register VDAC, -22 twl_reg: probe of twl_reg.45 failed with error -22 Signed-off-by: Balaji T K <balajitk@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Rajendra Nayak authored
clean the regulator supply mapping data in the 3430sdp board file (which is spread all over) by moving all of them together. Also use the REGULATOR_SUPPLY macro and remove instances of mapping dev pointers at run time. Additonally define all regulator_consumer_supply as array's and use ARRAY_SIZE macro to define num_consumer_supplies. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 21 Feb, 2011 1 commit
-
-
Benoit Cousson authored
- Add a rev attribute to identify various McSPI IP version. - Add a dev_attr structure to provide the number of chipselect supported by the instance. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 18 Feb, 2011 1 commit
-
-
Nishant Kamat authored
Allow OMAP4 ES2.1 and ES2.2 revisions to be recognized in the omap4_check_revision() function. Mainly, ES2.1 has fixes that allow LPDDR to be used at 100% OPP (400MHz). ES2.2 additionally has a couple of power management fixes (to reduce leakage), an I2C1 SDA line state fix, and a floating point write corruption fix (cortex erratum). Even though the current mainline support doesn't need to distinguish between ES2.X versions, it's still useful to know the correct silicon rev when issues are reported. Moreover, these id checks can be used by power management code that selects suitable OPPs considering the memory speed limitation on ES2.0. For details about the silicon errata on OMAP4430, refer http://focus.ti.com/pdfs/wtbu/SWPZ009A_OMAP4430_Errata_Public_vA.pdfSigned-off-by: Nishant Kamat <nskamat@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 17 Feb, 2011 4 commits
-
-
Sanjeev Premi authored
Change all occurences of printf() to pr_err(). Includes minor formatting changes as result of this change. Signed-off-by: Sanjeev Premi <premi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Sanjeev Premi authored
This patch fixes typos that were remaining after the file and functions were renamed. Signed-off-by: Sanjeev Premi <premi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
David Cohen authored
Declaration of exported function 'iopgtable_lookup_entry' is missing from header file. Currently we have a sparse warning as it's not being used externally. Adding its declaration to avoid such warning and allow its usage in future. Signed-off-by: David Cohen <dacohen@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Roman Tereshonkov authored
The current multiblock erase verify read timeout 100us is the maximum for none-error case. If errors happen during multibock erase then the specification recommends to run multiblock erase verify command with maximum timeout 10ms (see specs. for KFM4G16Q2A and KFN8G16Q2A). For the most common non-error case we wait 100us in udelay polling loop. In case of timeout the interrupt mode is used to wait for the command end. Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com> Acked-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-