2013/9/25 Jani Nikula jani.nik...@linux.intel.com:
On Wed, 25 Sep 2013, Jörg Otte jrg.o...@gmail.com wrote:
2013/9/25 Jani Nikula jani.nik...@linux.intel.com:
On Wed, 25 Sep 2013, Aaron Lu aaron...@intel.com wrote:
On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
Backlight can't be
On Wed, Sep 25, 2013 at 02:04:32PM -0700, Jesse Barnes wrote:
Still digging up the actual VBT info for this, but wanted to get this
out there for testing, or in case others are also bugged by this.
This can happen if you boot with an external display connected. In that
case, the attached
commit c6916417c8575637659686ff0e4f744babf0cb4e
Author: Ben Widawsky b...@bwidawsk.net
Date: Tue Sep 24 09:58:00 2013 -0700
drm/i915: Use the new vm [un]bind functions
changes the interpretation of the bind routines, and in particular we
only bind into the global GTT if we pass a flag to
commit c6916417c8575637659686ff0e4f744babf0cb4e
Author: Ben Widawsky b...@bwidawsk.net
Date: Tue Sep 24 09:58:00 2013 -0700
drm/i915: Use the new vm [un]bind functions
changes the interpretation of the bind routines, and in particular we
only bind into the global GTT if we pass a flag to
Hi Dave,
Just a few fixes for regressions and other serious stuff.
Two fix state tracking mismatches, together with an additional patch that
I've submitted to stable (somehow forgotten to tag it) we should have them
fixed now (I hope).
Cheers, Daniel
The following changes since commit
On Wed, Sep 25, 2013 at 05:47:48PM +0100, Damien Lespiau wrote:
Hi,
So this series looks like a good candidate to be merged in one tree.
Beside the new 3d flags added to the mode structure, the other new API
is the SET_CLIENT_CAP ioctl. It seems that this new ioctl could already
be
ville.syrj...@linux.intel.com writes:
s/leel/level in subject
From: Ville Syrjälä ville.syrj...@linux.intel.com
Use 'continue' to get rid of one indent level in vlv_find_best_dpll()
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
ville.syrj...@linux.intel.com writes:
From: Ville Syrjälä ville.syrj...@linux.intel.com
vlv_find_best_dpll() has an open coded DIV_ROUND_CLOSEST(). Replace it
with the real thing.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
On Tue, 24 Sep 2013, Aaron Lu wrote:
locate handle for ACPI video by HID, the problem is, ACPI video node
doesn't really have HID defined(i.e. no _HID control method is defined
ACPI video is supposed to attach a virtual HID node (ACPI_VIDEO_HID) to ACPI
video devices so as to keep the
Wrong subject, I need to fix my script ;-)
-Daniel
On Thu, Sep 26, 2013 at 10:48 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi Dave,
Just a few fixes for regressions and other serious stuff.
Two fix state tracking mismatches, together with an additional patch that
I've submitted to
ville.syrj...@linux.intel.com writes:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
an army of local variables.
Also extract the code to calculate the derived values into
vlv_clock().
v2: Split up the earlier fixes,
On Thu, Sep 26, 2013 at 09:22:45AM +0100, Chris Wilson wrote:
commit c6916417c8575637659686ff0e4f744babf0cb4e
Author: Ben Widawsky b...@bwidawsk.net
Date: Tue Sep 24 09:58:00 2013 -0700
drm/i915: Use the new vm [un]bind functions
changes the interpretation of the bind routines, and
On 25.09.13 10:14, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 04:35:56AM +0200, Mario Kleiner wrote:
On 23.09.13 13:48, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We have all the information we need in the mode structure, so going and
reading it
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for
On Thu, Sep 26, 2013 at 09:04:53AM -0700, Ben Widawsky wrote:
On Thu, Sep 26, 2013 at 09:22:45AM +0100, Chris Wilson wrote:
+ obj-has_global_gtt_mapping = false;
+ obj-has_aliasing_ppgtt_mapping = false;
Actually, the aliasing PPGTT mapping may very well still be in
On Thu, Sep 26, 2013 at 05:16:53PM +0100, Chris Wilson wrote:
On Thu, Sep 26, 2013 at 09:04:53AM -0700, Ben Widawsky wrote:
On Thu, Sep 26, 2013 at 09:22:45AM +0100, Chris Wilson wrote:
+ obj-has_global_gtt_mapping = false;
+ obj-has_aliasing_ppgtt_mapping = false;
On 25.09.13 09:49, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter
On 25.09.13 10:11, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 05:12:54AM +0200, Mario Kleiner wrote:
On 23.09.13 12:02, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The DSL register increments at the start of horizontal sync, so it
manages to miss
We need to use the clock control reg to figure out how many CZ clks are in
30ns and use that as the basis for our RC6 residency calculations.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69692
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h
And add some reg defines while we're at it. Since the units of the RC6
residency counter are actually in CZ clocks, we want to just use the
high bits or we'll overflow too frequently.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h | 4
On Thu, Sep 26, 2013 at 09:38:41AM -0700, Ben Widawsky wrote:
On Thu, Sep 26, 2013 at 05:16:53PM +0100, Chris Wilson wrote:
On Thu, Sep 26, 2013 at 09:04:53AM -0700, Ben Widawsky wrote:
On Thu, Sep 26, 2013 at 09:22:45AM +0100, Chris Wilson wrote:
+
On Thu, Sep 26, 2013 at 12:33:20PM -0700, Jesse Barnes wrote:
And add some reg defines while we're at it. Since the units of the RC6
residency counter are actually in CZ clocks, we want to just use the
high bits or we'll overflow too frequently.
Signed-off-by: Jesse Barnes
On Thu, Sep 26, 2013 at 09:53:29AM +0200, Daniel Vetter wrote:
On Wed, Sep 25, 2013 at 02:04:32PM -0700, Jesse Barnes wrote:
Still digging up the actual VBT info for this, but wanted to get this
out there for testing, or in case others are also bugged by this.
This can happen if you boot
This fixes resume on my test platform, since I think some DPIO bits need
recalibration.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69166
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 13
Hi all,
So the first part reworks the gtt -bind/unbind stuff so that I can rebase the
-internal try without going berserk. 2nd patch is a bit of fluff removal, next
for do reorder i915_gem_gtt.c a bit to make more sense (I've been confused every
2nd time I've had to rebase -internal and there was
We need them in the internal tree still.
Also give them neat generic_ prefixes so that it's clear that only
gen6 is special wrt binding/unbinding a vma. And move the to the top
of the file to avoid forward declarations.
Also use the ppgtt version in the ppgtt init code already, to avoid
marking
Trying to keep on running is poised to run into totally untested code
after a gpu reset or resume. So better just stop things from going
down the toilet.
And at driver load time we better bail out and fix whatever's breaking
ppgtt instead of ignoring it.
So there's no need for this complexity.
It's a little helper only used around for resume, so move it out
of all the setup code.
No functional change in here, just code movement.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 40 ++---
1 file changed, 20
They don't really have a good excuse to sit in the middle of the
platform/generic gtt code.
No functional change in here, just code movement.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 103
No functional change in here, just code movement.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 77 +
1 file changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
... and splatter some header comments above the now nicely-extracted
platform support code.
No functional change in here, just code movement.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 243 ++--
1 file changed,
Otherwise we can die in a fire of not-yet-allocated lazy requests when
we expect them to be there:
[ 4405.463113] [ cut here ]
[ 4405.464769] kernel BUG at
/home/user/src/linux/drivers/gpu/drm/i915/intel_ringbuffer.h:268!
[ 4405.466392] invalid opcode: [#1] PREEMPT
On Thu, Sep 26, 2013 at 02:39:14PM -0700, Jesse Barnes wrote:
This fixes resume on my test platform, since I think some DPIO bits need
recalibration.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69166
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
On Thu, 26 Sep 2013 23:51:52 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Sep 26, 2013 at 02:39:14PM -0700, Jesse Barnes wrote:
This fixes resume on my test platform, since I think some DPIO bits need
recalibration.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69166
On Thu, Sep 26, 2013 at 09:22:45AM +0100, Chris Wilson wrote:
commit c6916417c8575637659686ff0e4f744babf0cb4e
Author: Ben Widawsky b...@bwidawsk.net
Date: Tue Sep 24 09:58:00 2013 -0700
drm/i915: Use the new vm [un]bind functions
changes the interpretation of the bind routines, and
On Thu, Sep 26, 2013 at 12:33:21PM -0700, Jesse Barnes wrote:
We need to use the clock control reg to figure out how many CZ clks are in
30ns and use that as the basis for our RC6 residency calculations.
Hmm, that was confusing. Took a couple of reads to be sure that the
specs said that the
On Thu, 26 Sep 2013 23:25:46 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Sep 26, 2013 at 12:33:21PM -0700, Jesse Barnes wrote:
We need to use the clock control reg to figure out how many CZ clks are in
30ns and use that as the basis for our RC6 residency calculations.
Hmm,
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
These patches allow us to run the module_reload script from intel-gpu-tools on
Haswell. The script basically just removes i915.ko and loads it again.
There's a memory corruption fix and also the fix for fd.o #67813. Notice that
the first patch
From: Paulo Zanoni paulo.r.zan...@intel.com
VGA whack-a-mole!
We need VGA to be disabled whenever our driver is working. So even
without reproducible bugs this patch makes sense, but we do have a bug
solved by this patch.
If you boot a Haswell machine with eDP+HDMI, then kill your display
From: Paulo Zanoni paulo.r.zan...@intel.com
For some reason, every single time I try to run module_reload
something tries to read the connector sysfs files. This happens
after we destroy the encoders and before we destroy the connectors, so
when the sysfs read triggers the connector detect()
From: Paulo Zanoni paulo.r.zan...@intel.com
The consoles who need to do something when unbinding or binding can
optionally implement these functions.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA
From: Paulo Zanoni paulo.r.zan...@intel.com
And create fb_bind and fb_unbind fb_ops that the drivers can
implement.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA interface gets completely disabled, so
From: Paulo Zanoni paulo.r.zan...@intel.com
If we run the following command on Haswell when the power well is
disabled:
echo 0 /sys/class/vtconsole/vtcon1/bind
then we'll get thousands of consecutive interrupts because something
is trying to touch registers that are on the disabled power
On Thursday, September 26, 2013 09:49:03 AM Jörg Otte wrote:
2013/9/25 Jani Nikula jani.nik...@linux.intel.com:
On Wed, 25 Sep 2013, Jörg Otte jrg.o...@gmail.com wrote:
2013/9/25 Jani Nikula jani.nik...@linux.intel.com:
On Wed, 25 Sep 2013, Aaron Lu aaron...@intel.com wrote:
On Wed, Sep
On Thu, Sep 26, 2013 at 03:34:33PM -0700, Jesse Barnes wrote:
On Thu, 26 Sep 2013 23:25:46 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
if (!intel_enable_rc6(dev))
return 0;
- raw_time = I915_READ(reg) * 128ULL;
- return DIV_ROUND_UP_ULL(raw_time,
And add some reg defines while we're at it. Since the units of the RC6
residency counter are actually in CZ clocks, we want to just use the
high bits or we'll overflow too frequently.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h | 4
We need to use the clock control reg to figure out how many CZ clks are in
30ns and use that as the basis for our RC6 residency calculations.
v2: use ULL everywhere for consistency (Chris)
factor out bias for clarity (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=69692
47 matches
Mail list logo
