- 15 12月, 2011 6 次提交
-
-
由 Govindraj.R 提交于
Avoid unconditional context restore every time we gate uart clocks. Check whether context loss happened based on which we can context restore uart regs from uart_port structure. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Remove the uart reset function which is configuring the TX empty irq which can now be handled within omap-serial driver. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Add missing uart regs to uart_port structure which can be used in context restore. Store dll, dlh, mdr1, scr, efr, lcr, mcr reg values into uart_port structure while configuring individual port in termios function. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
The mapbase (start_address), membase(io_remap cookie) part of pdata struct omap_uart_port_info are removed as this should be derived within driver. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Currently we use a shared irq handler to identify uart activity and then trigger a timer. By default the timeout value is zero and can be set or modified from sysfs. If there was no uart activity for the period set through sysfs, the timer will expire and call timer handler this will set a flag can_sleep using which decision to gate uart clocks can be taken. Since the clock gating mechanism is outside the uart driver, we currently use this mechanism. In preparation to runtime implementation for omap-serial driver we can cleanup this mechanism and use runtime API's to gate uart clocks. Removes the following: * timer related info from local uart_state struct * the code used to set timeout value from sysfs. * irqflags used to set shared irq handler. * un-used function omap_uart_check_wakeup. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
In preparation to UART runtime conversion remove uart specific calls from pm24xx/34xx files and their definition from serial.c These func calls will no more be used with upcoming uart runtime design. 1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks. 2.) omap_uart_enable_irqs :- Used to enable/disable uart irq's in suspend path from PM code, this is removed as same is handled by uart_suspend_port/uart_resume_port in omap-serial driver which will do an port_shutdown on suspend freeing irq and port_startup on resume enabling back irq. 3.) Remove prepare_idle/resume_idle calls used to gate uart clocks. UART clocks can be gated within driver using runtime funcs and be woken up using irq_chaining from omap_prm driver. 4.) Remove console_locking from idle path as clock gating is done withing driver itself with runtime API. Remove is_suspending check used to acquire console_lock. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 14 12月, 2011 6 次提交
-
-
由 Hemant Pedanekar 提交于
This patch adds cpu type, macros for identification of TI814X device. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> [tony@atomide.com: left out CK_TI814X for now] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Hemant Pedanekar 提交于
This patch updates existing macros, functions used for TI816X, to enable addition of other SoCs belonging to TI81XX family (e.g., TI814X). The approach taken is to use TI81XX/ti81xx for code/data going to be common across all TI81XX devices. cpu_is_ti81xx() is introduced to handle code common across TI81XX devices. In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved in mach-omap2/common.c as same will be used for TI814X and is not board specific. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Leonid Iziumtsev 提交于
Add support for detection of the next chip in the OMAP4 family: OMAP4470 ES1.0 For more details on OMAP4470, visit: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12869&contentId=123362Signed-off-by: NLeonid Iziumtsev <x0153368@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 David Anders 提交于
allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdfSigned-off-by: NDavid Anders <x0132446@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Afzal Mohammed 提交于
This patch updates the common machine specific source files for support for AM33XX/AM335x with cpu type, macros for identification of AM33XX/AM335X device. Signed-off-by: NAfzal Mohammed <afzal@ti.com> Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> [tony@atomide.com: updated for map_io and common.h changes, dropped CK_AM33XX] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Afzal Mohammed 提交于
This patch updates the common platform files with AM335X device support (AM33XX family). The approach taken in this patch is, AM33XX device will be considered as OMAP3 variant, and a separate SoC class created for AM33XX family of devices with a subclass type for AM335X device, which is newly added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks will return success on AM335X device. A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3 to include support for AM33XX build. Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by: NAfzal Mohammed <afzal@ti.com> Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Cc: Hemant Pedanekar <hemantp@ti.com> [tony@atomide.com: left out CK_AM33XX for now] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 19 11月, 2011 1 次提交
-
-
由 Nicolas Pitre 提交于
A generic version should replace this later. As io.c has become nearly empty, omap_init_consistent_dma_size() is moved into common.c so that io.c can be removed entirely. Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org> Tested-by: NKevin Hilman <khilman@ti.com>
-
- 18 11月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>, there's no need to keep local prototypes in non-local headers. Add mach-omap1/common.h and mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 16 11月, 2011 2 次提交
-
-
由 Marc Zyngier 提交于
After the MULTI_IRQ_HANDLER conversion, a couple of global variables can be removed. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
Provide the OMAP2/3 IRQ code with low level handlers that can be used by platforms using CONFIG_MULTI_IRQ_HANDLER. Though the handlers are written in C, the compiled code looks very similar to its assembly counterpart (at least with my gcc 4.4.1). Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
- 11 11月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
Without this patch we get the following error: arch/arm/mach-omap2/clkt_dpll.c: In function '_dpll_test_fint': arch/arm/mach-omap2/clkt_dpll.c:98: error: 'struct dpll_data' has no member named 'flags' Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 08 11月, 2011 1 次提交
-
-
由 Tomi Valkeinen 提交于
This patch adds a custom DSS reset function used on OMAPs from OMAP2 forward. The function doesn't actually do a reset, it only waits for the reset to complete. The reason for this is that on OMAP4 there is no possibility to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets all the other DSS modules also, thus breaking the HWMOD model where every DSS module is handled independently. This fixes the problem with DSS reset on OMAP4, caused by the fact that because there's no SW reset for dss_core on OMAP4, the HWMOD framework doesn't try to reset dss_core and thus the DSS clocks were never enabled at the same time. This causes causes the HWMOD reset to fail for dss_dispc and dss_rfbi. The common reset function will also allow us to fix another problem in the future: before doing a reset we need to disable DSS outputs, which are in some cases enabled by the bootloader, as otherwise DSS HW seems to get more or less stuck, requiring a power reset to recover. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> [paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o unconditionally to avoid an error when !CONFIG_OMAP2_DSS] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 05 11月, 2011 2 次提交
-
-
由 Jarkko Nikula 提交于
There is no use for omap-alsa.h and board-palmz71.c doesn't need it either. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
get_context_loss_count functions return context loss count as u32, and zero means an error. However, zero is also returned when context has never been lost and could also be returned when the context loss count has wrapped and goes to zero. Change the functions to return an int, with negative value meaning an error. OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the hsmmc code handles the returned value as an int, with negative value meaning an error, this patch actually fixes hsmmc code also. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NKevin Hilman <khilman@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> [tony@atomide.com: updated to fix a warning with recent dmtimer changes] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 27 10月, 2011 1 次提交
-
-
由 Paul Walmsley 提交于
When device data indicates that multiple block reads are not supported on a given HSMMC controller instance, log a message to the console, and pass the appropriate MMC capability flag to the MMC core. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Dave Hylands <dhylands@gmail.com> Tested-by: NSteve Sakoman <sakoman@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 20 10月, 2011 5 次提交
-
-
由 Tony Lindgren 提交于
We don't have cpu_is_omapxxxx SoC detection initialized until SoC detection is initialized from init_early. Note that with the common map_io we should no longer need cpu_is_omapxxxx for ioremap. Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Otherwise we can't do generic map_io as we currently rely on static mappings that work only because of arch_ioremap. Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
This allows us to remove omap hacks for map_io. Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
This way we don't need to initialize SoC detection early and can start using generic map_io. Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
This allows removing omap hacks for map_io allowing generic map_io. Note that in the future we can't do cpu_is_omapxxxx detection until in init_early. This means that board-innovator.c now assumes 15xx only, and board-generic.c assumes 16xx only. This is best fixed later on by passing the SoC type from device tree. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 08 10月, 2011 1 次提交
-
-
由 Paul Walmsley 提交于
The way that we detect which OMAP3 chips support I/O wakeup and software I/O chain clock control is broken. Currently, I/O wakeup is marked as present for all OMAP3 SoCs other than the AM3505/3517. The TI81xx family of SoCs are at present considered to be OMAP3 SoCs, but don't support I/O wakeup. To resolve this, convert the existing blacklist approach to an explicit, whitelist support, in which only SoCs which are known to support I/O wakeup are listed. (At present, this only includes OMAP34xx, OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.) Also, the current code incorrectly detects the presence of a software-controllable I/O chain clock on several chips that don't support it. This results in writes to reserved bitfields, unnecessary delays, and console messages on kernels running on those chips: http://www.spinics.net/lists/linux-omap/msg58735.html Convert this test to a feature test with a chip-by-chip whitelist. Thanks to Dave Hylands <dhylands@gmail.com> for reporting this problem and doing some testing to help isolate the cause. Thanks to Steve Sakoman <sakoman@gmail.com> for catching a bug in the first version of this patch. Thanks to Russell King <linux@arm.linux.org.uk> for comments. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Dave Hylands <dhylands@gmail.com> Cc: Steve Sakoman <sakoman@gmail.com> Tested-by: NSteve Sakoman <sakoman@gmail.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 05 10月, 2011 1 次提交
-
-
由 Nishanth Menon 提交于
An API which translates a standard hwmod name to corresponding platform_device is useful for drivers when they need to look up the device associated with a hwmod name to map back into the device structure pointers. These ideally should be used by drivers in mach directory. Using a generic hwmod name like "gpu" instead of the actual device name which could change in the future, allows us to: a) Could in effect help replace apis such as omap2_get_mpuss_device, omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device, etc.. b) Scale to more devices rather than be restricted to named functions c) Simplify driver's platform_data from passing additional fields all doing the same thing with different function pointer names just for accessing a different device name. Signed-off-by: NNishanth Menon <nm@ti.com> [b-cousson@ti.com: Adapt it to the new pdev pointer inside od, remove the unneeded helpers, and fold the next patch here] Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 27 9月, 2011 12 次提交
-
-
由 Benoit Cousson 提交于
Add SoC specific map_io function to be used by the generic DT board file. This is an intermediate step before having some generic DT aware map_io function. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
These address definitions are OMAP1 specific can be in single source file. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
hardware.h is not needed here and let the definition for struct clk to come via linux/clk.h. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jhnikula@gmail.com> Cc: Paul Wamsley <paul@pwsan.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
Rationale here is to remove one global variable and to make possible to have variable size McBSP register maps inside SoC. Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jarkko Nikula 提交于
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: NJarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: NTony Lindgren <tony@atomide.com>
-