25 Apr, 2014

1 commit

  • The hw cursor is relatively adept at triggering underflows, which
    manifest as a "blue flash" (since blue is configured as the underflow
    color). Juggle a few things around to tighten up the timing for setting
    cursor registers in DONE irq.

    And most importantly, don't ever disable the hw cursor. Instead flip it
    to a blank/empty cursor. This seems far more reliable, as even simply
    clearing the cursor-enable bit (with no other updates in previous/
    following frames) can in some cases cause underflow.

    v1: original
    v2: add missing locking spotted by Micah

    Cc: Micah Richert
    Signed-off-by: Rob Clark

    Rob Clark
     

04 Apr, 2014

1 commit


02 Apr, 2014

2 commits

  • Now that CRTC's have a primary plane, there's no need to track the
    framebuffer in the CRTC. Replace all references to the CRTC fb with the
    primary plane's fb.

    This patch was generated by the Coccinelle semantic patching tool using
    the following rules:

    @@ struct drm_crtc C; @@
    - (C).fb
    + C.primary->fb

    @@ struct drm_crtc *C; @@
    - (C)->fb
    + C->primary->fb

    v3: Generate patch via coccinelle. Actual removal of crtc->fb has been
    moved to a subsequent patch.

    v2: Fixup several lingering crtc->fb instances that were missed in the
    first patch iteration. [Rob Clark]

    Signed-off-by: Matt Roper
    Reviewed-by: Rob Clark

    Matt Roper
     
  • Use drm_universal_plane_init() and drm_crtc_init_with_planes() rather
    than the legacy drm_plane_init() / drm_crtc_init(). This will ensure
    that the proper primary plane is registered with the DRM (and eventually
    exposed to userspace in future patches).

    Cc: Rob Clark
    Signed-off-by: Matt Roper
    Signed-off-by: Rob Clark

    Matt Roper
     

31 Mar, 2014

1 commit


06 Feb, 2014

4 commits

  • It seems we need to update all cursor registers from vblank. This
    appears to be the cause of intermittent underflows when enabling/
    disabling cursor.

    Signed-off-by: Rob Clark

    Rob Clark
     
  • Backport a few fixes found in the course of getting mdp5 working.
    There is a window of time after pageflip is requested, before we
    start scanning out the new fb (ie. while we are waiting for gpu).
    During that time we need to continue holding a reference to the
    still-current scanout fb, to avoid the backing gem bo's from being
    destroyed.

    Possibly a common mdp_crtc parent class could be useful to share
    some of this logic between mdp4_crtc and mdp5_crtc. OTOH, this
    all can be removed from the driver once atomic is in place, as
    plane/crtc updates get deferred until all fb's are ready before
    calling in to .page_flip(), etc.

    Signed-off-by: Rob Clark

    Rob Clark
     
  • Signed-off-by: Rob Clark

    Rob Clark
     
  • Small typo I noticed in the mdp4_plane code.. no consequence because
    PIPE_SRC_XY and PIPE_DST_XY have same register layout.

    Signed-off-by: Rob Clark

    Rob Clark
     

10 Jan, 2014

7 commits

  • Add support for the new MDP5 display controller block. The mapping
    between parts of the display controller and KMS is:

    plane -> PIPE{RGBn,VIGn} \
    crtc -> LM (layer mixer) |-> MDP "device"
    encoder -> INTF /
    connector -> HDMI/DSI/eDP/etc --> other device(s)

    Unlike MDP4, it appears we can get by with a single encoder, rather
    than needing a different implementation for DTV, DSI, etc. (Ie. the
    register interface is same, just different bases.)

    Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
    routed through MDP.

    And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
    which blocks need to be allocated to the active pipes based on fetch
    stride.

    Signed-off-by: Rob Clark

    Rob Clark
     
  • The HDMI block is basically the same between older SoC's with mdp4
    display controller, and newer ones with mdp5.

    So mostly this consists of better abstracting out the different sets of
    regulators, clks, etc. In particular, for regulators and clks we can
    split it up by what is needed for hot plug detect to work, and what is
    needed to light up the display.

    Also, 8x74 has a new phy.. a very simple one, but split out into a
    different mmio space. And with mdp5, the irq is shared with mdp, so we
    don't directly register our own irq handler.

    Signed-off-by: Rob Clark

    Rob Clark
     
  • We'll want basically the same thing for mdp5, so refactor it out so it
    can be shared.

    Signed-off-by: Rob Clark

    Rob Clark
     
  • Signed-off-by: Rob Clark

    Rob Clark
     
  • This can be shared between mdp4 and mdp5. Both use the same set of
    parameters to describe the format to the hw.

    Signed-off-by: Rob Clark

    Rob Clark
     
  • resync to latest envytools db, add mdp5 registers

    Signed-off-by: Rob Clark

    Rob Clark
     
  • There are some little bits and pieces that mdp4 and mdp5 can share, so
    move things around so that we can have both in a common parent
    directory.

    Signed-off-by: Rob Clark

    Rob Clark