On Wed, Nov 23, 2011 at 02:25:14AM +0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang
> wrote:
>
> > So the v3 patch will behave equally well on KMS console, gnome desktop
> > and bare X. Shall we just use it, or go back and use the original
> > ->hot_remove patch?
>
On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
>
> > So the user has to choose between 5W of power saving or having dmar? And
> > we default to giving them dmar? I think that's going to come as a
> > surprise to people
On Sat, Jul 09, 2011 at 09:25:04AM +0100, Chris Wilson wrote:
> In order to correctly account for reserving space in the GTT and fences
> for a batch buffer, we need to independently track whether the fence is
> pinned due to a fenced GPU access in the batch from from whether the
> buffer is pinned
On Sun, Nov 13, 2011 at 11:00:22AM +, Chris Wilson wrote:
> In order to correctly account for reserving space in the GTT and fences
> for a batch buffer, we need to independently track whether the fence is
> pinned due to a fenced GPU access in the batch from from whether the
> buffer is pinned
In order to correctly account for reserving space in the GTT and fences
for a batch buffer, we need to independently track whether the fence is
pinned due to a fenced GPU access in the batch or whether the buffer is
pinned in the aperture. Currently we count the fenced as pinned if the
buffer has a
On Tue, Nov 22, 2011 at 20:58, Ben Widawsky wrote:
> Many of the old fields from Ironlake have gone away. Strip all those
> fields, and try to update to fields people care about. RC information
> isn't exactly ideal anymore. All we can guarantee when we read the
> register is that we're not using
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
> >
> > > So the user has to choose between 5W of power saving or having dmar? And
> > > we default to giving th
On Wed, Nov 23, 2011 at 02:01:54PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> > On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett
> > > wrote:
> > >
> > > > So the user has to ch
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
>
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).
Well, the ILK workaround was only
On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the on
On Wed, Nov 23, 2011 at 04:31:54PM +0100, Daniel Vetter wrote:
> - Wait 2 minutes for the stuck-in-atomic detection logic to kick in and
> grab the backtrace over netconsole. Notice that the kernel is stuck
> trying to flush the dmar tlb cache (that's how I managed to track it
> down to a dma
Those are needed by the rc6 and semaphores support in i915 driver.
In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.
CC: Keith Packard
CC: Daniel Vetter
Signed-off-by: Eugeni Dodonov
---
On Wed, Nov 23, 2011 at 11:32:31AM -0200, Eugeni Dodonov wrote:
> On Tue, Nov 22, 2011 at 20:58, Ben Widawsky wrote:
>
> > Many of the old fields from Ironlake have gone away. Strip all those
> > fields, and try to update to fields people care about. RC information
> > isn't exactly ideal anymore
On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang wrote:
> What I need is a hot plug hook that knows whether the monitor is
> plugged or removed, which is only possible if the hook is called
> after ->detect().
That would be mode_set to tell you that the monitor is in use, and the
disable functio
On Wed, Nov 23, 2011 at 03:43:05PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> > Hm, that comment confuses me a bit. I've always thought that igfx_off only
> > instantiates a identity mapping and leaves the dmar unit on. Is that
> > wrong?
>
> It's co
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
>
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.
This i
On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse wrote:
> This is horrid. In the general case, drivers have no business knowing
> this. We need to properly identify what is wrong with this hardware, and
> put in a quirk for it — perhaps refusing to enable the IOMMU at all on
> the broken chips
On Sat, 22 Oct 2011 19:41:23 -0700, Ben Widawsky wrote:
> + mode != dev_priv->relative_constants_mode) {
> + if (INTEL_INFO(dev)->gen < 4)
> + return -EINVAL;
> +
> + if (INTEL_INFO(dev)->gen > 5 &&
> +
On Wed, Nov 23, 2011 at 01:34:06PM -0800, Keith Packard wrote:
> On Sat, 22 Oct 2011 19:41:23 -0700, Ben Widawsky wrote:
>
> > + mode != dev_priv->relative_constants_mode) {
> > + if (INTEL_INFO(dev)->gen < 4)
> > + return -EINVAL;
> > +
>
After my refactoring, Chris noticed that we had a bug.
dev_priv keeps track of the current addressing mode that gets set at
execbuffer time. Unfortunately the existing code was doing this before
acquiring struct_mutex which leaves a race with another thread also
doing an execbuffer. If that wasn't
23 matches
Mail list logo
