• 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