All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Return early when pipes are not available
@ 2017-11-09 10:49 Mika Kahola
  2017-11-09 11:01 ` Chris Wilson
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Mika Kahola @ 2017-11-09 10:49 UTC (permalink / raw)
  To: intel-gfx

At least in Coffee Lake it happens that we start initiliazing audio when
no display is connected. This was discovered by CI when running IGT test
case

drv_module_reload --r basic-no-display

The issue here is that the 'intel_device_info_runtime_init()' sets
num_pipes to 0 but before this happens the audio part has already started
to initialize itself. Later on the num_pipes is updated to 0 in
intel_device_info_runtime_init() and we hit that when audio part is digging
out ELD. This causes a warning in dmesg. To fix this issue, let's check the
number of available pipes when trying to read out ELD.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103206
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
---
 drivers/gpu/drm/i915/intel_audio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
index 4705194..5e367b1 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -859,6 +859,9 @@ static int i915_audio_component_get_eld(struct device *kdev, int port,
 	const u8 *eld;
 	int ret = -EINVAL;
 
+	if (INTEL_INFO(dev_priv)->num_pipes == 0)
+		return ret;
+
 	mutex_lock(&dev_priv->av_mutex);
 
 	intel_encoder = get_saved_enc(dev_priv, port, pipe);
-- 
2.7.4

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

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] drm/i915: Return early when pipes are not available
  2017-11-09 10:49 [PATCH] drm/i915: Return early when pipes are not available Mika Kahola
@ 2017-11-09 11:01 ` Chris Wilson
  2017-11-09 11:11   ` Mika Kahola
  2017-11-09 11:27 ` ✓ Fi.CI.BAT: success for " Patchwork
  2017-11-09 12:54 ` ✗ Fi.CI.IGT: failure " Patchwork
  2 siblings, 1 reply; 10+ messages in thread
From: Chris Wilson @ 2017-11-09 11:01 UTC (permalink / raw)
  To: Mika Kahola, intel-gfx

Quoting Mika Kahola (2017-11-09 10:49:52)
> At least in Coffee Lake it happens that we start initiliazing audio when
> no display is connected. This was discovered by CI when running IGT test
> case
> 
> drv_module_reload --r basic-no-display
> 
> The issue here is that the 'intel_device_info_runtime_init()' sets
> num_pipes to 0 but before this happens the audio part has already started
> to initialize itself. Later on the num_pipes is updated to 0 in
> intel_device_info_runtime_init() and we hit that when audio part is digging
> out ELD. This causes a warning in dmesg. To fix this issue, let's check the
> number of available pipes when trying to read out ELD.

dev_info_runtime_init() is too late. It depends on mmio being enabled to
probe the HW and nothing else; so move it to i915_driver_init_mmio()?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] drm/i915: Return early when pipes are not available
  2017-11-09 11:01 ` Chris Wilson
@ 2017-11-09 11:11   ` Mika Kahola
  2017-11-09 13:15     ` Ville Syrjälä
  0 siblings, 1 reply; 10+ messages in thread
From: Mika Kahola @ 2017-11-09 11:11 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

On Thu, 2017-11-09 at 11:01 +0000, Chris Wilson wrote:
> Quoting Mika Kahola (2017-11-09 10:49:52)
> > 
> > At least in Coffee Lake it happens that we start initiliazing audio
> > when
> > no display is connected. This was discovered by CI when running IGT
> > test
> > case
> > 
> > drv_module_reload --r basic-no-display
> > 
> > The issue here is that the 'intel_device_info_runtime_init()' sets
> > num_pipes to 0 but before this happens the audio part has already
> > started
> > to initialize itself. Later on the num_pipes is updated to 0 in
> > intel_device_info_runtime_init() and we hit that when audio part is
> > digging
> > out ELD. This causes a warning in dmesg. To fix this issue, let's
> > check the
> > number of available pipes when trying to read out ELD.
> dev_info_runtime_init() is too late. It depends on mmio being enabled
> to
> probe the HW and nothing else; so move it to i915_driver_init_mmio()?
Ok. I could try that. I was also thinking that is there a way to
postpone audio initialization?

> -Chris
-- 
Mika Kahola - Intel OTC

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915: Return early when pipes are not available
  2017-11-09 10:49 [PATCH] drm/i915: Return early when pipes are not available Mika Kahola
  2017-11-09 11:01 ` Chris Wilson
@ 2017-11-09 11:27 ` Patchwork
  2017-11-09 12:54 ` ✗ Fi.CI.IGT: failure " Patchwork
  2 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2017-11-09 11:27 UTC (permalink / raw)
  To: Mika Kahola; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Return early when pipes are not available
URL   : https://patchwork.freedesktop.org/series/33506/
State : success

== Summary ==

Series 33506v1 drm/i915: Return early when pipes are not available
https://patchwork.freedesktop.org/api/1.0/series/33506/revisions/1/mbox/

Test chamelium:
        Subgroup dp-crc-fast:
                pass       -> FAIL       (fi-kbl-7500u) fdo#102514
Test gem_exec_reloc:
        Subgroup basic-gtt-active:
                fail       -> PASS       (fi-gdg-551) fdo#102582 +2
Test gem_sync:
        Subgroup basic-store-all:
                pass       -> FAIL       (fi-ivb-3520m) fdo#100007

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582
fdo#100007 https://bugs.freedesktop.org/show_bug.cgi?id=100007

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:444s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:450s
fi-blb-e6850     total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:380s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:539s
fi-bwr-2160      total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 time:275s
fi-bxt-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:502s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:505s
fi-byt-j1900     total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  time:495s
fi-byt-n2820     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:491s
fi-elk-e7500     total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:424s
fi-gdg-551       total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 time:264s
fi-glk-1         total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:540s
fi-hsw-4770      total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:437s
fi-hsw-4770r     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:437s
fi-ilk-650       total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  time:424s
fi-ivb-3520m     total:289  pass:259  dwarn:0   dfail:0   fail:1   skip:29  time:468s
fi-ivb-3770      total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:460s
fi-kbl-7500u     total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  time:475s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:521s
fi-kbl-7567u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:474s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:534s
fi-pnv-d510      total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  time:570s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:451s
fi-skl-6600u     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:548s
fi-skl-6700hq    total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:563s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:521s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:497s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:456s
fi-snb-2520m     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:567s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  time:419s
Blacklisted hosts:
fi-cnl-y         total:289  pass:99   dwarn:0   dfail:0   fail:0   skip:20 
fi-glk-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:492s

65dc54b704d3ee0486f9f5b11f00c28973f783a2 drm-tip: 2017y-11m-09d-08h-53m-46s UTC integration manifest
6eb51f11a76f drm/i915: Return early when pipes are not available

== Logs ==

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* ✗ Fi.CI.IGT: failure for drm/i915: Return early when pipes are not available
  2017-11-09 10:49 [PATCH] drm/i915: Return early when pipes are not available Mika Kahola
  2017-11-09 11:01 ` Chris Wilson
  2017-11-09 11:27 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2017-11-09 12:54 ` Patchwork
  2 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2017-11-09 12:54 UTC (permalink / raw)
  To: Mika Kahola; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Return early when pipes are not available
URL   : https://patchwork.freedesktop.org/series/33506/
State : failure

== Summary ==

Test kms_setmode:
        Subgroup basic:
                fail       -> PASS       (shard-hsw) fdo#99912
Test kms_flip:
        Subgroup blocking-wf_vblank:
                pass       -> FAIL       (shard-hsw)
Test pm_lpsp:
        Subgroup screens-disabled:
                pass       -> FAIL       (shard-hsw) fdo#102579
Test perf:
        Subgroup blocking:
                fail       -> PASS       (shard-hsw) fdo#102252

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102579 https://bugs.freedesktop.org/show_bug.cgi?id=102579
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hsw        total:2540 pass:1432 dwarn:0   dfail:0   fail:11  skip:1097 time:9255s

== Logs ==

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] drm/i915: Return early when pipes are not available
  2017-11-09 11:11   ` Mika Kahola
@ 2017-11-09 13:15     ` Ville Syrjälä
  2017-11-10 12:22       ` Mika Kahola
  0 siblings, 1 reply; 10+ messages in thread
From: Ville Syrjälä @ 2017-11-09 13:15 UTC (permalink / raw)
  To: Mika Kahola; +Cc: intel-gfx

On Thu, Nov 09, 2017 at 01:11:05PM +0200, Mika Kahola wrote:
> On Thu, 2017-11-09 at 11:01 +0000, Chris Wilson wrote:
> > Quoting Mika Kahola (2017-11-09 10:49:52)
> > > 
> > > At least in Coffee Lake it happens that we start initiliazing audio
> > > when
> > > no display is connected. This was discovered by CI when running IGT
> > > test
> > > case
> > > 
> > > drv_module_reload --r basic-no-display
> > > 
> > > The issue here is that the 'intel_device_info_runtime_init()' sets
> > > num_pipes to 0 but before this happens the audio part has already
> > > started
> > > to initialize itself. Later on the num_pipes is updated to 0 in
> > > intel_device_info_runtime_init() and we hit that when audio part is
> > > digging
> > > out ELD. This causes a warning in dmesg. To fix this issue, let's
> > > check the
> > > number of available pipes when trying to read out ELD.
> > dev_info_runtime_init() is too late. It depends on mmio being enabled
> > to
> > probe the HW and nothing else; so move it to i915_driver_init_mmio()?
> Ok. I could try that. I was also thinking that is there a way to
> postpone audio initialization?

We probably shouldn't be registering the audio thing until we've
actually set up the outputs.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] drm/i915: Return early when pipes are not available
  2017-11-09 13:15     ` Ville Syrjälä
@ 2017-11-10 12:22       ` Mika Kahola
  2017-11-10 13:22         ` Jani Nikula
  0 siblings, 1 reply; 10+ messages in thread
From: Mika Kahola @ 2017-11-10 12:22 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

On Thu, 2017-11-09 at 15:15 +0200, Ville Syrjälä wrote:
> On Thu, Nov 09, 2017 at 01:11:05PM +0200, Mika Kahola wrote:
> > 
> > On Thu, 2017-11-09 at 11:01 +0000, Chris Wilson wrote:
> > > 
> > > Quoting Mika Kahola (2017-11-09 10:49:52)
> > > > 
> > > > 
> > > > At least in Coffee Lake it happens that we start initiliazing
> > > > audio
> > > > when
> > > > no display is connected. This was discovered by CI when running
> > > > IGT
> > > > test
> > > > case
> > > > 
> > > > drv_module_reload --r basic-no-display
> > > > 
> > > > The issue here is that the 'intel_device_info_runtime_init()'
> > > > sets
> > > > num_pipes to 0 but before this happens the audio part has
> > > > already
> > > > started
> > > > to initialize itself. Later on the num_pipes is updated to 0 in
> > > > intel_device_info_runtime_init() and we hit that when audio
> > > > part is
> > > > digging
> > > > out ELD. This causes a warning in dmesg. To fix this issue,
> > > > let's
> > > > check the
> > > > number of available pipes when trying to read out ELD.
> > > dev_info_runtime_init() is too late. It depends on mmio being
> > > enabled
> > > to
> > > probe the HW and nothing else; so move it to
> > > i915_driver_init_mmio()?
> > Ok. I could try that. I was also thinking that is there a way to
> > postpone audio initialization?
> We probably shouldn't be registering the audio thing until we've
> actually set up the outputs.
I tried couple of versions. One with Chris's idea to move
intel_device_info_runtime_init() to i915_driver_init_mmio() didn't turn
out to be a success. 

https://patchwork.freedesktop.org/series/33514/

I also tried to set num_pipes to 0 in case of display disable already
in i915_driver_init_early(). That approach didn't turn out to be a
success either.

https://patchwork.freedesktop.org/series/33522/

I'll give it a go for a patch that doesn't register audio in case of
disabled display.

> 
-- 
Mika Kahola - Intel OTC

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] drm/i915: Return early when pipes are not available
  2017-11-10 12:22       ` Mika Kahola
@ 2017-11-10 13:22         ` Jani Nikula
  2017-11-10 13:34           ` Mika Kahola
  0 siblings, 1 reply; 10+ messages in thread
From: Jani Nikula @ 2017-11-10 13:22 UTC (permalink / raw)
  To: mika.kahola, Ville Syrjälä; +Cc: intel-gfx

On Fri, 10 Nov 2017, Mika Kahola <mika.kahola@intel.com> wrote:
> On Thu, 2017-11-09 at 15:15 +0200, Ville Syrjälä wrote:
>> On Thu, Nov 09, 2017 at 01:11:05PM +0200, Mika Kahola wrote:
>> > 
>> > On Thu, 2017-11-09 at 11:01 +0000, Chris Wilson wrote:
>> > > 
>> > > Quoting Mika Kahola (2017-11-09 10:49:52)
>> > > > 
>> > > > 
>> > > > At least in Coffee Lake it happens that we start initiliazing
>> > > > audio
>> > > > when
>> > > > no display is connected. This was discovered by CI when running
>> > > > IGT
>> > > > test
>> > > > case
>> > > > 
>> > > > drv_module_reload --r basic-no-display
>> > > > 
>> > > > The issue here is that the 'intel_device_info_runtime_init()'
>> > > > sets
>> > > > num_pipes to 0 but before this happens the audio part has
>> > > > already
>> > > > started
>> > > > to initialize itself. Later on the num_pipes is updated to 0 in
>> > > > intel_device_info_runtime_init() and we hit that when audio
>> > > > part is
>> > > > digging
>> > > > out ELD. This causes a warning in dmesg. To fix this issue,
>> > > > let's
>> > > > check the
>> > > > number of available pipes when trying to read out ELD.
>> > > dev_info_runtime_init() is too late. It depends on mmio being
>> > > enabled
>> > > to
>> > > probe the HW and nothing else; so move it to
>> > > i915_driver_init_mmio()?
>> > Ok. I could try that. I was also thinking that is there a way to
>> > postpone audio initialization?
>> We probably shouldn't be registering the audio thing until we've
>> actually set up the outputs.
> I tried couple of versions. One with Chris's idea to move
> intel_device_info_runtime_init() to i915_driver_init_mmio() didn't turn
> out to be a success. 
>
> https://patchwork.freedesktop.org/series/33514/
>
> I also tried to set num_pipes to 0 in case of display disable already
> in i915_driver_init_early(). That approach didn't turn out to be a
> success either.
>
> https://patchwork.freedesktop.org/series/33522/
>
> I'll give it a go for a patch that doesn't register audio in case of
> disabled display.

That seems like the way to go. Display disable on the command line
should be no different from num_pipes == 0.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] drm/i915: Return early when pipes are not available
  2017-11-10 13:22         ` Jani Nikula
@ 2017-11-10 13:34           ` Mika Kahola
  2017-11-10 13:37             ` Saarinen, Jani
  0 siblings, 1 reply; 10+ messages in thread
From: Mika Kahola @ 2017-11-10 13:34 UTC (permalink / raw)
  To: Jani Nikula, Ville Syrjälä; +Cc: intel-gfx

On Fri, 2017-11-10 at 15:22 +0200, Jani Nikula wrote:
> On Fri, 10 Nov 2017, Mika Kahola <mika.kahola@intel.com> wrote:
> > 
> > On Thu, 2017-11-09 at 15:15 +0200, Ville Syrjälä wrote:
> > > 
> > > On Thu, Nov 09, 2017 at 01:11:05PM +0200, Mika Kahola wrote:
> > > > 
> > > > 
> > > > On Thu, 2017-11-09 at 11:01 +0000, Chris Wilson wrote:
> > > > > 
> > > > > 
> > > > > Quoting Mika Kahola (2017-11-09 10:49:52)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > At least in Coffee Lake it happens that we start
> > > > > > initiliazing
> > > > > > audio
> > > > > > when
> > > > > > no display is connected. This was discovered by CI when
> > > > > > running
> > > > > > IGT
> > > > > > test
> > > > > > case
> > > > > > 
> > > > > > drv_module_reload --r basic-no-display
> > > > > > 
> > > > > > The issue here is that the
> > > > > > 'intel_device_info_runtime_init()'
> > > > > > sets
> > > > > > num_pipes to 0 but before this happens the audio part has
> > > > > > already
> > > > > > started
> > > > > > to initialize itself. Later on the num_pipes is updated to
> > > > > > 0 in
> > > > > > intel_device_info_runtime_init() and we hit that when audio
> > > > > > part is
> > > > > > digging
> > > > > > out ELD. This causes a warning in dmesg. To fix this issue,
> > > > > > let's
> > > > > > check the
> > > > > > number of available pipes when trying to read out ELD.
> > > > > dev_info_runtime_init() is too late. It depends on mmio being
> > > > > enabled
> > > > > to
> > > > > probe the HW and nothing else; so move it to
> > > > > i915_driver_init_mmio()?
> > > > Ok. I could try that. I was also thinking that is there a way
> > > > to
> > > > postpone audio initialization?
> > > We probably shouldn't be registering the audio thing until we've
> > > actually set up the outputs.
> > I tried couple of versions. One with Chris's idea to move
> > intel_device_info_runtime_init() to i915_driver_init_mmio() didn't
> > turn
> > out to be a success. 
> > 
> > https://patchwork.freedesktop.org/series/33514/
> > 
> > I also tried to set num_pipes to 0 in case of display disable
> > already
> > in i915_driver_init_early(). That approach didn't turn out to be a
> > success either.
> > 
> > https://patchwork.freedesktop.org/series/33522/
> > 
> > I'll give it a go for a patch that doesn't register audio in case
> > of
> > disabled display.
> That seems like the way to go. Display disable on the command line
> should be no different from num_pipes == 0.
Yeah, let's skip this patch for this. I tested another patch that
doesn't register the audio in case of disabled display. At least the
trybot run for this patch was clean.

https://patchwork.freedesktop.org/series/33601/


> 
> BR,
> Jani.
> 
-- 
Mika Kahola - Intel OTC

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] drm/i915: Return early when pipes are not available
  2017-11-10 13:34           ` Mika Kahola
@ 2017-11-10 13:37             ` Saarinen, Jani
  0 siblings, 0 replies; 10+ messages in thread
From: Saarinen, Jani @ 2017-11-10 13:37 UTC (permalink / raw)
  To: Kahola, Mika, Jani Nikula, Ville Syrjälä; +Cc: intel-gfx

HI, 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of
> Mika Kahola
> Sent: perjantai 10. marraskuuta 2017 15.35
> To: Jani Nikula <jani.nikula@linux.intel.com>; Ville Syrjälä
> <ville.syrjala@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Return early when pipes are not
> available
> 
> > > https://patchwork.freedesktop.org/series/33522/
> > >
> > > I'll give it a go for a patch that doesn't register audio in case of
> > > disabled display.
> > That seems like the way to go. Display disable on the command line
> > should be no different from num_pipes == 0.
> Yeah, let's skip this patch for this. I tested another patch that doesn't register
> the audio in case of disabled display. At least the trybot run for this patch was
> clean.
Well, no if you look all.html. same issues seen.

> 
> https://patchwork.freedesktop.org/series/33601/
> 
> 
> >
> > BR,
> > Jani.
> >
> --
> Mika Kahola - Intel OTC
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-11-10 13:37 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-09 10:49 [PATCH] drm/i915: Return early when pipes are not available Mika Kahola
2017-11-09 11:01 ` Chris Wilson
2017-11-09 11:11   ` Mika Kahola
2017-11-09 13:15     ` Ville Syrjälä
2017-11-10 12:22       ` Mika Kahola
2017-11-10 13:22         ` Jani Nikula
2017-11-10 13:34           ` Mika Kahola
2017-11-10 13:37             ` Saarinen, Jani
2017-11-09 11:27 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-11-09 12:54 ` ✗ Fi.CI.IGT: failure " Patchwork

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.