summaryrefslogtreecommitdiffstats
path: root/arch/arm/include/asm/arch-omap4
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP4: Panda: rework DMM logicNishanth Menon2015-01-051-0/+3
| | | | | | | | | | | | | | | Part of DMM logic is reuse from commit 47a4bea6af77b01d59a410d09a4c34b2dd14cf50 ("ARM: omap4: Update sdram setting for panda rev A6") Which broke SDP4430 with ES2.3 (uses old DDR). So, to maintain support for newer DDR used in Panda ES rev B3, we should, in addition to the commit 675cc77a3ae45e8b0ec17128563264d4a509f628 ("ARM:OMAP4+: panda-es: Support Rev B3 Elpida DDR2 RAM"), DDR timings, also do DMM configuration specific to Panda. Signed-off-by: Nishanth Menon <nm@ti.com>
* armv7:TI: Add <asm/ti-common/sys_proto.h> and migrate omap_hw_init_contextTom Rini2014-05-231-50/+1
| | | | | | | | | | | | | The omap_hw_init_context function (and assorted helpers) is the same for all OMAP-derived parts as when CHSETTINGS are used, that's the same and our DDR base is also always the same. In order to make this common we simply need to update the names of the define for DDR address space which is also common. Cc: Sricharan R. <r.sricharan@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
* ARM: omap4: add platform specific info for GPMC and ELM controllerspekon gupta2014-05-234-6/+90
| | | | | | | | | | | | | | | | This patch moves platform specific information for GPMC and ELM controller into separate header files, so that any derivative devices do not mess other header files. Platform specific information added into arch-xx/../hardware.h - CPU related platform specific details like base-address of GPMC and ELM Platform specific information added into arch-xx/../mem.h - Generic configs for GPMC and ELM initialization. - Hardware parameters or constrains specific to GPMC and ELM IP like; number of max number of chip-selects available Signed-off-by: Pekon Gupta <pekon@ti.com>
* ARM: OMAP: hide custom bit manipulation function sr32()Wolfgang Denk2014-04-171-1/+0
| | | | | | | | | | The only remaining user of the custom bit manipulation function sr32() is arch/arm/cpu/armv7/omap3/clock.c, so make it a static function in that file to prepare complete removal. Signed-off-by: Wolfgang Denk <wd@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
* spl: Fix guardian macros in spl.hMarek Vasut2014-03-281-1/+1
| | | | | | | | | Fix the macros guarding the spl.h header for various platforms. Due to a typo and a propagation of it, the macros went out-of-sync with their ifdef check, so fix this. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com>
* mtd: nand: omap: move omap_gpmc.h from arch/arm/include/asm to drivers/mtd/nandpekon gupta2014-03-041-1/+1
| | | | | | | | | omap_gpmc.h is a generic header used by OMAP NAND driver for all TI platfoms. Hence this file should be present in generic folder instead of architecture specific include folder. Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: merge duplicate GPMC data from different arch-xx headers ↵pekon gupta2014-03-042-45/+1
| | | | | | | | | | | | | | | into common omap_gpmc.h Each SoC platform (AM33xx, OMAP3, OMAP4, OMAP5) has its own copy of GPMC related defines and declarations scattered in SoC platform specific header files like include/asm/arch-xx/cpu.h However, GPMC hardware remains same across all platforms thus this patch merges GPMC data scattered across different arch-xx specific header files into single header file include/asm/arch/omap_gpmc.h Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
* ARM: OMAP4/5: Remove dead code against CONFIG_SYS_ENABLE_PADS_ALLJassi Brar2014-01-241-1/+0
| | | | | | | | | The commit f3f98bb0 : "ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls" removed the config option aimed towards moving that stuff into kernel, which renders some code unreachable. Remove that code. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
* ARM: OMAP4: Move TEXT_BASE down to non-HS limitLokesh Vutla2013-12-121-1/+1
| | | | | | | | | | | | | | | With the current scenario SPL size is being overlapped with the public stack and not allowing any OMAP4 device to boot. So the suggestion came up was to move the TEXT_BASE down to non-HS limit. Fixing the same and also moving the SRAM_SCRATCH_SPACE_ADDR up to the end of image downloadable area. Discussion on this can be seen here: https://www.mail-archive.com/u-boot@lists.denx.de/msg127147.html Tested on OMAP4460 PANDA. Reported-by: Chao Xu <caesarxuchao@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* pandaboard: 1/1] ARM:OMAP4+: panda-es: Support Rev B3 Elpida DDR2 RAMHardik Patel2013-12-041-0/+4
| | | | Signed-off-by: Hardik Patel <hardik.patel@volansystech.com>
* ARM: omap4-panda: Add MAC address creation for pandaDan Murphy2013-10-141-0/+4
| | | | | | | | Add a MAC address create based on the OMAP die ID registers. Then poplulate the ethaddr enviroment variable so that the device tree alias can be updated prior to boot. Signed-off-by: Dan Murphy <dmurphy@ti.com>
* Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'Albert ARIBAUD2013-09-042-1/+7
|\
| * ARM: OMAP4470: Add voltage and dpll dataTaras Kondratiuk2013-08-281-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | OMAP4470 reference design uses TWL6032 PMIC with a following connection scheme: VDD_CORE = TWL6032 SMPS2 VDD_MPU = TWL6032 SMPS1 VDD_IVA = TWL6032 SMPS5 Set voltage and frequency values according to OMAP4470 Data Manual Operating Condition Addendum v0.7 Signed-off-by: Taras Kondratiuk <taras@ti.com>
| * ARM: OMAP4470: Add OMAP4470 identificationTaras Kondratiuk2013-08-281-0/+1
| | | | | | | | Signed-off-by: Taras Kondratiuk <taras@ti.com>
* | SPDX-License-Identifier: fixing some problematic GPL-2.0 filesWolfgang Denk2013-08-191-18/+1
|/ | | | | | | | | | | | | | | | | Unlike the other patches in this series so far, this commit fixes a ambiguity in the license terms for some OMAP files: the code was originally derived from the Linux kernel sources, where it was clearly marked as GPL-2.0 (i. e. without the "or later" part), but the U-Boot version had a GPL-2.0+ file header added, apparently without permission / relicensing from the original authors of the code. Insert a GPL-2.0 SPDX-License-Identifier to fix this. Signed-off-by: Wolfgang Denk <wd@denx.de> cc: Tom Rix <Tom.Rix@windriver.com> Cc: Tom Rini <trini@ti.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Acked-by: Tom Rini <trini@ti.com>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-247-117/+7
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* Merge branch 'master' of git://git.denx.de/u-boot-armTom Rini2013-07-121-0/+2
|\ | | | | | | | | | | | | | | | | | | Fix a trivial conflict in arch/arm/dts/exynos5250.dtsi about gpio and serial. Conflicts: arch/arm/dts/exynos5250.dtsi Signed-off-by: Tom Rini <trini@ti.com>
| * ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on OMAP5Axel Lin2013-07-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The omap_gpio driver is used by AM33XX, OMAP3/4, OMAP54XX and DRA7XX SoCs. These SoCs have different gpio count but currently omap_gpio driver uses hard coded 192 which is wrong. This patch fixes this issue by: 1. Move define of OMAP_MAX_GPIO to all arch/arm/include/asm/arch-omap*/gpio.h. 2. Update gpio bank settings and enable GPIO modules 7 & 8 clocks for OMAP5. Thanks for Lubomir Popov to provide valuable comments to fix this issue. Signed-off-by: Axel Lin <axel.lin@ingics.com> Tested-by: Lubomir Popov <lpopov@mm-sol.com> Acked-by: Heiko Schocher <hs@denx.de>
* | Merge branch 'master' of git://git.denx.de/u-boot-armTom Rini2013-06-134-57/+16
|\ \ | |/ | | | | | | | | | | | | | | Small conflict over DRA7XX updates and adding SRAM_SCRATCH_SPACE_ADDR Conflicts: arch/arm/include/asm/arch-omap5/omap.h Signed-off-by: Tom Rini <trini@ti.com>
| * ARM: DRA7xx: clocks: Update PLL valuesLokesh Vutla2013-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | Update PLL values. SYS_CLKSEL value for 20MHz is changed to 2. In other platforms SYS_CLKSEL value 2 represents reserved. But in sys_clk array ind 1 is used for 13Mhz. Since other platforms are not using 13Mhz, reusing index 1 for 20MHz. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Sricharan R <r.sricharan@ti.com>
| * ARM: DRA7xx: Correct the SYS_CLK to 20MHZSricharan R2013-06-101-0/+4
| | | | | | | | | | | | | | | | | | | | The sys_clk on the dra evm board is 20MHZ. Changing the configuration for the same. And also moving V_SCLK, V_OSCK defines to arch/clock.h for OMAP4+ boards. Signed-off-by: Sricharan R <r.sricharan@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
| * ARM: DRA7xx: power Add support for tps659038 PMICLokesh Vutla2013-06-101-0/+1
| | | | | | | | | | | | | | | | TPS659038 is the power IC used in DRA7XX boards. Adding support for this and also adding pmic data for DRA7XX boards. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
| * ARM: OMAP4+: pmic: Make generic bus init and write functionsLokesh Vutla2013-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | Voltage scaling can be done in two ways: -> Using SR I2C -> Using GP I2C In order to support both, have a function pointer in pmic_data so that we can call as per our requirement. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
| * ARM: OMAP2+: Rename asm/arch/clocks.h asm/arch/clock.hLokesh Vutla2013-06-102-1/+1
| | | | | | | | | | | | | | To be consistent with other ARM platforms, renaming asm/arch-omap*/clocks.h to asm/arch-omap*/clock.h Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
| * ARM: OMAP4+: Cleanup header filesLokesh Vutla2013-06-103-54/+0
| | | | | | | | | | | | | | After having the u-boot clean up series, there are many definitions that are unused in header files. Removing all those unused ones. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
| * OMAP3+: introduce generic ABB supportAndrii Tseglytskyi2013-06-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adaptive Body Biasing (ABB) modulates transistor bias voltages dynamically in order to optimize switching speed versus leakage. Adaptive Body-Bias ldos are present for some voltage domains starting with OMAP3630. There are three modes of operation: * Bypass - the default, it just follows the vdd voltage * Foward Body-Bias - applies voltage bias to increase transistor performance at the cost of power. Used to operate safely at high OPPs. * Reverse Body-Bias - applies voltage bias to decrease leakage and save power. Used to save power at lower OPPs. Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com> Acked-by: Nishanth Menon <nm@ti.com>
* | am33xx/omap4+: Move SRAM_SCRATCH_SPACE_ADDR to <asm/arch/omap.h>Tom Rini2013-06-061-0/+1
|/ | | | | | | | | | The location of valid scratch space is dependent on SoC, so move that there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR. On am33xx/ti814x we want to use what the ROM defines as "public stack" which is the area after our defined download image space. Correct the comment about and location of CONFIG_SPL_TEXT_BASE. Signed-off-by: Tom Rini <trini@ti.com>
* am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.cTom Rini2013-06-051-0/+1
| | | | | | | | | | | We need to call the save_omap_boot_params function on am33xx/ti81xx and other newer TI SoCs, so move the function to boot-common. Only OMAP4+ has the omap_hw_init_context function so add ifdefs to not call it on am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx boards. Reviewed-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Tom Rini <trini@ti.com>
* ARM: OMAP: Cleanup boot parameters usageSRICHARAN R2013-05-101-8/+3
| | | | | | | | | | | The boot parameters are read from individual variables assigned for each of them. This been corrected and now they are stored as a part of the global data 'gd' structure. So read them from 'gd' instead. Signed-off-by: Sricharan R <r.sricharan@ti.com> [trini: Add igep0033 hunk] Signed-off-by: Tom Rini <trini@ti.com>
* ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines commonSRICHARAN R2013-05-101-12/+0
| | | | | | | | These defines are same across OMAP4/5. So move them to omap_common.h. This is required for the patches that follow. Signed-off-by: Sricharan R <r.sricharan@ti.com>
* ARM: OMAP: Make omap_boot_parameters common across socsSRICHARAN R2013-05-101-24/+0
| | | | | | | | omap_boot_parameters is same and defined for each soc. So move this to a common place to reuse it across socs. Signed-off-by: Sricharan R <r.sricharan@ti.com>
* ARM: OMAP5: Fix warm reset with USB cable connectedLokesh Vutla2013-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Warm reset on OMAP5 freezes when USB cable is connected. Fix requires PRM_RSTTIME.RSTTIME1 to be programmed with the time for which reset should be held low for the voltages and the oscillator to reach stable state. There are 3 parameters to be considered for calculating the time, which are mostly board and PMIC dependent. -1- Time taken by the Oscillator to shut + restart -2- PMIC OTP times -3- Voltage rail ramp times, which inturn depends on the PMIC slew rate and value of the voltage ramp needed. In order to keep the code in u-boot simple, have a way for boards to specify a pre computed time directly using the 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC' option. If boards fail to specify the time, use a default as specified by 'CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC' instead. Using the default value translates into some ~22ms and should work in all cases. However in order to avoid this large delay hiding other bugs, its recommended that all boards look at their respective data sheets and specify a pre computed and optimal value using 'CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC' In order to help future board additions to compute this config option value, add a README at doc/README.omap-reset-time which explains how to compute the value. Also update the toplevel README with the additional option and pointers to doc/README.omap-reset-time. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [rnayak@ti.com: Updated changelog and added the README] Signed-off-by: Rajendra Nayak <rnayak@ti.com>
* OMAP3/4/5/AM33xx: Correct logic for checking FAT or RAW MMCTom Rini2013-04-081-0/+2
| | | | | | | | | | | | | | | In the case of booting from certain peripherals, such as UART, we must not see what the device descriptor says for RAW or FAT mode because in addition to being nonsensical, it leads to a hang. This is why we have a test currently for the boot mode being within range. The problem however is that on some platforms we get MMC2_2 as the boot mode and not the defined value for MMC2, and in others we get the value for MMC2_2. This is required to fix eMMC booting on omap5_uevm. Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC). Signed-off-by: Tom Rini <trini@ti.com>
* arm: omap4: Fix SDRAM AUTO DETECTIONLokesh Vutla2013-04-081-1/+0
| | | | | | | | | | | | | | Commit "8602114 omap: emif: configure emif only when required" breaks SDRAM_AUTO_DETECTION. The issue is dmm_init() depends on emif_sizes[](SDRAM Auto detection) done in do_sdram_init(). The above commit moves dmm_init() above do_sdram_init() because of which dmm_init() uses uninitialized emif_sizes[]. So instead of using global emif_sizes[], get sdram details locally and calculate emif sizes. Reported-by: Michael Cashwell <mboards@prograde.net> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* ARM: OMAP4+: Make control module register structure genericLokesh Vutla2013-03-111-29/+2
| | | | | | | | | | | | A seperate omap_sys_ctrl_regs structure is defined for omap4 & 5. If there is any change in control module for any of the ES versions, a new structure needs to be created. In order to remove this dependency, making the register structure generic for all the omap4+ boards. Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* ARM: OMAP4+: Clean up the pmic codeSRICHARAN R2013-03-112-6/+2
| | | | | | | | | | The pmic code is duplicated for OMAP 4 and 5. Instead move the data to Soc specific place and share the code. Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* ARM: OMAP4+: Cleanup the clocks layerSRICHARAN R2013-03-112-46/+2
| | | | | | | | | | | | | | | Currently there is quite a lot of code which is duplicated in the clocks code for OMAP 4 and 5 Socs. Avoiding this here by moving the clocks data to a SOC specific place and the sharing the common code. This helps in addition of a new Soc with minimal changes. Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* ARM: OMAP4+: Change the PRCM structure prototype common for all SocsSRICHARAN R2013-03-113-480/+49
| | | | | | | | | | | | The current PRCM structure prototype directly matches the hardware register layout. So there is a need to change this for every new silicon revision which has register space changes. Avoiding this by making the prototye generic and populating the register addresses seperately for all Socs. Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* SPL: ONENAND: Fix some ONENAND related defines.Enric Balletbo i Serra2013-03-081-1/+1
| | | | | | | | Some ONENAND related defines use the term ONE_NAND instead of ONENAND, as the technology name is ONENAND this patch replaces all these defines. Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
* omap: consolidate common mmc definitionsNikita Kiryanov2013-03-081-138/+2
| | | | | | | | | The various mmc_host_def.h files are almost identical. Reduce code duplication by moving the similar definitions to a common header file. Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
* ARM: SPL: Add <asm/spl.h> and <asm/arch/spl.h>Tom Rini2012-09-271-0/+35
| | | | | | | Move the SPL prototypes from <asm/omap_common.h> into <asm/spl.h> and add <asm/arch/spl.h> for arch specific portions of CONFIG_SPL_FRAMEWORK. Signed-off-by: Tom Rini <trini@ti.com>
* omap-common: SPL: Add CONFIG_SPL_DISPLAY_PRINT / spl_display_print()Tom Rini2012-09-271-1/+0
| | | | | | | | Only omap4/5 currently have a meaningful set of display text and overo had been adding a function to display nothing. Change how this works to be opt-in and only turned on for omap4/5 now. Signed-off-by: Tom Rini <trini@ti.com>
* omap4 i2c: add support for i2c bus 4Koen Kooi2012-09-062-1/+2
| | | | Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
* omap4/5/am33xx: Make lowlevel_init available to all armv7 platformsTom Rini2012-09-011-1/+0
| | | | | | | | | | | | | | Make the lowlevel_init function that these platforms have which just sets up the stack and calls a C function available to all armv7 platforms. As part of this we change some of the macros that are used to be more clear. Previously (except for am335x evm) we had been setting CONFIG_SYS_INIT_SP_ADDR to a series of new defines that are equivalent to simply referencing NON_SECURE_SRAM_END. On am335x evm we should have been doing this initially and do now. Cc: Sricharan R <r.sricharan@ti.com> Tested-by: Allen Martin <amartin@nvidia.com> Signed-off-by: Tom Rini <trini@ti.com>
* OMAP4+: Force DDR in self-refresh after warm resetLokesh Vutla2012-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Errata ID:i727 Description: The refresh rate is programmed in the EMIF_SDRAM_REF_CTRL[15:0] REG_REFRESH_RATE parameter taking into account frequency of the device. When a warm reset is applied on the system, the OMAP processor restarts with another OPP and so frequency is not the same. Due to this frequency change, the refresh rate will be too low and could result in an unexpected behavior on the memory side. Workaround: The workaround is to force self-refresh when coming back from the warm reset with the following sequence: • Set EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE to 0x2 • Set EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM to 0x0 • Do a dummy read (loads automatically new value of sr_tim) This will reduce the risk of memory content corruption, but memory content can't be guaranteed after a warm reset. This errata is impacted on OMAP4430: 1.0, 2.0, 2.1, 2.2, 2.3 OMAP4460: 1.0, 1.1 OMAP4470: 1.0 OMAP5430: 1.0 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
* ARM: OMAP3+: Detect reset typeLokesh Vutla2012-07-072-0/+3
| | | | | | | | | | | | Certain modules are not affected by means of a warm reset and need not be configured again. Adding an API to detect the reset reason warm/cold. This will be used to skip the module configurations that are retained across a warm reset. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: R Sricharan <r.sricharan@ti.com>
* ARM: OMAP4: Correct the lpddr2 io settings register value.SRICHARAN R2012-07-071-1/+1
| | | | | | | | | | To meet certain timing requirements on the lpddr2 cmd and data phy interfaces ,lpddr iopads have to be configured as differential buffers and a Vref has to be internally generated and provided to these buffers. Correcting the above settings here. Signed-off-by: R Sricharan <r.sricharan@ti.com>
* OMAP5: DPLL core lock for OMAP5432Lokesh Vutla2012-07-071-0/+5
| | | | | | | No need to Unlock DPLL initially. DDR3 can work at normal OPP from initialozation Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* omap4+: Avoid using __attribute__ ((__packed__))Aneesh V2012-05-151-1/+1
| | | | | | | | | | | | | Avoid using __attribute__ ((__packed__)) unless it's absolutely necessary. "packed" will remove alignment requirements for the respective objects and may cause alignment issues unless alignment is also enforced using a pragma. Here, these packed attributes were causing alignment faults in Thumb build. Signed-off-by: Aneesh V <aneesh@ti.com>
* OMAP3+: reset: Create a common reset layer.SRICHARAN R2012-05-152-11/+11
| | | | | | | | | The reset.S has the function to do a warm reset on OMAP based socs. Moving this to a reset.c file so that this acts a common layer to add any reset related functionality for the future. Signed-off-by: R Sricharan <r.sricharan@ti.com>
OpenPOWER on IntegriCloud