1. 19 12月, 2017 1 次提交
    • P
      drm/omap: Filter displays mode based on bandwidth limit · a7631c4b
      Peter Ujfalusi 提交于
      If we have memory bandwidth limit configured, reject the modes which would
      require more bandwidth than the limit if it is used with one full
      resolution plane (most common use case).
      
      This filtering is not providing full protection as it is possible that
      application would pick smaller crtc resolution with high resolution planes
      and down scaling, or can enable more smaller planes where the sum of their
      bandwidth need would be higher than the limit.
      
      This patch only allows us to filter out modes which would need more
      bandwidth if they were used with one full screen plane.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a7631c4b
  2. 08 12月, 2017 1 次提交
  3. 23 8月, 2017 1 次提交
    • T
      drm/omap: work-around for omap3 display enable · fc5cc967
      Tomi Valkeinen 提交于
      Seems that on omap3 enabling a crtc without any planes causes a sync
      lost flood. This only happens on the first enable, and after that it
      works. This looks like an HW issue and it's unclear why this is
      happening or how to fix it.
      
      This started happening after 897145d0
      ("drm/omapdrm: Move commit_modeset_enables() before commit_planes()")
      which, as a work-around, changed omapdrm first to do the modeset enable,
      and plane set only after that. This WA should be fine on all DSS
      versions, but apparently OMAP3 DSS is an exception.
      
      This patch reverts that work-around for OMAP3 DSS.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      fc5cc967
  4. 16 8月, 2017 3 次提交
  5. 15 8月, 2017 1 次提交
  6. 01 8月, 2017 1 次提交
  7. 29 7月, 2017 1 次提交
  8. 02 6月, 2017 6 次提交
  9. 22 5月, 2017 1 次提交
  10. 03 4月, 2017 8 次提交
  11. 16 2月, 2017 2 次提交
  12. 09 2月, 2017 1 次提交
  13. 08 2月, 2017 1 次提交
  14. 27 1月, 2017 1 次提交
  15. 09 1月, 2017 1 次提交
  16. 19 12月, 2016 3 次提交
  17. 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
  18. 22 10月, 2016 2 次提交
  19. 17 10月, 2016 1 次提交
  20. 29 8月, 2016 1 次提交
  21. 09 8月, 2016 1 次提交
  22. 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