1. 25 2月, 2010 1 次提交
    • 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
  2. 27 1月, 2010 1 次提交
  3. 20 1月, 2010 1 次提交
    • T
      OMAP3: hwmod: Adding flag to prevent caching of sysconfig register. · 883edfdd
      Thara Gopinath 提交于
      In the current implementation the sysconfig value is read into
       _sysc_cache once and an actual update to the sysconfig register
      happens only if the new value paased is differnt from the one in _sysc_cache.
      _sysc_cache is updated only if _HWMOD_SYSCONFIG_LOADED is not set.
      This can lead to the follwing issue if off mode is enabled in modules
      which employs "always-retore" mechanism of context save and restore.
      
              a. The module sets the sysconfig register through omap_device_enable.
                 Here _sysc_cache is updated with the value written to the sysconfig
                 register and left.
              b. The power domain containig the module enters off mode and the
                 module context is lost.
              c. The module in use becomes active and calls omap_device_enable to
                 enable itself. Here a read of sysconfig register does not happen
                 as _HWMOD_SYSCONFIG_LOADED flag is set. The value to be written
                 to the sysconfig register will be same as the one written in step a.
                 Since _sysc_cache reflects the previous written value an update
                 of the sysconfig register does not happen.
      This means in modules which employs "always-restore" mechanism
      after off , the sysconfig regsiters will never get updated.
      
      This patch introduces a flag SYSC_NO_CACHE which if set ensures that the
      sysconfig register is always read into _sysc_cache before an update is
      attempted.
      
      This flags need to be set only by modules which does not do a context save
      but re-initializes the registers every time the module is accessed. This
      includes modules like i2c, smartreflex etc.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      [paul@pwsan.com: tweaked to apply on a different head, added flag comment]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      883edfdd
  4. 12 12月, 2009 2 次提交
    • P
      OMAP hwmod: add names to module MPU IRQ lines · 718bfd76
      Paul Walmsley 提交于
      Replace the existing u8 array of module MPU IRQ lines with a struct
      that includes a name - similar to the existing struct
      omap_hwmod_dma_info.  Device drivers can then use
      platform_get_resource_byname() to retrieve specific IRQs without nasty
      dependencies on array ordering.
      
      Thanks to Benoît Cousson <b-cousson@ti.com> and Kevin Hilman
      <khilman@deeprootsystems.com> for feedback on this approach.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      718bfd76
    • P
      OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling · 726072e5
      Paul Walmsley 提交于
      This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP
      hwmod code.
      
      After this patch, the hwmod code will set the module AUTOIDLE bit
      (generally <module>.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon
      enable.  If the hwmod flag HWMOD_NO_OCP_AUTOIDLE is set, AUTOIDLE will
      be set to 0 upon enable.  Upon module disable, AUTOIDLE will be set to
      1.
      
      Enabling module autoidle should save some power.  The only reason to
      not set the OCP_SYSCONFIG.AUTOIDLE bit is if there is a bug in the
      module RTL, e.g., the MPUINTC block on OMAP3.
      
      Comments from Kevin Hilman <khilman@deeprootsystems.com> inspired this patch,
      and Kevin tested an earlier version of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      726072e5
  5. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      Tony Lindgren 提交于
      Move the remaining headers under plat-omap/include/mach
      to plat-omap/include/plat. Also search and replace the
      files using these headers to include using the right path.
      
      This was done with:
      
      #!/bin/bash
      mach_dir_old="arch/arm/plat-omap/include/mach"
      plat_dir_new="arch/arm/plat-omap/include/plat"
      headers=$(cd $mach_dir_old && ls *.h)
      omap_dirs="arch/arm/*omap*/ \
      drivers/video/omap \
      sound/soc/omap"
      other_files="drivers/leds/leds-ams-delta.c \
      drivers/mfd/menelaus.c \
      drivers/mfd/twl4030-core.c \
      drivers/mtd/nand/ams-delta.c"
      
      for header in $headers; do
      	old="#include <mach\/$header"
      	new="#include <plat\/$header"
      	for dir in $omap_dirs; do
      		find $dir -type f -name \*.[chS] | \
      			xargs sed -i "s/$old/$new/"
      	done
      	find drivers/ -type f -name \*omap*.[chS] | \
      		xargs sed -i "s/$old/$new/"
      	for file in $other_files; do
      		sed -i "s/$old/$new/" $file
      	done
      done
      
      for header in $(ls $mach_dir_old/*.h); do
      	git mv $header $plat_dir_new/
      done
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  6. 04 9月, 2009 1 次提交
    • P
      OMAP2/3/4: create omap_hwmod layer · 63c85238
      Paul Walmsley 提交于
      OMAP SoCs can be considered a collection of hardware IP blocks
      connected by various interconnects.  The bus topology and device
      integration data is somewhat more complex than platform_device can
      encode.  This patch creates code and structures to manage information
      about OMAP on-chip devices ("hardware modules") and their integration
      to the rest of the chip.  Hardware module data is intended to be
      generated dynamically from the TI hardware database for the OMAP4
      chips and beyond, easing Linux support for new chip variants.
      
      This code currently:
      
      - resets and configures all hardware modules upon startup, reducing bootloader
        dependencies;
      
      - provides hooks for Linux driver model code to enable, idle, and shutdown
        hardware modules (forthcoming patch);
      
      - waits for hardware modules to leave idle once their clocks
        are enabled and OCP_SYSCONFIG bits are set appropriately.
      
      - provides a means to pass arbitrary IP block configuration data (e.g.,
        FIFO size) to the device driver (via the dev_attr void pointer)
      
      In the future this code is intended to:
      
      - estimate interconnect bandwidth and latency characteristics to
        ensure constraints are satisfied during DVFS
      
      - provide *GRPSEL bit data to the powerdomain code
      
      - handle pin/ball muxing for devices
      
      - generate IO mapping information dynamically
      
      - supply device firewall configuration data
      
      - provide hardware module data to other on-chip coprocessor software
      
      - allow the removal of the "disable unused clocks" code in the OMAP2/3
        clock code
      
      This patch represents a collaborative effort involving many people from TI,
      Nokia, and the Linux-OMAP community.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vikram Pandita <vikram.pandita@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Eric Thomas <ethomas@ti.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      63c85238