All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually
@ 2018-01-16 15:21 Mika Kuoppala
  2018-01-16 15:26 ` Chris Wilson
  2018-01-16 16:05 ` ✗ Fi.CI.BAT: warning for " Patchwork
  0 siblings, 2 replies; 7+ messages in thread
From: Mika Kuoppala @ 2018-01-16 15:21 UTC (permalink / raw)
  To: intel-gfx; +Cc: Hans de Goede

There is a suspicion that with aggressive upclocking, power rail
voltage fluctuations can disrupt c state transition, leading
to system hang.

When upclocking with 4 cpu Baytrails, bring up cpus to c1 and then
go through bins gradually towards target frequency to give leeway
for hw.

We go towards requested frequency on 1 millisecond intervals. For
each 1 millisecond, we increase the frequency by half of bins
that are in between current frequency and target.

This will have an adverse effect on client boosting, delaying
reaching full frequency by about 8ms.

References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 ++++
 drivers/gpu/drm/i915/i915_drv.c     |  5 +++
 drivers/gpu/drm/i915/i915_drv.h     |  4 +++
 drivers/gpu/drm/i915/intel_pm.c     | 72 +++++++++++++++++++++++++++++++++++--
 4 files changed, 86 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index cc659b4b2a45..9c718c2811b8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1043,6 +1043,13 @@ static int i915_frequency_info(struct seq_file *m, void *unused)
 		seq_printf(m, "current GPU freq: %d MHz\n",
 			   intel_gpu_freq(dev_priv, rps->cur_freq));
 
+		if (IS_VALLEYVIEW(dev_priv)) {
+			seq_printf(m, "target GPU freq: %d MHz\n",
+				   intel_gpu_freq(dev_priv, rps->target_freq));
+			seq_printf(m, "QOS CPU DMA Latency %d usecs\n",
+				   pm_qos_request(PM_QOS_CPU_DMA_LATENCY));
+		}
+
 		seq_printf(m, "max GPU freq: %d MHz\n",
 			   intel_gpu_freq(dev_priv, rps->max_freq));
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d20c33..9718afacfa30 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -896,6 +896,10 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv,
 	BUG_ON(device_info->gen > sizeof(device_info->gen_mask) * BITS_PER_BYTE);
 	device_info->gen_mask = BIT(device_info->gen - 1);
 
+	pm_qos_add_request(&dev_priv->gt_pm.rps.qos,
+			   PM_QOS_CPU_DMA_LATENCY,
+			   PM_QOS_DEFAULT_VALUE);
+
 	spin_lock_init(&dev_priv->irq_lock);
 	spin_lock_init(&dev_priv->gpu_error.lock);
 	mutex_init(&dev_priv->backlight_lock);
@@ -953,6 +957,7 @@ static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
 	intel_irq_fini(dev_priv);
 	i915_workqueues_cleanup(dev_priv);
 	i915_engines_cleanup(dev_priv);
+	pm_qos_remove_request(&dev_priv->gt_pm.rps.qos);
 }
 
 static int i915_mmio_setup(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c42015b05b47..90cc2788fbbb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -936,6 +936,10 @@ struct intel_rps {
 
 	/* manual wa residency calculations */
 	struct intel_rps_ei ei;
+
+	u8 target_freq;         /* vlv target to reach */
+	struct pm_qos_request qos;
+	struct delayed_work vlv_rps_work;
 };
 
 struct intel_rc6 {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1db79a860b96..00ef4cb7bd8f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6200,7 +6200,7 @@ static int gen6_set_rps(struct drm_i915_private *dev_priv, u8 val)
 	return 0;
 }
 
-static int valleyview_set_rps(struct drm_i915_private *dev_priv, u8 val)
+static int valleyview_set_hw_rps(struct drm_i915_private *dev_priv, u8 val)
 {
 	int err;
 
@@ -6224,6 +6224,69 @@ static int valleyview_set_rps(struct drm_i915_private *dev_priv, u8 val)
 	return 0;
 }
 
+static void valleyview_queue_rps_change(struct drm_i915_private *dev_priv)
+{
+	struct intel_rps * const rps = &dev_priv->gt_pm.rps;
+	unsigned long delay;
+
+	delay = 1 + msecs_to_jiffies(1);
+	queue_delayed_work(system_wq, &rps->vlv_rps_work, delay);
+}
+
+static int valleyview_set_rps(struct drm_i915_private *dev_priv, u8 val)
+{
+	struct intel_rps * const rps = &dev_priv->gt_pm.rps;
+
+	/* 2 cpu Baytrails seems to be safe */
+	if (IS_CHERRYVIEW(dev_priv) || num_online_cpus() <= 2)
+		return valleyview_set_hw_rps(dev_priv, val);
+
+	/*
+	 * For >2 cpu Baytrails we need to get cpus to C1
+	 * and limit the freq rampup.
+	 */
+	rps->target_freq = val;
+	pm_qos_update_request(&dev_priv->gt_pm.rps.qos, 0);
+
+	valleyview_queue_rps_change(dev_priv);
+
+	return 0;
+}
+
+static void vlv_rps_write_work(struct work_struct *work)
+{
+	struct drm_i915_private *dev_priv =
+		container_of(work, typeof(*dev_priv),
+			     gt_pm.rps.vlv_rps_work.work);
+	struct intel_rps * const rps = &dev_priv->gt_pm.rps;
+	u8 next;
+
+	mutex_lock(&dev_priv->pcu_lock);
+
+	if (rps->target_freq == rps->cur_freq) {
+		pm_qos_update_request(&dev_priv->gt_pm.rps.qos,
+				      PM_QOS_DEFAULT_VALUE);
+		mutex_unlock(&dev_priv->pcu_lock);
+		return;
+	}
+
+	if (rps->target_freq > rps->cur_freq) {
+		u8 diff = rps->target_freq - rps->cur_freq;
+
+		if (diff > 1)
+			diff = diff >> 1;
+
+		next = rps->cur_freq + diff;
+	} else {
+		next = rps->target_freq;
+	}
+
+	valleyview_set_hw_rps(dev_priv, next);
+	mutex_unlock(&dev_priv->pcu_lock);
+
+	valleyview_queue_rps_change(dev_priv);
+}
+
 /* vlv_set_rps_idle: Set the frequency to idle, if Gfx clocks are down
  *
  * * If Gfx is Idle, then
@@ -6237,9 +6300,11 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
 	u32 val = rps->idle_freq;
 	int err;
 
-	if (rps->cur_freq <= val)
+	if (IS_CHERRYVIEW(dev_priv) && rps->cur_freq <= val)
 		return;
 
+	rps->target_freq = val;
+
 	/* The punit delays the write of the frequency and voltage until it
 	 * determines the GPU is awake. During normal usage we don't want to
 	 * waste power changing the frequency if the GPU is sleeping (rc6).
@@ -9336,6 +9401,9 @@ int intel_freq_opcode(struct drm_i915_private *dev_priv, int val)
 
 void intel_pm_setup(struct drm_i915_private *dev_priv)
 {
+	INIT_DELAYED_WORK(&dev_priv->gt_pm.rps.vlv_rps_work,
+			  vlv_rps_write_work);
+
 	mutex_init(&dev_priv->pcu_lock);
 
 	atomic_set(&dev_priv->gt_pm.rps.num_waiters, 0);
-- 
2.14.1

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

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

* Re: [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually
  2018-01-16 15:21 [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually Mika Kuoppala
@ 2018-01-16 15:26 ` Chris Wilson
  2018-01-17  8:31   ` Mika Kuoppala
  2018-01-16 16:05 ` ✗ Fi.CI.BAT: warning for " Patchwork
  1 sibling, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2018-01-16 15:26 UTC (permalink / raw)
  To: Mika Kuoppala, intel-gfx; +Cc: Hans de Goede

Quoting Mika Kuoppala (2018-01-16 15:21:16)
> There is a suspicion that with aggressive upclocking, power rail
> voltage fluctuations can disrupt c state transition, leading
> to system hang.
> 
> When upclocking with 4 cpu Baytrails, bring up cpus to c1 and then
> go through bins gradually towards target frequency to give leeway
> for hw.
> 
> We go towards requested frequency on 1 millisecond intervals. For
> each 1 millisecond, we increase the frequency by half of bins
> that are in between current frequency and target.

Either this is good for everyone or it is not. Doing more punit accesses
seems counter productive though, and adds 8ms to the initial request?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✗ Fi.CI.BAT: warning for drm/i915/vlv: Ramp up gpu freq gradually
  2018-01-16 15:21 [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually Mika Kuoppala
  2018-01-16 15:26 ` Chris Wilson
@ 2018-01-16 16:05 ` Patchwork
  1 sibling, 0 replies; 7+ messages in thread
From: Patchwork @ 2018-01-16 16:05 UTC (permalink / raw)
  To: Mika Kuoppala; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/vlv: Ramp up gpu freq gradually
URL   : https://patchwork.freedesktop.org/series/36550/
State : warning

== Summary ==

Series 36550v1 drm/i915/vlv: Ramp up gpu freq gradually
https://patchwork.freedesktop.org/api/1.0/series/36550/revisions/1/mbox/

Test kms_busy:
        Subgroup basic-flip-a:
                pass       -> DMESG-WARN (fi-byt-j1900)
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                dmesg-warn -> PASS       (fi-kbl-r) fdo#104172

fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172

fi-bdw-5557u     total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  time:422s
fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:424s
fi-blb-e6850     total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  time:373s
fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:491s
fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:287s
fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:482s
fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:487s
fi-byt-j1900     total:288  pass:252  dwarn:1   dfail:0   fail:0   skip:35  time:471s
fi-byt-n2820     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:458s
fi-elk-e7500     total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551       total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 time:278s
fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:515s
fi-hsw-4770      total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:394s
fi-hsw-4770r     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:408s
fi-ilk-650       total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  time:412s
fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:463s
fi-ivb-3770      total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  time:414s
fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:461s
fi-kbl-7560u     total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  time:499s
fi-kbl-7567u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:453s
fi-kbl-r         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:510s
fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:580s
fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:429s
fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:512s
fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:528s
fi-skl-6700k2    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:491s
fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:477s
fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:432s
fi-snb-2520m     total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:531s
fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:397s
Blacklisted hosts:
fi-cfl-s2        total:109  pass:97   dwarn:0   dfail:0   fail:0   skip:11 
fi-glk-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:471s

a0ca279440c8d7c40d798fed9939a2a25b31434b drm-tip: 2018y-01m-16d-10h-49m-51s UTC integration manifest
11597a3b28d6 drm/i915/vlv: Ramp up gpu freq gradually

== Logs ==

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

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

* Re: [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually
  2018-01-16 15:26 ` Chris Wilson
@ 2018-01-17  8:31   ` Mika Kuoppala
  2018-01-17  9:16     ` Hans de Goede
  2018-01-17 15:45     ` Ville Syrjälä
  0 siblings, 2 replies; 7+ messages in thread
From: Mika Kuoppala @ 2018-01-17  8:31 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx; +Cc: Hans de Goede

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Quoting Mika Kuoppala (2018-01-16 15:21:16)
>> There is a suspicion that with aggressive upclocking, power rail
>> voltage fluctuations can disrupt c state transition, leading
>> to system hang.
>> 
>> When upclocking with 4 cpu Baytrails, bring up cpus to c1 and then
>> go through bins gradually towards target frequency to give leeway
>> for hw.
>> 
>> We go towards requested frequency on 1 millisecond intervals. For
>> each 1 millisecond, we increase the frequency by half of bins
>> that are in between current frequency and target.
>
> Either this is good for everyone or it is not. Doing more punit accesses
> seems counter productive though, and adds 8ms to the initial request?

Wanted to see if it is not punit access in itself but voltage rampup. We
can forget this patch as atleast with these values as it didn't survive
night.

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

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

* Re: [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually
  2018-01-17  8:31   ` Mika Kuoppala
@ 2018-01-17  9:16     ` Hans de Goede
  2018-01-17 15:45     ` Ville Syrjälä
  1 sibling, 0 replies; 7+ messages in thread
From: Hans de Goede @ 2018-01-17  9:16 UTC (permalink / raw)
  To: Mika Kuoppala, Chris Wilson, intel-gfx

Hi,

On 17-01-18 09:31, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
>> Quoting Mika Kuoppala (2018-01-16 15:21:16)
>>> There is a suspicion that with aggressive upclocking, power rail
>>> voltage fluctuations can disrupt c state transition, leading
>>> to system hang.
>>>
>>> When upclocking with 4 cpu Baytrails, bring up cpus to c1 and then
>>> go through bins gradually towards target frequency to give leeway
>>> for hw.
>>>
>>> We go towards requested frequency on 1 millisecond intervals. For
>>> each 1 millisecond, we increase the frequency by half of bins
>>> that are in between current frequency and target.
>>
>> Either this is good for everyone or it is not. Doing more punit accesses
>> seems counter productive though, and adds 8ms to the initial request?
> 
> Wanted to see if it is not punit access in itself but voltage rampup. We
> can forget this patch as atleast with these values as it didn't survive
> night.

I noticed this patch was lacking the ping Chris' version has. Is that
in the intel_idle driver now ? And did your test kernel have the intel_idle
patch? If not the lack of the ping may be the reason why this patch did not
survive the night.

Regards,

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

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

* Re: [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually
  2018-01-17  8:31   ` Mika Kuoppala
  2018-01-17  9:16     ` Hans de Goede
@ 2018-01-17 15:45     ` Ville Syrjälä
  2018-01-17 15:50       ` Hans de Goede
  1 sibling, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2018-01-17 15:45 UTC (permalink / raw)
  To: Mika Kuoppala; +Cc: Hans de Goede, intel-gfx

On Wed, Jan 17, 2018 at 10:31:09AM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > Quoting Mika Kuoppala (2018-01-16 15:21:16)
> >> There is a suspicion that with aggressive upclocking, power rail
> >> voltage fluctuations can disrupt c state transition, leading
> >> to system hang.
> >> 
> >> When upclocking with 4 cpu Baytrails, bring up cpus to c1 and then
> >> go through bins gradually towards target frequency to give leeway
> >> for hw.
> >> 
> >> We go towards requested frequency on 1 millisecond intervals. For
> >> each 1 millisecond, we increase the frequency by half of bins
> >> that are in between current frequency and target.
> >
> > Either this is good for everyone or it is not. Doing more punit accesses
> > seems counter productive though, and adds 8ms to the initial request?
> 
> Wanted to see if it is not punit access in itself but voltage rampup. We
> can forget this patch as atleast with these values as it didn't survive
> night.

I guess one big problem is that the GPU frequency is just one small part
of the voltage equation. RC6 might play a bigger role since it could
cause the voltage to alternate between low and high values rapidly. And
the Vnn rail is shared by most devices on the soc, so even just limiting
things to the GPU might not be entirely sufficient. And if there's some
link between the number of cores and the instability then the Vcc
rail(s) are perhaps also suspect. And for those I guess we would have
to somehow throttle the CPU C and P state transitions.

-- 
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] 7+ messages in thread

* Re: [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually
  2018-01-17 15:45     ` Ville Syrjälä
@ 2018-01-17 15:50       ` Hans de Goede
  0 siblings, 0 replies; 7+ messages in thread
From: Hans de Goede @ 2018-01-17 15:50 UTC (permalink / raw)
  To: Ville Syrjälä, Mika Kuoppala; +Cc: intel-gfx

Hi,

On 17-01-18 16:45, Ville Syrjälä wrote:
> On Wed, Jan 17, 2018 at 10:31:09AM +0200, Mika Kuoppala wrote:
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>>
>>> Quoting Mika Kuoppala (2018-01-16 15:21:16)
>>>> There is a suspicion that with aggressive upclocking, power rail
>>>> voltage fluctuations can disrupt c state transition, leading
>>>> to system hang.
>>>>
>>>> When upclocking with 4 cpu Baytrails, bring up cpus to c1 and then
>>>> go through bins gradually towards target frequency to give leeway
>>>> for hw.
>>>>
>>>> We go towards requested frequency on 1 millisecond intervals. For
>>>> each 1 millisecond, we increase the frequency by half of bins
>>>> that are in between current frequency and target.
>>>
>>> Either this is good for everyone or it is not. Doing more punit accesses
>>> seems counter productive though, and adds 8ms to the initial request?
>>
>> Wanted to see if it is not punit access in itself but voltage rampup. We
>> can forget this patch as atleast with these values as it didn't survive
>> night.
> 
> I guess one big problem is that the GPU frequency is just one small part
> of the voltage equation. RC6 might play a bigger role since it could
> cause the voltage to alternate between low and high values rapidly. And
> the Vnn rail is shared by most devices on the soc, so even just limiting
> things to the GPU might not be entirely sufficient. And if there's some
> link between the number of cores and the instability then the Vcc
> rail(s) are perhaps also suspect. And for those I guess we would have
> to somehow throttle the CPU C and P state transitions.

Right, various users have reported success with this patch:
https://bugzilla.kernel.org/attachment.cgi?id=260585

Often mixed with some patch to also make the GPU frequency changes
less. I guess that when only C7 is available it is used less, or
maybe the punit allows for a larger delay for the rails to stabilize
when coming out of C7, who knows. Might be worthwhile to try combining
this patch with Chris' patch to see if that helps.

Regards,

Hans

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

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

end of thread, other threads:[~2018-01-17 15:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-16 15:21 [PATCH RFC] drm/i915/vlv: Ramp up gpu freq gradually Mika Kuoppala
2018-01-16 15:26 ` Chris Wilson
2018-01-17  8:31   ` Mika Kuoppala
2018-01-17  9:16     ` Hans de Goede
2018-01-17 15:45     ` Ville Syrjälä
2018-01-17 15:50       ` Hans de Goede
2018-01-16 16:05 ` ✗ Fi.CI.BAT: warning for " 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.