Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp3524023rwl; Tue, 27 Dec 2022 10:24:24 -0800 (PST) X-Google-Smtp-Source: AMrXdXu3klblMyIpj3x+OWDwTjeU6TxTpPtNkHze5dC12NtKlWK9VVeDiF6EVP7cfGcHT1/dQSOz X-Received: by 2002:a17:90b:8b:b0:223:fec2:f9e0 with SMTP id bb11-20020a17090b008b00b00223fec2f9e0mr24407601pjb.35.1672165464558; Tue, 27 Dec 2022 10:24:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672165464; cv=none; d=google.com; s=arc-20160816; b=BH4yFwTBFu2tvmpGCRLvD31UPNHYbXbvlON0nYhVp/ASlp/RQwoXMPyeZb4wGdfi1a 4abYy2b4b2ouReqsm0/V2hAAQKOoZfa9dRYQYYS/VXZfr8HML0ITdPX3783Ibx8MldUl mfcIC9sD8nSf4zmeDYoEVGc39RwLd3VWDmjgXk4I81wmyt5uKrwrY/o9fMX8DbqNFD01 d77/28B/G2E8+UYfBCPG/Z8r7CYKypbz5WQ4sJzfgyNw6N4GAv6Z6cJr05HOq8XgpBVE upticdFqo6Z+a/dXz08LvJavKvxLyrXiLYtz4pBl+Va02GwboRWUuAr5KdAHDPsdZ8Xs nyDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=O3IfD2rnmuqDpbg0u7OKsWKBEPTwptgRXaYL7QMT/Co=; b=fCOMmUO7mgGF7iArcFh5uq60QmkcJWhh4aXkA0DHCEnOiXb/qW80a0UrdsoGn9OHT3 ifoYhPmnKdHfbd6PActa2wJQtjFodlvUQ+TJaF3LMChdko5yETOWGaHh0UXj1zWI5ljf peMQ/1DgPK5O2QTkGaYjyKpoz+azDJUQF1RAzX1SiRd+qPTWxwjvRwX+PXIIs5UNqDpL px0N/f7pcuJA27mMhAfhrKhy7ZdhQ0zNKWr7waIYqQrM0tWluBEjRm6/dBDSbwsUjqZ4 JJKIaeead5l7/5+/8Yew4p+bsW6A+Vbypfb6cI506kYO3gNQxrNpTxIKkIYTHuMig9Eh deTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@skif-web.ru header.s=mail header.b=N4GGP21F; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f10-20020a17090aa78a00b00213b01e42adsi13601283pjq.42.2022.12.27.10.24.14; Tue, 27 Dec 2022 10:24:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@skif-web.ru header.s=mail header.b=N4GGP21F; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232097AbiL0Rrc (ORCPT + 66 others); Tue, 27 Dec 2022 12:47:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232229AbiL0Rqm (ORCPT ); Tue, 27 Dec 2022 12:46:42 -0500 X-Greylist: delayed 370 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 27 Dec 2022 09:46:30 PST Received: from forward501c.mail.yandex.net (forward501c.mail.yandex.net [IPv6:2a02:6b8:c03:500:1:45:d181:d501]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2002FCE15; Tue, 27 Dec 2022 09:46:30 -0800 (PST) Received: from myt6-1289f562e823.qloud-c.yandex.net (myt6-1289f562e823.qloud-c.yandex.net [IPv6:2a02:6b8:c12:259d:0:640:1289:f562]) by forward501c.mail.yandex.net (Yandex) with ESMTP id CB03E5F1A8; Tue, 27 Dec 2022 20:40:11 +0300 (MSK) Received: by myt6-1289f562e823.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 4eTgJY4Y8mI1-9YvFUjgN; Tue, 27 Dec 2022 20:40:11 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skif-web.ru; s=mail; t=1672162811; bh=O3IfD2rnmuqDpbg0u7OKsWKBEPTwptgRXaYL7QMT/Co=; h=Message-ID:Subject:References:To:From:In-Reply-To:Cc:Date; b=N4GGP21FyopxUJO5DtsV4VvXufE4Cod1Zj8k5HTI2xZ+tEflHpwC5KGJ+Ng4WrEdK 3axIsX8urQUSAPmXwpZ+jGCIVB+3tHbaHbwybvWWm/5bycsQsv2US+3F+wYPgag6V5 shGCDtQzsIkmIVw/gnpcSWyM1GhCPp92bEc7Ex/A= Authentication-Results: myt6-1289f562e823.qloud-c.yandex.net; dkim=pass header.i=@skif-web.ru Date: Tue, 27 Dec 2022 20:40:03 +0300 From: Alexey Lukyachuk To: Rodrigo Vivi Cc: , , "Greg Kroah-Hartman" , , , , Daniel Vetter , David Airlie Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: dell wyse 3040 shutdown fix Message-ID: <20221227204003.6b0abe65@alexey-Swift-SF314-42> In-Reply-To: References: <20221225184413.146916-1-skif@skif-web.ru> <20221225185507.149677-1-skif@skif-web.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NO_DNS_FOR_FROM,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Dec 2022 11:39:25 -0500 Rodrigo Vivi wrote: > On Sun, Dec 25, 2022 at 09:55:08PM +0300, Alexey Lukyanchuk wrote: > > dell wyse 3040 doesn't peform poweroff properly, but instead remains in= =20 > > turned power on state. >=20 > okay, the motivation is explained in the commit msg.. >=20 > > Additional mutex_lock and=20 > > intel_crtc_wait_for_next_vblank=20 > > feature 6.2 kernel resolve this trouble. >=20 > but this why is not very clear... seems that by magic it was found, > without explaining what race we are really protecting here. >=20 > but even worse is: > what about those many random vblank waits in the code? what's the > reasoning? >=20 > >=20 > > cc: stable@vger.kernel.org > > original commit Link: https://patchwork.freedesktop.org/patch/508926/ > > fixes: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c > > Signed-off-by: Alexey Lukyanchuk > > --- > > I got some troubles with this device (dell wyse 3040) since kernel 5.11 > > started to use i915_driver_shutdown function. I found solution here: > >=20 > > https://lore.kernel.org/dri-devel/Y1wd6ZJ8LdJpCfZL@intel.com/#r > >=20 > > --- > > drivers/gpu/drm/i915/display/intel_audio.c | 37 +++++++++++++++------- > > 1 file changed, 25 insertions(+), 12 deletions(-) > >=20 > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c b/drivers/gpu/d= rm/i915/display/intel_audio.c > > index aacbc6da8..44344ecdf 100644 > > --- a/drivers/gpu/drm/i915/display/intel_audio.c > > +++ b/drivers/gpu/drm/i915/display/intel_audio.c > > @@ -336,6 +336,7 @@ static void g4x_audio_codec_disable(struct intel_en= coder *encoder, > > const struct drm_connector_state *old_conn_state) > > { > > struct drm_i915_private *dev_priv =3D to_i915(encoder->base.dev); > > + struct intel_crtc *crtc =3D to_intel_crtc(old_crtc_state->uapi.crtc); > > u32 eldv, tmp; > > =20 > > tmp =3D intel_de_read(dev_priv, G4X_AUD_VID_DID); > > @@ -348,6 +349,9 @@ static void g4x_audio_codec_disable(struct intel_en= coder *encoder, > > tmp =3D intel_de_read(dev_priv, G4X_AUD_CNTL_ST); > > tmp &=3D ~eldv; > > intel_de_write(dev_priv, G4X_AUD_CNTL_ST, tmp); > > + > > + intel_crtc_wait_for_next_vblank(crtc); > > + intel_crtc_wait_for_next_vblank(crtc); > > } > > =20 > > static void g4x_audio_codec_enable(struct intel_encoder *encoder, > > @@ -355,12 +359,15 @@ static void g4x_audio_codec_enable(struct intel_e= ncoder *encoder, > > const struct drm_connector_state *conn_state) > > { > > struct drm_i915_private *dev_priv =3D to_i915(encoder->base.dev); > > + struct intel_crtc *crtc =3D to_intel_crtc(crtc_state->uapi.crtc); > > struct drm_connector *connector =3D conn_state->connector; > > const u8 *eld =3D connector->eld; > > u32 eldv; > > u32 tmp; > > int len, i; > > =20 > > + intel_crtc_wait_for_next_vblank(crtc); > > + > > tmp =3D intel_de_read(dev_priv, G4X_AUD_VID_DID); > > if (tmp =3D=3D INTEL_AUDIO_DEVBLC || tmp =3D=3D INTEL_AUDIO_DEVCL) > > eldv =3D G4X_ELDV_DEVCL_DEVBLC; > > @@ -493,6 +500,7 @@ static void hsw_audio_codec_disable(struct intel_en= coder *encoder, > > const struct drm_connector_state *old_conn_state) > > { > > struct drm_i915_private *dev_priv =3D to_i915(encoder->base.dev); > > + struct intel_crtc *crtc =3D to_intel_crtc(old_crtc_state->uapi.crtc); > > enum transcoder cpu_transcoder =3D old_crtc_state->cpu_transcoder; > > u32 tmp; > > =20 > > @@ -508,6 +516,10 @@ static void hsw_audio_codec_disable(struct intel_e= ncoder *encoder, > > tmp |=3D AUD_CONFIG_N_VALUE_INDEX; > > intel_de_write(dev_priv, HSW_AUD_CFG(cpu_transcoder), tmp); > > =20 > > + > > + intel_crtc_wait_for_next_vblank(crtc); > > + intel_crtc_wait_for_next_vblank(crtc); > > + > > /* Invalidate ELD */ > > tmp =3D intel_de_read(dev_priv, HSW_AUD_PIN_ELD_CP_VLD); > > tmp &=3D ~AUDIO_ELD_VALID(cpu_transcoder); > > @@ -633,6 +645,7 @@ static void hsw_audio_codec_enable(struct intel_enc= oder *encoder, > > const struct drm_connector_state *conn_state) > > { > > struct drm_i915_private *dev_priv =3D to_i915(encoder->base.dev); > > + struct intel_crtc *crtc =3D to_intel_crtc(crtc_state->uapi.crtc); > > struct drm_connector *connector =3D conn_state->connector; > > enum transcoder cpu_transcoder =3D crtc_state->cpu_transcoder; > > const u8 *eld =3D connector->eld; > > @@ -651,12 +664,7 @@ static void hsw_audio_codec_enable(struct intel_en= coder *encoder, > > tmp &=3D ~AUDIO_ELD_VALID(cpu_transcoder); > > intel_de_write(dev_priv, HSW_AUD_PIN_ELD_CP_VLD, tmp); > > =20 > > - /* > > - * FIXME: We're supposed to wait for vblank here, but we have vblanks > > - * disabled during the mode set. The proper fix would be to push the > > - * rest of the setup into a vblank work item, queued here, but the > > - * infrastructure is not there yet. > > - */ > > + intel_crtc_wait_for_next_vblank(crtc); > > =20 > > /* Reset ELD write address */ > > tmp =3D intel_de_read(dev_priv, HSW_AUD_DIP_ELD_CTRL(cpu_transcoder)); > > @@ -705,6 +713,8 @@ static void ilk_audio_codec_disable(struct intel_en= coder *encoder, > > aud_cntrl_st2 =3D CPT_AUD_CNTRL_ST2; > > } > > =20 > > + mutex_lock(&dev_priv->display.audio.mutex); > > + > > /* Disable timestamps */ > > tmp =3D intel_de_read(dev_priv, aud_config); > > tmp &=3D ~AUD_CONFIG_N_VALUE_INDEX; > > @@ -721,6 +731,10 @@ static void ilk_audio_codec_disable(struct intel_e= ncoder *encoder, > > tmp =3D intel_de_read(dev_priv, aud_cntrl_st2); > > tmp &=3D ~eldv; > > intel_de_write(dev_priv, aud_cntrl_st2, tmp); > > + mutex_unlock(&dev_priv->display.audio.mutex); > > + > > + intel_crtc_wait_for_next_vblank(crtc); > > + intel_crtc_wait_for_next_vblank(crtc); > > } > > =20 > > static void ilk_audio_codec_enable(struct intel_encoder *encoder, > > @@ -740,12 +754,7 @@ static void ilk_audio_codec_enable(struct intel_en= coder *encoder, > > if (drm_WARN_ON(&dev_priv->drm, port =3D=3D PORT_A)) > > return; > > =20 > > - /* > > - * FIXME: We're supposed to wait for vblank here, but we have vblanks > > - * disabled during the mode set. The proper fix would be to push the > > - * rest of the setup into a vblank work item, queued here, but the > > - * infrastructure is not there yet. > > - */ > > + intel_crtc_wait_for_next_vblank(crtc); > > =20 > > if (HAS_PCH_IBX(dev_priv)) { > > hdmiw_hdmiedid =3D IBX_HDMIW_HDMIEDID(pipe); > > @@ -767,6 +776,8 @@ static void ilk_audio_codec_enable(struct intel_enc= oder *encoder, > > =20 > > eldv =3D IBX_ELD_VALID(port); > > =20 > > + mutex_lock(&dev_priv->display.audio.mutex); > > + > > /* Invalidate ELD */ > > tmp =3D intel_de_read(dev_priv, aud_cntrl_st2); > > tmp &=3D ~eldv; > > @@ -798,6 +809,8 @@ static void ilk_audio_codec_enable(struct intel_enc= oder *encoder, > > else > > tmp |=3D audio_config_hdmi_pixel_clock(crtc_state); > > intel_de_write(dev_priv, aud_config, tmp); > > + > > + mutex_unlock(&dev_priv->display.audio.mutex); > > } > > =20 > > /** > > --=20 > > 2.25.1 > >=20 I would like to say, that this solution was found in drm-tip repository: link: git://anongit.freedesktop.org/drm-tip I will quotate original commit message from Ville Syrj=C3=A4l=C3=A4=20 : "The spec tells us to do a bunch of=20 vblank waits in the audio enable/disable sequences. Make it so." So it's just a backport of accepted patch. Which i wanna to propagate to stable versions