- 13 5月, 2010 3 次提交
-
-
由 Kevin Hilman 提交于
Currently, the GPIO 'prepare' hook is only called when going to off-mode, while the function is called 'prepare_for_retention.' This patch renames the function to 'prepare_for_idle' and calls it for any powersate != PWRDM_POWER_ON passing in the powerstate. The hook itself is then responsible for doing various preparation based on the powerstate. Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Chunqiu Wang 提交于
According to the GPIO 'Wakeup and Interrupt' section of the TRM[1], wake-up requests can only be generated on edge transitions. Also for OMAP3, only edge GPIOs may lose interrupts when PER enters RET/OFF state, this is addressed by gpio prepare|resume idle functions [1] Section 25.5.3.1 OMAP34xx_ES3.1_TRM_V_Q Signed-off-by: NChunqiu Wang <cqwang@motorola.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Tero Kristo 提交于
Off mode is now using the omap2 retention fix code for scanning GPIOs during off-mode transitions. All the *non_wakeup_gpios variables are now used for off-mode transition tracking on OMAP3. This patch fixes cases where GPIO state changes are missed during off-mode. Signed-off-by: NTero Kristo <tero.kristo@nokia.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 01 5月, 2010 1 次提交
-
-
由 Ajay Kumar Gupta 提交于
MUSB can supply upto 500mA such as, AM3517 and OMAP3EVM Rev >=E and thus the 'power' field has to hold values above 255. Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 24 4月, 2010 5 次提交
-
-
由 Aaro Koskinen 提交于
They are not needed and add over 512 bytes to kernel data. Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Santosh Shilimkar 提交于
This patch fixes the McBSP4 base address for OMAP4 Signed-off-by: NBalaji T K <balajitk@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 stanley.miao 提交于
INT_34XX_BENCH_MPU_EMUL was defined twice, another is at Line 312. Signed-off-by: NStanley.Miao <stanley.miao@windriver.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 stanley.miao 提交于
If CONFIG_MTD_NAND_OMAP2 is not enabled, there will be a compile error, "gpmc_nand_init() is not defined". Add a inline noop function to fix it. Signed-off-by: NStanley.Miao <stanley.miao@windriver.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Santosh Shilimkar 提交于
This patch fixes the base address of CONTROL register on OMAP4430SDP. The control base is used by peripherals like MMC1 for PBIAS configuration. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 23 4月, 2010 3 次提交
-
-
由 manjugk manjugk 提交于
The register DMA4_CDAC needs to be initialized to zero before starting DMA transfer. Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Govindraj R <govindraj.raja@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Reported-by: NS, Venkatraman <svenkatr@ti.com> Signed-off-by: NManjunatha GK <manjugk@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Janusz Krzysztofik 提交于
Since IRQ_TYPE_EDGE_BOTH is defined as (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING), testing against it with a bitwise AND also matches both single-edge cases in addition to the intended both edges case. Fix it, replacing with a more accurate expression. Created and tested againts linux-2.6.34-rc3. Applicable to 2.6.33-stable as well. Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Aaro Koskinen 提交于
When the 32k sync timer is used for sched_clock(), it should count time from the kernel boot (clocksource init) instead of the last HW reset. Otherwise printk.time values will jump suddenly during the boot: [ 0.000000] calling omap2_clk_arch_init+0x0/0x138 @ 1 [ 0.000000] initcall omap2_clk_arch_init+0x0/0x138 returned -22 after 0 usecs [ 0.000000] initcall omap2_clk_arch_init+0x0/0x138 returned with error code -22 [ 0.000000] calling omap_init_clocksource_32k+0x0/0x98 @ 1 [ 508.697937] initcall omap_init_clocksource_32k+0x0/0x98 returned 0 after 0 usecs [ 508.697967] calling omap_init_devices+0x0/0x38 @ 1 [ 508.698425] initcall omap_init_devices+0x0/0x38 returned 0 after 0 usecs This will confuse tools such as scripts/bootgraph.pl. Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com> Acked-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 31 3月, 2010 1 次提交
-
-
由 Thara Gopinath 提交于
This patch corrects the width of sysc_flags in hwmod sysconfig structure where the values to be stored to this variable exceed the current field width. Signed-off-by: NThara Gopinath <thara@ti.com> [paul@pwsan.com: edited to apply; rearranged structure members to pack] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 13 3月, 2010 1 次提交
-
-
由 Janusz Krzysztofik 提交于
The MsBSP register cache will never have any error/status flags set, since these flags are never written to the reg_cache. So it is kind of not necessary to clear these flags, which are actually always 0. In other words, clearing the status/error flags are not necessary, since the reg_cache will never got these bits set. We can just write back the register content from the cache as it is when clearing an error condition. Tested on Amstrad Delta. Reported-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: NJarkko Nikula <jhnikula@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 12 3月, 2010 5 次提交
-
-
由 Kevin Hilman 提交于
Currently if omap2420 is defined but not omap2430, cpu_is_omap2430() is still defined as a macro, instead of #define'd to zero. This results in conditional cpu_is_omap2430() code still being compiled, and leads to possible compile/link errors. In particular for hwmod init. To fix, add extra #ifdefs to CPU check macros to ensure that the is_omap* macros are zero for each OMAP2 if they are not configured into the kernel. Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sergio Aguirre 提交于
For omap4 case, this was wrongly writing GPIO_LEVELDETECTx registers with OMAP24XX_ offset and OMAP4_ offset. Bug introduced in commit: commit 3f1686a9 Author: Tony Lindgren <tony@atomide.com> Date: Mon Feb 15 09:27:25 2010 -0800 omap: Fix gpio.c for multi-omap for omap4 Signed-off-by: NSergio Aguirre <saaguirre@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Andrea Gelmini 提交于
arch/arm/plat-omap/include/plat/blizzard.h:9: ERROR: spaces prohibited around that ':' (ctx:WxW) Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Aaro Koskinen 提交于
This patch follows the commit be093beb by Russell King: OMAP wishes to pass state to the boot loader upon reboot in order to instruct it whether to wait for USB-based reflashing or not. There is already a facility to do this via the reboot() syscall, except we ignore the string passed to machine_restart(). The patch adds the missing parameter to omap1_arch_reset() and omap_prcm_arch_reset(), and modifies the latter to pass the reboot command parameter to the boot loader instead of reboot mode (which is for kernel internal use only and cannot be modified by the userspace). Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Felipe Balbi 提交于
the early_param() call in board-omap3touchbook.c expands to: static const char __setup_str_early_touchbook_revision[] __section(.init.rodata) _aligned(1) = tbr; [...] and we have a non-const variable being added to the same section: static struct ehci_hcd_omap_platform_data ehci_pdata __section(.init.rodata); because of that, gcc generates a section type conflict which can (and actually should) be avoided by marking const every variable marked with __initconst. This patch fixes that for the ehci_hdc_omap_platform_data. Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 2月, 2010 2 次提交
-
-
由 Jarkko Nikula 提交于
The commit b63128e8 broke the pin muxing for I2C busses that are enabled from the kernel command line. Fix this by defining the board registration function omap_register_i2c_bus in common platform code as it was before but keep the muxing in architecture dependent files. Signed-off-by: NJarkko Nikula <jhnikula@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
Add dsi_vc_dcs_read_2() helper function to read two bytes from the DSI peripheral. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-
- 25 2月, 2010 18 次提交
-
-
由 Santosh Shilimkar 提交于
On OMAP4 platform the iclk control is completly under hardware control and no software control is available. This difference w.r.t previous OMAP's needs all the common driver accross OMAP's , cpu_is_xxxx() checks. To avoid poulluting the drivers dummy clock nodes are created (The autogeneration script has been updated accordingly). Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NBenoit Cousson <b-cousson@ti.com> [paul@pwsan.com: made OMAP1 dummy_ck common and edited patch to reuse that] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
Add support for categorizing and iterating over hardware IP blocks by the "class" of the IP block. The class is the type of the IP block: e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data from the struct omap_hwmod into the struct omap_hwmod_class, since it's expected to stay consistent for each class. While here, fix some comments. The hwmod_class structures in this patch were designed and proposed by Benoît Cousson <b-cousson@ti.com> and were refined in a discussion between Thara Gopinath <thara@ti.com>, Kevin Hilman <khilman@deeprootsystems.com>, and myself. This patch uses WARN() lines that are longer than 80 characters, as Kevin noted a broader lkml consensus to increase greppability by keeping the messages all on one line. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NBenoît Cousson <b-cousson@ti.com> Cc: Thara Gopinath <thara@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Kukjin Kim 提交于
Add ARM_L1_CACHE_SHIFT_6 to arch/arm/Kconfig to allow CPUs with L1 cache lines which are 64bytes to indicate this without having to alter the arch/arm/mm/Kconfig entry each time. Update the mm Kconfig so that ARM_L1_CACHE_SHIFT default value uses this and change OMAP3 and S5PC1XX to select ARM_L1_CACHE_SHIFT_6. Acked-by: NBen Dooks <ben-linux@fluff.org> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Paul Walmsley 提交于
Code should be able to #include any header file without the fear that the header file will go allocating memory. This is a coding style issue, similar to commit 82e9bd58. Move the existing hwmod data from .h files to .c files. While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since most of these structures should be reusable across all OMAP3 chips. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
The OMAP hwmod core code is intended to use SoC IP block description structures that are autogenerated from TI's OMAP hardware database. Currently the hwmod code uses clkdev device + connection addressing to identify clocks. This causes problems in the hwmod autogeneration process, since the TI hardware database doesn't use platform_device or clkdev addressing; it uses a single clock signal name string, which tends to bear some resemblance to what is used in the OMAP TRMs. This patch converts the hwmod code and existing data to use omap_clk_get_by_name(), introduced in the previous patch. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
The OMAP hwmod core code is intended to use SoC IP block description structures that are autogenerated from TI's OMAP hardware database. Currently the hwmod code uses clkdev device + connection addressing to identify clocks. This causes problems in the hwmod autogeneration process, since the TI hardware database doesn't use platform_device or clkdev addressing; it uses a single clock signal name string, which tends to bear some resemblance to what is used in the OMAP TRMs. This patch adds a non-exported function to the OMAP clock code, omap_clk_get_by_name(). A subsequent patch will convert the hwmod code to use this function. This function is for use only by core code, and practically, no other code outside the hwmod code should need it. Device driver code in the kernel must not use this function, which is why it is not exported. Drivers should use the appropriate clock alias provided by the clkdev data structures, so driver code can be completely SoC-independent. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
Get rid of the ALWAYS_ENABLED clock flag - it doesn't actually do anything. (The OMAP4 clock autogeneration scripts have been updated accordingly.) Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
The RATE_FIXED clock flag is pointless. In the OMAP1 clock code, it simply causes the omap1_clk_round_rate() function to return the current rate of the clock. omap1_clk_round_rate(), however, should never be called for a fixed-rate clock, since none of these clocks have a .round_rate function pointer set in their struct clk records. Similarly, in the OMAP2+ clock code, the RATE_FIXED flag just causes the clock code to emit a warning if the OMAP clock maintainer was foolish enough to add a .round_rate function pointer to a fixed-rate clock. "Doctor, it hurts when I pretend that a fixed-rate clock is rate-changeable." "Then don't pretend that a fixed-rate clock is rate-changeable." It has no functional value. This patch drops the RATE_FIXED clock flag, removing it from all clocks that are so marked. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
-
由 Paul Walmsley 提交于
All of the clocks that are marked with DELAYED_APP are changed as part of the virt_prcm_set OPP virtual clock. On 24xx, these clocks all need to be changed as part of a group to keep the clock tree functional - hence the need for the VALID_CONFIG bit, which is not present on later OMAPs. These clocks should not be rate-changed independently. So prevent these clocks from being changed independently by dropping their .round_rate and .set_rate function pointers. It then turns out that the DELAYED_APP clock flag is no longer useful, so drop it and the associated code and renumber the clock flags. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
-
由 Paul Walmsley 提交于
After the clkdev conversion, the struct clk.id field became superfluous, so, drop it. Bring the clock names closer to the TRMs and ensure they are unique for debugfs. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
There are now only eight OMAP clock flags, so renumber the flags to fit in a u8 and shrink the size of struct clk.flags from a u32 to a u8. The intention is to save memory. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
It turns out that the only purpose of the CONFIG_PARTICIPANT clock flag is to prevent omap2_clk_set_rate() and omap2_clk_set_parent() from being executed on clocks with that flag set. The rate-changing component can be more directly accomplished by dropping the .set_rate and .round_rate function pointers from those CONFIG_PARTICIPANT struct clks. As far as the parent-changing component is concerned, it turns out that none of the CONFIG_PARTICIPANT clocks have multiple parent choices, so all that is necessary is for omap2_clk_set_parent() to bail out early if the new parent is equal to the old parent. Implement this change and get rid of the flag, which has always had a confusing name (it appears to be a Kconfig option, falsely). Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
-
由 Paul Walmsley 提交于
The CLOCK_IN_OMAP4430 clock flag is not currently needed in the OMAP4 ES1 clock tree, and platform discrimination via clock flags is deprecated in favor of the clkdev mechanism, so, drop it. (The OMAP4 clock tree autogeneration script has been updated accordingly.) Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
由 Paul Walmsley 提交于
The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are one increment higher than they should be. See for example the OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL". Programming a 0 into the DPLL's M register bitfield is valid for OMAP2/3 and indicates that the DPLL should enter MN-bypass mode. Also, increase the minimum multiplier (M) value for the DPLL rate rounding code from 1 to 2, to ensure that it does not inadvertently put the DPLL into bypass. Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs does not make clear that the actual DPLL divider value (the "N") is the content of the appropriate register bitfield for the N value, _plus one_. (In other words, an N register bitfield of 0 indicates a DPLL divider value of 1.) This is only clearly documented in the OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167 "CM_CLKSEL_DPLL_USB". While here, update copyrights, add kerneldoc for struct dpll_data, drop the unused struct dpll_data.max_tolerance field, remove some unnecessary #includes in DPLL-related code, and replace the #include of <linux/module.h> with <linux/list.h>, which is what was really needed. The OMAP4 clock autogenerator script has been updated accordingly. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
由 Vishwanath BS 提交于
In 3630, DPLL4M2 output can be 96MHz or 192MHz (for SGX to run at 192). This patch has changes to support this feature. 96MHz clock is generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register. SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's functional clock. In summary changes done are: 1. Added a feature called omap3_has_192mhz_clk and enabled for 3630 2. Added a new clock node called omap_192m_alwon_ck 3. Made omap_96m_alwon_fck to derive its clock from omap_192m_alwon_ck Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com> [paul@pwsan.com: fixed whitespace] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Vishwanath BS 提交于
Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit in 3630. This patch has changes to accommodate this in CM dynamically based on chip version. Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and M6 and value of these nodes are used if cpu type is 3630. Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com> [paul@pwsan.com: updated to apply on 2.6.34 queue; comments added] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Richard Woodruff 提交于
DPLL4 for 3630 introduces a changed block called j type dpll, requiring special divisor bits and additional reg fields. To allow for silicons to use this, this is introduced as a flag and is enabled for 3630 silicon. OMAP4 also has j type dpll for usb. Tested with 3630 ZOOM3 and OMAP3430 ZOOM2 Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com> [paul@pwsan.com: added some comments; updated copyrights and credits; fixed some style issues] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Thara Gopinath 提交于
This patch adds support in omap device layer to register devices as early platform devices. Certain devices needed during system boot up like timers, gpio etc can be registered as early devices. This will allow for them to be probed very early on during system boot up. This patch adds a parameter is_early_device in omap_device_build. Depending on this parameter a call to early_platform_add_devices or platform_register_device is made. Signed-off-by: NThara Gopinath <thara@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-