... rather than the clock names themselves.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

... which now means no driver requests the "armxor_ck" clock directly.
Also, fix the error handling for clk_get(), ensuring that we propagate
the error returned from clk_get().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

By providing a dummy ick for OMAP1510 and OMAP310, we avoid having
SoC conditional clock information in i2c-omap.c.  Also, fix the
error handling by making sure we propagate the error returned via
clk_get().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

On OMAP1, the I2C functional clock (fck) is the armxor_ck, so there's
no need to get "armxor_ck" separately.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

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>

... rather than the clock names themselves.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Eliminate the OMAP1 vs OMAP2 clock knowledge in the MMC driver.
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>

Eliminate the OMAP1 vs OMAP2 clock knowledge in the watchdog driver.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This eliminates the need for separate OMAP24xx and OMAP34xx clock
requesting code sections.
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>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

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>

This is needed to use these with the clkdev helpers.
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>

which only has to return clk->parent.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Nothing makes any use of these functions, so there's little point in
providing them.
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>

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>

Nothing tests the clock flags for this bit, so it serves no purpose.
Remove it.
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>

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>