On Thu, 2015-02-26 at 12:50 +, Chris Wilson wrote:
> On Thu, Feb 26, 2015 at 06:19:37PM +0530, akash.g...@intel.com wrote:
> > +#define GT_INTERVAL_FROM_US(us) (IS_GEN9(dev_priv->dev) ? \
> > + INTERVAL_1_33_US(us) : \
> > + INTERVAL_1_28_US(u
On Thu, Mar 05, 2015 at 02:12:07PM +0530, Akash Goel wrote:
> On Thu, 2015-02-26 at 12:50 +, Chris Wilson wrote:
> > On Thu, Feb 26, 2015 at 06:19:37PM +0530, akash.g...@intel.com wrote:
> > > +#define GT_INTERVAL_FROM_US(us) (IS_GEN9(dev_priv->dev) ? \
> > > + INTERVAL_
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using sr
For primary plane, we can use the plane's state for src width and height
like sprite plane.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/d
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_display.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 437a679..e1b0c4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
On Thu, Feb 26, 2015 at 06:19:39PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> On SKL the frequency is specified in units of 16.66 MHZ, barring the
> RP_STATE_CAP(0x5998) register, which still reports frequency in units
> of 50 MHZ. So an extra conversion is required in gen6_init_rp
On Thu, Feb 26, 2015 at 06:19:38PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> On SKL, frequency is specified in units of 16.66 MHZ.
> Updated the intel_gpu_freq() and intel_freq_opecode() functions
> to do the conversion appropriately.
>
> Signed-off-by: Akash Goel
Reviewed-by:
On Thu, Feb 26, 2015 at 06:19:42PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> RP Interrupt Up/Down Frequency Limits register (A014) definition
> has changed for SKL. Updated the gen6_rps_limits function as per that
>
> v2: Renamed the function to intel_rps_limits (Chris)
>
> Sign
On Thu, 2015-03-05 at 12:14 +0200, Ville Syrjälä wrote:
> On Thu, Feb 26, 2015 at 06:19:39PM +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
> >
> > On SKL the frequency is specified in units of 16.66 MHZ, barring the
> > RP_STATE_CAP(0x5998) register, which still reports frequency in uni
On Thu, Feb 26, 2015 at 06:19:40PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> On SKL, the frequency is programmed differently in RPNSWREQ (A008)
> register (from bits 23 to 31, compared to bits 24 to 31). So updated
> the gen6_set_rps function, as per this change.
>
> Signed-off-b
On Thu, Feb 26, 2015 at 06:19:45PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> Added support for SKL in the act_freq_mhz_show sysfs function
>
> Signed-off-by: Akash Goel
Again required a bit of mail juggling to double chekc the definition,
but looks correct.
Reviewed-by: Ville
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5890
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 280/280
On Thu, 2015-03-05 at 09:43 +0200, Jani Nikula wrote:
> On Wed, 04 Mar 2015, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2015 at 08:11:38PM +0530, Purushothaman, Vijay A wrote:
> >> Minor nitpick: typo in patch title
> >
> > Dang. I already fixed a typo there before sending this out, but turns
> > ou
On Wed, Mar 04, 2015 at 03:00:17PM -0800, Rodrigo Vivi wrote:
> On Tue, Mar 3, 2015 at 7:23 AM, Ramalingam C wrote:
> > From: Vandana Kannan
> >
> > Adding a debugfs entry to determine if DRRS is supported or not
> >
> > V2: [By Ram]: Following details about the active crtc will be filled
> >
On Thursday 05 March 2015 04:48 PM, Daniel Vetter wrote:
On Wed, Mar 04, 2015 at 03:00:17PM -0800, Rodrigo Vivi wrote:
On Tue, Mar 3, 2015 at 7:23 AM, Ramalingam C wrote:
From: Vandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details ab
Hi Dave, two i915 fixes, both of them cc: stable.
BR,
Jani.
The following changes since commit 13a7a6ac0a11197edcd0f756a035f472b42cdf8b:
Linux 4.0-rc2 (2015-03-03 09:04:59 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-03-0
On Wed, Mar 04, 2015 at 02:55:23PM -0800, Rodrigo Vivi wrote:
> Looks enough for me...
>
> Reviewed-by: Rodrigo Vivi
>
> On Mon, Mar 2, 2015 at 10:41 PM, Ramalingam C wrote:
> > In invalidate and flush functions of eDP DRRS, if deferred downclock
> > work starts execution at a time window betwe
On Wed, Mar 04, 2015 at 08:54:21PM +, Vivi, Rodrigo wrote:
> On Wed, 2015-03-04 at 15:03 -0300, Paulo Zanoni wrote:
> > 2015-03-03 21:57 GMT-03:00 Rodrigo Vivi :
> > > On Fri, Feb 13, 2015 at 11:23 AM, Paulo Zanoni wrote:
> > >> From: Paulo Zanoni
> > >>
> > >> Kill the blt/render tracking we
On Thu, Mar 05, 2015 at 10:02:30AM +0530, Sonika Jindal wrote:
> eDp 1.4 supports custom frequencies.
> Skylake supports following intermediate frequencies : 3.24 GHz, 2.16 GHz and
> 4.32 GHz along with usual LBR, HBR and HBR2 frequencies.
> Read sink supported frequencies and get common frequencie
On Wed, Mar 04, 2015 at 03:05:11PM -0800, Rodrigo Vivi wrote:
> On Wed, Mar 4, 2015 at 6:30 AM, Daniel Vetter wrote:
> > On Tue, Mar 03, 2015 at 08:03:13PM +, Vivi, Rodrigo wrote:
> >> On Tue, 2015-03-03 at 09:28 +0100, Daniel Vetter wrote:
> >> > On Mon, Mar 02, 2015 at 06:35:26PM +, Vivi
On Wed, Mar 04, 2015 at 09:14:39PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 04, 2015 at 02:55:17PM +0200, Mika Kuoppala wrote:
> > If the requested size is less than what the full range
> > of pdps can address, we end up setting pdps for only the
> > requested area.
> >
> > The logical context ho
On Wed, Mar 04, 2015 at 11:58:41AM -0800, Ben Widawsky wrote:
> On Tue, Mar 03, 2015 at 05:03:29PM +0200, Mika Kuoppala wrote:
> > If the mappable size is less than what the full range
> > of pdps can address, we end up setting pdps for only the
> > mappable area.
> >
> > The logical context howev
On Wed, Mar 04, 2015 at 08:21:16PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 04, 2015 at 05:13:07PM +0100, Daniel Vetter wrote:
> > On Wed, Mar 04, 2015 at 11:45:42AM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 03, 2015 at 06:15:12PM -0800, Matt Roper wrote:
> > > > Universal planes allow us to h
On Wed, Mar 04, 2015 at 06:09:26PM +, Chris Wilson wrote:
> This fixes a regression from
>
> commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9
> Author: Thomas Gleixner
> Date: Wed Jul 16 21:05:06 2014 +
>
> drm: i915: Use nsec based interfaces
>
> that made a negative timeout retur
On Wed, Mar 04, 2015 at 10:50:53AM -0800, Matt Roper wrote:
> i915 was using the main atomic 'disable plane' to turn off sprite planes
> during a CRTC disable. This was problematic because it modified the
> plane state, preventing us from recovering the original state later.
> One such case was th
On Wed, Mar 04, 2015 at 10:49:04AM -0800, Matt Roper wrote:
> We need to disable all sprite planes when disabling the CRTC. We had
> been using the top-level atomic 'disable' entrypoint to accomplish this,
> which was wrong. Not only can this lead to various locking issues, it
> also modifies the
On Thu, Mar 05, 2015 at 01:20:17PM +0100, Daniel Vetter wrote:
> On Wed, Mar 04, 2015 at 08:21:16PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2015 at 05:13:07PM +0100, Daniel Vetter wrote:
> > > On Wed, Mar 04, 2015 at 11:45:42AM +0200, Ville Syrjälä wrote:
> > > > On Tue, Mar 03, 2015 at 06:
On Thu, Mar 05, 2015 at 02:56:52AM +, Song, Ruiling wrote:
> Hi Daniel,
>
> OpenCL language support NULL pointer, using zero as the NULL pointer is
> the obvious way. That is zero will be treated as invalid address. Then
> it requires drm won't allocate zero to drm buffer. And David in CC
> l
On Thu, Mar 05, 2015 at 02:51:26PM +0530, Sonika Jindal wrote:
> Signed-off-by: Sonika Jindal
Imo this needs a little more commit message, and more important it needs
igt test coverage. Best approach there is probably to take the plane test
we have already and extend it to the primary plane.
-Dan
On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote:
> @@ -1519,16 +1550,7 @@ intel_plane_init(struct drm_device *dev, enum pipe
> pipe, int plane)
> goto out;
> }
>
> - if (!dev->mode_config.rotation_property)
> - dev->mode_config.rotation_property
On Thu, Mar 05, 2015 at 02:51:27PM +0530, Sonika Jindal wrote:
> For primary plane, we can use the plane's state for src width and height
> like sprite plane.
>
> Signed-off-by: Sonika Jindal
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 ++
> 1 file changed, 6 insertions(+), 4 del
On Thu, Mar 05, 2015 at 01:52:51PM +0100, Daniel Vetter wrote:
> On Thu, Mar 05, 2015 at 02:56:52AM +, Song, Ruiling wrote:
> > Hi Daniel,
> >
> > OpenCL language support NULL pointer, using zero as the NULL pointer is
> > the obvious way. That is zero will be treated as invalid address. Then
On Thu, Mar 05, 2015 at 04:52:47PM +0530, Ramalingam C wrote:
> On Thursday 05 March 2015 04:48 PM, Daniel Vetter wrote:
> >Also it's usually much more informative to dump all the
> >frontbuffer bits instead of just a busy/idle answer - if there's a bug in
> >the frontbuffer tracking it's good to k
On 26/02/2015 02:26, Daniel Vetter wrote:
On Wed, Feb 25, 2015 at 11:17:00PM +0100, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:14AM +, john.c.harri...@intel.com wrote:
From: John Harrison
For some reason, the i915_add_request() call in
i915_gem_execbuffer_retire_commands() was exp
On Thu, Mar 05, 2015 at 01:56:53PM +0100, Daniel Vetter wrote:
> On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote:
> > @@ -1519,16 +1550,7 @@ intel_plane_init(struct drm_device *dev, enum pipe
> > pipe, int plane)
> > goto out;
> > }
> >
> > - if (!dev->mode_config
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5892
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 280/280
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
There is a flags word that is passed through the execbuffer code path all the
way from initial decoding of the user parameters down to the very final dispatch
buffer call. It is simply called 'flags'. Unfortuantely, there
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
There is a trace point in the legacy execbuffer execution path that is missing
from the execlist path. Trace points are extremely useful for debugging and are
used by various automated validation tests. Hence, this patch
From: John Harrison
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplies the prototype by passing a p
From: John Harrison
In execlist mode, the context object pointer is written in to the request
structure (and reference counted) at the point of request creation. In legacy
mode, this only happens inside i915_add_request().
This patch updates the legacy code path to match the execlist version. Th
v2 : Handle M2 frac division for both M2 frac and int cases
v3 : Addressed Ville's review comments. Cleared the old bits for RMW
v4 : Fix feedfwd gain (Ville)
Signed-off-by: Vijay Purushothaman
Signed-off-by: Ville Syrjala
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i91
On 3/3/2015 9:08 PM, Ville Syrjälä wrote:
On Tue, Mar 03, 2015 at 08:43:12PM +0530, Vijay Purushothaman wrote:
Initialize lock detect threshold and select coarse threshold for the
case where M2 fraction division is disabled.
v2: Split the changes into multiple smaller patches based on review by
From: John Harrison
A bunch of the low level LRC functions were passing around ringbuf and
ctx pairs. In a few cases, they took the r/c pair and a request as
well. This is all quite messy and unnecesary.
Updated those functions to just take the request structure.
For: VIZ-5115
Signed-off-by: Jo
From: John Harrison
The LRC submission code requires a request for tracking purposes. It does not
actually require that request to 'complete' it simply uses it for keeping hold
of reference counts on contexts and such like.
In the case where the ring buffer is completely full, the LRC code looks
From: John Harrison
The submission portion of the execbuffer code path was abstracted into a
function pointer indirection as part of the legacy vs execlist work. The two
implementation functions are called 'i915_gem_ringbuffer_submission' and
'intel_execlists_submission' but the pointer was calle
Initialize lock detect threshold and select coarse threshold for the
case where M2 fraction division is disabled.
v2: Split the changes into multiple smaller patches (Ville)
v3: Clear out the old bits before we modify those bits as RMW (Ville)
v4: Reset coarse threshold when M2 fraction is enabled
On 3/3/2015 9:06 PM, Ville Syrjälä wrote:
On Tue, Mar 03, 2015 at 08:41:54PM +0530, Vijay Purushothaman wrote:
v2 : Handle M2 frac division for both M2 frac and int cases
v3 : Addressed Ville's review comments. Cleared the old bits for RMW
Signed-off-by: Vijay Purushothaman
---
drivers/gpu/
From: John Harrison
Apparently, this has never worked reliably and is currently disabled. Also, the
gains are not particularly impressive. Thus rather than try to keep unused code
from decaying and having to update it for other driver changes, it was decided
to simply remove it.
For: VIZ-5115
Si
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, the ringbuf is a function of the ring and context whereas in
legacy mode, it is derived from the ring alone. Thus the calculation required to
determine the ringbuf pointer from the ring (and context) als
On Tue, 2015-03-03 at 13:49 +, Chris Wilson wrote:
>
> It's an OR. The bug I am thinking about has a w/a in the ddx and a real
> fix in the kernel. Either one should do, and I think will resolve your
> issue.
Yeah, upgrading to that newer Intel driver did seem to do the trick. I
wonder if it
This patch implements latest PHY changes in Gain, prop and int co-efficients
based on the vco freq.
v2: Split the original changes into multiple smaller patches based on
review by Ville
v3: Addressed Ville's review comments. Fixed the error introduced in v2.
Clear the old bits before we modify th
drivers/gpu/drm/i915/intel_ringbuffer.c:435:1-4: WARNING: end returns can be
simpified
Simplify a trivial if-return sequence. Possibly combine with a
preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci
CC: Paulo Zanoni
Signed-off-by: Fengguang Wu
---
intel_r
From: Tvrtko Ursulin
Plane state carries the rotation information which is needed for determining
the appropriate GGTT view type.
This just adds the parameter with the actual usage coming in future patches.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 18 ++
From: Tvrtko Ursulin
Display engine on Skylake can scan out specially prepared frame buffers
rotated by 90 or 270 degrees.
This adds partial support for this and will need some patches from Sonika to
complete the feature.
Going by "looking pretty" comment by Daniel Vetter (on IRC) I think this
From: Tvrtko Ursulin
It will be used in a later patch and also convert all height parameters
from int to unsigned int.
v2: Rebased for fb modifiers.
v3: Fixed v2 rebase.
v4:
* Height should be unsigned int.
* Make it take pixel_format for consistency and simplicity.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
v2: Pass in rotation info to sprite plane updates as well.
v3: Use helper to determine 90/270 rotation. (Michel Thierry)
v4: Rebased for fb modifiers and atomic changes.
For: VIZ-4546
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Michel Thierry (v3)
---
drivers/gpu/drm/i91
From: Tvrtko Ursulin
Need to do this in order to support 90/270 rotated display.
v2: Pass in drm_plane instead of plane index to intel_obj_display_address.
v3:
* Renamed intel_obj_display_address to intel_plane_obj_offset.
(Chris Wilson)
* Simplified rotation check to bitwise AND.
From: Tvrtko Ursulin
90/270 rotated scanout needs a rotated GTT view of the framebuffer.
This is put in a separate VMA with a dedicated ggtt view and wired such that
it is created when a framebuffer is pinned to a 90/270 rotated plane.
Rotation is only possible with Yb/Yf buffers and error is p
From: Tvrtko Ursulin
To support frame buffer rotation we need to be able to pass on the information
on what kind of GGTT view is required for display.
This patch just adds the parameter and makes all the callers default to the
normal view.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i91
From: Tvrtko Ursulin
For now only default implementation defaulting to normal view.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/dri
On Thu, Mar 05, 2015 at 09:04:54AM -0500, Brian J. Murrell wrote:
> On Tue, 2015-03-03 at 13:49 +, Chris Wilson wrote:
> >
> > It's an OR. The bug I am thinking about has a w/a in the ddx and a real
> > fix in the kernel. Either one should do, and I think will resolve your
> > issue.
>
> Yeah
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Further, it is due to grow massively with the arrival of the GPU sche
On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote:
>
> This warning is moved from linux-next to v4.0-rc1 now. After system boot is
> just a black screen.
> I ssh'ed into the machine and saved the log. I attached updated dmesg.log
> with drm.debug=6. Hopefully it helps.
> If you n
Michel Thierry writes:
> From: Ben Widawsky
>
> This patch just breaks out the logic of context switch skip.
>
> It also adds pd load pre, and pd load post logic (for GEN8).
>
I dont think this patch just breaks out the logic but it changes
it. And the reasons remains a mystery.
Could you plea
On Thu, Mar 05, 2015 at 07:33:08PM +0530, Vijay Purushothaman wrote:
> This patch implements latest PHY changes in Gain, prop and int co-efficients
> based on the vco freq.
>
> v2: Split the original changes into multiple smaller patches based on
> review by Ville
>
> v3: Addressed Ville's review
On Thu, Mar 05, 2015 at 01:06:10PM +, John Harrison wrote:
> On 26/02/2015 02:26, Daniel Vetter wrote:
> >On Wed, Feb 25, 2015 at 11:17:00PM +0100, Daniel Vetter wrote:
> >>On Fri, Feb 13, 2015 at 11:48:14AM +, john.c.harri...@intel.com wrote:
> >>>From: John Harrison
> >>>
> >>>For some r
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
For some reason, the i915_add_request() call in
i915_gem_execbuffer_retire_commands() was explicitly having its return code
ignored. The _retire_commands() function itself was 'void'. Given that
_add_request() can fail wi
On Thu, Mar 05, 2015 at 01:57:31PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The LRC submission code requires a request for tracking purposes. It does not
> actually require that request to 'complete' it simply uses it for keeping hold
> of reference counts on contexts and
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
In order to explicitly manage requests from creation to submission, it is
necessary to be able to explicitly create them in the first place. This patch
adds an indirection wrapper to the request creation function so that
On Thu, Mar 05, 2015 at 01:32:19PM +0100, Daniel Vetter wrote:
> On Wed, Mar 04, 2015 at 10:50:53AM -0800, Matt Roper wrote:
> > i915 was using the main atomic 'disable plane' to turn off sprite planes
> > during a CRTC disable. This was problematic because it modified the
> > plane state, prevent
On 05/03/2015 14:44, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 01:06:10PM +, John Harrison wrote:
On 26/02/2015 02:26, Daniel Vetter wrote:
On Wed, Feb 25, 2015 at 11:17:00PM +0100, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:14AM +, john.c.harri...@intel.com wrote:
From: Jo
On 03/04/2015 05:42 PM, Matt Roper wrote:
On Wed, Mar 04, 2015 at 05:26:36PM +, Tvrtko Ursulin wrote:
On 03/04/2015 02:15 AM, Matt Roper wrote:
Universal planes allow us to have an active CRTC without a primary plane
framebuffer bound. Drop the test for primary->fb from
intel_crtc_active
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Start of explicit request management in the execbuffer code path. This patch
adds a call to allocate a request structure before all the actual hardware work
is done. Thus guaranteeing that all that work is tagged by a kno
On Thu, Mar 05, 2015 at 02:03:03PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Apparently, this has never worked reliably and is currently disabled. Also,
> the
> gains are not particularly impressive. Thus rather than try to keep unused
> code
> from decaying and having t
On Thu, Mar 05, 2015 at 01:01:21PM +, Chris Wilson wrote:
> On Thu, Mar 05, 2015 at 01:52:51PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:56:52AM +, Song, Ruiling wrote:
> > > Hi Daniel,
> > >
> > > OpenCL language support NULL pointer, using zero as the NULL pointer is
> >
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly allocated
request. Instead, it must be pulled from ring->outstanding_lazy_request. This
patch fixes this so that code can create a request and start using it
On Thu, Mar 05, 2015 at 03:08:17PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 05, 2015 at 01:56:53PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote:
> > > @@ -1519,16 +1550,7 @@ intel_plane_init(struct drm_device *dev, enum pipe
> > > pipe, int plane)
On Thu, Mar 05, 2015 at 10:03:08PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/i915/intel_ringbuffer.c:435:1-4: WARNING: end returns can be
> simpified
>
> Simplify a trivial if-return sequence. Possibly combine with a
> preceding function call.
> Generated by: scripts/coccinelle/misc/si
On 05/03/2015 15:22, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 02:03:03PM +, john.c.harri...@intel.com wrote:
From: John Harrison
Apparently, this has never worked reliably and is currently disabled. Also, the
gains are not particularly impressive. Thus rather than try to keep unused co
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Rather than just having a local request variable in the execbuff code, the
request pointer is now stored in the execbuff params structure. Also added
explicit cleanup of the request (plus wiping the OLR to match) in the e
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated a couple of trace points to use the now cached request pointer rather
than extracting it from the ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
dri
On 05/03/2015 15:27, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly
allocated
request. Instead, it must be pulled from
ring->outstanding_lazy_request. This
patch fixes this so that cod
On Mon, Feb 16, 2015 at 01:21:34PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 16, 2015 at 03:07:59PM +0530, Vijay Purushothaman wrote:
> > As per the recommendation from PHY team, limit the max vco supported in CHV
> > to 6.48 GHz
> >
> > Signed-off-by: Vijay Purushothaman
> > ---
> > drivers/gp
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the move_to_gpu() code paths.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gp
On Thu, Mar 05, 2015 at 04:29:30PM +0100, Daniel Vetter wrote:
> On Thu, Mar 05, 2015 at 03:08:17PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 05, 2015 at 01:56:53PM +0100, Daniel Vetter wrote:
> > > On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote:
> > > > @@ -1519,16 +1550,7 @@ inte
On Thu, Mar 05, 2015 at 04:52:56PM +0100, Daniel Vetter wrote:
> On Mon, Feb 16, 2015 at 01:21:34PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 16, 2015 at 03:07:59PM +0530, Vijay Purushothaman wrote:
> > > As per the recommendation from PHY team, limit the max vco supported in
> > > CHV to 6.48 G
From: Deepak S
In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in
C6 in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0
transition delays can result in performance impact
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the
execbuffer_move_to_active() code path.
For: VIZ-5115
Signed-off-by: John Harrison
---
On Thu, Mar 05, 2015 at 03:06:42PM +, John Harrison wrote:
> On 05/03/2015 14:44, Daniel Vetter wrote:
> >Imo reserving a bit of ring space for each add_request should be solid.
> >Userspace uses the exact same reservation logic for adding end-of-batch
> >workarounds. The only thing needed to m
Time to switch over all the IS_GENX() macros to the new device object.
Nothing more than a mechanical search & replace here.
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 7 +-
intel/intel_chipset.h | 158 --
intel/intel_decode.c
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index e22a867..9a8df6a 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -181,16 +181,6 @@
#define PCI_CHIP_SKYLAKE
We were pulling a few PCI ids, we can just hardcode them, it doesn't
change much.
Signed-off-by: Damien Lespiau
---
intel/test_decode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index 1ffd829..b9897b3 100644
--- a/intel/t
Turns out nobody was using it, nor the underlying defines.
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index a8a2b0e..241d700 100644
--- a/intel/intel_chipset.h
+++ b/int
While the bitwise operator should do the right thing here, it's probably
better to use the logical or here, at least to not cause a 'wtf' when
reading the code.
At the same time, get rid of unnecessary '()'.
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 4 ++--
1 file changed, 2
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 58 +++-
1 file changed, 8 insertions(+), 50 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 33d8fbc..72a6ab1 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/i
IS_9XX() has grown to mean gen >= 3. It was only used in a single test:
(IS_9XX && !IS_GEN3)
Which has then be replaced with gen >= 4.
The code in that area was idented a bit weirdly, so do a pass on that as
well.
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 9 -
intel
A couple of things I wanted to do for the longest time:
- Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy the
file when updating
- Start a new object, struct drm_intel_device where we could put common code
across several userspace projects. For instance it coul
The intention here is to:
- have a single object that represents a device
- reuse the kernel i915_pciids.h file so we only one place to update
and copy the file over.
- hide the various information about an intel device in that object
instead of having endless #define in intel_chip
One more step towards getting rid of intel_chipset.h. The slightly
tricky bit here is that I don't want to leave defines like IS_CHIP() or
IS_GEN4() is a file that can potentially become a public header.
intel_device_priv.h was introduced then.
Signed-off-by: Damien Lespiau
---
intel/Makefile.so
Finally, we can remove this file now that everything is using
drm_intel_device.
Signed-off-by: Damien Lespiau
---
intel/Makefile.sources | 1 -
intel/intel_bufmgr_gem.c | 1 -
intel/intel_chipset.h| 184 ---
intel/intel_decode.c | 1 -
1 - 100 of 173 matches
Mail list logo
