On Wed, Oct 17, 2012 at 4:22 PM, Daniel Vetter wrote:
> On Mon, Oct 15, 2012 at 05:16:23PM -0300, Rodrigo Vivi wrote:
> > On the worst scenario, users with new hardwares and old kernel from
> enabling times can get black screens.
> > So, now on, this i915_perliminary_hw_support variable shall be
On Wed, 17 Oct 2012 15:44:54 -0700, Ben Widawsky wrote:
> On Wed, 17 Oct 2012 08:17:51 +0200
> Oleksij Rempel wrote:
>
> > Hallo all,
> >
> > i get on Asus Zenbook UX32A [IVB] fallowing errors:
> > [4.464893] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out
> > waiting for forcewake old
On Wed, 17 Oct 2012 08:17:51 +0200
Oleksij Rempel wrote:
> Hallo all,
>
> i get on Asus Zenbook UX32A [IVB] fallowing errors:
> [4.464893] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out
> waiting for forcewake old ack to clear.
> [ 6678.604211] [drm:__gen6_gt_force_wake_mt_get] *ERROR*
Hi
2012/10/11 Daniel Vetter :
> We now no longer rely on this.
>
> This is step 1 on a long journey to rid us of the save/restore
> madness, which tends to lightly paper over many issues, and cause
> tons of bad things itself ...
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915
Hi
2012/10/11 Daniel Vetter :
> ... instead of relying on the register save/restore madness to do this.
>
> To extract a bit of code call drm_mode_config_reset both on resume
> and boot-up and move the hw state frobbing from the crt_init to the
> ->reset callback. The crt connector is the only one
2012/10/12 Daniel Vetter :
> On Fri, Oct 12, 2012 at 7:17 PM, Paulo Zanoni wrote:
>> Ok, so please do a final test: try to write something to those
>> "must-be-preserved" bits and check if the values stay or not. If after
>> writing 1 to bits 17-18, 20-23 you read 0, then you have my
>> Reviewed-b
On Wed, Oct 17, 2012 at 04:52:28PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/10/17 Daniel Vetter :
> > We completely compute these anew in each modeset, hence we don't rely
> > on them containing anything valid after resume.
> >
> > To avoid breaking any ums setup due to reordering of the reads/wri
On Tue, Oct 16, 2012 at 02:49:58PM +0300, Jani Nikula wrote:
> On Mon, 15 Oct 2012, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Much simpler and looks more like the M/N code inside intel_display.c.
>
> Reviewed-by: Jani Nikula
Merged up to this patch, thanks.
-Daniel
--
Daniel Vetter
S
Found while strolling for ilk workarounds since this one is listed
there, too. I think that's a mistake though, since the w/a isn't
listed for snb/ivb, and the relevant register doesn't seem to exist on
ilk.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/d
Hi
2012/10/17 Daniel Vetter :
> We completely compute these anew in each modeset, hence we don't rely
> on them containing anything valid after resume.
>
> To avoid breaking any ums setup due to reordering of the reads/writes
> simply don't reorder anything, but bracket the reads/writes into if
>
On Mon, Oct 15, 2012 at 05:16:23PM -0300, Rodrigo Vivi wrote:
> On the worst scenario, users with new hardwares and old kernel from enabling
> times can get black screens.
> So, now on, this i915_perliminary_hw_support variable shall be used by all
> upcoming platforms that are still under enabli
On Wed, Oct 17, 2012 at 10:05:15AM -0700, Jesse Barnes wrote:
> On Wed, 17 Oct 2012 09:27:24 -0700
> Jesse Barnes wrote:
>
> > On Wed, 17 Oct 2012 12:09:55 +0100
> > Chris Wilson wrote:
> >
> > > No functional change, but reserves 0x2 for use by userspace.
> > >
> > > Signed-off-by: Chris Wils
On Wed, Oct 17, 2012 at 09:31:21AM -0700, Jesse Barnes wrote:
> On Wed, 17 Oct 2012 12:09:54 +0100
> Chris Wilson wrote:
>
> > With the introduction of per-process GTT space, the hardware designers
> > thought it wise to also limit the ability to write to MMIO space to only
> > a "secure" batch b
On Wed, Oct 17, 2012 at 03:58:21PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/10/12 Daniel Vetter :
> > Somehow this was left out in the refactoring that introduced the pch
> > handlers. Avoids a hotplug_mask special case in the ilk_irq_handler.
> >
> > Noticed while hunting down the pch hotplug bit
On Wed, Oct 17, 2012 at 8:47 PM, Eric Anholt wrote:
> Chris Wilson writes:
>
>> With the introduction of per-process GTT space, the hardware designers
>> thought it wise to also limit the ability to write to MMIO space to only
>> a "secure" batch buffer. The ability to rewrite registers is the on
Hi
2012/10/12 Daniel Vetter :
> Somehow this was left out in the refactoring that introduced the pch
> handlers. Avoids a hotplug_mask special case in the ilk_irq_handler.
>
> Noticed while hunting down the pch hotplug bits.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Paulo Zanoni
> ---
> d
Chris Wilson writes:
> With the introduction of per-process GTT space, the hardware designers
> thought it wise to also limit the ability to write to MMIO space to only
> a "secure" batch buffer. The ability to rewrite registers is the only
> way to program the hardware to perform certain operati
On Wed, 17 Oct 2012 09:27:24 -0700
Jesse Barnes wrote:
> On Wed, 17 Oct 2012 12:09:55 +0100
> Chris Wilson wrote:
>
> > No functional change, but reserves 0x2 for use by userspace.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_reg.h |2 ++
> > drivers/gpu/drm/
On Wed, 17 Oct 2012 12:09:54 +0100
Chris Wilson wrote:
> With the introduction of per-process GTT space, the hardware designers
> thought it wise to also limit the ability to write to MMIO space to only
> a "secure" batch buffer. The ability to rewrite registers is the only
> way to program the h
On Wed, 17 Oct 2012 12:09:55 +0100
Chris Wilson wrote:
> No functional change, but reserves 0x2 for use by userspace.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_reg.h |2 ++
> drivers/gpu/drm/i915/intel_pm.c | 10 +-
> 2 files changed, 7 insertions(+), 5 de
On Tue, 16 Oct 2012 16:15:40 +0200, Daniel Vetter wrote:
> On Tue, Oct 16, 2012 at 11:47 AM, Chris Wilson
> wrote:
> >
> > I am still not convinced this fixes anything as at the moment I am
> > simply unable to detect any tearing on my ivb setup if I apply any form of
> > vblank throttling.
> >
From: Damien Lespiau
We were programming register 0x42020 twice on those platforms. Once
should be enough.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/g
From: Damien Lespiau
With the consolidated registers, it appears that we're setting the same
bis several times. Let's just collect the bit we want to set and program
it once.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 files changed, 4 insertions
From: Damien Lespiau
Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and
ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one.
The transforms done are:
PCH_DSPCLK_GATE_D-> ILK_DSPCLK_GATE_D
ILK_DSPCLK_GATE -> ILK_DSPCLK_GATE_D
DPARBUNIT_CLOCK_GATE_
With the introduction of per-process GTT space, the hardware designers
thought it wise to also limit the ability to write to MMIO space to only
a "secure" batch buffer. The ability to rewrite registers is the only
way to program the hardware to perform certain operations like scanline
waits (requir
No functional change, but reserves 0x2 for use by userspace.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 10 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/
We already do that as part of the ringbuffer re-setup at resume time.
Furthermore the register offset has moved on gen6+ around quite a bit,
and on ilk/gm45 we also need to restore the HWS reg for the bsd ring,
not just the render ring.
So again in kms mode this is only confusing a best, hence don
We already call drm_irq_install/uninstall at the right time, which
will set up the irq registers with the correct values (through the
preinstall hooks).
For kms this is at best harmless, in the worst case we get an
interrupt when we don't really expect it.
v2: Fixup the logic, noticed by Paulo Za
We completely compute these anew in each modeset, hence we don't rely
on them containing anything valid after resume.
To avoid breaking any ums setup due to reordering of the reads/writes
simply don't reorder anything, but bracket the reads/writes into if
(!kms) conditionals. More churn, but safer
On Wed, Oct 17, 2012 at 10:43:15AM +0100, Chris Wilson wrote:
> On Wed, 17 Oct 2012 11:17:16 +0200, Daniel Vetter
> wrote:
> > -ENOSPC can happen if userspace is being simplistic and tries to map a
> > too big object. To aid further spurious WARN debugging, also print out
> > the error code.
> >
On Wed, 17 Oct 2012 11:17:16 +0200, Daniel Vetter
wrote:
> -ENOSPC can happen if userspace is being simplistic and tries to map a
> too big object. To aid further spurious WARN debugging, also print out
> the error code.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56017
> Signed-o
-ENOSPC can happen if userspace is being simplistic and tries to map a
too big object. To aid further spurious WARN debugging, also print out
the error code.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56017
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |4 +++-
Hallo all,
i get on Asus Zenbook UX32A [IVB] fallowing errors:
[4.464893] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out
waiting for forcewake old ack to clear.
[ 6678.604211] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out
waiting for forcewake old ack to clear.
[ 9144.381337] [dr
33 matches
Mail list logo
