All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ander Conselvan de Oliveira <conselvan2@gmail.com>
To: Matt Roper <matthew.d.roper@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 09/13] drm/i915: Setup dummy atomic state for connectors
Date: Wed, 21 Jan 2015 20:21:16 +0200	[thread overview]
Message-ID: <54BFEE1C.8020202@gmail.com> (raw)
In-Reply-To: <1421726266-31941-10-git-send-email-matthew.d.roper@intel.com>

On 01/20/2015 05:57 AM, Matt Roper wrote:
> We want to enable/test plane updates via the atomic interface, but as
> soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic
> codepaths to lookup properties during drmModeGetConnector() and some of
> those codepaths unconditionally dereference connector->state
> (specifically when looking up the CRTC ID property in
> drm_atomic_connector_get_property()).  Create a dummy connector state
> for each connector at init time to ensure the DRM core doesn't try to
> dereference a NULL connector->state.  The actual connector properties
> will never be updated or contain useful information, but since we're
> doing this specifically for testing/debug of the plane operations (and
> only when a specific kernel module option is given), that shouldn't
> really matter.
>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>   drivers/gpu/drm/i915/intel_display.c | 28 ++++++++++++++++++++++++++++
>   1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 0e18879..82defd3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12368,6 +12368,7 @@ static void intel_setup_outputs(struct drm_device *dev)
>   {
>   	struct drm_i915_private *dev_priv = dev->dev_private;
>   	struct intel_encoder *encoder;
> +	struct drm_connector *connector;
>   	bool dpd_is_edp = false;
>
>   	intel_lvds_init(dev);
> @@ -12498,6 +12499,33 @@ static void intel_setup_outputs(struct drm_device *dev)
>   	if (SUPPORTS_TV(dev))
>   		intel_tv_init(dev);
>
> +	/*
> +	 * FIXME:  We don't have full atomic support yet, but we want to be
> +	 * able to enable/test plane updates via the atomic interface in the
> +	 * meantime.  However as soon as we flip DRIVER_ATOMIC on, the DRM core
> +	 * will take some atomic codepaths to lookup properties during
> +	 * drmModeGetConnector() that unconditionally dereference
> +	 * connector->state.
> +	 *
> +	 * We create a dummy connector state here for each connector to ensure
> +	 * the DRM core doesn't try to dereference a NULL connector->state.
> +	 * The actual connector properties will never be updated or contain
> +	 * useful information, but since we're doing this specifically for
> +	 * testing/debug of the plane operations (and only when a specific
> +	 * kernel module option is given), that shouldn't really matter.
> +	 *
> +	 * Once atomic support for crtc's + connectors lands, this loop should
> +	 * be removed since we'll be setting up real connector state, which
> +	 * will contain Intel-specific properties.
> +	 */
> +	list_for_each_entry(connector,
> +			    &dev->mode_config.connector_list,
> +			    head) {
> +		if (!WARN_ON(connector->state))
> +			connector->state = kzalloc(sizeof(*connector->state),
> +						   GFP_KERNEL);
> +	}
> +

I think this will trigger a WARN in drm_connector_cleanup() on driver 
unload, and we also leak the dummy state.

Also, I'm not sure if this changes the behaviour of 
drm_mode_getconnector(), since now the call to 
drm_connector_get_encoder() will always return NULL.

Ander

>   	intel_psr_init(dev);
>
>   	for_each_intel_encoder(dev, encoder) {
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-01-21 18:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-20  3:57 [PATCH 00/13] i915 nuclear pageflip Matt Roper
2015-01-20  3:57 ` [PATCH 01/13] squash! drm/i915: Improve how the memory for crtc state is allocated Matt Roper
2015-01-20  3:57 ` [PATCH 02/13] drm/i915: Move rotation from intel_plane to intel_plane_state Matt Roper
2015-01-21 10:03   ` Ander Conselvan de Oliveira
2015-01-20  3:57 ` [PATCH 03/13] drm/i915: Consolidate plane handler vtables Matt Roper
2015-01-21 10:09   ` Ander Conselvan de Oliveira
2015-01-20  3:57 ` [PATCH 04/13] drm/plane-helper: Add transitional helper for .set_plane() Matt Roper
2015-01-20  3:57 ` [PATCH 05/13] drm/plane-helper: Fix transitional helper kerneldocs Matt Roper
2015-01-20  3:57 ` [PATCH 06/13] drm/i915: Add .atomic_{get, set}_property() entrypoints to planes Matt Roper
2015-01-20  3:57 ` [PATCH 07/13] drm/i915: Replace intel_set_property() with transitional helper Matt Roper
2015-01-20  3:57 ` [PATCH 08/13] drm/i915: Add main atomic entrypoints Matt Roper
2015-01-21 13:48   ` Ander Conselvan de Oliveira
2015-01-20  3:57 ` [PATCH 09/13] drm/i915: Setup dummy atomic state for connectors Matt Roper
2015-01-21 18:21   ` Ander Conselvan de Oliveira [this message]
2015-01-20  3:57 ` [PATCH 10/13] drm/i915: Set connector state destruction handler Matt Roper
2015-01-21 18:24   ` Ander Conselvan de Oliveira
2015-01-20  3:57 ` [PATCH 11/13] drm/i915: Add atomic_get_property entrypoint for connectors Matt Roper
2015-01-20  3:57 ` [PATCH 12/13] drm/i915: Add crtc state duplication/destruction functions Matt Roper
2015-01-20  3:57 ` [PATCH 13/13] drm/i915: Add i915.nuclear kernel command line param to force atomic Matt Roper
2015-01-20 10:17   ` Daniel Vetter
2015-01-20 14:22     ` Jani Nikula
2015-01-21 18:44   ` Ander Conselvan de Oliveira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54BFEE1C.8020202@gmail.com \
    --to=conselvan2@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.