[Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
The recursion loop goes retire_requests-unbind-gpu_idle-retire_reqeusts. Every time we go through this we need a - active object that can be retired - and there are no other references to that object than the one from the active list, so that it gets unbound and freed immediately. Otherwise the recursion stops. So the recursion is only limited by the number of objects that fit these requirements sitting in the active list any time retire_request is called. Issue exercised by tests/gem_unref_active_buffers from i-g-t. There's been a decent bikeshed discussion whether it wouldn't be better to pass around a flag, but imo this is o.k. for such a limited case that only supports a w/a. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson chris@chris-wilson # we built better bikesheds, but this keeps the rain off for now --- drivers/gpu/drm/i915/i915_gem.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 036bc58..d7d5801 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2026,8 +2026,13 @@ i915_wait_request(struct intel_ring_buffer *ring, * to handle this, the waiter on a request often wants an associated * buffer to have made it to the inactive list, and we would need * a separate wait queue to handle that. +* +* To avoid a recursion with the ilk VT-d workaround (that calls +* gpu_idle when unbinding objects with interruptible==false) don't +* retire requests in that case (because it might call unbind if the +* active list holds the last reference to the object). */ - if (ret == 0) + if (ret == 0 dev_priv-mm.interruptible) i915_gem_retire_requests_ring(ring); return ret; -- 1.7.6.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel 2011Q4 graphics package
2011/12/6 Alan W. Irwin ir...@beluga.phys.uvic.ca On 2011-12-05 23:03-0200 Eugeni Dodonov wrote: Hi, We’d like to announce Intel 2011Q4 graphics package, focused on performance and stability improvements in the Intel Linux Graphics stack. Please check http://intellinuxgraphics.org/**2011Q4.htmlhttp://intellinuxgraphics.org/2011Q4.htmlfor the recommended stack, list of new features and known issues. I'd also like to thank all the developers, community, our users and testers for helping us to improve the drivers. Thanks a lot for all your work, help and support! And as usual, if you find any new issues, please let as know by filing bugs following the http://intellinuxgraphics.org/**how_to_report_bug.htmlhttp://intellinuxgraphics.org/how_to_report_bug.htmlguidelines. Thanks, Eugeni Dodonov Intel Open Source Technology Center Hi Eugeni: My primary interest in Intel graphics is I just want something that is completely stable for a mostly 2D desktop with the ability to play some low-end 3D games. Thus, I have been reasonably content with what I get from Debian stable for my g33 graphics hardware, but I would like to upgrade to Debian testing for a number of reasons. However, what's been holding me back from that upgrade is concern that g33 has not been validated for a while by the Intel team (e.g., no mention of g33 for your first quarterly release this year). Therefore, I was very glad to see g33 mentioned as one of the validated platforms both for this release and also for the 3rd quarterly release this year so my hopes that g33 will work with no big issues for Debian testing are much higher than they were. However, testing results for only some (Pineview 32-bit, and Sandybridge/Ivybridge for 64-bit) of your validated platforms are linked at the above URL. Is there a link you can give me for the g33 test results (preferably 64 bit)? Hi Alan, for g33, it is not being the main focus of the release validation and testing lately, so it receives limited validation, checking for regressions mostly. However, for all the kernel/mesa/drm/2d releases, the expectation is for it to work in a no regressions mode. It should be similar to pineview for most test cases and workloads. Having said that, we do intend to provide a good support for it. So if you observe any new issues or bugs which are not previously filled in our bugzilla, please, let us know. Even if we do not focus on full validation and testing for it as part of the stack release, we still do intend to have a good level of functionality for it. So if there are stability or regression issues, or its functionality under Debian testing is somehow worse than with Debian stable, we'd like to know about it. Thanks! -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] i915/intel-acpi.c: failed to get supported _DSM functions (was: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off)
On Mon, Dec 05, 2011 at 09:56:47PM +0100, Baptiste Jonglez wrote: CC-ing intel-gfx@lists.freedesktop.org (see below) On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote: [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions (attached is the relevant part of dmesg [1]) Have no idea for this _DSM error, need help from drm and acpi experts. It definitely looks like an ACPI issue. That function is defined in `drivers/gpu/drm/i915/intel_acpi.c'. The whole file was added more than a year ago by commit 723bfd707a97 (see the relevant thread on intel-gfx@ [1]) to add _DSM support. One of the first comment is about Calpella, which is exactly the platform of my laptop (as shown by lshw) Ignore that - it's entirely harmless. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/i915: add HAS_ALIASING_PPGTT parameter for userspace
On Mon, Nov 28, 2011 at 10:24:55PM +0100, Daniel Vetter wrote: On Sanybridge a few MI read/write commands only work when ppgtt is enabled. Userspace therefore needs to be able to check whether ppgtt is enabled. For added hilarity, you need to reset the use global GTT bit on both snb/ivb when ppgtt is enabled, otherwise it won't work. Despite what bspec says about automatically using ppgtt ... Luckily PIPE_CONTROL (the only write cmd current userspace uses) is not affected by all this, as tested by tests/gem_pipe_control_store_loop. Since this is all SNB only, and we have no good benchmarks to show performance gains, can we not just enable this for IVB+? Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: The recursion loop goes retire_requests-unbind-gpu_idle-retire_reqeusts. Every time we go through this we need a - active object that can be retired - and there are no other references to that object than the one from the active list, so that it gets unbound and freed immediately. Otherwise the recursion stops. So the recursion is only limited by the number of objects that fit these requirements sitting in the active list any time retire_request is called. Issue exercised by tests/gem_unref_active_buffers from i-g-t. There's been a decent bikeshed discussion whether it wouldn't be better to pass around a flag, but imo this is o.k. for such a limited case that only supports a w/a. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson chris@chris-wilson # we built better bikesheds, but this keeps the rain off for now --- What about: http://lists.freedesktop.org/archives/intel-gfx/2011-October/012984.html Did someone prove that doesn't work? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/i915: add HAS_ALIASING_PPGTT parameter for userspace
On Tue, 6 Dec 2011 09:39:39 -0800, Ben Widawsky b...@bwidawsk.net wrote: On Mon, Nov 28, 2011 at 10:24:55PM +0100, Daniel Vetter wrote: On Sanybridge a few MI read/write commands only work when ppgtt is enabled. Userspace therefore needs to be able to check whether ppgtt is enabled. For added hilarity, you need to reset the use global GTT bit on both snb/ivb when ppgtt is enabled, otherwise it won't work. Despite what bspec says about automatically using ppgtt ... Luckily PIPE_CONTROL (the only write cmd current userspace uses) is not affected by all this, as tested by tests/gem_pipe_control_store_loop. Since this is all SNB only, and we have no good benchmarks to show performance gains, can we not just enable this for IVB+? Don't we have the same basic problem with IVB, that we need to adjust the commands in the batchbuffer depending on whether HAS_ALIASING_PPGTT is true? Or do you mean that we should just assume that IVB uses the ppgtt and so kernel 3.3+, which will be around March... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Dual-LVDS Acer Iconia laptop
Cc-ing to intel-gfx@ On Tue, Dec 06, 2011 at 06:48:17PM +0100, Benjamin Tissoires wrote: Hi Guys, I've seen on the list that some of you (as we were) have troubles with the second screen on the iconia laptop. In our lab, we managed to make it work by using two patches: * http://web.archiveorange.com/archive/v/rNRcWX4nB2U5uRmbLm9h (LVDS are digital as well), this solved the xrandr disconnected issue * a small patch we are finalizing to call the right DMI function to light up the second LCD. Awesome, thank you! It's quite frustrating to see that this patch was written almost 6 months ago then forgotten... It's already compiling, let's see if it works :) So, as soon as we have clean this code, this bug will be solved. This first patch seems indeed based on an old tree, it requires some small changes to apply. Cheers, Benjamin PS: I'm sorry to start a new thread as I just registered myself on the list and was not able to get the previous Message-ID. No problem, I'll post on the original thread for the record. Thank you again, Baptiste ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Is MI_FLUSH_ENABLE bit 12?
On Mon, 5 Dec 2011 14:57:09 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 30 Nov 2011 13:54:47 -0800 Eric Anholt e...@anholt.net wrote: On Wed, 30 Nov 2011 03:42:00 +, Ben Widawsky b...@bwidawsk.net wrote: Non-text part: multipart/signed On Tue, Nov 29, 2011 at 04:47:57PM -0800, Eric Anholt wrote: On Mon, 28 Nov 2011 18:48:04 -0800, Keith Packard kei...@keithp.com wrote: Non-text part: multipart/mixed Non-text part: multipart/signed Just reading through vol1c.4 of the bspec this evening and found something odd. Bit 11 of MI_MODE is Invalidate UHPTR enable. Bit 12 of MI_MODE is MI_FLUSH Enable And, yet, in i915_reg.h: #define MI_MODE 0x0209c # define VS_TIMER_DISPATCH(1 6) # define MI_FLUSH_ENABLE (1 11) Are we off-by-one on MI_FLUSH_ENABLE? Seems like this would cause serious problems... I think we are. On the other hand, based on actual behavior plus reading of simulator, I believe that the bit does nothing, regardless. I do not think so. We've (Chris, I, and perhaps Jesse?) been through this excercise at least twice before, and both times resulted in hangs when we switched to bit 12 on Ironlake, not sure about other platforms. There is no MI_FLUSH enable bit on Ironlake in my copy of the docs. Bit 12 is MBZ on that hardware. It's one of those been there forever bits. A comment wouldn't hurt, but we should also put in a doc change request (in fact I think I did that but it went into a black hole). Well, by been there forever, you mean introduced in: commit a69ffdbfcba8eabf2ca9d384b578e6f28b339c61 Author: Zhenyu Wang zhen...@linux.intel.com Date: Mon Aug 30 16:12:42 2010 +0800 drm/i915: Enable MI_FLUSH on Sandybridge MI_FLUSH is being deprecated, but still available on Sandybridge. Make sure it's enabled as userspace still uses MI_FLUSH. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com Cc: sta...@kernel.org Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk It should be removed on Ironlake, and fixed to be 12 on SNB or just removed. pgpYlkgSIiQRP.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]
On Tue, Dec 06, 2011 at 11:12:26PM +0100, Benjamin Tissoires wrote: Hi Baptiste, Hi, On Tue, Dec 6, 2011 at 22:51, Baptiste Jonglez bapti...@jonglez.org wrote: The second screen works fine with the attached patch. It actually is 6 months old but seems to have been lost in the wild... You don't have the problem of the second backlight still off? On our Iconia, we need to trigger a special DMI command to set it up (SDSS, IIRC). No, with the patch, it worked out-of-the-box. I can even control the brightness in `/sys/class/backlight/acpi_video0/brightness' (it affects both displays at the same time though). But even at 0, it's still perfectly readable. Maybe this a bug that got fixed recently? I've actually tried the 3.1 kernel (and then the 3.2-rc4) because I noticed a lot of commits and improvements in the i915 driver recently. Thanks Benjamin! All the credits are from Ajax and somebody else on IRC I don't recall, really sorry. Thanks to them. Cheers, Benjamin. Regards, Baptiste ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Rotating video signal in INTEGRITY OS
Hello all,
I have a board that is using the Intel 855GME chipset.
http://www.intel.com/content/www/us/en/chipsets/value-chipsets/chipset-855gme.html
it has two outputs, LVDS and a VGA.
My application is build on the INEGRITY OS, not LINUX.
I need to rotate only the VGA output by 180 degrees.
How can I do it using the 855GME? I cannot use the RandR in INTEGRITY.
I am using a graphic library called PEG.
http://www.swellsoftware.com/products/pegplus.php
in its source I see when the data is written to a buffer that is mapped to the
memory region in the kernel called __ghs_vga_videomem.
The problem the same data is shown on both outputs.
Here is the declaration of the memory region:
MemoryReservation __ghsentry_reservedmem_vgaframebuffer =
{ MEMORY_RWE | MEMORY_IOCOHERENT | MEMORY_VOLATILE,
0, 0x400a, 0x400b, Other_MemoryType, true, 0x, 0x,
__ghs_vga_videomem };
1. Does the rotation is done by writing the data rotated or it is rotated
by the hardware?
2. How do I split the two outputs?
Thanks.
Alex.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
