- 02 3月, 2011 3 次提交
-
-
由 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 提交于
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 提交于
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 3 次提交
-
-
由 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 提交于
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 提交于
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>
-
- 28 2月, 2011 1 次提交
-
-
由 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>
-
- 23 2月, 2011 3 次提交
-
-
由 Sumit Semwal 提交于
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: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Senthilvadivu Guruswamy 提交于
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: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Senthilvadivu Guruswamy 提交于
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: NBenoit Cousson <b-cousson@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 18 2月, 2011 12 次提交
-
-
由 Nishant Kamat 提交于
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: NNishant Kamat <nskamat@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 David Cohen 提交于
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: NDavid Cohen <dacohen@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Adrian Hunter 提交于
OneNAND version ID may not give the highest frequency supported and some OneNAND's have setup times that are clock dependent. Let the board provide that information. Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Adrian Hunter 提交于
OneNAND frequency is determined when calculating GPMC timings. Return that value instead of determining it again in the OMAP OneNAND driver. Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sukumar Ghorai 提交于
This patch overrides nand ecc layout and bad block descriptor (for 8-bit device) to support hw ecc in romcode layout. So as to have in sync with ecc layout throughout; i.e. x-loader, u-boot and kernel. This enables to flash x-loader, u-boot, kernel, FS images from kernel itself and compatiable with other tools. This patch does not enables this feature by default and need to pass from board file to enable for any board. Signed-off-by: NVimal Singh <vimalsingh@ti.com> Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sukumar Ghorai 提交于
This patch makes it possible to select sw or hw (different layout options) ecc scheme supported by omap nand driver. Signed-off-by: NVimal Singh <vimalsingh@ti.com> Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sukumar Ghorai 提交于
Configure the FIFO THREASHOLD value different for read and write to keep busy both filling and to drain out of FIFO at reading and writing. Signed-off-by: NVimal Singh <vimalsingh@ti.com> Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sukumar Ghorai 提交于
This patch enable prefetch-irq mode for nand transfer(read, write) Signed-off-by: NVimal Singh <vimalsingh@ti.com> Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sukumar Ghorai 提交于
add support the irq mode in GPMC. gpmc_init() function move after omap_init_irq() as it has dependecy on irq. Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sukumar Ghorai 提交于
nand transfer type (sDMA, Polled, prefetch) can be select from board file, enabling all transfer type in driver, by default. this helps in multi-omap build and to select different transfer type for different board. Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Charulatha V 提交于
Cleans up all base address definitions for omap_mcspi and adapts the device registration and driver to hwmod framework. Changes involves: 1) Removing all base address macro defines. 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(number of chipselect). 3) Appending base address with pdata reg_offset for omap4 boards. For omap4 all regs used in driver deviate with reg_offset_macros defined with an value of 0x100. So pass this offset through pdata and append the same to base address retrieved from hwmod data file and we are not mapping *_HL_* regs which are not used in driver. Signed-off-by: NCharulatha V <charu@ti.com> Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: NGrant Likely <grant.likely@secretlab.ca> Reviewed-by: NPartha Basak <p-basak2@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Charulatha V 提交于
Update the omap2420 hwmod data with the McSPI info. Add a device attribute structure which will be used for passing number of chipselects from hwmod data. Add revision macros to be passed from rev field from hwmod. Signed-off-by: NCharulatha V <charu@ti.com> Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: NGrant Likely <grant.likely@secretlab.ca> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 17 2月, 2011 4 次提交
-
-
由 Hema HK 提交于
Moved all the board specific internal PHY functions out of usb_musb.c file as this file is shared between the OMAP2+ and AM35xx platforms. There exists a file which has the functions specific to internal PHY used for OMAP4 platform. Moved all phy specific functions to this file and passing these functions through board data in the board file. Signed-off-by: NHema HK <hemahk@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Hemant Pedanekar 提交于
This patch adds support for low level debugging on TI816X boards. Currently the support for UART3 console on TI816X EVM is added. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Hemant Pedanekar 提交于
This patch updates the common machine specific source files with support for TI816X. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Hemant Pedanekar 提交于
This patch updates the common platform files with TI816X support. The approach taken in this patch is to add TI816X as part of OMAP3 variant where the cpu class is considered as OMAP34XX and the type is TI816X. This means, both cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X. A kernel config option CONFIG_SOC_OMAPTI816X is added under OMAP3 to include support for TI816X build. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 15 2月, 2011 3 次提交
-
-
由 Tony Lindgren 提交于
The new init_early hook happens at the end of setup_arch, which is too early for kzalloc. However, there's no need to call omap_serial_early_init that early, so fix this by setting it up as a core_initcall. Signed-off-by: NTony Lindgren <tony@atomide.com> Tested-by: NKevin Hilman <khilman@ti.com>
-
由 Tony Lindgren 提交于
Otherwise things will fail with early_init changes. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kishon Vijay Abraham I 提交于
Some macros defined in mcbsp.h related to audio, which are never being used is removed. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Reviewed-by: NCharulatha V <charu@ti.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Acked-by: NJarkko Nikula <jhnikula@gmail.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NG, Manjunath Kondaiah <manjugk@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 10 2月, 2011 1 次提交
-
-
由 Uwe Kleine-König 提交于
All callers of these functions live in .init.text, so these can go there, too. There they must not be exported anymore, this is no problem though, as all callers are always built-in. Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 28 1月, 2011 3 次提交
-
-
由 Russell King - ARM Linux 提交于
This adds a clean method to allow platforms to hook into the reset code if they require to. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Felipe Balbi 提交于
Fix the following compile warnings: arch/arm/mach-omap1/board-innovator.c:165:3: warning: initialization makes integer from pointer without a cast arch/arm/mach-omap1/board-perseus2.c:305:3: warning: initialization makes integer from pointer without a cast arch/arm/mach-omap1/board-fsample.c:338:3: warning: initialization makes integer from pointer without a cast Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest are nowadays just subcategories of these. Search and replace the following: ARCH_OMAP2420 SOC_OMAP2420 ARCH_OMAP2430 SOC_OMAP2430 ARCH_OMAP3430 SOC_OMAP3430 No functional changes. Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NThomas Weber <weber@corscience.de> Acked-by: NSourav Poddar <sourav.poddar@ti.com>
-
- 20 1月, 2011 2 次提交
-
-
由 Tony Lindgren 提交于
Earlier patches select HAVE_SCHED_CLOCK for omaps. To have working sched_clock also for MPU timer, we need to implement it in a way where the right one gets selected during the runtime. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
For omap15xx and 730 we need to use the MPU timer as the 32K timer is not available. For omap16xx we want to use the 32K timer because of PM. Fix this by allowing to build in both timers. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 19 1月, 2011 1 次提交
-
-
由 Paul Walmsley 提交于
After commit dc548fbb ("ARM: omap: convert sched_clock() to use new infrastructure"), OMAPs that use the 32KiHz "synchronization timer" as their clocksource crash during boot: [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 0.000000] pgd = c0004000 [ 0.000000] [00000000] *pgd=00000000 [ 0.000000] Internal error: Oops: 80000005 [#1] SMP [ 0.000000] last sysfs file: [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 Tainted: G W (2.6.37-07734-g2467802 #7) [ 0.000000] PC is at 0x0 [ 0.000000] LR is at sched_clock_poll+0x2c/0x3c [ 0.000000] pc : [<00000000>] lr : [<c0060b74>] psr: 600001d3 [ 0.000000] sp : c058bfd0 ip : c058a000 fp : 00000000 [ 0.000000] r10: 00000000 r9 : 411fc092 r8 : 800330c8 [ 0.000000] r7 : c05a08e0 r6 : c0034c48 r5 : c05ffc40 r4 : c0034c4c [ 0.000000] r3 : c05ffe6c r2 : c05a0bc0 r1 : c059f098 r0 : 00000000 [ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 0.000000] Control: 10c53c7f Table: 8000404a DAC: 00000017 This is due to the recent ARM init_sched_clock() changes and the late initialization of the counter_32k clock source. More information here: http://marc.info/?l=linux-omap&m=129513468605208&w=2 Fix by initializing the counter_32k clocksource during the machine timer initialization. Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk> Tested-by: NThomas Weber <weber@corscience.de> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 10 1月, 2011 4 次提交
-
-
由 Sumit Semwal 提交于
A panel connects to one of the overlay managers of DSS through some interface block. On OMAP4, specifying the type of the display is not sufficient to conclude which manager the panel should be connected to. Hence, a new member 'channel' is introduced in omap_dss_device structure to determine which manager the panel uses. The dss_recheck_connections() called in dss_driver_probe() uses this channel parameter to set the correct manager to the corresponding omap_dss_device. The channel parameter is used only once to ensure the correct managers are set for each panel. The parameter dssdev->manager->id will take care of ensuring that the panel and then the interface driver configures the correct DISPC channel. Also, add a new Overlay Manager in manager.c, make other changes needed for LCD2 channel. Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NMukund Mittal <mmittal@ti.com> Signed-off-by: NSamreen <samreen@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-
由 Sumit Semwal 提交于
DISPC functions are modified in order to work when the manager is LCD2. This includes: Adding new IRQs specific to LCD2 and their handling. Provide dumps of the new manager's registers. Provide dumps of the new manager's clocks. Checks for channel for registers DISPC_CONTROL2 and DISPC_CONFIG2 which can't be parametrized. Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NMukund Mittal <mmittal@ti.com> Signed-off-by: NSamreen <samreen@ti.com> Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-
由 Sumit Semwal 提交于
On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. There is a set of regsiters for LCD2 channel similar to the existing LCD channel, like DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so on. Introduce new enum members for LCD2 Channel and corresponding Overlay Manager in display.h. Represent the following DISPC register defines with channel as a parameter to differentiate between LCD and LCD2 registers (and also DIGIT in some cases): DISPC_DEFAULT_COLOR, DISPC_TRANS_COLOR, DISPC_TIMING_H, DISPC_TIMING_V, DISPC_POL_FREQ, DISPC_DIVISOR, DISPC_SIZE_LCD, DISPC_DATA_CYCLEk, DISPC_CPR_COEF_R, DISPC_CPR_COEF_G and DISPC_CPR_COEF_B This parametrization helps in reducing the number of register defines for DISPC. Replace the existing reads/writes to these registers in this new way. Also, Introduce defines for registers DISPC_CONTROL2 and DISPC_CONFIG2 which are used exclusively for LCD2 channel. Signed-off-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NMukund Mittal <mmittal@ti.com> Signed-off-by: NSamreen <samreen@ti.com> Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-
由 Bryan Wu 提交于
Generic DPI panel driver includes the driver and 4 similar panel configurations. It will match the panel name which is passed from platform data and setup the right configurations. With generic DPI panel driver, we can remove those 4 duplicated panel display drivers. In the future, it is simple for us just add new panel configuration date in panel-generic-dpi.c to support new display panel. Signed-off-by: NBryan Wu <bryan.wu@canonical.com> Acked-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-