Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      由 Tejun Heo 提交于 
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  3. 13 3月, 2010 1 次提交
  5. 12 3月, 2010 10 次提交
  7. 10 3月, 2010 1 次提交
  9. 27 2月, 2010 1 次提交
  11. 26 2月, 2010 3 次提交
  13. 25 2月, 2010 23 次提交
    • S
      OMAP4: clock: Remove clock hacks from timer-gp.c · ad001f14
      由 Santosh Shilimkar 提交于 
      Now the omap4 clock framework is in mainline and clk_get_rate()
is functional. Hence reomve the hardcoded clock hacks.

This patch also fixes
Division by zero in kernel.
Backtrace:
[<c0025fb8>] (dump_backtrace+0x0/0x110) from [<c017febc>] (dump_stack+0x18/0x1c)
 r7:60000093 r6:c0641050 r5:c0223e78 r4:c02126b4
[<c017fea4>] (dump_stack+0x0/0x1c) from [<c00260fc>] (__div0+0x18/0x20)
[<c00260e4>] (__div0+0x0/0x20) from [<c01431fc>] (Ldiv0+0x8/0x10)
[<c00318d4>] (omap_dm_timer_stop+0x0/0xb0) from [<c002c148>] (omap2_gp_timer_set_mode+0x1c/0x68)
 r5:c0223e78 r4:00000000
[<c002c12c>] (omap2_gp_timer_set_mode+0x0/0x68) from [<c0063270>] (clockevents_set_mode+0x30/0x64)
 r5:c020cae0 r4:00000000
[<c0063240>] (clockevents_set_mode+0x0/0x64) from [<c00632fc>] (clockevents_exchange_device+0x30/0x9c)
 r5:c020cae0 r4:c02146e0
[<c00632cc>] (clockevents_exchange_device+0x0/0x9c) from [<c00636e0>] (tick_notify+0x17c/0x404)
 r7:00000000 r6:c0641050 r5:00000000 r4:c020cae0
[<c0063564>] (tick_notify+0x0/0x404) from [<c005d5fc>] (notifier_call_chain+0x34/0x78)
[<c005d5c8>] (notifier_call_chain+0x0/0x78) from [<c005d684>] (__raw_notifier_call_chain+0x1c/0x24)
[<c005d668>] (__raw_notifier_call_chain+0x0/0x24) from [<c005d6ac>] (raw_notifier_call_chain+0x20/0x28)
[<c005d68c>] (raw_notifier_call_chain+0x0/0x28) from [<c0062e78>] (clockevents_do_notify+0x1c/0x24)
[<c0062e5c>] (clockevents_do_notify+0x0/0x24) from [<c0062f18>] (clockevents_register_device+0x98/0xd0)
[<c0062e80>] (clockevents_register_device+0x0/0xd0) from [<c001a194>] (percpu_timer_setup+0x80/0x9c)
 r7:00000000 r6:00000002 r5:00000002 r4:00000003
[<c001a114>] (percpu_timer_setup+0x0/0x9c) from [<c000e9f0>] (smp_prepare_cpus+0xb0/0xe8)
[<c000e940>] (smp_prepare_cpus+0x0/0xe8) from [<c00084e8>] (kernel_init+0x5c/0x1fc)
 r7:00000000 r6:00000000 r5:00000000 r4:c001b8a4
[<c000848c>] (kernel_init+0x0/0x1fc) from [<c0046c50>] (do_exit+0x0/0x604)
 r7:00000000 r6:00000000 r5:00000000 r4:00000000
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      ad001f14
    • S
      OMAP4: clock: Add dummy clock nodes for interface clocks · 7c43d547
      由 Santosh Shilimkar 提交于 
      On OMAP4 platform the iclk control is completly under hardware control
and no software control is available.

This difference w.r.t previous OMAP's needs all the common driver
accross OMAP's , cpu_is_xxxx() checks. To avoid poulluting the
drivers dummy clock nodes are created (The autogeneration
script has been updated accordingly).
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: made OMAP1 dummy_ck common and edited patch to reuse that]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7c43d547
    • R
      OMAP4: clock: Rename leaf clock nodes to end with a _ick or _fck · 54776050
      由 Rajendra Nayak 提交于 
      All leaf clock nodes are renamed for OMAP4 to have a clk name which
end with a _ick or a _fck. This is done so that the naming convention
is same as that followed on older OMAPs.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      54776050
    • P
      OMAP2+ clock: revise omap2_clk_{disable,enable}() · 30962d9d
      由 Paul Walmsley 提交于 
      Simplify the code in the omap2_clk_disable() and omap2_clk_enable()
functions, reducing levels of indentation.  This makes the code easier
to read.  Add some additional debugging pr_debug()s here also to help
others understand what is going on.

Revise the omap2_clk_disable() logic so that it now attempts to
disable the clock's clockdomain before recursing up the clock tree.
Simultaneously, ensure that omap2_clk_enable() is called on parent
clocks first, before enabling the clockdomain.  This ensures that a
parent clock's clockdomain is enabled before the child clock's
clockdomain.  These sequences should be the inverse of each other.

Revise the omap2_clk_enable() logic so that it now cleans up after
itself upon encountering an error.  Previously, an error enabling a
parent clock could have resulted in inconsistent usecounts on the
enclosing clockdomain.

Remove the trivial _omap2_clk_disable() and _omap2_clk_enable() static
functions, and replace it with the clkops calls that they were
executing.

For all this to work, the clockdomain omap2_clkdm_clk_enable() and
omap2_clkdm_clk_disable() code must not return an error on clockdomains
without CLKSTCTRL registers; so modify those functions to simply return 0
in that case.

While here, add some basic kerneldoc documentation on both functions,
and get rid of some old non-CodingStyle-compliant comments that have
existed since the dawn of time (at least, the OMAP clock framework's
time).
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      30962d9d
    • P
      OMAP2/3 clock: combine OMAP2 & 3 boot-time MPU rate change code · 4d30e82c
      由 Paul Walmsley 提交于 
      The OMAP2 and OMAP3 boot-time MPU rate change code is almost
identical.  Merge them into mach-omap2/clock.c, and add kerneldoc
documentation.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d30e82c
    • P
      OMAP clockdomain: if no autodeps exist, don't try to add or remove them · ad956160
      由 Paul Walmsley 提交于 
      _clkdm_add_autodeps() and _clkdm_del_autodeps() will attempt to dereference
a NULL pointer if no autodeps were supplied to clkdm_init().

Based on a patch from Roel Kluin <roel.kluin@gmail.com> - thanks Roel.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Roel Kluin <roel.kluin@gmail.com>
      ad956160
    • P
      OMAP hwmod: add hwmod class support · 43b40992
      由 Paul Walmsley 提交于 
      Add support for categorizing and iterating over hardware IP blocks by
the "class" of the IP block.  The class is the type of the IP block:
e.g., "timer", "timer1ms", etc.  Move the OCP_SYSCONFIG/SYSSTATUS data
from the struct omap_hwmod into the struct omap_hwmod_class, since
it's expected to stay consistent for each class.  While here, fix some
comments.

The hwmod_class structures in this patch were designed and proposed by
Benoît Cousson <b-cousson@ti.com> and were refined in a discussion
between Thara Gopinath <thara@ti.com>, Kevin Hilman
<khilman@deeprootsystems.com>, and myself.

This patch uses WARN() lines that are longer than 80 characters, as
Kevin noted a broader lkml consensus to increase greppability by
keeping the messages all on one line.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
Cc: Thara Gopinath <thara@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
      43b40992
    • P
      OMAP hwmod: convert header files with static allocations into C files · 7359154e
      由 Paul Walmsley 提交于 
      Code should be able to #include any header file without the fear that
the header file will go allocating memory.  This is a coding style
issue, similar to commit 82e9bd58.
Move the existing hwmod data from .h files to .c files.

While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since
most of these structures should be reusable across all OMAP3 chips.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
      7359154e
    • P
      OMAP hwmod: convert hwmod to use hardware clock names rather than clkdev dev+con · 50ebdac2
      由 Paul Walmsley 提交于 
      The OMAP hwmod core code is intended to use SoC IP block description
structures that are autogenerated from TI's OMAP hardware database.
Currently the hwmod code uses clkdev device + connection addressing to
identify clocks.  This causes problems in the hwmod autogeneration
process, since the TI hardware database doesn't use platform_device or
clkdev addressing; it uses a single clock signal name string, which
tends to bear some resemblance to what is used in the OMAP TRMs.  This
patch converts the hwmod code and existing data to use omap_clk_get_by_name(),
introduced in the previous patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
      50ebdac2
    • V
      OMAP3: clock: add capability to change rate of dpll4_m5_ck_3630 · e8d37377
      由 Vimarsh Zutshi 提交于 
      Add necessary clk_sel definitions to clock framework to allow changing
dpll4_m5_ck_3630 rate. This is used by the ISP driver.
Signed-off-by: NVimarsh Zutshi <vimarsh.zutshi@nokia.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e8d37377
    • P
      OMAP4 clock: drop the ALWAYS_ENABLED clock flag · 53c92d8f
      由 Paul Walmsley 提交于 
      Get rid of the ALWAYS_ENABLED clock flag - it doesn't actually do anything.
(The OMAP4 clock autogeneration scripts have been updated accordingly.)
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      53c92d8f
    • P
      OMAP clock: drop RATE_FIXED clock flag · 51c19541
      由 Paul Walmsley 提交于 
      The RATE_FIXED clock flag is pointless.  In the OMAP1 clock code, it
simply causes the omap1_clk_round_rate() function to return the
current rate of the clock.  omap1_clk_round_rate(), however, should
never be called for a fixed-rate clock, since none of these clocks
have a .round_rate function pointer set in their struct clk records.
Similarly, in the OMAP2+ clock code, the RATE_FIXED flag just causes
the clock code to emit a warning if the OMAP clock maintainer was
foolish enough to add a .round_rate function pointer to a fixed-rate
clock.  "Doctor, it hurts when I pretend that a fixed-rate clock is
rate-changeable."  "Then don't pretend that a fixed-rate clock is
rate-changeable."  It has no functional value.  This patch drops the
RATE_FIXED clock flag, removing it from all clocks that are so marked.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      51c19541
    • P
      OMAP2 clock: drop DELAYED_APP clock flag · 8c34974a
      由 Paul Walmsley 提交于 
      All of the clocks that are marked with DELAYED_APP are changed as part
of the virt_prcm_set OPP virtual clock.  On 24xx, these clocks all
need to be changed as part of a group to keep the clock tree
functional - hence the need for the VALID_CONFIG bit, which is not
present on later OMAPs.  These clocks should not be rate-changed
independently.  So prevent these clocks from being changed
independently by dropping their .round_rate and .set_rate function
pointers.  It then turns out that the DELAYED_APP clock flag is no
longer useful, so drop it and the associated code and renumber the
clock flags.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      8c34974a
    • P
      OMAP2430 clock: make func_96m_ck parent-selectable · 5173804f
      由 Paul Walmsley 提交于 
      func_96m_ck was incorrectly marked as being rate-selectable, when in
fact it is only parent-selectable.  Remove the .set_rate and .round_rate
function pointers for this clk.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      5173804f
    • P
      OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files · 81b34fbe
      由 Paul Walmsley 提交于 
      In preparation for multi-OMAP2 kernels, split
mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and
mach-omap2/clock2430_data.c.  2430 uses a different device space
physical memory layout than past or future OMAPs, and we use a
different virtual memory layout as well, which causes trouble for
architecture-level code/data that tries to support both.  We tried
using offsets from the virtual base last year, but those patches never
made it upstream; so after some discussion with Tony about the best
all-around approach, we'll just grit our teeth and duplicate the
structures.  The maintenance advantages of a single kernel config that
can compile and boot on OMAP2, 3, and 4 platforms are simply too
compelling.

This approach does have some nice benefits beyond multi-OMAP 2 kernel
support.  The runtime size of OMAP2420-specific and OMAP2430-specific
kernels is smaller, since unused clocks for the other OMAP2 chip will
no longer be compiled in.  (At some point we will mark the clock data
__initdata and allocate it during registration, which will eliminate
the runtime memory advantage.)  It also makes the clock trees slightly
easier to read, since 2420-specific and 2430-specific clocks are no
longer mixed together.

This patch also splits 2430-specific clock code into its own file,
mach-omap2/clock2430.c, which is only compiled in for 2430 builds -
mostly for organizational clarity.

While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was
incorrectly marked as being 2420-only, when actually it is present on
both OMAP2420 and OMAP2430.

Thanks to Tony for some good discussions about how to approach this
problem.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      81b34fbe
    • P
      OMAP3/4 clock: split into per-chip family files · 657ebfad
      由 Paul Walmsley 提交于 
      clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c.  Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate.  So now "clock3xxx.*" refers to the OMAP3
superset.

The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family.  To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.

OMAP4 is also affected by this.  It duplicated the OMAP3 non-CORE DPLL
clkops structure.  The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it.  (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
      657ebfad
    • P
      OMAP clock: drop .id field; ensure each clock has a unique name · b92c170d
      由 Paul Walmsley 提交于 
      After the clkdev conversion, the struct clk.id field became
superfluous, so, drop it.  Bring the clock names closer to the TRMs
and ensure they are unique for debugfs.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b92c170d
    • P
      OMAP2 clock: drop CONFIG_PARTICIPANT clock flag · 1a337717
      由 Paul Walmsley 提交于 
      It turns out that the only purpose of the CONFIG_PARTICIPANT clock
flag is to prevent omap2_clk_set_rate() and omap2_clk_set_parent()
from being executed on clocks with that flag set.  The rate-changing
component can be more directly accomplished by dropping the .set_rate
and .round_rate function pointers from those CONFIG_PARTICIPANT struct
clks.  As far as the parent-changing component is concerned, it turns
out that none of the CONFIG_PARTICIPANT clocks have multiple parent
choices, so all that is necessary is for omap2_clk_set_parent() to
bail out early if the new parent is equal to the old parent.
Implement this change and get rid of the flag, which has always had a
confusing name (it appears to be a Kconfig option, falsely).
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      1a337717
    • P
      OMAP2xxx clock: drop DELAYED_APP flag from non-clksel clocks · 17d09273
      由 Paul Walmsley 提交于 
      The DELAYED_APP flag is effective only with clksel clocks, so drop it from
clocks that are not rate-changeable or that use non-clksel rate changing code
(e.g., virt_prcm_set).
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      17d09273
    • P
      OMAP2xxx clock: GFX functional clock rates are not independently changeable · 94297784
      由 Paul Walmsley 提交于 
      According to the OMAP242x TRM Rev X Figure 5-15 "Clock Output Control
- Functional Clocks 2", the GFX functional clocks should be marked
both DELAYED_APP and CONFIG_PARTICIPANT, meaning that their rates must
be reprogrammed as part of a larger OPP set change.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      94297784
    • P
      OMAP4 clock: drop the CLOCK_IN_OMAP4430 clock flag · c78a05e8
      由 Paul Walmsley 提交于 
      The CLOCK_IN_OMAP4430 clock flag is not currently needed in the OMAP4
ES1 clock tree, and platform discrimination via clock flags is
deprecated in favor of the clkdev mechanism, so, drop it.  (The OMAP4
clock tree autogeneration script has been updated accordingly.)
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      c78a05e8
    • P
      OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation · 93340a22
      由 Paul Walmsley 提交于 
      The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are
one increment higher than they should be.  See for example the
OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the
OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL".  Programming a 0 into
the DPLL's M register bitfield is valid for OMAP2/3 and indicates that
the DPLL should enter MN-bypass mode.  Also, increase the minimum
multiplier (M) value for the DPLL rate rounding code from 1 to 2, to
ensure that it does not inadvertently put the DPLL into bypass.

Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs
does not make clear that the actual DPLL divider value (the "N") is
the content of the appropriate register bitfield for the N value,
_plus one_.  (In other words, an N register bitfield of 0 indicates a
DPLL divider value of 1.)  This is only clearly documented in the
OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167
"CM_CLKSEL_DPLL_USB".

While here, update copyrights, add kerneldoc for struct dpll_data,
drop the unused struct dpll_data.max_tolerance field, remove some
unnecessary #includes in DPLL-related code, and replace the #include
of <linux/module.h> with <linux/list.h>, which is what was really
needed.  The OMAP4 clock autogenerator script has been updated
accordingly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      93340a22
    • V
      OMAP3 clock: add support for 192Mhz DPLL4M2 output · 7356f0b2
      由 Vishwanath BS 提交于 
      In 3630, DPLL4M2 output can be 96MHz or 192MHz (for SGX to run at
192). This patch has changes to support this feature. 96MHz clock is
generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register.
SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's
functional clock. In summary changes done are:
1. Added a feature called omap3_has_192mhz_clk and enabled for 3630
2. Added a new clock node called omap_192m_alwon_ck
3. Made omap_96m_alwon_fck to derive its clock from omap_192m_alwon_ck
Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
[paul@pwsan.com: fixed whitespace]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7356f0b2