Re: [Intel-gfx] [PATCH] drm/i915: Force a TypeC PHY disconnect during suspend/shutdown
On Fri, Jun 11, 2021 at 1:42 AM Imre Deak wrote:
>
> Disconnect TypeC PHYs during system suspend and shutdown, even with the
> corresponding TypeC sink still plugged to its connector, since leaving
> the PHY connected causes havoc at least during system resume in the
> presence of an Nvidia card.
>
> Note that this will only make a difference in the TypeC DP alternate
> mode, since in Thunderbolt alternate mode the PHY is never owned by the
> display engine and there is no notion of PHY ownership in legacy mode
> (the display engine being the only possible owner in that mode and the
> TypeC subsystem not having anything to do with the port in that case).
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3500
> Reported-and-tested-by: Chris Chiu
> Signed-off-by: Imre Deak
> ---
Tested-by: Chris Chiu
> drivers/gpu/drm/i915/display/intel_ddi.c | 34 ++--
> drivers/gpu/drm/i915/display/intel_tc.c | 34 +++-
> drivers/gpu/drm/i915/display/intel_tc.h | 2 ++
> 3 files changed, 61 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 390869bd6b633..7e25d0f80b78f 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4496,6 +4496,36 @@ static bool intel_ddi_is_tc(struct drm_i915_private
> *i915, enum port port)
> return false;
> }
>
> +static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> +
> + intel_dp_encoder_suspend(encoder);
> +
> + if (!intel_phy_is_tc(i915, phy))
> + return;
> +
> + intel_tc_port_disconnect_phy(dig_port);
> +}
> +
> +void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> +
> + intel_dp_encoder_shutdown(encoder);
> +
> + if (!intel_phy_is_tc(i915, phy))
> + return;
> +
> + intel_tc_port_disconnect_phy(dig_port);
> +}
> +
> #define port_tc_name(port) ((port) - PORT_TC1 + '1')
> #define tc_port_name(tc_port) ((tc_port) - TC_PORT_1 + '1')
>
> @@ -4605,8 +4635,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> encoder->get_hw_state = intel_ddi_get_hw_state;
> encoder->sync_state = intel_ddi_sync_state;
> encoder->initial_fastset_check = intel_ddi_initial_fastset_check;
> - encoder->suspend = intel_dp_encoder_suspend;
> - encoder->shutdown = intel_dp_encoder_shutdown;
> + encoder->suspend = intel_ddi_encoder_suspend;
> + encoder->shutdown = intel_ddi_encoder_shutdown;
> encoder->get_power_domains = intel_ddi_get_power_domains;
>
> encoder->type = INTEL_OUTPUT_DDI;
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index c23c210a55f5c..3ffece568ed98 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -556,7 +556,7 @@ intel_tc_port_get_target_mode(struct intel_digital_port
> *dig_port)
> }
>
> static void intel_tc_port_reset_mode(struct intel_digital_port *dig_port,
> -int required_lanes)
> +int required_lanes, bool
> force_disconnect)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> enum tc_port_mode old_tc_mode = dig_port->tc_mode;
> @@ -572,7 +572,8 @@ static void intel_tc_port_reset_mode(struct
> intel_digital_port *dig_port,
> }
>
> icl_tc_phy_disconnect(dig_port);
> - icl_tc_phy_connect(dig_port, required_lanes);
> + if (!force_disconnect)
> + icl_tc_phy_connect(dig_port, required_lanes);
>
> drm_dbg_kms(>drm, "Port %s: TC port mode reset (%s -> %s)\n",
> dig_port->tc_port_name,
> @@ -662,7 +663,7 @@ bool intel_tc_port_connected(struct intel_encoder
> *encoder)
> }
>
> static void __intel_tc_port_lock(struct intel_digital_port *dig_port,
> -
Re: [Intel-gfx] NVIDIA GPU fallen off the bus after exiting s2idle
On Thu, May 6, 2021 at 5:46 PM Rafael J. Wysocki wrote:
>
> On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote:
> >
> > Hi,
> > We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> > suffering the same GPU falling off the bus problem while exiting
> > s2idle with external display connected. These laptops connect the
> > external display via the HDMI/DisplayPort on a USB Type-C interfaced
> > dock. If we enter and exit s2idle with the dock connected, the NVIDIA
> > GPU (confirmed on 10de:24b6 and 10de:25b8) and the PCIe port can come
> > back to D0 w/o problem. If we enter the s2idle, disconnect the dock,
> > then exit the s2idle, both external display and the panel will remain
> > with no output. The dmesg as follows shows the "nvidia :01:00.0:
> > can't change power state from D3cold to D0 (config space
> > inaccessible)" due to the following ACPI error
> > [ 154.446781]
> > [ 154.446783]
> > [ 154.446783] Initialized Local Variables for Method [IPCS]:
> > [ 154.446784] Local0: 9863e365 Integer 09C5
> > [ 154.446790]
> > [ 154.446791] Initialized Arguments for Method [IPCS]: (7 arguments
> > defined for method invocation)
> > [ 154.446792] Arg0: 25568fbd Integer 00AC
> > [ 154.446795] Arg1: 9ef30e76 Integer
> > [ 154.446798] Arg2: fdf820f0 Integer 0010
> > [ 154.446801] Arg3: 9fc2a088 Integer 0001
> > [ 154.446804] Arg4: 3a3418f7 Integer 0001
> > [ 154.446807] Arg5: 20c4b87c Integer
> > [ 154.446810] Arg6: 8b965a8a Integer
> > [ 154.446813]
> > [ 154.446815] ACPI Error: Aborting method \IPCS due to previous error
> > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446824] ACPI Error: Aborting method \MCUI due to previous error
> > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446829] ACPI Error: Aborting method \SPCX due to previous error
> > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446835] ACPI Error: Aborting method \_SB.PC00.PGSC due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446841] ACPI Error: Aborting method \_SB.PC00.PGON due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446846] ACPI Error: Aborting method \_SB.PC00.PEG1.NPON due to
> > previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446852] ACPI Error: Aborting method \_SB.PC00.PEG1.PG01._ON due
> > to previous error (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529)
> > [ 154.446860] acpi device:02: Failed to change power state to D0
> > [ 154.690760] video LNXVIDEO:00: Cannot transition to power state D0
> > for parent in (unknown)
>
> If I were to guess, I would say that AML tries to access memory that
> is not accessible while suspended, probably PCI config space.
>
> > The IPCS is the last function called from \_SB.PC00.PEG1.PG01._ON
> > which we expect it to prepare everything before bringing back the
> > NVIDIA GPU but it's stuck in the infinite loop as described below.
> > Please refer to
> > https://gist.github.com/mschiu77/fa4f5a97297749d0d66fe60c1d421c44 for
> > the full DSDT.dsl.
>
> The DSDT alone may not be sufficient.
>
> Can you please create a bug entry at bugzilla.kernel.org for this
> issue and attach the full output of acpidump from one of the affected
> machines to it? And please let me know the number of the bug.
>
> Also please attach the output of dmesg including a suspend-resume
> cycle including dock disconnection while suspended and the ACPI
> messages quoted below.
>
> >While (One)
> > {
> > If ((!IBSY || (IERR == One)))
> > {
> > Break
> > }
> >
> > If ((Local0 > TMOV))
> > {
> > RPKG [Zero] = 0x03
> > Return (RPKG) /* \IPCS.RPKG */
> > }
> >
> > Sleep (One)
> > Local0++
> > }
> >
> > And the upstream PCIe port of NVIDIA seems to become inaccessible due
> > to the messages as follows.
> > [ 292.746508] pcieport :00:01.0: waiting 100 ms for downstream
> > link, after activation
> > [ 292.882296] pci :01:00.0: waiting additional 100 ms to become
> > accessible
> > [ 316.876997] pci :01:00.0: can't change power state from D3cold
> > to D0 (config space inaccessible)
[Intel-gfx] TGL: : No video output on external monitor after unplug and re-plug the cable
We found another bug after the fix of https://gitlab.freedesktop.org/drm/intel/-/issues/2538. The external monitor is also connected via WD19's HDMI/DisplayPort just as #2538. However, the display monitor can only be detected and show output at the very first time we power on the WD19 dock. If we unplug the cable and replug again, the monitor seems to be detected but there's no video output. When we power on the WD19 dock with cable connected to the monitor, the drm kernel log shows as follows i915 :00:02.0: [drm:intel_get_hpd_pins.isra.0 [i915]] hotplug event received, stat 0x0001, dig 0x008a, pins 0x0200, long 0x0200 i915 :00:02.0: [drm:intel_hpd_irq_handler [i915]] digital hpd on [ENCODER:292:DDI D] - long i915 :00:02.0: [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 9 - cnt: 10 i915 :00:02.0: [drm:intel_dp_hpd_pulse [i915]] got hpd irq on [ENCODER:292:DDI D] - long i915 :00:02.0: [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions i915 :00:02.0: [drm:i915_hotplug_work_func [i915]] Connector DP-1 (pin 9) received hotplug event. (retry 0) i915 :00:02.0: [drm:intel_dp_detect [i915]] [CONNECTOR:293:DP-1] i915 :00:02.0: [drm:intel_power_well_enable [i915]] enabling TC cold off i915 :00:02.0: [drm:tgl_tc_cold_request [i915]] TC cold block succeeded i915 :00:02.0: [drm:__intel_tc_port_lock [i915]] Port D/TC#1: TC port mode reset (tbt-alt -> dp-alt) i915 :00:02.0: [drm:intel_power_well_enable [i915]] enabling AUX D TC1 i915 :00:02.0: [drm:drm_dp_dpcd_read [drm_kms_helper]] AUX D/port D: 0xf AUX -> (ret= 8) 14 1e 40 55 02 00 00 00 i915 :00:02.0: [drm:intel_dp_lttpr_init [i915]] LTTPR common capabilities: 14 1e 40 55 02 00 00 00 Then I replug the cable, the intel_power_well_enable() in intel_dp_aux_xfer() shows "enabling DC off" power domain instead of enabling AUX D TC1. After that, the flooded i915 :00:02.0: [drm:intel_dp_aux_xfer [i915]] AUX D/port D: timeout (status 0x7d4003ff) keeps show up and no video output. I filed a bug on https://gitlab.freedesktop.org/drm/intel/-/issues/3407 and also uploaded the journal log with kernel boot parameter "drm.debug=0x10e". Can anyone suggest what happens at the replug? What can we do to identify the cause? Thanks Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Unexpected screen flicker during i915 initialization
On Wed, Oct 30, 2019 at 6:25 PM Chris Chiu wrote: > > Hi guys, > We have 2 laptops, ASUS Z406MA and Acer TravelMate B118, both > powered by the same Intel N5000 GemniLake CPU. On the Acer laptop, the > panel will blink once during boot which never happens on the ASUS > laptop. It caught my attention and I find the difference between them > but I need help for more information, Sorry, I forgot to mention that the problem was reproduced on the latest kernel 5.3. Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Unexpected screen flicker during i915 initialization
Hi guys, We have 2 laptops, ASUS Z406MA and Acer TravelMate B118, both powered by the same Intel N5000 GemniLake CPU. On the Acer laptop, the panel will blink once during boot which never happens on the ASUS laptop. It caught my attention and I find the difference between them but I need help for more information, The major difference happens in bxt_sanitize_cdclk() on the following condition check. if (cdctl == expected) /* All well; nothing to sanitize */ return; On the problematic Acer laptop, the value of cdctl is 0x27a while the same cdctl is 0x278 on ASUS machine. Due to the 0x27a is not equal to the expected value 0x278 so it needs to be sanitized by assigning -1 to dev_priv->cdclk.hw.vco. Then the consequent bxt_set_cdclk() will force the full PLL disable and enable. And that's the flicker (blink) we observed during boot. Although I can't find the definition about the BIT(2) of CDCLK_CTL which cause this difference. Can anyone suggest what exactly the problem is and how should we deal with it? Thanks. Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)
On Thu, Jan 3, 2019 at 1:50 AM Guang Bai wrote: > > On Wed, 2 Jan 2019 17:29:46 +0800 > Chris Chiu wrote: > > > Happy New Year. > > Sorry for bothering you guys again, I don't really want to make myself > > a nuisance. > > Is there any better idea for fixing this issue? > I've already back ported this change into the kernel 4.18.17 and sent > it to our customer for integration test - So far so good. > Thanks, > -Guang Thanks, Guang. Can I expect to see it in next kernel release? Or we need to wait until more positive results coming? > > > > Chris > > > > On Mon, Dec 3, 2018 at 6:38 PM Chris Chiu wrote: > > > > > > On Fri, Nov 30, 2018 at 1:15 AM Guang Bai > > > wrote: > > > > > > > > On Thu, 29 Nov 2018 10:17:49 +0200 > > > > Jani Nikula wrote: > > > > > > > > > On Wed, 28 Nov 2018, Guang Bai wrote: > > > > > > On some GEN9 platforms, slowly unplugging (wiggling) the HDMI > > > > > > cable makes the kernel to believe the HDMI display is still > > > > > > connected. This is because the HDMI DDC lines are > > > > > > disconnected a little bit later after the hot-plug interrupt > > > > > > triggered thus an immediate edid fetch can be made. This > > > > > > problem has been identified by more than one customer > > > > > > recently. Use digital port live states to authorize the edid > > > > > > read at HDMI detection point will ensure most of the display > > > > > > related software states updated and rest of them will be > > > > > > renewed accordingly when the port is connected. > > > > > > > > > > > > v2: Fix the formatting issue > > > > > > v3: Use digital port states to authorize the edid read > > > > > > v4: Add comments on issue histories and rationale of the fix > > > > > > (Chris W) > > > > > > > > > > You're not answering Chris Wilson's question. > > > > > > > > > > Why do you think the problems we've historically had with live > > > > > status are no longer a problem? We've tried and reverted live > > > > > status checks at least twice before because of regressions. Why > > > > > do you think this time there won't be regressions? Why do you > > > > > think this patch makes forward progress? > > > > Jani, > > > > I'm still new to kernel developments compared with all of you > > > > working in this area for many years - Haven't got any feedbacks > > > > on how exactly the HDMI live statue *not* fit for HDMI hot-plug > > > > related port status checking, neither had time to track all > > > > upstream bugzilla, plus not working directly with Intel OTC teams > > > > - What are those failing cases/regressions you mentioned above? > > > > - what were the kernel versions related with those developments? > > > > - Given the fact i915 architecture and implementation are > > > > constantly evolving - Should we re-visit those issues with > > > > current kernel implementation? > > > > - Fundamentally, do you think the edid fetch is still *valid* > > > > when the HDMI is unplugged (status either from PCH or DE)? Or > > > > other platform configurations may present more complexities such > > > > as kvm switches are used along with HDMI? > > > > Again, if you could provide me more historical issue details, I'd > > > > like to have some reviews/re-investigation for those cases with > > > > current 4.20 kernel. > > > > Thanks, > > > > -Guang > > > > > > Hi Jani, > > > I don't know the history and what kind of painful regression > > > that you had run into. Could you maybe provide a test plan or some > > > test cases for the regression verification? I can follow steps to > > > try to verify whether if the patch can work on all cases. > > > > > > Chris > > > > > > > > > > > > > I've *repeatedly* said from the beginning that I am very > > > > > sceptical of using live status because we've been burned by it > > > > > so many times before. I don't much care to repeat this anymore. > > > > > > > > > > > > > > > BR, > > > > > Jani. > > > > > > > > > > > > > > > > > > > > > &
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)
Happy New Year. Sorry for bothering you guys again, I don't really want to make myself a nuisance. Is there any better idea for fixing this issue? Chris On Mon, Dec 3, 2018 at 6:38 PM Chris Chiu wrote: > > On Fri, Nov 30, 2018 at 1:15 AM Guang Bai wrote: > > > > On Thu, 29 Nov 2018 10:17:49 +0200 > > Jani Nikula wrote: > > > > > On Wed, 28 Nov 2018, Guang Bai wrote: > > > > On some GEN9 platforms, slowly unplugging (wiggling) the HDMI cable > > > > makes the kernel to believe the HDMI display is still connected. > > > > This is because the HDMI DDC lines are disconnected a little bit > > > > later after the hot-plug interrupt triggered thus an immediate edid > > > > fetch can be made. This problem has been identified by more than > > > > one customer recently. Use digital port live states to authorize > > > > the edid read at HDMI detection point will ensure most of the > > > > display related software states updated and rest of them will be > > > > renewed accordingly when the port is connected. > > > > > > > > v2: Fix the formatting issue > > > > v3: Use digital port states to authorize the edid read > > > > v4: Add comments on issue histories and rationale of the fix (Chris > > > > W) > > > > > > You're not answering Chris Wilson's question. > > > > > > Why do you think the problems we've historically had with live status > > > are no longer a problem? We've tried and reverted live status checks > > > at least twice before because of regressions. Why do you think this > > > time there won't be regressions? Why do you think this patch makes > > > forward progress? > > Jani, > > I'm still new to kernel developments compared with all of you working > > in this area for many years - Haven't got any feedbacks on how > > exactly the HDMI live statue *not* fit for HDMI hot-plug related port > > status checking, neither had time to track all upstream bugzilla, plus > > not working directly with Intel OTC teams > > - What are those failing cases/regressions you mentioned above? > > - what were the kernel versions related with those developments? > > - Given the fact i915 architecture and implementation are constantly > > evolving - Should we re-visit those issues with current kernel > > implementation? > > - Fundamentally, do you think the edid fetch is still *valid* when the > > HDMI is unplugged (status either from PCH or DE)? Or other platform > > configurations may present more complexities such as kvm switches are > > used along with HDMI? > > Again, if you could provide me more historical issue details, I'd like > > to have some reviews/re-investigation for those cases with current 4.20 > > kernel. > > Thanks, > > -Guang > > Hi Jani, > I don't know the history and what kind of painful regression that you > had run into. Could you maybe provide a test plan or some test cases > for the regression verification? I can follow steps to try to verify whether > if the patch can work on all cases. > > Chris > > > > > > > I've *repeatedly* said from the beginning that I am very sceptical of > > > using live status because we've been burned by it so many times > > > before. I don't much care to repeat this anymore. > > > > > > > > > BR, > > > Jani. > > > > > > > > > > > > > > Cc: Jani Nikula > > > > Cc: Chris Chiu > > > > Cc: Chris Wilson > > > > Signed-off-by: Guang Bai > > > > --- > > > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > > > b/drivers/gpu/drm/i915/intel_hdmi.c index e2c6a2b..8cf7c78 100644 > > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > > > @@ -1929,7 +1929,7 @@ intel_hdmi_detect(struct drm_connector > > > > *connector, bool force) > > > > intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS); > > > > > > > > - if (IS_ICELAKE(dev_priv) && > > > > + if ((IS_ICELAKE(dev_priv) || IS_GEN9_BC(dev_priv)) && > > > > !intel_digital_port_connected(encoder)) > > > > goto out; > > > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)
On Fri, Nov 30, 2018 at 1:15 AM Guang Bai wrote: > > On Thu, 29 Nov 2018 10:17:49 +0200 > Jani Nikula wrote: > > > On Wed, 28 Nov 2018, Guang Bai wrote: > > > On some GEN9 platforms, slowly unplugging (wiggling) the HDMI cable > > > makes the kernel to believe the HDMI display is still connected. > > > This is because the HDMI DDC lines are disconnected a little bit > > > later after the hot-plug interrupt triggered thus an immediate edid > > > fetch can be made. This problem has been identified by more than > > > one customer recently. Use digital port live states to authorize > > > the edid read at HDMI detection point will ensure most of the > > > display related software states updated and rest of them will be > > > renewed accordingly when the port is connected. > > > > > > v2: Fix the formatting issue > > > v3: Use digital port states to authorize the edid read > > > v4: Add comments on issue histories and rationale of the fix (Chris > > > W) > > > > You're not answering Chris Wilson's question. > > > > Why do you think the problems we've historically had with live status > > are no longer a problem? We've tried and reverted live status checks > > at least twice before because of regressions. Why do you think this > > time there won't be regressions? Why do you think this patch makes > > forward progress? > Jani, > I'm still new to kernel developments compared with all of you working > in this area for many years - Haven't got any feedbacks on how > exactly the HDMI live statue *not* fit for HDMI hot-plug related port > status checking, neither had time to track all upstream bugzilla, plus > not working directly with Intel OTC teams > - What are those failing cases/regressions you mentioned above? > - what were the kernel versions related with those developments? > - Given the fact i915 architecture and implementation are constantly > evolving - Should we re-visit those issues with current kernel > implementation? > - Fundamentally, do you think the edid fetch is still *valid* when the > HDMI is unplugged (status either from PCH or DE)? Or other platform > configurations may present more complexities such as kvm switches are > used along with HDMI? > Again, if you could provide me more historical issue details, I'd like > to have some reviews/re-investigation for those cases with current 4.20 > kernel. > Thanks, > -Guang Hi Jani, I don't know the history and what kind of painful regression that you had run into. Could you maybe provide a test plan or some test cases for the regression verification? I can follow steps to try to verify whether if the patch can work on all cases. Chris > > > > I've *repeatedly* said from the beginning that I am very sceptical of > > using live status because we've been burned by it so many times > > before. I don't much care to repeat this anymore. > > > > > > BR, > > Jani. > > > > > > > > > > Cc: Jani Nikula > > > Cc: Chris Chiu > > > Cc: Chris Wilson > > > Signed-off-by: Guang Bai > > > --- > > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > > b/drivers/gpu/drm/i915/intel_hdmi.c index e2c6a2b..8cf7c78 100644 > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > > @@ -1929,7 +1929,7 @@ intel_hdmi_detect(struct drm_connector > > > *connector, bool force) > > > intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS); > > > > > > - if (IS_ICELAKE(dev_priv) && > > > + if ((IS_ICELAKE(dev_priv) || IS_GEN9_BC(dev_priv)) && > > > !intel_digital_port_connected(encoder)) > > > goto out; > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)
On Thu, Nov 29, 2018 at 9:52 AM Guang Bai wrote: > On some GEN9 platforms, slowly unplugging (wiggling) the HDMI cable makes > the kernel to believe the HDMI display is still connected. This is because > the HDMI DDC lines are disconnected a little bit later after the hot-plug > interrupt triggered thus an immediate edid fetch can be made. This problem > has been identified by more than one customer recently. Use digital > port live states to authorize the edid read at HDMI detection point will > ensure most of the display related software states updated and rest of them > will be renewed accordingly when the port is connected. > > v2: Fix the formatting issue > v3: Use digital port states to authorize the edid read > v4: Add comments on issue histories and rationale of the fix (Chris W) > > Cc: Jani Nikula > Cc: Chris Chiu > Cc: Chris Wilson > Signed-off-by: Guang Bai > --- > drivers/gpu/drm/i915/intel_hdmi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index e2c6a2b..8cf7c78 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1929,7 +1929,7 @@ intel_hdmi_detect(struct drm_connector *connector, > bool force) > > intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS); > > - if (IS_ICELAKE(dev_priv) && > + if ((IS_ICELAKE(dev_priv) || IS_GEN9_BC(dev_priv)) && > !intel_digital_port_connected(encoder)) > goto out; > > -- > 2.7.4 > > I've tried on my problematic ASUS X705FD, seems no problem on my test scenarios (100% pass). I can reproduce with very slow unplug on previous versions but can't reproduce anymore on this one. I tried slow unplgug with few finds of HDMI jack I have in hand, it responds as expected. Don't know if there's any tough test case I should try, but I think it pretty much solve the problem. Thanks. Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v2)
On Tue, Nov 13, 2018 at 1:18 PM Guang Bai wrote: > On Tue, 13 Nov 2018 09:04:37 +0800 > Chris Chiu wrote: > > > Gentle ping. Just want to know if you have time for this so far. > > Thanks > > > > Chris > Actually I'm still working on it right now with > DRM_MODE_CONNECTOR_HDMIA/HDMIB, recommended by James, I'm able to > differentiate the HDMI or DP even the encoder type is the > "INTEL_OUTPUT_DDI", I still have the "trybot" intermittent test failures > with new DRM connector types. Even worse, there is phantom > "intel_encoder_hotplug()" call following the correct one: > When connecting both DP and HDMI on the platform, unplug the DP, the > "i915_hotplug_work_func()" first calls the "intel_encoder_hotplug()" > with DP encoder, then calls again with HDMI encoder. > I haven't identified if the work function get queued twice or itself > is incorrectly identifying wrong encoder hotplut status. Will try to > get everything cleaned up ASAP. > Thanks, > Guang > > > > Anything I can help? Maybe test in a more complicated use case? I have lots of different laptops/AIOs/Desktops if you need. Chris > On Tue, Oct 30, 2018 at 1:24 AM Guang Bai wrote: > > > > > On Tue, 23 Oct 2018 17:14:34 +0800 > > > Chris Chiu wrote: > > > > > > > On Thu, Oct 11, 2018 at 2:04 AM Guang Bai > > > > wrote: > > > > > On Mon, 8 Oct 2018 08:56:20 -0700 > > > > > Guang Bai wrote: > > > > > > > > > > > On Mon, 8 Oct 2018 22:35:34 +0800 > > > > > > Chris Chiu wrote: > > > > > > > > > > > > > Thanks! I have no problem with this patch. > > > > > > > > > > > > There are Fi.CI.BAT failures with the v2 (only with > > > > > > formatting fix added) while the previous patch had passing > > > > > > results. Now trying to identify why the failures happened > > > > > > with trybot Thanks, > > > > > > Guang > > > > > The tribot run my patch twice and passes the tests without any > > > > > error however I'm recommended to chase down root causes of > > > > > Patchwork Fi.CI.BAT test errors still - WIP on that. > > > > > Thanks, > > > > > Guang > > > > > > > > > > > > > Gentle ping. Any good news on this? > > > > > > > > Chris > > > > > > > Sorry...was distracted by other dev taks...will get update ASAP. > > > -Guang > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 4, 2018 at 2:08 AM Guang Bai > > > > > > > wrote: > > > > > > > > On some platforms, slowly unplugging (wiggling) the HDMI > > > > > > > > cable makes the kernel to believe the HDMI display still > > > > > > > > connected. This is because the HDMI DDC lines are > > > > > > > > disconnected sometimes later after the hot-plug interrupt > > > > > > > > triggered. Use the hot plug live states to honor HDMI hot > > > > > > > > plug status in addtion to access the DDC channels. > > > > > > > > > > > > > > > > v2: Fix the formatting issue > > > > > > > > > > > > > > > > Cc: Jani Nikula > > > > > > > > Cc: Chris Chiu > > > > > > > > Signed-off-by: Guang Bai > > > > > > > > --- > > > > > > > > drivers/gpu/drm/i915/intel_hotplug.c | 32 > > > > > > > > +--- 1 file changed, 29 > > > > > > > > insertions(+), 3 deletions(-) > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c > > > > > > > > b/drivers/gpu/drm/i915/intel_hotplug.c > > > > > > > > index 648a13c..98ab1ab 100644 > > > > > > > > --- a/drivers/gpu/drm/i915/intel_hotplug.c > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_hotplug.c > > > > > > > > @@ -246,17 +246,43 @@ static void > > > > > > > > intel_hpd_irq_storm_reenable_work(struct work_struct > > > > > > > > *work) intel_runtime_pm_put(dev_priv); > > > > > > > > } > > > > > > > > > > &
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v2)
Gentle ping. Just want to know if you have time for this so far. Thanks
Chris
On Tue, Oct 30, 2018 at 1:24 AM Guang Bai wrote:
> On Tue, 23 Oct 2018 17:14:34 +0800
> Chris Chiu wrote:
>
> > On Thu, Oct 11, 2018 at 2:04 AM Guang Bai wrote:
> >
> > > On Mon, 8 Oct 2018 08:56:20 -0700
> > > Guang Bai wrote:
> > >
> > > > On Mon, 8 Oct 2018 22:35:34 +0800
> > > > Chris Chiu wrote:
> > > >
> > > > > Thanks! I have no problem with this patch.
> > > >
> > > > There are Fi.CI.BAT failures with the v2 (only with formatting fix
> > > > added) while the previous patch had passing results.
> > > > Now trying to identify why the failures happened with trybot
> > > > Thanks,
> > > > Guang
> > > The tribot run my patch twice and passes the tests without any error
> > > however I'm recommended to chase down root causes of Patchwork
> > > Fi.CI.BAT test errors still - WIP on that.
> > > Thanks,
> > > Guang
> > >
> >
> > Gentle ping. Any good news on this?
> >
> > Chris
> >
> Sorry...was distracted by other dev taks...will get update ASAP.
> -Guang
> >
> > > >
> > > > >
> > > > > On Thu, Oct 4, 2018 at 2:08 AM Guang Bai
> > > > > wrote:
> > > > > > On some platforms, slowly unplugging (wiggling) the HDMI cable
> > > > > > makes the kernel to believe the HDMI display still connected.
> > > > > > This is because the HDMI DDC lines are disconnected sometimes
> > > > > > later after the hot-plug interrupt triggered. Use the hot plug
> > > > > > live states to honor HDMI hot plug status in addtion to access
> > > > > > the DDC channels.
> > > > > >
> > > > > > v2: Fix the formatting issue
> > > > > >
> > > > > > Cc: Jani Nikula
> > > > > > Cc: Chris Chiu
> > > > > > Signed-off-by: Guang Bai
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/intel_hotplug.c | 32
> > > > > > +--- 1 file changed, 29
> > > > > > insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > > > > > b/drivers/gpu/drm/i915/intel_hotplug.c
> > > > > > index 648a13c..98ab1ab 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > > > > > @@ -246,17 +246,43 @@ static void
> > > > > > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > > > > > intel_runtime_pm_put(dev_priv);
> > > > > > }
> > > > > >
> > > > > > +#define MAX_SHORT_PULSE_MS 100
> > > > > > +#define PORT_CHECK_LOOP_COUNT 3
> > > > > > +
> > > > > > bool intel_encoder_hotplug(struct intel_encoder *encoder,
> > > > > >struct intel_connector *connector)
> > > > > > {
> > > > > > struct drm_device *dev = connector->base.dev;
> > > > > > - enum drm_connector_status old_status;
> > > > > > + enum drm_connector_status old_status, new_status;
> > > > > > + enum hpd_pin pin = encoder->hpd_pin;
> > > > > > + struct drm_i915_private *dev_priv =
> > > > > > to_i915(encoder->base.dev);
> > > > > > + u32 count = 0;
> > > > > >
> > > > > > WARN_ON(!mutex_is_locked(>mode_config.mutex));
> > > > > > old_status = connector->base.status;
> > > > > >
> > > > > > - connector->base.status =
> > > > > > - drm_helper_probe_detect(>base,
> > > > > > NULL, false);
> > > > > > + /*
> > > > > > +* Set HDMI connection status based on hot-plug live
> > > > > > states and
> > > > > > +* display probe results.
> > > > > > +*/
> > > > > > + if ((encoder->type == INTEL_OUTPUT_HDMI ||
> > > > > > +encoder->type == INTEL_OUTPUT_DDI) &&
> > > > &
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v2)
On Thu, Oct 11, 2018 at 2:04 AM Guang Bai wrote:
> On Mon, 8 Oct 2018 08:56:20 -0700
> Guang Bai wrote:
>
> > On Mon, 8 Oct 2018 22:35:34 +0800
> > Chris Chiu wrote:
> >
> > > Thanks! I have no problem with this patch.
> >
> > There are Fi.CI.BAT failures with the v2 (only with formatting fix
> > added) while the previous patch had passing results.
> > Now trying to identify why the failures happened with trybot
> > Thanks,
> > Guang
> The tribot run my patch twice and passes the tests without any error
> however I'm recommended to chase down root causes of Patchwork Fi.CI.BAT
> test errors still - WIP on that.
> Thanks,
> Guang
>
Gentle ping. Any good news on this?
Chris
> >
> > >
> > > On Thu, Oct 4, 2018 at 2:08 AM Guang Bai
> > > wrote:
> > > > On some platforms, slowly unplugging (wiggling) the HDMI cable
> > > > makes the kernel to believe the HDMI display still connected.
> > > > This is because the HDMI DDC lines are disconnected sometimes
> > > > later after the hot-plug interrupt triggered. Use the hot plug
> > > > live states to honor HDMI hot plug status in addtion to access
> > > > the DDC channels.
> > > >
> > > > v2: Fix the formatting issue
> > > >
> > > > Cc: Jani Nikula
> > > > Cc: Chris Chiu
> > > > Signed-off-by: Guang Bai
> > > > ---
> > > > drivers/gpu/drm/i915/intel_hotplug.c | 32
> > > > +--- 1 file changed, 29 insertions(+),
> > > > 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > > > b/drivers/gpu/drm/i915/intel_hotplug.c
> > > > index 648a13c..98ab1ab 100644
> > > > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > > > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > > > @@ -246,17 +246,43 @@ static void
> > > > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > > > intel_runtime_pm_put(dev_priv);
> > > > }
> > > >
> > > > +#define MAX_SHORT_PULSE_MS 100
> > > > +#define PORT_CHECK_LOOP_COUNT 3
> > > > +
> > > > bool intel_encoder_hotplug(struct intel_encoder *encoder,
> > > >struct intel_connector *connector)
> > > > {
> > > > struct drm_device *dev = connector->base.dev;
> > > > - enum drm_connector_status old_status;
> > > > + enum drm_connector_status old_status, new_status;
> > > > + enum hpd_pin pin = encoder->hpd_pin;
> > > > + struct drm_i915_private *dev_priv =
> > > > to_i915(encoder->base.dev);
> > > > + u32 count = 0;
> > > >
> > > > WARN_ON(!mutex_is_locked(>mode_config.mutex));
> > > > old_status = connector->base.status;
> > > >
> > > > - connector->base.status =
> > > > - drm_helper_probe_detect(>base, NULL,
> > > > false);
> > > > + /*
> > > > +* Set HDMI connection status based on hot-plug live
> > > > states and
> > > > +* display probe results.
> > > > +*/
> > > > + if ((encoder->type == INTEL_OUTPUT_HDMI ||
> > > > +encoder->type == INTEL_OUTPUT_DDI) &&
> > > > + dev_priv->hotplug.stats[pin].state == HPD_ENABLED) {
> > > > + do {
> > > > + new_status =
> > > > connector_status_disconnected;
> > > > + msleep(MAX_SHORT_PULSE_MS);
> > > > +
> > > > + if (intel_digital_port_connected(encoder))
> > > > + new_status =
> > > > drm_helper_probe_detect(>base,
> > > > +
> > > > NULL, false);
> > > > + if (new_status ==
> > > > connector_status_connected)
> > > > + break;
> > > > + } while (++count <= PORT_CHECK_LOOP_COUNT);
> > > > + connector->base.status = new_status;
> > > > + } else {
> > > > + connector->base.status =
> > > > + drm_helper_probe_detect(>base,
> > > > NULL, false);
> > > > + }
> > > >
> > > > if (old_status == connector->base.status)
> > > > return false;
> > > > --
> > > > 2.7.4
> > > >
> > > >
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v2)
Thanks! I have no problem with this patch.
On Thu, Oct 4, 2018 at 2:08 AM Guang Bai wrote:
> On some platforms, slowly unplugging (wiggling) the HDMI cable makes
> the kernel to believe the HDMI display still connected. This is because
> the HDMI DDC lines are disconnected sometimes later after the hot-plug
> interrupt triggered. Use the hot plug live states to honor HDMI hot plug
> status in addtion to access the DDC channels.
>
> v2: Fix the formatting issue
>
> Cc: Jani Nikula
> Cc: Chris Chiu
> Signed-off-by: Guang Bai
> ---
> drivers/gpu/drm/i915/intel_hotplug.c | 32 +---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 648a13c..98ab1ab 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -246,17 +246,43 @@ static void intel_hpd_irq_storm_reenable_work(struct
> work_struct *work)
> intel_runtime_pm_put(dev_priv);
> }
>
> +#define MAX_SHORT_PULSE_MS 100
> +#define PORT_CHECK_LOOP_COUNT 3
> +
> bool intel_encoder_hotplug(struct intel_encoder *encoder,
>struct intel_connector *connector)
> {
> struct drm_device *dev = connector->base.dev;
> - enum drm_connector_status old_status;
> + enum drm_connector_status old_status, new_status;
> + enum hpd_pin pin = encoder->hpd_pin;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + u32 count = 0;
>
> WARN_ON(!mutex_is_locked(>mode_config.mutex));
> old_status = connector->base.status;
>
> - connector->base.status =
> - drm_helper_probe_detect(>base, NULL, false);
> + /*
> +* Set HDMI connection status based on hot-plug live states and
> +* display probe results.
> +*/
> + if ((encoder->type == INTEL_OUTPUT_HDMI ||
> +encoder->type == INTEL_OUTPUT_DDI) &&
> + dev_priv->hotplug.stats[pin].state == HPD_ENABLED) {
> + do {
> + new_status = connector_status_disconnected;
> + msleep(MAX_SHORT_PULSE_MS);
> +
> + if (intel_digital_port_connected(encoder))
> + new_status =
> drm_helper_probe_detect(>base,
> +NULL,
> false);
> + if (new_status == connector_status_connected)
> + break;
> + } while (++count <= PORT_CHECK_LOOP_COUNT);
> + connector->base.status = new_status;
> + } else {
> + connector->base.status =
> + drm_helper_probe_detect(>base, NULL,
> false);
> + }
>
> if (old_status == connector->base.status)
> return false;
> --
> 2.7.4
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure
It works on my problematic laptops. Verified on X530UN and X560UD.
On Wed, Oct 3, 2018 at 1:23 PM Guang Bai wrote:
>
> On some platforms, slowly unplugging (wiggling) the HDMI cable makes
> the kernel to believe the HDMI display still connected. This is because
> the HDMI DDC lines are disconnected sometimes later after the hot-plug
> interrupt triggered. Use the hot plug live states to honor HDMI hot plug
> status in addtion to access the DDC channels.
>
> Cc: Jani Nikula
> Cc: Chris Chiu
> Signed-off-by: Guang Bai
> ---
> drivers/gpu/drm/i915/intel_hotplug.c | 31 ---
> 1 file changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 648a13c..db6288f 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -246,17 +246,42 @@ static void intel_hpd_irq_storm_reenable_work(struct
> work_struct *work)
> intel_runtime_pm_put(dev_priv);
> }
>
> +#define MAX_SHORT_PULSE_MS 100
> +#define PORT_CHECK_LOOP_COUNT 3
> +
> bool intel_encoder_hotplug(struct intel_encoder *encoder,
>struct intel_connector *connector)
> {
> struct drm_device *dev = connector->base.dev;
> - enum drm_connector_status old_status;
> + enum drm_connector_status old_status, new_status;
> + enum hpd_pin pin = encoder->hpd_pin;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + u32 count = 0;
>
> WARN_ON(!mutex_is_locked(>mode_config.mutex));
> old_status = connector->base.status;
>
> - connector->base.status =
> - drm_helper_probe_detect(>base, NULL, false);
> + /*
> +* Set HDMI connection status based on hot-plug live states and
> +* display probe results.
> +*/
> + if ((encoder->type == INTEL_OUTPUT_HDMI ||
> +encoder->type == INTEL_OUTPUT_DDI) &&
> + dev_priv->hotplug.stats[pin].state == HPD_ENABLED) {
> + do {
> + new_status = connector_status_disconnected;
> + msleep(MAX_SHORT_PULSE_MS);
> +
> + if (intel_digital_port_connected(encoder))
> + new_status =
> drm_helper_probe_detect(>base,
> +NULL,
> false);
> + if (new_status == connector_status_connected)
> + break;
> + } while (++count <= PORT_CHECK_LOOP_COUNT);
> + connector->base.status = new_status;
> + } else
> + connector->base.status =
> + drm_helper_probe_detect(>base, NULL,
> false);
>
> if (old_status == connector->base.status)
> return false;
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
On Wed, Sep 19, 2018 at 8:08 PM, Jani Nikula wrote:
> On Wed, 19 Sep 2018, Chris Chiu wrote:
>> I tried to add a slight delay in the hotplug work as follows
>>
>> --- a/drivers/gpu/drm/i915/intel_hotplug.c
>> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
>> @@ -378,6 +378,8 @@ static void do_i915_hotplug_check(struct work_struct
>> *work,
>>
>> spin_unlock_irq(_priv->irq_lock);
>>
>> + msleep(100);
>> +
>> drm_connector_list_iter_begin(dev, _iter);
>> drm_for_each_connector_iter(connector, _iter) {
>> intel_connector = to_intel_connector(connector);
>>
>> It does work in most cases, but still fail to update the status if I
>> unplug the HDMI
>> cable very slow. I basically pull the HDMI cable in loose connected
>> state first, and
>> hold in that state ~1 second, totally unplug after that. The status in
>> sysfs will report
>> connected as it used to. There was no problem when I tried the patch
>> https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8
>>
>> I'll try to modify this patch a little bit and send upstream for
>> discussion later. Please
>> advise if any. Thanks.
>
> Please let's not add excessive msleeps in work functions.
>
> My idea was more along the lines of making the hotplug function run in a
> delayed work. After a chat with Ville, below is what I came up with.
>
> Please let me know how it works. Feel free to toy with the
> delay. However, 1-2 seconds or more seems too much.
>
> BR,
> Jani.
>
Thanks to the patch. It works in most cases on my problematic laptops.
After lots
of experiments, ex. pull the cable out with different paces, range
delay from 300 to
800 msec, it makes no significant difference for a longer delay. So
300 msec is good
enough for most cases. It at least updates the status correctly with a
visible quick
display blink when disconnecting HDMI. And compared to other machines which have
no such problem, the HDMI cable slow pull out also result in the same
problem. I'll
say the test result is OK for me. Thanks.
Chris
>
>
> From 72515b3e856171e52e96bb74796774f595a7f418 Mon Sep 17 00:00:00 2001
> From: Jani Nikula
> Date: Tue, 18 Sep 2018 13:12:34 +0300
> Subject: [PATCH] drm/i915: delay hotplug scheduling
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> Cc: Jani Nikula
>
> On some systems we get the hotplug irq on unplug before the DDC pins
> have been disconnected, resulting in connector status remaining
> connected. Since previous attempts at using hotplug live status before
> DDC have failed, the only viable option is to reduce the window for
> mistakes. Delay the hotplug processing.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_hotplug.c | 15 ++-
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7d4daa7412f1..27f579abddae 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -286,7 +286,7 @@ enum hpd_pin {
> #define HPD_STORM_DEFAULT_THRESHOLD 5
>
> struct i915_hotplug {
> - struct work_struct hotplug_work;
> + struct delayed_work hotplug_work;
>
> struct {
> unsigned long last_jiffies;
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 648a13c6043c..3af64daa5cfc 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -110,6 +110,8 @@ enum hpd_pin intel_hpd_pin_default(struct
> drm_i915_private *dev_priv,
> }
> }
>
> +#define HOTPLUG_DELAY_MS 300
> +
> #define HPD_STORM_DETECT_PERIOD1000
> #define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000)
>
> @@ -319,7 +321,8 @@ static void i915_digport_work_func(struct work_struct
> *work)
> spin_lock_irq(_priv->irq_lock);
> dev_priv->hotplug.event_bits |= old_bits;
> spin_unlock_irq(_priv->irq_lock);
> - schedule_work(_priv->hotplug.hotplug_work);
> + schedule_delayed_work(_priv->hotplug.hotplug_work,
> + msecs_to_jiffies(HOTPLUG_DELAY_MS));
> }
> }
>
> @@ -329,7 +332,7 @@ static void i915_digport_work_func(struct work_struct
> *work)
> static void i915_hotplug_work_func(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv =
> - container_of(work, struct drm_i915_private,
> hotplug.hotplug
[Intel-gfx] [PATCH] drm/i915: re-check the hotplug with a delayed work
I have few ASUS laptops, X705FD(Intel i7-8565), X560UD(Intel i5-8250U)
and X530UN(Intel i7-8550U) share the same problem. The HDMI connector
status stays 'connected' even the HDMI cable has been unplugged.
Then the status in sysfs would never change since then until we
do 'xrandr' to reprobe the devices. It would also cause the audio
output path cannot correctly swicth based on the connector status.
This commit kicks off a delayed work when the status remains unchanged
in the first hotplug event handling, which may not be the perfect
timing in some special cases.
Signed-off-by: Chris Chiu
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_hotplug.c | 35 +++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d51d8574a679..78e2cf09cc10 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -286,6 +286,7 @@ struct i915_hotplug {
} stats[HPD_NUM_PINS];
u32 event_bits;
struct delayed_work reenable_work;
+ struct delayed_work recheck_work;
struct intel_digital_port *irq_port[I915_MAX_PORTS];
u32 long_port_mask;
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 43aa92beff2a..089a24588ec8 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -349,14 +349,15 @@ static void i915_digport_work_func(struct work_struct
*work)
}
}
+#define HPD_RECHECK_DELAY(2 * 1000)
+
/*
* Handle hotplug events outside the interrupt handler proper.
*/
-static void i915_hotplug_work_func(struct work_struct *work)
+static void do_i915_hotplug_check(struct work_struct *work,
+ struct drm_i915_private *dev_priv,
+ struct drm_device *dev, bool do_recheck)
{
- struct drm_i915_private *dev_priv =
- container_of(work, struct drm_i915_private,
hotplug.hotplug_work);
- struct drm_device *dev = _priv->drm;
struct intel_connector *intel_connector;
struct intel_encoder *intel_encoder;
struct drm_connector *connector;
@@ -396,8 +397,31 @@ static void i915_hotplug_work_func(struct work_struct
*work)
if (changed)
drm_kms_helper_hotplug_event(dev);
+ else if (do_recheck) {
+ spin_lock_irq(_priv->irq_lock);
+ dev_priv->hotplug.event_bits |= hpd_event_bits;
+ spin_unlock_irq(_priv->irq_lock);
+ schedule_delayed_work(_priv->hotplug.recheck_work,
msecs_to_jiffies(HPD_RECHECK_DELAY));
+ }
}
+static void i915_hotplug_work_func(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, struct drm_i915_private,
hotplug.hotplug_work);
+ struct drm_device *dev = _priv->drm;
+
+ do_i915_hotplug_check(work, dev_priv, dev, true);
+}
+
+static void i915_hotplug_recheck_func(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, struct drm_i915_private,
hotplug.recheck_work.work);
+ struct drm_device *dev = _priv->drm;
+
+ do_i915_hotplug_check(work, dev_priv, dev, false);
+}
/**
* intel_hpd_irq_handler - main hotplug irq handler
@@ -619,6 +643,8 @@ void intel_hpd_init_work(struct drm_i915_private *dev_priv)
INIT_WORK(_priv->hotplug.poll_init_work, i915_hpd_poll_init_work);
INIT_DELAYED_WORK(_priv->hotplug.reenable_work,
intel_hpd_irq_storm_reenable_work);
+ INIT_DELAYED_WORK(_priv->hotplug.recheck_work,
+ i915_hotplug_recheck_func);
}
void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
@@ -635,6 +661,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
*dev_priv)
cancel_work_sync(_priv->hotplug.hotplug_work);
cancel_work_sync(_priv->hotplug.poll_init_work);
cancel_delayed_work_sync(_priv->hotplug.reenable_work);
+ cancel_delayed_work_sync(_priv->hotplug.recheck_work);
}
bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
On Tue, Sep 11, 2018 at 6:25 PM, Chris Chiu wrote:
> On Fri, Aug 24, 2018 at 11:04 PM, Jani Nikula wrote:
>> On Wed, 22 Aug 2018, Chris Chiu wrote:
>>> On Fri, Jul 6, 2018 at 2:44 PM, Chris Chiu wrote:
>>>> On Thu, Jul 5, 2018 at 10:40 PM, Ville Syrjälä
>>>> wrote:
>>>>> On Thu, Jul 05, 2018 at 03:58:36PM +0800, Chris Chiu wrote:
>>>>>> Hi,
>>>>>> We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel
>>>>>> i5-8250U), X530UN (intel i7-8550U) share the same problem, which is
>>>>>> the HDMI connector status stays connected even the HDMI cable has been
>>>>>> unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for
>>>>>> checking the status while plug/unplug the HDMI, it shows
>>>>>> "disconnected" before plug in HDMI cable, then switch to "connected"
>>>>>> after plugin, and still stay "connected" after unplug. This would
>>>>>> cause the audio output path cannot correctly switch from HDMI to
>>>>>> internal speaker after unplugging the HDMI.
>>>>>>
>>>>>> I then try to verify with the latest kernel 4.18.0-rc3+, the bug still
>>>>>> present. The full "dmesg" log is here.
>>>>>> https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1
>>>>>>
>>>>>> The HDMI cable is plugged in at ~26th second.
>>>>>> "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic
>>>>>> audio support"
>>>>>> then unplug the HDMI at ~73th second.
>>>>>> "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic
>>>>>> audio support"
>>>>>>
>>>>>> Please advise what I can do to fix this. Thanks
>>>>>
>>>>> Pull the cable out faster?
>>>>>
>>>>> I presume this is the same old case of hpd disconnecting slightly
>>>>> before ddc and we still manage to read the EDID when processing
>>>>> the hpd irq. We kinda tried to fix that with the live status
>>>>> check but that thing failed spectacularly.
>>>>>
>>>>> --
>>>>> Ville Syrjälä
>>>>> Intel
>>>
>>> There's a patch https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8.
>>> And I verified on the X705FD/X560UD which were easy to reproduce, the patch
>>> works as expected. Can anyone kindly give comments about this patch?
>>> We can do anything to help fix this issue upstream. Thanks
>>
>> Seems like a hack. Should look into hw based debouncing or a slight
>> delay in the hotplug work processing I think.
>>
>> BR,
>> Jani.
>>
I tried to add a slight delay in the hotplug work as follows
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -378,6 +378,8 @@ static void do_i915_hotplug_check(struct work_struct *work,
spin_unlock_irq(_priv->irq_lock);
+ msleep(100);
+
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
intel_connector = to_intel_connector(connector);
It does work in most cases, but still fail to update the status if I
unplug the HDMI
cable very slow. I basically pull the HDMI cable in loose connected
state first, and
hold in that state ~1 second, totally unplug after that. The status in
sysfs will report
connected as it used to. There was no problem when I tried the patch
https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8
I'll try to modify this patch a little bit and send upstream for
discussion later. Please
advise if any. Thanks.
Chris
> So you're suggesting to add a slight delay directly in
> i915_hotplug_work_func()?
> And any suggestion about the 'hw based' debouncing? Maybe some examples
> that I can refer to?
>
> Thanks
>
>>>
>>> Chris
>>>
>>>> Thanks for the suggestion. I tried pulling the cable out faster, the status
>>>> shows correctly. I also tried branch drm-tip of
>>>> https://cgit.freedesktop.org/drm/drm-tip
>>>> but the symptom persists.
>>>>
>>>> Anything I can help here? Or any old commit/patch I can try to do some
>>>> experiments?
>>>>
>>>> Chris
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
On Fri, Aug 24, 2018 at 11:04 PM, Jani Nikula wrote: > On Wed, 22 Aug 2018, Chris Chiu wrote: >> On Fri, Jul 6, 2018 at 2:44 PM, Chris Chiu wrote: >>> On Thu, Jul 5, 2018 at 10:40 PM, Ville Syrjälä >>> wrote: >>>> On Thu, Jul 05, 2018 at 03:58:36PM +0800, Chris Chiu wrote: >>>>> Hi, >>>>> We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel >>>>> i5-8250U), X530UN (intel i7-8550U) share the same problem, which is >>>>> the HDMI connector status stays connected even the HDMI cable has been >>>>> unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for >>>>> checking the status while plug/unplug the HDMI, it shows >>>>> "disconnected" before plug in HDMI cable, then switch to "connected" >>>>> after plugin, and still stay "connected" after unplug. This would >>>>> cause the audio output path cannot correctly switch from HDMI to >>>>> internal speaker after unplugging the HDMI. >>>>> >>>>> I then try to verify with the latest kernel 4.18.0-rc3+, the bug still >>>>> present. The full "dmesg" log is here. >>>>> https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1 >>>>> >>>>> The HDMI cable is plugged in at ~26th second. >>>>> "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>>>> audio support" >>>>> then unplug the HDMI at ~73th second. >>>>> "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>>>> audio support" >>>>> >>>>> Please advise what I can do to fix this. Thanks >>>> >>>> Pull the cable out faster? >>>> >>>> I presume this is the same old case of hpd disconnecting slightly >>>> before ddc and we still manage to read the EDID when processing >>>> the hpd irq. We kinda tried to fix that with the live status >>>> check but that thing failed spectacularly. >>>> >>>> -- >>>> Ville Syrjälä >>>> Intel >> >> There's a patch https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8. >> And I verified on the X705FD/X560UD which were easy to reproduce, the patch >> works as expected. Can anyone kindly give comments about this patch? >> We can do anything to help fix this issue upstream. Thanks > > Seems like a hack. Should look into hw based debouncing or a slight > delay in the hotplug work processing I think. > > BR, > Jani. > So you're suggesting to add a slight delay directly in i915_hotplug_work_func()? And any suggestion about the 'hw based' debouncing? Maybe some examples that I can refer to? Thanks >> >> Chris >> >>> Thanks for the suggestion. I tried pulling the cable out faster, the status >>> shows correctly. I also tried branch drm-tip of >>> https://cgit.freedesktop.org/drm/drm-tip >>> but the symptom persists. >>> >>> Anything I can help here? Or any old commit/patch I can try to do some >>> experiments? >>> >>> Chris > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
On Fri, Jul 6, 2018 at 2:44 PM, Chris Chiu wrote: > On Thu, Jul 5, 2018 at 10:40 PM, Ville Syrjälä > wrote: >> On Thu, Jul 05, 2018 at 03:58:36PM +0800, Chris Chiu wrote: >>> Hi, >>> We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel >>> i5-8250U), X530UN (intel i7-8550U) share the same problem, which is >>> the HDMI connector status stays connected even the HDMI cable has been >>> unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for >>> checking the status while plug/unplug the HDMI, it shows >>> "disconnected" before plug in HDMI cable, then switch to "connected" >>> after plugin, and still stay "connected" after unplug. This would >>> cause the audio output path cannot correctly switch from HDMI to >>> internal speaker after unplugging the HDMI. >>> >>> I then try to verify with the latest kernel 4.18.0-rc3+, the bug still >>> present. The full "dmesg" log is here. >>> https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1 >>> >>> The HDMI cable is plugged in at ~26th second. >>> "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>> audio support" >>> then unplug the HDMI at ~73th second. >>> "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>> audio support" >>> >>> Please advise what I can do to fix this. Thanks >> >> Pull the cable out faster? >> >> I presume this is the same old case of hpd disconnecting slightly >> before ddc and we still manage to read the EDID when processing >> the hpd irq. We kinda tried to fix that with the live status >> check but that thing failed spectacularly. >> >> -- >> Ville Syrjälä >> Intel There's a patch https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8. And I verified on the X705FD/X560UD which were easy to reproduce, the patch works as expected. Can anyone kindly give comments about this patch? We can do anything to help fix this issue upstream. Thanks Chris > Thanks for the suggestion. I tried pulling the cable out faster, the status > shows correctly. I also tried branch drm-tip of > https://cgit.freedesktop.org/drm/drm-tip > but the symptom persists. > > Anything I can help here? Or any old commit/patch I can try to do some > experiments? > > Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
On Thu, Jul 5, 2018 at 10:40 PM, Ville Syrjälä wrote: > On Thu, Jul 05, 2018 at 03:58:36PM +0800, Chris Chiu wrote: >> Hi, >> We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel >> i5-8250U), X530UN (intel i7-8550U) share the same problem, which is >> the HDMI connector status stays connected even the HDMI cable has been >> unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for >> checking the status while plug/unplug the HDMI, it shows >> "disconnected" before plug in HDMI cable, then switch to "connected" >> after plugin, and still stay "connected" after unplug. This would >> cause the audio output path cannot correctly switch from HDMI to >> internal speaker after unplugging the HDMI. >> >> I then try to verify with the latest kernel 4.18.0-rc3+, the bug still >> present. The full "dmesg" log is here. >> https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1 >> >> The HDMI cable is plugged in at ~26th second. >> "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >> audio support" >> then unplug the HDMI at ~73th second. >> "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >> audio support" >> >> Please advise what I can do to fix this. Thanks > > Pull the cable out faster? > > I presume this is the same old case of hpd disconnecting slightly > before ddc and we still manage to read the EDID when processing > the hpd irq. We kinda tried to fix that with the live status > check but that thing failed spectacularly. > > -- > Ville Syrjälä > Intel Thanks for the suggestion. I tried pulling the cable out faster, the status shows correctly. I also tried branch drm-tip of https://cgit.freedesktop.org/drm/drm-tip but the symptom persists. Anything I can help here? Or any old commit/patch I can try to do some experiments? Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
On Thu, Jul 5, 2018 at 9:18 PM, Jani Nikula wrote: > On Thu, 05 Jul 2018, Chris Chiu wrote: >> On Thu, Jul 5, 2018 at 5:37 PM, Jani Nikula wrote: >>> On Thu, 05 Jul 2018, Chris Wilson wrote: >>>> Quoting Jani Nikula (2018-07-05 09:58:57) >>>>> On Thu, 05 Jul 2018, Chris Chiu wrote: >>>>> > Hi, >>>>> > We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel >>>>> > i5-8250U), X530UN (intel i7-8550U) share the same problem, which is >>>>> > the HDMI connector status stays connected even the HDMI cable has been >>>>> > unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for >>>>> > checking the status while plug/unplug the HDMI, it shows >>>>> > "disconnected" before plug in HDMI cable, then switch to "connected" >>>>> > after plugin, and still stay "connected" after unplug. This would >>>>> > cause the audio output path cannot correctly switch from HDMI to >>>>> > internal speaker after unplugging the HDMI. >>>>> > >>>>> > I then try to verify with the latest kernel 4.18.0-rc3+, the bug still >>>>> > present. The full "dmesg" log is here. >>>>> > https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1 >>>>> > >>>>> > The HDMI cable is plugged in at ~26th second. >>>>> > "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>>>> > audio support" >>>>> > then unplug the HDMI at ~73th second. >>>>> > "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>>>> > audio support" >>>>> > >>>>> > Please advise what I can do to fix this. Thanks >>>>> >>>>> Seems rather odd. Please file a bug report at [1]. Attach the dmesg on >>>>> the bug. Please attach 'xrandr --verbose' output before and after >>>>> unplugging on the bug. >>>> >>>> Note that 'xrandr --verbose' will trigger a reprobe of the devices, >>>> papering over any missed probe following hotplug. I would suggest >>>> preceding with 'xrandr --current --verbose'. >>>> >>>> If all you are doing is checking status, you need to 'echo detect > >>>> status' to trigger a reprobe after hotplug. >> >> It's interesting that reprobe triggered by 'xrandr --verbose' after unplug >> will >> get the status back to "disconnected". But if I just do 'xrandr >> --current --verbose' >> before and after unplugging the cable, the output shows the same status >> 'connected'. >> >> Here's the output of 'xrandr --verbose' before unplugging HDMI >> https://gist.github.com/mschiu77/ea2e843078297f344596243418dcdaf7 >> >> And the output of 'xrandr --current --verbose' after unplugging the cable >> https://gist.github.com/mschiu77/55756c0801046d49cd9bc3f87712b079 >> >> Then do 'xrandr --current --verbose' to trigger reprobe, the ouput >> https://gist.github.com/mschiu77/72e6ab5438cbe64443300fc4fd71770c >> >> It means that the HDMI unplug not detected by the driver? > > Please do file the bug, and attach the information there. People go on > vacations, the pastebins will go away, and the memory of all of this > will fade. > Sorry that I missed to list here. I've reported the bug as follows https://bugs.freedesktop.org/show_bug.cgi?id=107125 Thanks > BR, > Jani. > >> >> Chris >> >>> >>> I was curious about the logs seemingly indicating that we can read the >>> EDID even after the user says they've unplugged the cable. The updating >>> of sysfs status attribute is another matter. >>> >>> BR, >>> Jani. >>> >>> >>> -- >>> Jani Nikula, Intel Open Source Graphics Center > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
On Thu, Jul 5, 2018 at 5:37 PM, Jani Nikula wrote: > On Thu, 05 Jul 2018, Chris Wilson wrote: >> Quoting Jani Nikula (2018-07-05 09:58:57) >>> On Thu, 05 Jul 2018, Chris Chiu wrote: >>> > Hi, >>> > We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel >>> > i5-8250U), X530UN (intel i7-8550U) share the same problem, which is >>> > the HDMI connector status stays connected even the HDMI cable has been >>> > unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for >>> > checking the status while plug/unplug the HDMI, it shows >>> > "disconnected" before plug in HDMI cable, then switch to "connected" >>> > after plugin, and still stay "connected" after unplug. This would >>> > cause the audio output path cannot correctly switch from HDMI to >>> > internal speaker after unplugging the HDMI. >>> > >>> > I then try to verify with the latest kernel 4.18.0-rc3+, the bug still >>> > present. The full "dmesg" log is here. >>> > https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1 >>> > >>> > The HDMI cable is plugged in at ~26th second. >>> > "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>> > audio support" >>> > then unplug the HDMI at ~73th second. >>> > "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic >>> > audio support" >>> > >>> > Please advise what I can do to fix this. Thanks >>> >>> Seems rather odd. Please file a bug report at [1]. Attach the dmesg on >>> the bug. Please attach 'xrandr --verbose' output before and after >>> unplugging on the bug. >> >> Note that 'xrandr --verbose' will trigger a reprobe of the devices, >> papering over any missed probe following hotplug. I would suggest >> preceding with 'xrandr --current --verbose'. >> >> If all you are doing is checking status, you need to 'echo detect > >> status' to trigger a reprobe after hotplug. It's interesting that reprobe triggered by 'xrandr --verbose' after unplug will get the status back to "disconnected". But if I just do 'xrandr --current --verbose' before and after unplugging the cable, the output shows the same status 'connected'. Here's the output of 'xrandr --verbose' before unplugging HDMI https://gist.github.com/mschiu77/ea2e843078297f344596243418dcdaf7 And the output of 'xrandr --current --verbose' after unplugging the cable https://gist.github.com/mschiu77/55756c0801046d49cd9bc3f87712b079 Then do 'xrandr --current --verbose' to trigger reprobe, the ouput https://gist.github.com/mschiu77/72e6ab5438cbe64443300fc4fd71770c It means that the HDMI unplug not detected by the driver? Chris > > I was curious about the logs seemingly indicating that we can read the > EDID even after the user says they've unplugged the cable. The updating > of sysfs status attribute is another matter. > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [BUG] i915 HDMI connector status is connected after disconnection
Hi, We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel i5-8250U), X530UN (intel i7-8550U) share the same problem, which is the HDMI connector status stays connected even the HDMI cable has been unplugged. Look into the "/sys/class/drm/card0-HDMI-A-1/status" for checking the status while plug/unplug the HDMI, it shows "disconnected" before plug in HDMI cable, then switch to "connected" after plugin, and still stay "connected" after unplug. This would cause the audio output path cannot correctly switch from HDMI to internal speaker after unplugging the HDMI. I then try to verify with the latest kernel 4.18.0-rc3+, the bug still present. The full "dmesg" log is here. https://gist.github.com/mschiu77/d761d7c5cf191b7868d4d7788ae087f1 The HDMI cable is plugged in at ~26th second. "[ 26.214371] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support" then unplug the HDMI at ~73th second. "[ 73.328361] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support" Please advise what I can do to fix this. Thanks Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] GemniLake laptops goes power off directly after performing suspend
On Tue, Dec 12, 2017 at 9:32 PM, Imre Deak <imre.d...@intel.com> wrote: > On Fri, Dec 08, 2017 at 10:31:30AM +, Daniel Drake wrote: >> Hi, >> >> Adding intel-gfx list in case i915 developers can help. Updated summary >> below. >> >> On Thu, Dec 7, 2017 at 2:14 AM, Chris Chiu <c...@endlessm.com> wrote: >> > On Wed, Dec 6, 2017 at 9:34 PM, Rafael J. Wysocki <raf...@kernel.org> >> > wrote: >> > > On Wed, Dec 6, 2017 at 10:33 AM, Chris Chiu <c...@endlessm.com> wrote: >> > >> On Wed, Dec 6, 2017 at 5:56 AM, Rafael J. Wysocki <r...@rjwysocki.net> >> > >> wrote: >> > >>> On Tuesday, December 5, 2017 5:19:03 PM CET Chris Chiu wrote: >> > >>>> On Tue, Dec 5, 2017 at 11:01 PM, Rafael J. Wysocki >> > >>>> <raf...@kernel.org> wrote: >> > >>>> > On Tue, Dec 5, 2017 at 11:32 AM, Chris Chiu <c...@endlessm.com> >> > >>>> > wrote: >> > >>>> >> I have 2 GemniLake laptops from ASUS, named X441MB and X507MA, >> > >>>> >> both go power off after I do "systemctl suspend" on top of kerne >> > >>>> >> head >> > >>>> >> fd6d2e506ce6 (Merge tag 'docs-4.15-fixes' of >> > >>>> >> git://git.lwn.net/linux). >> > >>>> >> I then wipe it out and install Windows RS3 instead, also goes to >> > >>>> >> power >> > >>>> >> off after pressing media key for suspend(S3). Then I installed >> > >>>> >> intel >> > >>>> >> graphic driver with the following version number, Windows has no >> > >>>> >> problem on suspend resume then. >> > >>>> > >> > >>>> > There is a suspend-related fix missing in 4.15-rc at this point, so >> > >>>> > please test 4.14.y or wait for the fix to be merged. >> > >>>> >> > >>>> You mean the suspend-related fix used to exist in 4.14? Could you >> > >>>> point me >> > >>>> out which commit it is? Thanks >> > >>> >> > >>> I mean that suspend generally works in 4.14 and is currently broken >> > >>> in 4.15-rc which requires a fix to be applied. The fix in question is >> > >>> at: >> > >>> https://lkml.org/lkml/2017/11/30/546 >> > >>> This is needed due to some changes made in 4.15-rc (with respect to >> > >>> 4.14) >> > >>> that broke resume from suspend to RAM. >> > >> >> > >> I think maybe for GemniLake is a different issue. I tried >> > >> Ubuntu-4.14.0-11.13 >> > >> kernel and 4.13 kernel. Both go power off immediately. >> > > >> > > OK, so yes, this is a different issue. >> > > Is that suspend-to-idle or suspend-to-RAM (ACPI S3)? >> > >> > It's ACPI S3, suspend-to RAM. Due to it power off immediately, >> > difficult for me to collect useful information >> >> Multiple new Acer and Asus consumer products based on Intel GeminiLake >> N4100/N5000 fail to go into S3 suspend-to-RAM. At the point when you >> would normally expect the system to go into sleep, the computer >> completely powers off. >> >> The same happens under Windows 10 RS3, until the following Intel >> graphics driver is installed: >> >> Package: 530967 >> Intel(R) Graphics Driver: 23.20.16.4849 >> Intel(R) Display Audio Driver: 10.00.00.1 >> >> After installing this driver, Windows can now go into S3 suspend and >> also be resumed. I'm wondering if someone can check with the Windows >> gfx driver developers what this driver does to affect S3 suspend, so >> that we can fix up Linux behaviour. > > To check this from the GFX side, could you open a bug at [1]? Please try > suspend/resume without the graphics driver loaded (booting with > nomodeset) and if that works suspend/resume with first setting one of > the test phases in /sys/power/state. Trying the drm-tip branch from [2] > would be also helpful. Please provide the dmesg logs at each run when > GFX is enabled, booting with drm.debug=0xe. Using netconsole or > pstore could help gathering the log when the machine just powers off. > > Thanks, > Imre > > [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI > [2] git://anongit.freedesktop.org/drm-tip > > >> >> Thanks >> Daniel >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx Hi Imre, Thanks for your feedback. I've opened a bug on https://bugs.freedesktop.org/show_bug.cgi?id=104235 and attach a dmesg log which shows the Linux does go into sleep while booting with "nomodeset". I will try drm-tip then and update the ticket if anything interesting Chris. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
