1. 05 11月, 2020 1 次提交
  2. 03 7月, 2020 1 次提交
    • D
      drm/atomic-helper: reset vblank on crtc reset · 51f644b4
      Daniel Vetter 提交于
      Only when vblanks are supported ofc.
      
      Some drivers do this already, but most unfortunately missed it. This
      opens up bugs after driver load, before the crtc is enabled for the
      first time. syzbot spotted this when loading vkms as a secondary
      output. Given how many drivers are buggy it's best to solve this once
      and for all in shared helper code.
      
      Aside from moving the few existing calls to drm_crtc_vblank_reset into
      helpers (i915 doesn't use helpers, so keeps its own) I think the
      regression risk is minimal: atomic helpers already rely on drivers
      calling drm_crtc_vblank_on/off correctly in their hooks when they
      support vblanks. And driver that's failing to handle vblanks after
      this is missing those calls already, and vblanks could only work by
      accident when enabling a CRTC for the first time right after boot.
      
      Big thanks to Tetsuo for helping track down what's going wrong here.
      
      There's only a few drivers which already had the necessary call and
      needed some updating:
      - komeda, atmel and tidss also needed to be changed to call
        __drm_atomic_helper_crtc_reset() intead of open coding it
      - tegra and msm even had it in the same place already, just code
        motion, and malidp already uses __drm_atomic_helper_crtc_reset().
      - Laurent noticed that rcar-du and omap open-code their crtc reset and
        hence would actually be broken by this patch now. So fix them up by
        reusing the helpers, which brings the drm_crtc_vblank_reset() back.
      
      Only call left is in i915, which doesn't use drm_mode_config_reset,
      but has its own fastboot infrastructure. So that's the only case where
      we actually want this in the driver still.
      
      I've also reviewed all other drivers which set up vblank support with
      drm_vblank_init. After the previous patch fixing mxsfb all atomic
      drivers do call drm_crtc_vblank_on/off as they should, the remaining
      drivers are either legacy kms or legacy dri1 drivers, so not affected
      by this change to atomic helpers.
      
      v2: Use the drm_dev_has_vblank() helper.
      
      v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
      instead of drm_crtc_vblank_reset. Adjust them too.
      
      v4: Laurent noticed that rcar-du and omap open-code their crtc reset
      and hence would actually be broken by this patch now. So fix them up
      by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
      
      v5: also mention rcar-du and ompadrm in the proper commit message
      above (Laurent).
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: NMaxime Ripard <mripard@kernel.org>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cbReported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reported-by: syzbot+0871b14ca2e2fb64f6e3@syzkaller.appspotmail.com
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Mihail Atanassov <mihail.atanassov@arm.com>
      Cc: Brian Starkey <brian.starkey@arm.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Boris Brezillon <bbrezillon@kernel.org>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <mripard@kernel.org>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Jonathan Hunter <jonathanh@nvidia.com>
      Cc: Jyri Sarha <jsarha@ti.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Brian Masney <masneyb@onstation.org>
      Cc: Emil Velikov <emil.velikov@collabora.com>
      Cc: zhengbin <zhengbin13@huawei.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-tegra@vger.kernel.org
      Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-renesas-soc@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-1-daniel.vetter@ffwll.ch
      51f644b4
  3. 20 5月, 2020 1 次提交
  4. 19 5月, 2020 1 次提交
  5. 13 2月, 2020 2 次提交
  6. 11 2月, 2020 1 次提交
  7. 11 10月, 2019 1 次提交
  8. 04 9月, 2019 1 次提交
    • S
      drm/msm: drop use of drmP.h · feea39a8
      Sam Ravnborg 提交于
      Drop the deprecated drmP.h header file, and trim msm_drv.h
      to the relevant include files.
      
      This resulted in a suprisingly many edits as many files relied
      on headers included via msm_drv.h.
      But msm_drv.h is not supposed to carry include files it do not need, so
      the individual files have to include what extra they needs.
      
      v2:
      - Rebased on top of https://gitlab.freedesktop.org/drm/msm.git msm-next
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Jordan Crouse <jcrouse@codeaurora.org>
      Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
      Cc: Bruce Wang <bzwang@chromium.org>
      Cc: Shayenne Moura <shayenneluzmoura@gmail.com>
      Cc: Mamta Shukla <mamtashukla555@gmail.com>
      Cc: Jonathan Marek <jonathan@marek.ca>
      Cc: Carsten Behling <carsten.behling@googlemail.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
      Cc: Sibi Sankar <sibis@codeaurora.org>
      Cc: Todor Tomov <todor.tomov@linaro.org>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190804065551.GA5211@ravnborg.org
      feea39a8
  9. 01 8月, 2019 1 次提交
  10. 19 6月, 2019 1 次提交
  11. 20 5月, 2019 2 次提交
  12. 25 4月, 2019 1 次提交
  13. 24 1月, 2019 1 次提交
  14. 11 1月, 2019 1 次提交
  15. 12 12月, 2018 3 次提交
    • J
      drm/msm: Count how many times iova memory is pinned · 7ad0e8cf
      Jordan Crouse 提交于
      Add a reference count to track how many times a particular
      chunk of iova memory is pinned (mapped) in the iomu and
      add msm_gem_unpin_iova to give up references.
      
      It is important to note that msm_gem_unpin_iova replaces
      msm_gem_put_iova because the new implicit behavior
      that an assigned iova in a given vma is now valid for the
      life of the buffer and what we are really focusing on is
      the use of that iova.
      
      For now the unmappings are lazy; once the reference counts
      go to zero they *COULD* be unmapped dynamically but that
      will require an outside force such as a shrinker or
      mm_notifiers.  For now, we're just focusing on getting
      the counting right and setting ourselves up to be ready
      for the future.
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      7ad0e8cf
    • J
      drm/msm: Add msm_gem_get_and_pin_iova() · 9fe041f6
      Jordan Crouse 提交于
      Add a new function to get and pin the iova memory in one
      step (basically renaming the old msm_gem_get_iova function)
      and switch msm_gem_get_iova() to only allocate an iova but
      not map it in the IOMMU. This is only currently used by
      msm_ioctl_gem_info() since all other users of of the iova
      expect that the memory be immediately available.
      Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      9fe041f6
    • M
      drm: msm: Use DRM_DEV_* instead of dev_* · 6a41da17
      Mamta Shukla 提交于
      Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
      drm-formatted specific log messages so that it will be easy to
      differentiate in case of multiple instances of driver.
      Signed-off-by: NMamta Shukla <mamtashukla555@gmail.com>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      6a41da17
  16. 25 7月, 2018 1 次提交
  17. 12 6月, 2018 1 次提交
  18. 05 6月, 2018 1 次提交
  19. 04 6月, 2018 1 次提交
  20. 19 4月, 2018 1 次提交
  21. 19 3月, 2018 3 次提交
    • R
      drm/msm/mdp5: print a bit more of the atomic state · 1af81790
      Rob Clark 提交于
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      1af81790
    • R
      drm/msm/mdp5: rework CTL START signal handling · f9cb8d8d
      Rob Clark 提交于
      For DSI cmd-mode and writeback, we need to write the CTL's START
      register to kick things off, but we only want to do that once both
      the encoder and the crtc have a chance to write their corresponding
      flush bits.  The difficulty is that when there is a full modeset
      (ie. encoder state has changed) we want to defer the start until
      encoder->enable().  But if only plane's have changed, we want to do
      this from crtc->commit().
      
      The start_mask was a previous attempt to handle this, but it didn't
      really do the right thing since atomic conversion.
      
      Instead track in the crtc state that the start should be deferred,
      set to try from encoder's (or in future writeback's) atomic_check().
      This way the state is part of the atomic state, and rollback can
      work properly if an atomic test fails.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      f9cb8d8d
    • R
      drm/msm: rename mdp->disp · 14be3200
      Rob Clark 提交于
      Since new display controller is called "dpu" instead of "mdp".  Lets
      make the name of the toplevel directory for the display controllers a
      bit more generic.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      14be3200
  22. 20 2月, 2018 1 次提交
  23. 29 10月, 2017 4 次提交
  24. 28 10月, 2017 1 次提交
  25. 13 10月, 2017 1 次提交
  26. 23 8月, 2017 1 次提交
  27. 08 8月, 2017 1 次提交
  28. 02 8月, 2017 4 次提交
    • 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
    • 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