• Archit Taneja's avatar
    OMAPDSS: outputs: Create a new entity called outputs · 484dc404
    Archit Taneja authored
    The current OMAPDSS design contains 3 software entities: Overlays, Managers and
    Devices. These map to pipelines, overlay managers and the panels respectively in
    hardware. One or more overlays connect to a manager to represent a composition,
    the manager connects to a device(generally a display) to display the content.
    
    The part of DSS hardware which isn't represented by any of the above entities
    are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
    HDMI, VENC and so on. Currently, an overlay manager directly connects to the
    display, and the output to which it is actually connected is ignored. The panel
    driver of the display is responsible of calling output specific functions to
    configure the output.
    
    Adding outputs as a new software entity gives us the following benefits:
    
    - Have exact information on the possible connections between managers and
      outputs: A manager can't connect to each and every output, there only limited
      hardware links between a manager's video port and some of the outputs.
    
    - Remove hacks related to connecting managers and devices: Currently, default
      links between managers and devices are set in a not so clean way. Matching is
      done via comparing the device type, and the display types supported by the
      manager. This isn't sufficient to establish all the possible links between
      managers, outputs and devices in hardware.
    
    - Make panel drivers more generic: The DSS panel drivers currently call
      interface/output specific functions to configure the hardware IP. When making
      these calls, the driver isn't actually aware of the underlying output. The
      output driver extracts information from the panel's omap_dss_device pointer
      to figure out which interface it is connected to, and then configures the
      corresponding output block. An example of this is when a DSI panel calls
      dsi functions, the dsi driver figures out whether the panel is connected
      to DSI1 or DSI2. This isn't correct, and having output as entities will
      give the panel driver the exact information on which output to configure.
      Having outputs also gives the opportunity to make panel drivers generic
      across different platforms/SoCs, this is achieved as omap specific output
      calls can be replaced by ops of a particular output type.
    
    - Have more complex connections between managers, outputs and devices: OMAPDSS
      currently doesn't support use cases like 2 outputs connect to a single
      device. This can be achieved by extending properties of outputs to connect to
      more managers or devices.
    
    - Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
      as compared to overlays, managers or devices.
    
    Add a new struct to represent outputs. An output struct holds pointers to the
    manager and device structs to which it is connected. Add functions which can
    register/unregister an output, or look for one. Create an enum which represent
    each output instance.
    Signed-off-by: default avatarArchit Taneja <archit@ti.com>
    484dc404
output.c 1.21 KB