HI Kausal,
You don't need to send the entire series again .
Just send the updated patch --in-reply-to to the last message.
Otherwise the thread gets lost.
You can send the entire series once the review is complete and you feel that
the patches are too nested inside.
Please keep sending the patch
On Thu, Jun 4, 2015 at 11:27 AM, Peter Antoine wrote:
> This change adds the programming of the MOCS registers to the gen 9+
> platforms. This change set programs the MOCS register values to a set
> of values that are defined to be optimal.
>
> It creates a fixed register set that is programmed ac
On Thu, Jun 04, 2015 at 07:28:31PM +0300, Ville Syrjälä wrote:
> So besides avoiding the disconnected->unknown transition, the other thing
> we now seem to do is set intel_tv->type to -1 when we find that things
> are disconnected. However that doesn't seem to be user visible, and I
> can't see any
On Sun, May 31, 2015 at 11:50:26AM +0200, Bálint Pámer wrote:
>Hello!
>
>In a nutshell:
>I have a problem where my linux box hooked up to my sharp lcd tv can only
>output 1080p@30hz OR 1080i@60hz under linux (opensuse 13.2), but CAN
>output 1080p@60hz under windows. (meaning in
On Wed, May 27, 2015 at 4:39 PM, <> wrote:
> On Thu, May 21, 2015 at 12:17:48AM +0100, Robert Bragg wrote:
>> >
>> > So for me the 'natural' way to represent this in perf would be through
>> > event groups. Create a perf event for every single event -- yes this is
>> > 53 events.
>>
>> So when I wa
I just noticed that I had forgotten to reply-all...
Jani, would you consider merge this fix with the explanation above
related to Ville's question?
or do you want/need any action here?
Thanks,
Rodrigo.
-- Forwarded message --
From: Rodrigo Vivi
Date: Fri, May 29, 2015 at 9:45
This change adds the programming of the MOCS registers to the gen 9+
platforms. This change set programs the MOCS register values to a set
of values that are defined to be optimal.
It creates a fixed register set that is programmed across the different
engines so that all engines have the same tab
Note that this is a new patch to the series. The issue was found when
debugging a problem with the conversion to struct fence that is still in
progress. Basically, it was possible to get continuous TDR timeouts on
the ECS ring because the start of day initialisation request never got
retired an
From: John Harrison
A previous patch (read-read optimisation) changed the early exit
condition in i915_gem_retire_requests_ring() from checking the request
list to checking the active list. This assumes that all requests have
objects associated with them which are placed on the active list. The
r
Signed-off-by: Damien Lespiau
---
tests/pm_rpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index a1f4013..2a83a75 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -669,9 +669,9 @@ static void setup_pc8(void)
if (!supports_pc
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 47636f3..d8bd4e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d8bd4e1..92cf273 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915
Ville's and Mika's cdclk series was in flight at the same time as the
SKL S3 patches so we were missing that update.
intel_update_max_cdclk() and intel_update_cdclk() had to be moved up a
bit to avoid forward declarations.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c |
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c38c297..a96f181 100644
--- a
We can operate with DPLL0 off with CDCLK backed by the 24Mhz reference
clock, and that's a supported configuration. Don't warn when notice
DPLL0 is off then.
We still have a separate warn at boot if cdclk is disabled (because we
don't currently try to handle the case (that shouldn't happen on SKL
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 47c765d..a232dc9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/dr
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a232dc9..a018465 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/dr
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_display.c | 13 -
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0f72c0e..cfe262c 100
intel_update_cdclk() will already display the boot CDCLK for DDI
platforms, no need to repeat there.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i9
On Thu, Jun 04, 2015 at 04:47:00PM +0100, Chris Wilson wrote:
> On Thu, Jun 04, 2015 at 04:42:16PM +0100, Damien Lespiau wrote:
> > It's handy to have debug message for the "big" events and this one
> > qualifies IMHO. Also helpful to see what's happening while we're loading
> > the firwmare and ho
On Thu, Jun 04, 2015 at 04:56:18PM +0100, Damien Lespiau wrote:
> I noticed one of those and it turned out we have a few lingering around.
Yuck. I'd prefer we got the other way. Consider the following diffs for example:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.
On Thu, Jun 04, 2015 at 04:26:18PM +0100, Chris Wilson wrote:
> For old-school component TV and CRT connectors, we require a heavyweight
> load-detection mechanism. This involves setting up a CRTC and sending a
> signal to the output, before reading back any response. As that is quite
> slow and CP
Acked-by: Rodrigo Vivi
On Thu, Jun 4, 2015 at 7:31 AM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Use the igt_set_module_param_int() call to enable it, then restore the
> previous value after we are done testing.
>
> With this, we can change the psr_enabled() function to psr_possible():
> the
I noticed one of those and it turned out we have a few lingering around.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display
On Thu, Jun 04, 2015 at 04:42:16PM +0100, Damien Lespiau wrote:
> It's handy to have debug message for the "big" events and this one
> qualifies IMHO. Also helpful to see what's happening while we're loading
> the firwmare and how much time it takes.
>
> Signed-off-by: Damien Lespiau
> ---
> dri
In Linux, macros are usually well done and protect their arguments
properly, even avoiding multiple evaluations of the parameters. Extra ()
are really not needed.
Cc: Suketu Shah
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_csr.c | 3 ++-
1 file changed, 2 insertions(+), 1 delet
It's handy to have debug message for the "big" events and this one
qualifies IMHO. Also helpful to see what's happening while we're loading
the firwmare and how much time it takes.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_csr.c | 3 +++
1 file changed, 3 insertions(+)
diff -
For old-school component TV and CRT connectors, we require a heavyweight
load-detection mechanism. This involves setting up a CRTC and sending a
signal to the output, before reading back any response. As that is quite
slow and CPU heavy, the process is only performed when the output
detection is fo
On Thu, Jun 04, 2015 at 04:24:43PM +0300, Jani Nikula wrote:
> On Wed, 03 Jun 2015, Mika Kahola wrote:
> > From: Ville Syrjälä
> >
> > ilk_get_aux_clock_divider() is now a subset of
> > hsw_get_aux_clock_divider() so unify them.
>
> I do like the clarity of having these two separate,
I see no c
According to bspec the DDI PHY vswing scale value is "don't care" in
case the scale enable bit [27] is clear. But this doesn't seem to be
correct. The scale value seems to also matter if the scale mode bit
[26] is set. So both bit 26 and 27 depend on the value. Setting the
scale value to 0 while ei
On 04/06/15 06:59, Sagar Arun Kamble wrote:
>
> Hi Daniel,
>
> We already are grabbing RPM reference before start of DMC FW load and
> release post load completion.
>
> DC5/6 can happen without Runtime PM as well. So we need to wait for CSR
> FW load for some time once we disable PW2.
>
> Havin
From: Paulo Zanoni
So people that write tests based on the template don't forget to use
the macro.
Signed-off-by: Paulo Zanoni
---
tests/template.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/template.c b/tests/template.c
index 24fd850..4b5794b 100644
--- a/tests/template.c
+++
From: Paulo Zanoni
We may not be perfect, but if we don't even test, we will probably
only get worse over time.
The function called makes sure we restore whatever was the original
FBC parameter when we exit the test, so this should not affect the
other tests.
Signed-off-by: Paulo Zanoni
---
t
From: Paulo Zanoni
Use the igt_set_module_param_int() call to enable it, then restore the
previous value after we are done testing.
With this, we can change the psr_enabled() function to psr_possible():
the only requirement should be that we have a PSR capable sink. The
test should now be able t
From: Paulo Zanoni
Some i915.ko features have very nice IGT tests, which are never
executed because the features are disabled by default. This leads to
unnoticed regressions both in the Kernel and in the IGT tests. We
have seen this multiple times, for example, on FBC and PSR.
We want to be abl
On 02/06/2015 19:47, Dave Gordon wrote:
On 02/06/15 19:36, Siluvery, Arun wrote:
On 01/06/2015 11:22, Daniel, Thomas wrote:
Indeed, allocating an extra scratch page in the context would simplify
vma/mm management. A trick might be to allocate the scratch page at the
start, then offset the lrc
On 02/06/2015 19:16, Tomas Elf wrote:
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_add_request() function is called to keep track of work that
has been
written to the ring buffer. It adds epilogue commands to track
progress (seqno
updates and such), move
On Thu, 04 Jun 2015, Damien Lespiau wrote:
> On Wed, Jun 03, 2015 at 03:45:06PM +0300, Mika Kahola wrote:
>> This patch series rebases Ville's original cdclk patch series
>> excluding the ones that has already been reviewed.
>>
>> http://lists.freedesktop.org/archives/intel-gfx/2014-November
On Wed, 03 Jun 2015, Mika Kahola wrote:
> From: Ville Syrjälä
>
> Implement support for changing the cdclk frequency during runtime on
> HSW. VLV/CHV already have support for this, so we can follow their
> example for the most part. Only the actual hardware programming differs,
> the rest is pret
Tvrtko Ursulin writes:
> From: Tvrtko Ursulin
>
> Since this drivers creates attributes on the heap, lockdep
> gets upset and disabled itself.
>
> Fix by setting ignore_lockdep flags for problematic attributes.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Alexander Shishkin
> Cc: Ingo Molnar
> Cc:
On Wed, 03 Jun 2015, Mika Kahola wrote:
> From: Ville Syrjälä
>
> ilk_get_aux_clock_divider() is now a subset of
> hsw_get_aux_clock_divider() so unify them.
I do like the clarity of having these two separate, especially with the
early return in the ilk version and the w/a in the hsw/bdw version
On 02/06/2015 19:26, Tomas Elf wrote:
On 29/05/2015 17:43, 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
i915_gem_object_sync()
code path.
v2: Much m
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 60
1 file changed, 26 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 41e0f50b3eae..5ce78fec2575 100644
Huzzah! \o/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 128
drivers/gpu/drm/i915/intel_display.c | 280 ++-
drivers/gpu/drm/i915/intel_drv.h | 5 -
3 files changed, 42 insertions(+), 371 deletions(-)
diff --
All transitional plane helpers are gone, party!
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atom
The only reason to check anything without modeset was for fastboot
audio_changed/infoframe_changed changes.
Now that's handled during hw readout parameters shouldn't change
any more when all things stay identical.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 27 ++
It's easier to read separate functions for crtc and plane scaler state.
Changes since v1:
- Update documentation.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 200 ++-
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/
No point in applying vblank evasion if there's nothing to evade.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 728
Read out the initial state, and add a quirk to force disable all plane
that were initially active. Use this to disable planes during modeset
too.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 7 ++
drivers/gpu/drm/i915/intel_display.c | 139 +++
The scaler setup may add planes, but since they're unchanged we only
have to wait for primary flips. Also set planes_changed to indicate
at least 1 plane is modified.
Changes since v1:
- Instead of removing planes, do minimal validation needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/d
No point in hiding behind big ifs. This will be true most of the time.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_sprite.c | 33 ++---
2 files changed, 22 insertions(+), 27 deletions(-)
By passing crtc_state to the check_plane functions a lot of duplicated
code can be removed. And now that the transitional helpers are gone the
crtc_state can be reliably obtained.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 4 ++-
drivers/gpu/drm/i915/intel_
This is probably intended to be be done during vblank evasion.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 3 ---
drivers/gpu/drm/i915/intel_display.c | 8
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 8 deletions(-)
diff
This patch requires the following patch from airlied/drm-next:
"[PATCH] drm/atomic: Clear crtc_state->active in drm_atomic_helper_set_config."
Now that suspend/restore is atomic it's time to clean up some
remaining issues. First I clean up the suspend code some more now
that it's atomic.
After th
And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.
All the existing state is fine in this case, only setting mode_changed
will force a full recalculation here, and take all the state needed.
Signed-off-by: Maarten L
This makes it easier to verify that no changes are done when
calling this from crtc instead.
Changes since v1:
- Make intel_wm_need_update static and always check it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 21 +--
drivers/gpu/drm/i915/intel_display.c
The idea was good, but planes can have a fb even though
they're disabled. This makes the force argument useless
and always true, because only the commit function updates
state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 16 +++-
drivers/gpu/drm/i915/i
Instead of breaking all connections manually, kill them with
atomic modeset, if it happens. Now that the everything's atomic
some code becomes obsolete.
Forcing a atomic modeset with null mode and all connectors gone
updates the state too, in a cleaner way.
Because load detection is atomic too th
To allow them to be used in intel_set_mode.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 127 +++
1 file changed, 69 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_disp
The original commit 206645910b97
"drm/i915: check for audio and infoframe changes across mode sets v2"
added checking when has_audio and has_infoframe were changed.
It seems the original commit added both checks for the fastboot case.
By setting crtc_state->mode_changed the code will disable the c
Use a full atomic call instead. intel_crtc_page_flip will still
have to live until async updates are allowed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i
Get rid of a whole lot of ternary operators and assign the index
in scaler_id, instead of the id. They're the same thing.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 21 +++--
drivers/gpu/drm/i915/intel_display.c | 2 --
drivers/gpu/drm/i915/intel
Now that there's only a single path for all atomic updates we can call
intel_(pre/post)_plane_update from intel_atomic_commit directly. This
makes the intention more clear.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
1 file changed, 6 insertions(+
Move the check for encoder cloning here.
Changes since v1:
- Remove was/is crtc_disabled. (mattrope)
- Rename function to intel_crtc_atomic_check. (mattrope)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 5 +-
drivers/gpu/drm/i915/intel_display.c | 126 ++
This can only fail because of a bug in the code.
Suggested-by: Daniel Vetter
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 17 +++--
3 files changed
Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.
The code is shared with atomic_begin/flush, except watermark updating
and vblank evasion are not used.
Signed-off-b
By making color key atomic there are no more transitional helpers.
The plane check function will reject the color key when a scaler is
active.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 1 +
drivers/gpu/drm/i915/intel_display.c | 5 +-
drivers/gpu/drm
No need to repeatedly call update_watermarks, or update_fbc.
Down to a single call to update_watermarks in .crtc_enable
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 65 +---
1 file changed, 15 insertions(+), 50 deletions(-)
diff --g
Grabbing crtc state from atomic state is a lot more involved,
and make sure connectors are added before calling this function.
Move check_digital_port_conflicts to intel_modeset_checks,
it's only useful to check it on a modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_di
Use for_each_crtc_state to only touch affected crtc's.
In order to make sure that the initial power is still set
correctly we make sure modeset_update_crtc_power_domains is called
during the initial modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
driv
On Wed, Jun 03, 2015 at 03:45:06PM +0300, Mika Kahola wrote:
> This patch series rebases Ville's original cdclk patch series
> excluding the ones that has already been reviewed.
>
> http://lists.freedesktop.org/archives/intel-gfx/2014-November/055633.html
>
> The patches are rebased to the
From: John Harrison
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the
On Thu, Jun 04, 2015 at 12:08:17PM +0100, Tomas Elf wrote:
> On 01/06/2015 16:53, Chris Wilson wrote:
> >On Wed, May 27, 2015 at 07:12:02PM +0100, Tomas Elf wrote:
> >>On 22/05/2015 18:05, Mika Kuoppala wrote:
> >>>During review of dynamic page tables series, I was able
> >>>to hit a lite restore b
On Wed, 03 Jun 2015, Jani Nikula wrote:
> On Tue, 02 Jun 2015, Damien Lespiau wrote:
>> On Tue, Jun 02, 2015 at 03:37:35PM +0300, ville.syrj...@linux.intel.com
>> wrote:
>>> From: Ville Syrjälä
>>>
>>> commit 65ca7514e21adbee25b8175fc909759c735d00ff
>>> Author: Damien Lespiau
>>> Date: M
On Tue, 02 Jun 2015, Ander Conselvan De Oliveira wrote:
> On Tue, 2015-06-02 at 09:27 +0200, Maarten Lankhorst wrote:
>> Op 02-06-15 om 09:12 schreef Jani Nikula:
>> > On Mon, 01 Jun 2015, Ander Conselvan de Oliveira
>> > wrote:
>> >> Since the force restore logic will restore the CRTCs state on
On 01/06/2015 16:53, Chris Wilson wrote:
On Wed, May 27, 2015 at 07:12:02PM +0100, Tomas Elf wrote:
On 22/05/2015 18:05, Mika Kuoppala wrote:
During review of dynamic page tables series, I was able
to hit a lite restore bug with execlists. I assume that
due to incorrect pd, the batch run out of
On Thu, Jun 04, 2015 at 01:39:50PM +0530, Sagar Arun Kamble wrote:
> The warning faced by Chandra has to corrected. This warning is not
> related to firmware load.
>
> Issue is -> During boot DC5/6 will be already disabled and hence While
> enabling PW2 for the first time the check to see if DC5/
On to, 2015-06-04 at 10:01 +0100, Chris Wilson wrote:
> On Thu, Jun 04, 2015 at 11:49:06AM +0300, Joonas Lahtinen wrote:
> > Get rid of the over-generic i915_gem_obj_is_pinned and replace it
> > with i915_gem_obj_ggtt_is_pinned or more specific VMA handling.
> >
> > Requested-by: Chris Wilson
> >
On Thu, Jun 04, 2015 at 11:49:06AM +0300, Joonas Lahtinen wrote:
> Get rid of the over-generic i915_gem_obj_is_pinned and replace it
> with i915_gem_obj_ggtt_is_pinned or more specific VMA handling.
>
> Requested-by: Chris Wilson
> Signed-off-by: Joonas Lahtinen
I take it you didn't read my patc
Get rid of the over-generic i915_gem_obj_is_pinned and replace it
with i915_gem_obj_ggtt_is_pinned or more specific VMA handling.
Requested-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 +--
drivers/gpu/drm/i915/i915_drv.h | 9 +
On Mon, 01 Jun 2015, Maarten Lankhorst
wrote:
> The goal of this patch series is to implement hardware readout using
> atomic state, and restore sw state with a single call to intel_set_mode.
>
> After that's done intel_crtc_control can be safely converted to
> atomic modeset, because nothing rel
On Thu, Jun 04, 2015 at 01:36:36PM +0530, Akash Goel wrote:
> On Wed, 2015-06-03 at 14:27 -0700, Rodrigo Vivi wrote:
> > On Tue, May 12, 2015 at 12:49 AM, wrote:
> > > From: Akash Goel
> > >
> > > Updated the i915_ring_freq_table debugfs function to allow read of ring
> > > frequency table throu
Now that we can subclass drm_atomic_state we can also use it to keep
track of all the pll settings. atomic_state is a better place to hold
all shared state than keeping pll->new_config everywhere.
Changes since v1:
- Assert connection_mutex is held.
Changes since v2:
- Fix swapped arguments to kza
On Tue, 02 Jun 2015, Ville Syrjälä wrote:
> On Tue, Jun 02, 2015 at 02:17:47PM +0300, Ander Conselvan de Oliveira wrote:
>> Add all missing platforms handled by intel_set_memory_cxsr() to the
>> i915_sr_status debugfs entry.
>>
>> v2: Add G4X too. (Ville)
>> Clarify the change also affects CH
On Wed, 03 Jun 2015, Ville Syrjälä wrote:
> On Tue, Jun 02, 2015 at 08:06:59PM +0100, Arun Siluvery wrote:
>> After GPU reset, HW is losing the address of HWS page in the register.
>> The page itself is valid except that HW is not aware of its location.
>>
>> [ 64.368623] [drm:gen8_init_common_
The warning faced by Chandra has to corrected. This warning is not
related to firmware load.
Issue is -> During boot DC5/6 will be already disabled and hence While
enabling PW2 for the first time the check to see if DC5/6 is already
disabled does not make sense.
So condition should be
WARN(!(I9
On Wed, 2015-06-03 at 14:27 -0700, Rodrigo Vivi wrote:
> On Tue, May 12, 2015 at 12:49 AM, wrote:
> > From: Akash Goel
> >
> > Updated the i915_ring_freq_table debugfs function to allow read of ring
> > frequency table through Punit interface, for SKL also.
> >
> > Signed-off-by: Akash Goel
> >
On Mon, 01 Jun 2015, Maarten Lankhorst
wrote:
> The primary plane can still be configured when crtc is off,
> furthermore this is also a noop now that affected planes are
> added on modesets.
>
> Changes since v1:
> - Move commit so no frontbuffer_bits warnings are generated.
>
> Signed-off-by: M
On Wed, 2015-06-03 at 14:24 -0700, Rodrigo Vivi wrote:
> On Tue, May 5, 2015 at 4:30 AM, wrote:
> > From: Akash Goel
> >
> > Ring frequency table programming changes for SKL. No need for a
> > floor on ring frequency, as the issue of performance impact with
> > ring running below DDR frequency,
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6530
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Mon, 01 Jun 2015, Maarten Lankhorst
wrote:
> From: Ander Conselvan de Oliveira
>
> Now that we can subclass drm_atomic_state we can also use it to keep
> track of all the pll settings. atomic_state is a better place to hold
> all shared state than keeping pll->new_config everywhere.
>
> Chang
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6533
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Wed, 2015-06-03 at 14:19 -0700, Rodrigo Vivi wrote:
> On Tue, May 5, 2015 at 4:30 AM, wrote:
> > From: Akash Goel
> >
> > Read the efficient frequency (aka RPe) value through the the mailbox
> > command (0x1A) from the pcode, as done on Haswell and Broadwell.
> > The turbo minimum frequency s
93 matches
Mail list logo
