summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/mux.c
AgeCommit message (Collapse)Author
2011-08-10arm: mach-omap2: mux: use kstrdup()Thomas Meyer
Use kstrdup rather than duplicating its implementation The semantic patch that makes this output is available in scripts/coccinelle/api/kstrdup.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/ Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-06-01ARM: omap2+: mux: Allow board mux settings to be NULLColin Cross
OMAP4 has two mux instances, and the board may not have settings for one of them. Allow the board file to pass NULL for an instance's mux settings, which will initialize the mux instance but skip writing board settings. Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-06-01OMAP2+: mux: fix compilation warningsGovindraj.R
Fix below compilation warnings. arch/arm/mach-omap2/omap_hwmod.c: In function 'omap_hwmod_for_each': arch/arm/mach-omap2/omap_hwmod.c:1631: warning: 'ret' may be used uninitialized in this function arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_gpio': arch/arm/mach-omap2/mux.c:917: warning: 'm' may be used uninitialized in this function Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-11omap2+: mux: Remove the use of IDLE flagR Sricharan
Currently OMAP_DEVICE_PAD_IDLE flag is used to mux pins dynamically. This can be simplified by using the enabled state variable of each pad. This also fixes the issue of the static pads not getting muxed after idling and disable/enable state transitions. Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-11omap2+: Add separate list for dynamic pads to muxTony Lindgren
This avoids going through the list unnecessarily when idling devices for runtime PM. Based on an earlier patch by sricharan <r.sricharan@ti.com>. Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-04mach-omap2: mux: world-writable debugfs filesVasiliy Kulikov
Do not create mux debugfs files as world-writable. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-01arm: mach-omap2: mux: free allocated memory on error exitAaro Koskinen
Free allocated memory on error exit. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-01-28arm: omap2: mux: fix compile warningFelipe Balbi
Commit 8419fdbaf2118a0a169441be82f09f7be93a5ca1 (omap2+: Add omap_mux_get_by_name) introduced the following compile warning: arch/arm/mach-omap2/mux.c: In function '_omap_mux_get_by_name': arch/arm/mach-omap2/mux.c:163:17: warning: 'found_mode' may be used uninitialized in this function Signed-off-by: Felipe Balbi <balbi@ti.com> [tony@atomide.com: updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-01-07arm: mach-omap2: mux: fix buffer overrunAaro Koskinen
memcpy() copies 8 bytes too much (omap_mux_entry vs. omap_mux). Correct by replacing memcpy() with struct assignment, which is safer. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-23omap2+: Allow hwmod state changes to mux pads based on the state changesTony Lindgren
Allow hwmod state changes to mux pads based on the state changes. By default, only enable and disable the pads. In some rare cases dynamic remuxing for the idles states is needed, this can be done by passing the enable, idle, and off pads from board-*.c file along with OMAP_DEVICE_PAD_REMUX flag. Thanks to Paul Walmsley <paul@booyaka.com> for the comments on the hwmod related changes. Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-23omap2+: Add support for hwmod specific muxing of devicesTony Lindgren
This allows adding hwmod specific pads dynamically during the platform device init. Note that we don't currently have the hwmod specific signals listed in the hwmod data, but struct omap_hwmod_mux_info will make that possible if necessary. Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-23omap2+: Add omap_mux_get_by_nameTony Lindgren
Do this by splitting _omap_mux_init_signal as it already has most of the necessary features. Based on an earlier patch by Dan Murphy <dmurphy@ti.com>. Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-11-17OMAP: mux: Add __func__ macro to pr_xxx macrosDan Murphy
Removed mux: and added the __func__ macro to make debugging easier. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com>
2010-11-17OMAP: mux: Add support for control module split in several partitionsBenoit Cousson
Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time depending of Soc partitioning. - Add some init flags as well in order to avoid explicit Soc version check inside the mux core code. - Add a comment with mux0 mode on top of omap_mux/board/<partition> if the current mux mode is not the default one. Thanks to Tony Lindgren <tony@atomide.com> for the following improvements: - Add omap_mux_get for getting the partition data so platform level device code can use it. - Fix the rx51 board code to use the new API. - Do not store the partition for each mux entry. Look up the partition for debugfs instead. Thanks to Dan Murphy <dmurphy@ti.com> for testing on OMAP4 and reporting a couple of bugs. Thanks to Anand Gadiyar <gadiyar@ti.com> for testing on OMAP3 zoom and bug report. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Murphy Dan <dmurphy@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Anand Gadiyar <gadiyar@ti.com>
2010-11-17OMAP: mux: Replace printk with pr_xxx macrosBenoit Cousson
Replace all the printk(KERN_XXX... with pr_xxx macros. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-10-08OMAP: control: move plat-omap/control.h to mach-omap2/control.hPaul Walmsley
Only OMAP2+ platforms have the System Control Module (SCM) IP block. In the past, we've kept the SCM header file in plat-omap. This has led to abuse - device drivers including it; includes being added that create implicit dependencies on OMAP2+ builds; etc. In response, move the SCM headers into mach-omap2/. As part of this, remove the direct SCM access from the OMAP UDC driver. It was clearly broken. The UDC code needs an indepth review for use on OMAP2+ chips. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Cory Maccarrone <darkstar6262@gmail.com> Cc: Kyungmin Park <kyungmin.park@samsung.com>
2010-10-01omap: Fix omap_mux_init_signal not to trash muxnameTony Lindgren
Otherwise the muxname passed to the function will get truncated. Based on an earlier patch by rockefeller.lin@innocomm.com. Reported-by: rockefeller.lin@innocomm.com Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-09-24omap2: fix assorted compiler warningsSanjeev Premi
This patch fixes these compiler warnings: CC arch/arm/mach-omap2/mux.o arch/arm/mach-omap2/mux.c: In function 'omap_mux_init_gpio': arch/arm/mach-omap2/mux.c:90: warning: 'gpio_mux' may be used uninitial ized in this function CC arch/arm/plat-omap/gpio.o arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_resume_after_idle': arch/arm/plat-omap/gpio.c:2152: warning: 'l' may be used uninitialized in this function arch/arm/plat-omap/gpio.c: In function 'omap2_gpio_prepare_for_idle': arch/arm/plat-omap/gpio.c:2085: warning: 'l2' may be used uninitialized in this function arch/arm/plat-omap/gpio.c:2085: warning: 'l1' may be used uninitialized in this function CC arch/arm/mach-omap2/board-omap4panda.o arch/arm/mach-omap2/board-omap4panda.c: In function 'omap4_panda_init': arch/arm/mach-omap2/board-omap4panda.c:277: warning: unused variable 's tatus' Signed-off-by: Sanjeev Premi <premi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-08-02omap: mux: fix multipath gpio handlingGrazvydas Ignotas
OMAP3530 CBB package can have GPIO126 muxed on 2 pins: mmc1_dat4 and cam_strobe. This causes a problem with current multipath GPIO mux handling, which muxes both pins as GPIO126 and makes the GPIO unusable. Fix this by not muxing any pins if multipath GPIO is detected and just print a warning instead. It's up to board files to set correct mux using omap_mux_init_signal and pin name. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-07-05omap: mux: Remove old mux codeTony Lindgren
All mach-omap2 omaps should now use the new mux code. Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-07-05omap: mux: Allow compiling in new mux code on all mach-omap2 systemsTony Lindgren
Allow compiling in new mux code on all mach-omap2 systems Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-07-05omap: mux: Fix omap_mux_init_gpio for omap24xxTony Lindgren
Looks like 24xx uses mode3 instead of mode4 for muxable GPIO pins. This will be needed when 24xx mux code is converted to use the new mux functions. Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-02-17Merge branch 'omap-fixes-for-linus' into omap-for-linusTony Lindgren
2010-02-17omap: Remove DEBUG_FS dependency for mux name checkingRanjith Lohithakshan
The check for a valid mux name should be performed regardless of whether DEBUG_FS is enabled or not. Otherwise without DEBUG_FS, we get: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.33-rc8 #10) PC is at strcmp+0x18/0x40 LR is at omap_mux_init_signal+0x68/0x14c ... This fixes the issue currently seen with boards not booting up if DEBUG_FS is not enabled in defconfig. Note that the earlier ifndef + ifdef now becomes simpler ifdef else: If CONFIG_OMAP_MUX is selected, we use pin names. If it's not selected, we only want the GPIO to mux register mapping. Signed-off-by: Ranjith Lohithakshan <ranjithl@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-02-15omap3: Clean-up for omap_mux_initTony Lindgren
Get rid of the ifdeffery in omap_mux_init by creating omap_mux_init_package and omap_mux_init_signals functions. Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-02-15omap3: Replace ARCH_OMAP34XX with ARCH_OMAP3Tony Lindgren
Replace ARCH_OMAP34XX with ARCH_OMAP3 Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-02-15omap2: Convert ARCH_OMAP24XX to ARCH_OMAP2Tony Lindgren
Convert ARCH_OMAP24XX to ARCH_OMAP2 Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-02-03omap: Fix arch/arm/mach-omap2/mux.c: Off by one errorTony Lindgren
David Binderman ran the sourceforge tool cppcheck over the source code of the new Linux kernel 2.6.33-rc6: [./arm/mach-omap2/mux.c:492]: (error) Buffer access out-of-bounds 13 characters + 1 digit + 1 zero byte is more than 14 characters. Also add a comment on mode0 name length in case new omaps start using longer names. Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-02-03omap: Fix 3630 mux errorsTony Lindgren
3630 has more mux signals than 34xx. The additional pins exist in omap36xx_cbp_subset, but are not initialized as the superset is missing these offsets. This causes the following errors during the boot: mux: Unknown entry offset 0x236 mux: Unknown entry offset 0x22e mux: Unknown entry offset 0x1ec mux: Unknown entry offset 0x1ee mux: Unknown entry offset 0x1f4 mux: Unknown entry offset 0x1f6 mux: Unknown entry offset 0x1f8 mux: Unknown entry offset 0x1fa mux: Unknown entry offset 0x1fc mux: Unknown entry offset 0x22a mux: Unknown entry offset 0x226 mux: Unknown entry offset 0x230 mux: Unknown entry offset 0x22c mux: Unknown entry offset 0x228 Fix this by adding the missing offsets to omap3 superset. Note that additionally the uninitialized pins need to be skipped on 34xx. Based on an earlier patch by Allen Pais <allen.pais@ti.com>. Reported-by: Allen Pais <allen.pais@ti.com> Signed-off-by: Allen Pais <allen.pais@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-01-20omap: Fix functions for dynamic remuxing of pinsTony Lindgren
Make the omap_mux_read and write available for board code, and rename omap_mux_set_board_signals into omap_mux_write_array. Also add the related prototypes and comments into mux.h. In some cases we want to change the signals dynamically, mostly for power management. Note that we cannot use the signal names as they are set __init to save memory. Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-01-20omap: Fix cmdline muxingTony Lindgren
Looks like cmdline muxing got broken at some point when we decided to limit muxing to __init code. Currently omap_mux_entry list is not yet initialized when we try to initialize cmdline muxing. Fix this by calling omap_mux_init_list() before calling omap_mux_set_cmdline_signals(). Reported-by: Philip Balister <philip@balister.org> Tested-by: Philip Balister <philip@balister.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-01-08omap3: Fix booting if package is uninitializedTony Lindgren
Otherwise bringing up new boards can be harder: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.33-rc2-00015-g0bc9c93-dirty #37) PC is at omap_mux_init+0xa4/0x3d8 LR is at omap_mux_init+0x3c/0x3d8 ... Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-12-12omap: mux: Remove old mux code for 34xxTony Lindgren
Remove old mux code for 34xx Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-12-12omap: mux: Add debugfs support for new mux codeTony Lindgren
Add debugfs support for new mux code Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-12-12omap: mux: Add new style pin multiplexing code for omap3Tony Lindgren
Initially only for 34xx. This code allows us to: - Make the code more generic as the omap internal signal names can stay the same across omap generations for some devices - Map mux registers to GPIO registers that is needed for dynamic muxing of pins during off-idle - Override bootloader mux values via kernel cmdline using omap_mux=some.signa1=0x1234,some.signal2=0x1234 - View and set the mux registers via debugfs if CONFIG_DEBUG_FS is enabled Cc: Mike Rapoport <mike@compulab.co.il> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-12-12omap2: mux: intoduce omap_mux_{read,write}Mike Rapoport
intoduce omap_mux_{read,write} Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-11-22omap3evm: ehci: Update EHCI support on OMAP3EVM (Rev >= E)Ajay Kumar Gupta
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>
2009-11-22omap3: HSMMC2 8-bit mux configurationMadhu
Add support for omap hsmmc2 8-bit mux configuration. Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-10-20omap: headers: Move remaining headers from include/mach to include/platTony Lindgren
Move the remaining headers under plat-omap/include/mach to plat-omap/include/plat. Also search and replace the files using these headers to include using the right path. This was done with: #!/bin/bash mach_dir_old="arch/arm/plat-omap/include/mach" plat_dir_new="arch/arm/plat-omap/include/plat" headers=$(cd $mach_dir_old && ls *.h) omap_dirs="arch/arm/*omap*/ \ drivers/video/omap \ sound/soc/omap" other_files="drivers/leds/leds-ams-delta.c \ drivers/mfd/menelaus.c \ drivers/mfd/twl4030-core.c \ drivers/mtd/nand/ams-delta.c" for header in $headers; do old="#include <mach\/$header" new="#include <plat\/$header" for dir in $omap_dirs; do find $dir -type f -name \*.[chS] | \ xargs sed -i "s/$old/$new/" done find drivers/ -type f -name \*omap*.[chS] | \ xargs sed -i "s/$old/$new/" for file in $other_files; do sed -i "s/$old/$new/" $file done done for header in $(ls $mach_dir_old/*.h); do git mv $header $plat_dir_new/ done Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-09-24omap: Fix MMC gpio_wp for BeagleBoard C2 and aboveJarkko Nikula
Earlier BeagleBoards were using pad AH8 muxed to GPIO29 for MMC write-protect. However, this signal has been changed to pad AG9 in board revision C2. Fix this by adding mux configuration for pad AG9, runtime check for board revisions and set the gpio number and pad muxing accordingly. Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-09-24omap: Add missing mux pin for EHCI phy reset lineAjay Kumar Gupta
GPIO135 is used as EHCI (port2) phy reset pin on Multi Media Daughter card connected to OMAP3EVM. Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-09-02OMAP3: PM: add T2 interrupt line mux setting, and enable on 3430SDPReddy, Teerth
This patch changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup issue on OMAP3 SDP. Signed-off-by: Teerth Reddy <teerth@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-28OMAP3: MMC: Add mux for pinsVikram Pandita
For OMAP3 add MMC1 MMC2 pin mux MMC3 mux is not added as there are multiple configurations possible, so the muxing is left to be done in board file. Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-07-25OMAP3: Setup MUX settings for SDRC CKE signalsJean Pihet
This patches ensures the MUX settings are correct for the SDRC CKE signals to SDRAM. This allows the self-refresh to work when 2 chip-selects are in use. A warning is thrown away in case the initial muxing is incorrect, in order to track faulty or old-dated bootloaders. Note: The CONFIG_OMAP_MUX and CONFIG_OMAP_MUX_WARNINGS options must be enabled for the mux code to have effect. Signed-off-by: Jean Pihet <jpihet@mvista.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2009-03-24ARM: OMAP3: Add more GPIO mux optionsTony Lindgren
This patch adds several new GPIO pins and updates the pin naming comments. The patch is based on earlier patches on linux-omap list by Manikandan Pillai <mani.pillai@ti.com>, Vaibhav Hiremath <hvaibhav@ti.com> and David Brownell <dbrownell@users.sourceforge.net>. Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-12-11ARM: OMAP3: Pin multiplexing updates for 24xx and 34xxArun KS
This patch adds some new pin multiplexing options for McBSP and McSPI from Arun KS. Also add two more GPIOs from David Brownell. Also mark omap24xx_cfg_reg() static. Signed-off-by: Arun KS <arunks@mistralsolutions.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2008-10-14Merge branch 'omap-all' into develRussell King
Conflicts: arch/arm/mach-omap2/gpmc.c arch/arm/mach-omap2/irq.c
2008-10-09ARM: OMAP3: Add minimal omap3430 supportSyed Mohammed, Khasim
Add minimal omap3430 support based on earlier patches from Syed Mohammed Khasim. Also merge in omap34xx SRAM support from Karthik Dasu and use consistent naming for sram init functions. Also do following changes that make 34xx support usable: - Remove unused sram.c functions for 34xx - Rename IRQ_SIR_IRQ to INTCPS_SIR_IRQ and define it locally in entry-macro.S - Update mach-omap2/io.c to support 2420, 2430, and 34xx - Also merge in 34xx GPMC changes to add fields wr_access and wr_data_mux_bus from Adrian Hunter - Remove memory initialization call omap2_init_memory() until until more generic memory initialization patches are posted. It's OK to rely on bootloader initialization until then. Signed-off-by: Syed Mohammed, Khasim <khasim@ti.com> Signed-off-by: Karthik Dasu<karthik-dp@ti.com> Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>