Summary
We covered the platform: Baytrail-M, Haswell mobile, HSW desktop, HSW ULT,
IvyBridge, SandyBridge, IronLake. in this circle, 10 new bugs are filed, 31
bugs are still opened, no WONTFIX bugs, no NOTABUG bugs, no NOTOURBUG bugs, no
Duplicated bugs, no REOPENED bugs, 2 bugs are fixed, 12 bu
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
So I'm poking around the preemption code and stumble
CDCLK is used to generate the gmbus clock. This is normally done by
BIOS. This is only for valleyview platform.
v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency
during resume. (Daniel)
Signed-off-by: Chon Ming Lee
---
drivers/gpu/drm/i915/i915_reg.h |8 +++
driv
Without the DPIO cmnreset, the PLL fail to lock. This should have
done by BIOS.
v2: Move this to intel_uncore_sanitize to allow it to get call during
resume path. (Daniel)
Signed-off-by: Chon Ming Lee
---
drivers/gpu/drm/i915/intel_uncore.c | 15 +++
1 files changed, 15 insertion
In non PC system, such as IVI, may not use BIOS, instead it uses boot
loader with only minimal system initialization. Most of the time, boot
loader doesn't come with VBIOS, and depends on device driver to fully
initialize the display controller and GPU.
For Valleyview, without VBIOS, i915 fail
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
So I'm poking around the preemption code and stumble
Signed-off-by: Ben Widawsky
---
tools/Makefile.am | 6 ++-
tools/intel_l3_parity.c| 39 +--
tools/intel_l3_parity.h| 31
tools/intel_l3_udev_listener.c | 108 +
4 files changed, 179 insertions(+), 5
Signed-off-by: Ben Widawsky
---
tools/intel_l3_parity.c | 45 -
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/tools/intel_l3_parity.c b/tools/intel_l3_parity.c
index fd09d39..cf15541 100644
--- a/tools/intel_l3_parity.c
+++ b/tools/int
Haswell added the ability to inject errors which is extremely useful for
testing. Add two arguments to the tool to inject, and uninject.
Signed-off-by: Ben Widawsky
---
tests/sysfs_l3_parity | 2 +-
tools/intel_l3_parity.c | 69 +++--
2 files change
Haswell GT3 adds a new slice which is kept distinct from the old
register interface. Plumb it into the code, though it's only 1 slice
still.
Signed-off-by: Ben Widawsky
---
tools/intel_l3_parity.c | 113 +---
1 file changed, 68 insertions(+), 45 deleti
Add a new command line argument to the tool which will spit out various
parameters for the giving hardware. As a result of this, some new
defines are added to help with the various info.
Signed-off-by: Ben Widawsky
---
tools/intel_l3_parity.c | 24
1 file changed, 20 ins
Signed-off-by: Ben Widawsky
---
tools/intel_l3_parity.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/intel_l3_parity.c b/tools/intel_l3_parity.c
index ad027ac..970dcd6 100644
--- a/tools/intel_l3_parity.c
+++ b/tools/intel_l3_parity.c
@@ -58,12 +58,12 @@
Add new command line arguments in addition to supporting the old
features. This patch only introduces one feature, the -e argument to
enable a specific row/bank/subbank. Previously you could only enable
all. Otherwise, it has what you expect (we prefer -r -b -s for
specifying the row/bank/subbank).
Signed-off-by: Ben Widawsky
---
tools/intel_l3_parity.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/intel_l3_parity.c b/tools/intel_l3_parity.c
index 970dcd6..a3d268b 100644
--- a/tools/intel_l3_parity.c
+++ b/tools/intel_l3_parity.c
@@ -120,7 +120,7 @@ int main(int
On both Ivybridge and Haswell, row remapping information is saved and
restored with context. This means, we never actually properly supported
the l3 remapping because our sysfs interface is asynchronous (and not
tied to any context), and the known faulty HW would be reused by the
next context to ru
I have implemented this patch before without creating a separate list
(I'm having trouble finding the links, but the messages ids are:
<1364942743-6041-2-git-send-email-...@bwidawsk.net>
<1365118914-15753-9-git-send-email-...@bwidawsk.net>)
However, the code is much simpler to just use a list and
Using LRI for setting the remapping registers allows us to stream l3
remapping information. This is necessary to handle per context remaps as
we'll see implemented in an upcoming patch.
Using the ring also means we don't need to frob the DOP clock gating
bits.
Signed-off-by: Ben Widawsky
---
dr
Certain HSW SKUs have a second bank of L3. This L3 remapping has a
separate register set, and interrupt from the first "slice". A slice is
simply a term to define some subset of the GPU's l3 cache. This patch
implements both the interrupt handler, and ability to communicate with
userspace about thi
Haswell changed the log registers to be WO, so we can no longer read
them to determine the programming (which sucks, see later note). For
now, simply use the cached value, and hope HW doesn't screw us over.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
Signed-off-by: Ben Widawsky
-
The buf pointer used during l3_write is just char *, therefore it does
not require the silly any addition of offset.
v2: Also fix i915_l3_read with a suggested logic from Ville
Cc: Ville Syrjälä
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_sysfs.c | 12 ++--
1 file changed
Sadly, this isn't the first time we've done this:
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029065.html
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/d
We always read a register for l3 parity reads, and we don't really want
to ever let userspace trick us into giving back less than the dword.
Writes are okay because we assume everything will be 0 filled, and as
such, if a user really wants to write less than a dword, let them.
Signed-off-by: Ben
Since IVB, our driver has supported GPU L3 cacheline remapping for
parity errors. This is known as, "DPF" for Dynamic Parity Feature. I am
told such an error is a good predictor for a subsequent error in the
same part of the cache. To address this possible issue for workloads
requiring precise and
On 09/12 18:30, Daniel Vetter wrote:
> On Fri, Sep 13, 2013 at 5:59 AM, Chon Ming Lee
> wrote:
> > In non PC system, such as IVI, may not use BIOS, instead it uses boot
> > loader with only minimal system initialization. Most of the time, boot
> > loader doesn't come with VBIOS, and depends on d
hmm, looks like I cargo-cult'd the same into msm.
I guess in i915 (and ttm) case, the issue arises due to need for CPU
access to buffer via GTT? In which case I should be safe to drop the
set_need_resched() as well? (Since CPU always has direct access to the
pages.) Or am I missing something abo
As Paulo explained at [1], there's a modeset related hang occuring on HSW.
I bisected it down to removing a workaround meant for pre-production hardware,
and Paulo cooked up a workaround that worked for him. Unfortunately I was still
able to trigger the hangs by disabling all planes on pipe B but
Op 12-09-13 18:44, Thomas Hellstrom schreef:
> On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
>> Op 12-09-13 17:36, Daniel Vetter schreef:
>>> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra
>>> wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i9
On Thu, Sep 12, 2013 at 06:06:43PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Both callers had code to sanitize the uncore and restore the GTT
> mappings just before calling __i915_drm_thaw, so Chris suggested I
> should unify the code.
>
> Signed-off-by: Paulo Zanoni
Slightly more tr
From: Paulo Zanoni
So far we control all the reads an none of them exceeds the current
limit of 20 bytes, but we never think about this when reviewing
patches, so we may at some point in the future overflow the buffer.
My initial patch just added a WARN in case we were about to overflow
the buff
On Thu, Sep 12, 2013 at 10:45:10PM +0200, Hans de Bruin wrote:
> On 09/10/2013 01:00 PM, Jani Nikula wrote:
> >
> >Hi Hans -
> >
> >On Sat, 07 Sep 2013, Hans de Bruin wrote:
> >>Since a day or two the screen of my laptop goes blank when the kernel
> >>switches resolution in the boot process. Happi
On Thu, 12 Sep 2013 22:38:41 +0200
Daniel Vetter wrote:
> On Wed, Sep 11, 2013 at 01:43:20PM -0700, Jesse Barnes wrote:
> > Unsupported; we just do RC6.
> >
> > Signed-off-by: Jesse Barnes
>
> You only change the sysfs stuff here, so I wondered where the hunk for
> intel_pm.c is. And noticed t
From: Paulo Zanoni
Both callers had code to sanitize the uncore and restore the GTT
mappings just before calling __i915_drm_thaw, so Chris suggested I
should unify the code.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 39 ++-
1 file cha
On 09/12/2013 10:39 PM, Thomas Gleixner wrote:
On Thu, 12 Sep 2013, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner wrote:
I think for ttm drivers it's just execbuf being exploitable. But on
drm/i915 we've
had the same issue with the pwrite/pread ioctls, so a simple
glB
On Wed, Sep 11, 2013 at 01:43:20PM -0700, Jesse Barnes wrote:
> Unsupported; we just do RC6.
>
> Signed-off-by: Jesse Barnes
You only change the sysfs stuff here, so I wondered where the hunk for
intel_pm.c is. And noticed that we don't actually obey the enable_rc6
parameter! Aside: We don't do
On 09/10/2013 01:00 PM, Jani Nikula wrote:
Hi Hans -
On Sat, 07 Sep 2013, Hans de Bruin wrote:
Since a day or two the screen of my laptop goes blank when the kernel
switches resolution in the boot process. Happily the x-server turns it
on again.
Please try the drm-intel-nightly branch of
gi
On Thu, Sep 12, 2013 at 9:58 PM, Thomas Gleixner wrote:
>
>> On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra wrote:
>> > If 'sane' userspace is never supposed to do this, then only insane
>> > userspace is going to hurt from this and that's a GOOD (tm) thing,
>> > right? ;-)
>>
>> Afaik sane user
On Thu, Sep 12, 2013 at 05:59:51PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote:
> > This is just a remnant from the old days when our reset handling was
> > horribly racy, suffered from terribly locking issues and often happily
> > live-locked. Those
On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner wrote:
>> I think for ttm drivers it's just execbuf being exploitable. But on
>> drm/i915 we've
>> had the same issue with the pwrite/pread ioctls, so a simple
>> glBufferData(glMap) kind of recursion from gl clients blew the kernel
>> to pieces ..
On Thu, Sep 12, 2013 at 05:35:43PM +0100, Chris Wilson wrote:
> Not quite, as it would be possible for the evil userspace to trigger a
> GPU hang that would cause the sane userspace to spin indefinitely
> waiting for the error recovery to kick in.
So with FIFOn+1 preempting FIFOn its a live-lock
From: Paulo Zanoni
Our code makes a lot of assumptions regarding what each DDI port
actually supports, and the VBT should tell us what is really happening
in the hardware. So parse the information provided by the VBT and
check if any of our assumptions is wrong.
Our driver also has a history of
On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra wrote:
> If 'sane' userspace is never supposed to do this, then only insane
> userspace is going to hurt from this and that's a GOOD (tm) thing,
> right? ;-)
Afaik sane userspace doesn't hit the _deadlock_ (or lifelock if we
have the set_need_resche
Op 12-09-13 17:36, Daniel Vetter schreef:
> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
>> So I'm poking around the preemption code and stumbled upon:
>>
>> drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
>> drivers/gpu/drm/ttm/ttm_bo_vm.c:set
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm
From: Paulo Zanoni
There's no reason to init a DP connector if the encoder just supports
HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
AUX transactions to detect if there's something there. Same goes for a
DP connector that doesn't support HDMI, but I'm not sure these
act
On Thu, Sep 12, 2013 at 10:45:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On HSW enabling a plane on a disabled pipe may hang the entire system.
> And there's no good reason for doing it ever, so just don't.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ville Syr
On 09/12/2013 05:58 PM, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra wrote:
The one in ttm is just bonghits to shut up lockdep: ttm can recurse
into it's own pagefault handler and then deadlock, the trylock just
keeps lockdep quiet.
Could you describe how it could recu
From: Paulo Zanoni
We currently use the recommended values from BSpec, but the VBT
specifies the correct value to use for the hardware we have, so use
it. We also fall back to the recommended value in case we can't find
the VBT.
In addition, this code also provides some infrastructure to parse m
From: Ville Syrjälä
On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
1 file changed, 2 insertions(+), 2 d
On Thu, Sep 12, 2013 at 05:11:25PM +0200, Maarten Lankhorst wrote:
> Op 12-09-13 17:06, Peter Zijlstra schreef:
> > Hi Dave,
> >
> > So I'm poking around the preemption code and stumbled upon:
> >
> > drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
> > drivers/gpu/drm/ttm/ttm_bo
On Thu, Sep 12, 2013 at 10:45:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On HSW enabling a plane on a disabled pipe may hang the entire system.
> And there's no good reason for doing it ever, so just don't.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ville Syr
On Thu, Sep 12, 2013 at 05:57:29PM +0200, Daniel Vetter wrote:
> This very much looks like copypasta from drm/i915's fault handler.
> It was used there to duct-tape over issues around gpu reset handling.
>
> Since that can't ever happen for udl and there's seemingly no other
> reason for this just
On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote:
> This is just a remnant from the old days when our reset handling was
> horribly racy, suffered from terribly locking issues and often happily
> live-locked. Those days are now gone so we can drop the hacks and just
> rip the reschedul
On Thu, Sep 12, 2013 at 6:44 PM, Thomas Hellstrom wrote:
>
> I think a possible fix would be if fault() were allowed to return an error
> and drop the mmap_sem() before returning.
>
> Otherwise we need to track down all copy_to_user / copy_from_user which
> happen with bo::reserve held.
For maxim
From: Paulo Zanoni
Our code currently assumes that port X will use the DP AUX channel X
and the DDC pin X. The VBT should tell us how things are mapped, so
add some WARNs in case we discover our assumptions are wrong (or in
case the VBT is just wrong, which is also perfectly possible).
Why would
On Thu, Sep 12, 2013 at 10:45:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Jani Nikula
>
> The cursor is disabled before crtc mode set in crtc disable (and we
> assert this is the case), and enabled afterwards in crtc enable. Do not
> update it in crtc mode set.
>
> On HSW enabling a
On Thu, Sep 12, 2013 at 05:58:49PM +0200, Daniel Vetter wrote:
> On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra wrote:
> >> The one in ttm is just bonghits to shut up lockdep: ttm can recurse
> >> into it's own pagefault handler and then deadlock, the trylock just
> >> keeps lockdep quiet. We've
Hi Dave,
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
drivers/
On Thu, Sep 12, 2013 at 05:36:43PM +0200, Daniel Vetter wrote:
> The set_need_resched in i915_gem.c:i915_gem_fault can actually be
> removed. It was there to give the error handler a chance to sneak in
> and reset the hw/sw tracking when the gpu is dead. That hack goes back
> to the days when the l
From: Jani Nikula
The cursor is disabled before crtc mode set in crtc disable (and we
assert this is the case), and enabled afterwards in crtc enable. Do not
update it in crtc mode set.
On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it
From: Ville Syrjälä
On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
dif
From: Paulo Zanoni
Sometimes I see the "non asle set request??" message on my Haswell
machine, so I decided to get the spec and see if some bits are missing
from the mask. We do have some bits missing from the mask, so this
patch adds them. But I still see the "non asle set request??" message
on
From: Paulo Zanoni
Before this patch, i915_drm_thaw would always return 0. After this
patch, it returns the error code from __i915_drm_thaw(), since it's
the only sub-function that can return an error code.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed,
From: Paulo Zanoni
We don't seem to be using the pointer after it's unmapped, so this
patch doesn't fix any bug I can reproduce.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_opregion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/dr
From: Paulo Zanoni
So far we control all the reads an none of them exceeds the current
limit of 20 bytes, but we never think about this when reviewing
patches, so add a big WARN. In case we ever hit that WARN, we whould
change the size of the reply array.
Signed-off-by: Paulo Zanoni
---
driver
From: Paulo Zanoni
Because this PCI config register doesn't exist on Gen5+.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_suspend.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
On Thu, Sep 12, 2013 at 01:58:17PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because this PCI config register doesn't exist on Gen5+.
>
> Signed-off-by: Paulo Zanoni
Yep. Can't see it in configdb. Actually it's only listed there for CTG
and CLN, which I guess makes sense as non-mobil
On Thu, Sep 12, 2013 at 01:58:21PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Before this patch, i915_drm_thaw would always return 0. After this
> patch, it returns the error code from __i915_drm_thaw(), since it's
> the only sub-function that can return an error code.
You could go a st
On Thu, Sep 12, 2013 at 01:58:18PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> So far we control all the reads an none of them exceeds the current
> limit of 20 bytes, but we never think about this when reviewing
> patches, so add a big WARN. In case we ever hit that WARN, we whould
> cha
2013/9/11 Chris Wilson :
> On Wed, Sep 11, 2013 at 06:02:48PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> We currently use the recommended values from BSpec, but the VBT
>> specifies the correct value to use for the hardware we have, so use
>> it. We also fall back to the recommended va
This very much looks like copypasta from drm/i915's fault handler.
It was used there to duct-tape over issues around gpu reset handling.
Since that can't ever happen for udl and there's seemingly no other
reason for this just drop it.
Reported-by: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Linux Ker
On Fri, Sep 13, 2013 at 5:59 AM, Chon Ming Lee wrote:
> In non PC system, such as IVI, may not use BIOS, instead it uses boot
> loader with only minimal system initialization. Most of the time, boot
> loader doesn't come with VBIOS, and depends on device driver to fully
> initialize the display c
Sprinkling random special functions all over the place always
has the risk that we miss it somewhere. Furthermore in this
case the ordering wrt gem_init_hw was actually different between
the driver load sequence and the resume sequence.
So just call this at the beginning of modeset_init_hw.
Cc: P
This is just a remnant from the old days when our reset handling was
horribly racy, suffered from terribly locking issues and often happily
live-locked. Those days are now gone so we can drop the hacks and just
rip the reschedule-point out.
Reported-by: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Linu
On Thu, Sep 12, 2013 at 06:22:10PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 12, 2013 at 05:58:49PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra
> > wrote:
> > >> The one in ttm is just bonghits to shut up lockdep: ttm can recurse
> > >> into it's own pagefault
In non PC system, such as IVI, may not use BIOS, instead it uses boot
loader with only minimal system initialization. Most of the time, boot
loader doesn't come with VBIOS, and depends on device driver to fully
initialize the display controller and GPU.
For Valleyview, without VBIOS, i915 fails t
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra wrote:
>> The one in ttm is just bonghits to shut up lockdep: ttm can recurse
>> into it's own pagefault handler and then deadlock, the trylock just
>> keeps lockdep quiet. We've had that bug arise in drm/i915 due to some
>> fun userspace did and now
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra wrote:
>
> So I'm poking around the preemption code and stumbled upon:
>
> drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
> drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
> drivers/gpu/drm/ttm/ttm_bo_
Op 12-09-13 17:06, Peter Zijlstra schreef:
> Hi Dave,
>
> So I'm poking around the preemption code and stumbled upon:
>
> drivers/gpu/drm/i915/i915_gem.c:set_need_resched();
> drivers/gpu/drm/ttm/ttm_bo_vm.c:set_need_resched();
> drivers/gpu/drm/ttm/ttm_bo_vm
From: Ville Syrjälä
Add APIs to get/put power well references for specific purposes.
Also reorganize the internal i915_request power well handling to use the
reference count just like everyone else. This way all we need to do is
check the reference count and we know whether the power well needs
From: Ville Syrjälä
We increase/decrease the power well refcount in several places now, and
all of those places need to do the same thing, so pull that code into
a few small helper functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 39 +---
From: Ville Syrjälä
VGA registers live inside the power well on HSW, so in order to write
the VGA MSR register we need the power well to be on.
We really must write to the register to properly clear the
VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when
the power well is down.
From: Ville Syrjälä
The init and resume codepaths want to handel the power well in slightly
different ways, so pull the power well init out from
intel_modeset_init_hw() which gets called in both cases.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_dma.c | 2 ++
drivers/gpu/dr
From: Ville Syrjälä
VGA registers/memory live inside the the display power well. Add a power
domain for VGA.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915
Match of a lifetime! In the red corner VGA, the underdog. In the blue corner,
the killer of registers, the bane of memory access, the POWER WELL! Who will
win?
This series eliminates the unclaimed register access warning introduced by
the delayed VGA memory disable. And now we actually disable VGA
On Thu, Sep 12, 2013 at 2:30 PM, Damien Lespiau
wrote:
> On Thu, Sep 12, 2013 at 02:02:30PM +0200, Daniel Vetter wrote:
>> The simulator doesn't like this nor really support it :(
>>
>> Cc: Ben Widawsky
>> Cc: Ville Syrjälä
>> Cc: Damien Lespiau
>> Signed-off-by: Daniel Vetter
>
> Aye! (I reca
On Thu, Sep 12, 2013 at 02:02:30PM +0200, Daniel Vetter wrote:
> The simulator doesn't like this nor really support it :(
>
> Cc: Ben Widawsky
> Cc: Ville Syrjälä
> Cc: Damien Lespiau
> Signed-off-by: Daniel Vetter
Aye! (I recall we don't really need that for i-g-t, but can't hurt)
Reviewed-
The simulator doesn't like this nor really support it :(
Cc: Ben Widawsky
Cc: Ville Syrjälä
Cc: Damien Lespiau
Signed-off-by: Daniel Vetter
---
lib/drmtest.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 9d4c5da..509db13 100644
--- a/lib/drmtest.c
+
87 matches
Mail list logo
