Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 5月, 2010 1 次提交
  3. 12 3月, 2010 1 次提交
  5. 25 2月, 2010 5 次提交
    • 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
      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
    • T
      OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. · 358f0e63
      由 Thara Gopinath 提交于 
      In OMAP3 Some modules like Smartreflex do not have the regular sysconfig
register.Instead clockactivity bits are part of another register at a
different bit position than the usual bit positions 8 and 9.

In OMAP4, a new scheme is available  due to the new protocol
between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG
bitfields position will be different.
The IP_REVISION register should be at offset 0x00.
It should contain a SCHEME field. From this we can determine whether
the IP follows legacy scheme or the new scheme.

31:30 SCHEME  Used to distinguish between old scheme and current.
 Read 0x0:  Legacy protocol.
 Read 0x1:  New PRCM protocol defined for new OMAP4 IPs

For legacy IP
 13:12 MIDLEMODE
 11:8  CLOCKACTIVITY
 6     EMUSOFT
 5     EMUFREE
 4:3   SIDLEMODE
 2     ENAWAKEUP
 1     SOFTRESET
 0     AUTOIDLE

For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target):
 5:4   STANDBYMODE (Ex MIDLEMODE)
 3:2   IDLEMODE (Ex SIDLEMODE)
 1     FREEEMU (Ex EMUFREE)
 0     SOFTRESET

Unfortunately In OMAP4 also some IPs will not follow any of these
two schemes. This is the case at least for McASP, SmartReflex
and some security IPs.

This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which
can be used by the hwmod structures to specify the offsets for the
sysconfig register of the IP.Also two static structures
omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined
which can be used directly to populate the sysc_fields if the IP follows
legacy or new OMAP4 scheme. If the IP follows none of these two schemes
a new omap_hwmod_sysc_fields structure has to be defined and
passed as part of omap_hwmod_sysconfig.
Signed-off-by: NThara Gopinath <thara@ti.com>
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      358f0e63
  7. 20 2月, 2010 1 次提交
  9. 16 2月, 2010 5 次提交
  11. 29 1月, 2010 4 次提交
    • P
      OMAP3 clock: split out DPLL3 M2 divider functions into mach-omap2/clkt34xx_dpll3m2.c · 35e424e2
      由 Paul Walmsley 提交于 
      Split the DPLL3 M2 divider clock functions out of clock34xx.c and move
them into mach-omap2/clkt34xx_dpll3m2.c. This is intended to make the
clock code easier to understand, since all of the functions needed to
manage the OMAP3 DPLL3 M2 divider are now located in their own file,
rather than being mixed with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG macro
can now be defined for the DPLL3 M2 clock alone.  This should reduce
unnecessary console noise when debugging DVFS.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap34xx/
directory, rather than shared with other chip types that don't use this
clock type.

This patch also lays the groundwork to skip compilation of this
code on OMAP3 chips that don't support DVFS (e.g., AM35xx) via
the Makefile, rather than via #ifdefs.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Jouni Högander <jouni.hogander@nokia.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
      35e424e2
    • P
      OMAP2xxx clock: move sys_clk code into mach-omap2/clkt2xxx_sys.c · 44da0a51
      由 Paul Walmsley 提交于 
      Move the sys_clk clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_sys.c.  This is intended to make the clock code
easier to understand, since all of the functions needed to manage the
sys_clk are now located in their own file, rather than being mixed
with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG
macro can now be defined for the sys_clk clock alone.  This
should reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split into
OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use
this clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
      44da0a51
    • P
      OMAP2xxx clock: move osc_clk code into mach-omap2/clkt2xxx_osc.c · 87a1b26c
      由 Paul Walmsley 提交于 
      Move the osc_clk clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_osc.  This is intended to make the clock code
easier to understand, since all of the functions needed to manage the
osc_clk are now located in their own file, rather than being mixed
with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG
macro can now be defined for osc_clk clocks alone.  This
should reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use this
clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
      87a1b26c
    • P
      OMAP2xxx clock: move the APLL clock code into mach-omap2/clkt2xxx_apll.c · 49214640
      由 Paul Walmsley 提交于 
      Move the APLL-related clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_apll.c.  This is intended to make the clock code
easier to understand, since all of the functions needed to manage APLLs
are now located in their own file, rather than being mixed with other,
unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG
macro can now be defined for APLL clocks alone.  This
should reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use this
clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
      49214640
  13. 27 1月, 2010 7 次提交
    • P
      OMAP2xxx clock: move the DVFS virtual clock code into mach-omap2/clkt2xxx_virt_prcm_set.c · 734f69a7
      由 Paul Walmsley 提交于 
      Move the DVFS virtual clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_virt_prcm_set.c.  This is intended to make the
clock code easier to understand, since all of the functions needed to
manage the virt_prcm_set clock are now located in their own file,
rather than being mixed with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG macro
can now be defined for the virt_prcm_set clock alone.  This should
reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split into
OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use
this clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments.
Thanks also to Kevin Hilman <khilman@deeprootsystems.com> for finding
and fixing a bug with the CONFIG_CPU_FREQ portion of this patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
      734f69a7
    • P
      OMAP2xxx clock: move the DPLL+CORE composite clock code into mach-omap2/clkt2xxx_dpllcore.c · b1823d86
      由 Paul Walmsley 提交于 
      Move the DPLL+CORE composite clock functions from clock2xxx.c to
mach-omap2/clkt2xxx_dpllcore.c.  This is intended to make the clock
code easier to understand, since all of the functions needed to manage
the OMAP2 DPLL+CORE clock are now located in their own file, rather
than being mixed with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG
macro can now be defined for the DPLL+CORE clock alone.  This
should reduce unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
directory, rather than shared with other chip types that don't use this
clock type.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
      b1823d86
    • P
      OMAP2/3/4 clock: move clksel clock functions into mach-omap2/clkt_clksel.c · df791b3e
      由 Paul Walmsley 提交于 
      Move all clksel-related clock functions from mach-omap2/clock.c to
mach-omap2/clkt_clksel.c.  This is intended to make the clock code
easier to understand, since all of the functions needed to manage
clksel clocks are now located in their own file, rather than being
mixed with other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG macro
can now be defined for clksel clocks alon.  This should reduce
unnecessary console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be moved to the plat-omap/
directory to be shared.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
      df791b3e
    • P
      OMAP2/3/4 clock: move DPLL clock functions into mach-omap2/clkt_dpll.c · 0b96af68
      由 Paul Walmsley 提交于 
      Move all DPLL-related clock functions from mach-omap2/clock.c to
mach-omap2/clkt_dpll.c.  This is intended to make the clock code
easier to understand, since all of the functions needed to manage
DPLLs are now located in their own file, rather than being mixed with
other, unrelated functions.

Clock debugging is also now more finely-grained, since the DEBUG macro
can now be defined for DPLLs alone.  This should reduce unnecessary
console noise when debugging.

Also, if at some future point the mach-omap2/ directory is split
into OMAP2/3/4 variants, this clkt file can be moved to the plat-omap/
directory to be shared.

Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
improve the patch description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Alexander Shishkin <virtuoso@slind.org>
      0b96af68
    • P
      OMAP3 clock: move OMAP3-specific DPLL functions to dpll3xxx.c · 98c45457
      由 Paul Walmsley 提交于 
      Mark the OMAP3-specific DPLL functions as being OMAP3-specific by moving
them from mach-omap2/dpll.c to mach-omap2/dpll3xxx.c.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      98c45457
    • A
      ARM: OMAP4: PM: Refine the APIs to support OMAP4 features. · 8a3ddc75
      由 Abhijit Pagare 提交于 
      Port the APIs to support the OMAP4 clockdomain framework.
Also take care of the compiling requirements for the same.
Signed-off-by: NAbhijit Pagare <abhijitpagare@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      8a3ddc75
    • A
      ARM: OMAP4: PM: Refine the APIs to support OMAP4 features. · 3a759f09
      由 Abhijit Pagare 提交于 
      The proper Macros have to be used for platform specific calls and
some of the compiling requirements and init calls are taken care of.
Signed-off-by: NAbhijit Pagare <abhijitpagare@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
      3a759f09
  15. 12 12月, 2009 9 次提交
  17. 02 12月, 2009 1 次提交
  19. 26 11月, 2009 4 次提交
  21. 23 11月, 2009 2 次提交