- 27 Sep, 2011 12 commits
-
-
Jarkko Nikula authored
This generalizes the omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src implementation between generic McBSP and OMAP2 specific McBSP code. These functions are used to select source for CLKR and FSR signals on OMAP2+. Start generalizing the code by implementing an optional mux_signal function pointer in platform data that will implement the actual muxing and which is called now from omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src. These functions are to be removed later and cleanup the API so that mux_signal gets its arguments directly from client code. Signed-off-by:
Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by:
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Jarkko Nikula authored
This generalizes the omap2_mcbsp_set_clks_src implementation between generic McBSP and OMAP2 specific McBSP code. Currently this function is used to select either internal fclk or clks pin as a McBSP CLKS source on OMAP2+. Implement generalization by having an optional set_clk_src function pointer in platform data that is used to select parent for a given clock. Idea is to pass higher level source clock name (later coming from client driver) that platform specific code will map to platform specific clock name. API cleanup between McBSP and client code comes later. Signed-off-by:
-
Jarkko Nikula authored
These address definitions are OMAP1 specific can be in single source file. Signed-off-by:
-
Jarkko Nikula authored
hardware.h is not needed here and let the definition for struct clk to come via linux/clk.h. Signed-off-by:
-
Jarkko Nikula authored
Sidetone resource is already registered for a device so there is no need for cpu_is_omap34xx() and McBSP port number tests in the driver. We can cleanup and make the code generic by dropping remaining CONFIG_ARCH_OMAP3 conditional compilations and then using sidetone resource and st_data variable for runtime tests. Signed-off-by:
-
Jarkko Nikula authored
Active sidetone requires that McBSP interface clock doesn't idle and there is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3 in OMAP34xx share their interface clock with McBSP sidetone module and that interface clock must be active when the sidetone is operating. Sidetone has its own autoidle bit which should keep the interface clock active but it is broken. Putting the McBSP core to no-idle mode when the sidetone is active is no good either since it results to higher power consumption when using the threshold based DMA transfers. For making the McBSP code more generic, move this sidetone clock management with fixme comments to mach-omap2/mcbsp.c and pass pointer to it via platform data. Signed-off-by:
Jarkko Nikula <jhnikula@gmail.com> Cc: Paul Wamsley <paul@pwsan.com> Acked-by:
-
Jarkko Nikula authored
Rationale here is to remove one global variable and to make possible to have variable size McBSP register maps inside SoC. Signed-off-by:
-
Jarkko Nikula authored
Remove CONFIG_ARCH_OMAP3 conditional compilation and cpu_is_omap34xx test around buffer threshold based transfer and DMA operating mode control. Use instead the buffer_size in platform data to determine when these sysfs controls are exposed and when to access related McBSP registers. Rationale for this is to make code generic and to allow to use it on OMAP4 that also supports threshold based transfers. Currently buffer_size variable is set only for OMAP3 SoCs but it is easy to extend to OMAP4 and any later OMAP version. Signed-off-by:
-
Jarkko Nikula authored
McBSP transmit and receive configuration control registers must be set up for OMAP2430 and later. Replace is_omap tests in generic code with a new feature flag has_ccr in platform data so that there is no need to change code for any upcoming OMAP version. Signed-off-by:
-
Jarkko Nikula authored
Currently wakeup control code is compiled only when CONFIG_ARCH_OMAP3 is set even it should be available for CONFIG_ARCH_OMAP4 only builds also. Fix this by making wakeup control generic so that it is executed whenever new feature flag has_wakeup in platform data is set. Currently flag is set for McBSP config types 3 and 4. Remove also old comments about idle mode settings and HW bug workarounds that were not updated during hwmod conversion. Signed-off-by:
-
Jarkko Nikula authored
Register access can be made more generic by calculating register address offsets runtime from common register definitions and by using reg_size and reg_step variables that are passed via platform data. Common register definitions are possible since McBSP registers are ordered similarly between OMAP versions. Remove also references to OMAP2+ specific config_type variable from generic McBSP code since other variables and feature flags are better to carry needed information from platform code. Signed-off-by:
-
Jarkko Nikula authored
Only OMAP1s are using omap_mcbsp_register_board_cfg after OMAP2+ hwmod conversion so it can be moved to mach-omap1/mcbsp.c. Signed-off-by:
-
- 26 Sep, 2011 1 commit
-
-
Jarkko Nikula authored
These variables got unused after McBSP was converted to use resource structures. Signed-off-by:
-
- 22 Sep, 2011 2 commits
-
-
- 21 Sep, 2011 1 commit
-
-
Kevin Hilman authored
Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime. Suggested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Acked-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
Kevin Hilman <khilman@ti.com> Signed-off-by:
-
- 20 Sep, 2011 1 commit
-
-
Tony Lindgren authored
Commit f41caddb (omap2+: Use Kconfig symbol in Makefile instead of obj-y) cleaned up the omap2+ Makefile. However this did not account for the inline functions that are now needed for board_flash_init and board_nand_init. Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 16 Sep, 2011 1 commit
-
-
Kevin Hilman authored
During the idle/suspend path, we expect the console lock to be held so that no console output is done during/after the UARTs are idled. However, when using the no_console_suspend argument on the command-line, the console driver does not take the console lock. This allows the possibility of console activity after UARTs have been disabled. To fix, update the current is_suspending() to also check the console_suspend_enabled flag. Reported-by:
Abhilash Koyamangalath <abhilash.kv@ti.com> Tested-by:
-
- 15 Sep, 2011 9 commits
-
-
Kevin Hilman authored
Rather than embedding a struct platform_device inside a struct omap_device, decouple them, leaving only a pointer to the platform_device inside the omap_device. Use the arch-specific data field of the platform_device (pdev_archdata) to add an omap_device pointer after the platform_device has been created. Signed-off-by: -
Kevin Hilman authored
Public omap_device functions need to take platform_device pointers, conversion to omap_device pointers is done internal to the omap_device layer. Signed-off-by: -
Kevin Hilman authored
The internal device register functions do not need or use any omap_device internals, so pass in a platform_device pointer instead of an omap_device pointer. Signed-off-by: -
Kevin Hilman authored
All of the device init and device driver interaction with omap_device is done using platform_device pointers. To make this more explicit, have omap_device return a platform_device pointer instead of an omap_device pointer. All current users of the omap_device pointer were only using it to get at the platform_device pointer or struct device pointer, so fixing all of the users was trivial. This also makes it more difficult for device init code to directly access members of struct omap_device, and allows for easier changing of omap_device internals. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: -
Kevin Hilman authored
The *_device_register() functions and the count/fill resources functions are internal to omap_device and do not need to be in the header. Signed-off-by: -
Grazvydas Ignotas authored
During normal system operation warning messages similar to this are appearing quite often: omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035 This doesn't seem to be reporting a problem, nor is it very useful for non-developers, so reduce it to debug level. Acked-by:
Steve Sakoman <steve@sakoman.com> Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Kevin Hilman authored
For consistency in kernel printk output for devices, use dev_dbg(), dev_warn(), dev_err() instead of pr_debug(), pr_warning() and pr_err(), some of which currently use direct access of name from platform_device and others of which use dev_name(). Using the dev_* versions uses the standard device naming from the driver core. Some pr_* prints were not converted with this patch since they are used before the platform_device and struct device are created so neither the dev_* prints or dev_name() is valid. Reported-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Jarkko Nikula authored
struct omap_device *od is only set with find_omap_device_by_dev but not used otherwise so remove them and references to omap device API. Acked-by:
-
-
- 14 Sep, 2011 12 commits
-
-
Paul Walmsley authored
Now that all of the users of the OMAP_CHIP bitfield code have been converted to use lists, the OMAP_CHIP code, data, and declarations can be removed. Signed-off-by:Paul Walmsley <paul@pwsan.com>
-
Paul Walmsley authored
At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and replace it instead with chip family, variant, and ES level-specific lists of hwmods to register. Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the AM3517/3505 support, and for other review comments. Signed-off-by: -
Paul Walmsley authored
At Tony's request, remove the omap_chip bitmasks from the powerdomain definitions. Instead, initialize powerdomains based on one or more lists that are applicable to a particular SoC family, variant, and silicon revision. Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a related patch that also applied to this patch - thanks Gražvydas. Signed-off-by: -
Paul Walmsley authored
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three functions. This allows some of them to be called multiple times: for example, pwrdm_register_pwrdms() can be called once to register powerdomains that are common to a group of SoCs, and once to register powerdomains that are specific to a single SoC. The appropriate order to call these functions - which is enforced by the code - is: 1. pwrdm_register_platform_funcs() 2. pwrdm_register_pwrdms() (can be called multiple times) 3. pwrdm_complete_init() Convert the OMAP2, 3, and 4 powerdomain init code to use these new functions. While here, improve documentation, and increase CodingStyle conformance by shortening some local variable names. Signed-off-by: -
Paul Walmsley authored
At Tony's request, remove the omap_chip bitmasks from the clockdomain and clockdomain dependency definitions. Instead, initialize clockdomains based on one or more lists that are applicable to a particular SoC family, variant, and silicon revision. Tony Lindgren <tony@atomide.com> found a bug in a previous version of this patch - thanks Tony. Signed-off-by: -
Paul Walmsley authored
In preparation for OMAP_CHIP() removal, split clkdm_init() into four functions. This allows some of them to be called multiple times: for example, clkdm_register_clkdms() can be called once to register clockdomains that are common to a group of SoCs, and once to register clockdomains that are specific to a single SoC. The appropriate order to call these functions - which is enforced by the code - is: 1. clkdm_register_platform_funcs() 2. clkdm_register_clkdms() (can be called multiple times) 3. clkdm_register_autodeps() (optional; deprecated) 4. clkdm_complete_init() Convert the OMAP2, 3, and 4 clockdomain init code to use these new functions. While here, improve documentation, and increase CodingStyle conformance by shortening some local variable names. Signed-off-by: -
Paul Walmsley authored
The OMAP_REVBITS_* macros are just used as otherwise meaningless aliases for the numbers zero through five, so remove these macros. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Tested-by:
-
Paul Walmsley authored
omap3_cpuinfo() contains essentially duplicated code from omap3_check_revision(), just for the purpose of determining the chip ES level. Set the cpu_rev char array pointer in omap3_check_revision() instead, and drop the now-useless code from omap3_cpuinfo(). Signed-off-by:
-
Paul Walmsley authored
Emit a warning to the console in omap3_check_revision() if that code cannot determine what type of SoC the system is currently running on. Remove some extra whitespace, remove some duplicate code, and add an appropriate comment to a fallthrough case. Signed-off-by:
-
Paul Walmsley authored
Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest of the OMAP2+ SoCs do in mach-omap2/cpu.c. Signed-off-by:
-
Paul Walmsley authored
omap3_cpuinfo() is filled with useless strcpy() calls; remove them. Signed-off-by:
-
Paul Walmsley authored
The OMAP3505/AM3505 appears to be based on the same silicon as the OMAP3517/AM3517, with some features disabled via eFuse bits. Follow the same practice as OMAP3430 and identify these devices internally as part of the OMAP3517/AM3517 family. The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon as the OMAP3430, with some features disabled via eFuse bits. Identify these devices internally as part of the OMAP3430 family. Remove the old OMAP35XX_CLASS, which actually covered two very different chip families. The OMAP3503/3515/3525/3530 chips will now be covered by OMAP343X_CLASS, since the silicon appears to be identical. For the OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS. Thanks to Tony Lindgren <tony@atomide.com> for some help with the second revision of this patch. Signed-off-by:
-
- 12 Sep, 2011 1 commit
-
-
Linus Torvalds authored
-
