Rather than introducing a special 'mcbsp_clk' with code behind it in
mach-omap*/mcbsp.c to handle the SoC specifics, arrange for the mcbsp
driver to be like any other driver. mcbsp requests its fck and ick
clocks directly, and the SoC specific code deals with selecting the
correct clock.
There is one oddity to deal with - OMAP1 fiddles with the DSP clocks
and DSP reset, so we move this to the two callback functions.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Convert OMAP MMC driver to match clocks using the device ID and a
connection ID rather than a clock name. This allows us to eliminate
the OMAP1/OMAP2 differences for the function clock.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
By providing a dummy clock node, we can eliminate the SoC conditional
clock handing in the OMAP drivers, moving this knowledge out of the
driver and into the machine clock support code.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This stops things blowing up if a 'struct clk' to be passed more
than once to clk_register(), which will be required when we decouple
struct clk's from their names.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It makes no sense to have the CKCTL rate selection implemented as a flag
and a special exception in the top level set_rate/round_rate methods.
Provide CKCTL set_rate/round_rate methods, and use these for where ever
RATE_CKCTL is used and they're not already overridden. This allows us
to remove the RATE_CKCTL flag.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
propagate_rate() is recursive, so it makes sense to minimise the
amount of stack which is used for each recursion. So, rather than
recursing back into it from the ->recalc functions if RATE_PROPAGATES
is set, do that test at the higher level.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We've always called propagate_rate() in the parent function to
the .set_rate methods, so there's no point having the .set_rate
methods also call this heavy-weight function - it's mere
duplication of what's happening elsewhere.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Move the clock propagation calls for set_parent and set_rate into
the core omap clock code, rather than having these calls scattered
throughout the OMAP1 and OMAP2 implementations.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
... to eliminate unnecessary padding. We have rather a lot of these
structures, so eliminating unnecessary padding results in a saving of
1488 bytes.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
clk->owner is always NULL, so its existence doesn't serve any useful
function other than bloating the kernel by 992 bytes. Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The original code in omap2_clk_wait_ready() used to check the low 8
bits to determine whether they were within the FCLKEN or ICLKEN
registers. Specifically, the test is satisfied when these offsets
are used:
CM_FCLKEN, CM_FCLKEN1, CM_CLKEN, OMAP24XX_CM_FCLKEN2, CM_ICLKEN,
CM_ICLKEN1, CM_ICLKEN2, CM_ICLKEN3, OMAP24XX_CM_ICLKEN4
OMAP3430_CM_CLKEN_PLL, OMAP3430ES2_CM_CLKEN2
If one of these offsets isn't used, omap2_clk_wait_ready() merely
returns without doing anything. So we should use the non-wait clkops
version instead and eliminate that conditional.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rather than employing run-time tests in omap2_clk_wait_ready() to
decide whether we need to wait for the clock to become ready, we
can set the .ops appropriately.
This change deals with the OMAP24xx and OMAP34xx conditionals only.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
PARENT_CONTROLS_CLOCK just makes enable/disable no-op, and is
functionally an alias for ALWAYS_ENABLED. This can be handled
in the same way, using clkops_null.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
... and use it for clocks which are ALWAYS_ENABLED. These clocks
use a non-NULL enable_reg pointer for other purposes (such as
selecting clock rates.)
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Collect up all the common enable/disable clock operation functions
into a separate operations structure.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drivers/char/nvram.c uses rtc_lock, that (on ARM) is only defined if
RTC_DRV_CMOS is enabled.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
"flash" is a very generic name for a platform_driver that is only
available on SA11x0.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Nicolas Pitre <nico@marvell.com>
SPIN_LOCK_UNLOCKED is deprecated as lockdep cannot properly work with
locks initialized with it.
This fix is necessary to compile the linux-rt tree for ARM.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Steven Rostedt <srostedt@redhat.com>
In omap24xx_cpu_suspend assembly routine, the r2 register which holds
the address of the SDRC_POWER reg is set to zero before the value is
written back triggering a fault due to writing to address zero.
It's hard to tell where this change was introduced since this file
has been moved and merged.
While this fix prevents a crash, suspend on my n810 is broken with
current kernels. I never come out of suspend.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
By Ingo Molnar, interrupts are not masked by default.
(refer to 76d2160147)
But if interrupts are not masked, the processor can wake up while in
Suspend-to-RAM state by an external interrupt. For example, if an
OMAP3 board is connected to Host PC by USB and entered to Suspend-to-RAM
state, it wake up automatically by M_IRQ_92. The disable_irq() function
can't disable the interrupt in H/W level, So I modified
arch/arm/mach-omap2/irq.c
Signed-off-by: Kim Kyuwon <chammoru@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When 32 kHz timer is used the min_delta_ns should be initialized so
that it reflects the timer programming cost. A write to the timer
device will be usually posted, but it takes roughly 3 cycles before
it is effective. If the timer is reprogrammed before that, the CPU
will stall until the previous write completes. This was pointed out by
Richard Woodruff.
Since the lower bound for min_delta_ns is 1000, the change is visible
only with tick rates less than 3 MHz.
Also note that the old value is incorrect for 32 kHz also due to
a rounding error, and it can cause the timer queue to hang (due to
clockevent code trying to program the timer with zero ticks).
Signed-off-by: Aaro Koskinen <Aaro.Koskinen@nokia.com>
Reviewed-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The naming accidentally broke while changing the name for the
driver to not to conflict with the other mmc driver.
Signed-off-by: Tony Lindgren <tony@atomide.com>
This has similar symptoms than 66c23551b1
where just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch
can cause incorrect dump_stack(). Here it can happen if channel has been
used before and the channel flags variable holds old status.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
CSR must be cleared before invoking the callback.
If the callback function starts a new, fast DMA transfer on the same
channel, the completion status might lost if CSR is cleared after
the callback invocation.
Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
A spin_lock deadlock will occur when omap_mcbsp_request() is invoked.
omap_mcbsp_request()
\- clk_enable(mcbsp->clk) [takes and holds clockfw_lock]
\- omap2_clk_enable()
\- _omap2_clk_enable()
\- omap_mcbsp_clk_enable()
\- clk_enable(child clock) [tries for clockfw_lock again]
mcbsp_clk is a virtual clock and it comprises several child clocks. when
enable mcbsp_clk in omap_mcbsp_request(), the enable function of mcbsp_clk
will enable its child clocks, then the deadlock occurs.
The solution is to remove the virtual clock and enable these child clocks in
omap_mcbsp_request() directly.
Signed-off-by: Stanley.Miao <stanley.miao@windriver.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code
powerpc/pseries: Correct VIO bus accounting problem in CMO env.
powerpc: More printing warning fixes for the l64 to ll64 conversion
powerpc: Remove arch/ppc cruft from Kconfig
powerpc: Printing fix for l64 to ll64 conversion: phyp_dump.c
powerpc/embedded6xx: Update defconfigs
powerpc/8xx: Update defconfigs
powerpc/86xx: Update defconfigs
powerpc/83xx: Update defconfigs
powerpc/85xx: Update defconfigs
powerpc/mpc8313erdb: fix kernel panic because mdio device is not probed
powerpc/4xx: Update multi-board PowerPC 4xx defconfigs
powerpc/44x: Update PowerPC 44x defconfigs
powerpc/40x: Update PowerPC 40x defconfigs
powerpc/85xx: Fix typo in mpc8572ds dts
powerpc/44x: Warp patches for the new NDFC driver
powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
When there are multiple L1-aliasing userland mappings of the same physical
page, we currently remap each of them uncached, to prevent VIVT cache
aliasing issues. (E.g. writes to one of the mappings not being immediately
visible via another mapping.) However, when we do this remapping, there
could still be stale data in the L2 cache, and an uncached mapping might
bypass L2 and go straight to RAM. This would cause reads from such
mappings to see old data (until the dirty L2 line is eventually evicted.)
This issue is solved by forcing a L2 cache flush whenever the shared page
is made L1 uncacheable.
Ideally, we would make L1 uncacheable and L2 cacheable as L2 is PIPT. But
Feroceon does not support that combination, and the TEX=5 C=0 B=0 encoding
for XSc3 doesn't appear to work in practice.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
m68knommu: fix 5329 ColdFire periphal addressing
uclinux: add process name to allocation error message
m68knommu: correct the mii calculations for 532x ColdFire FEC
m68knommu: add ColdFire M532x to the FEC configuration options
m68knommu: fix syscall restarting
m68knommu: remove the obsolete and long unused comempci chip support
m68knommu: remove the no longer used PCI support option
m68knommu: remove obsolete and unused eLIA board
m68knommu: set NO_DMA
m68knommu: fix cache flushing for the 527x ColdFire processors
m68knommu: fix ColdFire 5272 serial baud rates in mcf.c
m68knommu: use one exist from execption
Commit d7b1956fed ("DMI: Introduce
dmi_first_match to make the interface more flexible") introduced compile
errors like the following when !CONFIG_DMI
drivers/ata/sata_sil.c: In function 'sil_broken_system_poweroff':
drivers/ata/sata_sil.c:713: error: implicit declaration of function 'dmi_first_match'
drivers/ata/sata_sil.c:713: warning: initialization makes pointer from integer without a cast
We just need a dummy version of dmi_first_match() to fix this all up.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Schedule a vblank signal, kill the process, and we'll go walking over freed
memory. Given that no open-source userland exists using this, nor have I
ever heard of a consumer, just let this code die.
Signed-off-by: Eric Anholt <eric@anholt.net>
Requested-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Aaro says:
> With spinlock debugs enabled I get might_sleep() warnings when using
> ptrace.
tracked down to a missing enable_irq before calling do_undefinstr().
Reported-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arch/arm/mach-msm/board-halibut.c:45: error: implicit declaration of function 'MSM_GPIO_TO_INT'
arch/arm/mach-msm/board-halibut.c:45: error: initializer element is not constant
arch/arm/mach-msm/board-halibut.c:45: error: (near initialization for 'smc91x_resources[1].start')
arch/arm/mach-msm/board-halibut.c:46: error: initializer element is not constant
arch/arm/mach-msm/board-halibut.c:46: error: (near initialization for 'smc91x_resources[1].end')
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
