1. 09 Sep, 2017 3 commits
    • Chen-Yu Tsai's avatar
      drm/sun4i: tcon: get TCON ID and matching engine with remote endpoint ID · e8d5bbf7
      Chen-Yu Tsai authored
      The device tree binding for sun4i-drm says:
      
          For all connections between components up to the TCONs in the display
          pipeline, when there are multiple components of the same type at the
          same depth, the local endpoint ID must be the same as the remote
          component's index. For example, if the remote endpoint is Frontend 1,
          then the local endpoint ID must be 1.
      
      We should be able to get the TCON's ID directly from any of the remote
      endpoints from its input port. With the ID, we can then go through the
      list of registered engines and find a matching one by ID.
      
      However the A31 device tree is incorrect. We assumed that there were no
      cross pipeline connections between the backends and TCONs. As a result,
      in all the endpoints between the backends and TCONs of the second
      display pipeline, the endpoint IDs were incorrectly set to 0, when in
      fact they should've been set to 1.
      
      To maintain compatibility with this incorrect device tree, we first
      check if the TCON's input port has 1 or many endpoints. If there are
      more than 1, then it is likely a fixed version, and we can proceed
      with the new method. If there is only 1 endpoint, then it is possibly
      an incorrect version, or it could be the SoC only has one pipeline.
      In either case we fall back to using the old method of traversing
      the input connections to find a matching engine, and then get its
      ID.
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170908075016.18657-5-wens@csie.org
      e8d5bbf7
    • Chen-Yu Tsai's avatar
      drm/sun4i: tcon: Check for multiple paths between TCONs and backends · 1469619d
      Chen-Yu Tsai authored
      The patch b317fa3b ("drm/sun4i: tcon: Find matching display backend
      by device node matching") assumed a one-to-one mapping between TCONs
      and backends. This turned out wrong, as we found muxing controls in the
      TCON of the A31, and undocumented usage of the backend output selector
      of the A20.
      
      Make sun4i_tcon_find_engine() bail out if the current node has multiple
      input connections.
      
      Fixes: b317fa3b ("drm/sun4i: tcon: Find matching display backend
      		      by device node matching")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170908075016.18657-4-wens@csie.org
      1469619d
    • Chen-Yu Tsai's avatar
      drm/sun4i: add components in breadth first traversal order · da82b878
      Chen-Yu Tsai authored
      The encoder drivers use drm_of_find_possible_crtcs to get upstream
      crtcs from the device tree using of_graph. For the results to be
      correct, encoders must be probed/bound after _all_ crtcs have been
      created. The existing code uses a depth first recursive traversal
      of the of_graph, which means the encoders downstream of the TCON
      get add right after the first TCON. The second TCON or CRTC will
      never be properly associated with encoders connected to it.
      
      Other platforms, such as Rockchip, deal with this by probing all
      CRTCs first, then all subsequent components. This is easy to do
      since the CRTCs correspond to just one device node, and are the
      first nodes in the pipeline.
      
      However with Allwinner SoCs, the function of the CRTC is split
      between the display backend (DE 1.0) or mixer (DE 2.0), which does
      scan-out and compositing, and the TCON, which generates the display
      timing signals. Further complicating the process, there may be a
      Dynamic Range Controller between the backend and the TCON. Also, the
      backend is preceded by the frontend, with a Display Enhancement Unit
      possibly in between.
      
      In a dual display pipeline setup, both frontends can feed either
      backend, and both backends can feed either TCON. We want all
      components of the same type to be added before the next type in the
      pipeline. Fortunately, the pipelines are perfectly symmetric, i.e.
      components of the same type are at the same depth when counted from
      the frontend. The only exception is the third pipeline in the A80
      SoC, which we do not support anyway.
      
      Hence we can use a breadth first search traversal order to add
      components. We do not need to check for duplicates. The component
      matching system handles this for us.
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170908075016.18657-3-wens@csie.org
      da82b878
  2. 08 Sep, 2017 15 commits
  3. 06 Sep, 2017 1 commit
  4. 05 Sep, 2017 3 commits
  5. 04 Sep, 2017 3 commits
  6. 02 Sep, 2017 6 commits
  7. 01 Sep, 2017 5 commits
  8. 31 Aug, 2017 1 commit
  9. 30 Aug, 2017 1 commit
  10. 27 Aug, 2017 2 commits