[PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v3)

[PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v3)

[Guang Bai]

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. Use digital
port live states to authorize the edid read.

v2: Fix the formatting issue
v3: Use digital port states to authorize the edid read

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Guang Bai <guang.bai@intel.com>
---
 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 e2c6a2b3e8f2..8cf7c78b8cdd 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.17.1

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

Re: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v3)

[Chris Wilson]

Quoting Guang Bai (2018-11-28 21:18:13)
> 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. Use digital
> port live states to authorize the edid read.

You should at least comment upon why we don't historically do this and
why you now believe that it is safe.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Guang Bai]

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 <jani.nikula@intel.com>
Cc: Chris Chiu <chiu@endlessm.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Guang Bai <guang.bai@intel.com>
---
 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

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

Re: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Jani Nikula]

On Wed, 28 Nov 2018, Guang Bai <guang.bai@intel.com> 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?

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 <jani.nikula@intel.com>
> Cc: Chris Chiu <chiu@endlessm.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Guang Bai <guang.bai@intel.com>
> ---
>  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;

-- 
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: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Guang Bai]

On Thu, 29 Nov 2018 10:17:49 +0200
Jani Nikula <jani.nikula@intel.com> wrote:

> On Wed, 28 Nov 2018, Guang Bai <guang.bai@intel.com> 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
> 
> 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 <jani.nikula@intel.com>
> > Cc: Chris Chiu <chiu@endlessm.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Guang Bai <guang.bai@intel.com>
> > ---
> >  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: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Chris Chiu]

On Fri, Nov 30, 2018 at 1:15 AM Guang Bai <guang.bai@intel.com> wrote:
>
> On Thu, 29 Nov 2018 10:17:49 +0200
> Jani Nikula <jani.nikula@intel.com> wrote:
>
> > On Wed, 28 Nov 2018, Guang Bai <guang.bai@intel.com> 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 <jani.nikula@intel.com>
> > > Cc: Chris Chiu <chiu@endlessm.com>
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Signed-off-by: Guang Bai <guang.bai@intel.com>
> > > ---
> > >  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: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Chris Chiu]

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 <chiu@endlessm.com> wrote:
>
> On Fri, Nov 30, 2018 at 1:15 AM Guang Bai <guang.bai@intel.com> wrote:
> >
> > On Thu, 29 Nov 2018 10:17:49 +0200
> > Jani Nikula <jani.nikula@intel.com> wrote:
> >
> > > On Wed, 28 Nov 2018, Guang Bai <guang.bai@intel.com> 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 <jani.nikula@intel.com>
> > > > Cc: Chris Chiu <chiu@endlessm.com>
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Signed-off-by: Guang Bai <guang.bai@intel.com>
> > > > ---
> > > >  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: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Guang Bai]

On Wed, 2 Jan 2019 17:29:46 +0800
Chris Chiu <chiu@endlessm.com> 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
> 
> Chris
> 
> On Mon, Dec 3, 2018 at 6:38 PM Chris Chiu <chiu@endlessm.com> wrote:
> >
> > On Fri, Nov 30, 2018 at 1:15 AM Guang Bai <guang.bai@intel.com>
> > wrote:  
> > >
> > > On Thu, 29 Nov 2018 10:17:49 +0200
> > > Jani Nikula <jani.nikula@intel.com> wrote:
> > >  
> > > > On Wed, 28 Nov 2018, Guang Bai <guang.bai@intel.com> 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 <jani.nikula@intel.com>
> > > > > Cc: Chris Chiu <chiu@endlessm.com>
> > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Signed-off-by: Guang Bai <guang.bai@intel.com>
> > > > > ---
> > > > >  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: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Chris Chiu]

On Thu, Jan 3, 2019 at 1:50 AM Guang Bai <guang.bai@intel.com> wrote:
>
> On Wed, 2 Jan 2019 17:29:46 +0800
> Chris Chiu <chiu@endlessm.com> 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 <chiu@endlessm.com> wrote:
> > >
> > > On Fri, Nov 30, 2018 at 1:15 AM Guang Bai <guang.bai@intel.com>
> > > wrote:
> > > >
> > > > On Thu, 29 Nov 2018 10:17:49 +0200
> > > > Jani Nikula <jani.nikula@intel.com> wrote:
> > > >
> > > > > On Wed, 28 Nov 2018, Guang Bai <guang.bai@intel.com> 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 <jani.nikula@intel.com>
> > > > > > Cc: Chris Chiu <chiu@endlessm.com>
> > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Signed-off-by: Guang Bai <guang.bai@intel.com>
> > > > > > ---
> > > > > >  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: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Guang Bai]

On Fri, 4 Jan 2019 12:02:34 +0800
Chris Chiu <chiu@endlessm.com> wrote:

> On Thu, Jan 3, 2019 at 1:50 AM Guang Bai <guang.bai@intel.com> wrote:
> >
> > On Wed, 2 Jan 2019 17:29:46 +0800
> > Chris Chiu <chiu@endlessm.com> 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?

- I'm not sure if and when my changes will pass the review and merged
  into the upstream kernel. I'm stuck on re-testing my fix with all
  those claimed failures from HDMI port live status checking happened
  sometimes before. I don't have any background info on those failures
  simply because I stepped into DRM/i915 area in recent one or two
  years after working on other OS/platform's gfx driver for more than
  two decades
- My customer can't wait for this long, endless review time-period and
  just go ahead on proactive integration testing. They'll update us the
  results in a couple of days
Thanks,
-Guang
> 
> > >
> > > Chris
> > >
> > > On Mon, Dec 3, 2018 at 6:38 PM Chris Chiu <chiu@endlessm.com>
> > > wrote:  
> > > >
> > > > On Fri, Nov 30, 2018 at 1:15 AM Guang Bai <guang.bai@intel.com>
> > > > wrote:  
> > > > >
> > > > > On Thu, 29 Nov 2018 10:17:49 +0200
> > > > > Jani Nikula <jani.nikula@intel.com> wrote:
> > > > >  
> > > > > > On Wed, 28 Nov 2018, Guang Bai <guang.bai@intel.com>
> > > > > > 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 <jani.nikula@intel.com>
> > > > > > > Cc: Chris Chiu <chiu@endlessm.com>
> > > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > > Signed-off-by: Guang Bai <guang.bai@intel.com>
> > > > > > > ---
> > > > > > >  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: [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)

[Chris Chiu]

[-- Attachment #1.1: Type: text/plain, Size: 2064 bytes --]

On Thu, Nov 29, 2018 at 9:52 AM Guang Bai <guang.bai@intel.com> 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 <jani.nikula@intel.com>
> Cc: Chris Chiu <chiu@endlessm.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Guang Bai <guang.bai@intel.com>
> ---
>  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

[-- Attachment #1.2: Type: text/html, Size: 2899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

✓ Fi.CI.BAT: success for drm/i915: Fix the HDMI hot plug disconnection failure (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the HDMI hot plug disconnection failure (rev3)
URL   : https://patchwork.freedesktop.org/series/50477/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5217 -> Patchwork_10938
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/50477/revisions/3/mbox/

Known issues
------------

  Here are the changes found in Patchwork_10938 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_create@basic-files:
    - fi-bsw-n3050:       PASS -> FAIL [fdo#108656]

  * igt@kms_frontbuffer_tracking@basic:
    - fi-hsw-peppy:       PASS -> DMESG-WARN [fdo#102614]
    - fi-byt-clapper:     PASS -> FAIL [fdo#103167]

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
    - fi-byt-clapper:     PASS -> FAIL [fdo#103191] / [fdo#107362]

  
#### Possible fixes ####

  * igt@kms_chamelium@hdmi-hpd-fast:
    - {fi-kbl-7500u}:     FAIL [fdo#108769] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
  [fdo#108769]: https://bugs.freedesktop.org/show_bug.cgi?id=108769


Participating hosts (49 -> 44)
------------------------------

  Additional (1): fi-pnv-d510 
  Missing    (6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 


Build changes
-------------

    * Linux: CI_DRM_5217 -> Patchwork_10938

  CI_DRM_5217: 3b8acd938b1edc326fb69d377cbceca8791df177 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4735: b05c028ccdb6ac8e8d8499a041bb14dfe358ee26 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10938: 365b3fb384daa0f192de6e2414182d323e8422a4 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

365b3fb384da drm/i915: Fix the HDMI hot plug disconnection failure (v3)

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10938/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for drm/i915: Fix the HDMI hot plug disconnection failure (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the HDMI hot plug disconnection failure (rev4)
URL   : https://patchwork.freedesktop.org/series/50477/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5220 -> Patchwork_10943
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/50477/revisions/4/mbox/

Known issues
------------

  Here are the changes found in Patchwork_10943 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       PASS -> INCOMPLETE [fdo#107718]

  
#### Possible fixes ####

  * igt@kms_frontbuffer_tracking@basic:
    - fi-byt-clapper:     FAIL [fdo#103167] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
    - fi-byt-clapper:     FAIL [fdo#103191] / [fdo#107362] -> PASS +1

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718


Participating hosts (49 -> 44)
------------------------------

  Additional (1): fi-byt-j1900 
  Missing    (6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 


Build changes
-------------

    * Linux: CI_DRM_5220 -> Patchwork_10943

  CI_DRM_5220: b3a448de6828d0bd0397318d15ec143a3dfb553a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4735: b05c028ccdb6ac8e8d8499a041bb14dfe358ee26 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10943: 74baf446cd7cf1e0493a37fa34381575e7b79f94 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

74baf446cd7c drm/i915: Fix the HDMI hot plug disconnection failure (v4)

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10943/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for drm/i915: Fix the HDMI hot plug disconnection failure (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the HDMI hot plug disconnection failure (rev4)
URL   : https://patchwork.freedesktop.org/series/50477/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5220_full -> Patchwork_10943_full
====================================================

Summary
-------

  **WARNING**

  Minor unknown changes coming with Patchwork_10943_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_10943_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_10943_full:

### IGT changes ###

#### Warnings ####

  * igt@perf_pmu@rc6:
    - shard-kbl:          PASS -> SKIP

  * igt@pm_rc6_residency@rc6-accuracy:
    - shard-snb:          PASS -> SKIP

  * igt@tools_test@tools_test:
    - shard-hsw:          SKIP -> PASS

  
Known issues
------------

  Here are the changes found in Patchwork_10943_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@vecs0-s3:
    - shard-kbl:          PASS -> INCOMPLETE [fdo#103665]

  * igt@gem_exec_schedule@pi-ringfull-vebox:
    - shard-skl:          NOTRUN -> FAIL [fdo#103158]

  * igt@kms_busy@extended-modeset-hang-newfb-render-b:
    - shard-kbl:          PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
    - shard-hsw:          PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_cursor_crc@cursor-256x256-dpms:
    - shard-glk:          PASS -> FAIL [fdo#103232] +1

  * igt@kms_cursor_crc@cursor-256x256-offscreen:
    - shard-skl:          PASS -> FAIL [fdo#103232]

  * igt@kms_fbcon_fbt@psr:
    - shard-skl:          NOTRUN -> FAIL [fdo#107882]

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
    - shard-skl:          PASS -> FAIL [fdo#100368]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
    - shard-apl:          PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
    - shard-glk:          PASS -> FAIL [fdo#103167] / [fdo#105682]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-cpu:
    - shard-glk:          PASS -> FAIL [fdo#103167] +2

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
    - {shard-iclb}:       PASS -> FAIL [fdo#105683] +1

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-render:
    - shard-skl:          NOTRUN -> FAIL [fdo#103167]

  * igt@kms_panel_fitting@legacy:
    - shard-skl:          NOTRUN -> FAIL [fdo#105456]

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
    - shard-skl:          NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-mid:
    - shard-apl:          PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +10

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
    - {shard-iclb}:       PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
    - shard-apl:          PASS -> DMESG-FAIL [fdo#103166] / [fdo#103558] / [fdo#105602]

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
    - shard-apl:          PASS -> FAIL [fdo#103166]

  * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format:
    - {shard-iclb}:       PASS -> DMESG-WARN [fdo#107724]

  
#### Possible fixes ####

  * igt@drm_import_export@import-close-race-flink:
    - shard-skl:          TIMEOUT [fdo#108667] -> PASS

  * igt@kms_color@pipe-b-degamma:
    - shard-apl:          FAIL [fdo#104782] -> PASS +1

  * igt@kms_cursor_crc@cursor-256x256-onscreen:
    - shard-glk:          FAIL [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-256x256-suspend:
    - shard-apl:          FAIL [fdo#103191] / [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-256x85-onscreen:
    - shard-apl:          FAIL [fdo#103232] -> PASS +2

  * igt@kms_flip_tiling@flip-to-y-tiled:
    - {shard-iclb}:       DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +1

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
    - shard-glk:          FAIL [fdo#103167] -> PASS

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt:
    - {shard-iclb}:       DMESG-FAIL [fdo#107724] -> PASS

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
    - {shard-iclb}:       FAIL [fdo#103167] -> PASS +1

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
    - {shard-iclb}:       FAIL [fdo#103166] -> PASS +1

  * igt@kms_setmode@basic:
    - shard-apl:          FAIL [fdo#99912] -> PASS

  * igt@kms_sysfs_edid_timing:
    - shard-skl:          FAIL [fdo#100047] -> PASS
    - shard-kbl:          FAIL [fdo#100047] -> PASS

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
    - {shard-iclb}:       DMESG-WARN [fdo#107724] -> PASS +5

  * igt@pm_rpm@basic-pci-d3-state:
    - {shard-iclb}:       INCOMPLETE [fdo#108840] -> PASS +1

  * igt@pm_rpm@modeset-non-lpsp-stress:
    - shard-skl:          INCOMPLETE [fdo#107807] -> SKIP

  * igt@pm_rpm@modeset-stress-extra-wait:
    - shard-skl:          INCOMPLETE [fdo#107807] -> PASS

  * igt@pm_rpm@system-suspend:
    - shard-skl:          INCOMPLETE [fdo#104108] / [fdo#107807] -> PASS

  
#### Warnings ####

  * igt@i915_suspend@shrink:
    - shard-skl:          DMESG-WARN [fdo#108784] -> INCOMPLETE [fdo#106886]
    - shard-apl:          DMESG-WARN [fdo#108784] -> INCOMPLETE [fdo#103927] / [fdo#106886]
    - shard-glk:          DMESG-WARN [fdo#108784] -> INCOMPLETE [fdo#103359] / [fdo#106886] / [k.org#198133]

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
  [fdo#105456]: https://bugs.freedesktop.org/show_bug.cgi?id=105456
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105682]: https://bugs.freedesktop.org/show_bug.cgi?id=105682
  [fdo#105683]: https://bugs.freedesktop.org/show_bug.cgi?id=105683
  [fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
  [fdo#107882]: https://bugs.freedesktop.org/show_bug.cgi?id=107882
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108336]: https://bugs.freedesktop.org/show_bug.cgi?id=108336
  [fdo#108667]: https://bugs.freedesktop.org/show_bug.cgi?id=108667
  [fdo#108784]: https://bugs.freedesktop.org/show_bug.cgi?id=108784
  [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (7 -> 7)
------------------------------

  No changes in participating hosts


Build changes
-------------

    * Linux: CI_DRM_5220 -> Patchwork_10943

  CI_DRM_5220: b3a448de6828d0bd0397318d15ec143a3dfb553a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4735: b05c028ccdb6ac8e8d8499a041bb14dfe358ee26 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10943: 74baf446cd7cf1e0493a37fa34381575e7b79f94 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10943/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx