GitHub/LineageOS/android_kernel_motorola_exynos9610.git
11 years agoARM: AM33xx: clock: drop obsolete clock data
Paul Walmsley [Mon, 10 Sep 2012 20:17:50 +0000 (14:17 -0600)]
ARM: AM33xx: clock: drop obsolete clock data

Drop the now-obsolete AM33xx original OMAP clock data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
11 years agoARM: OMAP3xxx: clk: drop obsolete clock data
Paul Walmsley [Mon, 10 Sep 2012 20:08:12 +0000 (14:08 -0600)]
ARM: OMAP3xxx: clk: drop obsolete clock data

Drop the now-obsolete OMAP3xxx original OMAP clock data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
11 years agoARM: OMAP3: clock: Cleanup !CONFIG_COMMON_CLK parts
Rajendra Nayak [Fri, 27 Apr 2012 11:05:52 +0000 (16:35 +0530)]
ARM: OMAP3: clock: Cleanup !CONFIG_COMMON_CLK parts

Clean all #ifdef's added to OMAP3 clock code to make it COMMON clk
ready, not that CONFIG_COMMON_CLK is enabled.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: remove some ifdefs in mach-omap2/io.c]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP44xx: clock: drop obsolete clock data
Paul Walmsley [Mon, 10 Sep 2012 20:07:48 +0000 (14:07 -0600)]
ARM: OMAP44xx: clock: drop obsolete clock data

Drop the now-obsolete OMAP44xx original OMAP clock data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
11 years agoARM: OMAP4: clock: Cleanup !CONFIG_COMMON_CLK parts
Rajendra Nayak [Tue, 6 Nov 2012 22:28:25 +0000 (15:28 -0700)]
ARM: OMAP4: clock: Cleanup !CONFIG_COMMON_CLK parts

Clean all #ifdef's added to OMAP4 clock code to make it COMMON clk
ready, now that CONFIG_COMMON_CLK is enabled.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: remove some ifdefs in mach-omap2/io.c]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP: hwmod: Cleanup !CONFIG_COMMON_CLK parts
Rajendra Nayak [Fri, 27 Apr 2012 11:02:53 +0000 (16:32 +0530)]
ARM: OMAP: hwmod: Cleanup !CONFIG_COMMON_CLK parts

Clean all #ifdef's added as part of fixing the clkdm
accesses from hwmod.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP: clock: Switch to COMMON clk
Rajendra Nayak [Fri, 27 Apr 2012 10:57:51 +0000 (16:27 +0530)]
ARM: OMAP: clock: Switch to COMMON clk

Select COMMON_CLK for all OMAP2+ SoCs and switch over to using new
data files for OMAP2/3/4.

The older data files will get removed in subsequent patches.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: move 'select COMMON_CLK' from ARCH_OMAP2PLUS_TYPICAL to
 the per-SoC and per-"arch" Kconfig sections]
[mturquette@ti.com: fixed up #ifdef mismatch in clock.h in previous
  patch which drops that change from this patch]
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP2: clock: Add 24xx data using common struct clk
Rajendra Nayak [Sun, 11 Nov 2012 04:22:28 +0000 (21:22 -0700)]
ARM: OMAP2: clock: Add 24xx data using common struct clk

The patch is the output from a python script which converts
from the old OMAP clk format to COMMON clk format using a
JSON parser in between which was developed by Paul Walmsley.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: replace omap2_init_clksel_parent() with
 omap2_clksel_find_parent_index(); reflowed macros; dropped 243x clkdev
 aliases in 242x file; added recalc_rate fn ptrs to APLL clocks;
 fixed some checkpatch warnings]
[mturquette@ti.com: removed deprecated variables from omap24x0_clk_init]
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: fixed boot crash due to missing clock init code; added twl.fck
 alias; fix DPLL rate initialization; fix APLL clocks and virt_prcm_set
 initialization]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP3: clock: Add 3xxx data using common struct clk
Rajendra Nayak [Fri, 2 Nov 2012 11:02:58 +0000 (05:02 -0600)]
ARM: OMAP3: clock: Add 3xxx data using common struct clk

The patch is the output from a python script which converts
from the old OMAP clk format to COMMON clk format using a
JSON parser in between which was developed by Paul Walmsley.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: AM3517/05: dropped bogus hsotgusb "ick" and "fck"
 clkdev aliases; added hsotgusb_fck alias; added emac_ick and emac_fck
 aliases; replace omap2_init_clksel_parent() with
 omap2_clksel_find_parent_index(); reflow macros and parent name
 lists; add clkdm_name argument to DEFINE_STRUCT_CLK_HW_OMAP macros]
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: AM33XX: clock: add clock data in common clock format
Vaibhav Hiremath [Tue, 6 Nov 2012 22:40:43 +0000 (15:40 -0700)]
ARM: AM33XX: clock: add clock data in common clock format

OMAP2/3/4 clock-tree data is migrated to common-clock framework,
so it is needed to do same for AM33XX device.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: replace omap2_init_clksel_parent() with
 omap2_clksel_find_parent_index(); modified to not use the AM33xx common
 clock data yet; updated patch description; reflowed the macros;
 updated DEFINE_STRUCT_CLK_HW_OMAP usage to include clkdm_name]
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP4: clock: Add 44xx data using common struct clk
Rajendra Nayak [Tue, 6 Nov 2012 22:41:08 +0000 (15:41 -0700)]
ARM: OMAP4: clock: Add 44xx data using common struct clk

This patch is output from updated omap hw data autogeneration scripts
mostly contributed by Mike Turquette, with some later fixes from me.
All data is added into a new cclock44xx_data.c file which will be
switched with clock44xx_data.c file in a later patch.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: replace omap2_init_clksel_parent() with
 omap2_clksel_find_parent_index(); reflowed macros; updated
 DEFINE_STRUCT_CLK_HW_OMAP macro to include clkdm_name;
 use macros for clksel mux+gate clocks; many other fixes]
[mturquette@ti.com: converted DPLL outputs to HSDIVIDER macro; trace_clk_div_ck
 has clkdm ops]
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: fixed the omap-gpmc.fck alias per commit a2e5b90b; fixed
 several checkpatch issues; moved the dpll3xxx.c clockdomain modifications to
 another patch]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP2+: clock: add OMAP CCF convenience macros to mach-omap2/clock.h
Paul Walmsley [Sun, 16 Sep 2012 16:45:54 +0000 (10:45 -0600)]
ARM: OMAP2+: clock: add OMAP CCF convenience macros to mach-omap2/clock.h

Define four convenience macros to be used in the upcoming OMAP2+
common clock framework port.  Although the use of these macros will
make the data somewhat more difficult to read, they significantly reduce
the number of lines in the output patch data.

Most of these were created by Rajendra Nayak and Mike Turquette, as
far as I know.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
[mturquette@ti.com: added DEFINE_CLK_OMAP_HSDIVIDER macro]
Signed-off-by: Mike Turquette <mturquette@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP: clock: Get rid of some clkdm assocations within clks
Rajendra Nayak [Mon, 14 May 2012 07:20:38 +0000 (12:50 +0530)]
ARM: OMAP: clock: Get rid of some clkdm assocations within clks

It's suspected that some of the clockdomain associations with clocks
can be removed from the clock data.  Drop several of these
associations to save diffstat and improve performance.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: removed most of the changes in this patch; modified patch
 description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
11 years agoARM: OMAP2+: clockdomain: bypass clockdomain handling when disabling unused clks
Mike Turquette [Fri, 9 Nov 2012 18:28:42 +0000 (11:28 -0700)]
ARM: OMAP2+: clockdomain: bypass clockdomain handling when disabling unused clks

The OMAP port to the common clk framework[1] resulted in spurious WARNs
while disable unused clocks.  This is due to _clkdm_clk_hwmod_disable
catching clkdm->usecount's with a value of zero.  Even less desirable it
would not allow the clkdm_clk_disable function pointer to get called due
to an early return of -ERANGE.

This patch adds a check for such a corner case by skipping the WARN and
early return in the event that clkdm->usecount and clk->enable_usecount
are both zero.  Presumably this could only happen during the check for
unused clocks at boot-time.

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/88824

Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: split the hwmod and clock disable cases; modified the
 code to skip the clockdomain handling during the disable-unused-clocks phase;
 added COMMON_CLK ifdef; removed include of clk-private.h at Mike's request]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP2+: hwmod: Invoke init_clkdm before other init functions
Vaibhav Hiremath [Mon, 9 Jul 2012 12:54:30 +0000 (18:24 +0530)]
ARM: OMAP2+: hwmod: Invoke init_clkdm before other init functions

Without this kernel would crash, since clkdm inside omap_hwmod
is accessed in some of the init functions like, _init_main_clk.

So call init_clkdm before _init_main_clk().

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP: clock: Define a function to enable clocks at init
Rajendra Nayak [Fri, 1 Jun 2012 08:32:49 +0000 (14:02 +0530)]
ARM: OMAP: clock: Define a function to enable clocks at init

Platform code can use omap2_clk_enable_init_clocks() to enable a
list of clocks that are needed to be enabled at init.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: added kerneldoc to non-trivial new function]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP: clock: list all clk_hw_omap clks to enable/disable autoidle
Rajendra Nayak [Fri, 1 Jun 2012 08:32:49 +0000 (14:02 +0530)]
ARM: OMAP: clock: list all clk_hw_omap clks to enable/disable autoidle

Platforms can call omap2_init_clk_hw_omap_clocks() to register a clock
using clk_hw_omap. omap2_clk_enable_autoidle_all() and
omap2_clk_disable_autoidle_all() can then be used to run through
all the clocks which support autoidle to enable/disable them.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: added kerneldoc on non-trivial new functions]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP2xxx: clock: add APLL rate recalculation functions
Paul Walmsley [Sat, 15 Sep 2012 05:18:20 +0000 (23:18 -0600)]
ARM: OMAP2xxx: clock: add APLL rate recalculation functions

OMAP2420 and OMAP2430 chips each have two on-chip APLLs.  When locked,
one APLL generates a 96 MHz rate; the other, a 54 MHz rate.
Previously we treated these clocks as fixed-rate clocks at the locked
rates, but this isn't quite right.  The locked rate should be returned
when the APLL is locked, and a zero rate should be returned when the
APLL is stopped.  This patch adds the infrastructure that will be used
by the CCF changes.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
11 years agoARM: OMAP2: clock: Convert to common clk
Rajendra Nayak [Fri, 27 Apr 2012 10:29:32 +0000 (15:59 +0530)]
ARM: OMAP2: clock: Convert to common clk

Convert all OMAP2 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP3: clock: Convert to common clk
Rajendra Nayak [Fri, 27 Apr 2012 10:23:48 +0000 (15:53 +0530)]
ARM: OMAP3: clock: Convert to common clk

Convert all OMAP3 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP4: clock: Convert to common clk
Mike Turquette [Sat, 10 Nov 2012 23:58:41 +0000 (16:58 -0700)]
ARM: OMAP4: clock: Convert to common clk

Convert all OMAP4 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.

This converts all apis which will be called directly from COMMON
clk to take a struct clk_hw parameter, and all the internal platform
apis to take a struct clk_hw_omap parameter.

Changes are based off the original patch from Mike Turquette.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: created new omap2_clksel_find_parent_index() rather than
 modifying omap2_init_clksel_parent(); moved clkhwops_iclk_wait to
 clkt_iclk.c to fix OMAP4-only builds; added clk-provider.h include to clock.h
 to try to fix some 3430-builds]
[mturquette@ti.com: squash patch for omap2_clkops_{en,dis}able_clkdm;
 omap2_dflt_clk_is_enabled should not enable clocks]
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul@pwsan.com: fix compiler warning; update to apply; added kerneldoc on
 non-trivial new functions; added the dpll3xxx clockdomain modifications]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP: hwmod: Fix up hwmod based clkdm accesses
Rajendra Nayak [Sat, 10 Nov 2012 23:58:41 +0000 (16:58 -0700)]
ARM: OMAP: hwmod: Fix up hwmod based clkdm accesses

hwmod uses deferencing the clk pointer to acccess the clkdm.
With COMMON clk hwoever this will need to be deferenced through
the clk_hw_omap pointer, so do the necessary changes.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
11 years agoARM: OMAP: clock: Nuke plat/clock.c & reuse struct clk as clk_hw_omap
Rajendra Nayak [Sat, 10 Nov 2012 23:58:40 +0000 (16:58 -0700)]
ARM: OMAP: clock: Nuke plat/clock.c & reuse struct clk as clk_hw_omap

plat/clock.c which has most of usecounting/locking infrastructure will
be used only for OMAP1 until that is moved to use COMMON clk.

reuse most of what plat/clock.h has while we move to common clk, and
move most of what 'struct clk' was as 'struct clk_hw_omap' which
will then be used to define platform specific parameters.
All usecounting/locking related variables from 'struct clk' are
dropped as they will not be used with 'struct clk_hw_omap'.

Based on the original changes from Mike Turquette.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
12 years agoMerge tag 'omap-cleanup-b2-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel...
Tony Lindgren [Fri, 9 Nov 2012 22:13:43 +0000 (14:13 -0800)]
Merge tag 'omap-cleanup-b2-for-3.8' of git://git./linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-prcm

Second set of OMAP PRCM cleanups for 3.8.

These patches remove the use of omap_prcm_get_reset_sources() from the
OMAP watchdog driver, and remove mach-omap2/prcm.c and
plat-omap/include/plat/prcm.h.

Basic test logs for this branch on top of Tony's cleanup-prcm branch
at commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33 are here:

    http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121108151646/

However, cleanup-prcm at 7fc54fd3 does not include some fixes
that are needed for a successful test.  With several reverts,
fixes, and workarounds applied, the following test logs were
obtained:

    http://www.pwsan.com/omap/testlogs/TEST_prcm_cleanup_b_3.8/20121108151930/

 which indicate that the series tests cleanly.

This second pull request updates one of the patches which broke
with rmk's allnoconfigs, and also updates the tag description to
indicate that 7fc54fd3 is building cleanly here.

12 years agoARM: OMAP2+: PRCM: remove obsolete prcm.[ch]
Paul Walmsley [Tue, 30 Oct 2012 02:59:29 +0000 (20:59 -0600)]
ARM: OMAP2+: PRCM: remove obsolete prcm.[ch]

arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h
are now completely unused and can be removed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call
Paul Walmsley [Tue, 30 Oct 2012 02:57:55 +0000 (20:57 -0600)]
ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call

The hwmod code unconditionally calls _omap4_disable_module() on all
SoCs when a module doesn't enable correctly.  This "worked" due to the
weak function omap4_cminst_wait_module_idle() in
arch/arm/mach-omap2/prcm.c, which was a no-op.  But now those weak
functions are going away - they should not be used.  So this patch
will now call the SoC-specific disable_module code, assuming it
exists.

Needs to be done before the weak function is removed, otherwise AM33xx
will crash early in boot.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros
Paul Walmsley [Tue, 30 Oct 2012 02:57:44 +0000 (20:57 -0600)]
ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros

Consolidate all of the copies of MAX_MODULE_HARDRESET_WAIT and
MAX_MODULE_SOFTRESET_WAIT into one place, arch/arm/mach-omap2/prm.h.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup
Paul Walmsley [Tue, 30 Oct 2012 02:57:39 +0000 (20:57 -0600)]
ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup

Split omap2_set_globals_prcm() into PRM, CM, and PRCM_MPU variants, since
these are all separate IP blocks.  This should make it easier to move the
PRM, CM, PRCM_MPU code into drivers/ in future patchsets.

At this point arch/arm/plat-omap/include/plat/prcm.h is empty; a
subsequent patch will remove it, and remove the #include from all the
files that #include it.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest()
Paul Walmsley [Tue, 30 Oct 2012 02:57:31 +0000 (20:57 -0600)]
ARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest()

Now that all users of mach-omap2/omap2_cm_wait_idlest() have been removed,
delete the function and its supporting macros and prototypes.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent...
Paul Walmsley [Tue, 30 Oct 2012 02:56:29 +0000 (20:56 -0600)]
ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions

Convert the OMAP clock code's _omap2_module_wait_ready() to use
SoC-independent CM functions that are provided by the CM code, rather
than using a deprecated function from mach-omap2/prcm.c.

This facilitates the future conversion of the CM code to a driver, and
also removes a mach-omap2/prcm.c user.  mach-omap2/prcm.c will be removed
by a subsequent patch.

Some modules have IDLEST registers that aren't in the CM module, such
as the AM3517 IDLEST bits.  So we also need a fallback function for
these non-CM odd cases.  Create a temporary one in mach-omap2/clock.c,
intended to exist until the SCM drivers are ready.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready()
Paul Walmsley [Tue, 30 Oct 2012 02:56:17 +0000 (20:56 -0600)]
ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready()

Convert the OMAP2xxx APLL code to use omap2_cm_wait_module_ready(),
and move the low-level CM register manipulation functions to
mach-omap2/cm2xxx.c.  The objectives here are to remove the dependency
on the deprecated omap2_cm_wait_idlest() function in
mach-omap2/prcm.c, so that code can be removed later; and move
low-level register accesses to the CM IP block to the CM code, which
will soon be moved into drivers/.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: board files: use SoC-specific system restart functions
Paul Walmsley [Tue, 30 Oct 2012 02:56:12 +0000 (20:56 -0600)]
ARM: OMAP2+: board files: use SoC-specific system restart functions

Modify the board files to use the SoC-specific system restart
functions.  At this point it's possible to remove omap_prcm_restart()
from mach-omap2/prcm.c.

While removing the prototypes for the now-unused restart functions, clean
up a few more obsolete prototypes in mach-omap2/clock.h.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: PRCM: create SoC-specific chip restart functions
Paul Walmsley [Tue, 30 Oct 2012 02:56:07 +0000 (20:56 -0600)]
ARM: OMAP2+: PRCM: create SoC-specific chip restart functions

Split omap_prcm_restart() from mach-omap2/prcm.c into SoC-specific
variants.  These functions need to be able to save the reboot reason
into the scratchpad RAM.  This implies a dependency on both the PRM
and SCM IP blocks, so they've been moved into their own file.  This
will eventually call functions in the PRM and SCM drivers, once those
are created.

Vaibhav Hiremath <hvaibhav@ti.com> identified an unused prototype in
the first version of this patch - now removed.  Tony Lindgren
<tony@atomide.com> noted a compile problem with some RMK Kconfigs;
resolved in this patch.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
12 years agoARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c
Paul Walmsley [Tue, 30 Oct 2012 02:56:00 +0000 (20:56 -0600)]
ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c

Collect all of the virt_prcm_set-specific clocktype code into
mach-omap2/clkt2xxx_virt_prcm_set.c.  Remove its dependency on the
'sclk' and 'vclk' global variables.  Those variables will be removed
by subsequent patches.

This is part of the process of cleaning up the OMAP2xxx clock code
and preparing for the removal of the omap_prcm_restart() function.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2xxx: clock: remove global 'dclk' variable
Paul Walmsley [Tue, 30 Oct 2012 02:55:53 +0000 (20:55 -0600)]
ARM: OMAP2xxx: clock: remove global 'dclk' variable

Remove the global 'dclk' variable, instead replacing it with a
variable local to the dpllcore clock type C file.  This removes some
of the special-case code surrounding the OMAP2xxx clock init.

This patch is a prerequisite for the removal of the
omap_prcm_restart() code from arch/arm/mach-omap2/prcm.c.  It also
cleans up some special-case OMAP2xxx clock code in the process.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)
Paul Walmsley [Tue, 30 Oct 2012 02:55:46 +0000 (20:55 -0600)]
ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)

Add SoC reset functions into the PRM code.  These functions are based
on code from mach-omap2/prcm.c.  They reset the SoC using the CORE DPLL
reset method (as opposed to one of the other two or three chip reset
methods).

Adding them here will facilitate their removal from
arch/arm/mach-omap2/prcm.c.  (prcm.c is deprecated.)

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io code
Paul Walmsley [Tue, 30 Oct 2012 02:50:21 +0000 (20:50 -0600)]
ARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io code

Get rid of the mach-omap2/common.c globals by moving the global
initialization for IP block addresses that must occur early into
mach-omap2/io.c.  In the process, remove the *_map_common_io*() and
SoC-specific *set_globals* functions.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agoARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources()
Paul Walmsley [Tue, 30 Oct 2012 02:49:45 +0000 (20:49 -0600)]
ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources()

omap_prcm_get_reset_sources() is now unused; so, remove it.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
12 years agowatchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
Paul Walmsley [Tue, 30 Oct 2012 02:49:44 +0000 (20:49 -0600)]
watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr

Previously the OMAP watchdog driver used a non-standard way to report
the chip reset source via the GETBOOTSTATUS ioctl.  This patch
converts the driver to use the standard WDIOF_* flags for this
purpose.

This patch may break existing userspace code that uses the existing
non-standard data format returned by the OMAP watchdog driver's
GETBOOTSTATUS ioctl.  To fetch detailed reset source information,
userspace code will need to retrieve it directly from the CGRM or PRM
drivers when those are completed.

Previously, to fetch the reset source, the driver either read a
register outside the watchdog IP block (OMAP1), or called a function
exported directly from arch/arm/mach-omap2.  Both approaches are
broken.  This patch also converts the driver to use a platform_data
function pointer.  This approach is temporary, and is due to the lack
of drivers for the OMAP16xx+ Clock Generation and Reset Management IP
block and the OMAP2+ Power and Reset Management IP block.  Once
drivers are available for those IP blocks, the watchdog driver can be
converted to call exported functions from those drivers directly.
At that point, the platform_data function pointer can be removed.

In the short term, this patch is needed to allow the PRM code to be
removed from arch/arm/mach-omap2 (it is being moved to a driver).

This version integrates a fix from Jon Hunter <jon-hunter@ti.com>
that avoids a NULL pointer dereference in a DT-only boot, and integrates
a patch commit message fix from Felipe Balbi <balbi@ti.com>.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Acked-by: Wim Van Sebroeck <wim@iguana.be>
[paul@pwsan.com: integrated pdata fix from Jon Hunter]
Cc: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: integrated changelog fix from Felipe Balbi]
Cc: Felipe Balbi <balbi@ti.com>
12 years agoARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
Paul Walmsley [Tue, 30 Oct 2012 02:49:44 +0000 (20:49 -0600)]
ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer

The OMAP watchdog timer driver directly calls a function exported by
code in arch/arm/mach-omap2.  This is not good; it tightly couples
this driver to the mach-omap2 integration code.  Instead, add a
temporary platform_data function pointer to abstract this function
call.  A subsequent patch will convert the watchdog driver to use this
function pointer.

This patch also moves the device creation code out of
arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c.
This is another step towards the removal of
arch/arm/mach-omap2/devices.c.

Cc: Wim Van Sebroeck <wim@iguana.be>
Acked-by: Wim Van Sebroeck <wim@iguana.be>
[paul@pwsan.com: skip wd_timer device creation when DT blob is present]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
12 years agoARM: OMAP1: CGRM: fix omap1_get_reset_sources() return type
Paul Walmsley [Tue, 30 Oct 2012 02:49:43 +0000 (20:49 -0600)]
ARM: OMAP1: CGRM: fix omap1_get_reset_sources() return type

An older version of the patch "ARM: OMAP1: create read_reset_sources()
function (for initial use by watchdog)" was sent upstream, which used
the wrong return type for the omap1_get_reset_sources() function.
Fix it to return a u32, which is what the WDTIMER platform_data
function pointer read_reset_sources() expects.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
12 years agoMerge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm
Tony Lindgren [Fri, 26 Oct 2012 20:32:22 +0000 (13:32 -0700)]
Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm

12 years agoMerge tag 'omap-cleanup-fixes-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel...
Tony Lindgren [Fri, 26 Oct 2012 20:18:19 +0000 (13:18 -0700)]
Merge tag 'omap-cleanup-fixes-a-for-3.8' of git://git./linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-headers

Several fixes for build failures and sparse warnings in the
OMAP cleanup-headers branch.  Intended for 3.8 cleanup.

Basic build, boot, and PM test logs are available from here:

    http://www.pwsan.com/omap/testlogs/cleanup-headers-compile-fixes-3.8/20121026132711/

Due to underlying problems in v3.7-rc2, several tests fail.  These
failures are unrelated to these patches.

12 years agoARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3
Paul Walmsley [Fri, 26 Oct 2012 19:21:48 +0000 (13:21 -0600)]
ARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3

Commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3 ("ARM: OMAP: Make
plat/fpga.h local to arch/arm/plat-omap") results in a new warning from
sparse:

arch/arm/mach-omap1/fpga.c:147:6: warning: symbol 'omap1510_fpga_init_irq' was not declared. Should it be static?

Fix by adding a missing include.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
12 years agoARM: OMAP1: fix build breakage introduced by commit 25c7d49ed48b4843da7dea56a81ae7f62...
Paul Walmsley [Fri, 26 Oct 2012 01:01:11 +0000 (19:01 -0600)]
ARM: OMAP1: fix build breakage introduced by commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0

Commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0 ("ARM: OMAP: Make
omap_device local to mach-omap2") broke an OMAP5912-only build here:

arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_init':
arch/arm/mach-omap1/pm_bus.c:69:2: error: implicit declaration of function
'cpu_class_is_omap1'
make[1]: *** [arch/arm/mach-omap1/pm_bus.o] Error 1

Fix by adding a missing include.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
12 years agoARM: OMAP2+: fix build breakage introduced by commit b7754452b3e27716347a528b47b0a108...
Paul Walmsley [Fri, 26 Oct 2012 19:16:30 +0000 (13:16 -0600)]
ARM: OMAP2+: fix build breakage introduced by commit b7754452b3e27716347a528b47b0a1083af32520

Commit b7754452b3e27716347a528b47b0a1083af32520 ("mtd: onenand: omap:
use pdata info instead of cpu_is") broke an OMAP3+4 build and an N800
multi-OMAP2xxx build here:

drivers/built-in.o: In function `omap2_onenand_probe':
drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram'
drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram'
drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram'
drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram'

...

drivers/built-in.o: In function `omap2_onenand_probe':
drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_read_bufferram'
drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_write_bufferram'

Fix by declaring static functions for the missing symbols, rather than
just prototypes.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Afzal Mohammed <afzal@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
12 years agoMerge branch 'omap-for-v3.8/cleanup-headers-menelaus' into omap-for-v3.8/cleanup...
Tony Lindgren [Thu, 25 Oct 2012 19:21:48 +0000 (12:21 -0700)]
Merge branch 'omap-for-v3.8/cleanup-headers-menelaus' into omap-for-v3.8/cleanup-headers

Conflicts:
arch/arm/mach-omap2/board-h4.c
arch/arm/mach-omap2/board-n8x0.c

12 years agoMerge tag 'omap-cleanup-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git...
Tony Lindgren [Thu, 25 Oct 2012 00:05:59 +0000 (17:05 -0700)]
Merge tag 'omap-cleanup-a-for-3.8' of git://git./linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-prcm

The first set of OMAP PRM/CM-related cleanup patches for 3.8.
Prepares for the future move of the PRM/CM code to drivers/.  Also
includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
series that don't need external acks.

Basic test logs for this branch on top of v3.7-rc2 are here:

http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/

But due to the number of unrelated regressions present in v3.7-rc[12],
it's not particularly usable as a testing base.  With reverts, fixes,
and workarounds applied as documented in:

http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt

the following test logs were obtained:

http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/

which indicate that the series tests cleanly.

Conflicts:
arch/arm/mach-omap2/Makefile
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
arch/arm/mach-omap2/pm24xx.c

12 years agoMerge branch 'omap-for-v3.8/cleanup-headers-usb' into omap-for-v3.8/cleanup-headers
Tony Lindgren [Wed, 24 Oct 2012 22:05:45 +0000 (15:05 -0700)]
Merge branch 'omap-for-v3.8/cleanup-headers-usb' into omap-for-v3.8/cleanup-headers

Conflicts:
arch/arm/mach-omap1/clock.c
arch/arm/mach-omap2/board-2430sdp.c
arch/arm/mach-omap2/board-4430sdp.c
arch/arm/mach-omap2/board-cm-t35.c
arch/arm/mach-omap2/board-igep0020.c
arch/arm/mach-omap2/board-ldp.c
arch/arm/mach-omap2/board-omap3beagle.c
arch/arm/mach-omap2/board-omap3logic.c
arch/arm/mach-omap2/board-omap4panda.c
arch/arm/mach-omap2/board-overo.c
arch/arm/mach-omap2/board-rm680.c
arch/arm/mach-omap2/board-rx51.c
arch/arm/mach-omap2/twl-common.c
arch/arm/mach-omap2/usb-host.c
arch/arm/mach-omap2/usb-musb.c

12 years agoARM: OMAP: move OMAP USB platform data to <linux/platform_data/omap-usb.h>
Felipe Balbi [Wed, 24 Oct 2012 21:26:19 +0000 (14:26 -0700)]
ARM: OMAP: move OMAP USB platform data to <linux/platform_data/omap-usb.h>

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>
12 years agoARM: OMAP2+: Introduce local usb.h
Tony Lindgren [Wed, 24 Oct 2012 21:26:18 +0000 (14:26 -0700)]
ARM: OMAP2+: Introduce local usb.h

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>
12 years agoARM: OMAP: Split plat/serial.h for omap1 and omap2+
Tony Lindgren [Mon, 15 Oct 2012 19:50:46 +0000 (12:50 -0700)]
ARM: OMAP: Split plat/serial.h for omap1 and omap2+

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>
12 years agoARM: OMAP: Split uncompress.h to mach-omap1 and mach-omap2
Tony Lindgren [Mon, 15 Oct 2012 19:50:38 +0000 (12:50 -0700)]
ARM: OMAP: Split uncompress.h to mach-omap1 and mach-omap2

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>
12 years agoMerge tag 'omap-for-v3.8/cleanup-headers-signed' into omap-for-v3.8/cleanup-headers...
Tony Lindgren [Wed, 24 Oct 2012 20:25:44 +0000 (13:25 -0700)]
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.

12 years agotty/serial/8250: Make omap hardware workarounds local to 8250.h
Tony Lindgren [Wed, 3 Oct 2012 22:31:58 +0000 (15:31 -0700)]
tty/serial/8250: Make omap hardware workarounds local to 8250.h

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>
12 years agoserial/8250/8250_early: Prevent rounding error in uartclk
Alexey Brodkin [Wed, 3 Oct 2012 12:27:43 +0000 (16:27 +0400)]
serial/8250/8250_early: Prevent rounding error in uartclk

Modify divisor to select the nearest baud rate divider rather than the
lowest. It minimizes baud rate errors especially on low UART clock
frequencies.

For example, if uartclk is 33000000 and baud is 115200 the ratio is
about 17.9 The current code selects 17 (5% error) but should select 18
(0.5% error).

This 5% error in baud rate leads to garbage on receiving end, while 0.5%
doesn't.

The issue showed up when using the stock 8250 driver for
Synopsys DW UART. This was on a FPGA with ~12MHz UART clock.
When we enabled early serial, we saw garbage which was narrowed down
to the rounding error.

So the bug had been latent and it only showed up with such low clock rates.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoserial: samsung: use clk_prepare_enable and clk_disable_unprepare
Thomas Abraham [Tue, 2 Oct 2012 22:40:04 +0000 (07:40 +0900)]
serial: samsung: use clk_prepare_enable and clk_disable_unprepare

Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.

Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: Report warning when low_latency flag is wrongly used
Ivo Sieben [Wed, 24 Oct 2012 12:35:42 +0000 (14:35 +0200)]
TTY: Report warning when low_latency flag is wrongly used

When a driver has the low_latency flag set and uses the schedule_flip()
function to initiate copying data to the line discipline, a workqueue is
scheduled in but never actually flushed. This is incorrect use of the
low_latency flag (driver should not support the low_latency flag, or use
the tty_flip_buffer_push() function instead). Make sure a warning is
reported to catch incorrect use of the low_latency flag.

This patch goes with: cee4ad1ed90a0959fc29f9d30a2526e5e9522cfa

Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoconsole: use might_sleep in console_lock
Daniel Vetter [Mon, 17 Sep 2012 23:03:31 +0000 (23:03 +0000)]
console: use might_sleep in console_lock

Instead of BUG_ON(in_interrupt()), since that doesn't check for all
the newfangled stuff like preempt.

Note that this is valid since the console_sem is essentially used like
a real mutex with only two twists:
- we allow trylock from hardirq context
- across suspend/resume we lock the logical console_lock, but drop the
  semaphore protecting the locking state.

Now that doesn't guarantee that no one is playing tricks in
single-thread atomic contexts at suspend/resume/boot time, but
- I couldn't find anything suspicious with some grepping,
- might_sleep shouldn't die,
- and I think the upside of catching more potential issues is worth
  the risk of getting a might_sleep backtrace that would have been
  save (and then dealing with that fallout).

Cc: Dave Airlie <airlied@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: move tty buffers to tty_port
Jiri Slaby [Thu, 18 Oct 2012 20:26:47 +0000 (22:26 +0200)]
TTY: move tty buffers to tty_port

So this is it. The big step why we did all the work over the past
kernel releases. Now everything is prepared, so nothing protects us
from doing that big step.

           |  |            \  \ nnnn/^l      |  |
           |  |             \  /     /       |  |
           |  '-,.__   =>    \/   ,-`    =>  |  '-,.__
           | O __.´´)        (  .`           | O __.´´)
            ~~~   ~~          ``              ~~~   ~~
The buffers are now in the tty_port structure and we can start
teaching the buffer helpers (insert char/string, flip etc.) to use
tty_port instead of tty_struct all around.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: add port -> tty link
Jiri Slaby [Thu, 18 Oct 2012 20:26:46 +0000 (22:26 +0200)]
TTY: add port -> tty link

For that purpose we have to temporarily introduce a second tty back
pointer into tty_port. It is because serial layer, and maybe others,
still do not use tty_port_tty_set/get. So that we cannot set the
tty_port->tty to NULL at will now.

Yes, the fix would be to convert whole serial layer and all its users
to tty_port_tty_set/get. However we are in the process of removing the
need of tty in most of the call sites, so this would lead to a
duplicated work.

Instead we have now tty_port->itty (internal tty) which will be used
only in flush_to_ldisc. For that one it is ensured that itty is valid
wherever the work is run. IOW, the work is synchronously cancelled
before we set itty to NULL and also before hangup is processed.

After we need only tty_port and not tty_struct in most code, this
shall be changed to tty_port_tty_set/get and itty removed completely.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: tty_buffer, cache pointer to tty->buf
Jiri Slaby [Thu, 18 Oct 2012 20:26:45 +0000 (22:26 +0200)]
TTY: tty_buffer, cache pointer to tty->buf

During the move of tty buffers from tty_struct to tty_port, we will
need to switch all users of buf to tty->port->buf. There are many
functions where this is accessed directly in their code many times.
Cache the tty->buf pointer in such functions now and change only
single lines in each function in the next patch.

Not that it is convenient for the next patch, but the code is now also
more readable.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: move TTY_FLUSH* flags to tty_port
Jiri Slaby [Thu, 18 Oct 2012 20:26:44 +0000 (22:26 +0200)]
TTY: move TTY_FLUSH* flags to tty_port

They are only TTY buffers specific. And the buffers will go to
tty_port in the next patches. So to remove the need to have both
tty_port and tty_struct at some places, let us move the flags to
tty_port.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: n_tty, propagate n_tty_data
Jiri Slaby [Thu, 18 Oct 2012 20:26:43 +0000 (22:26 +0200)]
TTY: n_tty, propagate n_tty_data

In some funtions we need only n_tty_data, so pass it down directly in
case tty is not needed there.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: move ldisc data from tty_struct: locks
Jiri Slaby [Thu, 18 Oct 2012 20:26:42 +0000 (22:26 +0200)]
TTY: move ldisc data from tty_struct: locks

atomic_write_lock is not n_tty specific, so move it up in the
tty_struct.

And since these are the last ones to move, remove also the comment
saying there are some ldisc' members. There are none now.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: move ldisc data from tty_struct: read_* and echo_* and canon_* stuff
Jiri Slaby [Thu, 18 Oct 2012 20:26:41 +0000 (22:26 +0200)]
TTY: move ldisc data from tty_struct: read_* and echo_* and canon_* stuff

All the ring-buffers...

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: move ldisc data from tty_struct: bitmaps
Jiri Slaby [Thu, 18 Oct 2012 20:26:40 +0000 (22:26 +0200)]
TTY: move ldisc data from tty_struct: bitmaps

Here we move bitmaps and use DECLARE_BITMAP to declare them in the new
structure. And instead of memset, we use bitmap_zero as it is more
appropriate.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: move ldisc data from tty_struct: simple members
Jiri Slaby [Thu, 18 Oct 2012 20:26:39 +0000 (22:26 +0200)]
TTY: move ldisc data from tty_struct: simple members

Here we start moving all the n_tty related bits from tty_struct to
the newly defined n_tty_data struct in n_tty proper.

In this patch primitive members and bits are moved. The rest will be
done per-partes in the next patches.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: n_tty, add ldisc data to n_tty
Jiri Slaby [Thu, 18 Oct 2012 20:26:38 +0000 (22:26 +0200)]
TTY: n_tty, add ldisc data to n_tty

All n_tty related members from tty_struct will be moved here.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: audit, stop accessing tty->icount
Jiri Slaby [Thu, 18 Oct 2012 20:26:37 +0000 (22:26 +0200)]
TTY: audit, stop accessing tty->icount

This is a private member of n_tty. Stop accessing it. Instead, take is
as an argument.

This is needed to allow clean switch of the private members to a
separate private structure of n_tty.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: n_tty, remove bogus checks
Jiri Slaby [Thu, 18 Oct 2012 20:26:36 +0000 (22:26 +0200)]
TTY: n_tty, remove bogus checks

* BUG_ON(!tty) in n_tty_set_termios -- it cannot be called with tty ==
  NULL. It is called from two call sites. First, from n_tty_open where
  we have a valid tty. Second, as ld->ops->set_termios from
  tty_set_termios. But there we have a valid tty too.
* if (!tty) in n_tty_open -- why would the TTY layer call ldisc's
  open with an invalid TTY? No it indeed does not. All call sites have
  a tty and dereference that.
* BUG_ON(!tty->read_buf) in n_tty_read -- this used to be a valid
  check. The ldisc handling was broken some time ago when I added the
  check to ensure everything is OK. It still can catch the case, but
  no later than we move the buffer to ldisc data. Then there will be
  no read_buf in tty_struct, i.e. nothing to check for.
* if (!tty->read_buf) in n_tty_receive_buf -- this should never
  happen. All callers of ldisc->ops->receive_ops should hold a
  reference to an ldisc and close (which frees read_buf) cannot be
  called until the reference is dropped.
* if (WARN_ON(!tty->read_buf)) in n_tty_read -- the same as in the
  previous case.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: n_tty, simplify read_buf+echo_buf allocation
Jiri Slaby [Thu, 18 Oct 2012 20:26:35 +0000 (22:26 +0200)]
TTY: n_tty, simplify read_buf+echo_buf allocation

ldisc->open and close are called only once and cannot cross. So the
tests in open and close are superfluous. Remove them. (But leave sets
to NULL to ensure there is not a bug somewhere.)

And when the tests are gone, handle properly failures in open. We
leaked read_buf if allocation of echo_buf failed before. Now this is
not the case anymore.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: hci_ldisc, remove invalid check in open
Jiri Slaby [Thu, 18 Oct 2012 20:26:34 +0000 (22:26 +0200)]
TTY: hci_ldisc, remove invalid check in open

hci_ldisc's open checks if tty_struct->disc_data is set. And if so it
returns with an error. But nothing ensures disc_data to be NULL. And
since ld->ops->open shall be called only once, we do not need the
check at all. So remove it.

Note that this is not an issue now, but n_tty will start using the
disc_data pointer and this invalid 'if' would trigger then rendering
TTYs over BT unusable.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: ldisc, wait for idle ldisc in release
Jiri Slaby [Thu, 18 Oct 2012 20:26:33 +0000 (22:26 +0200)]
TTY: ldisc, wait for idle ldisc in release

We reintroduced tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore
tty_ldisc_wait_idle) and used in set_ldisc. Then we added it also to
the hangup path in 92f6fa09bd453 (TTY: ldisc, do not close until there
are readers). And we noted that there is one more path:
~   Before 65b770468e98 tty_ldisc_wait_idle was called also from
~   tty_ldisc_release. It is called from tty_release, so I don't think
~   we need to restore that one.

Well, I was wrong. There might still be holders of an ldisc
reference. Not from userspace, but drivers. If they take a reference
and a user closes the device immediately after that, we have a
problem. ldisc is halted and closed by TTY, but the driver still may
call some ldisc's operation and cause a crash.

So restore the tty_ldisc_wait_idle call also to the third location
where it was before 65b770468e98 (tty-ldisc: turn ldisc user count
into a proper refcount). Now we should be safe with respect to the
ldisc reference counting as all* tty_ldisc_close paths are safely
called with reference count of one.

* Not the one in tty_ldisc_setup's fail path. But that is called
  before the first open finishes. So userspace does not see it yet.
  Even thought the driver is given the TTY already via ->install, it
  should not take a reference to the ldisc yet. If some driver is to
  do this, we should put one tty_ldisc_wait_idle also in the setup.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: vt, fix paste_selection ldisc handling
Jiri Slaby [Thu, 18 Oct 2012 20:26:32 +0000 (22:26 +0200)]
TTY: vt, fix paste_selection ldisc handling

There used to be a single tty_ldisc_ref_wait. But then, when a
big-tty-mutex (BTM) was introduced, it has to be tty_ldisc_ref +
tty_unlock + tty_ldisc_ref_wait + tty_lock. Later, BTM was removed
from that path and tty_ldisc_ref + tty_ldisc_ref_wait remained there.
But it makes no sense now. So leave there only tty_ldisc_ref_wait.

And when we have a reference to an ldisc, actually use it in the loop.
Otherwise it may be racy.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: move devpts kill to pty
Jiri Slaby [Thu, 18 Oct 2012 20:26:31 +0000 (22:26 +0200)]
TTY: move devpts kill to pty

Now that we have control over tty->driver_data in pty, we can just
kill the /dev/pts/ in pty code too. Namely, in ->shutdown hook of
tty. For pty, this is called only once, for whichever end is closed
last. But we don't care, both driver_data are the inode as it used to
be till now.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: devpts, document devpts inode operations
Jiri Slaby [Thu, 18 Oct 2012 20:26:30 +0000 (22:26 +0200)]
TTY: devpts, document devpts inode operations

Add kernel-doc texts for some devpts functions, i.e. document them.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: devpts, do not set driver_data
Jiri Slaby [Thu, 18 Oct 2012 20:26:29 +0000 (22:26 +0200)]
TTY: devpts, do not set driver_data

The goal is to stop setting and using tty->driver_data in devpts code.
It should be used solely by the driver's code, pty in this case.

Now driver_data are managed only in the pty driver. devpts_pty_new is
switched to accept what we used to dig out of tty_struct, i.e. device
node number and index.

This also removes a note about driver_data being set outside of the
driver.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: devpts, return created inode from devpts_pty_new
Jiri Slaby [Thu, 18 Oct 2012 20:26:28 +0000 (22:26 +0200)]
TTY: devpts, return created inode from devpts_pty_new

The goal is to stop setting and using tty->driver_data in devpts code.
It should be used solely by the driver's code, pty in this case.

For the cleanup of layering, we will need the inode created in
devpts_pty_new to be stored into slave's driver_data. So we convert
devpts_pty_new to return the inode or an ERR_PTR-encoded error in case
of failure.

The move of 'inode = new_inode(sb);' from declarators to the code is
only cosmetical, but it makes the code easier to read.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoTTY: devpts, don't care about TTY in devpts_get_tty
Jiri Slaby [Thu, 18 Oct 2012 20:26:27 +0000 (22:26 +0200)]
TTY: devpts, don't care about TTY in devpts_get_tty

The goal is to stop setting and using tty->driver_data in devpts code.
It should be used solely by the driver's code, pty in this case.

First, here we remove TTY from devpts_get_tty and rename it to
devpts_get_priv. Note we do not remove type safety, we just shift the
[implicit] (void *) cast one layer up.

index was unused in devpts_get_tty, so remove that from the prototype
too.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agotty: prevent unnecessary work queue lock checking on flip buffer copy
Ivo Sieben [Thu, 27 Sep 2012 12:02:05 +0000 (14:02 +0200)]
tty: prevent unnecessary work queue lock checking on flip buffer copy

When low_latency flag is set the TTY receive flip buffer is copied to the
line discipline directly instead of using a work queue in the background.
Therefor only in case a workqueue is actually used for copying data to the
line discipline we'll have to flush the workqueue.

This prevents unnecessary spin lock/unlock on the workqueue spin lock that
can cause additional scheduling overhead on a PREEMPT_RT system. On a 200
MHz AT91SAM9261 processor setup this fixes about 100us of scheduling
overhead on the TTY read call.

Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoconsole: implement lockdep support for console_lock
Daniel Vetter [Sat, 22 Sep 2012 17:52:11 +0000 (19:52 +0200)]
console: implement lockdep support for console_lock

Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:

https://lkml.org/lkml/2012/8/21/36

Unfortunately the console_lock isn't a plain mutex and hence has no
lockdep support. Which resulted in a few days wasted of tracking down
this bug (complicated by the fact that printk doesn't show anything
when the console is locked) instead of noticing the bug much earlier
with the lockdep splat.

Hence I've figured I need to fix that for the next deadlock involving
console_lock - and with kms/drm growing ever more complex locking
that'll eventually happen.

Now the console_lock has rather funky semantics, so after a quick irc
discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
the original idead of switching to a real mutex (since it won't work)
and instead opted to annotate the console_lock with lockdep
information manually.

There are a few special cases:
- The console_lock state is protected by the console_sem, and usually
  grabbed/dropped at _lock/_unlock time. But the suspend/resume code
  drops the semaphore without dropping the console_lock (see
  suspend_console/resume_console). But since the same thread that did
  the suspend will do the resume, we don't need to fix up anything.

- In the printk code there's a special trylock, only used to kick off
  the logbuffer printk'ing in console_unlock. But all that happens
  while lockdep is disable (since printk does a few other evil
  tricks). So no issue there, either.

- The console_lock can also be acquired form irq context (but only
  with a trylock). lockdep already handles that.

This all leaves us with annotating the normal console_lock, _unlock
and _trylock functions.

And yes, it works - simply unloading a drm kms driver resulted in
lockdep complaining about the deadlock in fbcon_deinit:

======================================================
[ INFO: possible circular locking dependency detected ]
3.6.0-rc2+ #552 Not tainted
-------------------------------------------------------
kms-reload/3577 is trying to acquire lock:
 ((&info->queue)){+.+...}, at: [<ffffffff81058c70>] wait_on_work+0x0/0xa7

but task is already holding lock:
 (console_lock){+.+.+.}, at: [<ffffffff81264686>] bind_con_driver+0x38/0x263

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (console_lock){+.+.+.}:
       [<ffffffff81087440>] lock_acquire+0x95/0x105
       [<ffffffff81040190>] console_lock+0x59/0x5b
       [<ffffffff81209cb6>] fb_flashcursor+0x2e/0x12c
       [<ffffffff81057c3e>] process_one_work+0x1d9/0x3b4
       [<ffffffff810584a2>] worker_thread+0x1a7/0x24b
       [<ffffffff8105ca29>] kthread+0x7f/0x87
       [<ffffffff813b1204>] kernel_thread_helper+0x4/0x10

-> #0 ((&info->queue)){+.+...}:
       [<ffffffff81086cb3>] __lock_acquire+0x999/0xcf6
       [<ffffffff81087440>] lock_acquire+0x95/0x105
       [<ffffffff81058cab>] wait_on_work+0x3b/0xa7
       [<ffffffff81058dd6>] __cancel_work_timer+0xbf/0x102
       [<ffffffff81058e33>] cancel_work_sync+0xb/0xd
       [<ffffffff8120a3b3>] fbcon_deinit+0x11c/0x1dc
       [<ffffffff81264793>] bind_con_driver+0x145/0x263
       [<ffffffff81264a45>] unbind_con_driver+0x14f/0x195
       [<ffffffff8126540c>] store_bind+0x1ad/0x1c1
       [<ffffffff8127cbb7>] dev_attr_store+0x13/0x1f
       [<ffffffff8116d884>] sysfs_write_file+0xe9/0x121
       [<ffffffff811145b2>] vfs_write+0x9b/0xfd
       [<ffffffff811147b7>] sys_write+0x3e/0x6b
       [<ffffffff813b0039>] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(console_lock);
                               lock((&info->queue));
                               lock(console_lock);
  lock((&info->queue));

 *** DEADLOCK ***

v2: Mark the lockdep_map static, noticed by Jani Nikula.

Cc: Dave Airlie <airlied@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
12 years agoARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver
Paul Walmsley [Sun, 21 Oct 2012 07:01:13 +0000 (01:01 -0600)]
ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver

The OMAP watchdog timer driver needs to determine what caused the SoC
to reset for its GETBOOTSTATUS ioctl.  So, define a set of standard
reset sources across OMAP SoCs.  For OMAP2xxx, 3xxx, and 4xxx SoCs,
define mappings from the SoC-specific reset source register bits to
the standardized reset source IDs.  Create SoC-specific PRM functions
that read the appropriate per-SoC register and use the mapping to
return the standardized reset bits.  Register the SoC-specific PRM
functions with the common PRM code via prm_register().  Create a
function in the common PRM code, prm_read_reset_sources(), that
calls the SoC-specific function, registered during boot.

This patch does not yet handle some SoCs, such as AM33xx.  Those SoCs
were not handled by the code this will replace.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
12 years agoARM: OMAP1: create read_reset_sources() function (for initial use by watchdog)
Paul Walmsley [Sun, 21 Oct 2012 07:01:12 +0000 (01:01 -0600)]
ARM: OMAP1: create read_reset_sources() function (for initial use by watchdog)

On OMAP1, the existing OMAP watchdog driver reads a register directly
from a non-watchdog IP block.  It also does not convert the register's
contents into the standard WDIOF_* bits expected from the
GETBOOTSTATUS ioctl().

To move towards fixing these problems, create an function in
arch/arm/mach-omap1 to return the reset source data.  A subsequent
patch will provide this function to the watchdog driver via
platform_data.

In the long term, the best approach would be to move this function
to a new OMAP1 driver that handles access to the OMAP1 Clock
Generation and Reset Management IP block.  Then no platform_data would
be needed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
12 years agoARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers
Paul Walmsley [Sun, 21 Oct 2012 07:01:12 +0000 (01:01 -0600)]
ARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers

There are several CM operations which behave similarly across OMAP2+
SoCs, but which have slight differences in their underlying
implementations.

This patch creates the support code for this function pointer
registration process.  No function pointers are included yet, but a
subsequent patch will create these for the module IDLEST registers.

This patch allows other code to use CM-provided data and operations
without needing to know which SoC is currently in use.  A further
description of the concept is provided in the patch entitled
"ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers".

Signed-off-by: Paul Walmsley <paul@pwsan.com>
12 years agoARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers
Paul Walmsley [Sun, 21 Oct 2012 07:01:11 +0000 (01:01 -0600)]
ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers

There are several PRM operations which behave similarly across OMAP2+
SoCs, but which have slight differences in their underlying
implementations.  For example, to fetch the SoC's last reset sources,
different registers are read across OMAP2xxx, 3xxx, and 44xx, and
different bits are used on each SoC.  But the information returned is
so similar that a single, common interface for drivers is useful.

This patch creates the support code for this function pointer
registration process.  No function pointers are included yet, but a
subsequent patch will create one for the reset source API.

To illustrate the end goal with the above reset source example, each
per-SoC driver will use its own low-level implementation function --
e.g., prm2xxx.c would contain omap2xxx_prm_read_reset_sources().  This
function would read the appropriate register and remap the register
bits to a standard set of reset source bits.  When the prm2xxx.c
driver is loaded, it would register this function with the common PRM
driver, prm.c.  prm.c would then export a common function,
omap_prm_read_reset_sources().  Calling it would call through to the
function pointer for the currently-registered SoC PRM driver.  This
will allow other drivers to use PRM-provided data and operations
without needing to know which SoC is currently in use.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
12 years agoARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain functions into PRM/CM
Paul Walmsley [Sun, 21 Oct 2012 07:01:11 +0000 (01:01 -0600)]
ARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain functions into PRM/CM

Move the low-level SoC-specific clockdomain control functions into
cm*.c and prm*.c.  For example, OMAP2xxx low-level clockdomain
functions go into cm2xxx.c.  Then remove the unnecessary
clockdomain*xxx*.c files.

The objective is to centralize low-level CM and PRM register accesses
into the cm*.[ch] and prm*.[ch] files, and then to export an OMAP
SoC-independent API to higher-level OMAP power management code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
12 years agoARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files
Paul Walmsley [Sun, 21 Oct 2012 07:01:11 +0000 (01:01 -0600)]
ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files

Move OMAP3xxx-specific CM functions & macros into cm3xxx.[ch] and
OMAP2xxx-specific macros into cm2xxx.[ch].  Move basic CM register
access functions into static inline functions in cm2xxx_3xxx.h,
leaving only OMAP2/3 hardreset functions in cm2xxx_3xxx.c.

As part of this, split the CM and hwmod code that waits for devices to
become ready into SoC-specific functions.

This is in preparation for the upcoming move of this code to drivers/.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
12 years agoARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions into PRM
Paul Walmsley [Sun, 21 Oct 2012 07:01:10 +0000 (01:01 -0600)]
ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions into PRM

Move the low-level SoC-specific powerdomain control functions into
prm*.c.  For example, OMAP2xxx low-level powerdomain functions go into
prm2xxx.c.  Then remove the unnecessary powerdomain*xxx*.c files.

The objective is to centralize low-level PRM register accesses into
the prm*.[ch] files, and then to export an OMAP SoC-independent API to
higher-level OMAP power management code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
12 years agoARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files
Paul Walmsley [Sun, 21 Oct 2012 07:01:10 +0000 (01:01 -0600)]
ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files

Move OMAP3xxx-specific PRM functions & macros into prm3xxx.[ch] and
OMAP2xxx-specific macros into prm2xxx.h.  (prm2xxx.c will be created
by a subsequent patch when it's needed.)  Move basic PRM register
access functions into static inline functions in prm2xxx_3xxx.h, leaving
only OMAP2/3 hardreset functions in prm2xxx_3xxx.c.

Also clarify the initcall function naming to reinforce that this code
is specifically for the PRM IP block.

This is in preparation for the upcoming powerdomain series and the
upcoming move of this code to drivers/.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
12 years agoARM: OMAP2+: PRM: remove PRM weak functions
Paul Walmsley [Sun, 21 Oct 2012 07:01:09 +0000 (01:01 -0600)]
ARM: OMAP2+: PRM: remove PRM weak functions

Remove the now-unused PRM weak functions from prm_common.c.  These
were formerly used to ensure that some OMAP2/3 PRM code would build on
OMAP4, but none of those functions ever would have worked on OMAP4 due
to an incompatible PRM register layout.  Now all that has been cleaned
up and these can be removed.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
12 years agoLinux 3.7-rc2
Linus Torvalds [Sat, 20 Oct 2012 19:11:32 +0000 (12:11 -0700)]
Linux 3.7-rc2

12 years agoMerge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas...
Linus Torvalds [Sat, 20 Oct 2012 16:48:10 +0000 (09:48 -0700)]
Merge tag 'arm64-fixes' of git://git./linux/kernel/git/cmarinas/linux-aarch64

Pull arm64 fixes from Catalin Marinas:
 "Main changes:
   - AArch64 Linux compilation fixes following 3.7-rc1 changes
     (MODULES_USE_ELF_RELA, update_vsyscall() prototype)
   - Unnecessary register setting in start_thread() (thanks to Al Viro)
   - ptrace fixes"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
  arm64: fix alignment padding in assembly code
  arm64: ptrace: use HW_BREAKPOINT_EMPTY type for disabled breakpoints
  arm64: ptrace: make structure padding explicit for debug registers
  arm64: No need to set the x0-x2 registers in start_thread()
  arm64: Ignore memory blocks below PHYS_OFFSET
  arm64: Fix the update_vsyscall() prototype
  arm64: Select MODULES_USE_ELF_RELA
  arm64: Remove duplicate inclusion of mmu_context.h in smp.c

12 years agoarm64: fix alignment padding in assembly code
Marc Zyngier [Fri, 19 Oct 2012 16:33:27 +0000 (17:33 +0100)]
arm64: fix alignment padding in assembly code

An interesting effect of using the generic version of linkage.h
is that the padding is defined in terms of x86 NOPs, which can have
even more interesting effects when the assembly code looks like this:

ENTRY(func1)
mov x0, xzr
ENDPROC(func1)
// fall through
ENTRY(func2)
mov x0, #1
ret
ENDPROC(func2)

Admittedly, the code is not very nice. But having code from another
architecture doesn't look completely sane either.

The fix is to add arm64's version of linkage.h, which causes the insertion
of proper AArch64 NOPs.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
12 years agouse clamp_t in UNAME26 fix
Kees Cook [Sat, 20 Oct 2012 01:45:53 +0000 (18:45 -0700)]
use clamp_t in UNAME26 fix

The min/max call needed to have explicit types on some architectures
(e.g. mn10300). Use clamp_t instead to avoid the warning:

  kernel/sys.c: In function 'override_release':
  kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
12 years agoMerge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sat, 20 Oct 2012 01:39:36 +0000 (18:39 -0700)]
Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull perf fixes from Ingo Molnar:
 "Assorted small fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf python: Properly link with libtraceevent
  perf hists browser: Add back callchain folding symbol
  perf tools: Fix build on sparc.
  perf python: Link with libtraceevent
  perf python: Initialize 'page_size' variable
  tools lib traceevent: Fix missed freeing of subargs in free_arg() in filter
  lib tools traceevent: Add back pevent assignment in __pevent_parse_format()
  perf hists browser: Fix off-by-two bug on the first column
  perf tools: Remove warnings on JIT samples for srcline sort key
  perf tools: Fix segfault when using srcline sort key
  perf: Require exclude_guest to use PEBS - kernel side enforcement
  perf tool: Precise mode requires exclude_guest

12 years agoperf python: Properly link with libtraceevent
Arnaldo Carvalho de Melo [Thu, 18 Oct 2012 14:38:35 +0000 (11:38 -0300)]
perf python: Properly link with libtraceevent

Namhyung Kim reported that the build fails with:

  GEN python/perf.so
  gcc: error: python_ext_build/tmp//../../libtraceevent.a: No such file or directory
  error: command 'gcc' failed with exit status 1
  cp: cannot stat `python_ext_build/lib/perf.so': No such file or directory
  make: *** [python/perf.so] Error 1

We need to propagate the TE_PATH variable to the setup.py file.

Reported-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: http://lkml.kernel.org/n/tip-8umiPbm4sxpknKivbjgykhut@git.kernel.org
[ Fixed superfluous variable build error. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
12 years agoMerge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git...
Ingo Molnar [Sat, 20 Oct 2012 00:32:56 +0000 (02:32 +0200)]
Merge tag 'perf-urgent-for-mingo' of git://git./linux/kernel/git/acme/linux into perf/urgent

Pull perf/urgent fixes from Arnaldo Carvalho de Melo:

* The python binding needs to link with libtraceevent and to initialize
  the 'page_size' variable so that mmaping works again.

* The callchain folding character that appears on the TUI just before
  the overhead had disappeared due to recent changes, add it back.

* Intel PEBS in VT-x context uses the DS address as a guest linear address,
  even though its programmed by the host as a host linear address. This either
  results in guest memory corruption and or the hardware faulting and 'crashing'
  the virtual machine.  Therefore we have to disable PEBS on VT-x enter and
  re-enable on VT-x exit, enforcing a strict exclude_guest.

  Kernel side enforcement fix by Peter Zijlstra, tooling side fix by David Ahern.

* Fix build on sparc due to UAPI, fix from David Miller.

* Fixes for the srclike sort key for unresolved symbols and when processing
  samples in JITted code, where we don't have an ELF file, just an special
  symbol table, fixes from Namhyung Kim.

* Fix some leaks in libtraceevent, from Steven Rostedt.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
12 years agoMerge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm...
Linus Torvalds [Sat, 20 Oct 2012 00:32:37 +0000 (17:32 -0700)]
Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM soc fixes from Olof Johansson:
 "A set of fixes and some minor cleanups for -rc2:

   - A series from Arnd that fixes warnings in drivers and other code
     included by ARM defconfigs.  Most have been acked by corresponding
     maintainers (and seem quite hard to argue not picking up anyway in
     the few exception cases).
   - A few misc patches from the list for integrator/vt8500/i.MX
   - A batch of fixes to OMAP platforms, fixing:
     - boot problems on beaglebone,
     - regression fixes for local timers
     - clockdomain locking fixes
     - a few boot/sparse warnings
   - For Tegra:
     - Clock rate calculation overflow fix
     - Revert a change that removed timer clocks and a fix for symbol
       name clashes
   - For Renesas:
     - IO accessor / annotation cleanups to remove warnings
   - For Kirkwood/Dove/mvebu:
     - Fixes for device trees for Dove (some minor cleanups, some fixes)
     - Fixes for the mvebu gpio driver
     - Fix build problem for Feroceon due to missing ifdefs
     - Fix lsxl DTS files"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
  ARM: kirkwood: fix buttons on lsxl boards
  ARM: kirkwood: fix LEDs names for lsxl boards
  ARM: Kirkwood: fix disabling CACHE_FEROCEON_L2
  gpio: mvebu: Add missing breaks in mvebu_gpio_irq_set_type
  ARM: dove: Add crypto engine to DT
  ARM: dove: Remove watchdog from DT
  ARM: dove: Restructure SoC device tree descriptor
  ARM: dove: Fix clock names of sata and gbe
  ARM: dove: Fix tauros2 device tree init
  ARM: dove: Add pcie clock support
  ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory
  ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
  ARM: s3c: mark s3c2440_clk_add as __init_refok
  spi/s3c64xx: use correct dma_transfer_direction type
  ARM: OMAP4: devices: fixup OMAP4 DMIC platform device error message
  ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck
  ARM: OMAP: resolve sparse warning concerning debug_card_init()
  ARM: OMAP4: Fix twd_local_timer_register regression
  ARM: tegra: add tegra_timer clock
  ARM: tegra: rename tegra system timer
  ...

12 years agoMODSIGN: Move the magic string to the end of a module and eliminate the search
David Howells [Sat, 20 Oct 2012 00:19:29 +0000 (01:19 +0100)]
MODSIGN: Move the magic string to the end of a module and eliminate the search

Emit the magic string that indicates a module has a signature after the
signature data instead of before it.  This allows module_sig_check() to
be made simpler and faster by the elimination of the search for the
magic string.  Instead we just need to do a single memcmp().

This works because at the end of the signature data there is the
fixed-length signature information block.  This block then falls
immediately prior to the magic number.

From the contents of the information block, it is trivial to calculate
the size of the signature data and thus the size of the actual module
data.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>