1. 02 8月, 2021 1 次提交
  2. 27 7月, 2021 2 次提交
    • D
      drm/plane: Move drm_plane_enable_fb_damage_clips into core · ba6cd766
      Daniel Vetter 提交于
      We're trying to have a fairly strict split between core functionality
      that defines the uapi, including the docs, and the helper functions to
      implement it.
      
      Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
      drm_plane from drm_damage_helper.c to fix this.
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.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>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-3-daniel.vetter@ffwll.ch
      ba6cd766
    • D
      drm/plane: check that fb_damage is set up when used · c7fcbf25
      Daniel Vetter 提交于
      There's two stages of manual upload/invalidate displays:
      - just handling dirtyfb and uploading the entire fb all the time
      - looking at damage clips
      
      In the latter case we support it through fbdev emulation (with
      fb_defio), atomic property, and with the dirtfy clip rects.
      
      Make sure at least the atomic property is set up as the main official
      interface for this. Ideally we'd also check that
      drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up,
      but that's quite a bit harder to do. Ideas very much welcome.
      
      From a cursor audit drivers seem to be getting this right mostly, but
      better to make sure. At least no one is bypassing the accessor
      function.
      
      v2:
      - use drm_warn_once with a meaningful warning string (José)
      - don't splat in the atomic check code for everyone (intel-gfx-ci)
      
      Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1)
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.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>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210723083457.696939-2-daniel.vetter@ffwll.ch
      c7fcbf25
  3. 12 5月, 2021 1 次提交
  4. 17 2月, 2021 1 次提交
  5. 24 1月, 2021 1 次提交
  6. 12 1月, 2021 1 次提交
  7. 04 1月, 2021 1 次提交
  8. 18 12月, 2020 1 次提交
  9. 17 12月, 2020 2 次提交
  10. 15 12月, 2020 2 次提交
  11. 08 12月, 2020 1 次提交
  12. 21 10月, 2020 1 次提交
  13. 18 8月, 2020 1 次提交
  14. 02 7月, 2020 1 次提交
  15. 14 5月, 2020 1 次提交
  16. 24 4月, 2019 1 次提交
  17. 11 1月, 2019 1 次提交
  18. 29 11月, 2018 1 次提交
  19. 07 11月, 2018 1 次提交
  20. 15 9月, 2018 1 次提交
    • C
      drm: Differentiate the lack of an interface from invalid parameter · 69fdf420
      Chris Wilson 提交于
      If the ioctl is not supported on a particular piece of HW/driver
      combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily
      distinguished from both the lack of the ioctl and from a regular invalid
      parameter.
      
      v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
      ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
      drm_core_check_feature(). Update everybody to report ENOTSUPP.
      
      v3: ENOTSUPP is an internal errno! It's value (524) does not correspond
      to a POSIX errno, the one we want is ENOTSUP. However,
      uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says
      
      	"ENOTSUP and EOPNOTSUPP have the same value on Linux,
      	but according to POSIX.1 these error values should be
      	distinct."
      
      so use EOPNOTSUPP as its equivalent.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v2
      Link: https://patchwork.freedesktop.org/patch/msgid/20180913192050.24812-1-chris@chris-wilson.co.uk
      69fdf420
  21. 11 9月, 2018 1 次提交
  22. 09 9月, 2018 1 次提交
  23. 13 7月, 2018 2 次提交
  24. 18 6月, 2018 1 次提交
  25. 12 6月, 2018 1 次提交
  26. 01 6月, 2018 1 次提交
  27. 30 3月, 2018 4 次提交
  28. 16 3月, 2018 1 次提交
  29. 26 2月, 2018 1 次提交
  30. 16 2月, 2018 1 次提交
  31. 30 1月, 2018 1 次提交
  32. 20 12月, 2017 1 次提交
  33. 23 11月, 2017 1 次提交