On 09/26 14:58, Jesse Barnes wrote:
> On Thu, 26 Sep 2013 23:51:52 +0200
> Daniel Vetter 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://
On Thu, Sep 26, 2013 at 10:31:26PM +0200, Daniel Vetter wrote:
> 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'v
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
Signe
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
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 5 +
On Fri, 27 Sep 2013 01:49:37 +0100
Chris Wilson wrote:
> On Thu, Sep 26, 2013 at 03:34:33PM -0700, Jesse Barnes wrote:
> > On Thu, 26 Sep 2013 23:25:46 +0100
> > Chris Wilson wrote:
> > >
> > > >
> > > > if (!intel_enable_rc6(dev))
> > > > return 0;
> > > >
> > > > -
On Thu, Sep 26, 2013 at 03:34:33PM -0700, Jesse Barnes wrote:
> On Thu, 26 Sep 2013 23:25:46 +0100
> Chris Wilson wrote:
> >
> > >
> > > if (!intel_enable_rc6(dev))
> > > return 0;
> > >
> > > - raw_time = I915_READ(reg) * 128ULL;
> > > - return DIV_ROUND_UP_ULL(raw_time, 10);
On Thursday, September 26, 2013 09:49:03 AM Jörg Otte wrote:
> 2013/9/25 Jani Nikula :
> > On Wed, 25 Sep 2013, Jörg Otte wrote:
> >> 2013/9/25 Jani Nikula :
> >>> On Wed, 25 Sep 2013, Aaron Lu wrote:
> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
> > Backlight can't be mod
From: Paulo Zanoni
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 well. So
before we unbind t
From: Paulo Zanoni
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 when we unbind fbcon we
nee
From: Paulo Zanoni
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 interface gets completely disabl
From: Paulo Zanoni
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() function,
intel_conector->enc
From: Paulo Zanoni
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
manager and run:
echo 0 >
From: Paulo Zanoni
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 fixes the case where we bo
On Thu, 26 Sep 2013 23:25:46 +0100
Chris Wilson 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, that was confusing
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 un
On Thu, Sep 26, 2013 at 09:22:45AM +0100, Chris Wilson wrote:
> commit c6916417c8575637659686ff0e4f744babf0cb4e
> Author: Ben Widawsky
> 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 particul
On Thu, 26 Sep 2013 23:51:52 +0200
Daniel Vetter 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
> > Signe
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
> ---
> drivers/gpu/drm/i915/intel_display.c
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 SM
... 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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 243 ++--
1 file changed, 124 insertions(+), 119 d
No functional change in here, just code movement.
Signed-off-by: Daniel Vetter
---
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
b/drivers/gpu/drm/i915/i915_gem_
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
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 103 ++--
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 40 ++---
1 file changed, 20 insertions(+), 20 deletio
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. Sh
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 f
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
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
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/g
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
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
> ---
> dri
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:
> > > > + obj->has_global
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
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 5 +
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
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm
On 25.09.13 22:55, Daniel Vetter wrote:
On Wed, Sep 25, 2013 at 07:55:26PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The old style frame counter increments at the start of active video.
However for i915_get_vblank_counter() we want a counter that increments
at the start o
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ä
The DSL register increments at the start of horizontal sync, so it
manages to miss the entire active portion of
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 Hur
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 = fals
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 b
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner 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 the rt people and without the
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ä
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless,
On Thu, Sep 26, 2013 at 09:22:45AM +0100, Chris Wilson wrote:
> commit c6916417c8575637659686ff0e4f744babf0cb4e
> Author: Ben Widawsky
> 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 particul
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> 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, extract vlv_clock()
>
> Sig
Wrong subject, I need to fix my script ;-)
-Daniel
On Thu, Sep 26, 2013 at 10:48 AM, Daniel Vetter 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 stable (somehow forg
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 non-triv
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> vlv_find_best_dpll() has an open coded DIV_ROUND_CLOSEST(). Replace it
> with the real thing.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
ville.syrj...@linux.intel.com writes:
s/leel/level in subject
> From: Ville Syrjälä
> Use 'continue' to get rid of one indent level in vlv_find_best_dpll()
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-
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
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 4a10c2ac
commit c6916417c8575637659686ff0e4f744babf0cb4e
Author: Ben Widawsky
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 the routine. So upo
commit c6916417c8575637659686ff0e4f744babf0cb4e
Author: Ben Widawsky
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 the routine. So upo
commit c6916417c8575637659686ff0e4f744babf0cb4e
Author: Ben Widawsky
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 the routine. So upo
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 attache
2013/9/25 Jani Nikula :
> On Wed, 25 Sep 2013, Jörg Otte wrote:
>> 2013/9/25 Jani Nikula :
>>> On Wed, 25 Sep 2013, Aaron Lu wrote:
On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
> Backlight can't be modified with this patch set - neither with
> function keys nor with the
52 matches
Mail list logo
