Home
last modified time | relevance | path

Searched hist:c103d1cfb3543f61ec44d4d15a84c888db84794d (Results 1 – 3 of 3) sorted by relevance

/linux/include/drm/
H A Ddrm_plane_helper.hc103d1cfb3543f61ec44d4d15a84c888db84794d Wed Apr 02 00:22:35 CEST 2014 Matt Roper <matthew.d.roper@intel.com> drm: Add primary plane helpers (v3)

When we expose non-overlay planes to userspace, they will become
accessible via standard userspace plane API's. We should be able to
handle the standard plane operations against primary planes in a generic
way via the modeset handler.

Drivers that can program primary planes more efficiently, that want to
use their own primary plane structure to track additional information,
or that don't have the limitations assumed by the helpers are free to
provide their own implementation of some or all of these handlers.

v3: Tweak kerneldoc formatting slightly to avoid ugliness
v2:
- Move plane helpers to a new file (drm_plane_helper.c)
- Tighten checks on update handler (check for scaling, CRTC coverage,
subpixel positioning)
- Pass proper panning parameters to modeset interface
- Disallow disabling primary plane (and thus CRTC) if other planes are
still active on the CRTC.
- Use a minimal format list that should work on all hardware/drivers.
Drivers may call this function with a more accurate plane list to
enable additional formats they can support.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
/linux/drivers/gpu/drm/
H A Ddrm_plane_helper.cc103d1cfb3543f61ec44d4d15a84c888db84794d Wed Apr 02 00:22:35 CEST 2014 Matt Roper <matthew.d.roper@intel.com> drm: Add primary plane helpers (v3)

When we expose non-overlay planes to userspace, they will become
accessible via standard userspace plane API's. We should be able to
handle the standard plane operations against primary planes in a generic
way via the modeset handler.

Drivers that can program primary planes more efficiently, that want to
use their own primary plane structure to track additional information,
or that don't have the limitations assumed by the helpers are free to
provide their own implementation of some or all of these handlers.

v3: Tweak kerneldoc formatting slightly to avoid ugliness
v2:
- Move plane helpers to a new file (drm_plane_helper.c)
- Tighten checks on update handler (check for scaling, CRTC coverage,
subpixel positioning)
- Pass proper panning parameters to modeset interface
- Disallow disabling primary plane (and thus CRTC) if other planes are
still active on the CRTC.
- Use a minimal format list that should work on all hardware/drivers.
Drivers may call this function with a more accurate plane list to
enable additional formats they can support.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
H A DMakefilediff c103d1cfb3543f61ec44d4d15a84c888db84794d Wed Apr 02 00:22:35 CEST 2014 Matt Roper <matthew.d.roper@intel.com> drm: Add primary plane helpers (v3)

When we expose non-overlay planes to userspace, they will become
accessible via standard userspace plane API's. We should be able to
handle the standard plane operations against primary planes in a generic
way via the modeset handler.

Drivers that can program primary planes more efficiently, that want to
use their own primary plane structure to track additional information,
or that don't have the limitations assumed by the helpers are free to
provide their own implementation of some or all of these handlers.

v3: Tweak kerneldoc formatting slightly to avoid ugliness
v2:
- Move plane helpers to a new file (drm_plane_helper.c)
- Tighten checks on update handler (check for scaling, CRTC coverage,
subpixel positioning)
- Pass proper panning parameters to modeset interface
- Disallow disabling primary plane (and thus CRTC) if other planes are
still active on the CRTC.
- Use a minimal format list that should work on all hardware/drivers.
Drivers may call this function with a more accurate plane list to
enable additional formats they can support.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>