1. 10 7月, 2011 5 次提交
  2. 22 12月, 2010 6 次提交
    • P
      OMAP4: CM instances: add clockdomain register offsets · e4156ee5
      Paul Walmsley 提交于
      In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP,
      CM_DYNAMICDEP, and the module-specific registers underneath) are
      organized by clockdomain.  Add the clockdomain offset macros to the
      appropriate PRCM module header files.
      
      This data was almost completely autogenerated from the TI hardware
      database; the autogeneration scripts have been updated.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      e4156ee5
    • P
      OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file · dac9a771
      Paul Walmsley 提交于
      Move the OMAP4 global software reset function to the OMAP4-specific
      prm44xx.c file, where it belongs.  Part of the long-term process of
      moving all of the direct PRCM register writes into lower-layer code.
      
      Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU
      will continue executing while the system is supposed to be resetting
      itself.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      dac9a771
    • P
      OMAP4: PRCM: add OMAP4-specific accessor/mutator functions · 2ace831f
      Paul Walmsley 提交于
      In some ways, the OMAP4 PRCM register layout is quite different than
      the OMAP2/3 PRCM register layout.  For example, on OMAP2/3, from a
      register layout point of view, all CM instances were located in the CM
      subsystem, and all PRM instances were located in the PRM subsystem.
      OMAP4 changes this.  Now, for example, some CM instances, such as
      WKUP_CM and EMU_CM, are located in the system PRM subsystem.  And a
      "local PRCM" exists for the MPU - this PRCM combines registers that
      would normally appear in both CM and PRM instances, but uses its own
      register layout which matches neither the OMAP2/3 PRCM layout nor the
      OMAP4 PRCM layout.
      
      To try to deal with this, introduce some new functions, omap4_cminst*
      and omap4_prminst*.  The former is to be used when writing to a CM
      instance register (no matter what subsystem or hardware module it
      exists in), and the latter, similarly, with PRM instance registers.
      To determine which "PRCM partition" to write to, the functions take a
      PRCM instance ID argument.  Subsequent patches add these partition IDs
      to the OMAP4 powerdomain and clockdomain definitions.
      
      As far as I can see, there's really no good way to handle these types
      of register access inconsistencies.  This patch seemed like the least
      bad approach.
      
      Moving forward, the long-term goal is to remove all direct PRCM
      register access from the PM code.  PRCM register access should go
      through layers such as the powerdomain and clockdomain code that can
      hide the details of how to interact with the specific hardware
      variant.
      
      While here, rename cm4xxx.c to cm44xx.c to match the naming convention
      of the other OMAP4 PRCM files.
      
      Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
      <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      2ace831f
    • P
      OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files · 59fb659b
      Paul Walmsley 提交于
      In preparation for adding OMAP4-specific PRCM accessor/mutator
      functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
      files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
      moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
      OMAP2xxx/3xxx-specific.
      
      This process also requires the #includes in each of these files to be
      changed to reference the new file name.  As part of doing so, add some
      comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
      "sideways includes", to indicate that these users of the PRM/CM includes
      should not be doing so.
      
      Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
      patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Cc: Liam Girdwood <lrg@slimlogic.co.uk>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Acked-by: NFelipe Contreras <felipe.contreras@gmail.com>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      59fb659b
    • P
      OMAP4: PRCM: rename _MOD macros to _INST · cdb54c44
      Paul Walmsley 提交于
      Back in the OMAP2/3 PRCM interface days, the macros that referred to
      the offsets of individual PRM/CM instances from the top of the PRM/CM
      hardware modules were incorrectly suffixed with "_MOD".  (They should
      have been suffixed with something like "_INST" or "_INSTANCE".)  These
      days, now that we have better contact with the OMAP hardware people,
      we know that this naming is wrong.  And in fact in OMAP4, there are
      actual hardware module offsets inside the instances, so the incorrect
      naming gets confusing very quickly for anyone who knows the hardware.
      
      Fix this naming for OMAP4, before things get too far along, by
      changing "_MOD" to "_INST" on the end of these macros.  So, for
      example, OMAP4430_CM2_INSTR_MOD becomes OMAP4430_CM2_INSTR_INST.
      
      This unfortunately creates quite a large diff, but it is a
      straightforward rename.  This patch should not result in any
      functional changes.
      
      The 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: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      cdb54c44
    • P
      OMAP4: PRCM: reorganize existing OMAP4 PRCM header files · d198b514
      Paul Walmsley 提交于
      Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files
      so they match their underlying OMAP hardware modules.  Add clockdomain
      offset information.
      
      Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the
      SCRM, scrm44xx.h.  SCRM register offsets still need to be added; TI
      should do this.
      
      Move the "_MOD" macros out of the prcm-common.h header file, into the
      header file of the hardware module that they belong to.  For example,
      OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header.
      
      Adjust #includes of all files that used the old PRCM header file names
      to point to the new filenames.
      
      The 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>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      d198b514
  3. 28 9月, 2010 1 次提交
  4. 21 5月, 2010 2 次提交
  5. 21 1月, 2010 1 次提交
  6. 12 12月, 2009 1 次提交