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 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 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 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 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: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
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: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 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
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 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
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 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
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
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
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
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
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
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
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
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 ++
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
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
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
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
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 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/
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
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
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
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
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
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
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
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
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
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
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 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
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 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 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 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 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: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: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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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
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, 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
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, 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: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, 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: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
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
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
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
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_
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
101 - 173 of 173 matches
Mail list logo
