• Tony Lindgren's avatar
    ARM: dts: omap4: Add l4 interconnect hierarchy and ti-sysc data · 8f42cb7f
    Tony Lindgren authored
    Let's add proper interconnect hierarchy for l4 interconnect
    instances with the related ti-sysc interconnect module data as
    documented in Documentation/devicetree/bindings/bus/ti-sysc.txt.
    
    Using ti-sysc driver binding allows us to start dropping
    legacy platform data in arch/arm/mach-omap2/omap*hwmod*data.c
    files later on in favor of ti-sysc dts data.
    
    For setting up a proper hierarchy for the interconnect and
    ti-sysc data, there are multiple reasons:
    
    1. We can use dts ranges to protect registers from being
       ioremapped from other devices and prevent hard to track
       issues with failed flush of posted write between modules
    
    2. Some of the ranges may not be accessible to operating systems
       at all if configured so on high-security devices
    
    3. The interconnect hierarchy provides proper clockdomain
       hierarchy that can be used for genpd later on
    
    4. We can avoid almost all deferred probe related issues simply
       by probing the resource providing interconnect instance first
       for l4 wkup instance
    
    5. With deferred probe issues gone, we can probe everything
       later at module_init time except for system timer and interrupt
       controller and their clocks.
    
    This data is generated based on platform data from a booted system
    and the interconnect acces protection registers for ranges. To avoid
    regressions, we initially validate the device tree provided data
    against the existing platform data on boot.
    
    Each interconnect instance is typically divided into segments
    to avoid powering up the whole interconnect. And each segment
    has one or more ranges TI specific interconnect target modules
    connected to it. Some devices can also have a separate data
    access port directly to the parent L3 interconnect for DMA that
    can be set up as a separate range.
    
    Note that we cannot yet include this file from omap4.dtsi
    until child devices are moved to their proper locations in
    the interconnect hierarchy in the following patch. Otherwise
    we would have the each module probed twice.
    
    Also note that this does not yet add l4 abe instance, that will
    be added separately later on.
    Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
    8f42cb7f
omap4-l4.dtsi 55.7 KB