Remove unnecessary declaration of structure omap_dm_timer from dmtimer.h and
move the actual declaration of structure omap_dm_timer towards top of dmtimer.h
to avoid any compilation errors.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
The OMAP2+ system timer code stores the physical address of the timer
but never uses it. Remove this and clean-up the code by removing the
local variable "size" and changing the names of the local variables
mem_rsrc and irq_rsrc to mem and irq, respectively.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
The omap_dm_timer_prepare function is a local function only used in the
dmtimer.c file. Therefore, make this a static function and remove its
declaration from the dmtimer.h file.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Only OMAP1 devices use the omap_dm_timer_reset() and so require the
omap_dm_timer_wait_for_reset() and __omap_dm_timer_reset() functions.
Therefore combine these into a single function called omap_dm_timer_reset()
and simplify the code.
The omap_dm_timer_reset() function is now the only place that is using the
omap_dm_timer structure member "sys_stat". Therefore, remove this member and
just use the register offset definition to simplify and clean-up the code. The
TISTAT register is only present on revision 1 timers and so check for this in
the omap_dm_timer_reset() function.
Please note that for OMAP1 devices, the TIOCP_CFG register does not have the
clock-activity field and so when we reset the timer for an OMAP1 device we
only need to configure the idle-mode field in the TIOCP_CFG register.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
The __omap_dm_timer_set_source() function is only used by the system timer
(clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
remove this code from the dmtimer driver and move it to the system timer
code for OMAP2+ devices.
The current __omap_dm_timer_set_source() function calls clk_disable() before
calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
omap_hwmod_enable() to after the call to clk_set_parent() in
omap_dm_timer_init_one().
The function omap_hwmod_setup_one() will enable the timers functional clock
and therefore increment the use-count of the functional clock to 1.
clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
clk_disable() before calling clk_set_parent() to decrement the use-count.
Hence, avoid these extra calls to disable and enable the functional clock by
moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
clk_set_parent().
We can also remove the delay from the __omap_dm_timer_set_source() function
because enabling the clock will now be handled via the HWMOD framework by
calling omap_hwmod_setup_one(). Therefore, by moving the calls to
omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
clk_set_parent().
It should be safe to move these hwmod calls to later in the
omap_dm_timer_init_one() because other calls to the hwmod layer that occur
before are just requesting resource information.
Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
with the following configurations:
1. CONFIG_OMAP_32K_TIMER=y
2. CONFIG_OMAP_32K_TIMER=y and boot parameter "clocksource=gp_timer"
3. CONFIG_OMAP_32K_TIMER not set
4. CONFIG_OMAP_32K_TIMER not set and boot parameter "clocksource=gp_timer"
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Whenever we call the function omap_dm_timer_set_source() to set the clock
source of a dmtimer we look-up the dmtimer functional clock source by
calling clk_get(). This is not necessary because on requesting a dmtimer
we look-up the functional clock source and store it in the omap_dm_timer
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because the same interrupt
enable register is used to disable interrupts. However, some timer instances
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1,
2 and 10 need this function and for OMAP5 all timers need this function.
Please note that the interrupt disable function has been written so that it
can be used by all OMAP devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The OMAP DMTIMERs can generate an interrupt when the timer counter value
matches the value stored in the timer's match register. When using this
feature spurious interrupts were seen, because the compare logic is being
enabled before the match value is loaded and according to the documentation
the match value must be loaded before the compare logic is enable.
The reset value for the timer counter and match registers is 0 and hence,
by enabling the compare logic before the actual match value is loaded a
spurious interrupt can be generated as the reset values match.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Restoring the timer interrupt status is not possible because writing a 1 to any
bit in the register clears that bit if set and writing a 0 has no affect.
Furthermore, if an interrupt is pending when someone attempts to disable a
timer, the timer will fail to transition to the idle state and hence it's
context will not be lost. Users should take care to service all interrupts
before disabling the timer.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
a fix was added to prevent timer1 being reset in the function
omap_dm_timer_reset() because timer1 was being used as the system timer for
OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the "timer->posted" variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which was before the
omap_dm_timer_enable_posted() function was introduced. Although this is a
regression from the original code it only impacts performance and so is not
needed for stable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The only thing omap_init_consistent_dma_size() does is increase the
consistent DMA size if CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is defined.
Increasing the consistent DMA size should no longer be needed with CMA
in place.
This patch removes omap_init_consistent_dma_size() and also
arch/arm/mach-omap2/io.c:omap_common_init_early() which becomes an empty
function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[tony@atomide.com: updated for moved dma.h]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Now mach/hardware.h is empty for omap2+ and can be
removed except for plat-omap/dmtimer.c for omap1.
Also the include of mach/irqs.h can now be removed
for shared plat-omap/i2c.c as it's no longer needed.
Signed-off-by: Tony Lindgren <tony@atomide.com>
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Currently OMAP timers can be requested by requesting any available or by a
numerical device ID. If a specific timer is required because it has a particular
capability, such as can interrupt the on-chip DSP in addition to the ARM CPU,
then the user needs to know the device ID of the timer with this feature.
Therefore, add a new API called omap_dm_timer_request_by_cap() that allows
drivers to request a timer by capability.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* code:
http://www.spinics.net/lists/linux-omap/msg80520.html
Fix includes for fpga.h by making fpga.h local
to mach-omap1. The common code in plat-omap just
needs to know the struct h2p2_dbg_fpga, which can
be local to debug-leds.c.
This also fixes the braindead <../*.h> style includes
that got accidentally added with search and replace
during the cleanup.
Signed-off-by: Tony Lindgren <tony@atomide.com>
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* code:
http://www.spinics.net/lists/linux-omap/msg80520.html
Note that eventually when the omap1 specific drivers
are fixed to not use cpu_is_omap macros and not depend
on mach/hardware.h, this patch can be reverted and these
headers can be local. But since just fixing the drivers for
omap2+ is already a big enough hassle, let's deal
with that properly first.
[tony@atomide.com: also drop unused include for ispvideo.c]
Signed-off-by: Tony Lindgren <tony@atomide.com>
This code will be eventually in drivers, and for the
code in the drivers we don't want to have any cpu_is_omap
usage. Those macros should be private to arch/arm/mach-omap1
and arch/arm/mach-omap2.
To fix this, let's move the define for dma_omap2plus()
to dma-omap.h, and use the existing dma_attr passed in
the platform_data as the revision registers are what they
are.
Note that we can now also remove the relative includes
introduced by the recent clean-up patches.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:
http://www.spinics.net/lists/linux-omap/msg80520.html
Let's add plat/debug-devices.h for debug_card_init()
to fix the relative includes.
Note that drivers must not use this header as it will
break build for omap2+ CONFIG_MULTIPLATFORM builds.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Most of the prototypes in plat-omap/common.h are not
common to omap1 and omap2+, they are local to omap2+
and should not be in plat-omap/common.h.
The only shared function prototype in this file is
omap_init_clocksource_32k(), let's put that into
counter-32k.h.
Note that the new plat/counter-32k.h must not be
included from drivers, that will break omap2+ build
for CONFIG_MULTIPLATFORM.
Signed-off-by: Tony Lindgren <tony@atomide.com>
This code should be private to mach-omap2.
The only use for it in for omap1 has been in dmtimer.c
to check for context loss. However, omap1 does not
lose context during idle, so the code is not needed.
Further, omap1 timer has OMAP_TIMER_ALWON set, so omap1
was not hitting omap_pm_get_dev_context_loss_count()
test.
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:
http://www.spinics.net/lists/linux-omap/msg80520.html
To fix this for the shared i2c.h, let's re-introduce
a minimal plat/i2c.h.
Note that drivers must not use this header as it will
break build for omap2+ CONFIG_MULTIPLATFORM builds.
Signed-off-by: Tony Lindgren <tony@atomide.com>
The common code should not have any omap1 or omap2+
specific code, and should not need to call the cpu_is_omap
macros.
The only remaining user for cpu_is_omap macros is
omap_i2c_nr_ports(). Let's make those checks in
the omap specific implementation of omap_i2c_add_bus()
instead in order to remove cpu_is_omap usage from
the common code.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Let's make the omap2+ specific parts private to mach-omap2.
This leaves just a minimal shared code into plat-omap like
it should be.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Most of the defines are specific to omap1 and omap2+,
and should be in the local headers. Only minimal function
prototypes need to be shared.
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:
http://www.spinics.net/lists/linux-omap/msg80520.html
So this patch re-adds a minimal plat/sram.h.
The new plat/sram.h must not be included from drivers,
that will break build for omap2+ CONFIG_MULTIPLATFORM.
Note that this patch temporarily adds two more
relative includes; Those will be removed in the
following patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Bug fixes for a number of ARM platforms, mostly OMAP, imx and at91.
These come a little later than I had hoped but unfortunately we
had a few of these patches cause regressions themselves and had to
work out how to deal with those in the meantime.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUAUIwDWmCrR//JCVInAQJREBAAwkH8kI/Xl3JqTfP4A69P8fOdD0p1ZC08
QHzRdgXixpssiIC2wKwM4N4Ine23p1sbGIHHjnDMyTytFXGl7RIRjIXucm3NVBq5
bw5uW5HziO8Pg+uA0ieZiqDEvroIw6U0AxKEKrZ9Fpc9XBr9RArIsRtTNyoFli+2
JBgQ5eHYq4cq3cmX1XkU4q7RVUUA6XE/Vqs9IT6dfK4x56RR0Huri/ldkxqsLNj+
HdN+7QoTz4wUjhF1tqCZt/3bo1dUONpDu4DJPnzscQA77HplQsSF3MsY5AEajjsA
8mKG6AOjmvZsqJFjGYsq/r4DerPj2ME+1z84y5xrMI5WUxJL/6fj5uGTNsdVxifW
scywLEG9bRjCehgoAg26XZWNKy6NuzkONxR9fjbrj9vGopje23VT5OXgeygesUD2
WTbI3qeZz/O1esDBQ9D025K3a9kTCsJltstO2oVubGWgqvG2oK8LTqjeu8DwM2ti
tloNQmylOKOaxnYm9TSouDRpQ0MPFVxMxe1VwFxzry7Mz3+lfyC2/fiYpZLC+OgQ
2TjclUB4aIXLPVJAsAxu9Z8vEhx11EtghkeWy5Hk4TT3dXgn77MnyAPWp594DjQ0
WdHrCNCK+K0Kk7R2FDkaZi2CvdCd1+AS6xyXjO3CmA7HbWLDEUlRg4/24/AzLK3j
rO+bw62yQKg=
=IDdm
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull arm-soc fixes from Arnd Bergmann:
"Bug fixes for a number of ARM platforms, mostly OMAP, imx and at91.
These come a little later than I had hoped but unfortunately we had a
few of these patches cause regressions themselves and had to work out
how to deal with those in the meantime."
* tag 'fixes-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (38 commits)
Revert "ARM i.MX25: Fix PWM per clock lookups"
ARM: versatile: fix versatile_defconfig
ARM: mvebu: update defconfig with 3.7 changes
ARM: at91: fix at91x40 build
ARM: socfpga: Fix socfpga compilation with early_printk() enabled
ARM: SPEAr: Remove unused empty files
MAINTAINERS: Add arm-soc tree entry
ARM: dts: mxs: add the "clock-names" for gpmi-nand
ARM: ux500: Correct SDI5 address and add some format changes
ARM: ux500: Specify AMBA Primecell IDs for Nomadik I2C in DT
ARM: ux500: Fix build error relating to IRQCHIP_SKIP_SET_WAKE
ARM: at91: drop duplicated config SOC_AT91SAM9 entry
ARM: at91/i2c: change id to let i2c-at91 work
ARM: at91/i2c: change id to let i2c-gpio work
ARM: at91/dts: at91sam9g20ek_common: Fix typos in buttons labels.
ARM: at91: fix external interrupt specification in board code
ARM: at91: fix external interrupts in non-DT case
ARM: at91: at91sam9g10: fix SOC type detection
ARM: at91/tc: fix typo in the DT document
ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driverDate:Wed, 17 Oct 2012 13:55:55 -0500
...
In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.
Move USB platform_data to <linux/platform_data/omap-usb.h>
and add a minimal drivers/mfd/usb-omap.h.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Partha Basak <parthab@india.ti.com>
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Felipe Balbi <balbi@ti.com>
[tony@atomide.com: updated for local mfd/usb-omap.h]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Let's move what we can from plat/usb.h to the local usb.h
for ARM common zImage support.
This is needed so we can remove plat/usb.h for ARM common
zImage support.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Partha Basak <parthab@india.ti.com>
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: linux-usb@vger.kernel.org
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
For omap1, we'll keep mach/serial.h around for 8250.c hardware
workarounds. For omap2+, we no longer need mach/serial.h and
can make it local to mach-omap2.
Signed-off-by: Tony Lindgren <tony@atomide.com>
This allows us to eventually move omap2+ to generic
debug code that's configured in Kconfig for the port.
Signed-off-by: Tony Lindgren <tony@atomide.com>
window to remove most of the remaining plat includes to get us
closer to ARM common zImage support.
To avoid a huge amount of trivial merge conflicts with includes,
this branch is based on several small topic branches coordinated
with the driver subsystem maintainers. These branches are based on
v3.7-rc1 and can also be merged into the related driver subsystem
branches as needed:
omap-for-v3.8/cleanup-headers-prepare few trivial driver changes
omap-for-v3.8/cleanup-headers-dma move of the DMA header
omap-for-v3.8/cleanup-headers-gpmc GPMC and MTD changes
omap-for-v3.8/cleanup-headers-mmc MMC related changes
omap-for-v3.8/cleanup-headers-dss DSS related changes
omap-for-v3.8/cleanup-headers-asoc ASoC related changes
Note that for the dma-omap.h, it was decided that it should be
is completed. For the related discussion, please see:
https://patchwork.kernel.org/patch/1519591/#
After these patches we still have a few plat headers remaining
that will be handled in later pull requests.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQgLn6AAoJEBvUPslcq6VztJIQAMDLmUr4XRa0pV9ASPieMSnP
LqXQ8Gpr8JP6I2A7mjj5K/PVvU2PCIgefX5/F7PssWeDzPs1p6T5eQc6/Oo88j+k
6xIaPJtuU6aiMKiH4QJBU9mfFZN4tvKNX8sJZ4YhzAmkKshwSd2XdWQlkSWYV7Ii
QFRXOdYdX3dgvt3Pv5LYhFMlRDzXlMtCNkdyO0C5yDc038FvT5kxcgpOJ99ndX1F
aSpNPchDwEXP7WZl3O7uZs732hRHQbKraMkzalVJ5mgvLSwF7VsB+BLdjOgRqFfg
edpAPt/izpTk7cg7RQiItrW3xz3eSiN/fiAg2wLvxr6ewzB5DguPLa6DNPF+uyup
BlpQAvNsICIixfKb/qimQBOkB71TTRxqvBnG0Vt/cExS1dTuWlhyCYzA6dhZtl+w
7ETCo7Mmj+L9T1EfzhMPgjWvMZ4Luli4NHSUYxMl5Cs8nu1y6ytIXxH9e0mnZAbK
n4ANoIuFE3ZueXWnHAVCOs0YZj2F1OLB+mFkIFg3OVpB4WCXiOTgJuDNsAAQNS3/
VsYVehNFRB/E/lMWkN293j95LRSwl/sIKbvlpxe7M3XQi4IWh1bDPwcg1YhGPxRV
HIuQSSMIIzcsFoDqbQYv9qzpvslfee58fBV0L8BzMyXNd1lYzWJ5Af6A8ddSVVFS
Hh+btZObC1zP/2IKbImk
=HUTj
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v3.8/cleanup-headers-signed' into omap-for-v3.8/cleanup-headers-serial-take2
This is the first set of omap cleanup patches for v3.8 merge
window to remove most of the remaining plat includes to get us
closer to ARM common zImage support.
To avoid a huge amount of trivial merge conflicts with includes,
this branch is based on several small topic branches coordinated
with the driver subsystem maintainers. These branches are based on
v3.7-rc1 and can also be merged into the related driver subsystem
branches as needed:
omap-for-v3.8/cleanup-headers-prepare few trivial driver changes
omap-for-v3.8/cleanup-headers-dma move of the DMA header
omap-for-v3.8/cleanup-headers-gpmc GPMC and MTD changes
omap-for-v3.8/cleanup-headers-mmc MMC related changes
omap-for-v3.8/cleanup-headers-dss DSS related changes
omap-for-v3.8/cleanup-headers-asoc ASoC related changes
Note that for the dma-omap.h, it was decided that it should be
is completed. For the related discussion, please see:
https://patchwork.kernel.org/patch/1519591/#
After these patches we still have a few plat headers remaining
that will be handled in later pull requests.
This reverts commit 957ee7270d
(serial: omap: fix software flow control).
As Russell has pointed out, that commit isn't fixing
Software Flow Control at all, and it actually makes
it even more broken.
It was agreed to revert this commit and use Russell's
latest UART patches instead.
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This allows us to get rid of the ifdefs in 8250.c.
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 8f31cefe (ARM: OMAP2+: select PINCTRL in Kconfig)
added select PINCTRL, but accdentally added it to a wrong
location.
We want to select if for ARCH_OMAP2PLUS, not for
ARCH_OMAP2PLUS_TYPICAL.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We want to remove plat/cpu.h. To do this, let's first split
it to private soc.h to mach-omap1 and mach-omap2. We have to
keep plat/cpu.h around until the remaining drivers are fixed,
so let's include the local soc.h in plat/cpu.h and for drivers
still including plat/cpu.h.
Once the drivers are fixed not to include plat/cpu.h, we
can remove the file.
This is needed for the ARM common zImage support.
[tony@atomide.com: updated to not print a warning]
Signed-off-by: Tony Lindgren <tony@atomide.com>
To facilitate the ARM single image work, split
arch/arm/plat-omap/include/plat/clkdev_omap.h into the
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h files.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the "plat/" symlink.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed to remove duplicate clock.h includes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Duplicate arch/arm/plat-omap/clock.c into arch/arm/mach-omap1/clock.c
and arch/arm/mach-omap2/clock.c. This is to support people who are working
on the ARM single image kernel and the OMAP common clock framework
conversion.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Moving plat/omap-secure.h locally to mach-omap2/
as part of single zImage work
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
omap_reserve() callback is defned only for mach-omap2.
So, moving definition of omap_reserve() to mach-omap2.
This helps is moving plat/omap_secure.h local to
mach-omap2
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We must move this for ARM common zImage support.
Note that neither drivers/media/rc/ir-rx51.c or
drivers/media/platform/omap3isp/ispvideo.c need
to include omap-pm.h, so this patch removes the
include for those files.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
