1. 13 5月, 2010 3 次提交
  2. 01 5月, 2010 1 次提交
  3. 24 4月, 2010 5 次提交
  4. 23 4月, 2010 3 次提交
  5. 31 3月, 2010 1 次提交
  6. 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
  7. 13 3月, 2010 1 次提交
  8. 12 3月, 2010 5 次提交
  9. 26 2月, 2010 2 次提交
  10. 25 2月, 2010 18 次提交
    • 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
    • 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
    • K
      ARM: 5952/1: ARM: MM: Add ARM_L1_CACHE_SHIFT_6 for handle inside each ARCH Kconfig · d6d502fa
      Kukjin Kim 提交于
      Add ARM_L1_CACHE_SHIFT_6 to arch/arm/Kconfig to allow CPUs with
      L1 cache lines which are 64bytes to indicate this without having to
      alter the arch/arm/mm/Kconfig entry each time.
      
      Update the mm Kconfig so that ARM_L1_CACHE_SHIFT default value
      uses this and change OMAP3 and S5PC1XX to select ARM_L1_CACHE_SHIFT_6.
      Acked-by: NBen Dooks <ben-linux@fluff.org>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d6d502fa
    • 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
    • P
      OMAP clock: add omap_clk_get_by_name() for use by OMAP hwmod core code · 74be8427
      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 adds a non-exported function to the OMAP clock code,
      omap_clk_get_by_name().  A subsequent patch will convert the hwmod
      code to use this function.
      
      This function is for use only by core code, and practically, no other
      code outside the hwmod code should need it.  Device driver code in the
      kernel must not use this function, which is why it is not exported.
      Drivers should use the appropriate clock alias provided by the clkdev
      data structures, so driver code can be completely SoC-independent.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      74be8427
    • 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
      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
      OMAP clock: compress clock flags down to a u8 · f71eddb1
      Paul Walmsley 提交于
      There are now only eight OMAP clock flags, so renumber the flags to
      fit in a u8 and shrink the size of struct clk.flags from a u32 to a
      u8.  The intention is to save memory.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f71eddb1
    • 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
      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
    • V
      OMAP3 clock: Introduce 3630 DPLL4 HSDivider changes · 678bc9a2
      Vishwanath BS 提交于
      Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
      in 3630. This patch has changes to accommodate this in CM dynamically
      based on chip version.
      Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
      M6 and value of these nodes are used if cpu type is 3630.
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      [paul@pwsan.com: updated to apply on 2.6.34 queue; comments added]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      678bc9a2
    • R
      OMAP3 clock: introduce DPLL4 Jtype · 358965d7
      Richard Woodruff 提交于
      DPLL4 for 3630 introduces a changed block called j type dpll, requiring
      special divisor bits and additional reg fields. To allow for silicons to
      use this, this is introduced as a flag and is enabled for 3630 silicon.
      OMAP4 also has j type dpll for usb.
      
      Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
      Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
      [paul@pwsan.com: added some comments; updated copyrights and credits; fixed
       some style issues]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      358965d7
    • T
      OMAP: HWMOD: Add support for early device register into omap device layer · c23a97d3
      Thara Gopinath 提交于
      This patch adds support in omap device layer to register devices
      as early platform devices. Certain devices needed during system boot up
      like timers, gpio etc can be registered as early devices. This will
      allow for them to be probed very early on during system boot up.
      This patch adds a parameter is_early_device in omap_device_build.
      Depending on this parameter a call to early_platform_add_devices
      or platform_register_device is made.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c23a97d3