- 22 Nov, 2009 40 commits
-
-
vikram pandita authored
Replace zoom2 with zoom name in board-zoom-peripherals.c file and board-zoom-debugboard.c. Create mach/board-zoom.h. This file has functions reused for boards: Zoom2/Zoom3/sdp3630. Hence have all functions commonly named as zoom Signed-off-by:
Vikram Pandita <vikram.pandita@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
vikram pandita authored
Split zoom2 board file into a base board file and a board-zoom-peripherals.c file. That way the same peripherals file can be reused for zoom3 and sdp3630 in addition to zoom2. Also remove unused struct omap_board_config_kernel entry. NOTE: Keep the twl4030_madc_platform_data and twl4030_platform_data entries in board-zoom2.c to avoid merge conflicts with the pending patches in MFD tree. These entries will be removed later as a fix. Following list shows the commonality across the three platforms and hence the case for software reuse: Peripheral zoom2 zoom3 sdp3630 --------------------------------------- Ethernet smsc smsc smc NOR n/a n/a B Onenand n/a n/a B HDMI A A B (present on different i2c) NAND A A A (same nand) SDRAM A A A (same sdram) Keypad A A A (same twl) Camera A A A (same sensor can be mounted) LCD Display A A A (same wvga display) OPPs A A A (same chip feature) Audio A A A (same audio via twl5030) Signed-off-by:
-
Sriram authored
Migrate to smsc911x ethernet driver instead of smc911x driver. The smsc911x ethernet driver supports NAPI and performs better under heavy traffic. With the smc911x driver we were witnessing very high iowait time for high IO load over NFS. Signed-off-by:
Sriramakrishnan <srk@ti.com> Signed-off-by:
-
Mike Rapoport authored
Initialize vmmc and vmmc_aux regulators Note that the omap3evm_twldata.vmmc1 and omap3evm_twldata.vsim are set in omap3_evm_i2c_init() to avoid a merge conflict with the MFD tree. These will be initialized in omap3evm_i2c_boardinfo as a fix later on. Signed-off-by:
Mike Rapoport <mike@compulab.co.il> Signed-off-by:
-
Ajay Kumar Gupta authored
Added runtime programming for the differences in EHCI interface between OMAP3EVM revisions (Rev >= E) and (Rev < E). Changes: - EHCI PHY reset GPIO pin is 21 on Rev >= E while Rev < E uses GPIO pin 135. - Rev >= E uses EHCI Vbus enable GPIO22 line. - Rev >= E uses GPIO61 to select EHCI port either on main board or on Mistral Daughter Card (MDC). OMAP3EVM Rev < E doesn't have EHCI port on main board. - Currently GPIO61 it programmed to enable EHCI port on main board only. Signed-off-by:Ajay Kumar Gupta <ajay.gupta@ti.com>
-
Ajay Kumar Gupta authored
Added function to differentiate between the OMAP3EVM revisions. The chip-id of the ethernet PHY is being used for this purpose. Rev A to D : 0x01150000 Rev >= E : 0x92200000 Signed-off-by:
Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by:
Sanjeev Premi <premi@ti.com> Signed-off-by:
-
Anand Gadiyar authored
The mainline merge of the 3430SDP support (commit 6fdc29e2) seems to have messed up the 3430 defconfig completely. Update the defconfig using a known good version (SDP defconfig from v2.6.26-omap2 and current beagle defconfig) as reference. The image size is now 1.9 MB down from 2.4 MB earlier, and the number of modules is 8, down from 203. Build time also scales proportionally. Other support (OneNAND, etc) can be enabled as needed. Note that this patch intentionally does not update CONFIG_FB related options to avoid merge conflicts with the pending omap_dss2 patches. Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Signed-off-by:
-
vikram pandita authored
Remove the SYSFS_DEPRECATED flag from OMAP3 board defconfigs This is a deprecated feature no longer needed. Signed-off-by:
Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by:
-
Charulatha V authored
This patch disables a GPIO module when all pins of a GPIO module are inactive (clock gating forced at module level) and enables the module when any gpio in the module is requested. The module is enabled only when "mod_usage" indicates that no GPIO in that module is currently active and the GPIO being requested is the 1st one to be active in that module. Each module would be disabled in omap_gpio_free() API when all GPIOs in a particular module becomes inactive. The module is re-enabled in omap_gpio_request() API when a GPIO is requested from the module that was previously disabled. Since individual GPIO's bookkeeping is added in this patch via "mod_usage", the same is used in omap_set_gpio_debounce() & omap_set_gpio_debounce_time() APIs to ensure that the gpio being used is actually "requested" prior to being used (Nishant Menon's <nm@ti.comSuggestion) GPIO module level details are specific to hardware and hence introducing this patch in low level layer (plat-omap/gpio.c) Signed-off-by:
Charulatha V <charu@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Felipe Balbi authored
Cleanup the coding style in id.c while avoiding unneeded switch() statements. Signed-off-by:
Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
-
C A Subramaniam authored
This patch uses a tasklet implementation for sending mailbox messages. Signed-off-by:
C A Subramaniam <subramaniam.ca@ti.com> Signed-off-by:
Ramesh Gupta G <grgupta@ti.com> Signed-off-by:
Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by:
-
C A Subramaniam authored
Currently, this facilitates both the tesla and ducati sides to request for the same irq through an omap_mbox_get() call. Signed-off-by:
-
C A Subramaniam authored
This patch adds code changes in the mailbox driver module to add support for OMAP4 mailbox. Signed-off-by:
Hari Kanigeri <h-kanigeri2@ti.com> Signed-off-by:
-
Hiroshi DOYU authored
Expose omap_mbox_enable()/disable_irq() Signed-off-by: -
C A Subramaniam authored
Also removed from tx_data Signed-off-by:
-
Hiroshi DOYU authored
No need to handle it in isr, since irq won't happen during isr. Signed-off-by:
-
Hiroshi DOYU authored
It's not used at present. Signed-off-by:
-
Hiroshi DOYU authored
Any protocol should be handled in the upper layer and mailbox driver shouldn't care about the contents of messages. Signed-off-by:
-
C A Subramaniam authored
This patch adds resource information of mailbox driver for OMAP4 mailbox module. Register base address also added Signed-off-by:
-
C A Subramaniam authored
This patch adds changes to the build related files of mailbox driver Signed-off-by:
-
Julia Lawall authored
map_iovm_area is only called from a context where its second argument is known not to be NULL, so drop the unnecessary test. If new could be NULL, the initialization of da should be moved below the test. A simplified version of the semantic match that detects this problem is as follows (http://coccinelle.lip6.fr/): // <smpl> @match exists@ expression x, E; identifier fld; @@ * x->fld ... when != \(x = E\|&x\) * x == NULL // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Cc: Russell King <linux@arm.linux.org.uk> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Paul Walmsley authored
All of the OMAP3 IVA physical address macros in plat-omap/include/plat/omap34xx.h are wrong[1]: OMAP34XX_IVA_INTC_BASE: The IVA interrupt controller does not appear to be accessible from the L3 interconnect, and in any case is definitely not at 0x40000000; the latter address appears to be the internal IVA physical address base for the OMAP2420's interrupt control[2]. OMAP34XX_DSP_BASE: The section of L3 physical address space mapped to the IVA starts at 0x5c000000, not 0x58000000. OMAP34XX_DSP_MEM_BASE: It's not clear what this refers to, but it's not in the L3 IVA address space. OMAP34XX_DSP_IPI_BASE: The Intrusive Port Interface is a relic from the OMAP2420 days and no longer applies to OMAP3. OMAP34XX_DSP_MMU_BASE: The DSP MMU is mapped at 0x5d000000, not 0x5a000000. Nothing that uses these can possibly be working, so drop them. When future code needs these, correct versions can be added in. 1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. W, Table 2-8: "L3 Interconnect View of the IVA2.2 Subsystem Memory Space." p. 229. 2. OMAP2420 Multimedia Processor Silicon Revision 2.1.1, 2.2 (Rev. Q), section 2.2.4.1, "IVA Memory Space Seen by L3", p. 132. 3. ibid., section 4.3.11, "DSP IPI Overview", p. 200. Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Kevin Hilman authored
When listing the various SoC features, print them on the same line. So, instead of this OMAP3430/3530 ES3.1 - l2cache : Y - iva : Y - sgx : Y - neon : Y - isp : Y you get this: OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) Signed-off-by:
-
Nishanth Menon authored
omap3_check_revision() does not depend on omap3_check_features() move this above so that we can add logic based on revision detected in check_features. Signed-off-by:
Mika Westerberg <mika.westerberg@iki.fi> Signed-off-by:
-
Sriram authored
For ease of use it is preferrable to build in HSMMC driver rather than build it as kernel module. This patches updates default configuration for omap3evm to reflect this change. Signed-off-by:
-
Madhu authored
Add support for omap hsmmc2 8-bit mux configuration. Signed-off-by:
Madhusudhan Chikkature <madhu.cr@ti.com> Signed-off-by:
-
Madhu authored
The speed ctrl bit for MMC I/O is part of CONTROL_PROG_IO1 register in omap3630.This patch sets it up accordingly. Signed-off-by:
-
Madhu authored
The HSMMC1 controller on omap3630 supprts only 4-bit mode. If cpu is 3630 configure HSMMC1 wires to 4-bit. Signed-off-by:
-
Madhu authored
Change the cpu_is_omap3430() check to cpu_is_omap34xx() to allow HSMMC1/2 mux configuration for omap3630. Signed-off-by:
-
Peter Ujfalusi authored
The use of the spin lock, which supposed to protect the the dma_op_mode causing "INFO: inconsistent lock state" on playback start. Remove the spin locks around the dma_op_mode, when it's purpuse is to protect the dma_op_mode. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by:
Jarkko Nikula <jhnikula@gmail.com> Signed-off-by:
-
Felipe Contreras authored
This way it's more object oriented and easier to see what is happening. No functional changes. Signed-off-by:
Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by:
-
Hiroshi DOYU authored
Cache flush operation is handled in the upper client layer and iovmm modules doesn't have to care about it. This patch will improve some performance with current camera isp driver. Signed-off-by:
-
Hiroshi DOYU authored
MPU side (v)-(p) mapping is necessary only if IOVMF_MMIO is set in "flags". Signed-off-by:
-
Felipe Balbi authored
Add platform init code for EHCI driver. Various fixes to the original patch by Ajay Kumar Gupta <ajay.gupta@ti.com> and Anand Gadiyar <gadiyar@ti.com>. Overo support added by Olof Johansson <olof@lixom.net> Beagle support added by Koen Kooi <koen@beagleboard.org> CM-T32 support added by Mike Rapoport <mike@compulab.co.il> Signed-off-by:
Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by:
Steve Sakoman <steve@sakoman.com> Signed-off-by:
Koen Kooi <koen@beagleboard.org> Signed-off-by:
-
Anand Gadiyar authored
Add missing declarations to allow the recently introduced ehci-omap driver to build on OMAP3 Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ranjith Lohithakshan authored
AM35xx is functionally similar to OMAP3430 ES3.1 from a powerdomain/clockdomain perspective. This patch initializes the omap_chip bits on AM35xx for use by powerdomain and clockdomain code. Signed-off-by:
Ranjith Lohithakshan <ranjithl@ti.com> Signed-off-by:
-
Sanjeev Premi authored
Add support to detect AM3505/AM3517 devices at runtime. Also updates the CPU names printed during boot. Signed-off-by:
-
vikram pandita authored
3630 is getting treated like next rev of 3430 omap_chip.oc variable has to be updated for 3630 version Otherwise the Core power domain is not getting registered. This gets used in the registration of power domains in: "arch/arm/mach-omap2/powerdomains34xx.h" core_34xx_es3_1_pwrdm OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1) Core power doman will get registered for 3630 only when .oc is populated correctly. Tested on Zoom3(3630) board Signed-off-by:
Alexander Shishkin <virtuoso@slind.org> Acked-by:
Ari Kauppi <kauppi@papupata.org> Acked-by:
-
Nishanth Menon authored
OMAP3630 is the latest in the family of OMAP3 devices and among the changes it introduces are: New OPP levels for new voltage and frequency levels. a bunch of Bug fixes to various modules feature additions, notably with ISP, sDMA etc. Details about the chip is available here: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12836&contentId=52606 Strategy used: Strategy to introduce this device into Linux was discussed here: Ref: http://marc.info/?t=125343303400003&r=1&w=2 Two approaches were available: a) Consider 3630 generation of devices as a new family of silicon b) Consider 3630 as an offshoot of 3430 family of devices As a common consensus, (b) seems to be more valid for 3630 as: * There are changes which are easily handled by using "FEATURES" infrastructure. For details how to do this, see thread: http://marc.info/?t=125050998500001&r=1&w=2 * Most of existing 34xx infrastructure can be reused(almost 90%+) - so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx()) all over the place - lesser chance of bugs due to reuse of proven code flow - 36xx specific handling can still be done where required within the existing infrastructure NOTE: * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be added on top of the existing 3630 ones are renumbered This patch was tested on SDP3430, boot tested on 3630 platform using 3430sdp defconfig Signed-off-by:
-
Sanjeev Premi authored
Add runtime check for these OMAP35x variations based on the detected Si features: OMAP3503, OMAP3515, OMAP3525 and OMA3530. Also, delayed the call to pr_info() into actual variant is detected in omap3_cpuinfo() Signed-off-by:
-
