On Fri, Feb 21, 2014 at 03:34:43AM +, Sharma, Shashank wrote:
> Hi Ville/All,
>
> We gave a presentation on design on this framework, few months ago, in one of
> our common forum with OTC folks.
> We discussed, took review comments, and re-designed the framework, as per
> the feedbacks.
Hi Ville,
Thanks for your time and comments.
I can understand two basic problems what you see in this implementation:
1. The most important issue from my POV is that it can't be part of the atomic
modeset.
2. it make the whole API inconsistent.
I am not sure if its good to block all c
From: Ville Syrjälä
If we've explicitly stopped the rings for testing purposes, don't ban
the default context. Fixes kms_flip hang tests.
Signed-off-by: Ville Syrjälä
---
I'm not sure this is what we want in general, but it's what kms_flip expects
currently.
drivers/gpu/drm/i915/i915_gem.c |
On Fri, Feb 21, 2014 at 02:20:24PM +, Sharma, Shashank wrote:
> Hi Ville,
>
> Thanks for your time and comments.
> I can understand two basic problems what you see in this implementation:
>
> 1. The most important issue from my POV is that it can't be part of the
> atomic modeset.
>
On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank
wrote:
> Hi Ville,
>
> Thanks for your time and comments.
> I can understand two basic problems what you see in this implementation:
>
> 1. The most important issue from my POV is that it can't be part of the
> atomic modeset.
> 2. it make the w
From: Mika Kuoppala
There should not be a case where fifo count is other
than zero after a successful reset. Always set
count to zero, but be paranoid enough to warn.
Suggested-by: Ben Widawsky
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c |8
1 file change
From: Mika Kuoppala
Tweaked 2/5 commit message a bit to remove mention
of hang, as we are not sure about the root cause.
4/5 is hopefully something that Ben was looking after in his
review.
Thanks for Ben and Ville for looking at these.
-Mika
Mika Kuoppala (5):
drm/i915: Fix forcewake count
From: Mika Kuoppala
As we now have intel_uncore_forcewake_reset() no need
to do explicit put after reset.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/driver
From: Mika Kuoppala
Sometimes generic driver code gets forcewake explicitly by
gen6_gt_force_wake_get(), which check forcewake_count before accessing
hardware. However the register access with gen8_write function access
low level hw accessors directly, ignoring the forcewake_count. This
leads to
From: Mika Kuoppala
When we get control from BIOS there might be mt forcewake
bits already set. This causes us to do double mt get
without proper clear/ack sequence.
Fix this by clearing mt forcewake register on init,
like we do with older gens.
Signed-off-by: Mika Kuoppala
Reviewed-by: Ben Wi
From: Mika Kuoppala
as they don't exists.
Signed-off-by: Mika Kuoppala
Reviewed-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_uncore.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
i
On Fri, Feb 21, 2014 at 05:32:01PM +0200, mika.kuopp...@intel.com wrote:
> From: Mika Kuoppala
>
> as they don't exists.
>
> Signed-off-by: Mika Kuoppala
> Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_uncore.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
On Fri, Feb 21, 2014 at 9:46 AM, Ville Syrjälä
wrote:
> On Fri, Feb 21, 2014 at 02:20:24PM +, Sharma, Shashank wrote:
>> Hi Ville,
>>
>> Thanks for your time and comments.
>> I can understand two basic problems what you see in this implementation:
>>
>> 1. The most important issue from my POV
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> If we've explicitly stopped the rings for testing purposes, don't ban
> the default context. Fixes kms_flip hang tests.
>
To keep logs clean from 'unnecessary' hang messages we set stop_rings also on
all the gem_reset_stats hanging
Mika Kuoppala writes:
> ville.syrj...@linux.intel.com writes:
>
>> From: Ville Syrjälä
>>
>> If we've explicitly stopped the rings for testing purposes, don't ban
>> the default context. Fixes kms_flip hang tests.
>>
>
> To keep logs clean from 'unnecessary' hang messages we set stop_rings also
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> If we've explicitly stopped the rings for testing purposes, don't ban
> the default context. Fixes kms_flip hang tests.
>
> Signed-off-by: Ville Syrjälä
> ---
> I'm not sure this is what we want in general, but it's what kms_flip ex
as they don't exists.
v2: rename gen6_*_mt_* to gen7_*_mt_* as they never get called
with gen6 (Chris)
Signed-off-by: Mika Kuoppala
Reviewed-by: Ben Widawsky (v1)
---
drivers/gpu/drm/i915/intel_uncore.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
From: Paulo Zanoni
Hi
This series contains a collection of fixes for problems I found on the runtime
PM code. All these problems either result in failure of some pm_pc8 test, or
result in a Kernel WARN/DRM_ERROR when running pm_pc8, or there is a patch in
this series that adds a WARN that will b
From: Paulo Zanoni
When we call gen6_gt_force_wake_put we don't actually put force_wake,
we just schedule gen6_force_wake_work through mod_delayed_work, and
that will eventually release force_wake.
The problem is that we call intel_runtime_pm_put directly at
gen6_gt_force_wake_put, so most of th
From: Paulo Zanoni
Otherwise, when we run intel_modeset_check_state we may already be
runtime suspended, and our state checking code will read registers
while the device is suspended. This can only happen if your
autosuspend_delay_ms is low (not the default 10s).
Signed-off-by: Paulo Zanoni
---
From: Paulo Zanoni
These are places where we read (not write) registers while we're
runtime suspended.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/d
From: Paulo Zanoni
Because we shouldn't be runtime suspended when forcewake is supposed
to be enabled.
This commit will trigger the WARNs because we currently have a bug
with this. The next patches should fix the bug.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_uncore.c | 15 ++
From: Chris Wilson
We currently call intel_mark_idle() too often, as we do so as a
side-effect of processing the request queue. However, we the calls to
intel_mark_idle() are expected to be paired with a call to
intel_mark_busy() (or else we try to idle the hardware by accessing
registers that ar
From: Paulo Zanoni
Because intel_mark_idle still touches some registers: it needs the
machine to be awake. If you set both the autosuspend and PC8 delays to
zero, you can get a "Device suspended" WARN when gen6_rps_idle touches
registers.
This is not easy to reproduce, but happens once in a whil
From: Paulo Zanoni
Just to be sure...
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 8
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/driver
From: Paulo Zanoni
Because gen6_gt_force_wake_{get,put} should already be responsible for
getting/putting runtime PM.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/
From: Paulo Zanoni
I could swear this was already happening in the current code...
Also, put the reads and writes in a generic place, so we don't forget
it again when we add runtime PM support to new platforms.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
1 fi
From: Paulo Zanoni
Otherwise we'll read registers that return 0x, trigger some
WARNs, think CRT is actually connected (because certain bits are 1),
and fail the drm-resources-equal testcase!
Tested on a SNB machine with runtime PM support (which is not upstream
yet, but is already on my
From: Paulo Zanoni
Since the addition of dev_priv->mm.busy, there's no more need for
dev_priv->pc8.gpu_idle, so kill it.
Notice that when you remove gpu_idle, hsw_package_c8_gpu_idle and
hsw_package_c8_gpu_busy become identical to hsw_enable_package_c8 and
hsw_disable_package_c8, so just use the
On Fri, Feb 21, 2014 at 01:52:18PM -0300, Paulo Zanoni wrote:
> From: Chris Wilson
>
> We currently call intel_mark_idle() too often, as we do so as a
> side-effect of processing the request queue. However, we the calls to
> intel_mark_idle() are expected to be paired with a call to
> intel_mark_
2014-02-21 13:55 GMT-03:00 Chris Wilson :
> On Fri, Feb 21, 2014 at 01:52:18PM -0300, Paulo Zanoni wrote:
>> From: Chris Wilson
>>
>> We currently call intel_mark_idle() too often, as we do so as a
>> side-effect of processing the request queue. However, we the calls to
>> intel_mark_idle() are ex
On Fri, Feb 21, 2014 at 02:04:32PM -0300, Paulo Zanoni wrote:
> 2014-02-21 13:55 GMT-03:00 Chris Wilson :
> > On Fri, Feb 21, 2014 at 01:52:18PM -0300, Paulo Zanoni wrote:
> >> From: Chris Wilson
> >>
> >> We currently call intel_mark_idle() too often, as we do so as a
> >> side-effect of processi
On Fri, 21 Feb 2014 13:52:20 -0300
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> When we call gen6_gt_force_wake_put we don't actually put force_wake,
> we just schedule gen6_force_wake_work through mod_delayed_work, and
> that will eventually release force_wake.
>
> The problem is that we call
On Fri, 21 Feb 2014 13:52:19 -0300
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because intel_mark_idle still touches some registers: it needs the
> machine to be awake. If you set both the autosuspend and PC8 delays to
> zero, you can get a "Device suspended" WARN when gen6_rps_idle touches
>
On Fri, 21 Feb 2014 13:52:21 -0300
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Otherwise, when we run intel_modeset_check_state we may already be
> runtime suspended, and our state checking code will read registers
> while the device is suspended. This can only happen if your
> autosuspend_del
On Fri, 21 Feb 2014 13:52:22 -0300
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Otherwise we'll read registers that return 0x, trigger some
> WARNs, think CRT is actually connected (because certain bits are 1),
> and fail the drm-resources-equal testcase!
>
> Tested on a SNB machine wi
We currently call intel_mark_idle() too often, as we do so as a
side-effect of processing the request queue. However, we the calls to
intel_mark_idle() are expected to be paired with a call to
intel_mark_busy() (or else we try to idle the hardware by accessing
registers that are already disabled).
On Fri, 21 Feb 2014 13:52:23 -0300
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> These are places where we read (not write) registers while we're
> runtime suspended.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 17 +
> 1 file changed, 17 inser
2014-02-21 14:41 GMT-03:00 Jesse Barnes :
> On Fri, 21 Feb 2014 13:52:23 -0300
> Paulo Zanoni wrote:
>
>> From: Paulo Zanoni
>>
>> These are places where we read (not write) registers while we're
>> runtime suspended.
>>
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/gpu/drm/i915/i915_debugfs
We currently call intel_mark_idle() too often, as we do so as a
side-effect of processing the request queue. However, we the calls to
intel_mark_idle() are expected to be paired with a call to
intel_mark_busy() (or else we try to idle the hardware by accessing
registers that are already disabled).
2014-02-21 13:52 GMT-03:00 Paulo Zanoni :
> From: Paulo Zanoni
>
> Because we shouldn't be runtime suspended when forcewake is supposed
> to be enabled.
>
> This commit will trigger the WARNs because we currently have a bug
> with this. The next patches should fix the bug.
Actually I changed the
Try to flush out dirty pages into the swapcache (and from there into the
swapfile) when under memory pressure and forced to drop GEM objects from
memory.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 48 ++---
1 file changed, 36 insertions(
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3618bb0cda0a..d0cd9df4c1f7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++
Under memory pressure it is important that we strive to unpin some of
our objects so that their backing pages can be swapped out. However, we
have to avoid recursion in struct_mutex and also make sure that we
safely wait upon the device and driver. The first part is done by first
using a trylock an
On Fri, Feb 21, 2014 at 9:49 AM, Rob Clark wrote:
> On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank
> wrote:
>> Hi Ville,
>>
>> Thanks for your time and comments.
>> I can understand two basic problems what you see in this implementation:
>>
>> 1. The most important issue from my POV is that i
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, w
A common issue we have is that retiring requests causes recursion
through GTT manipulation or page table manipulation which we can only
handle at very specific points. However, to maintain internal
consistency (enforced through our sanity checks on write_domain at
various points in the GEM object l
lib/interval_tree.c provides a simple interface for an interval-tree
(an augmented red-black tree) but is only built when testing the generic
macros for building interval-trees. For drivers with modest needs,
export the simple interval-tree library as is.
v2: Lots of help from Michel Lespinasse to
On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
> > Color manager is a new framework in i915 driver, which provides
> > a unified interface for various color correction methods supported
> > b
From: Ville Syrjälä
I'm going to require vblank interrupts during modeset in i915 soon, however
the drm vblank code won't currently allow it. It simply refuses to re-enable
the vblank interrupts whenever they were disable and the refcount is
already elevated. That means anyone holding a vblank re
From: Peter Hurley
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/driver
From: Ville Syrjälä
If someone holds a vblank reference across the modeset, and after/during
the modeset someone tries to grab a vblank reference, the current code
won't re-enable the vblank interrupts. That's not good, so instead allow
the driver to choose whether drm_vblank_get() should always
From: Ville Syrjälä
Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
From: Ville Syrjälä
Tell the drm core vblank code to reject drm_vblank_get()s only between
drm_vblank_off() and drm_vblank_on() calls, and sprinkle the appropriate
drm_vblank_on() calls to the .crtc_enable() hooks. At this time I kept
the off calls in their current position, and added the on call
From: Ville Syrjälä
Allow the driver to specify whether all new vblank requests after
drm_vblank_off() should be rejected. And add a counterpart called
drm_vblank_on() which will again allow vblank requests to come in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/armada/armada_crtc.c |
2014-02-20 21:01 GMT-03:00 Ben Widawsky :
> This got lost when we shuffled around our internal branch and
> GEN7_FEATURES macro. There were no HW changes to support FBC, so we just
> need to set the flag.
>
> v2: Don't allow FBC for any pipe but A on platforms with DDI. (Paulo)
>
> Cc: Daisy Sun
>
2014-02-21 14:55 GMT-03:00 Chris Wilson :
> We currently call intel_mark_idle() too often, as we do so as a
> side-effect of processing the request queue. However, we the calls to
> intel_mark_idle() are expected to be paired with a call to
> intel_mark_busy() (or else we try to idle the hardware b
2014-02-21 14:27 GMT-03:00 Chris Wilson :
> On Fri, Feb 21, 2014 at 02:04:32PM -0300, Paulo Zanoni wrote:
>> 2014-02-21 13:55 GMT-03:00 Chris Wilson :
>> > On Fri, Feb 21, 2014 at 01:52:18PM -0300, Paulo Zanoni wrote:
>> >> From: Chris Wilson
>> >>
>> >> We currently call intel_mark_idle() too oft
On Fri, Feb 21, 2014 at 05:31:59PM +0200, mika.kuopp...@intel.com wrote:
> From: Mika Kuoppala
>
> Sometimes generic driver code gets forcewake explicitly by
> gen6_gt_force_wake_get(), which check forcewake_count before accessing
> hardware. However the register access with gen8_write function a
On Fri, Feb 21, 2014 at 11:38:48AM -0800, Ben Widawsky wrote:
> On Fri, Feb 21, 2014 at 05:31:59PM +0200, mika.kuopp...@intel.com wrote:
> > From: Mika Kuoppala
> >
> > Sometimes generic driver code gets forcewake explicitly by
> > gen6_gt_force_wake_get(), which check forcewake_count before acce
On Fri, Feb 21, 2014 at 11:38:48AM -0800, Ben Widawsky wrote:
> On Fri, Feb 21, 2014 at 05:31:59PM +0200, mika.kuopp...@intel.com wrote:
> > From: Mika Kuoppala
> >
> > Sometimes generic driver code gets forcewake explicitly by
> > gen6_gt_force_wake_get(), which check forcewake_count before acce
On Fri, 24 Jan 2014 19:23:54 +0200
Imre Deak wrote:
> On Fri, 2014-01-24 at 20:35 +0530, Naresh Kumar Kachhi wrote:
> > On 01/22/2014 06:53 PM, Imre Deak wrote:
> >
> > > On Wed, 2014-01-22 at 13:51 +0100, Daniel Vetter wrote:
> > > > On Wed, Jan 22, 2014 at 05:34:17PM +0530, naresh.kumar.kac...
2014-02-21 14:34 GMT-03:00 Jesse Barnes :
> On Fri, 21 Feb 2014 13:52:20 -0300
> Paulo Zanoni wrote:
>
>> From: Paulo Zanoni
>>
>> When we call gen6_gt_force_wake_put we don't actually put force_wake,
>> we just schedule gen6_force_wake_work through mod_delayed_work, and
>> that will eventually r
On Fri, 21 Feb 2014 17:08:50 -0300
Paulo Zanoni wrote:
> 2014-02-21 14:34 GMT-03:00 Jesse Barnes :
> > On Fri, 21 Feb 2014 13:52:20 -0300
> > Paulo Zanoni wrote:
> >
> >> From: Paulo Zanoni
> >>
> >> When we call gen6_gt_force_wake_put we don't actually put force_wake,
> >> we just schedule gen
From: Paulo Zanoni
When we call gen6_gt_force_wake_put we don't actually put force_wake,
we just schedule gen6_force_wake_work through mod_delayed_work, and
that will eventually release force_wake.
The problem is that we call intel_runtime_pm_put directly at
gen6_gt_force_wake_put, so most of th
With the original PPGTT implementation if the number of PDPs was not a
power of two, the number of pages for the page tables would end up being
rounded up. The code actually had a bug here afaict, but this is a
theoretical bug as I don't believe this can actually occur with the
current code/HW..
W
To silence locking complaints. This was a rebase failure on my part in
commit fa9fa083d0606cb323f6105c17702460ea0a6780
Author: Jesse Barnes
Date: Tue Feb 11 15:28:56 2014 -0800
drm/i915: read out hw state earlier v2
Reported-by: Ville Syrjälä
Signed-off-by: Jesse Barnes
---
drivers/gp
From: Paulo Zanoni
Just like we do to Haswell.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/intel_uncore.c | 2 ++
2 files changed, 4 insertions(+)
This patch is totally untested! Only checked against the spec.
diff --git a/drivers/gpu/dr
From: "Yu(Alex) Dai"
Add "zorder" property to crtc to control Z-order of sprite and
primary planes. The alpha channel of the planes can be enabled
or disabled during Z-order change.
Signed-off-by: Yu(Alex) Dai
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h
From: "Yu(Alex) Dai"
Add code to check invalid z-order. Also, avoid z-order setting if there
is no change in z-order.
Yu(Alex) Dai (1):
drm/i915: add support for Z-order of planes.
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 10 +
drivers/gpu/drm/i
On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrjälä
mailto:ville.syrj...@linux.intel.com>> wrote:
On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
>> Color manager is a new framework in i915 driver, which provides
>> a unified interface for various color correction methods supported
>>
>> Hi Ville,
>>
>> Thanks for your time and comments.
>> I can understand two basic problems what you see in this implementation:
>>
>> 1. The most important issue from my POV is that it can't be part of the
>> atomic modeset.
>> 2. it make the whole API inconsistent.
>>
>> I am not s
72 matches
Mail list logo
