1. 08 12月, 2016 1 次提交
    • T
      drm/omap: fix primary-plane's possible_crtcs · e43f2c33
      Tomi Valkeinen 提交于
      We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
      which is fine as the HW planes can be used fro all crtcs. However, when
      we're doing that, we are still incrementing 'num_crtcs', and we'll end
      up with bad possible_crtcs, preventing the use of the primary planes.
      
      This patch passes a possible_crtcs mask to plane init function so that
      we get correct possible_crtc.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      e43f2c33
  2. 22 10月, 2016 2 次提交
  3. 17 10月, 2016 1 次提交
  4. 29 8月, 2016 1 次提交
  5. 09 8月, 2016 1 次提交
  6. 22 6月, 2016 1 次提交
    • D
      drm: Lobotomize set_busid nonsense for !pci drivers · a3257256
      Daniel Vetter 提交于
      We already have a fallback in place to fill out the unique from
      dev->unique, which is set to something reasonable in drm_dev_alloc.
      
      Which means we only need to have a special set_busid for pci devices,
      to be able to care the backwards compat code for drm 1.1 around, which
      libdrm still needs.
      
      While developing and testing this patch things blew up in really
      interesting ways, and the code is rather confusing in naming things
      between the kernel code, ioctl #defines and libdrm. For the next brave
      dragon slayer, document all this madness properly in the userspace
      interface section of gpu.tmpl.
      
      v2: Make drm_dev_set_unique static and update kerneldoc.
      
      v3: Entire rewrite, plus document what's going on for posterity in the
      gpu docbook uapi section.
      
      v4: Drop accidental amdgpu hunk (Emil).
      
      v5: Drop accidental omapdrm vblank counter change (Emil).
      
      v6: Rebase on top of the sphinx conversion.
      
      Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
      Cc: Emil Velikov <emil.l.velikov@gmail.com>
      Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (virt_gpu)
      Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      a3257256
  7. 10 6月, 2016 1 次提交
  8. 06 6月, 2016 1 次提交
  9. 02 6月, 2016 1 次提交
  10. 17 5月, 2016 1 次提交
  11. 02 5月, 2016 1 次提交
  12. 03 3月, 2016 2 次提交
    • T
      drm/omap: remove use of omapdss_find_mgr_from_display() · 179df15f
      Tomi Valkeinen 提交于
      In order to remove uses of 'struct omap_overlay_manager' we need to get
      rid of using omapdss_find_mgr_from_display() when initializing omapdrm.
      
      Instead of using omapdss_find_mgr_from_display() and mgr->id to find the
      dispc channel used for the given display, we can instead use
      omapdss_find_output_from_display(), and get the output->dispc_channel
      from there.
      
      We can also remove omapdss_find_mgr_from_display() as it's no longer
      used.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      179df15f
    • T
      drm/omap: fix suspend/resume handling · 92bf0f9e
      Tomi Valkeinen 提交于
      For legacy reasons omapdss handles system suspend/resume via PM notifier
      callback, where the driver disables/resumes all the outputs.
      
      This doesn't work well with omapdrm. What happens on suspend is that the
      omapdss disables the displays while omapdrm is still happily continuing
      its work, possibly waiting for an vsync irq, which will never come if
      the display output is disabled, leading to timeouts and errors sent to
      userspace.
      
      This patch moves the suspend/resume handling to omapdrm, and the
      suspend/resume is now done safely inside modeset lock.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      92bf0f9e
  13. 08 2月, 2016 1 次提交
  14. 31 12月, 2015 4 次提交
  15. 16 10月, 2015 1 次提交
  16. 07 10月, 2015 1 次提交
  17. 25 9月, 2015 1 次提交
  18. 08 9月, 2015 1 次提交
    • D
      drm/atomic-helper: Add option to update planes only on active crtc · aef9dbb8
      Daniel Vetter 提交于
      With drivers supporting runtime pm it's generally not a good idea to
      touch the hardware when it's off. Add an option to the commit_planes
      helper to support this case.
      
      Note that the helpers already add all planes on a crtc when a modeset
      happens, hence plane updates will not be lost if drivers set this to
      true.
      
      v2: Check for NULL state->crtc before chasing the pointer. Also check
      both old and new crtc if there's a switch. Finally just outright
      disallow switching crtcs for a plane if the plane is in active use, on
      most hardware that doesn't make sense.
      
      v3: Since commit_planes(active_only = true) is for enabling things
      only after all the crtc are on we should only look at the new crtc to
      decide whether to call the plane hooks - if the current CRTC isn't on
      then skip. If the old crtc (when moving a plane) went down then the
      plane should have been disabled as part of the pipe shutdown work
      already. For which there's currently no helper really unfortunately.
      Also move the check for wether a plane gets a new CRTC assigned while
      still in active use out of this patch.
      
      v4: Rebase over exynos changes.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Tested-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      aef9dbb8
  19. 13 6月, 2015 12 次提交
  20. 24 3月, 2015 5 次提交
    • G
      drm/omap: add hibernation callbacks · 8450c8d0
      Grygorii Strashko 提交于
      Setting a dev_pm_ops suspend/resume pair but not a set of hibernation
      functions means those pm functions will not be called upon hibernation.
      
      Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the
      suspend and hibernation handlers and move
      omap_drm_suspend/omap_drm_resume under CONFIG_PM_SLEEP to avoid build
      warnings.
      Signed-off-by: NGrygorii Strashko <Grygorii.Strashko@linaro.org>
      [tomi.valkeinen@ti.com: fix conflict, clean up description]
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8450c8d0
    • T
      drm/omap: fix race condition with dev->obj_list · 76c4055f
      Tomi Valkeinen 提交于
      omap_gem_objects are added to dev->obj_list in omap_gem_new, and removed
      in omap_gem_free_object. Unfortunately there's no locking for
      dev->obj_list, which eventually leads to a crash:
      
      WARNING: CPU: 1 PID: 1123 at lib/list_debug.c:59 __list_del_entry+0xa4/0xe0()
      list_del corruption. prev->next should be e9281344, but was ea722b84
      
      Add a spinlock to protect dev->obj_list.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      76c4055f
    • T
      drm/omap: stop connector polling during suspend · ccd7b5ed
      Tomi Valkeinen 提交于
      When not using proper hotplug detection, DRM polls periodically the
      connectors to find out if a cable is connected. This polling can happen
      at any time, even very late in the suspend process.
      
      This causes a problem with omapdrm, when the poll happens during the
      suspend process after GPIOs have been disabled, leading to a crash in
      gpio_get().
      
      This patch fixes the issue by adding suspend and resume hooks to
      omapdrm, in which we disable and enable, respectively, the polling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ccd7b5ed
    • T
      drm/omap: remove dummy PM functions · f5a1d317
      Tomi Valkeinen 提交于
      omapdrm has dummy functions for platform_device's
      suspend/resume/shutdown. The functions don't do anything, and those
      platform device functions are deprecated, so remove them from omapdrm.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f5a1d317
    • T
      drm/omap: fix operation without fbdev · c7c1aecd
      Tomi Valkeinen 提交于
      omapdrm should work fine even if fbdev is missing. The current driver
      crashes in that case, though, as it is missing checks for the fbdev.
      
      Add the checks so that we don't free fbdev or restore fbdev mode when
      there's no fbdev.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c7c1aecd