1
0
Fork 0
alistair23-linux/drivers/gpu/drm/drm_plane_helper.c

250 lines
7.7 KiB
C
Raw Permalink Normal View History

/*
* Copyright (C) 2014 Intel Corporation
*
* DRM universal plane helper functions
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
#include <linux/list.h>
drm/atomic: Refcounting for plane_state->fb So my original plan was that the drm core refcounts framebuffers like with the legacy ioctls. But that doesn't work for a bunch of reasons: - State objects might live longer than until the next fb change happens for a plane. For example delayed cleanup work only happens _after_ the pageflip ioctl has completed. So this definitely doesn't work without the plane state holding its own references. - The other issue is transition from legacy to atomic implementations, where the driver works under a mix of both worlds. Which means legacy paths might not properly update the ->fb pointer under plane->state->fb. Which is a bit a problem when then someone comes around and _does_ try to clean it up when it's long gone. The second issue is just a bit a transition bug, since drivers should update plane->state->fb in all the paths that aren't converted yet. But a bit more robustness for the transition can't hurt - we pull similar tricks with cleaning up the old fb in the transitional helpers already. The pattern for drivers that transition is if (plane->state) drm_atomic_set_fb_for_plane(plane->state, plane->fb); inserted after the fb update has logically completed at the end of ->set_config (or ->set_base/mode_set if using the crtc helpers), ->page_flip, ->update_plane or any other entry point which updates plane->fb. v2: Update kerneldoc - copypasta fail. v3: Fix spelling in the commit message (Sean). Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-04 14:57:27 -07:00
#include <drm/drm_atomic.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_atomic_uapi.h>
drm/plane-helper: transitional atomic plane helpers Converting a driver to the atomic interface can be a daunting undertaking. One of the prerequisites is to have full universal planes support. To make that transition a bit easier this patch provides plane helpers which use the new atomic helper callbacks just only for the plane changes. This way the plane update functionality can be tested without being forced to convert everything at once. Of course a real atomic update capable driver will implement the all plane properties through the atomic interface, so these helpers are mostly transitional. But they can be used to enable proper universal plane support, especially once the crtc helpers have also been adapted. v2: Use ->atomic_duplicate_state if available. v3: Don't forget to call ->atomic_destroy_state if available. v4: Fixup kerneldoc, reported by Paulo. v5: Extract a common plane_commit helper and fix some bugs in the plane_state setup of the plane_disable implementation. v6: Fix issues with the cleanup of the old fb. Since transitional helpers can be mixed we need to assume that the old fb has been set up by a legacy path (e.g. set_config or page_flip when the primary plane is converted to use these functions already). Hence pass an additional old_fb parameter to plane_commit to do that cleanup work correctly. v7: - Fix spurious WARNING (crtc helpers really love to disable stuff harder) and fix array index bonghits. - Correctly handle the lack of plane->state object, necessary for transitional use. - Don't indicate failure if drm_vblank_get doesn't work - that's expected when the pipe is in dpms off mode. v8: Review from Sean: - s/fail/out/ to make the meaning of a label more clear. - spelling fix in the commit message. Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-29 07:33:05 -06:00
#include <drm/drm_crtc_helper.h>
#include <drm/drm_device.h>
#include <drm/drm_encoder.h>
#include <drm/drm_plane_helper.h>
#include <drm/drm_rect.h>
#define SUBPIXEL_MASK 0xffff
/**
* DOC: overview
*
* This helper library has two parts. The first part has support to implement
* primary plane support on top of the normal CRTC configuration interface.
* Since the legacy &drm_mode_config_funcs.set_config interface ties the primary
* plane together with the CRTC state this does not allow userspace to disable
* the primary plane itself. The default primary plane only expose XRBG8888 and
* ARGB8888 as valid pixel formats for the attached framebuffer.
*
* Drivers are highly recommended to implement proper support for primary
* planes, and newly merged drivers must not rely upon these transitional
* helpers.
*
* The second part also implements transitional helpers which allow drivers to
* gradually switch to the atomic helper infrastructure for plane updates. Once
* that switch is complete drivers shouldn't use these any longer, instead using
* the proper legacy implementations for update and disable plane hooks provided
* by the atomic helpers.
*
* Again drivers are strongly urged to switch to the new interfaces.
*
* The plane helpers share the function table structures with other helpers,
* specifically also the atomic helpers. See &struct drm_plane_helper_funcs for
* the details.
*/
/*
* Returns the connectors currently associated with a CRTC. This function
* should be called twice: once with a NULL connector list to retrieve
* the list size, and once with the properly allocated list to be filled in.
*/
static int get_connectors_for_crtc(struct drm_crtc *crtc,
struct drm_connector **connector_list,
int num_connectors)
{
struct drm_device *dev = crtc->dev;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
int count = 0;
drm: Split connection_mutex out of mode_config.mutex (v3) After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from connector->encoder and encoder->crtc and other modeset-relevant connector state (e.g. properties which control the panel fitter). The later is used by modeset operations. But they don't really care about the former since it's allowed to e.g. enable a disconnected VGA output or with a mode not in the probed list. Thus far this hasn't been a problem, but for the atomic modeset conversion Rob Clark needs to convert all modeset relevant locks into w/w locks. This is required because the order of acquisition is determined by how userspace supplies the atomic modeset data. This has run into troubles in the detect path since the i915 load detect code needs _both_ protections offered by the mode_config.mutex: It updates probe state and it needs to change the modeset configuration to enable the temporary load detect pipe. The big deal here is that for the probe/detect users of this lock a plain mutex fits best, but for atomic modesets we really want a w/w mutex. To fix this lets split out a new connection_mutex lock for the modeset relevant parts. For simplicity I've decided to only add one additional lock for all connector/encoder links and modeset configuration states. We have piles of different modeset objects in addition to those (like bridges or panels), so adding per-object locks would be much more effort. Also, we're guaranteed (at least for now) to do a full modeset if we need to acquire this lock. Which means that fine-grained locking is fairly irrelevant compared to the amount of time the full modeset will take. I've done a full audit, and there's just a few things that justify special focus: - Locking in drm_sysfs.c is almost completely absent. We should sprinkle mode_config.connection_mutex over this file a bit, but since it already lacks mode_config.mutex this patch wont make the situation any worse. This is material for a follow-up patch. - omap has a omap_framebuffer_flush function which walks the connector->encoder->crtc links and is called from many contexts. Some look like they don't acquire mode_config.mutex, so this is already racy. Again fixing this is material for a separate patch. - The radeon hot_plug function to retrain DP links looks at connector->dpms. Currently this happens without any locking, so is already racy. I think radeon_hotplug_work_func should gain mutex_lock/unlock calls for the mode_config.connection_mutex. - Same applies to i915's intel_dp_hot_plug. But again, this is already racy. - i915 load_detect code needs to acquire this lock. Which means the w/w dance due to Rob's work will be nicely contained to _just_ this function. I've added fixme comments everywhere where it looks suspicious but in the sysfs code. After a quick irc discussion with Dave Airlie it sounds like the lack of locking in there is due to sysfs cleanup fun at module unload. v1: original (only compile tested) v2: missing mutex_init(), etc (from Rob Clark) v3: i915 needs more care in the conversion: - Protect the edp pp logic with the connection_mutex. - Use connection_mutex in the backlight code due to get_pipe_from_connector. - Use drm_modeset_lock_all in suspend/resume paths. - Update lock checks in the overlay code. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-05-29 15:54:47 -06:00
/*
* Note: Once we change the plane hooks to more fine-grained locking we
* need to grab the connection_mutex here to be able to make these
* checks.
*/
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
drm: Split connection_mutex out of mode_config.mutex (v3) After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from connector->encoder and encoder->crtc and other modeset-relevant connector state (e.g. properties which control the panel fitter). The later is used by modeset operations. But they don't really care about the former since it's allowed to e.g. enable a disconnected VGA output or with a mode not in the probed list. Thus far this hasn't been a problem, but for the atomic modeset conversion Rob Clark needs to convert all modeset relevant locks into w/w locks. This is required because the order of acquisition is determined by how userspace supplies the atomic modeset data. This has run into troubles in the detect path since the i915 load detect code needs _both_ protections offered by the mode_config.mutex: It updates probe state and it needs to change the modeset configuration to enable the temporary load detect pipe. The big deal here is that for the probe/detect users of this lock a plain mutex fits best, but for atomic modesets we really want a w/w mutex. To fix this lets split out a new connection_mutex lock for the modeset relevant parts. For simplicity I've decided to only add one additional lock for all connector/encoder links and modeset configuration states. We have piles of different modeset objects in addition to those (like bridges or panels), so adding per-object locks would be much more effort. Also, we're guaranteed (at least for now) to do a full modeset if we need to acquire this lock. Which means that fine-grained locking is fairly irrelevant compared to the amount of time the full modeset will take. I've done a full audit, and there's just a few things that justify special focus: - Locking in drm_sysfs.c is almost completely absent. We should sprinkle mode_config.connection_mutex over this file a bit, but since it already lacks mode_config.mutex this patch wont make the situation any worse. This is material for a follow-up patch. - omap has a omap_framebuffer_flush function which walks the connector->encoder->crtc links and is called from many contexts. Some look like they don't acquire mode_config.mutex, so this is already racy. Again fixing this is material for a separate patch. - The radeon hot_plug function to retrain DP links looks at connector->dpms. Currently this happens without any locking, so is already racy. I think radeon_hotplug_work_func should gain mutex_lock/unlock calls for the mode_config.connection_mutex. - Same applies to i915's intel_dp_hot_plug. But again, this is already racy. - i915 load_detect code needs to acquire this lock. Which means the w/w dance due to Rob's work will be nicely contained to _just_ this function. I've added fixme comments everywhere where it looks suspicious but in the sysfs code. After a quick irc discussion with Dave Airlie it sounds like the lack of locking in there is due to sysfs cleanup fun at module unload. v1: original (only compile tested) v2: missing mutex_init(), etc (from Rob Clark) v3: i915 needs more care in the conversion: - Protect the edp pp logic with the connection_mutex. - Use connection_mutex in the backlight code due to get_pipe_from_connector. - Use drm_modeset_lock_all in suspend/resume paths. - Update lock checks in the overlay code. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com>
2014-05-29 15:54:47 -06:00
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
if (connector->encoder && connector->encoder->crtc == crtc) {
if (connector_list != NULL && count < num_connectors)
*(connector_list++) = connector;
count++;
}
}
drm_connector_list_iter_end(&conn_iter);
return count;
}
static int drm_plane_helper_check_update(struct drm_plane *plane,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_rect *src,
struct drm_rect *dst,
unsigned int rotation,
int min_scale,
int max_scale,
bool can_position,
bool can_update_disabled,
bool *visible)
{
struct drm_plane_state plane_state = {
.plane = plane,
.crtc = crtc,
.fb = fb,
.src_x = src->x1,
.src_y = src->y1,
.src_w = drm_rect_width(src),
.src_h = drm_rect_height(src),
.crtc_x = dst->x1,
.crtc_y = dst->y1,
.crtc_w = drm_rect_width(dst),
.crtc_h = drm_rect_height(dst),
.rotation = rotation,
.visible = *visible,
};
struct drm_crtc_state crtc_state = {
.crtc = crtc,
.enable = crtc->enabled,
drm: Don't pass clip to drm_atomic_helper_check_plane_state() Move the plane clip rectangle handling into drm_atomic_helper_check_plane_state(). Drivers no longer have to worry about such mundane details. v2: Convert armada, rcar, and sun4i as well v3: Resolve simple_kms_helper conflict Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Russell King <rmk+kernel@armlinux.org.uk> Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> #msm Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-5-ville.syrjala@linux.intel.com Acked-by: Liviu Dudau <liviu.dudau@arm.com> #hdlcd,malidp Acked-by: Philipp Zabel <p.zabel@pengutronix.de> #imx,mtk Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> #vmwgfx Acked-by: Neil Armstrong <narmstrong@baylibre.com> #meson Acked-by: Shawn Guo <shawnguo@kernel.org> #zte
2018-01-23 10:08:57 -07:00
.mode = crtc->mode,
};
int ret;
ret = drm_atomic_helper_check_plane_state(&plane_state, &crtc_state,
drm: Don't pass clip to drm_atomic_helper_check_plane_state() Move the plane clip rectangle handling into drm_atomic_helper_check_plane_state(). Drivers no longer have to worry about such mundane details. v2: Convert armada, rcar, and sun4i as well v3: Resolve simple_kms_helper conflict Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Russell King <rmk+kernel@armlinux.org.uk> Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> #msm Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-5-ville.syrjala@linux.intel.com Acked-by: Liviu Dudau <liviu.dudau@arm.com> #hdlcd,malidp Acked-by: Philipp Zabel <p.zabel@pengutronix.de> #imx,mtk Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> #vmwgfx Acked-by: Neil Armstrong <narmstrong@baylibre.com> #meson Acked-by: Shawn Guo <shawnguo@kernel.org> #zte
2018-01-23 10:08:57 -07:00
min_scale, max_scale,
can_position,
can_update_disabled);
if (ret)
return ret;
*src = plane_state.src;
*dst = plane_state.dst;
*visible = plane_state.visible;
return 0;
}
static int drm_primary_helper_update(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h,
struct drm_modeset_acquire_ctx *ctx)
{
struct drm_mode_set set = {
.crtc = crtc,
.fb = fb,
.mode = &crtc->mode,
.x = src_x >> 16,
.y = src_y >> 16,
};
struct drm_rect src = {
.x1 = src_x,
.y1 = src_y,
.x2 = src_x + src_w,
.y2 = src_y + src_h,
};
struct drm_rect dest = {
.x1 = crtc_x,
.y1 = crtc_y,
.x2 = crtc_x + crtc_w,
.y2 = crtc_y + crtc_h,
};
struct drm_connector **connector_list;
int num_connectors, ret;
bool visible;
ret = drm_plane_helper_check_update(plane, crtc, fb,
drm: Don't pass clip to drm_atomic_helper_check_plane_state() Move the plane clip rectangle handling into drm_atomic_helper_check_plane_state(). Drivers no longer have to worry about such mundane details. v2: Convert armada, rcar, and sun4i as well v3: Resolve simple_kms_helper conflict Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Russell King <rmk+kernel@armlinux.org.uk> Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> #msm Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-5-ville.syrjala@linux.intel.com Acked-by: Liviu Dudau <liviu.dudau@arm.com> #hdlcd,malidp Acked-by: Philipp Zabel <p.zabel@pengutronix.de> #imx,mtk Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> #vmwgfx Acked-by: Neil Armstrong <narmstrong@baylibre.com> #meson Acked-by: Shawn Guo <shawnguo@kernel.org> #zte
2018-01-23 10:08:57 -07:00
&src, &dest,
DRM_MODE_ROTATE_0,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, false, &visible);
if (ret)
return ret;
if (!visible)
/*
* Primary plane isn't visible. Note that unless a driver
* provides their own disable function, this will just
* wind up returning -EINVAL to userspace.
*/
return plane->funcs->disable_plane(plane, ctx);
/* Find current connectors for CRTC */
num_connectors = get_connectors_for_crtc(crtc, NULL, 0);
BUG_ON(num_connectors == 0);
connector_list = kcalloc(num_connectors, sizeof(*connector_list),
GFP_KERNEL);
if (!connector_list)
return -ENOMEM;
get_connectors_for_crtc(crtc, connector_list, num_connectors);
set.connectors = connector_list;
set.num_connectors = num_connectors;
/*
drm: Simplify fb refcounting rules around ->update_plane The introduction of primary planes has apparently caused a bit of fb refcounting fun for people. That makes it a good time to clean up the arcane rules and slight differences between ->update_plane and ->set_config. The new rules are: - The core holds a reference for both the new and the old fb (if they're non-NULL of course) while calling into the driver through either ->update_plane or ->set_config. - Drivers may not clobber plane->fb if their callback fails. If they do that, they need to store a pointer to the old fb in it again. When calling into the driver plane->fb still points at the current (old) framebuffer. - The core will update the plane->fb pointer on success. Drivers can do that themselves too, but aren't required to any more for the primary plane. - The core will update fb refcounts for the plane->fb pointer, presuming the drivers hold up their end of the bargain. v2: Remove now unused tmpfb (Thierry) v3: Drop broken changes from drm_mode_setplane (Ville). Also polish the commit message a bit. v4: Also fix up the handling of ->disable_plane in drm_plane_force_disable. The issue was that we didn't save plane->fb over the ->disable_plane call. Just paranoia, nothing relies on this. v5: Keep still useful comments about directly calling ->set_config, which I should have done for v4 already. Requested by Matt. Cc: Thierry Reding <treding@nvidia.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-04-23 09:34:06 -06:00
* We call set_config() directly here rather than using
* drm_mode_set_config_internal. We're reprogramming the same
* connectors that were already in use, so we shouldn't need the extra
* cross-CRTC fb refcounting to accomodate stealing connectors.
* drm_mode_setplane() already handles the basic refcounting for the
* framebuffers involved in this operation.
*/
ret = crtc->funcs->set_config(&set, ctx);
kfree(connector_list);
return ret;
}
static int drm_primary_helper_disable(struct drm_plane *plane,
struct drm_modeset_acquire_ctx *ctx)
{
drm/plane-helper: Don't fake-implement primary plane disabling After thinking about this topic a bit more I've reached the conclusion that implementing this doesn't make sense: - The locking is all wrong: set_config(NULL) will also unlink encoders and connectors, but those links are protected with the mode_config mutex. In the ->disable_plane callback we only hold all modeset locks, but eventually we want to switch to just grabbing the per-crtc (and maybe per-plane) locks as needed, maybe based on ww_mutexes. Having a callback which absolutely needs all modeset locks is bad for this conversion. Note that the same isn't true for the provided ->update_plane since we've audited the crtc helpers to make sure that not encoder or connector links are changed. - There's no way to re-enable the plane with an ->update_plane: The connectors/encoder links are lost and so we can't re-enable the CRTC. Even without that issue the driver might have reassigned some shared resources (as opposed to e.g. DPMS off, where drivers are not allowed to do that to make sure the CRTC can be enabled again). - The semantics don't make much sense: Userspace asked to scan out black (or some other color if the driver supports a background color), not that the screen be disabled. - Implementing proper primary plane support (i.e. actually disabling the primary plane without disabling the CRTC) is really simple, at least if all the hw needs is flipping a bit. The big task is auditing all the interactions with other ioctls when the CRTC is on but there's no primary plane (e.g. pageflips). And some of that work still needs to be done. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-04-15 02:02:43 -06:00
return -EINVAL;
}
/**
* drm_primary_helper_destroy() - Helper for primary plane destruction
* @plane: plane to destroy
*
* Provides a default plane destroy handler for primary planes. This handler
* is called during CRTC destruction. We disable the primary plane, remove
* it from the DRM plane list, and deallocate the plane structure.
*/
void drm_primary_helper_destroy(struct drm_plane *plane)
{
drm_plane_cleanup(plane);
kfree(plane);
}
EXPORT_SYMBOL(drm_primary_helper_destroy);
const struct drm_plane_funcs drm_primary_helper_funcs = {
.update_plane = drm_primary_helper_update,
.disable_plane = drm_primary_helper_disable,
.destroy = drm_primary_helper_destroy,
};
EXPORT_SYMBOL(drm_primary_helper_funcs);