On Wed, Apr 27, 2016 at 06:10:44PM -0700, tom.orou...@intel.com wrote:
> From: Tom O'Rourke
>
> SLPC (Single Loop Power Controller) is a replacement for
> some host-based power management features. The SLPC
> implemenation runs in firmware on GuC.
>
> This series has been tested with SKL guc fi
Hello,
These errors are unrelated to the major_minor version change.
Thanks,
Tom
>-Original Message-
>From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
>Sent: Monday, April 25, 2016 10:18 PM
>To: O'Rourke, Tom
>Cc: intel-gfx@lists.freedesktop.org
>Subjec
On Mon, Mar 07, 2016 at 08:57:09PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Read out the RPS frequencies already in intel_init_gt_powersave()
> on all the platforms. So far we only did that on VLV/CHV, and the
> rest of the platforms read them out at rps enable time,
On Tue, Jan 26, 2016 at 09:17:51AM -0800, Jesse Barnes wrote:
> On 01/26/2016 09:00 AM, Daniel Vetter wrote:
> > On Tue, Jan 26, 2016 at 07:45:42AM -0800, Jesse Barnes wrote:
> >> On 01/22/2016 09:00 AM, Daniel Vetter wrote:
> >>> On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orou...@intel.com wrot
On Thu, Jan 21, 2016 at 01:50:34PM +, Patchwork wrote:
> == Summary ==
>
> Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
> 2016y-01m-21d-11h-02m-42s UTC integration manifest
>
> Test drv_getparams_basic:
> Subgroup basic-eu-total:
> pass -
On Thu, Oct 01, 2015 at 07:59:27AM -0700, Kamble, Sagar A wrote:
> When using RC6 timeout mode, the timeout value
> should be written to GEN6_RC6_THRESHOLD.
>
> v2: Updated commit message. (Tom)
>
> v3: Rebase over whitespace differences. (Daniel)
>
> Cc: Tom O'Rourke
> Signed-off-by: Sagar Aru
On Wed, Sep 30, 2015 at 09:57:37AM -0700, yu@intel.com wrote:
> From: Sagar Arun Kamble
>
> Due to flip interrupts GuC stays awake always and GT does not enter
> RC6. Do not route those interrupts to GuC for now. Driver won't touch
> DE_GUCRMR register and leave it as what default value.
>
>
On Wed, Sep 30, 2015 at 04:13:43PM +0530, Sagar Arun Kamble wrote:
> When using RC6 timeout mode, the timeout value
> should be written to GEN6_RC6_THRESHOLD.
>
> v2: Updated commit message. (Tom)
>
> Signed-off-by: Sagar Arun Kamble
Reviewed-by: Tom O'Rourke
> ---
> drivers/gpu/drm/i915/int
On Wed, Sep 30, 2015 at 08:59:21AM -0700, Yu Dai wrote:
>
>
> On 09/30/2015 03:46 AM, Kamble, Sagar A wrote:
> >Thanks for the updated patch. Minor comment below.
> >
> >Thanks
> >Sagar
> >
> >On 9/26/2015 12:16 AM, yu@intel.com wrote:
> >> From: Alex Dai
> >>
> >> Add host2guc interfaces to
On Fri, Sep 25, 2015 at 11:46:56AM -0700, yu@intel.com wrote:
> From: Alex Dai
>
> GuC expects two bits for Render and Media domain separately when
> driver sends data via host2guc SAMPLE_FORCEWAKE. Bit 0 is for
> Render and bit 1 is for Media domain.
>
> v2: Keep sync with code for WaRsDoub
This change looks good and is necessary, but the
commit message should have more detail.
I would add:
"When using RC6 timeout mode, the timeout value
should be written to GEN6_RC6_THRESHOLD."
With that,
Reviewed-by: Tom O'Rourke
On Wed, Sep 23, 2015 at 03:06:42PM +0530, Sagar Arun Kamble wrote:
On Tue, Sep 22, 2015 at 01:48:44PM -0700, yu@intel.com wrote:
> From: Alex Dai
>
> GuC expects two bits for Render and Media domain separately when
> driver sends data via host2guc SAMPLE_FORCEWAKE. Bit 0 is for
> Render and bit 1 is for Media domain.
>
> v1: Add parameters definition to avo
On Tue, Sep 22, 2015 at 04:11:48PM -0700, yu@intel.com wrote:
> From: Sagar Arun Kamble
>
> Due to flip interrupts GuC stays awake always and GT does not enter
> RC6. Do not route those interrupts to GuC for now. Driver won't touch
> DE_GUCRMR register and leave it as what default value.
>
>
Hello,
This change looks good but incomplete.
When changing RC6 from EI mode to TO mode,
should the time value in GEN6_RC6_THRESHOLD
be changed to hold the timeout value instead
of the evaluation interval period?
Should the workaround name be included in a comment?
While this workaround is unname
On Fri, Sep 11, 2015 at 05:44:32AM -0700, Kamble, Sagar A wrote:
> Due to flip interrupts routed to GuC, GuC stays awake always and GT does not
> enter RC6.
> GuC firmware should re-direct to GuC those interrupts that it can handle.
>
> v2: Commit message change and routing all interrupts to host
On Sun, Aug 23, 2015 at 05:52:51PM +0530, Sagar Arun Kamble wrote:
> From: Alex Dai
>
[TOR:] This commit message is inadequate. The
needed information is in the cover letter but
is lacking here. Please rebase with Alex's
previous patch "drm/i915: Notify GuC rc6 state"
> Signed-off-by: Alex
On Tue, Aug 18, 2015 at 02:34:47PM -0700, yu@intel.com wrote:
> From: Alex Dai
>
> If rc6 is enabled, notify GuC so it can do proper forcewake before
> command submission.
>
> Signed-off-by: Alex Dai
Reviewed-by: Tom O'Rourke
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 15 +
On Tue, Aug 18, 2015 at 02:32:35PM -0700, yu@intel.com wrote:
> From: Alex Dai
>
> The firmware layout changes that now it only has css header +
> uCode + RSA signature. Plus, other trivial changes to support
> GuC V4.3.
>
> Signed-off-by: Alex Dai
Reviewed-by: Tom O'Rourke
This patch ha
On Wed, Aug 12, 2015 at 07:57:37AM -0700, Gordon, David S wrote:
> On 12/08/15 15:43, Dave Gordon wrote:
> > This patch series enables command submission via the GuC. In this mode,
> > instead of the host CPU driving the execlist port directly, it hands
> > over work items to the GuC, using a doorb
On Wed, Jul 29, 2015 at 06:48:28PM +0100, Dave Gordon wrote:
> This patch series enables command submission via the GuC. In this mode,
> instead of the host CPU driving the execlist port directly, it hands
> over work items to the GuC, using a doorbell mechanism to tell the GuC
> that new items hav
On Wed, Jul 29, 2015 at 06:48:29PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> This fetches the required firmware image from the filesystem,
> then loads it into the GuC's memory via a dedicated DMA engine.
>
> This patch is derived from GuC loading work originally done by
> Vinit Azad and Be
On Tue, Jul 28, 2015 at 08:40:58PM +0100, Dave Gordon wrote:
> On 28/07/15 16:16, Dave Gordon wrote:
> >On 28/07/15 00:12, O'Rourke, Tom wrote:
> >>On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote:
> >>>
> >>>On 07/24/2015 03:31 PM, O'Ro
On Tue, Jul 28, 2015 at 04:16:03PM +0100, Dave Gordon wrote:
> On 28/07/15 00:12, O'Rourke, Tom wrote:
> >On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote:
> >>
> >>On 07/24/2015 03:31 PM, O'Rourke, Tom wrote:
> >>>[TOR:] When I see "p
On Mon, Jul 27, 2015 at 03:41:31PM -0700, Yu Dai wrote:
>
>
> On 07/24/2015 03:31 PM, O'Rourke, Tom wrote:
> >[TOR:] When I see "phase 1" I also look for "phase 2".
> >A subject that better describes the change in this patch
> >would help.
&
On Thu, Jul 09, 2015 at 07:29:12PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> GuC-based submission is mostly the same as execlist mode, up to
> intel_logical_ring_advance_and_submit(), where the context being
> dispatched would be added to the execlist queue; at this point
> we submit the con
On Thu, Jul 09, 2015 at 07:29:13PM +0100, Dave Gordon wrote:
> This provides a means of reading status and counts relating
> to GuC actions and submissions.
>
> v2:
> Remove surplus blank line in output [Chris Wilson]
>
> v4:
> Rebased
>
> Signed-off-by: Dave Gordon
> Signed-off-by: Ale
On Thu, Jul 09, 2015 at 07:29:11PM +0100, Dave Gordon wrote:
> Turn on interrupt steering to route necessary interrupts to GuC.
>
> v4:
> Rebased
>
> Issue: VIZ-4884
> Signed-off-by: Alex Dai
> Signed-off-by: Dave Gordon
> ---
> drivers/gpu/drm/i915/i915_reg.h | 11 +--
> drive
On Thu, Jul 09, 2015 at 07:29:10PM +0100, Dave Gordon wrote:
> A GuC client has its own doorbell and workqueue. It maintains the
> doorbell cache line, process description object and work queue item.
>
> A default guc_client is created for the i915 driver to use for
> normal-priority in-order subm
On Thu, Jul 09, 2015 at 07:29:09PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> Allocate a GEM object to hold GuC log data. A debugfs interface
> (i915_guc_log_dump) is provided to print out the log content.
>
> v2:
> Add struct members at point of use [Chris Wilson]
>
> v4:
> Rebased
[TOR:] When I see "phase 1" I also look for "phase 2".
A subject that better describes the change in this patch
would help.
On Thu, Jul 09, 2015 at 07:29:08PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> This adds the first of the data structures used to communicate with the
> GuC (the pool
On Thu, Jul 09, 2015 at 07:29:07PM +0100, Dave Gordon wrote:
> GuC submission is basically execlist submission, but with the GuC
> handling the actual writes to the ELSP and the resulting context
> switch interrupts. So to prepare a context for submission via the
> GuC, we need some of the same fun
On Tue, Jul 21, 2015 at 08:38:35AM +0200, Daniel Vetter wrote:
> On Fri, Jul 17, 2015 at 05:38:05PM -0700, O'Rourke, Tom wrote:
> > On Thu, Jul 09, 2015 at 07:29:04PM +0100, Dave Gordon wrote:
> > > intel_guc_fwif.h contains the subset of the GuC interface that we
> >
On Thu, Jul 09, 2015 at 07:29:01PM +0100, Dave Gordon wrote:
> This patch series enables command submission via the GuC. In this mode,
> instead of the host CPU driving the execlist port directly, it hands
> over work items to the GuC, using a doorbell mechanism to tell the GuC
> that new items hav
On Thu, Jul 09, 2015 at 07:29:06PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> The new node provides access to the status of the GuC-specific loader;
> also the scratch registers used for communication between the i915
> driver and the GuC firmware.
>
> v2:
> Changes to output formats per
On Thu, Jul 09, 2015 at 07:29:04PM +0100, Dave Gordon wrote:
> intel_guc_fwif.h contains the subset of the GuC interface that we
> will need for submission of commands through the GuC. These MUST
> be kept in sync with the definitions used by the GuC firmware, and
> updates to this file will (or sh
On Thu, Jul 09, 2015 at 07:29:03PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> Two new module parameters: "enable_guc_submission" which will turn
> on submission of batchbuffers via the GuC (when implemented), and
> "guc_log_level" which controls the level of debugging logged by the
> GuC and
On Thu, Jul 09, 2015 at 07:29:02PM +0100, Dave Gordon wrote:
> i915_gem_object_create_from_data() is a generic function to save data
> from a plain linear buffer in a new pageable gem object that can later
> be accessed by the CPU and/or GPU.
>
> We will need this for the microcontroller firmware
On Thu, Jul 09, 2015 at 07:29:05PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> This fetches the required firmware image from the filesystem,
> then loads it into the GuC's memory via a dedicated DMA engine.
>
> This patch is derived from GuC loading work originally done by
> Vinit Azad and Be
On Mon, Jul 06, 2015 at 04:29:47PM +0200, Daniel Vetter wrote:
> On Fri, Jul 03, 2015 at 01:30:22PM +0100, Dave Gordon wrote:
> > This patch series enables command submission via the GuC. In this mode,
[TOR:] ...
> > created the original versions on which some of these patches are based.
>
> A f
On Thu, Jun 25, 2015 at 03:40:00PM +0100, Dave Gordon wrote:
> intel_guc_fwif.h contains the subset of the GuC interface that we
> will need for submission of commands through the GuC. These MUST
> be kept in sync with the definitions used by the GuC firmware, and
> updates to this file will (or sh
> > +
> > + dev_priv->rps.efficient_freq *=
> > + (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
This line seems awkward. I suppose a good compiler could
optimize out the multiply by one.
I would prefer something like:
if(IS_SKYLAKE
On Wed, Feb 11, 2015 at 08:30:44AM +0100, Daniel Vetter wrote:
> On Tue, Feb 10, 2015 at 10:26:02PM -0800, O'Rourke, Tom wrote:
> > On Thu, Jan 29, 2015 at 08:56:06PM -0500, Michael Auchter wrote:
> > > On Thu, Jan 29, 2015 at 06:12:31PM +0100, Daniel Vetter wrote:
> >
On Thu, Jan 29, 2015 at 08:56:06PM -0500, Michael Auchter wrote:
> On Thu, Jan 29, 2015 at 06:12:31PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 28, 2015 at 10:36:02PM -0800, O'Rourke, Tom wrote:
> > > On Wed, Jan 28, 2015 at 01:28:58PM +0200, Ville Syrjälä wrote:
> >
On Thu, Jan 29, 2015 at 08:56:06PM -0500, Michael Auchter wrote:
> On Thu, Jan 29, 2015 at 06:12:31PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 28, 2015 at 10:36:02PM -0800, O'Rourke, Tom wrote:
> > > On Wed, Jan 28, 2015 at 01:28:58PM +0200, Ville Syrjälä wrote:
> >
On Wed, Jan 28, 2015 at 01:28:58PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 28, 2015 at 09:58:15AM +, Chris Wilson wrote:
> > On Wed, Jan 28, 2015 at 12:43:21AM -0500, Michael Auchter wrote:
> > > Testing out 3.19-rc6 on my 2014 Thinkpad X1 Carbon (Haswell) resulted in
> > > this WARN at boot
On Sun, Jan 25, 2015 at 09:34:33AM +, Chris Wilson wrote:
> On Fri, Jan 23, 2015 at 09:04:24PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently the 'gt_cur_freq_mhz' file shows the actual GPU frequency on
> > VLV/CHV, and the last requested frequency on ot
On Tue, Jan 13, 2015 at 02:36:56PM -0800, Ben Widawsky wrote:
> On Tue, Jan 13, 2015 at 09:19:04PM +0000, O'Rourke, Tom wrote:
> > >Sent: Sunday, January 11, 2015 7:48 PM
> > >To: Widawsky, Benjamin
> > >Cc: Intel GFX
> > >Subject: Re: [Intel-
>Sent: Sunday, January 11, 2015 7:48 PM
>To: Widawsky, Benjamin
>Cc: Intel GFX
>Subject: Re: [Intel-gfx] [PATCH] [v2] intel_frequency: A tool to manipulate
>Intel
>GPU frequency
>
>On Sun, Jan 11, 2015 at 07:35:21PM -0800, Ben Widawsky wrote:
>> WARNING: very minimally tested
>>
>> In general you
On Fri, Nov 07, 2014 at 10:41:26AM +, Chris Wilson wrote:
> On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote:
> > From: Tom O'Rourke
> >
> > Updated gen6|8_enable_rps() for Haswell and Broadwell
> > to use the efficient frequency read from pcode.
> >
> > Added hsw_use_e
On Fri, Nov 07, 2014 at 10:50:02AM +0100, Daniel Vetter wrote:
> On Wed, Nov 05, 2014 at 05:31:34PM -0800, Tom.O'rou...@intel.com wrote:
> > From: Tom O'Rourke
> >
> > Updated gen6|8_enable_rps() for Haswell and Broadwell
> > to use the efficient frequency read from pcode.
> >
> > Added hsw_use_
On Thu, Nov 06, 2014 at 08:18:46PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 06, 2014 at 09:35:48AM -0800, O'Rourke, Tom wrote:
> > On Thu, Nov 06, 2014 at 10:28:53AM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 05, 2014 at 05:32:44PM -0800, Tom.O'rou...@intel.
On Thu, Nov 06, 2014 at 10:28:53AM +0200, Ville Syrjälä wrote:
> On Wed, Nov 05, 2014 at 05:32:44PM -0800, Tom.O'rou...@intel.com wrote:
> > From: Tom O'Rourke
> >
> > Based on sandybridge_pcode_write, haswell_pcode_write has an
> > additional field for address control.
>
> It's already there in
On Tue, Nov 04, 2014 at 04:51:41AM -0800, Rodrigo Vivi wrote:
> From: Deepak S
>
> Higher RC6 residency is observed using timeout mode
> instead of EI mode. It's Recommended to use TO Method for RC6.
>
[TOR:] My comments on the previous version of this patch are at
http://lists.freedesktop.org/a
On Mon, Sep 29, 2014 at 12:46:25PM -0700, Jesse Barnes wrote:
> On Mon, 29 Sep 2014 09:52:38 -0700
> Rodrigo Vivi wrote:
>
> > On Mon, Sep 29, 2014 at 9:38 AM, Daniel Vetter wrote:
> > > On Mon, Sep 29, 2014 at 08:48:53AM -0700, Jesse Barnes wrote:
> > >> On Mon, 29 Sep 2014 15:11:51 +0200
> > >
On Tue, Aug 05, 2014 at 07:51:26AM -0700, Rodrigo Vivi wrote:
> From: Deepak S
>
> Higher RC6 residency is observed using timeout mode
> instead of EI mode. It's Recommended to use TO Method for RC6.
>
[TOR:] When I made the similar change for BDW, I understood timeout mode will
provide benefit
>>From: Ben Widawsky [mailto:b...@bwidawsk.net]
>>Sent: Friday, June 20, 2014 9:43 AM
>>On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
>>> Higher RC6 residency is observed using timeout mode instead of EI
>>> mode. This applies to Broadwell only.
>>> The difference is particularly n
>From: Ben Widawsky [mailto:b...@bwidawsk.net]
>Sent: Friday, June 20, 2014 9:43 AM
>On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
>> Higher RC6 residency is observed using timeout mode instead of EI
>> mode. This applies to Broadwell only.
>> The difference is particularly noticea
>---
>
>All, I intend to push this to drm-intel-fixes, any objections?
>
>Jani.
>---
[TOR:] I have no objections. Looks good to me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> This is just a merge mishap in one the chv patches. Someone just needs
>> to send a patch that moves the misapplied stuff to the appropriate chv
>> function.
>
>Right. So my first comment was correct, and my elaboration total bullcrap. This
>is not present in 3.15, but we've queued the screwup f
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Tuesday, June 03, 2014 12:38 AM
>To: O'Rourke, Tom
>Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Ben Widawsky; Kristen
>Carlson Accardi
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/bd
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, June 02, 2014 1:26 AM
>To: O'Rourke, Tom
>Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky; Kristen Carlson Accardi
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode f
>On Wed, Apr 30, 2014 at 02:14:02PM -0700, Kristen Carlson Accardi wrote:
>> On Thu, 01 May 2014 00:03:15 +0300
>> Imre Deak wrote:
>>
>> > On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote:
>> > > On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote:
>> > > > On Tue, 29 Apr
>+static void gen8_disable_rps_interrupts(struct drm_device *dev) {
>+ struct drm_i915_private *dev_priv = dev->dev_private;
>+
>+ I915_WRITE(GEN6_PMINTRMSK, 0x);
[TOR:] Please note that for Broadwell, bit 31 in GEN6_PMINTRMSK is not an
interrupt disable bit.
In "drm/i915: Enabl
>> > Higher RC6 residency is observed using timeout mode instead of EI
>> > mode. This applies to Broadwell only.
>> > The difference is particularly noticeable with video playback.
>> >
>> > Issue: VIZ-3778
>> > Change-Id: I62bb12e21caf19651034826b45cde7f73a80938d
>> > Signed-off-by: Tom O'Rourke
64 matches
Mail list logo
