1. 29 10月, 2017 5 次提交
  2. 28 10月, 2017 2 次提交
  3. 11 10月, 2017 1 次提交
  4. 23 8月, 2017 3 次提交
  5. 08 8月, 2017 2 次提交
  6. 02 8月, 2017 9 次提交
    • A
      drm/msm/mdp5: Set up runtime PM for MDSS · 774e39ee
      Archit Taneja 提交于
      MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
      other sub-blocks. W.r.t device heirarchy, it's the parent of all these
      devices. The power domain of this device is actually tied to the GDSC
      hw. When any sub-device enables its PD, MDSS's PD is also enabled.
      
      The suspend/resume ops enable the top level clocks that end at the MDSS
      boundary. For now, we're letting them all be optional, since the child
      devices anyway hold a ref to these clocks.
      
      Until now, we'd called a runtime_get() during probe, which ensured that
      the GDSC was always on. Now that we've set up runtime PM for the children
      devices, we can get rid of this hack.
      
      Note: that the MDSS device is the platform_device in msm_drv.c. The
      msm_runtime_suspend/resume ops call the funcs that enable/disable
      the top level MDSS clocks. This is different from MDP4, where the
      platform device created in msm_drv.c represents MDP4 itself. It would
      have been nicer to hide these differences by adding new kms funcs, but
      runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
      is called).
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      774e39ee
    • A
      drm/msm/mdp5: Write to SMP registers even if allocations don't change · 0f379b79
      Archit Taneja 提交于
      Requests for assigning/freeing SMP blocks by planes are collected during
      the atomic check phase, and represented by mdp5_smp_state's 'assigned'
      and 'released' members.
      
      Once the atomic state is committed, these members are reset to 0,
      indicating that the existing configuration satisfies all the planes.
      Future atomic commits will copy the old mdp5_smp_state, and the 'assigned'
      and 'released' members would be updated only if there was a change in
      the plane configurations.
      
      When we disable and re-enable display, we lose the values we wrote to the
      SMP registers, but the code doesn't program the registers because there
      isn't any change in mdp5_smp_state.
      
      Fix this by writing to the registers irrespective of whether there was
      a change in SMP state or not. We do this by keeping a cache of the
      register values, and write them every time we commit a state.
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      0f379b79
    • A
      drm/msm/mdp5: Don't use mode_set helper funcs for encoders and CRTCs · 710e7a44
      Archit Taneja 提交于
      We shouldn't use use mode_set/mode_set_nofb helpers when we use runtime
      PM. The registers configured in these funcs lose their state when we
      eventually enable the display pipeline.
      
      Do not implement these vfuncs in the helpers, and call them in the
      crtc_enable/encoder_enable paths instead.
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      710e7a44
    • A
      drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks · d68fe15b
      Archit Taneja 提交于
      mdp5_enable/disable calls are scattered all around in the MDP5 code.
      Use the pm_runtime_get/put calls here instead, and populate the
      runtime PM suspend/resume ops to manage the clocks.
      
      About the overall design: MDP5 is a child of the top level MDSS
      device. MDSS is also the parent to DSI, HDMI and other interfaces. When
      we enable MDP5's power domain, we end up enabling MDSS's PD too. It is
      only MDSS's PD that actually controlls the GDSC HW. Therefore, calling
      runtime_get/put on the MDP5 device is like just requesting a vote to
      enable/disable the GDSC.
      
      Functionally, replacing the clock enable/disable calls with the RPM API
      can result in the power domain (GDSC) state being toggled if no other
      child isn't powered on. This can result in the register context being lost.
      We make sure (in future commits) that code paths don't end up configuring
      registers and then later lose state, resulting in a bad HW state.
      
      For now, we've replaced each mdp5_enable/disable with runtime_get/put API.
      We could optimize things later by removing runtime_get/put calls which
      don't really need to be there. This could prevent unnecessary toggling of
      the power domain and clocks.
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      d68fe15b
    • A
      drm/msm/mdp5: Drop clock names with "_clk" suffix · d0538f50
      Archit Taneja 提交于
      We have upstream bindings (msm8916) that have the "_clk" suffix in the
      clock names. The downstream bindings also require it.
      
      We want to drop the "_clk" suffix and at the same time support existing
      bindings. Update the MDP5 code with the the msm_clk_get() helper to
      support both old and new clock names.
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      d0538f50
    • A
      drm/msm/mdp5: Fix typo in encoder_enable path · b0e77fd8
      Archit Taneja 提交于
      The mdp5_cmd_encoder_disable is accidentally called in the encoder enable
      path. We've not seen any problems since we haven't tested with command
      mode panels in a while. Fix the copy-paste error.
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      b0e77fd8
    • R
      drm/msm/mdp5: fix unclocked register access in _cursor_set() · af1f5f12
      Rob Clark 提交于
      Fixes an insta-reboot when screen-blanking kicks in, due to cursor
      updates without clocks enabled.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      af1f5f12
    • V
      drm/msm/mdp5: Fix compilation warnings · d490c9cd
      Viresh Kumar 提交于
      Following compilation warnings were observed for these files:
      
        CC [M]  drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup':
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: missing braces around initializer [-Wmissing-braces]
        enum mdp5_pipe stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE };
             ^
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: (near initialization for 'stage[0]') [-Wmissing-braces]
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: missing braces around initializer [-Wmissing-braces]
        enum mdp5_pipe r_stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE };
             ^
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: (near initialization for 'r_stage[0]') [-Wmissing-braces]
      
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_mode_set':
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: missing braces around initializer [-Wmissing-braces]
        struct phase_step step = { 0 };
               ^
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: (near initialization for 'step.x') [-Wmissing-braces]
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: missing braces around initializer [-Wmissing-braces]
        struct pixel_ext pe = { 0 };
               ^
      drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: (near initialization for 'pe.left') [-Wmissing-braces]
      
      This happens because in the first case we were initializing a two
      dimensional array with {0} and in the second case we were initializing a
      struct containing two arrays with {0}.
      
      Fix them by adding another pair of {}.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      d490c9cd
    • B
      drm: Plumb modifiers through plane init · e6fc3b68
      Ben Widawsky 提交于
      This is the plumbing for supporting fb modifiers on planes. Modifiers
      have already been introduced to some extent, but this series will extend
      this to allow querying modifiers per plane. Based on this, the client to
      enable optimal modifications for framebuffers.
      
      This patch simply allows the DRM drivers to initialize their list of
      supported modifiers upon initializing the plane.
      
      v2: A minor addition from Daniel
      
      v3:
      * Updated commit message
      * s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
      * Remove some excess newlines (Liviu)
      * Update comment for > 64 modifiers (Liviu)
      
      v4: Minor comment adjustments (Liviu)
      
      v5: Some new platforms added due to rebase
      
      v6: Add some missed plane inits (or maybe they're new - who knows at
      this point) (Daniel)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: Daniel Stone <daniels@collabora.com> (v2)
      Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      e6fc3b68
  7. 30 6月, 2017 2 次提交
  8. 16 6月, 2017 5 次提交
  9. 28 5月, 2017 3 次提交
    • T
      drm/msm: constify irq_domain_ops · c43dd227
      Tobias Klauser 提交于
      struct irq_domain_ops is not modified, so it can be made const.
      Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      c43dd227
    • R
      drm/msm/mdp5: release hwpipe(s) for unused planes · adcbae31
      Rob Clark 提交于
      Otherwise, if userspace doesn't re-use a given plane, it's hwpipe(s)
      could stay permanently assigned.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      adcbae31
    • R
      drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state() · 786813c3
      Rob Clark 提交于
      Somehow the helper was never retrofitted for mdp5.  Which meant when
      plane_state->fence was added, it could get copied into new state in
      mdp5_plane_duplicate_state().
      
      If an update to disable the plane (for example on rmfb) managed to sneak
      in after an nonblock update had swapped state, but before it was
      committed, we'd get a splat:
      
          WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 drm_atomic_helper_wait_for_fences+0xe0/0xf8
         Modules linked in:
      
         CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: G        W       4.11.0-rc8+ #1187
         Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
         Workqueue: events drm_mode_rmfb_work_fn
         task: ffffffc036560d00 task.stack: ffffffc036550000
         PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
         LR is at complete_commit.isra.1+0x44/0x1c0
         pc : [<ffffff80084f6040>] lr : [<ffffff800854176c>] pstate: 20000145
         sp : ffffffc036553b60
         x29: ffffffc036553b60 x28: ffffffc0264e6a00
         x27: ffffffc035659000 x26: 0000000000000000
         x25: ffffffc0240e8000 x24: 0000000000000038
         x23: 0000000000000000 x22: ffffff800858f200
         x21: ffffffc0240e8000 x20: ffffffc02f56a800
         x19: 0000000000000000 x18: 0000000000000000
         x17: 0000000000000000 x16: 0000000000000000
         x15: 0000000000000000 x14: ffffffc00a192700
         x13: 0000000000000004 x12: 0000000000000000
         x11: ffffff80089a1690 x10: 00000000000008f0
         x9 : ffffffc036553b20 x8 : ffffffc036561650
         x7 : ffffffc03fe6cb40 x6 : 0000000000000000
         x5 : 0000000000000001 x4 : 0000000000000002
         x3 : ffffffc035659000 x2 : ffffffc0240e8c80
         x1 : 0000000000000000 x0 : ffffffc02adbe588
      
         ---[ end trace 13aeec77c3fb55e2 ]---
         Call trace:
         Exception stack(0xffffffc036553990 to 0xffffffc036553ac0)
         3980:                                   0000000000000000 0000008000000000
         39a0: ffffffc036553b60 ffffff80084f6040 0000000000004ff0 0000000000000038
         39c0: ffffffc0365539d0 ffffff800857e098 ffffffc036553a00 ffffff800857e1b0
         39e0: ffffffc036553a10 ffffff800857c554 ffffffc0365e8400 ffffffc0365e8400
         3a00: ffffffc036553a20 ffffff8008103358 000000000001aad7 ffffff800851b72c
         3a20: ffffffc036553a50 ffffff80080e9228 ffffffc02adbe588 0000000000000000
         3a40: ffffffc0240e8c80 ffffffc035659000 0000000000000002 0000000000000001
         3a60: 0000000000000000 ffffffc03fe6cb40 ffffffc036561650 ffffffc036553b20
         3a80: 00000000000008f0 ffffff80089a1690 0000000000000000 0000000000000004
         3aa0: ffffffc00a192700 0000000000000000 0000000000000000 0000000000000000
         [<ffffff80084f6040>] drm_atomic_helper_wait_for_fences+0xe0/0xf8
         [<ffffff800854176c>] complete_commit.isra.1+0x44/0x1c0
         [<ffffff8008541c64>] msm_atomic_commit+0x32c/0x350
         [<ffffff8008516230>] drm_atomic_commit+0x50/0x60
         [<ffffff8008517548>] drm_atomic_remove_fb+0x158/0x250
         [<ffffff80085186d0>] drm_framebuffer_remove+0x50/0x158
         [<ffffff8008518818>] drm_mode_rmfb_work_fn+0x40/0x58
         [<ffffff80080d5668>] process_one_work+0x1d0/0x378
         [<ffffff80080d5a54>] worker_thread+0x244/0x488
         [<ffffff80080db7fc>] kthread+0xfc/0x128
         [<ffffff8008082ec0>] ret_from_fork+0x10/0x50
      
      Fixes: 96260142 ("drm/fence: add in-fences support")
      Cc: stable@vger.kernel.org
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reported-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      786813c3
  10. 22 5月, 2017 1 次提交
  11. 17 5月, 2017 1 次提交
  12. 10 5月, 2017 3 次提交
    • D
      drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos · 1bf6ad62
      Daniel Vetter 提交于
      If we restrict this helper to only kms drivers (which is the case) we
      can look up the correct mode easily ourselves. But it's a bit tricky:
      
      - All legacy drivers look at crtc->hwmode. But that is updated already
        at the beginning of the modeset helper, which means when we disable
        a pipe. Hence the final timestamps might be a bit off. But since
        this is an existing bug I'm not going to change it, but just try to
        be bug-for-bug compatible with the current code. This only applies
        to radeon&amdgpu.
      
      - i915 tries to get it perfect by updating crtc->hwmode when the pipe
        is off (i.e. vblank->enabled = false).
      
      - All other atomic drivers look at crtc->state->adjusted_mode. Those
        that look at state->requested_mode simply don't adjust their mode,
        so it's the same. That has two problems: Accessing crtc->state from
        interrupt handling code is unsafe, and it's updated before we shut
        down the pipe. For nonblocking modesets it's even worse.
      
      For atomic drivers try to implement what i915 does. To do that we add
      a new hwmode field to the vblank structure, and update it from
      drm_calc_timestamping_constants(). For atomic drivers that's called
      from the right spot by the helper library already, so all fine. But
      for safety let's enforce that.
      
      For legacy driver this function is only called at the end (oh the
      fun), which is broken, so again let's not bother and just stay
      bug-for-bug compatible.
      
      The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
      directly to implement ->get_vblank_timestamp in every driver, deleting
      a lot of code.
      
      v2: Completely new approach, trying to mimick the i915 solution.
      
      v3: Fixup kerneldoc.
      
      v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
      currently unconditionally call this. Recomputing the same stuff should
      be harmless.
      
      v5: Fix typos and move misplaced hunks to the right patches (Neil).
      
      v6: Undo hunk movement (kbuild).
      
      Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
      1bf6ad62
    • D
      drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp · 3fcdcb27
      Daniel Vetter 提交于
      It's overkill to have a flag parameter which is essentially used just
      as a boolean. This takes care of core + adjusting drivers.
      
      Adjusting the scanout position callback is a bit harder, since radeon
      also supplies it's own driver-private flags in there.
      
      v2: Fixup misplaced hunks (Neil).
      
      v3: kbuild says v1 was better ...
      
      Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch
      3fcdcb27
    • D
      drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool · d673c02c
      Daniel Vetter 提交于
      There's really no reason for anything more:
      - Calling this while the crtc vblank stuff isn't set up is a driver
        bug. Those places alrready DRM_ERROR.
      - Calling this when the crtc is off is either a driver bug (calling
        drm_crtc_handle_vblank at the wrong time) or a core bug (for
        anything else). Again, we DRM_ERROR.
      - EINVAL is checked at higher levels already, and if we'd use struct
        drm_crtc * instead of (dev, pipe) it would be real obvious that
        those are again core bugs.
      
      The only valid failure mode is crap hardware that couldn't sample a
      useful timestamp, to ask the core to just grab a not-so-accurate
      timestamp. Bool is perfectly fine for that.
      
      v2: Also fix up the one caller, I lost that in the shuffling (Jani).
      
      v3: Fixup commit message (Neil).
      
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch
      d673c02c
  13. 08 4月, 2017 3 次提交