From: Ben Widawsky
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 001f8fb..f6a44d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/driv
From: Ben Widawsky
Originally I had a macro specifically for DPF support, and Daniel, with
good reason asked me to change it to this. It's not the way I would have
gone (and indeed I didn't), but for now there is no distinction as all
platforms with L3 also have DPF.
Signed-off-by: Ben Widawsky
Basic context support on HSW is no different than previous generations.
The size of the context object changes, but that's about it.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 5 -
drivers/gpu/drm/i915/i915_reg.h | 8
2 files changed, 12 insert
I have the faint hope that the total absence of any locking for the
rps code wasn't too good an idea and could very well have caused some
rc6 related regressions.
Unfortunately we've never managed to reproduce these issues on any of
our own machines, so the only way to go about this is to enable i
Like with the equivalent change for gen6+ rps state, this helps in
clarifying the code (and in fixing a few places that have fallen through
the cracks in the locking review).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 36 +---
drivers/gpu/drm/i915/i915_irq.c
We change the drps/ips sw/hw state from different callers: Our own irq
handler, the external intel-ips module and from process context. Most
of these callers don't take any lock at all.
Protect everything by making the mchdev_lock irqsave and grabbing it in
all relevant callsites. Note that we hav
Like all the other drps/ips stuff. Hence add the corresponding check,
give the function a preciser prefix and move the single reg clearing into
the rps handling function, too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 10 +-
1 file changed, 5 insertions(+), 5 d
It's only ever a pointer to the global mchdev_lock, and we don't use
it at all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_pm.c |1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i91
This way it's easier so see what belongs together, and what is used
by the ilk ips code. Also add some comments that explain the locking.
v2: Missed one place that the dev_priv->ips change caught ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 +++
drivers/g
- Take the dev->struct_mutex around access the corresponding state
(and adjusting the rps hw state).
- Add an assert to gen6_set_rps to ensure we don't forget about this
in the future.
- Don't set up the min/max_freq files if it doesn't apply to the hw.
And do the same for the gen6+ cache sha
The update_gfx_val function called from mark_busy wasn't taking the
mchdev_lock, as it should have. Also sprinkle a few spinlock asserts
over the code to document things better.
Things are still rather confusing, especially since a few variables
in dev_priv are used by both the gen6+ rps code and
Pure paranoia-induced patch as part of a large work to fix up the
locking around intel_mark_busy/idle. At least for the gen6+ rps state,
locking seems to be sane and the hw/sw state is protected by
dev->struct_mutex.
The only thing missing is a paranoid WARN_ON in sanitize_pm.
Signed-Off-by: Dani
Hi all
While reviewing Chris' simplified mark_busy/idle code I've noticed that we
seriously lack some locking. This series here fixes the first part around the
gpu power handling, the pll up/downclocking might still be rather broken :(
Since this clearly fixes some issues with the code, also try
On Tue, Jul 24, 2012 at 08:46:04PM +0200, Frederik Vogelsang wrote:
> Hi,
>
> thanks for your feedback, Attila.
>
> 2012/7/24 alanwww1 :
> > I already reported this problem here:
> > https://bugs.freedesktop.org/show_bug.cgi?id=49055
> I see. I did not search bugzilla yet, because I thought this
Hi,
thanks for your feedback, Attila.
2012/7/24 alanwww1 :
> I already reported this problem here:
> https://bugs.freedesktop.org/show_bug.cgi?id=49055
I see. I did not search bugzilla yet, because I thought this feature
was related to my pretty new hardware components. It's a little
disappointin
Hi,
We'd like to announce Intel 12.07 graphics package release, with continuous
stability and performance improvement over 12.02 release.
Please check http://intellinuxgraphics.org/2012.07.html for the recommended
stack, list of new features and known issues.
We'd also like to thank all the de
On 07/20/2012 10:10 AM, Daniel Vetter wrote:
On Fri, Jul 20, 2012 at 12:51:41AM +0200, Carsten Emde wrote:
On 07/19/2012 04:40 PM, Daniel Vetter wrote:
Well, the backlight-confusion branch had a bug and outright disabled
the intel backlight :( drm-intel-next-queued should have fixes for all
the
Hi all !
I already reported this problem here:
https://bugs.freedesktop.org/show_bug.cgi?id=49055
I was also in emailing on this problem with Intel developer Wu Fengguang.
It is probably an Intel driver problem.
His last email (back in may) was:
"Hi Attila,
Sorry for the delay! During the time
18 matches
Mail list logo
