• Nishanth Menon's avatar
    ti: k3: common: sec_proxy: Introduce sec_proxy_lite definition · 7f323eb2
    Nishanth Menon authored
    There are two communication scheme that have been enabled to communicate
    with Secure Proxy in TI.
    a) A full fledged prioritized communication scheme, which involves upto
       5 threads from the perspective of the host software
    b) A much simpler "lite" version which is just a two thread scheme
       involving just a transmit and receive thread scheme.
    
    The (a) system is specifically useful when the SoC is massive
    involving multiple processor systems and where the potential for
    priority inversion is clearly a system usecase killer. However, this
    comes with the baggage of significant die area for larger number of
    instances of secure proxy, ring accelerator and backing memories
    for queued messages. Example SoCs using this scheme would be:
    AM654[1], J721E[2], J7200[3]  etc.
    
    The (b) scheme(aka the lite scheme) is introduced on smaller SoCs
    where memory and area concerns are paramount. The tradeoff of
    priority loss is acceptable given the reduced number of processors
    communicating with the central system controller. This brings about
    a very significant area and memory usage savings while the loss of
    communication priority has no demonstrable impact. Example SoC using
    this scheme would be: AM642[4]
    
    While we can detect using JTAG ID and conceptually handle things
    dynamically, adding such a scheme involves a lot of unused data (cost
    of ATF memory footprint), pointer lookups (performance cost) and still
    due to follow on patches, does'nt negate the need for a different
    build configuration. However, (a) and (b) family of SoCs share the
    same scheme and addresses etc, this helps minimize our churn quite a
    bit
    
    Instead of introducing a complex data structure lookup scheme, lets
    keep things simple by first introducing the pieces necessary for an
    alternate communication scheme, then introduce a second platform
    representing the "lite" family of K3 processors.
    
    NOTE: This is only possible since ATF uses just two (secure) threads
    for actual communication with the central system controller. This is
    sufficient for the function that ATF uses.
    
    The (a) scheme and the (b) scheme also varies w.r.t the base addresses
    used, even though the memory window assigned for them have remained
    consistent. We introduce the delta as part of this change as well.
    This is expected to remain consistent as a standard in TI SoCs.
    
    References:
    [1] See AM65x Technical Reference Manual (SPRUID7, April 2018)
    for further details: https://www.ti.com/lit/pdf/spruid7
    
    [2] See J721E Technical Reference Manual (SPRUIL1, May 2019)
    for further details: https://www.ti.com/lit/pdf/spruil1
    
    [3] See J7200 Technical Reference Manual (SPRUIU1, June 2020)
    for further details: https://www.ti.com/lit/pdf/spruiu1
    
    [4] See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
    for further details: https://www.ti.com/lit/pdf/spruim2
    
    Signed-off-by: default avatarNishanth Menon <nm@ti.com>
    Change-Id: I697711ee0e6601965015ddf950fdfdec8e759bfc
    7f323eb2
platform_def.h 5.79 KB