diff mbox

[34/58] drm/i915: ensure the force pipe A quirk is actually followed

Message ID 1345403595-9678-35-git-send-email-daniel.vetter@ffwll.ch (mailing list archive)
State Accepted
Headers show

Commit Message

Daniel Vetter Aug. 19, 2012, 7:12 p.m. UTC
Many BIOSen forget to turn on the pipe A after resume (because they
actually don't turn on anything), so we have to do that ourselves when
sanitizing the hw state.

I've discovered this due to the recent addition of a pipe WARN that
takes the force quirk into account.

v2: Actually try to enable the pipe with a proper configuration instead
of simpyl switching it on with whatever random state the bios left it
in after resume.

v3: Fixup rebase conflict - the load_detect functions have lost their
encoder argument.

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/intel_display.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

Comments

Jesse Barnes Sept. 5, 2012, 4:32 p.m. UTC | #1
On Sun, 19 Aug 2012 21:12:51 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> Many BIOSen forget to turn on the pipe A after resume (because they
> actually don't turn on anything), so we have to do that ourselves when
> sanitizing the hw state.
> 
> I've discovered this due to the recent addition of a pipe WARN that
> takes the force quirk into account.
> 
> v2: Actually try to enable the pipe with a proper configuration instead
> of simpyl switching it on with whatever random state the bios left it
> in after resume.
> 
> v3: Fixup rebase conflict - the load_detect functions have lost their
> encoder argument.
> 
> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 2cfb397..ab4fa7f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7602,6 +7602,33 @@ intel_connector_break_all_links(struct intel_connector *connector)
>  	connector->encoder->base.crtc = NULL;
>  }
>  
> +static void intel_enable_pipe_a(struct drm_device *dev)
> +{
> +	struct intel_connector *connector;
> +	struct drm_connector *crt = NULL;
> +	struct intel_load_detect_pipe load_detect_temp;
> +
> +	/* We can't just switch on the pipe A, we need to set things up with a
> +	 * proper mode and output configuration. As a gross hack, enable pipe A
> +	 * by enabling the load detect pipe once. */
> +	list_for_each_entry(connector,
> +			    &dev->mode_config.connector_list,
> +			    base.head) {
> +		if (connector->encoder->type == INTEL_OUTPUT_ANALOG) {
> +			crt = &connector->base;
> +			break;
> +		}
> +	}
> +
> +	if (!crt)
> +		return;
> +
> +	if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp))
> +		intel_release_load_detect_pipe(crt, &load_detect_temp);

Should we shout if this fails?  Other than that:
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Daniel Vetter Sept. 5, 2012, 7:12 p.m. UTC | #2
On Wed, Sep 5, 2012 at 6:32 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Sun, 19 Aug 2012 21:12:51 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
>> Many BIOSen forget to turn on the pipe A after resume (because they
>> actually don't turn on anything), so we have to do that ourselves when
>> sanitizing the hw state.
>>
>> I've discovered this due to the recent addition of a pipe WARN that
>> takes the force quirk into account.
>>
>> v2: Actually try to enable the pipe with a proper configuration instead
>> of simpyl switching it on with whatever random state the bios left it
>> in after resume.
>>
>> v3: Fixup rebase conflict - the load_detect functions have lost their
>> encoder argument.
>>
>> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 36 ++++++++++++++++++++++++++++++++++++
>>  1 file changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 2cfb397..ab4fa7f 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -7602,6 +7602,33 @@ intel_connector_break_all_links(struct intel_connector *connector)
>>       connector->encoder->base.crtc = NULL;
>>  }
>>
>> +static void intel_enable_pipe_a(struct drm_device *dev)
>> +{
>> +     struct intel_connector *connector;
>> +     struct drm_connector *crt = NULL;
>> +     struct intel_load_detect_pipe load_detect_temp;
>> +
>> +     /* We can't just switch on the pipe A, we need to set things up with a
>> +      * proper mode and output configuration. As a gross hack, enable pipe A
>> +      * by enabling the load detect pipe once. */
>> +     list_for_each_entry(connector,
>> +                         &dev->mode_config.connector_list,
>> +                         base.head) {
>> +             if (connector->encoder->type == INTEL_OUTPUT_ANALOG) {
>> +                     crt = &connector->base;
>> +                     break;
>> +             }
>> +     }
>> +
>> +     if (!crt)
>> +             return;
>> +
>> +     if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp))
>> +             intel_release_load_detect_pipe(crt, &load_detect_temp);
>
> Should we shout if this fails?  Other than that:

We'll definitely shout on the next modeset (on pipe B) if pipe A is
still off. And the code also shouted rather loudly while we I've tried
to get this to work properly. So judging from experience I think we're
covered ...
-Daniel

> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>
> --
> Jesse Barnes, Intel Open Source Technology Center
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 2cfb397..ab4fa7f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7602,6 +7602,33 @@  intel_connector_break_all_links(struct intel_connector *connector)
 	connector->encoder->base.crtc = NULL;
 }
 
+static void intel_enable_pipe_a(struct drm_device *dev)
+{
+	struct intel_connector *connector;
+	struct drm_connector *crt = NULL;
+	struct intel_load_detect_pipe load_detect_temp;
+
+	/* We can't just switch on the pipe A, we need to set things up with a
+	 * proper mode and output configuration. As a gross hack, enable pipe A
+	 * by enabling the load detect pipe once. */
+	list_for_each_entry(connector,
+			    &dev->mode_config.connector_list,
+			    base.head) {
+		if (connector->encoder->type == INTEL_OUTPUT_ANALOG) {
+			crt = &connector->base;
+			break;
+		}
+	}
+
+	if (!crt)
+		return;
+
+	if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp))
+		intel_release_load_detect_pipe(crt, &load_detect_temp);
+
+
+}
+
 static void intel_sanitize_crtc(struct intel_crtc *crtc)
 {
 	struct drm_device *dev = crtc->base.dev;
@@ -7650,6 +7677,15 @@  static void intel_sanitize_crtc(struct intel_crtc *crtc)
 	}
 ok:
 
+	if (dev_priv->quirks & QUIRK_PIPEA_FORCE &&
+	    crtc->pipe == PIPE_A && !crtc->active) {
+		/* BIOS forgot to enable pipe A, this mostly happens after
+		 * resume. Force-enable the pipe to fix this, the update_dpms
+		 * call below we restore the pipe to the right state, but leave
+		 * the required bits on. */
+		intel_enable_pipe_a(dev);
+	}
+
 	/* Adjust the state of the output pipe according to whether we
 	 * have active connectors/encoders. */
 	intel_crtc_update_dpms(&crtc->base);