1. 09 Aug, 2019 4 commits
    • Suman Anna's avatar
      iommu/omap: add logic to save/restore locked TLBs · c3b44a06
      Suman Anna authored
      The MMUs provide a mechanism to lock TLB entries to avoid
      eviction and fetching of frequently used page table entries.
      These TLBs lose context when the MMUs are turned OFF. Add the
      logic to save and restore these locked TLBS during suspend
      and resume respectively. There are no locked TLBs during
      initial power ON, and they need not be saved during final
      shutdown.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      c3b44a06
    • Suman Anna's avatar
      iommu/omap: streamline enable/disable through runtime pm callbacks · db8918f6
      Suman Anna authored
      The OMAP IOMMU devices are typically present within the respective
      client processor subsystem and have their own dedicated hard-reset
      line. Enabling an IOMMU requires the reset line to be deasserted
      and the clocks to be enabled before programming the necessary IOMMU
      registers. The IOMMU disable sequence follow the reverse order of
      enabling. The OMAP IOMMU driver programs the reset lines through
      pdata ops to invoke the omap_device_assert/deassert_hardreset API.
      The clocks are managed through the pm_runtime framework, and the
      callbacks associated with the device's pm_domain, implemented in
      the omap_device layer.
      
      Streamline the enable and disable sequences in the OMAP IOMMU
      driver by implementing all the above operations within the
      runtime pm callbacks. All the OMAP devices have device pm_domain
      callbacks plugged in the omap_device layer for automatic runtime
      management of the clocks. Invoking the reset management functions
      within the runtime pm callbacks in OMAP IOMMU driver therefore
      requires that the default device's pm domain callbacks in the
      omap_device layer be reset, as the ordering sequence for managing
      the reset lines and clocks from the pm_domain callbacks don't gel
      well with the implementation in the IOMMU driver callbacks. The
      omap_device_enable/omap_device_idle functions are invoked through
      the newly added pdata ops.
      
      Consolidating all the device management sequences within the
      runtime pm callbacks allows the driver to easily support both
      system suspend/resume and runtime suspend/resume using common
      code.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      db8918f6
    • Suman Anna's avatar
      iommu/omap: add pdata ops for omap_device_enable/idle · 74c116df
      Suman Anna authored
      Add two new platform data ops to allow the OMAP iommu driver to
      be able to invoke the omap_device_enable and omap_device_idle
      from within the driver. These are being added to streamline the
      sequence between managing the hard reset lines and the clocks
      during the suspend path, as the default device pm_domain callback
      sequences in omap_device layer are not conducive for the OMAP
      IOMMU driver.
      
      This could have been done by expanding the existing pdata ops
      for reset management (like in the OMAP remoteproc driver), but
      this was chosen to avoid adding additional code in the separate
      file in the mach-omap2 layer.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      74c116df
    • Suman Anna's avatar
      iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache · 3846a3b9
      Suman Anna authored
      Support has been added to the OMAP IOMMU driver to fix a boot hang
      issue on OMAP remoteprocs with AMMU/Unicache, caused by an improper
      AMMU/Unicache state upon initial deassertion of the processor reset.
      The issue is described in detail in the next three paragraphs.
      
      All the Cortex M3/M4 IPU processor subsystems in OMAP SoCs have a
      AMMU/Unicache IP that dictates the memory attributes for addresses
      seen by the processor cores. The AMMU/Unicache is configured/enabled
      by the SCACHE_CONFIG.BYPASS bit - a value of 1 enables the cache and
      mandates all addresses accessed by M3/M4 be defined in the AMMU. This
      bit is not programmable from the host processor. The M3/M4 boot
      sequence starts out with the AMMU/Unicache in disabled state, and
      SYS/BIOS programs the AMMU regions and enables the Unicache during
      one of its initial boot steps. This SCACHE_CONFIG.BYPASS bit is
      however enabled by default whenever a RET reset is applied to the IP,
      irrespective of whether it was previously enabled or not. The AMMU
      registers lose their context whenever this reset is applied. The reset
      is effective as long as the MMU portion of the subsystem is enabled
      and clocked. This behavior is common to all the IPU and DSP subsystems
      that have an AMMU/Unicache.
      
      The IPU boot sequence involves enabling and programming the MMU, and
      loading the processor and releasing the reset(s) for the processor.
      The PM setup code currently sets the target state for most of the
      power domains to RET. The L2 MMU can be enabled, programmed and
      accessed properly just fine with the domain in hardware supervised
      mode, while the power domain goes through a RET->ON->RET transition
      during the programming sequence. However, the ON->RET transition
      asserts a RET reset, and the SCACHE_CONFIG.BYPASS bit gets auto-set.
      An AMMU fault is thrown immediately when the M3/M4 core's reset is
      released since the first instruction address itself will not be
      defined in any valid AMMU regions. The ON->RET transition happens
      automatically on the power domain after enabling the iommu due to
      the hardware supervised mode.
      
      This patch adds and invokes the .set_pwrdm_constraint pdata ops, if
      present, during the OMAP IOMMU enable and disable functions to resolve
      the above boot hang issue. The ops will allow to invoke a mach-omap2
      layer API pwrdm_set_next_pwrst() in a multi-arch kernel environment.
      The ops also returns the current power domain state while enforcing
      the constraint so that the driver can store it and use it to set back
      the power domain state while releasing the constraint. The pdata ops
      implementation restricts the target power domain to ON during enable,
      and back to the original power domain state during disable, and thereby
      eliminating the conditions for the boot issue. The implementation is
      effective only when the original power domain state is either RET or
      OFF, and is a no-op when it is ON or INACTIVE.
      
      The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
      for the affected remote processors to be able to boot properly.
      
      Note that the current issue is seen only on kernels with the affected
      power domains programmed to enter RET. For eg., IPU1 on DRA7xx is in a
      separate domain and is susceptible to this bug, while the IPU2 subsystem
      is within CORE power domain, and CORE RET is not supported on this SoC.
      IPUs on OMAP4 and OMAP5 are also susceptible since they are in CORE power
      domain, and CORE RET is a valid power target on these SoCs.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      3846a3b9
  2. 05 Aug, 2019 1 commit
  3. 04 Aug, 2019 10 commits
  4. 03 Aug, 2019 25 commits