Re: [Intel-gfx] Updated -next
Dear Yi¹, Am Mittwoch, den 11.04.2012, 03:20 + schrieb Sun, Yi: We finished a new round of kernel testing. The version of kernel is: Kernel: (drm-intel-testing)9d0b5b5468650e0ac72a7786cf6625963f926d4d Merge: ec34a01 b4db1e3 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Mon Apr 9 18:12:03 2012 +0200 We covered the platform IvyBridge, SandyBridge, IronLake, G45 and Pineview. We haven't any available HasWell machine, so didn't do testing on that. the platform seems to be spelled Haswell [1]. General, in this circle, 11 bugs are fixed, 4 bugs are still open, and 2 new bugs about suspending are filed. The detail of bugs are as following: Fixed bugs Bug 38138 - [SNB] mplayer -vo fbdev videofile will cause system hang on HuronRiver (https://bugs.freedesktop.org/show_bug.cgi?id=38138) Bug 40031 - [Regression] testdisplay can't display correctly with 30 bpp (https://bugs.freedesktop.org/show_bug.cgi?id=40031) Bug 42180 - System hang while running gem_linear_blits of Intel-gpu-tools (https://bugs.freedesktop.org/show_bug.cgi?id=42180) Bug 47990 - [PNV]I-G-T/gem_tiled_after_untiled_blt fail (https://bugs.freedesktop.org/show_bug.cgi?id=47990) Bug 48026 - [Regression]I-G-T/gem_linear_blits fail (https://bugs.freedesktop.org/show_bug.cgi?id=48026) Bug 47085 - [ILK]I-G-T/gem_pipe_control_store_loop fail unstablely (https://bugs.freedesktop.org/show_bug.cgi?id=47085) Bug 48028 - [Regression ILK]I-G-T/gem_tiled_blits fail (https://bugs.freedesktop.org/show_bug.cgi?id=48028) Bug 48030 - [Regression ILK]I-G-T /gem_tiled_fence_blits fail (https://bugs.freedesktop.org/show_bug.cgi?id=48030) Bug 42943 - [IVB] Boot with a vga monitor can't light the DP screen while plugin it (https://bugs.freedesktop.org/show_bug.cgi?id=42943) Bug 44305 - [IVB]The Edp can't work while booting with a monitor (https://bugs.freedesktop.org/show_bug.cgi?id=44305) Open bugs: Bug 41976 - [IVB] screen turn to be black while switching between console and x-window with 3-pipe active (https://bugs.freedesktop.org/show_bug.cgi?id=41976) Bug 47990 - [PNV]I-G-T/gem_tiled_after_untiled_blt fail (https://bugs.freedesktop.org/show_bug.cgi?id=47990) Bug 45867 - [IVB 3pipe] 3 Pipe Doesn't Work with Eaglemont Card (https://bugs.freedesktop.org/show_bug.cgi?id=45867) Bug 45870 - [IVB PCH eDP] PCH eDP doesn't work (https://bugs.freedesktop.org/show_bug.cgi?id=45870) so what are the newly submitted/opened problem reports? Thanks, Paul PS: Could you please adapt the subject line next time like [QA] Testing report for `drm-intel-testing` (was: Updated -next) for better overview in the inbox and the archive. ¹ I hope Yi is your first name. I am always confused about that. If it is, no comma goes after it. [1] https://en.wikipedia.org/wiki/Haswell_(microarchitecture) signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: rc6 in sysfs
On Tue, 10 Apr 2012 21:17:01 -0700, Ben Widawsky b...@bwidawsk.net wrote: Merge rc6 information into the power group for our device. Until now the i915 driver has not had any sysfs entries (aside from the connector stuff enabled by drm core). Since it seems like we're likely to have more in the future I created a new file for sysfs stubs, as well as the rc6 sysfs functions which don't really belong elsewhere (perhaps i915_suspend, but most of the stuff is in intel_display,c). displays rc6 modes enabled (as a hex mask): cat /sys/class/drm/card0/power/rc6_enable displays #ms GPU has been in rc6 since boot: cat /sys/class/drm/card0/power/rc6_residency_ms displays #ms GPU has been in deep rc6 since boot: cat /sys/class/drm/card0/power/rc6p_residency_ms displays #ms GPU has been in deepest rc6 since boot: cat /sys/class/drm/card0/power/rc6pp_residency_ms Important note: I've seen on SNB that even when RC6 is *not* enabled the rc6 register seems to have a random value in it. I can only guess at the reason reason for this. Those writing tools that utilize this value need to be careful and probably want to scrutinize the value very carefully. v2: use common rc6 residency units to milliseconds for the other RC6 types v3: don't create sysfs files for GEN = 5 add a rc6_enable to show a mask of enabled rc6 types use unmerge instead of remove for sysfs group squash intel_enable_rc6() extraction into this patch v4: rename sysfs files (Chris) CC: Chris Wilson ch...@chris-wilson.co.uk CC: Daniel Vetter daniel.vet...@ffwll.chf CC: Arjan van de Ven ar...@linux.intel.com Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com So the only downside to using the pre-existing power group is that we do not get the interface if power-management is compiled out of the kernel, which I suppose is appropriate. I'm down to just bikeshedding over useless lines of code which do not even add visual clarity... Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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] Updated -next
Am Mittwoch, den 11.04.2012, 08:24 + schrieb Sun, Yi: […] Thank all your comments. Thank you for your prompt reply and your work on the Intel-gfx driver. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: rc6 in sysfs
On Wed, Apr 11, 2012 at 09:14:43AM +0100, Chris Wilson wrote: On Tue, 10 Apr 2012 21:17:01 -0700, Ben Widawsky b...@bwidawsk.net wrote: Merge rc6 information into the power group for our device. Until now the i915 driver has not had any sysfs entries (aside from the connector stuff enabled by drm core). Since it seems like we're likely to have more in the future I created a new file for sysfs stubs, as well as the rc6 sysfs functions which don't really belong elsewhere (perhaps i915_suspend, but most of the stuff is in intel_display,c). displays rc6 modes enabled (as a hex mask): cat /sys/class/drm/card0/power/rc6_enable displays #ms GPU has been in rc6 since boot: cat /sys/class/drm/card0/power/rc6_residency_ms displays #ms GPU has been in deep rc6 since boot: cat /sys/class/drm/card0/power/rc6p_residency_ms displays #ms GPU has been in deepest rc6 since boot: cat /sys/class/drm/card0/power/rc6pp_residency_ms Important note: I've seen on SNB that even when RC6 is *not* enabled the rc6 register seems to have a random value in it. I can only guess at the reason reason for this. Those writing tools that utilize this value need to be careful and probably want to scrutinize the value very carefully. v2: use common rc6 residency units to milliseconds for the other RC6 types v3: don't create sysfs files for GEN = 5 add a rc6_enable to show a mask of enabled rc6 types use unmerge instead of remove for sysfs group squash intel_enable_rc6() extraction into this patch v4: rename sysfs files (Chris) CC: Chris Wilson ch...@chris-wilson.co.uk CC: Daniel Vetter daniel.vet...@ffwll.chf CC: Arjan van de Ven ar...@linux.intel.com Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com So the only downside to using the pre-existing power group is that we do not get the interface if power-management is compiled out of the kernel, which I suppose is appropriate. I'm down to just bikeshedding over useless lines of code which do not even add visual clarity... Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: make DP configuration vars less confusing in ironlake_crtc_mode_se
On Tue, Apr 10, 2012 at 10:22:09PM +0100, Chris Wilson wrote: On Tue, 10 Apr 2012 11:58:03 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Both PCH and CPU eDP are DP, so set the is_dp flag to true. Add is_cpu_edp and is_pch_edp bools to make checking for each less verbose (rather than has_edp_encoder !intel_encoder_is_pch_edp() sprinkled everywhere). And rename the has_edp_encoder variable to just edp_encoder. With the above variables cleaned up, the rest of the code becomes a bit more readable and clear. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Ok, that took quite a bit of reading to be sure that the changes were consistent. Unfortunately it also looks to be in its simplest form. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. I don't know what to do with the other two patches, are they supposed to be for -fixes? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: simplify ppgtt setup
On Tue, Apr 10, 2012 at 04:33:38PM +0100, Chris Wilson wrote: On Tue, 10 Apr 2012 17:29:17 +0200, daniel.vet...@ffwll.ch wrote: From: Daniel Vetter daniel.vet...@ffwll.ch We don't need the pt_addr for the !dmar case, so drop the else and move the if (dmar) condition out of the loop. v2: Fixup whitespace damage noticed by Chris Wilson. v3: Collapse the two identical if blocks. Chris Wilson makes me look like a moron right now ... Noticed-by: Konstantin Belousov kostik...@gmail.com Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wislon.co.uk Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: re-init modeset hw state after gpu reset
On Tue, Apr 10, 2012 at 03:10:23PM +0100, Chris Wilson wrote: On Tue, 10 Apr 2012 15:50:11 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: After a gpu reset we need to re-init some of the hw state we only initialize when modeset is enabled, like rc6, hw contexts or render/GT core clock gating and workaround register settings. Note that this patch has a small change in the resume code: - rc6 on gen6+ is only restored for the modeset case (for more consistency with other callsites). This is no problem because recent kernels refuse to load drm/i915 without kms on gen6+ - rc6/emon on ilk is only restored for the modeset case. This is no problem because rc6 is disabled by default on ilk, and ums on ilk has never really been a supported option outside of horrible rhel backports. v2: Chris Wilson noticed that we not only fail to restore the clock gating settings after gpu reset. v3: Move the call to modeset_init_hw in _reset out of the struct_mutext protected area - other callers don't hold it, too. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch I don't think it makes the locking any worse than it already is, but it is becoming more and more suspect. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow concurrent read access between CPU and GPU domain
On Tue, Apr 10, 2012 at 10:35:19PM +0100, Chris Wilson wrote: On Tue, 10 Apr 2012 11:52:50 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Similar to allowing a buffer to be simultaneously read by the GPU and through the GTT, we wish to allow readback of the pages through the CPU domain whilst they are also being read by the GPU. Domain coherency is managed by allowing multiple readers, but only a single writer. This is used by mesa for its program cache which it may search for every new program every frame and then renews should it need to add. During renewal, mesa copies the program bo currently executing through a CPU mapping onto the new bo. This patch allows the search and that copy to proceed without causing a stall on the current batch. At Daniel's request, I added i-g-t/gem_cpu_concurrent_blit to catch the possible bugs that may have been introduced by this patch. Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert drm/i915: reenable gmbus on gen3+ again
On Mon, Apr 09, 2012 at 08:31:20PM +0100, Chris Wilson wrote: On Mon, 9 Apr 2012 21:10:38 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: This reverts commit c3dfefa0a6d235bd465309e12f4c56ea16e7. gmbus in 3.4 has simply too many known issues: - gmbus is too noisy, we need to rework the logging: https://bugs.freedesktop.org/show_bug.cgi?id=48248 - zero-lenght writes cause an OOPS, and they are s/lenght/length/ userspace-triggerable: https://lkml.org/lkml/2012/3/30/176 - same for zero-lenght reads: s/lenght/length/ https://bugs.freedesktop.org/show_bug.cgi?id=48269 We can try again for 3.5. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: Chris Wilson ch...@chris-wilson.co.uk I've picked this one for -fixes. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g
On Mon, Apr 09, 2012 at 01:59:46PM +0100, Chris Wilson wrote: The 845g shares the errata with i830 whereby executing a command within 2 cachelines of the end of the ringbuffer may cause a GPU hang. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: sta...@kernel.org Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: implement ColorBlt w/a
On Tue, Apr 10, 2012 at 03:24:13PM -0700, Ben Widawsky wrote: On Sat, Mar 31, 2012 at 11:21:57AM +0200, Daniel Vetter wrote: According to an internal workaround master list, we need to set bit 5 of register 9400 to avoid issues with color blits. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch I'm having a lot of trouble actually tracking this one down in something other than the magical spreadsheet. So I'll for now, this is only Acked-by: Ben Widawsky b...@bwidawsk.net I've picked this up for -fixes, thanks for wrestling through hsd and that ugly xls. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: use semaphores for the display plane
On Thu, 5 Apr 2012 14:47:36 -0700, Ben Widawsky b...@bwidawsk.net wrote:
In theory this will have performance and power improvements. Performance
because we don't need to stall when the scanout BO is busy, and power
because we don't have to stall when the BO is busy (and the ring can
even go to sleep if the HW supports it).
v2:
squash 2 patches into 1 (me)
un-inline the enable_semaphores function (Daniel)
remove comment about SNB hangs from i915_gem_object_sync (Chris)
rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
removed page flip comment; no why (Chris)
To address other comments from Daniel (irc):
update the comment to say 'vt-d is crap, don't enable semaphores'
- I think you misinterpreted Chris' comment, it already exists.
checking out whether we can pageflip on the render ring on ivb (didn't
work on early silicon)
- We don't want to enable workarounds for early silicon unless we have
to.
- I can't find any references in the docs about this.
optionally use it if the fb is already busy on the render ring
- This should be how the code already worked, unless I am
misunderstanding your meaning.
CC: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
+int
+i915_gem_object_sync(struct drm_i915_gem_object *obj,
+ struct intel_ring_buffer *to)
+{
+ struct intel_ring_buffer *from = obj-ring;
+ u32 seqno;
+ int ret, idx;
+
+ if (from == NULL || to == from)
+ return 0;
+
+ if (!i915_semaphore_is_enabled(obj-base.dev))
Bug^ :(
-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] [PATCH v2] drm/i915: use semaphores for the display plane
On Wed, Apr 11, 2012 at 12:53:15PM +0100, Chris Wilson wrote:
On Thu, 5 Apr 2012 14:47:36 -0700, Ben Widawsky b...@bwidawsk.net wrote:
In theory this will have performance and power improvements. Performance
because we don't need to stall when the scanout BO is busy, and power
because we don't have to stall when the BO is busy (and the ring can
even go to sleep if the HW supports it).
v2:
squash 2 patches into 1 (me)
un-inline the enable_semaphores function (Daniel)
remove comment about SNB hangs from i915_gem_object_sync (Chris)
rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
removed page flip comment; no why (Chris)
To address other comments from Daniel (irc):
update the comment to say 'vt-d is crap, don't enable semaphores'
- I think you misinterpreted Chris' comment, it already exists.
checking out whether we can pageflip on the render ring on ivb (didn't
work on early silicon)
- We don't want to enable workarounds for early silicon unless we have
to.
- I can't find any references in the docs about this.
optionally use it if the fb is already busy on the render ring
- This should be how the code already worked, unless I am
misunderstanding your meaning.
CC: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
+int
+i915_gem_object_sync(struct drm_i915_gem_object *obj,
+struct intel_ring_buffer *to)
+{
+ struct intel_ring_buffer *from = obj-ring;
+ u32 seqno;
+ int ret, idx;
+
+ if (from == NULL || to == from)
+ return 0;
+
+ if (!i915_semaphore_is_enabled(obj-base.dev))
Bug^ :(
To elaborate, for to == NULL we need to do a synchronous wait_rendering,
too. This happens for set_base and modeset. Furthermore I've noticed two
other things while reading this function that imo deserve each another
patch:
- we update from-sync_seqno before to-sync_to successfully emits the
sync. That should happen after sync_to (and obviously only if that
succeeds).
- the seqno - 1 semantics of sync_to is annoying me. Imo that kind of
low-level stuff should be handled by the sync_to implementation.
Unfortunately neither the bug noticed by Chris nor the sync_seqno thing
can easily be exercised with i-g-t :(
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: use semaphores for the display plane
On Wed, 11 Apr 2012 14:06:42 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Apr 11, 2012 at 12:53:15PM +0100, Chris Wilson wrote:
On Thu, 5 Apr 2012 14:47:36 -0700, Ben Widawsky b...@bwidawsk.net wrote:
In theory this will have performance and power improvements. Performance
because we don't need to stall when the scanout BO is busy, and power
because we don't have to stall when the BO is busy (and the ring can
even go to sleep if the HW supports it).
v2:
squash 2 patches into 1 (me)
un-inline the enable_semaphores function (Daniel)
remove comment about SNB hangs from i915_gem_object_sync (Chris)
rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
removed page flip comment; no why (Chris)
To address other comments from Daniel (irc):
update the comment to say 'vt-d is crap, don't enable semaphores'
- I think you misinterpreted Chris' comment, it already exists.
checking out whether we can pageflip on the render ring on ivb (didn't
work on early silicon)
- We don't want to enable workarounds for early silicon unless we have
to.
- I can't find any references in the docs about this.
optionally use it if the fb is already busy on the render ring
- This should be how the code already worked, unless I am
misunderstanding your meaning.
CC: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
+int
+i915_gem_object_sync(struct drm_i915_gem_object *obj,
+ struct intel_ring_buffer *to)
+{
+ struct intel_ring_buffer *from = obj-ring;
+ u32 seqno;
+ int ret, idx;
+
+ if (from == NULL || to == from)
+ return 0;
+
+ if (!i915_semaphore_is_enabled(obj-base.dev))
Bug^ :(
To elaborate, for to == NULL we need to do a synchronous wait_rendering,
too. This happens for set_base and modeset. Furthermore I've noticed two
other things while reading this function that imo deserve each another
patch:
if (from == NULL !obj-active) should suffice?
This sounds like a pretty bad hack when it at some point in modesetting
code... who would have thought?
- we update from-sync_seqno before to-sync_to successfully emits the
sync. That should happen after sync_to (and obviously only if that
succeeds).
Probably a remnant of when ring_begin couldn't fail. This deserves to be
fixed, I will do this today if y'all haven't done it already.
- the seqno - 1 semantics of sync_to is annoying me. Imo that kind of
low-level stuff should be handled by the sync_to implementation.
If it ain't broke, don't fix it? I do agree with you, but I'll venture
to guess that I am less annoyed by it.
Unfortunately neither the bug noticed by Chris nor the sync_seqno thing
can easily be exercised with i-g-t :(
Cheers, Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: use semaphores for the display plane
On Wed, 11 Apr 2012 08:46:40 -0700, Ben Widawsky b...@bwidawsk.net wrote:
On Wed, 11 Apr 2012 14:06:42 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Apr 11, 2012 at 12:53:15PM +0100, Chris Wilson wrote:
On Thu, 5 Apr 2012 14:47:36 -0700, Ben Widawsky b...@bwidawsk.net
wrote:
In theory this will have performance and power improvements. Performance
because we don't need to stall when the scanout BO is busy, and power
because we don't have to stall when the BO is busy (and the ring can
even go to sleep if the HW supports it).
v2:
squash 2 patches into 1 (me)
un-inline the enable_semaphores function (Daniel)
remove comment about SNB hangs from i915_gem_object_sync (Chris)
rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
removed page flip comment; no why (Chris)
To address other comments from Daniel (irc):
update the comment to say 'vt-d is crap, don't enable semaphores'
- I think you misinterpreted Chris' comment, it already exists.
checking out whether we can pageflip on the render ring on ivb (didn't
work on early silicon)
- We don't want to enable workarounds for early silicon unless we have
to.
- I can't find any references in the docs about this.
optionally use it if the fb is already busy on the render ring
- This should be how the code already worked, unless I am
misunderstanding your meaning.
CC: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
+int
+i915_gem_object_sync(struct drm_i915_gem_object *obj,
+struct intel_ring_buffer *to)
+{
+ struct intel_ring_buffer *from = obj-ring;
+ u32 seqno;
+ int ret, idx;
+
+ if (from == NULL || to == from)
+ return 0;
+
+ if (!i915_semaphore_is_enabled(obj-base.dev))
Bug^ :(
To elaborate, for to == NULL we need to do a synchronous wait_rendering,
too. This happens for set_base and modeset. Furthermore I've noticed two
other things while reading this function that imo deserve each another
patch:
if (from == NULL !obj-active) should suffice?
if (to == NULL || !i915_sempahores)
return i915_gem_object_wait_rendering(obj);
-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] [PATCH 1/3] drm/i915: make DP configuration vars less confusing in ironlake_crtc_mode_se
On Wed, 11 Apr 2012 11:53:55 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Apr 10, 2012 at 10:22:09PM +0100, Chris Wilson wrote: On Tue, 10 Apr 2012 11:58:03 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Both PCH and CPU eDP are DP, so set the is_dp flag to true. Add is_cpu_edp and is_pch_edp bools to make checking for each less verbose (rather than has_edp_encoder !intel_encoder_is_pch_edp() sprinkled everywhere). And rename the has_edp_encoder variable to just edp_encoder. With the above variables cleaned up, the rest of the code becomes a bit more readable and clear. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Ok, that took quite a bit of reading to be sure that the changes were consistent. Unfortunately it also looks to be in its simplest form. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. I don't know what to do with the other two patches, are they supposed to be for -fixes? I don't think they're urgent enough for -fixes. They're still just fixing issues on my IVB SDV. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: use semaphores for the display plane
On Wed, 11 Apr 2012 16:52:33 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 11 Apr 2012 08:46:40 -0700, Ben Widawsky b...@bwidawsk.net wrote:
On Wed, 11 Apr 2012 14:06:42 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Apr 11, 2012 at 12:53:15PM +0100, Chris Wilson wrote:
On Thu, 5 Apr 2012 14:47:36 -0700, Ben Widawsky b...@bwidawsk.net
wrote:
In theory this will have performance and power improvements.
Performance
because we don't need to stall when the scanout BO is busy, and power
because we don't have to stall when the BO is busy (and the ring can
even go to sleep if the HW supports it).
v2:
squash 2 patches into 1 (me)
un-inline the enable_semaphores function (Daniel)
remove comment about SNB hangs from i915_gem_object_sync (Chris)
rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
removed page flip comment; no why (Chris)
To address other comments from Daniel (irc):
update the comment to say 'vt-d is crap, don't enable semaphores'
- I think you misinterpreted Chris' comment, it already exists.
checking out whether we can pageflip on the render ring on ivb (didn't
work on early silicon)
- We don't want to enable workarounds for early silicon unless we
have
to.
- I can't find any references in the docs about this.
optionally use it if the fb is already busy on the render ring
- This should be how the code already worked, unless I am
misunderstanding your meaning.
CC: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
+int
+i915_gem_object_sync(struct drm_i915_gem_object *obj,
+ struct intel_ring_buffer *to)
+{
+ struct intel_ring_buffer *from = obj-ring;
+ u32 seqno;
+ int ret, idx;
+
+ if (from == NULL || to == from)
+ return 0;
+
+ if (!i915_semaphore_is_enabled(obj-base.dev))
Bug^ :(
To elaborate, for to == NULL we need to do a synchronous wait_rendering,
too. This happens for set_base and modeset. Furthermore I've noticed two
other things while reading this function that imo deserve each another
patch:
if (from == NULL !obj-active) should suffice?
if (to == NULL || !i915_sempahores)
return i915_gem_object_wait_rendering(obj);
-Chris
Ha, I misread it... I thought from-ring could be NULL, and we needed to
wait for rendering. So wait, in this case, to and from are both NULL?
Doesn't that mean both objects are already setup for use by display? A
bad assumption, but I think it would technically work as the code is,
today.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: check PPS regs for sanity when using eDP
On Tue, Apr 10, 2012 at 10:26:56PM +0100, Chris Wilson wrote: On Tue, 10 Apr 2012 11:58:04 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: If these regs don't have valid values, the panel won't come up, and may even cause a system hang. So do a basic sanity check when an eDP panel is detected. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Other than adding a cleanup: error path (definitely before the third person cut'n'pastes the intel_dp*destroy()), and that checking for zero seems a little crude, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: allow PCH PWM override on IVB
On IVB, there are two sets of panel backlight regs: one in the CPU and
one in the PCH. The CPU ones aren't generally used, so on IVB make sure
we allow the PCH regs to actually control the backlight.
v2: remove unused pwm variable (Daniel)
move to init_hw function so we override on resume too
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 58f4b02..33aaad3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9530,6 +9530,19 @@ static void i915_disable_vga(struct drm_device *dev)
POSTING_READ(vga_reg);
}
+static void ivb_pch_pwm_override(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ /*
+* IVB has CPU eDP backlight regs too, set things up to let the
+* PCH regs control the backlight
+*/
+ I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE);
+ I915_WRITE(BLC_PWM_CPU_CTL, 0);
+ I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (130));
+}
+
void intel_modeset_init_hw(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -9545,6 +9558,9 @@ void intel_modeset_init_hw(struct drm_device *dev)
gen6_enable_rps(dev_priv);
gen6_update_ring_freq(dev_priv);
}
+
+ if (IS_IVYBRIDGE(dev))
+ ivb_pch_pwm_override(dev);
}
void intel_modeset_init(struct drm_device *dev)
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: IBX+ doesn't have separate vsync/hsync controls on the VGA DAC
When the PCH split occurred, we dropped support for separate hsync and
vsync disable in the VGA DAC. So add a PCH specific DPMS function that
just uses the port enable bit for controlling DPMS states.
Before this fix, when anything other than a full DPMS off occurred,
the VGA port would be left enabled and scanning out while all the other
heads would turn off as expected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_crt.c | 42 -
1 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 70b0f1a..bdaefff 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -55,18 +55,36 @@ static struct intel_crt *intel_attached_crt(struct
drm_connector *connector)
struct intel_crt, base);
}
-static void intel_crt_dpms(struct drm_encoder *encoder, int mode)
+static void pch_crt_dpms(struct drm_encoder *encoder, int mode)
{
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 temp, reg;
+ u32 temp;
- if (HAS_PCH_SPLIT(dev))
- reg = PCH_ADPA;
- else
- reg = ADPA;
+ temp = I915_READ(PCH_ADPA);
+ temp = ~ADPA_DAC_ENABLE;
+
+ switch (mode) {
+ case DRM_MODE_DPMS_ON:
+ temp |= ADPA_DAC_ENABLE;
+ break;
+ case DRM_MODE_DPMS_STANDBY:
+ case DRM_MODE_DPMS_SUSPEND:
+ case DRM_MODE_DPMS_OFF:
+ /* Just leave port enable cleared */
+ break;
+ }
+
+ I915_WRITE(PCH_ADPA, temp);
+}
+
+static void intel_crt_dpms(struct drm_encoder *encoder, int mode)
+{
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 temp;
- temp = I915_READ(reg);
+ temp = I915_READ(ADPA);
temp = ~(ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE);
temp = ~ADPA_DAC_ENABLE;
@@ -85,7 +103,7 @@ static void intel_crt_dpms(struct drm_encoder *encoder, int
mode)
break;
}
- I915_WRITE(reg, temp);
+ I915_WRITE(ADPA, temp);
}
static int intel_crt_mode_valid(struct drm_connector *connector,
@@ -516,8 +534,7 @@ static void intel_crt_reset(struct drm_connector *connector)
* Routines for controlling stuff on the analog port
*/
-static const struct drm_encoder_helper_funcs intel_crt_helper_funcs = {
- .dpms = intel_crt_dpms,
+static struct drm_encoder_helper_funcs intel_crt_helper_funcs = {
.mode_fixup = intel_crt_mode_fixup,
.prepare = intel_encoder_prepare,
.commit = intel_encoder_commit,
@@ -602,6 +619,11 @@ void intel_crt_init(struct drm_device *dev)
connector-interlace_allowed = 1;
connector-doublescan_allowed = 0;
+ if (HAS_PCH_SPLIT(dev))
+ intel_crt_helper_funcs.dpms = pch_crt_dpms;
+ else
+ intel_crt_helper_funcs.dpms = intel_crt_dpms;
+
drm_encoder_helper_add(crt-base.base, intel_crt_helper_funcs);
drm_connector_helper_add(connector, intel_crt_connector_helper_funcs);
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: disable turbo on ValleyView for now
We'll probably need new init functions and will need to test it.
v2: fix impossible GEN6 GEN7 condition, move to Daniel's new init function
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index aee389c..58f4b02 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9541,7 +9541,7 @@ void intel_modeset_init_hw(struct drm_device *dev)
intel_init_emon(dev);
}
- if (IS_GEN6(dev) || IS_GEN7(dev)) {
+ if ((IS_GEN6(dev) || IS_GEN7(dev)) !IS_VALLEYVIEW(dev)) {
gen6_enable_rps(dev_priv);
gen6_update_ring_freq(dev_priv);
}
@@ -9632,7 +9632,7 @@ void intel_modeset_cleanup(struct drm_device *dev)
if (IS_IRONLAKE_M(dev))
ironlake_disable_drps(dev);
- if (IS_GEN6(dev) || IS_GEN7(dev))
+ if ((IS_GEN6(dev) || IS_GEN7(dev)) !IS_VALLEYVIEW(dev))
gen6_disable_rps(dev);
if (IS_IRONLAKE_M(dev))
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: force CPU eDP onto pipe 3 on IVB
This is a hack to make sure CPU eDP mode sets avoid allocating a PCH PLL.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |2 ++
drivers/gpu/drm/i915/intel_dp.c |4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 33aaad3..0b5f843 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6225,6 +6225,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
fp == I915_READ(PCH_FP0(1))) {
intel_crtc-use_pll_a = false;
DRM_DEBUG_KMS(using pipe b dpll\n);
+ } else if (is_cpu_edp) {
+ DRM_DEBUG_KMS(CPU eDP, no PCH PLL needed\n);
} else {
DRM_DEBUG_KMS(no matching PLL configuration for pipe
2\n);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6346b29..89b326f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2417,6 +2417,10 @@ intel_dp_init(struct drm_device *dev, int output_reg)
}
intel_encoder-crtc_mask = (1 0) | (1 1) | (1 2);
+
+ if (IS_IVYBRIDGE(dev) output_reg == DP_A)
+ intel_encoder-crtc_mask = (1 2);
+
connector-interlace_allowed = true;
connector-doublescan_allowed = 0;
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make rc6 module parameter read-only
People have been getting confused and thinking this is a runtime control. Cc: sta...@vger.kernel.org Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index ccfdc81..3effcf7 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -64,7 +64,7 @@ MODULE_PARM_DESC(semaphores, Use semaphores for inter-ring sync (default: -1 (use per-chip defaults))); int i915_enable_rc6 __read_mostly = -1; -module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600); +module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0400); MODULE_PARM_DESC(i915_enable_rc6, Enable power-saving render C-state 6. Different stages can be selected via bitmask values -- 1.7.4.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: force CPU eDP onto pipe 3 on IVB
On Wed, 11 Apr 2012 09:23:36 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: This is a hack to make sure CPU eDP mode sets avoid allocating a PCH PLL. Ignore this one, it's too ugly to live. I'll put something better together now... -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make rc6 module parameter read-only
On Wed, 11 Apr 2012 09:39:02 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: People have been getting confused and thinking this is a runtime control. Cc: sta...@vger.kernel.org Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org But with Danvet's new reset code, you could echo 1 /sys/modules/i915/parameters/i915_enable_rc6 echo 1 /sys/kernel/debug/dri/0/i915_wedged cat /sys/kernel/debug/dri/0/i915_drpc_info That's probably not quite what you meant though. :) -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
[Intel-gfx] [PATCH 1/3] drm/i915: i915_gem_object_sync must handle NULL
When I extracted the synchronization code for implementing semaphorified pageflips (74f5f6e0), I neglected the non pipelined case which also calls this code. The modesetting code wants to make sure the object has finished rendering to the frame before configuring the scanout (ie. non-pipelined case). As a result of a follow on discussion on IRC, I've decided to add a comment about the function itself which received much inspiration from Chris as well. So really, this patch was ghost-written by Chris :). Reported-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com --- drivers/gpu/drm/i915/i915_gem.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 1bfb0d2..9fcdc9a 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1953,6 +1953,18 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj) return 0; } +/** + * i915_gem_object_sync - sync an object to a ring. + * + * @obj: object which may be in use on another ring. + * @to: ring we wish to use the object on. May be NULL. + * + * This code is meant to abstract object synchronization with the GPU. + * Calling with NULL implies synchronizing the object with the CPU + * rather than a particular GPU ring. + * + * Returns 0 if successful, else propagates up the lower layer error. + */ int i915_gem_object_sync(struct drm_i915_gem_object *obj, struct intel_ring_buffer *to) @@ -1964,7 +1976,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj, if (from == NULL || to == from) return 0; - if (!i915_semaphore_is_enabled(obj-base.dev)) + if (to == NULL || !i915_semaphore_is_enabled(obj-base.dev)) return i915_gem_object_wait_rendering(obj); idx = intel_ring_sync_index(from, to); -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: fix for when semaphore updates fail
This fixes a long standing issue where emitting the semaphore updates may have failed, but we've already updated our internal data structure. Reported-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com --- drivers/gpu/drm/i915/i915_gem.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 9fcdc9a..0115b12 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2001,10 +2001,12 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj, seqno = request-seqno; } - from-sync_seqno[idx] = seqno; - return to-sync_to(to, from, seqno - 1); + ret = to-sync_to(to, from, seqno - 1); + if (!ret) + from-sync_seqno[idx] = seqno; + return ret; } static void i915_gem_object_finish_gtt(struct drm_i915_gem_object *obj) -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: hide (seqno-1) in ringbuffer code
Waiting for seqno-1 in our object synchronization code is an implementation detail given how we've decided to do the waits within the rest of our code. Requested-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com --- drivers/gpu/drm/i915/i915_gem.c |2 +- drivers/gpu/drm/i915/intel_ringbuffer.c |6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 0115b12..71934dd 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2002,7 +2002,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj, } - ret = to-sync_to(to, from, seqno - 1); + ret = to-sync_to(to, from, seqno); if (!ret) from-sync_seqno[idx] = seqno; diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index dfdb613..467b331 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -482,6 +482,12 @@ intel_ring_sync(struct intel_ring_buffer *waiter, MI_SEMAPHORE_COMPARE | MI_SEMAPHORE_REGISTER; + /* Throughout all of the GEM code, seqno passed implies our current +* seqno is = the last seqno executed. However for hardware the +* comparison is strictly greater than. +*/ + seqno -= 1; + ret = intel_ring_begin(waiter, 4); if (ret) return ret; -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: IBX+ doesn't have separate vsync/hsync controls on the VGA DAC
On Wed, Apr 11, 2012 at 09:23:34AM -0700, Jesse Barnes wrote:
When the PCH split occurred, we dropped support for separate hsync and
vsync disable in the VGA DAC. So add a PCH specific DPMS function that
just uses the port enable bit for controlling DPMS states.
Before this fix, when anything other than a full DPMS off occurred,
the VGA port would be left enabled and scanning out while all the other
heads would turn off as expected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_crt.c | 42 -
1 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c
b/drivers/gpu/drm/i915/intel_crt.c
index 70b0f1a..bdaefff 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -55,18 +55,36 @@ static struct intel_crt *intel_attached_crt(struct
drm_connector *connector)
struct intel_crt, base);
}
-static void intel_crt_dpms(struct drm_encoder *encoder, int mode)
+static void pch_crt_dpms(struct drm_encoder *encoder, int mode)
{
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 temp, reg;
+ u32 temp;
- if (HAS_PCH_SPLIT(dev))
- reg = PCH_ADPA;
- else
- reg = ADPA;
+ temp = I915_READ(PCH_ADPA);
+ temp = ~ADPA_DAC_ENABLE;
+
+ switch (mode) {
+ case DRM_MODE_DPMS_ON:
+ temp |= ADPA_DAC_ENABLE;
+ break;
+ case DRM_MODE_DPMS_STANDBY:
+ case DRM_MODE_DPMS_SUSPEND:
+ case DRM_MODE_DPMS_OFF:
+ /* Just leave port enable cleared */
+ break;
+ }
+
+ I915_WRITE(PCH_ADPA, temp);
+}
+
+static void intel_crt_dpms(struct drm_encoder *encoder, int mode)
+{
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 temp;
- temp = I915_READ(reg);
+ temp = I915_READ(ADPA);
temp = ~(ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE);
temp = ~ADPA_DAC_ENABLE;
@@ -85,7 +103,7 @@ static void intel_crt_dpms(struct drm_encoder *encoder,
int mode)
break;
}
- I915_WRITE(reg, temp);
+ I915_WRITE(ADPA, temp);
}
static int intel_crt_mode_valid(struct drm_connector *connector,
@@ -516,8 +534,7 @@ static void intel_crt_reset(struct drm_connector
*connector)
* Routines for controlling stuff on the analog port
*/
-static const struct drm_encoder_helper_funcs intel_crt_helper_funcs = {
- .dpms = intel_crt_dpms,
+static struct drm_encoder_helper_funcs intel_crt_helper_funcs = {
.mode_fixup = intel_crt_mode_fixup,
.prepare = intel_encoder_prepare,
.commit = intel_encoder_commit,
@@ -602,6 +619,11 @@ void intel_crt_init(struct drm_device *dev)
connector-interlace_allowed = 1;
connector-doublescan_allowed = 0;
+ if (HAS_PCH_SPLIT(dev))
+ intel_crt_helper_funcs.dpms = pch_crt_dpms;
+ else
+ intel_crt_helper_funcs.dpms = intel_crt_dpms;
I like the clean split of this, but the static struct frobbing really
itches me. Can you either split up intel_crt_helper_funcs into a gmch and
pch_split version or add a dpms function pointer to struct intel_crt?
Patch 13 of this series are queued for -next, thanks.
-Daniel
+
drm_encoder_helper_add(crt-base.base, intel_crt_helper_funcs);
drm_connector_helper_add(connector, intel_crt_connector_helper_funcs);
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: manage PCH PLLs separately from pipes
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.
So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=44309
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_display.c | 185 +-
drivers/gpu/drm/i915/intel_dp.c |1 +
drivers/gpu/drm/i915/intel_drv.h |9 ++-
4 files changed, 126 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 422f424..c913b20 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -754,6 +754,8 @@ typedef struct drm_i915_private {
wait_queue_head_t pending_flip_queue;
bool flip_pending_is_done;
+ struct intel_pch_pll *pch_plls;
+
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 33aaad3..90562c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -913,11 +913,19 @@ static void assert_pll(struct drm_i915_private *dev_priv,
/* For ILK+ */
static void assert_pch_pll(struct drm_i915_private *dev_priv,
- enum pipe pipe, bool state)
+ struct intel_crtc *intel_crtc, bool state)
{
int reg;
u32 val;
bool cur_state;
+ int pll;
+
+ if (!intel_crtc-pch_pll) {
+ WARN(1, asserting PCH PLL enabled with no PLL\n);
+ return;
+ }
+
+ pll = intel_crtc-pch_pll-pll;
if (HAS_PCH_CPT(dev_priv-dev)) {
u32 pch_dpll;
@@ -925,14 +933,11 @@ static void assert_pch_pll(struct drm_i915_private
*dev_priv,
pch_dpll = I915_READ(PCH_DPLL_SEL);
/* Make sure the selected PLL is enabled to the transcoder */
- WARN(!((pch_dpll (4 * pipe)) 8),
-transcoder %d PLL not enabled\n, pipe);
-
- /* Convert the transcoder pipe number to a pll pipe number */
- pipe = (pch_dpll (4 * pipe)) 1;
+ WARN(!((pch_dpll (4 * intel_crtc-pipe)) 8),
+transcoder %d PLL not enabled\n, intel_crtc-pipe);
}
- reg = PCH_DPLL(pipe);
+ reg = PCH_DPLL(pll);
val = I915_READ(reg);
cur_state = !!(val DPLL_VCO_ENABLE);
WARN(cur_state != state,
@@ -1308,22 +1313,19 @@ static void intel_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
* The PCH PLL needs to be enabled before the PCH transcoder, since it
* drives the transcoder clock.
*/
-static void intel_enable_pch_pll(struct drm_i915_private *dev_priv,
-enum pipe pipe)
+static void intel_enable_pch_pll(struct intel_crtc *intel_crtc)
{
+ struct drm_i915_private *dev_priv = intel_crtc-base.dev-dev_private;
int reg;
u32 val;
- if (pipe 1)
- return;
-
/* PCH only available on ILK+ */
BUG_ON(dev_priv-info-gen 5);
/* PCH refclock must be enabled first */
assert_pch_refclk_enabled(dev_priv);
- reg = PCH_DPLL(pipe);
+ reg = PCH_DPLL(intel_crtc-pch_pll-pll);
val = I915_READ(reg);
val |= DPLL_VCO_ENABLE;
I915_WRITE(reg, val);
@@ -1331,32 +1333,19 @@ static void intel_enable_pch_pll(struct
drm_i915_private *dev_priv,
udelay(200);
}
-static void intel_disable_pch_pll(struct drm_i915_private *dev_priv,
- enum pipe pipe)
+static void intel_disable_pch_pll(struct intel_crtc *intel_crtc)
{
+ struct drm_i915_private *dev_priv = intel_crtc-base.dev-dev_private;
int reg;
- u32 val, pll_mask = TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL,
- pll_sel = TRANSC_DPLL_ENABLE;
-
- if (pipe 1)
- return;
+ u32 val;
/* PCH only available on ILK+ */
BUG_ON(dev_priv-info-gen 5);
/* Make sure transcoder isn't still depending on us */
- assert_transcoder_disabled(dev_priv, pipe);
+ assert_transcoder_disabled(dev_priv, intel_crtc-pipe);
- if (pipe == 0)
- pll_sel |= TRANSC_DPLLA_SEL;
- else if (pipe == 1)
- pll_sel |= TRANSC_DPLLB_SEL;
-
-
- if ((I915_READ(PCH_DPLL_SEL) pll_mask) == pll_sel)
- return;
-
- reg = PCH_DPLL(pipe);
+ reg = PCH_DPLL(intel_crtc-pch_pll-pll);
val = I915_READ(reg);
val = ~DPLL_VCO_ENABLE;
I915_WRITE(reg, val);
@@ -1375,7 +1364,7 @@ static void intel_enable_transcoder(struct
drm_i915_private *dev_priv,
BUG_ON(dev_priv-info-gen 5);
Re: [Intel-gfx] [PATCH 1/3] drm/i915: i915_gem_object_sync must handle NULL
On Wed, 11 Apr 2012 11:18:19 -0700, Ben Widawsky b...@bwidawsk.net wrote: When I extracted the synchronization code for implementing semaphorified pageflips (74f5f6e0), I neglected the non pipelined case which also calls this code. The modesetting code wants to make sure the object has finished rendering to the frame before configuring the scanout (ie. non-pipelined case). As a result of a follow on discussion on IRC, I've decided to add a comment about the function itself which received much inspiration from Chris as well. So really, this patch was ghost-written by Chris :). Reported-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Tested-by: Chris Wilson ch...@chris-wilson.co.uk -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] [PATCH 2/3] drm/i915: fix for when semaphore updates fail
On Wed, 11 Apr 2012 11:18:20 -0700, Ben Widawsky b...@bwidawsk.net wrote: This fixes a long standing issue where emitting the semaphore updates may have failed, but we've already updated our internal data structure. Reported-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com I would have written it as ret == 0, but since I didn't write this, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Fortunately the impact of the bug would have been render corruption and not a GPU hang. -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] [PATCH 3/3] drm/i915: hide (seqno-1) in ringbuffer code
On Wed, 11 Apr 2012 11:18:21 -0700, Ben Widawsky b...@bwidawsk.net wrote: Waiting for seqno-1 in our object synchronization code is an implementation detail given how we've decided to do the waits within the rest of our code. Requested-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com Thanks for the comment, I had forgotten about that hw detail. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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] [PATCH 1/3] drm/i915: i915_gem_object_sync must handle NULL
On Wed, Apr 11, 2012 at 07:41:04PM +0100, Chris Wilson wrote: On Wed, 11 Apr 2012 11:18:19 -0700, Ben Widawsky b...@bwidawsk.net wrote: When I extracted the synchronization code for implementing semaphorified pageflips (74f5f6e0), I neglected the non pipelined case which also calls this code. The modesetting code wants to make sure the object has finished rendering to the frame before configuring the scanout (ie. non-pipelined case). As a result of a follow on discussion on IRC, I've decided to add a comment about the function itself which received much inspiration from Chris as well. So really, this patch was ghost-written by Chris :). Reported-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Tested-by: Chris Wilson ch...@chris-wilson.co.uk I've picked up all 3 patches for -next, thanks for them. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make rc6 module parameter read-only
On Wed, Apr 11, 2012 at 09:39:02AM -0700, Jesse Barnes wrote: People have been getting confused and thinking this is a runtime control. Cc: sta...@vger.kernel.org Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: implement a media hang w/a
Contrary to the other clock gating w/a in GEN6_UCGCTL1, this one is actually documented in Bspec, vol1g GT Interface Registers [SNB], Section 1.5.1 UCGCTL1 - Unit Level Clock Gating Control 1. Supposedly this can prevent hangs on the media ring. Reviewed-by: Ben Widawsky b...@bwidawsk.net Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_display.c |3 ++- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b4bb1ef..3689812 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3730,6 +3730,7 @@ #define GEN6_UCGCTL1 0x9400 # define GEN6_BLBUNIT_CLOCK_GATE_DISABLE (1 5) +# define GEN6_CSUNIT_CLOCK_GATE_DISABLE(1 7) #define GEN6_UCGCTL2 0x9404 # define GEN6_RCZUNIT_CLOCK_GATE_DISABLE (1 13) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bae38ac..b98c933 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8558,7 +8558,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | - GEN6_BLBUNIT_CLOCK_GATE_DISABLE); + GEN6_BLBUNIT_CLOCK_GATE_DISABLE | + GEN6_CSUNIT_CLOCK_GATE_DISABLE); /* According to the BSpec vol1g, bit 12 (RCPBUNIT) clock * gating disable must be set. Failure to set it results in -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: set w/a bit for snb pagefaults
Bspec says that we need to set this: vol1c.3 Blitter Command
Streamer, Section 1.1.2.1 GAB_CTL_REG - GAB Unit Control Register.
We don't really rely on pagefaults, but who knows what this all
affects.
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c |7 ++-
drivers/gpu/drm/i915/i915_reg.h |3 +++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4c65c63..5e0d7d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3787,7 +3787,12 @@ void i915_gem_init_ppgtt(struct drm_device *dev)
pd_offset = 16;
if (INTEL_INFO(dev)-gen == 6) {
- uint32_t ecochk = I915_READ(GAM_ECOCHK);
+ uint32_t ecochk, gab_ctl;
+
+ gab_ctl = I915_READ(GAB_CTL);
+ I915_WRITE(GAB_CTL, gab_ctl | GAB_CTL_CONT_AFTER_PAGEFAULT);
+
+ ecochk = I915_READ(GAM_ECOCHK);
I915_WRITE(GAM_ECOCHK, ecochk | ECOCHK_SNB_BIT |
ECOCHK_PPGTT_CACHE64B);
I915_WRITE(GFX_MODE, GFX_MODE_ENABLE(GFX_PPGTT_ENABLE));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3689812..9aeee7a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -125,6 +125,9 @@
#define ECOCHK_PPGTT_CACHE64B(0x33)
#define ECOCHK_PPGTT_CACHE4B (0x03)
+#define GAB_CTL0x24000
+#define GAB_CTL_CONT_AFTER_PAGEFAULT (18)
+
/* VGA stuff */
#define VGA_ST01_MDA 0x3ba
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: properly set ppgtt cacheability on snb
For some reason snb has 2 fields to set ppgtt cacheability. This one
here does not exist on gen7.
This might explain why ppgtt wasn't a win on snb like on ivb - not
enough pte caching.
v2: Fixup rebase fail.
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c |5 -
drivers/gpu/drm/i915/i915_reg.h |4
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5e0d7d4..dc2478c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3787,7 +3787,10 @@ void i915_gem_init_ppgtt(struct drm_device *dev)
pd_offset = 16;
if (INTEL_INFO(dev)-gen == 6) {
- uint32_t ecochk, gab_ctl;
+ uint32_t ecochk, gab_ctl, ecobits;
+
+ ecobits = I915_READ(GAC_ECO_BITS);
+ I915_WRITE(GAC_ECO_BITS, ecobits | ECOBITS_PPGTT_CACHE64B);
gab_ctl = I915_READ(GAB_CTL);
I915_WRITE(GAB_CTL, gab_ctl | GAB_CTL_CONT_AFTER_PAGEFAULT);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9aeee7a..78171f7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -125,6 +125,10 @@
#define ECOCHK_PPGTT_CACHE64B(0x33)
#define ECOCHK_PPGTT_CACHE4B (0x03)
+#define GAC_ECO_BITS 0x14090
+#define ECOBITS_PPGTT_CACHE64B (38)
+#define ECOBITS_PPGTT_CACHE4B(08)
+
#define GAB_CTL0x24000
#define GAB_CTL_CONT_AFTER_PAGEFAULT (18)
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: implement w/a for incorrect guarband clipping
According to Bsepc, this should be set by default, but isn't. See vo1c.4 Render Engine Command Streamer, Section 1.1.14.3 3D_CHICKEN3 Bspec also says that we always need to set all mask bits. v2: Add comment about the mask bits wtf. Reviewed-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_display.c |4 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 78171f7..cd2d2c7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -439,6 +439,7 @@ */ # define _3D_CHICKEN2_WM_READ_PIPELINED(1 14) #define _3D_CHICKEN3 0x02090 +#define _3D_CHICKEN_SF_DISABLE_FASTCLIP_CULL (1 5) #define MI_MODE0x0209c # define VS_TIMER_DISPATCH (1 6) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b98c933..083c741 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8575,6 +8575,10 @@ static void gen6_init_clock_gating(struct drm_device *dev) GEN6_RCPBUNIT_CLOCK_GATE_DISABLE | GEN6_RCCUNIT_CLOCK_GATE_DISABLE); + /* Bspec says we need to always set all mask bits. */ + I915_WRITE(_3D_CHICKEN, (0x 16) | + _3D_CHICKEN_SF_DISABLE_FASTCLIP_CULL); + /* * According to the spec the following bits should be * set in order to enable memory self-refresh and fbc: -- 1.7.7.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/14] intel_ringbuffer.c reorg + cleanups
Hi all, This patch series is inspired by Ben's ring-get|put_irq cleanup for gen6+ and my perpetual hatred for intel_ringbuffer.c. It's a lot of churn, but the end result is imho worth it - I almost started to like what the ringbuffer abstraction looks like now. There are some follow-up cleanups possible, but I think that can wait until we've cleanup up our domain tracking and ripped out the flushing_list (if that ever happens). Commments, flames and review highly welcome. Yours, Daniel Daniel Vetter (14): drm/i915: rip out ring-irq_mask drm/i915: set ring-size in common ring setup code drm/i915: dynamically set up the render ring functions and params drm/i915: dynamically set up bsd ring functions and params drm/i915: dynamically set up blt ring functions and parameters drm/i915: don't set up rings on gen6+ for non-kms drm/i915: consolidate ring-sync-to functions drm/i915: abstract away ring-specific irq_get/put drm/i915: split out the gen5 ring irq get/put functions drm/i915: don't enable the gen6 bsd ring tail write enable on gen7 drm/i915: split up ring-dispatch_execbuffer functions drm/i915: consolidate ring-flush a bit drm/i915: don't set up gem ring functions on gen5 for !kms drm/i915: inline enable/disable_irq into ring-get/put_irq drivers/gpu/drm/i915/intel_ringbuffer.c | 466 +-- drivers/gpu/drm/i915/intel_ringbuffer.h |3 +- 2 files changed, 196 insertions(+), 273 deletions(-) -- 1.7.7.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/14] drm/i915: rip out ring-irq_mask
We only ever enable/disable one interrupt (namely user_interrupts and
pipe_notify), so we don't need to track the interrupt masking state.
Also rename irq_enable to irq_enable_mask, now that it won't collide -
beforehand both a irq_mask and irq_enable_mask would have looked a bit
strange.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 21 -
drivers/gpu/drm/i915/intel_ringbuffer.h |3 +--
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index dfdb613..54595cd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -792,7 +792,6 @@ gen6_ring_get_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
- u32 mask = ring-irq_enable;
if (!dev-irq_enabled)
return false;
@@ -804,9 +803,8 @@ gen6_ring_get_irq(struct intel_ring_buffer *ring)
spin_lock(ring-irq_lock);
if (ring-irq_refcount++ == 0) {
- ring-irq_mask = ~mask;
- I915_WRITE_IMR(ring, ring-irq_mask);
- ironlake_enable_irq(dev_priv, mask);
+ I915_WRITE_IMR(ring, ~ring-irq_enable_mask);
+ ironlake_enable_irq(dev_priv, ring-irq_enable_mask);
}
spin_unlock(ring-irq_lock);
@@ -818,13 +816,11 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
- u32 mask = ring-irq_enable;
spin_lock(ring-irq_lock);
if (--ring-irq_refcount == 0) {
- ring-irq_mask |= mask;
- I915_WRITE_IMR(ring, ring-irq_mask);
- ironlake_disable_irq(dev_priv, mask);
+ I915_WRITE_IMR(ring, ~0);
+ ironlake_disable_irq(dev_priv, ring-irq_enable_mask);
}
spin_unlock(ring-irq_lock);
@@ -996,7 +992,6 @@ int intel_init_ring_buffer(struct drm_device *dev,
init_waitqueue_head(ring-irq_queue);
spin_lock_init(ring-irq_lock);
- ring-irq_mask = ~0;
if (I915_NEED_GFX_HWS(dev)) {
ret = init_status_page(ring);
@@ -1374,7 +1369,7 @@ static const struct intel_ring_buffer gen6_bsd_ring = {
.flush = gen6_ring_flush,
.add_request= gen6_add_request,
.get_seqno = gen6_ring_get_seqno,
- .irq_enable = GEN6_BSD_USER_INTERRUPT,
+ .irq_enable_mask= GEN6_BSD_USER_INTERRUPT,
.irq_get= gen6_ring_get_irq,
.irq_put= gen6_ring_put_irq,
.dispatch_execbuffer= gen6_ring_dispatch_execbuffer,
@@ -1420,7 +1415,7 @@ static const struct intel_ring_buffer gen6_blt_ring = {
.get_seqno = gen6_ring_get_seqno,
.irq_get= gen6_ring_get_irq,
.irq_put= gen6_ring_put_irq,
- .irq_enable = GEN6_BLITTER_USER_INTERRUPT,
+ .irq_enable_mask= GEN6_BLITTER_USER_INTERRUPT,
.dispatch_execbuffer= gen6_ring_dispatch_execbuffer,
.sync_to= gen6_blt_ring_sync_to,
.semaphore_register = {MI_SEMAPHORE_SYNC_BR,
@@ -1440,7 +1435,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring-flush = gen6_render_ring_flush;
ring-irq_get = gen6_ring_get_irq;
ring-irq_put = gen6_ring_put_irq;
- ring-irq_enable = GT_USER_INTERRUPT;
+ ring-irq_enable_mask = GT_USER_INTERRUPT;
ring-get_seqno = gen6_ring_get_seqno;
} else if (IS_GEN5(dev)) {
ring-add_request = pc_render_add_request;
@@ -1465,7 +1460,7 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
ring-add_request = gen6_add_request;
ring-irq_get = gen6_ring_get_irq;
ring-irq_put = gen6_ring_put_irq;
- ring-irq_enable = GT_USER_INTERRUPT;
+ ring-irq_enable_mask = GT_USER_INTERRUPT;
} else if (IS_GEN5(dev)) {
ring-add_request = pc_render_add_request;
ring-get_seqno = pc_render_get_seqno;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3488a5a..06a66ad 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -58,8 +58,7 @@ struct intel_ring_buffer {
spinlock_t irq_lock;
u32 irq_refcount;
- u32 irq_mask;
- u32 irq_enable; /* IRQs enabled for this ring */
+ u32 irq_enable_mask;/* bitmask to enable ring
interrupt */
u32 irq_seqno;
[Intel-gfx] [PATCH 02/14] drm/i915: set ring-size in common ring setup code
Eventually we want to scale the ring size depending upon available
gtt space. For now just consolidate this instead of replicating it
over all ringbuffer templates.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 54595cd..8131c40 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -989,6 +989,7 @@ int intel_init_ring_buffer(struct drm_device *dev,
INIT_LIST_HEAD(ring-active_list);
INIT_LIST_HEAD(ring-request_list);
INIT_LIST_HEAD(ring-gpu_write_list);
+ ring-size = 32 * PAGE_SIZE;
init_waitqueue_head(ring-irq_queue);
spin_lock_init(ring-irq_lock);
@@ -1262,7 +1263,6 @@ static const struct intel_ring_buffer render_ring = {
.name = render ring,
.id = RCS,
.mmio_base = RENDER_RING_BASE,
- .size = 32 * PAGE_SIZE,
.init = init_render_ring,
.write_tail = ring_write_tail,
.flush = render_ring_flush,
@@ -1285,7 +1285,6 @@ static const struct intel_ring_buffer bsd_ring = {
.name = bsd ring,
.id = VCS,
.mmio_base = BSD_RING_BASE,
- .size = 32 * PAGE_SIZE,
.init = init_ring_common,
.write_tail = ring_write_tail,
.flush = bsd_ring_flush,
@@ -1363,7 +1362,6 @@ static const struct intel_ring_buffer gen6_bsd_ring = {
.name = gen6 bsd ring,
.id = VCS,
.mmio_base = GEN6_BSD_RING_BASE,
- .size = 32 * PAGE_SIZE,
.init = init_ring_common,
.write_tail = gen6_bsd_ring_write_tail,
.flush = gen6_ring_flush,
@@ -1407,7 +1405,6 @@ static const struct intel_ring_buffer gen6_blt_ring = {
.name = blt ring,
.id = BCS,
.mmio_base = BLT_RING_BASE,
- .size = 32 * PAGE_SIZE,
.init = init_ring_common,
.write_tail = ring_write_tail,
.flush = blt_ring_flush,
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/14] drm/i915: dynamically set up the render ring functions and params
Our hw is simply not well-designed enough that it neatly fits into
boxes. Everywhere else we set up vtables and similar things
dynamically using switch statements - it's simply much more flexible.
This is prep work to rework the pre-gen6 ring irq stuff - it'll add a
few more differences. With the current const struct templates, that
would be a mess.
This leads to some unfortunate duplication with the old dri1 code, but
we can reap that again because gen6 isn't actually supported there.
But that's for a separate patch.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 71 +--
1 files changed, 49 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8131c40..03ead75 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1259,26 +1259,6 @@ void intel_ring_advance(struct intel_ring_buffer *ring)
ring-write_tail(ring, ring-tail);
}
-static const struct intel_ring_buffer render_ring = {
- .name = render ring,
- .id = RCS,
- .mmio_base = RENDER_RING_BASE,
- .init = init_render_ring,
- .write_tail = ring_write_tail,
- .flush = render_ring_flush,
- .add_request= render_ring_add_request,
- .get_seqno = ring_get_seqno,
- .irq_get= render_ring_get_irq,
- .irq_put= render_ring_put_irq,
- .dispatch_execbuffer= render_ring_dispatch_execbuffer,
- .cleanup= render_ring_cleanup,
- .sync_to= render_ring_sync_to,
- .semaphore_register = {MI_SEMAPHORE_SYNC_INVALID,
- MI_SEMAPHORE_SYNC_RV,
- MI_SEMAPHORE_SYNC_RB},
- .signal_mbox= {GEN6_VRSYNC, GEN6_BRSYNC},
-};
-
/* ring buffer for bit-stream decoder */
static const struct intel_ring_buffer bsd_ring = {
@@ -1426,7 +1406,10 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring = dev_priv-ring[RCS];
- *ring = render_ring;
+ ring-name = render ring;
+ ring-id = RCS;
+ ring-mmio_base = RENDER_RING_BASE;
+
if (INTEL_INFO(dev)-gen = 6) {
ring-add_request = gen6_add_request;
ring-flush = gen6_render_ring_flush;
@@ -1434,10 +1417,30 @@ int intel_init_render_ring_buffer(struct drm_device
*dev)
ring-irq_put = gen6_ring_put_irq;
ring-irq_enable_mask = GT_USER_INTERRUPT;
ring-get_seqno = gen6_ring_get_seqno;
+ ring-sync_to = render_ring_sync_to;
+ ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore_register[1] = MI_SEMAPHORE_SYNC_RV;
+ ring-semaphore_register[2] = MI_SEMAPHORE_SYNC_RB;
+ ring-signal_mbox[0] = GEN6_VRSYNC;
+ ring-signal_mbox[1] = GEN6_BRSYNC;
} else if (IS_GEN5(dev)) {
ring-add_request = pc_render_add_request;
+ ring-flush = render_ring_flush;
ring-get_seqno = pc_render_get_seqno;
+ ring-irq_get = render_ring_get_irq;
+ ring-irq_put = render_ring_put_irq;
+ } else {
+ ring-add_request = render_ring_add_request;
+ ring-flush = render_ring_flush;
+ ring-get_seqno = ring_get_seqno;
+ ring-irq_get = render_ring_get_irq;
+ ring-irq_put = render_ring_put_irq;
}
+ ring-write_tail = ring_write_tail;
+ ring-dispatch_execbuffer = render_ring_dispatch_execbuffer;
+ ring-init = init_render_ring;
+ ring-cleanup = render_ring_cleanup;
+
if (!I915_NEED_GFX_HWS(dev)) {
ring-status_page.page_addr = dev_priv-status_page_dmah-vaddr;
@@ -1452,16 +1455,40 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring = dev_priv-ring[RCS];
- *ring = render_ring;
+ ring-name = render ring;
+ ring-id = RCS;
+ ring-mmio_base = RENDER_RING_BASE;
+
if (INTEL_INFO(dev)-gen = 6) {
ring-add_request = gen6_add_request;
+ ring-flush = gen6_render_ring_flush;
ring-irq_get = gen6_ring_get_irq;
ring-irq_put = gen6_ring_put_irq;
ring-irq_enable_mask = GT_USER_INTERRUPT;
+ ring-get_seqno = gen6_ring_get_seqno;
+ ring-sync_to = render_ring_sync_to;
+ ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_INVALID;
+
[Intel-gfx] [PATCH 04/14] drm/i915: dynamically set up bsd ring functions and params
The same treatment for the bds ring. Again, this will be split up
further by the irq rework.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 72 +-
1 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 03ead75..32ff8c7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1259,22 +1259,6 @@ void intel_ring_advance(struct intel_ring_buffer *ring)
ring-write_tail(ring, ring-tail);
}
-/* ring buffer for bit-stream decoder */
-
-static const struct intel_ring_buffer bsd_ring = {
- .name = bsd ring,
- .id = VCS,
- .mmio_base = BSD_RING_BASE,
- .init = init_ring_common,
- .write_tail = ring_write_tail,
- .flush = bsd_ring_flush,
- .add_request= ring_add_request,
- .get_seqno = ring_get_seqno,
- .irq_get= bsd_ring_get_irq,
- .irq_put= bsd_ring_put_irq,
- .dispatch_execbuffer= ring_dispatch_execbuffer,
-};
-
static void gen6_bsd_ring_write_tail(struct intel_ring_buffer *ring,
u32 value)
@@ -1337,27 +1321,6 @@ gen6_ring_dispatch_execbuffer(struct intel_ring_buffer
*ring,
return 0;
}
-/* ring buffer for Video Codec for Gen6+ */
-static const struct intel_ring_buffer gen6_bsd_ring = {
- .name = gen6 bsd ring,
- .id = VCS,
- .mmio_base = GEN6_BSD_RING_BASE,
- .init = init_ring_common,
- .write_tail = gen6_bsd_ring_write_tail,
- .flush = gen6_ring_flush,
- .add_request= gen6_add_request,
- .get_seqno = gen6_ring_get_seqno,
- .irq_enable_mask= GEN6_BSD_USER_INTERRUPT,
- .irq_get= gen6_ring_get_irq,
- .irq_put= gen6_ring_put_irq,
- .dispatch_execbuffer= gen6_ring_dispatch_execbuffer,
- .sync_to= gen6_bsd_ring_sync_to,
- .semaphore_register = {MI_SEMAPHORE_SYNC_VR,
- MI_SEMAPHORE_SYNC_INVALID,
- MI_SEMAPHORE_SYNC_VB},
- .signal_mbox= {GEN6_RVSYNC, GEN6_BVSYNC},
-};
-
/* Blitter support (SandyBridge+) */
static int blt_ring_flush(struct intel_ring_buffer *ring,
@@ -1525,10 +1488,37 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring = dev_priv-ring[VCS];
- if (IS_GEN6(dev) || IS_GEN7(dev))
- *ring = gen6_bsd_ring;
- else
- *ring = bsd_ring;
+ ring-name = bsd ring;
+ ring-id = VCS;
+
+ if (IS_GEN6(dev) || IS_GEN7(dev)) {
+ ring-mmio_base = GEN6_BSD_RING_BASE;
+ ring-write_tail = gen6_bsd_ring_write_tail;
+ ring-flush = gen6_ring_flush;
+ ring-add_request = gen6_add_request;
+ ring-get_seqno = gen6_ring_get_seqno;
+ ring-irq_enable_mask = GEN6_BSD_USER_INTERRUPT;
+ ring-irq_get = gen6_ring_get_irq;
+ ring-irq_put = gen6_ring_put_irq;
+ ring-dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
+ ring-sync_to = gen6_bsd_ring_sync_to;
+ ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_VR;
+ ring-semaphore_register[1] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore_register[2] = MI_SEMAPHORE_SYNC_VB;
+ ring-signal_mbox[0] = GEN6_RVSYNC;
+ ring-signal_mbox[1] = GEN6_BVSYNC;
+ } else {
+ ring-mmio_base = BSD_RING_BASE;
+ ring-write_tail = ring_write_tail;
+ ring-flush = bsd_ring_flush;
+ ring-add_request = ring_add_request;
+ ring-get_seqno = ring_get_seqno;
+ ring-irq_get = bsd_ring_get_irq;
+ ring-irq_put = bsd_ring_put_irq;
+ ring-dispatch_execbuffer = ring_dispatch_execbuffer;
+ }
+ ring-init = init_ring_common;
+
return intel_init_ring_buffer(dev, ring);
}
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/14] drm/i915: dynamically set up blt ring functions and parameters
Just for consistency.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 40 ++
1 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 32ff8c7..ac2d10b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1344,26 +1344,6 @@ static int blt_ring_flush(struct intel_ring_buffer *ring,
return 0;
}
-static const struct intel_ring_buffer gen6_blt_ring = {
- .name = blt ring,
- .id = BCS,
- .mmio_base = BLT_RING_BASE,
- .init = init_ring_common,
- .write_tail = ring_write_tail,
- .flush = blt_ring_flush,
- .add_request= gen6_add_request,
- .get_seqno = gen6_ring_get_seqno,
- .irq_get= gen6_ring_get_irq,
- .irq_put= gen6_ring_put_irq,
- .irq_enable_mask= GEN6_BLITTER_USER_INTERRUPT,
- .dispatch_execbuffer= gen6_ring_dispatch_execbuffer,
- .sync_to= gen6_blt_ring_sync_to,
- .semaphore_register = {MI_SEMAPHORE_SYNC_BR,
- MI_SEMAPHORE_SYNC_BV,
- MI_SEMAPHORE_SYNC_INVALID},
- .signal_mbox= {GEN6_RBSYNC, GEN6_VBSYNC},
-};
-
int intel_init_render_ring_buffer(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
@@ -1528,7 +1508,25 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring = dev_priv-ring[BCS];
- *ring = gen6_blt_ring;
+ ring-name = blitter ring;
+ ring-id = BCS;
+
+ ring-mmio_base = BLT_RING_BASE;
+ ring-write_tail = ring_write_tail;
+ ring-flush = blt_ring_flush;
+ ring-add_request = gen6_add_request;
+ ring-get_seqno = gen6_ring_get_seqno;
+ ring-irq_enable_mask = GEN6_BLITTER_USER_INTERRUPT;
+ ring-irq_get = gen6_ring_get_irq;
+ ring-irq_put = gen6_ring_put_irq;
+ ring-dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
+ ring-sync_to = gen6_blt_ring_sync_to;
+ ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_BR;
+ ring-semaphore_register[1] = MI_SEMAPHORE_SYNC_BV;
+ ring-semaphore_register[2] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-signal_mbox[0] = GEN6_RBSYNC;
+ ring-signal_mbox[1] = GEN6_VBSYNC;
+ ring-init = init_ring_common;
return intel_init_ring_buffer(dev, ring);
}
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/14] drm/i915: don't set up rings on gen6+ for non-kms
It's not supported, and with the patch to refuse loading on gen6+
without kms enabled, there's also no way we can hit this.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ac2d10b..7d0a5bc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1403,18 +1403,8 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
ring-mmio_base = RENDER_RING_BASE;
if (INTEL_INFO(dev)-gen = 6) {
- ring-add_request = gen6_add_request;
- ring-flush = gen6_render_ring_flush;
- ring-irq_get = gen6_ring_get_irq;
- ring-irq_put = gen6_ring_put_irq;
- ring-irq_enable_mask = GT_USER_INTERRUPT;
- ring-get_seqno = gen6_ring_get_seqno;
- ring-sync_to = render_ring_sync_to;
- ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_INVALID;
- ring-semaphore_register[1] = MI_SEMAPHORE_SYNC_RV;
- ring-semaphore_register[2] = MI_SEMAPHORE_SYNC_RB;
- ring-signal_mbox[0] = GEN6_VRSYNC;
- ring-signal_mbox[1] = GEN6_BRSYNC;
+ /* non-kms not supported on gen6+ */
+ return -ENODEV;
} else if (IS_GEN5(dev)) {
ring-add_request = pc_render_add_request;
ring-flush = render_ring_flush;
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/14] drm/i915: consolidate ring-sync-to functions
The waiter is always the ring itself (otherwise we'd have a decent
snafu in a callsite), so we can unify this easily.
Also give it the usual gen6_ prefix, in case anyone is foolish enough to
implement hw semaphores for gen5.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 60 ++-
1 files changed, 11 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 7d0a5bc..12f9304 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -472,21 +472,24 @@ gen6_add_request(struct intel_ring_buffer *ring,
* @seqno - seqno which the waiter will block on
*/
static int
-intel_ring_sync(struct intel_ring_buffer *waiter,
- struct intel_ring_buffer *signaller,
- int ring,
- u32 seqno)
+gen6_ring_sync(struct intel_ring_buffer *waiter,
+ struct intel_ring_buffer *signaller,
+ u32 seqno)
{
int ret;
u32 dw1 = MI_SEMAPHORE_MBOX |
MI_SEMAPHORE_COMPARE |
MI_SEMAPHORE_REGISTER;
+ WARN_ON(signaller-semaphore_register[waiter-id] ==
+ MI_SEMAPHORE_SYNC_INVALID);
+
ret = intel_ring_begin(waiter, 4);
if (ret)
return ret;
- intel_ring_emit(waiter, dw1 | signaller-semaphore_register[ring]);
+ intel_ring_emit(waiter,
+ dw1 | signaller-semaphore_register[waiter-id]);
intel_ring_emit(waiter, seqno);
intel_ring_emit(waiter, 0);
intel_ring_emit(waiter, MI_NOOP);
@@ -495,47 +498,6 @@ intel_ring_sync(struct intel_ring_buffer *waiter,
return 0;
}
-/* VCS-RCS (RVSYNC) or BCS-RCS (RBSYNC) */
-int
-render_ring_sync_to(struct intel_ring_buffer *waiter,
- struct intel_ring_buffer *signaller,
- u32 seqno)
-{
- WARN_ON(signaller-semaphore_register[RCS] ==
MI_SEMAPHORE_SYNC_INVALID);
- return intel_ring_sync(waiter,
- signaller,
- RCS,
- seqno);
-}
-
-/* RCS-VCS (VRSYNC) or BCS-VCS (VBSYNC) */
-int
-gen6_bsd_ring_sync_to(struct intel_ring_buffer *waiter,
- struct intel_ring_buffer *signaller,
- u32 seqno)
-{
- WARN_ON(signaller-semaphore_register[VCS] ==
MI_SEMAPHORE_SYNC_INVALID);
- return intel_ring_sync(waiter,
- signaller,
- VCS,
- seqno);
-}
-
-/* RCS-BCS (BRSYNC) or VCS-BCS (BVSYNC) */
-int
-gen6_blt_ring_sync_to(struct intel_ring_buffer *waiter,
- struct intel_ring_buffer *signaller,
- u32 seqno)
-{
- WARN_ON(signaller-semaphore_register[BCS] ==
MI_SEMAPHORE_SYNC_INVALID);
- return intel_ring_sync(waiter,
- signaller,
- BCS,
- seqno);
-}
-
-
-
#define PIPE_CONTROL_FLUSH(ring__, addr__)
\
do { \
intel_ring_emit(ring__, GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE
|\
@@ -1360,7 +1322,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring-irq_put = gen6_ring_put_irq;
ring-irq_enable_mask = GT_USER_INTERRUPT;
ring-get_seqno = gen6_ring_get_seqno;
- ring-sync_to = render_ring_sync_to;
+ ring-sync_to = gen6_ring_sync;
ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_INVALID;
ring-semaphore_register[1] = MI_SEMAPHORE_SYNC_RV;
ring-semaphore_register[2] = MI_SEMAPHORE_SYNC_RB;
@@ -1471,7 +1433,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring-irq_get = gen6_ring_get_irq;
ring-irq_put = gen6_ring_put_irq;
ring-dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
- ring-sync_to = gen6_bsd_ring_sync_to;
+ ring-sync_to = gen6_ring_sync;
ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_VR;
ring-semaphore_register[1] = MI_SEMAPHORE_SYNC_INVALID;
ring-semaphore_register[2] = MI_SEMAPHORE_SYNC_VB;
@@ -1510,7 +1472,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
ring-irq_get = gen6_ring_get_irq;
ring-irq_put = gen6_ring_put_irq;
ring-dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
- ring-sync_to = gen6_blt_ring_sync_to;
+ ring-sync_to = gen6_ring_sync;
ring-semaphore_register[0] = MI_SEMAPHORE_SYNC_BR;
ring-semaphore_register[1] = MI_SEMAPHORE_SYNC_BV;
ring-semaphore_register[2] = MI_SEMAPHORE_SYNC_INVALID;
--
1.7.7.5
[Intel-gfx] [PATCH 08/14] drm/i915: abstract away ring-specific irq_get/put
Inspired by Ben Widawsky's patch for gen6+. Now after restructuring
how we set up the ring vtables and parameters, we can do this right.
This kills the bsd specific get/put_irq functions, they're now the
same.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 77 ++-
1 files changed, 24 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 12f9304..6624a22 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -639,7 +639,7 @@ i915_disable_irq(drm_i915_private_t *dev_priv, u32 mask)
}
static bool
-render_ring_get_irq(struct intel_ring_buffer *ring)
+i9xx_ring_get_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
@@ -651,9 +651,9 @@ render_ring_get_irq(struct intel_ring_buffer *ring)
if (ring-irq_refcount++ == 0) {
if (INTEL_INFO(dev)-gen = 5)
ironlake_enable_irq(dev_priv,
- GT_PIPE_NOTIFY | GT_USER_INTERRUPT);
+ ring-irq_enable_mask);
else
- i915_enable_irq(dev_priv, I915_USER_INTERRUPT);
+ i915_enable_irq(dev_priv, ring-irq_enable_mask);
}
spin_unlock(ring-irq_lock);
@@ -661,7 +661,7 @@ render_ring_get_irq(struct intel_ring_buffer *ring)
}
static void
-render_ring_put_irq(struct intel_ring_buffer *ring)
+i9xx_ring_put_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
@@ -670,10 +670,9 @@ render_ring_put_irq(struct intel_ring_buffer *ring)
if (--ring-irq_refcount == 0) {
if (INTEL_INFO(dev)-gen = 5)
ironlake_disable_irq(dev_priv,
-GT_USER_INTERRUPT |
-GT_PIPE_NOTIFY);
+ring-irq_enable_mask);
else
- i915_disable_irq(dev_priv, I915_USER_INTERRUPT);
+ i915_disable_irq(dev_priv, ring-irq_enable_mask);
}
spin_unlock(ring-irq_lock);
}
@@ -789,42 +788,6 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring)
gen6_gt_force_wake_put(dev_priv);
}
-static bool
-bsd_ring_get_irq(struct intel_ring_buffer *ring)
-{
- struct drm_device *dev = ring-dev;
- drm_i915_private_t *dev_priv = dev-dev_private;
-
- if (!dev-irq_enabled)
- return false;
-
- spin_lock(ring-irq_lock);
- if (ring-irq_refcount++ == 0) {
- if (IS_G4X(dev))
- i915_enable_irq(dev_priv, I915_BSD_USER_INTERRUPT);
- else
- ironlake_enable_irq(dev_priv, GT_BSD_USER_INTERRUPT);
- }
- spin_unlock(ring-irq_lock);
-
- return true;
-}
-static void
-bsd_ring_put_irq(struct intel_ring_buffer *ring)
-{
- struct drm_device *dev = ring-dev;
- drm_i915_private_t *dev_priv = dev-dev_private;
-
- spin_lock(ring-irq_lock);
- if (--ring-irq_refcount == 0) {
- if (IS_G4X(dev))
- i915_disable_irq(dev_priv, I915_BSD_USER_INTERRUPT);
- else
- ironlake_disable_irq(dev_priv, GT_BSD_USER_INTERRUPT);
- }
- spin_unlock(ring-irq_lock);
-}
-
static int
ring_dispatch_execbuffer(struct intel_ring_buffer *ring, u32 offset, u32
length)
{
@@ -1332,14 +1295,16 @@ int intel_init_render_ring_buffer(struct drm_device
*dev)
ring-add_request = pc_render_add_request;
ring-flush = render_ring_flush;
ring-get_seqno = pc_render_get_seqno;
- ring-irq_get = render_ring_get_irq;
- ring-irq_put = render_ring_put_irq;
+ ring-irq_get = i9xx_ring_get_irq;
+ ring-irq_put = i9xx_ring_put_irq;
+ ring-irq_enable_mask = GT_USER_INTERRUPT | GT_PIPE_NOTIFY;
} else {
ring-add_request = render_ring_add_request;
ring-flush = render_ring_flush;
ring-get_seqno = ring_get_seqno;
- ring-irq_get = render_ring_get_irq;
- ring-irq_put = render_ring_put_irq;
+ ring-irq_get = i9xx_ring_get_irq;
+ ring-irq_put = i9xx_ring_put_irq;
+ ring-irq_enable_mask = I915_USER_INTERRUPT;
}
ring-write_tail = ring_write_tail;
ring-dispatch_execbuffer = render_ring_dispatch_execbuffer;
@@ -1371,14 +1336,16 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
ring-add_request = pc_render_add_request;
ring-flush =
[Intel-gfx] [PATCH 09/14] drm/i915: split out the gen5 ring irq get/put functions
Now that we have sensibly split up, we can nicely get rid of that ugly
is_gen5 check.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 66 --
1 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6624a22..36dd660 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -639,6 +639,35 @@ i915_disable_irq(drm_i915_private_t *dev_priv, u32 mask)
}
static bool
+gen5_ring_get_irq(struct intel_ring_buffer *ring)
+{
+ struct drm_device *dev = ring-dev;
+ drm_i915_private_t *dev_priv = dev-dev_private;
+
+ if (!dev-irq_enabled)
+ return false;
+
+ spin_lock(ring-irq_lock);
+ if (ring-irq_refcount++ == 0)
+ ironlake_enable_irq(dev_priv, ring-irq_enable_mask);
+ spin_unlock(ring-irq_lock);
+
+ return true;
+}
+
+static void
+gen5_ring_put_irq(struct intel_ring_buffer *ring)
+{
+ struct drm_device *dev = ring-dev;
+ drm_i915_private_t *dev_priv = dev-dev_private;
+
+ spin_lock(ring-irq_lock);
+ if (--ring-irq_refcount == 0)
+ ironlake_disable_irq(dev_priv, ring-irq_enable_mask);
+ spin_unlock(ring-irq_lock);
+}
+
+static bool
i9xx_ring_get_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
@@ -648,13 +677,8 @@ i9xx_ring_get_irq(struct intel_ring_buffer *ring)
return false;
spin_lock(ring-irq_lock);
- if (ring-irq_refcount++ == 0) {
- if (INTEL_INFO(dev)-gen = 5)
- ironlake_enable_irq(dev_priv,
- ring-irq_enable_mask);
- else
- i915_enable_irq(dev_priv, ring-irq_enable_mask);
- }
+ if (ring-irq_refcount++ == 0)
+ i915_enable_irq(dev_priv, ring-irq_enable_mask);
spin_unlock(ring-irq_lock);
return true;
@@ -667,13 +691,8 @@ i9xx_ring_put_irq(struct intel_ring_buffer *ring)
drm_i915_private_t *dev_priv = dev-dev_private;
spin_lock(ring-irq_lock);
- if (--ring-irq_refcount == 0) {
- if (INTEL_INFO(dev)-gen = 5)
- ironlake_disable_irq(dev_priv,
-ring-irq_enable_mask);
- else
- i915_disable_irq(dev_priv, ring-irq_enable_mask);
- }
+ if (--ring-irq_refcount == 0)
+ i915_disable_irq(dev_priv, ring-irq_enable_mask);
spin_unlock(ring-irq_lock);
}
@@ -1295,8 +1314,8 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring-add_request = pc_render_add_request;
ring-flush = render_ring_flush;
ring-get_seqno = pc_render_get_seqno;
- ring-irq_get = i9xx_ring_get_irq;
- ring-irq_put = i9xx_ring_put_irq;
+ ring-irq_get = gen5_ring_get_irq;
+ ring-irq_put = gen5_ring_put_irq;
ring-irq_enable_mask = GT_USER_INTERRUPT | GT_PIPE_NOTIFY;
} else {
ring-add_request = render_ring_add_request;
@@ -1336,8 +1355,8 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
ring-add_request = pc_render_add_request;
ring-flush = render_ring_flush;
ring-get_seqno = pc_render_get_seqno;
- ring-irq_get = i9xx_ring_get_irq;
- ring-irq_put = i9xx_ring_put_irq;
+ ring-irq_get = gen5_ring_get_irq;
+ ring-irq_put = gen5_ring_put_irq;
ring-irq_enable_mask = GT_USER_INTERRUPT | GT_PIPE_NOTIFY;
} else {
ring-add_request = render_ring_add_request;
@@ -1412,12 +1431,15 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring-flush = bsd_ring_flush;
ring-add_request = ring_add_request;
ring-get_seqno = ring_get_seqno;
- ring-irq_get = i9xx_ring_get_irq;
- ring-irq_put = i9xx_ring_put_irq;
- if (IS_GEN5(dev))
+ if (IS_GEN5(dev)) {
ring-irq_enable_mask = GT_BSD_USER_INTERRUPT;
- else
+ ring-irq_get = gen5_ring_get_irq;
+ ring-irq_put = gen5_ring_put_irq;
+ } else {
ring-irq_enable_mask = I915_BSD_USER_INTERRUPT;
+ ring-irq_get = i9xx_ring_get_irq;
+ ring-irq_put = i9xx_ring_put_irq;
+ }
ring-dispatch_execbuffer = ring_dispatch_execbuffer;
}
ring-init = init_ring_common;
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 10/14] drm/i915: don't enable the gen6 bsd ring tail write enable on gen7
HW engineers have fixed this issue for ivb. Again, a nice cleanup
possible thanks to the more flexible ring initialization.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 36dd660..2cb1c8f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1409,9 +1409,12 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring-name = bsd ring;
ring-id = VCS;
+ ring-write_tail = ring_write_tail;
if (IS_GEN6(dev) || IS_GEN7(dev)) {
ring-mmio_base = GEN6_BSD_RING_BASE;
- ring-write_tail = gen6_bsd_ring_write_tail;
+ /* gen6 bsd needs a special wa for tail updates */
+ if (IS_GEN6(dev))
+ ring-write_tail = gen6_bsd_ring_write_tail;
ring-flush = gen6_ring_flush;
ring-add_request = gen6_add_request;
ring-get_seqno = gen6_ring_get_seqno;
@@ -1427,7 +1430,6 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring-signal_mbox[1] = GEN6_BVSYNC;
} else {
ring-mmio_base = BSD_RING_BASE;
- ring-write_tail = ring_write_tail;
ring-flush = bsd_ring_flush;
ring-add_request = ring_add_request;
ring-get_seqno = ring_get_seqno;
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/14] drm/i915: split up ring-dispatch_execbuffer functions
Now that we can, we should split them up in a way that makes some
sense and banishes the IS_ checks into init code.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 69 ++-
1 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2cb1c8f..3d32c51 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -808,7 +808,7 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring)
}
static int
-ring_dispatch_execbuffer(struct intel_ring_buffer *ring, u32 offset, u32
length)
+i965_dispatch_execbuffer(struct intel_ring_buffer *ring, u32 offset, u32
length)
{
int ret;
@@ -826,37 +826,36 @@ ring_dispatch_execbuffer(struct intel_ring_buffer *ring,
u32 offset, u32 length)
}
static int
-render_ring_dispatch_execbuffer(struct intel_ring_buffer *ring,
+i830_dispatch_execbuffer(struct intel_ring_buffer *ring,
u32 offset, u32 len)
{
- struct drm_device *dev = ring-dev;
int ret;
- if (IS_I830(dev) || IS_845G(dev)) {
- ret = intel_ring_begin(ring, 4);
- if (ret)
- return ret;
+ ret = intel_ring_begin(ring, 4);
+ if (ret)
+ return ret;
- intel_ring_emit(ring, MI_BATCH_BUFFER);
- intel_ring_emit(ring, offset | MI_BATCH_NON_SECURE);
- intel_ring_emit(ring, offset + len - 8);
- intel_ring_emit(ring, 0);
- } else {
- ret = intel_ring_begin(ring, 2);
- if (ret)
- return ret;
+ intel_ring_emit(ring, MI_BATCH_BUFFER);
+ intel_ring_emit(ring, offset | MI_BATCH_NON_SECURE);
+ intel_ring_emit(ring, offset + len - 8);
+ intel_ring_emit(ring, 0);
+ intel_ring_advance(ring);
- if (INTEL_INFO(dev)-gen = 4) {
- intel_ring_emit(ring,
- MI_BATCH_BUFFER_START | (2 6) |
- MI_BATCH_NON_SECURE_I965);
- intel_ring_emit(ring, offset);
- } else {
- intel_ring_emit(ring,
- MI_BATCH_BUFFER_START | (2 6));
- intel_ring_emit(ring, offset | MI_BATCH_NON_SECURE);
- }
- }
+ return 0;
+}
+
+static int
+i915_dispatch_execbuffer(struct intel_ring_buffer *ring,
+ u32 offset, u32 len)
+{
+ int ret;
+
+ ret = intel_ring_begin(ring, 2);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, MI_BATCH_BUFFER_START | (2 6));
+ intel_ring_emit(ring, offset | MI_BATCH_NON_SECURE);
intel_ring_advance(ring);
return 0;
@@ -1326,7 +1325,14 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring-irq_enable_mask = I915_USER_INTERRUPT;
}
ring-write_tail = ring_write_tail;
- ring-dispatch_execbuffer = render_ring_dispatch_execbuffer;
+ if (INTEL_INFO(dev)-gen = 6)
+ ring-dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
+ else if (INTEL_INFO(dev)-gen = 4)
+ ring-dispatch_execbuffer = i965_dispatch_execbuffer;
+ else if (IS_I830(dev) || IS_845G(dev))
+ ring-dispatch_execbuffer = i830_dispatch_execbuffer;
+ else
+ ring-dispatch_execbuffer = i915_dispatch_execbuffer;
ring-init = init_render_ring;
ring-cleanup = render_ring_cleanup;
@@ -1367,7 +1373,12 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
ring-irq_enable_mask = I915_USER_INTERRUPT;
}
ring-write_tail = ring_write_tail;
- ring-dispatch_execbuffer = render_ring_dispatch_execbuffer;
+ if (INTEL_INFO(dev)-gen = 4)
+ ring-dispatch_execbuffer = i965_dispatch_execbuffer;
+ else if (IS_I830(dev) || IS_845G(dev))
+ ring-dispatch_execbuffer = i830_dispatch_execbuffer;
+ else
+ ring-dispatch_execbuffer = i915_dispatch_execbuffer;
ring-init = init_render_ring;
ring-cleanup = render_ring_cleanup;
@@ -1442,7 +1453,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring-irq_get = i9xx_ring_get_irq;
ring-irq_put = i9xx_ring_put_irq;
}
- ring-dispatch_execbuffer = ring_dispatch_execbuffer;
+ ring-dispatch_execbuffer = i965_dispatch_execbuffer;
}
ring-init = init_ring_common;
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/14] drm/i915: consolidate ring-flush a bit
They're indentical, so just kill one. Also give the other a prefix to
distinguish it from the gen6+ functions - this add_request function is
not really generic code.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 29 -
1 files changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3d32c51..111981a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -559,27 +559,6 @@ pc_render_add_request(struct intel_ring_buffer *ring,
return 0;
}
-static int
-render_ring_add_request(struct intel_ring_buffer *ring,
- u32 *result)
-{
- u32 seqno = i915_gem_next_request_seqno(ring);
- int ret;
-
- ret = intel_ring_begin(ring, 4);
- if (ret)
- return ret;
-
- intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
- intel_ring_emit(ring, I915_GEM_HWS_INDEX MI_STORE_DWORD_INDEX_SHIFT);
- intel_ring_emit(ring, seqno);
- intel_ring_emit(ring, MI_USER_INTERRUPT);
- intel_ring_advance(ring);
-
- *result = seqno;
- return 0;
-}
-
static u32
gen6_ring_get_seqno(struct intel_ring_buffer *ring)
{
@@ -745,7 +724,7 @@ bsd_ring_flush(struct intel_ring_buffer *ring,
}
static int
-ring_add_request(struct intel_ring_buffer *ring,
+i9xx_add_request(struct intel_ring_buffer *ring,
u32 *result)
{
u32 seqno;
@@ -1317,7 +1296,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring-irq_put = gen5_ring_put_irq;
ring-irq_enable_mask = GT_USER_INTERRUPT | GT_PIPE_NOTIFY;
} else {
- ring-add_request = render_ring_add_request;
+ ring-add_request = i9xx_add_request;
ring-flush = render_ring_flush;
ring-get_seqno = ring_get_seqno;
ring-irq_get = i9xx_ring_get_irq;
@@ -1365,7 +1344,7 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
ring-irq_put = gen5_ring_put_irq;
ring-irq_enable_mask = GT_USER_INTERRUPT | GT_PIPE_NOTIFY;
} else {
- ring-add_request = render_ring_add_request;
+ ring-add_request = i9xx_add_request;
ring-flush = render_ring_flush;
ring-get_seqno = ring_get_seqno;
ring-irq_get = i9xx_ring_get_irq;
@@ -1442,7 +1421,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
} else {
ring-mmio_base = BSD_RING_BASE;
ring-flush = bsd_ring_flush;
- ring-add_request = ring_add_request;
+ ring-add_request = i9xx_add_request;
ring-get_seqno = ring_get_seqno;
if (IS_GEN5(dev)) {
ring-irq_enable_mask = GT_BSD_USER_INTERRUPT;
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/14] drm/i915: don't set up gem ring functions on gen5 for !kms
We already disallow initialition of gem in this case in the
corresponding ioctl, so don't bother setting up the gem support ring
functions in the legacy dri render ring init.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 24 ++--
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 111981a..108bfd6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1336,21 +1336,17 @@ int intel_render_ring_init_dri(struct drm_device *dev,
u64 start, u32 size)
if (INTEL_INFO(dev)-gen = 6) {
/* non-kms not supported on gen6+ */
return -ENODEV;
- } else if (IS_GEN5(dev)) {
- ring-add_request = pc_render_add_request;
- ring-flush = render_ring_flush;
- ring-get_seqno = pc_render_get_seqno;
- ring-irq_get = gen5_ring_get_irq;
- ring-irq_put = gen5_ring_put_irq;
- ring-irq_enable_mask = GT_USER_INTERRUPT | GT_PIPE_NOTIFY;
- } else {
- ring-add_request = i9xx_add_request;
- ring-flush = render_ring_flush;
- ring-get_seqno = ring_get_seqno;
- ring-irq_get = i9xx_ring_get_irq;
- ring-irq_put = i9xx_ring_put_irq;
- ring-irq_enable_mask = I915_USER_INTERRUPT;
}
+
+ /* Note: gem is not supported on gen5/ilk without kms (the corresponding
+* gem_init ioctl returns with -ENODEV). Hence we do not need to set up
+* the special gen5 functions. */
+ ring-add_request = i9xx_add_request;
+ ring-flush = render_ring_flush;
+ ring-get_seqno = ring_get_seqno;
+ ring-irq_get = i9xx_ring_get_irq;
+ ring-irq_put = i9xx_ring_put_irq;
+ ring-irq_enable_mask = I915_USER_INTERRUPT;
ring-write_tail = ring_write_tail;
if (INTEL_INFO(dev)-gen = 4)
ring-dispatch_execbuffer = i965_dispatch_execbuffer;
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/14] drm/i915: inline enable/disable_irq into ring-get/put_irq
Now that these are properly refactored this additional indirection
doesn't really buy us anything but confusion. Hence inline them.
This duplicates the ironlake gt enable/disable code snippet, but we've
already separate ilk from gen6+ gt irq in i915_irq.c, so I think this
makes more sense.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 68 ---
1 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 108bfd6..2ffde00 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -585,38 +585,6 @@ pc_render_get_seqno(struct intel_ring_buffer *ring)
return pc-cpu_page[0];
}
-static void
-ironlake_enable_irq(drm_i915_private_t *dev_priv, u32 mask)
-{
- dev_priv-gt_irq_mask = ~mask;
- I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
- POSTING_READ(GTIMR);
-}
-
-static void
-ironlake_disable_irq(drm_i915_private_t *dev_priv, u32 mask)
-{
- dev_priv-gt_irq_mask |= mask;
- I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
- POSTING_READ(GTIMR);
-}
-
-static void
-i915_enable_irq(drm_i915_private_t *dev_priv, u32 mask)
-{
- dev_priv-irq_mask = ~mask;
- I915_WRITE(IMR, dev_priv-irq_mask);
- POSTING_READ(IMR);
-}
-
-static void
-i915_disable_irq(drm_i915_private_t *dev_priv, u32 mask)
-{
- dev_priv-irq_mask |= mask;
- I915_WRITE(IMR, dev_priv-irq_mask);
- POSTING_READ(IMR);
-}
-
static bool
gen5_ring_get_irq(struct intel_ring_buffer *ring)
{
@@ -627,8 +595,11 @@ gen5_ring_get_irq(struct intel_ring_buffer *ring)
return false;
spin_lock(ring-irq_lock);
- if (ring-irq_refcount++ == 0)
- ironlake_enable_irq(dev_priv, ring-irq_enable_mask);
+ if (ring-irq_refcount++ == 0) {
+ dev_priv-gt_irq_mask = ~ring-irq_enable_mask;
+ I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
+ POSTING_READ(GTIMR);
+ }
spin_unlock(ring-irq_lock);
return true;
@@ -641,8 +612,11 @@ gen5_ring_put_irq(struct intel_ring_buffer *ring)
drm_i915_private_t *dev_priv = dev-dev_private;
spin_lock(ring-irq_lock);
- if (--ring-irq_refcount == 0)
- ironlake_disable_irq(dev_priv, ring-irq_enable_mask);
+ if (--ring-irq_refcount == 0) {
+ dev_priv-gt_irq_mask |= ring-irq_enable_mask;
+ I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
+ POSTING_READ(GTIMR);
+ }
spin_unlock(ring-irq_lock);
}
@@ -656,8 +630,11 @@ i9xx_ring_get_irq(struct intel_ring_buffer *ring)
return false;
spin_lock(ring-irq_lock);
- if (ring-irq_refcount++ == 0)
- i915_enable_irq(dev_priv, ring-irq_enable_mask);
+ if (ring-irq_refcount++ == 0) {
+ dev_priv-irq_mask = ~ring-irq_enable_mask;
+ I915_WRITE(IMR, dev_priv-irq_mask);
+ POSTING_READ(IMR);
+ }
spin_unlock(ring-irq_lock);
return true;
@@ -670,8 +647,11 @@ i9xx_ring_put_irq(struct intel_ring_buffer *ring)
drm_i915_private_t *dev_priv = dev-dev_private;
spin_lock(ring-irq_lock);
- if (--ring-irq_refcount == 0)
- i915_disable_irq(dev_priv, ring-irq_enable_mask);
+ if (--ring-irq_refcount == 0) {
+ dev_priv-irq_mask |= ring-irq_enable_mask;
+ I915_WRITE(IMR, dev_priv-irq_mask);
+ POSTING_READ(IMR);
+ }
spin_unlock(ring-irq_lock);
}
@@ -763,7 +743,9 @@ gen6_ring_get_irq(struct intel_ring_buffer *ring)
spin_lock(ring-irq_lock);
if (ring-irq_refcount++ == 0) {
I915_WRITE_IMR(ring, ~ring-irq_enable_mask);
- ironlake_enable_irq(dev_priv, ring-irq_enable_mask);
+ dev_priv-gt_irq_mask = ~ring-irq_enable_mask;
+ I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
+ POSTING_READ(GTIMR);
}
spin_unlock(ring-irq_lock);
@@ -779,7 +761,9 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring)
spin_lock(ring-irq_lock);
if (--ring-irq_refcount == 0) {
I915_WRITE_IMR(ring, ~0);
- ironlake_disable_irq(dev_priv, ring-irq_enable_mask);
+ dev_priv-gt_irq_mask |= ring-irq_enable_mask;
+ I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
+ POSTING_READ(GTIMR);
}
spin_unlock(ring-irq_lock);
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trigger hangcheck if we detect more a repeating missed IRQ
On Wed, 11 Apr 2012 09:18:15 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 10 Apr 2012 16:59:11 -0700, Ben Widawsky b...@bwidawsk.net wrote: On Tue, 10 Apr 2012 17:00:41 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On the first instance we just wish to kick the waiters and see if that terminates the wait conditions. If it does not, then we do not want to keep retrying without ever making any forward progress and becoming stuck in a hangcheck loop. Reported-and-tested-by: Lukas Hejtmanek xhejt...@fi.muni.cz Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48209 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk I'm still confused about the problem we are purportedly fixing. This should happen if we've missed an irq (or the watchdog fired too soon), and then fires again before the thread has actually woken up to realize that is missed the first IRQ? As for extract the kick_ring bit of code for core hangcheck_elapsed, that looks fine. I just don't quite understand the exact problem this solves, and can't envision how we hit this case it seems the patch will fix. Sure, just look at the bug report for the garbage we wrote into the ringbuffers and how we ended up indefinite wait. This is not defense against normal behaviour but the driver screwing up. -Chris In that case this is Reviewed-by: Ben Widawsky b...@bwidawsk.net Though I am still pretty surprised that we have even seen this :| ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/14] intel_ringbuffer.c reorg + cleanups
On Wed, 11 Apr 2012 22:12:45 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, This patch series is inspired by Ben's ring-get|put_irq cleanup for gen6+ and my perpetual hatred for intel_ringbuffer.c. It's a lot of churn, but the end result is imho worth it - I almost started to like what the ringbuffer abstraction looks like now. There are some follow-up cleanups possible, but I think that can wait until we've cleanup up our domain tracking and ripped out the flushing_list (if that ever happens). Commments, flames and review highly welcome. It's not offensive. Cleaning up the function names and the initialisation is certainly worth it. Maybe I was just expecting more. -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
[Intel-gfx] [PATCH] drm/i915: manage PCH PLLs separately from pipes
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.
So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.
v2: add num_pch_pll field to dev_priv (Daniel)
don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse)
put register offsets in pll struct (Chris)
NOTE: this still has what looks like an enable order bug; every other
mode set on a 3 pipe config works as expected, but in between one
or more of the heads won't come up
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=44309
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c |4 +
drivers/gpu/drm/i915/i915_drv.h |3 +
drivers/gpu/drm/i915/i915_reg.h |6 +-
drivers/gpu/drm/i915/i915_suspend.c |2 +-
drivers/gpu/drm/i915/intel_display.c | 198 ++
drivers/gpu/drm/i915/intel_dp.c |1 +
drivers/gpu/drm/i915/intel_drv.h | 11 ++-
7 files changed, 150 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3effcf7..355bd68 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,16 +377,20 @@ void intel_detect_pch(struct drm_device *dev)
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
dev_priv-pch_type = PCH_IBX;
+ dev_priv-num_pch_pll = 2;
DRM_DEBUG_KMS(Found Ibex Peak PCH\n);
} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
dev_priv-pch_type = PCH_CPT;
+ dev_priv-num_pch_pll = 2;
DRM_DEBUG_KMS(Found CougarPoint PCH\n);
} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
/* PantherPoint is CPT compatible */
dev_priv-pch_type = PCH_CPT;
+ dev_priv-num_pch_pll = 2;
DRM_DEBUG_KMS(Found PatherPoint PCH\n);
} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
dev_priv-pch_type = PCH_LPT;
+ dev_priv-num_pch_pll = 0;
DRM_DEBUG_KMS(Found LynxPoint PCH\n);
}
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 422f424..68add98 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -392,6 +392,7 @@ typedef struct drm_i915_private {
unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
int vblank_pipe;
int num_pipe;
+ int num_pch_pll;
/* For hangcheck timer */
#define DRM_I915_HANGCHECK_PERIOD 1500 /* in ms */
@@ -754,6 +755,8 @@ typedef struct drm_i915_private {
wait_queue_head_t pending_flip_queue;
bool flip_pending_is_done;
+ struct intel_pch_pll *pch_plls;
+
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 972321f..96449b7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3370,15 +3370,15 @@
#define _PCH_DPLL_A 0xc6014
#define _PCH_DPLL_B 0xc6018
-#define PCH_DPLL(pipe) (pipe == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
+#define _PCH_DPLL(pll) (pll == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
#define _PCH_FPA00xc6040
#define FP_CB_TUNE(0x322)
#define _PCH_FPA10xc6044
#define _PCH_FPB00xc6048
#define _PCH_FPB10xc604c
-#define PCH_FP0(pipe) (pipe == 0 ? _PCH_FPA0 : _PCH_FPB0)
-#define PCH_FP1(pipe) (pipe == 0 ? _PCH_FPA1 : _PCH_FPB1)
+#define _PCH_FP0(pll) (pll == 0 ? _PCH_FPA0 : _PCH_FPB0)
+#define _PCH_FP1(pll) (pll == 0 ? _PCH_FPA1 : _PCH_FPB1)
#define PCH_DPLL_TEST 0xc606c
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 0c3e3bf..73a5c3c 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -40,7 +40,7 @@ static bool i915_pipe_enabled(struct drm_device *dev, enum
pipe pipe)
return false;
if (HAS_PCH_SPLIT(dev))
- dpll_reg = PCH_DPLL(pipe);
+ dpll_reg = _PCH_DPLL(pipe);
else
dpll_reg = (pipe == PIPE_A) ? _DPLL_A : _DPLL_B;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 33aaad3..2bd77ba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -913,26 +913,28 @@ static void assert_pll(struct
Re: [Intel-gfx] [PATCH v4] drm/i915: rc6 in sysfs
On Wed, 11 Apr 2012 09:14:43 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I'm down to just bikeshedding over useless lines of code which do not
even add visual clarity...
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Oops, need to learn to spot 64-bit divides which become an issue on
32-bit builds.
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 2319f06..f1b5108 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -35,14 +35,12 @@ static u32 calc_residency(struct drm_device *dev, const u32
reg)
{
struct drm_i915_private *dev_priv = dev-dev_private;
u64 raw_time; /* 32b value may overflow during fixed point math */
- u32 residency;
if (!intel_enable_rc6(dev))
return 0;
- raw_time = I915_READ(reg) * 128ULL;
- residency = DIV_ROUND_CLOSEST(raw_time, 1000) / 100;
- return residency;
+ raw_time = I915_READ(reg) * 128ULL + 500;
+ return do_div(raw_time, 10);
}
static ssize_t
--
1.7.9.5
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Show fence pin count in /debug/.../i915_gem_fence_regs
May one day prove invaluable in debugging spurious fencing issues.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b505b70..6b80c5a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -530,7 +530,8 @@ static int i915_gem_fence_regs_info(struct seq_file *m,
void *data)
for (i = 0; i dev_priv-num_fence_regs; i++) {
struct drm_i915_gem_object *obj = dev_priv-fence_regs[i].obj;
- seq_printf(m, Fenced object[%2d] = , i);
+ seq_printf(m, Fence %d, pin count = %d, object = ,
+ i, dev_priv-fence_regs[i].pin_count);
if (obj == NULL)
seq_printf(m, unused);
else
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: rc6 in sysfs
On Wed, Apr 11, 2012 at 11:10:05PM +0100, Chris Wilson wrote:
On Wed, 11 Apr 2012 09:14:43 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I'm down to just bikeshedding over useless lines of code which do not
even add visual clarity...
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Oops, need to learn to spot 64-bit divides which become an issue on
32-bit builds.
Squashed onto Ben's patch and updated dinq pushed.
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 2319f06..f1b5108 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -35,14 +35,12 @@ static u32 calc_residency(struct drm_device *dev, const
u32 reg)
{
struct drm_i915_private *dev_priv = dev-dev_private;
u64 raw_time; /* 32b value may overflow during fixed point math */
- u32 residency;
if (!intel_enable_rc6(dev))
return 0;
- raw_time = I915_READ(reg) * 128ULL;
- residency = DIV_ROUND_CLOSEST(raw_time, 1000) / 100;
- return residency;
+ raw_time = I915_READ(reg) * 128ULL + 500;
+ return do_div(raw_time, 10);
}
static ssize_t
--
1.7.9.5
--
Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [3.2.y] Re: [PATCH] drm/i915: mask transcoder select bits before setting them on LVDS
Hi Greg, Keith Packard wrote: On Thu, 12 Jan 2012 14:51:17 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: The transcoder port may changed from mode set to mode set, so make sure to mask out the selection bits before setting the right ones or we'll get black screens when going from transcoder B to A. Reviewed-by: Keith Packard kei...@keithp.com Merged: a190d70..7885d20 drm-intel-fixes - drm-intel-fixes Please queue 7885d2052bd9 drm/i915: mask transcoder select bits before setting them on LVDS, 2012-01-12 for inclusion in the 3.2.y tree. Bisects[1] to v3.2-rc1~135^2~2^2~17 (drm/i915: add PLL sharing support to handle 3 pipes) so 3.1.y and earlier are not affected. Fixed between v3.3-rc1 and -rc2 so 3.3.y is not affected, either. Jakob (cc-ed) confirmed[2] that the patch helps. The author acked it for inclusion in stable[3]. Thanks, Jonathan [1] http://lists.freedesktop.org/archives/intel-gfx/2012-January/014316.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=65;bug=660394 [3] http://thread.gmane.org/gmane.linux.ubuntu.bugs.general/3173872/focus=3189969 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] Re: [PATCH] drm/i915: mask transcoder select bits before setting them on LVDS
Greg KH wrote: Argh, it just missed the cutoff for the next 3.2-stable release, sorry, this will have to wait for the next one, the build machines are already underway at the moment with the tests... No problem. As long as it enters the tree soonish, I'm happy. :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request
This fixes a regression introduce in
commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Mar 21 10:48:18 2012 +
drm/i915: Mark untiled BLT commands as fenced on gen2/3
which fixed fencing tracking for untiled blt commands.
A side effect of that patch was that now also untiled objects have a
non-zero obj-last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.
Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv-next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj-last_fenced_seqno from before the suspend.
The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.
Reported-and-tested-by: Rafael J. Wysocki r...@sisk.pl
Cc: Jiri Slaby jsl...@suse.cz
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 71934dd..cf50fbc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1415,6 +1415,7 @@ i915_gem_object_move_off_active(struct
drm_i915_gem_object *obj)
{
list_del_init(obj-ring_list);
obj-last_rendering_seqno = 0;
+ obj-last_fenced_seqno = 0;
}
static void
@@ -1443,6 +1444,7 @@ i915_gem_object_move_to_inactive(struct
drm_i915_gem_object *obj)
BUG_ON(!list_empty(obj-gpu_write_list));
BUG_ON(!obj-active);
obj-ring = NULL;
+ obj-last_fenced_ring = NULL;
i915_gem_object_move_off_active(obj);
obj-fenced_gpu_access = false;
--
1.7.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring requests
This fixes a regression uncovered by
commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Mar 21 10:48:18 2012 +
drm/i915: Mark untiled BLT commands as fenced on gen2/3
which fixed fencing tracking for untiled blt commands.
A side effect of that patch was that now also untiled objects have a
non-zero obj-last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.
Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv-next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj-last_fenced_seqno from before the suspend.
The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.
Reported-and-tested-by: Rafael J. Wysocki r...@sisk.pl
Cc: Jiri Slaby jsl...@suse.cz
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 71934dd..cf50fbc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1415,6 +1415,7 @@ i915_gem_object_move_off_active(struct
drm_i915_gem_object *obj)
{
list_del_init(obj-ring_list);
obj-last_rendering_seqno = 0;
+ obj-last_fenced_seqno = 0;
}
static void
@@ -1443,6 +1444,7 @@ i915_gem_object_move_to_inactive(struct
drm_i915_gem_object *obj)
BUG_ON(!list_empty(obj-gpu_write_list));
BUG_ON(!obj-active);
obj-ring = NULL;
+ obj-last_fenced_ring = NULL;
i915_gem_object_move_off_active(obj);
obj-fenced_gpu_access = false;
--
1.7.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: clear fencing tracking state when retiring request
On Thu, 12 Apr 2012 01:27:57 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: This fixes a regression introduce in s/introduce/introduced/ commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Mar 21 10:48:18 2012 + drm/i915: Mark untiled BLT commands as fenced on gen2/3 which fixed fencing tracking for untiled blt commands. A side effect of that patch was that now also untiled objects have a non-zero obj-last_fenced_seqno to track when a fence can be set up after a pipelined tiling change. Unfortunately this was only cleared by the fence setup and teardown code, resulting in tons of untiled but inactive objects with non-zero last_fenced_seqno. Now after resume we completely reset the seqno tracking, both on the driver side (by setting dev_priv-next_seqno = 1) and on the hw side (by allocating a new hws page, which contains the seqnos). Hilarity and indefinite waits ensued from the stale seqnos in obj-last_fenced_seqno from before the suspend. The fix is to properly clear the fencing tracking state like we already do for the normal gpu rendering while moving objects off the active list. Reported-and-tested-by: Rafael J. Wysocki r...@sisk.pl Cc: Jiri Slaby jsl...@suse.cz Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch I spent sometime discussing whether or not we could hit a similar bug with a well placed change of tiling after resume, and the outcome is that as the fences are reset during freeze then all tiled objects that had been used for rendering would have been flushed (and their last_fenced_seqno set to 0). So this is a new regression caused by the aforementioned patch and this is the cleanest fix, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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] [PATCH 00/14] intel_ringbuffer.c reorg + cleanups
On Wed, 11 Apr 2012 22:12:45 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, This patch series is inspired by Ben's ring-get|put_irq cleanup for gen6+ and my perpetual hatred for intel_ringbuffer.c. It's a lot of churn, but the end result is imho worth it - I almost started to like what the ringbuffer abstraction looks like now. There are some follow-up cleanups possible, but I think that can wait until we've cleanup up our domain tracking and ripped out the flushing_list (if that ever happens). Commments, flames and review highly welcome. This is so nice. It's way better than the series I started with when working on domain tracking lobotomy. Except for a s/bds/bsd/ in patch 4's commit message, Reviewed-by: Eric Anholt e...@anholt.net pgp3dSkP2uIno.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] (no subject)
There are many bugs open on fd.o regarding missing modes that are supported on
Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor
allows it trough range limited flag... obviously limiting by the range.
From our code:
* EDID spec says modes should be preferred in this order:
* - preferred detailed mode
* - other detailed modes from base block
* - detailed modes from extension blocks
* - CVT 3-byte code modes
* - standard timing codes
* - established timing codes
* - modes inferred from GTF or CVT range information
*
* We get this pretty much right.
Not actually so right... We were inferring just using GTF... not CVT or even
GTF2.
This patch not just add some common cvt modes but also allows some modes been
inferred when using gtf2 as well.
Cheers,
Rodrigo.
From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi rodrigo.v...@intel.com
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
allows range limited ones trough EDID.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/drm_edid.c | 37 +-
drivers/gpu/drm/drm_edid_modes.h | 101 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector
*connector, struct edid *edid,
return modes;
}
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+ struct detailed_timing *timing)
+{
+ int i, modes = 0;
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+
+ for (i = 0; i drm_num_cvt_inferred_modes; i++) {
+ if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+ newmode = drm_mode_duplicate(dev,
drm_cvt_inferred_modes[i]);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+
+ return modes;
+}
+
static void
do_inferred_modes(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = timing-data.other_data;
- int gtf = (closure-edid-features DRM_EDID_FEATURE_DEFAULT_GTF);
+ int timing_level = standard_timing_level(closure-edid);
- if (gtf data-type == EDID_DETAIL_MONITOR_RANGE)
+ if (data-type == EDID_DETAIL_MONITOR_RANGE)
+ switch (timing_level) {
+ case LEVEL_DMT:
+ break;
+ case LEVEL_GTF:
+ case LEVEL_GTF2:
closure-modes += drm_gtf_modes_for_range(closure-connector,
closure-edid,
timing);
+ break;
+ case LEVEL_CVT:
+ closure-modes += drm_cvt_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
+ break;
+ }
}
static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+ /* 640x480@60Hz */
+ { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 23750 640, 664,
+ 720, 800, 0, 480, 483, 487, 500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 800x600@60Hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+ 912, 1024, 0, 600, 603, 607, 624, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 900x600@60Hz */
+ { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+ 1088, 1216, 0, 600, 603, 609, 624, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 1024x576@60Hz */
+ { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+ 1160, 1296, 0, 576, 579, 584, 599, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 1024x768@60Hz */
+ { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+ 1176, 1328, 0, 768, 771, 775, 798, 0,
+
[Intel-gfx] (no subject)
There are many bugs open on fd.o regarding missing modes that are supported on
Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor
allows it trough range limited flag... obviously limiting by the range.
From our code:
* EDID spec says modes should be preferred in this order:
* - preferred detailed mode
* - other detailed modes from base block
* - detailed modes from extension blocks
* - CVT 3-byte code modes
* - standard timing codes
* - established timing codes
* - modes inferred from GTF or CVT range information
*
* We get this pretty much right.
Not actually so right... We were inferring just using GTF... not CVT or even
GTF2.
This patch not just add some common cvt modes but also allows some modes been
inferred when using gtf2 as well.
Cheers,
Rodrigo.
From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi rodrigo.v...@intel.com
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
allows range limited ones trough EDID.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/drm_edid.c | 37 +-
drivers/gpu/drm/drm_edid_modes.h | 101 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector
*connector, struct edid *edid,
return modes;
}
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+ struct detailed_timing *timing)
+{
+ int i, modes = 0;
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+
+ for (i = 0; i drm_num_cvt_inferred_modes; i++) {
+ if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+ newmode = drm_mode_duplicate(dev,
drm_cvt_inferred_modes[i]);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+
+ return modes;
+}
+
static void
do_inferred_modes(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = timing-data.other_data;
- int gtf = (closure-edid-features DRM_EDID_FEATURE_DEFAULT_GTF);
+ int timing_level = standard_timing_level(closure-edid);
- if (gtf data-type == EDID_DETAIL_MONITOR_RANGE)
+ if (data-type == EDID_DETAIL_MONITOR_RANGE)
+ switch (timing_level) {
+ case LEVEL_DMT:
+ break;
+ case LEVEL_GTF:
+ case LEVEL_GTF2:
closure-modes += drm_gtf_modes_for_range(closure-connector,
closure-edid,
timing);
+ break;
+ case LEVEL_CVT:
+ closure-modes += drm_cvt_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
+ break;
+ }
}
static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+ /* 640x480@60Hz */
+ { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 23750 640, 664,
+ 720, 800, 0, 480, 483, 487, 500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 800x600@60Hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+ 912, 1024, 0, 600, 603, 607, 624, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 900x600@60Hz */
+ { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+ 1088, 1216, 0, 600, 603, 609, 624, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 1024x576@60Hz */
+ { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+ 1160, 1296, 0, 576, 579, 584, 599, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 1024x768@60Hz */
+ { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+ 1176, 1328, 0, 768, 771, 775, 798, 0,
+
[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.
There are many bugs open on fd.o regarding missing modes that are supported on
Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor
allows it trough range limited flag... obviously limiting by the range.
From our code:
* EDID spec says modes should be preferred in this order:
* - preferred detailed mode
* - other detailed modes from base block
* - detailed modes from extension blocks
* - CVT 3-byte code modes
* - standard timing codes
* - established timing codes
* - modes inferred from GTF or CVT range information
*
* We get this pretty much right.
Not actually so right... We were inferring just using GTF... not CVT or even
GTF2.
This patch not just add some common cvt modes but also allows some modes been
inferred when using gtf2 as well.
Cheers,
Rodrigo.
From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi rodrigo.v...@intel.com
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
allows range limited ones trough EDID.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/drm_edid.c | 37 +-
drivers/gpu/drm/drm_edid_modes.h | 101 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector
*connector, struct edid *edid,
return modes;
}
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+ struct detailed_timing *timing)
+{
+ int i, modes = 0;
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+
+ for (i = 0; i drm_num_cvt_inferred_modes; i++) {
+ if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+ newmode = drm_mode_duplicate(dev,
drm_cvt_inferred_modes[i]);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+
+ return modes;
+}
+
static void
do_inferred_modes(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = timing-data.other_data;
- int gtf = (closure-edid-features DRM_EDID_FEATURE_DEFAULT_GTF);
+ int timing_level = standard_timing_level(closure-edid);
- if (gtf data-type == EDID_DETAIL_MONITOR_RANGE)
+ if (data-type == EDID_DETAIL_MONITOR_RANGE)
+ switch (timing_level) {
+ case LEVEL_DMT:
+ break;
+ case LEVEL_GTF:
+ case LEVEL_GTF2:
closure-modes += drm_gtf_modes_for_range(closure-connector,
closure-edid,
timing);
+ break;
+ case LEVEL_CVT:
+ closure-modes += drm_cvt_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
+ break;
+ }
}
static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+ /* 640x480@60Hz */
+ { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 23750 640, 664,
+ 720, 800, 0, 480, 483, 487, 500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 800x600@60Hz */
+ { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+ 912, 1024, 0, 600, 603, 607, 624, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 900x600@60Hz */
+ { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+ 1088, 1216, 0, 600, 603, 609, 624, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 1024x576@60Hz */
+ { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+ 1160, 1296, 0, 576, 579, 584, 599, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+ /* 1024x768@60Hz */
+ { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+ 1176, 1328, 0, 768, 771, 775, 798, 0,
+
Re: [Intel-gfx] [PATCH] drm/i915: Fix invalid backpanel values for GEN3 or older chips
Hello! I know this is an old thread, but i am having this problem on my macbook air. Ideas for a quick fix? Thanks, James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
