Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5587
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5586
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 353/353
Thanks for the pointer, let me sync with Ville and get back.
regards,
Sivakumar
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Friday, January 16, 2015 1:08 AM
To: Thulasimani, Sivakumar
Cc: intel-gfx@lists.freedesktop.or
drm_plane_helper_{update,disable} are not specific to primary planes;
fix some copy/paste summaries to avoid confusion.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dri
Runtime state that can be manipulated via properties should now go in
intel_plane_state instead so that it can be tracked as part of an atomic
transaction.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 36
drivers/gpu/drm/i915/intel_drv
Add a transitional helper for planes' .set_property() entrypoint,
similar to what we already have for .update_plane() and
.disable_plane(). This allows drivers that are still in the process of
transitioning to implement and exercise the .atomic_set_property()
driver entrypoint that will eventually
When we flip on the DRIVER_ATOMIC bit, the DRM core will start calling
this entrypoint to set and lookup driver-specific plane property values,
rather than maintaining a shadow copy in object->properties.
Note that although we add these functions to the plane vtable, they will
not yet be called.
All of the previous refactoring/consolidation of plane code has resulted
in intel_primary_plane_funcs, intel_cursor_plane_funcs, and
intel_sprite_plane_funcs being identical. Replace all of these with a
single 'intel_plane_funcs' vtable for simplicity.
Signed-off-by: Matt Roper
---
drivers/gpu/
This switch allows us to exercise the .atomic_set_property() that will
be used by atomic. The only real changes we need to make here are:
* extract the property validation from our old set_property handler and
stick it in intel_plane_atomic_check().
* make intel_check_*_plane() functions capa
I had hoped to make this a full "nuclear pageflip" enablement series, but I
didn't have as much time to work on this today as I hoped, so I still need to
finish up the final integration with the DRM core atomic code. Several of my
early patches are working and relatively straightforward, so I figu
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5585
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
On Thu, Jan 15, 2015 at 05:05:30PM +, Tvrtko Ursulin wrote:
>
> On 01/15/2015 04:54 PM, Ben Widawsky wrote:
> >On Thu, Jan 15, 2015 at 11:21:30AM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>This eliminates six needless spin lock/unlock pairs when writing out ELSP.
> >>Apar
I didn't get how it shows different rates if the i915_drrs_status only
shows if panel supports or not.
Maybe the debugfs file could contain more info for each crtc connect,
crtc info, if panel connected there supports, if it is enabled and
also current freq.. then parse all here properly.
But one
On Sun, Jan 11, 2015 at 4:40 AM, Chris Wilson wrote:
> On Sat, Jan 10, 2015 at 02:26:04AM +0530, Vandana Kannan wrote:
>> Adding a debugfs entry to determine if DRRS is supported or not
>>
>> Signed-off-by: Vandana Kannan
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 18 ++
>>
Great!
Although I'd prefer at intel_drrs.c.. ;)
Reviewed-by: Rodrigo Vivi
On Fri, Jan 9, 2015 at 12:56 PM, Vandana Kannan
wrote:
> Adding an overview of DRRS in general and the implementation for eDP DRRS.
> Also, describing the functions related to eDP DRRS.
>
> Signed-off-by: Vandana Kannan
On Fri, Jan 9, 2015 at 12:56 PM, Vandana Kannan
wrote:
> From: Durgadoss R
>
> This patch enables eDP DRRS for CHV by adding the
> required IS_CHERRYVIEW() checks.
> CHV uses the same register bit as VLV.
>
> [Vandana]: Since CHV has 2 sets of M_N registers, it will follow the same code
> path as
Reviewed-by: Rodrigo Vivi
On Fri, Jan 9, 2015 at 12:56 PM, Vandana Kannan
wrote:
> Definition of VLV RR switch bit and corresponding toggling in
> set_drrs function.
>
> Signed-off-by: Vandana Kannan
> Signed-off-by: Uma Shankar
> Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_re
On Fri, Jan 9, 2015 at 12:56 PM, Vandana Kannan
wrote:
> For Broadwell, there is one instance of Transcoder MN values per transcoder.
> For dynamic switching between multiple refreshr rates, M/N values may be
> reprogrammed on the fly. Link N programming triggers update of all data and
> link M &
looks ok for me...
you will also have conflict so a rebased version is at:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=review-drrs
Reviewed-by: Rodrigo Vivi
On Fri, Jan 9, 2015 at 12:55 PM, Vandana Kannan
wrote:
> Calls have been added to invalidate/flush DRRS whenever invalidate/flus
On Fri, Jan 9, 2015 at 12:55 PM, Vandana Kannan
wrote:
> Calling enable/disable DRRS when enable/disable DDI are called.
> These functions are responsible for setup of drrs data (in enable) and
> reset of drrs (in disable).
> has_drrs is true when downclock_mode is found and SEAMLESS_DRRS is set i
On Thu, Jan 15, 2015 at 02:00:06PM +, Dave Gordon wrote:
> On 12/01/15 03:35, Ben Widawsky wrote:
> > WARNING: very minimally tested
> >
> > In general you should not need this tool. It's primary purpose is for
> > benchmarking, and for debugging performance issues.
> >
> > For many kernel re
On Thu, Jan 15, 2015 at 08:36:15PM +0100, Daniel Vetter wrote:
> On Wed, Jan 14, 2015 at 9:34 PM, Chris Wilson
> wrote:
> > This (partially) reverts
> >
> > commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
> > Author: Chris Wilson
> > Date: Tue Mar 25 13:23:06 2014 +
> >
> > drm/i915: I
You realize that Ville has implemented all this already and his
patches are only waiting for review?
-Daniel
On Thu, Jan 15, 2015 at 2:50 PM, Thulasimani, Sivakumar
wrote:
> Hi,
>
> I’ll be working on implementing Dynamic Voltage Frequency
> Scaling in i915, whose rough proposal i
On Wed, Jan 14, 2015 at 9:34 PM, Chris Wilson wrote:
> This (partially) reverts
>
> commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
> Author: Chris Wilson
> Date: Tue Mar 25 13:23:06 2014 +
>
> drm/i915: Invalidate our pages under memory pressure
Shouldn't we also revert the hunk in i9
On Thu, Jan 15, 2015 at 02:55:26PM +0200, Ander Conselvan de Oliveira wrote:
> The previous patch changed the config field in intel_crtc to a pointer,
> but to keep the mechanical changes (done with spatch) separate from the
> new code, the pointer was made to point to a new _config field with type
On Thu, Jan 15, 2015 at 05:27:50PM +, tim.g...@intel.com wrote:
> From: Tim Gore
>
> getsubopt is not available in android. The "get" option
> doesn't really need sub-options, just display all the
> current frequency settings (as per discussion with
> Ben Widawsky)
>
> Signed-off-by: Tim Gor
On 13/01/15 22:20, Daniel Vetter wrote:
> On Tue, Jan 13, 2015 at 09:48:51AM +, Gore, Tim wrote:
>>
>>
>>> -Original Message-
>>> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
>>> Daniel Vetter
>>> Sent: Monday, January 12, 2015 11:26 PM
>>> To: Gore, Tim
>>>
From: Tim Gore
getsubopt is not available in android. The "get" option
doesn't really need sub-options, just display all the
current frequency settings (as per discussion with
Ben Widawsky)
Signed-off-by: Tim Gore
---
man/intel_gpu_frequency.man | 6 +++---
tools/intel_gpu_frequency.c | 27 ++
On 15/01/15 14:00, Dave Gordon wrote:
[snip]
> Finally, I think the choice of command names (especially --set vs
> --custom) is confusing. I'd like to propose the following:
>
> # Reading:
> --get # get all
> --get namelist # get specified
> -g [namelist] # synonym
On 01/15/2015 04:54 PM, Ben Widawsky wrote:
On Thu, Jan 15, 2015 at 11:21:30AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This eliminates six needless spin lock/unlock pairs when writing out ELSP. Apart
from tidier code main benefit is between 0.51% and 0.73% speedup on some OGL
tests
On Thu, Jan 15, 2015 at 11:21:30AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This eliminates six needless spin lock/unlock pairs when writing out ELSP.
> Apart
> from tidier code main benefit is between 0.51% and 0.73% speedup on some OGL
> tests under CHV (bench_OglBatch4 bench_Og
On 12/01/15 03:35, Ben Widawsky wrote:
> WARNING: very minimally tested
>
> In general you should not need this tool. It's primary purpose is for
> benchmarking, and for debugging performance issues.
>
> For many kernel releases now sysfs has supported reading and writing the GPU
> frequency. The
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Tuesday, January 13, 2015 10:20 PM
> To: Gore, Tim
> Cc: Daniel Vetter; Gordon, David S; intel-gfx@lists.freedesktop.org; Wood,
> Thomas
> Subject: Re: [Intel-gfx] [PAT
Hi,
I'll be working on implementing Dynamic Voltage Frequency
Scaling in i915, whose rough proposal is provided below. Please go through the
options and provide your feedback.
What is DVFS ?
Any SKU is capable of running at more than one display CD clock
value bu
The first pass implementation of execlists required a backpointer to the
context to be held
in the intel_ringbuffer. However the context pointer is available higher in the
call stack.
Remove the backpointer from the ring buffer structure and instead pass it down
through the
call stack.
v2: Inte
Move all remaining elements that were unique to execlists queue items
in to the associated request.
Issue: VIZ-4274
v2: Rebase. Fixed issue of overzealous freeing of request.
v3: Removed re-addition of cleanup work queue (found by Daniel Vetter)
v4: Rebase.
v5: Actual removal of intel_ctx_submit_
Add a reference and pointer from the execlist queue item to the associated
gem request. For execlist requests that don't have a request, create one
as a placeholder.
Issue: VIZ-4274
v1: Rebase after upstream of "Replace seqno values with request structures"
patchset.
Signed-off-by: Nick Hoath
--
Where there were duplicate variables for the tail, context and ring (engine)
in the gem request and the execlist queue item, use the one from the request
and remove the duplicate from the execlist queue item.
Issue: VIZ-4274
v1: Rebase
v2: Fixed build issues. Keep separate postfix & tail pointers
This patchset merges execlist queue items in to gem requests. It does this by
using the reference count added by the "Replace seqno values with
request structures" patchset to ensure that the gem request is available for
the whole execlist submission lifespan.
v2: merge intel_ctx_submit_request a
So that atomic operations will reference the right crtc state.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 002e5a9..b6c4
This reduces the number of direct users of crtc->new_config, opening up
the possibilty of removing it altogether.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_ddi.c | 29
drivers/gpu/drm/i915/intel_display
To match the semantics of drm_crtc->state, which this will eventually
become. The allocation of the memory for config will be fixed in a
followup patch. By adding the extra _config field to intel_crtc it was
possible to generate this entire patch with the cocci script below.
@@ @@
struct intel_crt
In functions that define a local pipe_config variable to point to
crtc->config, replace remaining references to crtc->config with
the local variable. This makes the code more consistent and easier
to change in an automated manner.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i
The previous patch changed the config field in intel_crtc to a pointer,
but to keep the mechanical changes (done with spatch) separate from the
new code, the pointer was made to point to a new _config field with type
struct intel_crtc_state added to that struct. This patch improves that
code by get
This series goes through a number of (mostly automated) changes to make
the core drm_crtc->state pointer correspond a crtc's pipe_config.
v2: Dropped the patches that remove intel_crtc->new_config
Ander Conselvan de Oliveira (7):
drm/i915: Rename struct intel_crtc_config to intel_crtc_state
d
And get rid of the duplicate mode structures. This patch was generated
with the following semantic patch:
@@ @@
struct intel_crtc_state {
+struct drm_crtc_state base;
+
...
-struct drm_display_mode requested_mode;
-struct drm_display_mode adjusted_mode;
...
}
@@ struct intel_crtc_state *state; @@
The objective is to make this structure usable with the atomic helpers,
so let's start with the rename. Patch generated with coccinelle:
@@ @@
-struct intel_crtc_config {
+struct intel_crtc_state {
...
}
@@ @@
-struct intel_crtc_config
+struct intel_crtc_state
v2: Completely generate the patch wi
Instead of pushing each byte via stack the specifier allows to supply the
pointer and length to dump buffers up to 64 bytes long.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_
On Wed, 14 Jan 2015, "Singh, Gaurav K" wrote:
> On 12/12/2014 1:03 PM, Singh, Gaurav K wrote:
>>
>> On 12/10/2014 7:38 PM, Gaurav K Singh wrote:
>>> For CHT changes are required for calculating the correct m,n & p with
>>> minimal error +/- for the required DSI clock, so that the correct
>>> divi
From: Tvrtko Ursulin
This eliminates six needless spin lock/unlock pairs when writing out ELSP. Apart
from tidier code main benefit is between 0.51% and 0.73% speedup on some OGL
tests under CHV (bench_OglBatch4 bench_OglDeferred respectively).
Kindly benchmarked by Ben Widawsky.
Signed-off-by:
Hi Dave, another round of fixes for v3.19.
BR,
Jani.
The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115:
linux 3.19-rc4 (2015-01-11 12:44:53 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-01-15
for
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5579
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Wednesday, January 14, 2015 11:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/5] drm/i915: Fallback to using CPU relocations
> for large b
On Thu, Jan 15, 2015 at 01:55:52AM +0100, Daniel Vetter wrote:
> On Wed, Jan 14, 2015 at 08:34:31PM +, Chris Wilson wrote:
> > This (partially) reverts
> >
> > commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
> > Author: Chris Wilson
> > Date: Tue Mar 25 13:23:06 2014 +
> >
> > drm/i9
On Thu, Jan 15, 2015 at 02:04:02AM +, Jindal, Sonika wrote:
> So, if we do the source and dst adjustments in userspace, the logic in
> intel_check_sprite_plane will not hold good there.
I'm not sure what adjustments you mean. Src says exactly which part of
the FB you want to present to the us
On Wed, Jan 14, 2015 at 08:46:09PM +0100, Daniel Vetter wrote:
> > + if (obj->cache_dirty &&
> > +obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
> > +cpu_write_needs_clflush(obj) &&
> > +i915_gem_clflush_object(obj, true))
>
> Imo hiding the actual action in the if condition like thi
56 matches
Mail list logo
