On Sat, 15 Oct 2011 13:47:15 -0700, Ben Widawsky wrote:
> [Description from: Daniel Vetter]
> I've just discussed this quickly with Chris on irc and it's probably
> best to just kill the list_empty early bailout. gpu_idle isn't a
> fastpath, so who cares. One candidate where we emit commands to th
On Sat, 15 Oct 2011 13:47:16 -0700, Ben Widawsky wrote:
> Idle the GPU before doing any unmaps. We know if VT-d is in use through
> an exported variable from iommu code.
>
> This should avoid a known HW issue.
>
> Signed-off-by: Ben Widawsky
Just one minor comment below, but
Reviewed-by: Chris
On Sat, Oct 15, 2011 at 01:47:16PM -0700, Ben Widawsky wrote:
> Idle the GPU before doing any unmaps. We know if VT-d is in use through
> an exported variable from iommu code.
>
> This should avoid a known HW issue.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/char/agp/intel-gtt.c|
On Sat, Oct 15, 2011 at 01:47:15PM -0700, Ben Widawsky wrote:
> [Description from: Daniel Vetter]
> I've just discussed this quickly with Chris on irc and it's probably
> best to just kill the list_empty early bailout. gpu_idle isn't a
> fastpath, so who cares. One candidate where we emit commands
Idle the GPU before doing any unmaps. We know if VT-d is in use through
an exported variable from iommu code.
This should avoid a known HW issue.
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c| 28
drivers/gpu/drm/i915/i915_drv.h |2 +
[Description from: Daniel Vetter]
I've just discussed this quickly with Chris on irc and it's probably
best to just kill the list_empty early bailout. gpu_idle isn't a
fastpath, so who cares. One candidate where we emit commands to the ring
without adding anything onto these lists is e.g. pageflip.
From: David Woodhouse
We really don't want this to work in the general case; device drivers
*shouldn't* care whether they are behind an IOMMU or not. But the
integrated graphics is a special case, because the IOMMU and the GTT are
all kind of smashed into one and generally horrifically buggy, so
Tested-by: Ben Widawsky
I ran the airlied test on it for 4 minutes. It normally hangs in <1
minute.
Changes from the last version:
Rebased on the new patches from David Woodhouse
Use the new global to determine if we need workaround.
Idling can fail now, instead of being uninterruptible.
No more
From: David Woodhouse
To work around a hardware issue, we have to submit IOTLB flushes while
the graphics engine is idle. The graphics driver will (we hope) go to
great lengths to ensure that it gets that right on the affected
chipset(s)... so let's not screw it over by deferring the unmap and
do
On Sat, 15 Oct 2011 16:01:17 +0200
Daniel Vetter wrote:
> On Tue, Oct 11, 2011 at 04:51:16PM -0700, Ben Widawsky wrote:
> > I thought we all agreed that "PIPE_CONTROL_WRITE_FLUSH" doesn't make
> > sense for Gen6? Or was that just me agreeing with myself?
>
> I couldn't find any comment of yours
On Tue, Oct 11, 2011 at 04:51:16PM -0700, Ben Widawsky wrote:
> I thought we all agreed that "PIPE_CONTROL_WRITE_FLUSH" doesn't make
> sense for Gen6? Or was that just me agreeing with myself?
I couldn't find any comment of yours to that effect ... :p You'd be much
happier if I add a RENDER_CACHE_
Sorry for the late reply. I have now tested with the current kernel (3.0.6).
At least it does not mess up as much as the manual patches, but still it
does not work.
I have attached the dmesg output if you want to check.
If you would like me to test patches, please do not hesitate.
As I am a bit s
12 matches
Mail list logo
