- 16 3月, 2010 3 次提交
-
-
由 Sergio Aguirre 提交于
This check is invalid, since we haven't filled the omap_revision var at this point. Signed-off-by: NSergio Aguirre <saaguirre@ti.com>
-
由 Sergio Aguirre 提交于
As we have a struct device populated at the time we are printing the errors, using dev_* macros makes more sense, as could give a better idea where the error/warning came from. Signed-off-by: NSergio Aguirre <saaguirre@ti.com>
-
由 Sergio Aguirre 提交于
This is for protecting a wrong mapping attempt of a zero-based physical address. The result is that, no serial port will be attempted to be mapped. Also add an additional protection for NULL clocks before attempting to enable them (if above condition applies) Signed-off-by: NSergio Aguirre <saaguirre@ti.com>
-
- 13 3月, 2010 1 次提交
-
-
由 Andrew Clayton 提交于
Remove the +x bit from a couple of source files Signed-off-by: NAndrew Clayton <andrew@digital-domain.net> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 12 3月, 2010 10 次提交
-
-
由 Kevin Hilman 提交于
When building for multi-omap, and OMAP4 is enabled, CONFIG_ARCH_OMAP4 will be true and prevent included code from building/running for OMAP2/3 as well. This problem exists in io.c where some hwmod/PM/SDRC init code is prevented from running even on OMAP2/3 when OMAP4 is included in a multi-OMAP build. A quick glance suggests that this #ifndef is no longer needed in most of the cases. In the remaining cases, the function is wrapped with "if (cpu_is_omap24xx() || cpu_is_omap34xx())" which will be optimized out for OMAP4-only builds. Note that this is only a short-term fix. Longer-term, OMAP4 needs to create init functions for SDRC and hwmod late-init. Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Grazvydas Ignotas 提交于
This will allow BQ27500 fuel gauge to function. Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Aaro Koskinen 提交于
Get rid of the following warnings: warning: non-ANSI function declaration of function [...] Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Enric Balletbo i Serra 提交于
Select CONFIG_LEDS_GPIO to enable IGEP v2 LED support and control of supported LEDs from userspace. Otherwise GPIO LEDs are exported as GPIO 26, 27 and 28 using the gpiolib framework. Signed-off-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com> 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>
-
由 Suman Anna 提交于
Remove a compiler warning in device-specific mailbox module. Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Thomas Weber 提交于
The omap_serial_early_init prints the following errors: Could not get uart4_ick Could not get uart4_fck because all the uarts available in omap_uart[] will be initialized. Only omap4430 and omap3630 have 4 uarts at the moment. This patch reduces the number of uarts when cpu is not omap4430 or omap3630. Signed-off-by: NThomas Weber <weber@corscience.de> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Francisco Alecrim 提交于
Based on Kalle's and Tony's patches. Some variables re-organized and unused code removed. Signed-off-by: NKalle Valo <kalle.valo@iki.fi> Signed-off-by: NFrancisco Alecrim <francisco.alecrim@openbossa.org> [tony@atomide.com: this is needed to fix the related tusb6010 DMA API changes] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Santosh Shilimkar 提交于
This patch moves omap_smc1 function to a seperate omap44xx-smc.S file and sets compile flags as -Wa,-march=armv7-a. This fix was suggested by Tony Lindgren <tony@atomide.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> [tony@atomide.com: otherwise multi-omap build with V6 and V7 breaks] 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>
-
- 10 3月, 2010 1 次提交
-
-
由 Tony Lindgren 提交于
Commit 2b0d8c25 changed ARM to use the common early_param code. Fix compile for Touch Book accordingly. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 27 2月, 2010 1 次提交
-
-
由 Tony Lindgren 提交于
Initialize MMC for N8X0 Based on an earlier patches from Nokia released kernel sources at: http://repository.maemo.org/pool/os2008/free/source/k/kernel-source-rx-34/Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 2月, 2010 3 次提交
-
-
由 Sriram 提交于
Correct instances where tca6416 is misspelt as tca6516 in the board-am3517evm file. Signed-off-by: NSriramakrishnan <srk@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Ajay Kumar Gupta 提交于
Adding GPIO mux config used for PHY reset of EHCI port on base board. We get below failure message without this patch, "hub 1-0:1.0: unable to enumerate USB device on port 1" Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 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>
-
- 25 2月, 2010 21 次提交
-
-
由 Santosh Shilimkar 提交于
Now the omap4 clock framework is in mainline and clk_get_rate() is functional. Hence reomve the hardcoded clock hacks. This patch also fixes Division by zero in kernel. Backtrace: [<c0025fb8>] (dump_backtrace+0x0/0x110) from [<c017febc>] (dump_stack+0x18/0x1c) r7:60000093 r6:c0641050 r5:c0223e78 r4:c02126b4 [<c017fea4>] (dump_stack+0x0/0x1c) from [<c00260fc>] (__div0+0x18/0x20) [<c00260e4>] (__div0+0x0/0x20) from [<c01431fc>] (Ldiv0+0x8/0x10) [<c00318d4>] (omap_dm_timer_stop+0x0/0xb0) from [<c002c148>] (omap2_gp_timer_set_mode+0x1c/0x68) r5:c0223e78 r4:00000000 [<c002c12c>] (omap2_gp_timer_set_mode+0x0/0x68) from [<c0063270>] (clockevents_set_mode+0x30/0x64) r5:c020cae0 r4:00000000 [<c0063240>] (clockevents_set_mode+0x0/0x64) from [<c00632fc>] (clockevents_exchange_device+0x30/0x9c) r5:c020cae0 r4:c02146e0 [<c00632cc>] (clockevents_exchange_device+0x0/0x9c) from [<c00636e0>] (tick_notify+0x17c/0x404) r7:00000000 r6:c0641050 r5:00000000 r4:c020cae0 [<c0063564>] (tick_notify+0x0/0x404) from [<c005d5fc>] (notifier_call_chain+0x34/0x78) [<c005d5c8>] (notifier_call_chain+0x0/0x78) from [<c005d684>] (__raw_notifier_call_chain+0x1c/0x24) [<c005d668>] (__raw_notifier_call_chain+0x0/0x24) from [<c005d6ac>] (raw_notifier_call_chain+0x20/0x28) [<c005d68c>] (raw_notifier_call_chain+0x0/0x28) from [<c0062e78>] (clockevents_do_notify+0x1c/0x24) [<c0062e5c>] (clockevents_do_notify+0x0/0x24) from [<c0062f18>] (clockevents_register_device+0x98/0xd0) [<c0062e80>] (clockevents_register_device+0x0/0xd0) from [<c001a194>] (percpu_timer_setup+0x80/0x9c) r7:00000000 r6:00000002 r5:00000002 r4:00000003 [<c001a114>] (percpu_timer_setup+0x0/0x9c) from [<c000e9f0>] (smp_prepare_cpus+0xb0/0xe8) [<c000e940>] (smp_prepare_cpus+0x0/0xe8) from [<c00084e8>] (kernel_init+0x5c/0x1fc) r7:00000000 r6:00000000 r5:00000000 r4:c001b8a4 [<c000848c>] (kernel_init+0x0/0x1fc) from [<c0046c50>] (do_exit+0x0/0x604) r7:00000000 r6:00000000 r5:00000000 r4:00000000 Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 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>
-
由 Rajendra Nayak 提交于
All leaf clock nodes are renamed for OMAP4 to have a clk name which end with a _ick or a _fck. This is done so that the naming convention is same as that followed on older OMAPs. Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
Simplify the code in the omap2_clk_disable() and omap2_clk_enable() functions, reducing levels of indentation. This makes the code easier to read. Add some additional debugging pr_debug()s here also to help others understand what is going on. Revise the omap2_clk_disable() logic so that it now attempts to disable the clock's clockdomain before recursing up the clock tree. Simultaneously, ensure that omap2_clk_enable() is called on parent clocks first, before enabling the clockdomain. This ensures that a parent clock's clockdomain is enabled before the child clock's clockdomain. These sequences should be the inverse of each other. Revise the omap2_clk_enable() logic so that it now cleans up after itself upon encountering an error. Previously, an error enabling a parent clock could have resulted in inconsistent usecounts on the enclosing clockdomain. Remove the trivial _omap2_clk_disable() and _omap2_clk_enable() static functions, and replace it with the clkops calls that they were executing. For all this to work, the clockdomain omap2_clkdm_clk_enable() and omap2_clkdm_clk_disable() code must not return an error on clockdomains without CLKSTCTRL registers; so modify those functions to simply return 0 in that case. While here, add some basic kerneldoc documentation on both functions, and get rid of some old non-CodingStyle-compliant comments that have existed since the dawn of time (at least, the OMAP clock framework's time). Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
由 Paul Walmsley 提交于
The OMAP2 and OMAP3 boot-time MPU rate change code is almost identical. Merge them into mach-omap2/clock.c, and add kerneldoc documentation. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
_clkdm_add_autodeps() and _clkdm_del_autodeps() will attempt to dereference a NULL pointer if no autodeps were supplied to clkdm_init(). Based on a patch from Roel Kluin <roel.kluin@gmail.com> - thanks Roel. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Roel Kluin <roel.kluin@gmail.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>
-
由 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>
-
由 Vimarsh Zutshi 提交于
Add necessary clk_sel definitions to clock framework to allow changing dpll4_m5_ck_3630 rate. This is used by the ISP driver. Signed-off-by: NVimarsh Zutshi <vimarsh.zutshi@nokia.com> [paul@pwsan.com: updated to apply] Signed-off-by: NPaul Walmsley <paul@pwsan.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 提交于
func_96m_ck was incorrectly marked as being rate-selectable, when in fact it is only parent-selectable. Remove the .set_rate and .round_rate function pointers for this clk. Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
In preparation for multi-OMAP2 kernels, split mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and mach-omap2/clock2430_data.c. 2430 uses a different device space physical memory layout than past or future OMAPs, and we use a different virtual memory layout as well, which causes trouble for architecture-level code/data that tries to support both. We tried using offsets from the virtual base last year, but those patches never made it upstream; so after some discussion with Tony about the best all-around approach, we'll just grit our teeth and duplicate the structures. The maintenance advantages of a single kernel config that can compile and boot on OMAP2, 3, and 4 platforms are simply too compelling. This approach does have some nice benefits beyond multi-OMAP 2 kernel support. The runtime size of OMAP2420-specific and OMAP2430-specific kernels is smaller, since unused clocks for the other OMAP2 chip will no longer be compiled in. (At some point we will mark the clock data __initdata and allocate it during registration, which will eliminate the runtime memory advantage.) It also makes the clock trees slightly easier to read, since 2420-specific and 2430-specific clocks are no longer mixed together. This patch also splits 2430-specific clock code into its own file, mach-omap2/clock2430.c, which is only compiled in for 2430 builds - mostly for organizational clarity. While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was incorrectly marked as being 2420-only, when actually it is present on both OMAP2420 and OMAP2430. Thanks to Tony for some good discussions about how to approach this problem. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
-
由 Paul Walmsley 提交于
clock34xx_data.c now contains data for the OMAP34xx family, the OMAP36xx family, and the OMAP3517 family, so rename it to clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the chip family-specific clock functions to clock34xx.c, clock36xx.c, or clock3517.c, as appropriate. So now "clock3xxx.*" refers to the OMAP3 superset. The main goal here is to prepare to compile chip family-specific clock functions only for kernel builds that target that chip family. To get to that point, we also need to add CONFIG_SOC_* options for those other chip families; that will be done in future patches, planned for 2.6.35. OMAP4 is also affected by this. It duplicated the OMAP3 non-CORE DPLL clkops structure. The OMAP4 variant of this clkops structure has been removed, and since there was nothing else currently in clock44xx.c, it too has been removed -- it can always be added back later when there is some content for it. (The OMAP4 clock autogeneration scripts have 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> Cc: Ranjith Lohithakshan <ranjithl@ti.com> Cc: Tony Lindgren <tony@atomide.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 提交于
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 DELAYED_APP flag is effective only with clksel clocks, so drop it from clocks that are not rate-changeable or that use non-clksel rate changing code (e.g., virt_prcm_set). Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
-
由 Paul Walmsley 提交于
According to the OMAP242x TRM Rev X Figure 5-15 "Clock Output Control - Functional Clocks 2", the GFX functional clocks should be marked both DELAYED_APP and CONFIG_PARTICIPANT, meaning that their rates must be reprogrammed as part of a larger OPP set change. 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>
-