Re: [Intel-gfx] [PATCH 1/2] BDW: Adding Reserved PCI IDs.
On Tue, Jun 10, 2014 at 10:15:38AM -0700, Rodrigo Vivi wrote: These PCI IDs are reserved on BSpec and can be used at any time in the future. So let's add this now in order to avoid issues that we already faced on previous platforms, like finding out about new ids when user reported accelaration weren't enabled. I'm going to hold off applying this until the kernel patch lands (and we can cite its commit). It is much easier if this file remains a duplicate. -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] Access to B-spec for DevSNB
Hey, With regard to this commit: http://lists.freedesktop.org/archives/intel-gfx/2012-December/023210.html How can I get access to this B-Spec document? Thanks, Nick -- [Intel-gfx] [PATCH 1/2] drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled Quoting from Bspec, 3D_CHICKEN1, bit 10 This bit needs to be set always to 1, Project: DevSNB Signed-off-by: Daniel Vetter daniel.vetter at ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sluggish performance after resume//Re: Bug Report - [Acer Aspire V5-122P] Unable to adjust screen brightness
On 06/11/2014 06:54 AM, Ben Widawsky wrote: On Tue, Jun 10, 2014 at 08:59:32PM +0100, Lewis Toohey wrote: On 10 June 2014 17:58, Ben Widawsky b...@bwidawsk.net wrote: On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: +Ben Widawsky Daniel Vetter On 06/09/2014 03:38 PM, Lewis Toohey wrote: Hi Aaron Firstly, yes the sluggish performance I was referring to is experienced in the GUI environment. Jerky graphics and CPU fan appears to max out and stay there. Old kernels (e.g. the Ubuntu default kernel) do not do this and just restore perfectly. I have completed the bisect as requested. Please find the full log below. I am slightly unconvinced, as building the previous commit in the log still seems to have the same problem, however, that commit is a merge and I don't really know what this means. Many thanks Bisect Log: git bisect start # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] include/linux/syscalls.h: add sys_renameat2() prototype git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix indenting in ncp_lookup() git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly return the vma from bind_to_vm git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement WaIncreaseL3CreditsForVLVB0:vlv git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the Global GTT VM first in the list of VM git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize PPGTT init git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax context alignment git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to error BO capture git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt lookups to not WARN git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't unconditionally try to deref aliasing ppgtt git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO The commit looks like related, I've added the commit author. Ben, Do you have any suggestions? Does the above commit have any chance of causing sluggish performance problem after a resume? What this comment actually does is use MMIO writes for the page tables after a GPU hang/reset. (What a poorly named commit message). Can you please provide the full dmesg with the drm.debug=0x2? Hi Ben Thank you for responding. Just to verify that I have done this correctly, I added drm.debug=0x2 to the kernel command line (in Grub), booted, suspended and resumed, and then ran Dmesg. I wasn't sure exactly where to put it, so please find a copy of the output here: http://www.toohey.co.uk/dmesg I hope that is helpful. If you need any further information please let me know. Many thanks I only see radeon stuff in that dmesg. But you did the right thing to grub. Oh yes, this is a AMD graphics card so the bisected commit can't be the culprit. No ideas now, Lewis, I'm afraid you will need try harder to find the bad commit. Thanks, Aaron ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] How to debug GTT/PTE errors?
Dear Linux folks, although there are no user visible issues, there is still the following error message in the log. [1.235596] i915: render error detected, EIR: 0x0010 [1.235596] i915: page table error [1.235596] i915: PGTBL_ER: 0x0012 [1.235596] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking [1.235596] i915: render error detected, EIR: 0x0010 [1.235596] i915: page table error [1.235596] i915: PGTBL_ER: 0x0012 [1.310633] [drm:intel_modeset_init], 2 display pipes available. The intel-gpu-tools [6] include the program `intel-error-decode`, which give the following. $ ./intel_error_decode /tmp/5927_7/error Time: 1402269737 s 277725 us Kernel: 3.14.4-gnuowen PCI ID: 0x27a2 Detected GEN3 chipset EIR: 0x0010 IER: 0x00028053 PGTBL_ER: 0x0012 Display A: Invalid GTT PTE Host Invalid PTE data […] Is there an option that the GTT is dumped on such an error or the addresses are shown in the logs to exactly see where in memory the problem is? Thanks, Paul [1] http://www.coreboot.org/pipermail/coreboot/2014-June/078092.html [6] http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ 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 2/2] drm/i915/vlv: Set D3_hot for vlv during runtime_suspend
This patch can be marked as abandoned.
Have verified locally that pci driver is taking care of D0ix transitions
and state save/restore.
Thanks Imre for the clarification.
On Tue, 2014-06-10 at 20:51 +0300, Imre Deak wrote:
On Tue, 2014-06-10 at 23:05 +0530, Sagar Arun Kamble wrote:
On Tue, 2014-06-10 at 15:43 +0300, Imre Deak wrote:
On Tue, 2014-06-10 at 00:27 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
To do a platform wide S0i3 transition, Gfx is required to go
to D3_hot state. pci_save_state and pci_restore_state needed to avoid
ring
hangs across D3_hot transitions.
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM
DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM
DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 5a08c86..70bb456 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1412,6 +1412,11 @@ static int intel_runtime_suspend(struct device
*device)
* via the suspend path.
*/
intel_opregion_notify_adapter(dev, PCI_D1);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+ }
DRM_DEBUG_KMS(Device suspended\n);
return 0;
@@ -1428,6 +1433,12 @@ static int intel_runtime_resume(struct device
*device)
DRM_DEBUG_KMS(Resuming device\n);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_device(pdev);
+ }
Setting the proper Dx state and saving/restoring the PCI config space is
already done for us by the PCI runtime PM framework, see
pci_pm_runtime_suspend/resume().
Where exactly it calls pci_pm_set_powerstate to set D3_hot ?
It's
pci_pm_runtime_suspend()-pci_finish_runtime_suspend()-pci_set_power_state()
.
There seems to be bug in the pci driver in the suspend path. it is not
saving the pci configuration space although code for same exists.
pci driver checks if client driver has saved if not it will exit from
suspend path.
check the code snippet below:
if (!pci_dev-state_saved pci_dev-current_state != PCI_D0
pci_dev-current_state != PCI_UNKNOWN) {
WARN_ONCE(pci_dev-current_state != prev,
PCI PM: State of device not saved by %pF\n,
pm-runtime_suspend);
return 0;
}
if (!pci_dev-state_saved) {
pci_save_state(pci_dev);
pci_finish_runtime_suspend(pci_dev);
}
I don't think this is a bug, but something the PCI framework requires
from drivers. That is if they set the power state to something else than
PCI_D0 or PCI_UNKNOWN they also have to save the state themselves.
I can't check this right now, but I haven't ever seen the above WARN and
by the look of it we are doing the right thing in the driver. That is
leave the power state in D0 and let the PCI framework handle the state
saving/power state transitioning.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] Documentation/drm: Describing aspect ratio property
Updated drm documentation to include desscription of aspect ratio property.
v2: Updated aspect ratio specific documentation on top of the HTML table
created.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: Sagar Kamble sagar.a.kam...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
Documentation/DocBook/drm.tmpl | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7df3134..3e98151 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2502,7 +2502,7 @@ void intel_crt_init(struct drm_device *dev)
td valign=top Description/Restrictions/td
/tr
tr
- td rowspan=20 valign=top DRM/td
+ td rowspan=21 valign=top DRM/td
td rowspan=2 valign=top Generic/td
td valign=top “EDID”/td
td valign=top BLOB | IMMUTABLE/td
@@ -2633,7 +2633,7 @@ void intel_crt_init(struct drm_device *dev)
td valign=top TBD/td
/tr
tr
- td rowspan=2 valign=top Optional/td
+ td rowspan=3 valign=top Optional/td
td valign=top “scaling mode”/td
td valign=top ENUM/td
td valign=top { None, Full, Center, Full aspect }/td
@@ -2641,6 +2641,15 @@ void intel_crt_init(struct drm_device *dev)
td valign=top TBD/td
/tr
tr
+ td valign=top aspect ratio/td
+ td valign=top ENUM/td
+ td valign=top { None, 4:3, 16:9 }/td
+ td valign=top Connector/td
+ td valign=top DRM property to set aspect ratio from user space app.
+ This enum is made generic to allow addition of custom aspect
+ ratios./td
+ /tr
+ tr
td valign=top “dirty”/td
td valign=top ENUM | IMMUTABLE/td
td valign=top { Off, On, Annotate }/td
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3
On Tue, Jun 10, 2014 at 12:45:38PM -0700, Jesse Barnes wrote:
On Tue, 10 Jun 2014 21:33:27 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yes, that's what I do below... I even added it to the changelog:
http://patchwork.freedesktop.org/patch/27223/
Did you miss the later hunk in intel_display.c?
What we try to do here is enable swizzling if possible, which we can do
if no inherited fbs are tiled.
So I think I've done exactly what you repeated above, and documented
it. So you're going to need to repeat it with different words so I can
understand, if I'm still missing something.
In swizzle_detect:
...
if (GEN6+) {
if (preserve_bios_swizzle) {
if (I915_READ(DISP_ARB_CTL) DISP_TILE_SURFACE_SWIZZLING) {
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
...
} else {
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
...
}
} else {
/* existing/old logic to decide about swizzling */
}
}
...
Plus no shortcut in i915_gem_init_swizzling. Personally I'd also just use
a small helper function to compute preserve_bios_swizzle instead of
storing it in dev_priv (since we will only use it at exactly one place),
but that's a pure style preference.
Doesn't this amount to the same thing? I.e. we enable it if possible,
otherwise just report it as unswizzled? So you're just wanting a style
change here?
So presuming I read your code correctly there's two issues:
- The first thing you check in swizzle_detect is the hw swizzle bit in
DSP_ARB. If that's not set you force unswizzled. Since most BIOS don't
bother to set this (they use an untiled buffer after all) this means
you've effectively disabled swizzling on almost all machines. The goal
of keeping the old logic was that we actually want to enable swizzling
in some situations.
- If you have a machine which uses tiled framebuffers and enables
swizzling in the BIOS your code will a) drop the swizzle setup in
gem_init_hw, breaking resume b) not set the swizzle settings correctly
in swizzle_detect, breaking swap in/out and pwrite/pread. Not sure such
a machine exists, but still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default
On Tue, Jun 10, 2014 at 11:42:37AM -0700, Jesse Barnes wrote:
On Tue, 10 Jun 2014 11:01:06 -0700
Stéphane Marchesin stephane.marche...@gmail.com wrote:
On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Tue, 10 Jun 2014 16:07:44 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
Let them eat mincemeat pie.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index d05a2af..081ab2f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
.preliminary_hw_support =
IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
.disable_power_well = 1,
.enable_ips = 1,
- .fastboot = 0,
+ .fastboot = 42,
.prefault_disable = 0,
.reset = true,
.invert_brightness = 0,
@@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, Enable IPS (default:
true));
module_param_named(fastboot, i915.fastboot, bool, 0600);
MODULE_PARM_DESC(fastboot,
- Try to skip unnecessary mode sets at boot time (default: false));
+ Try to skip unnecessary mode sets at boot time (default: true));
Nah, that wasn't the intention of this option. It was meant as a hack to
experiment around with fastboot and get things going, but imo we need to
really do the full modeset and short-circuit if the state matches.
And there's still a bunch of things we don't track like infoframes which
we either need to fix up (similar to the pfit fixup) or quirk to disallow
fastboot.
Hm that contradicts our earlier discussions w/Damien when we decided
the infoframes stuff were too esoteric to matter...
I'm pretty sure I've never claimed that infoframes are too esoteric. Like
Stéphane mentions they're really good at breaking shitty TVs and resulting
in black screens.
My 2 cents is that I've seen some really bad TVs which didn't work
because infoframes were missing (IIRC it relied on the VIC to detect
the video mode).
Yeah so we'd still leave them in place in this case, and apply them on
the next mode set as well, but we wouldn't be explicitly cross checking
for them, at least not yet.
It's a good thing to add, I just didn't think it was a blocker based on
our last discussion about this.
Imo we should quirk hdmi and prevent fastboot exactly because infoframes
are such a pain. Relying on the BIOS for the just means we'll loose a lot
of testing coverage on random screens out there, which I very much want to
avoid.
Another piece of state we don't fix up atm is sound. Since my latest
rework this is tracked in the pipe config, so at least we'll catch that.
Also iirc Chris complained about the modeset state checker overhead caused
by the fastboot option since a normal flip done through setCrtc now hits
that unconditionally. If we'd push the fastboot logic into the overall
modeset path we could restrict modeset state checks to only when we need
them.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] Documentation/drm: Describing aspect ratio property
Reviewed-by: Sagar Kamble sagar.a.kam...@intel.com
On Wed, 2014-06-11 at 14:33 +0530, Vandana Kannan wrote:
Updated drm documentation to include desscription of aspect ratio property.
v2: Updated aspect ratio specific documentation on top of the HTML table
created.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: Sagar Kamble sagar.a.kam...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
Documentation/DocBook/drm.tmpl | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7df3134..3e98151 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2502,7 +2502,7 @@ void intel_crt_init(struct drm_device *dev)
td valign=top Description/Restrictions/td
/tr
tr
- td rowspan=20 valign=top DRM/td
+ td rowspan=21 valign=top DRM/td
td rowspan=2 valign=top Generic/td
td valign=top “EDID”/td
td valign=top BLOB | IMMUTABLE/td
@@ -2633,7 +2633,7 @@ void intel_crt_init(struct drm_device *dev)
td valign=top TBD/td
/tr
tr
- td rowspan=2 valign=top Optional/td
+ td rowspan=3 valign=top Optional/td
td valign=top “scaling mode”/td
td valign=top ENUM/td
td valign=top { None, Full, Center, Full aspect }/td
@@ -2641,6 +2641,15 @@ void intel_crt_init(struct drm_device *dev)
td valign=top TBD/td
/tr
tr
+ td valign=top aspect ratio/td
+ td valign=top ENUM/td
+ td valign=top { None, 4:3, 16:9 }/td
+ td valign=top Connector/td
+ td valign=top DRM property to set aspect ratio from user space app.
+ This enum is made generic to allow addition of custom aspect
+ ratios./td
+ /tr
+ tr
td valign=top “dirty”/td
td valign=top ENUM | IMMUTABLE/td
td valign=top { Off, On, Annotate }/td
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Access to B-spec for DevSNB
On Wed, Jun 11, 2014 at 06:52:15AM +, Nicolae Badiu wrote: Hey, With regard to this commit: http://lists.freedesktop.org/archives/intel-gfx/2012-December/023210.html How can I get access to this B-Spec document? The public documents are here: https://01.org/linuxgraphics/documentation/driver-documentation-prms -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: Set D3_hot for vlv during runtime_suspend
On Wed, Jun 11, 2014 at 01:53:49PM +0530, Sagar Arun Kamble wrote:
This patch can be marked as abandoned.
Have verified locally that pci driver is taking care of D0ix transitions
and state save/restore.
That still leaves the question why you originally thought this is
required. What did blow up here in your testing?
Thanks, Daniel
Thanks Imre for the clarification.
On Tue, 2014-06-10 at 20:51 +0300, Imre Deak wrote:
On Tue, 2014-06-10 at 23:05 +0530, Sagar Arun Kamble wrote:
On Tue, 2014-06-10 at 15:43 +0300, Imre Deak wrote:
On Tue, 2014-06-10 at 00:27 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
To do a platform wide S0i3 transition, Gfx is required to go
to D3_hot state. pci_save_state and pci_restore_state needed to avoid
ring
hangs across D3_hot transitions.
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM
DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM
DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 5a08c86..70bb456 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1412,6 +1412,11 @@ static int intel_runtime_suspend(struct device
*device)
* via the suspend path.
*/
intel_opregion_notify_adapter(dev, PCI_D1);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+ }
DRM_DEBUG_KMS(Device suspended\n);
return 0;
@@ -1428,6 +1433,12 @@ static int intel_runtime_resume(struct device
*device)
DRM_DEBUG_KMS(Resuming device\n);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_device(pdev);
+ }
Setting the proper Dx state and saving/restoring the PCI config space is
already done for us by the PCI runtime PM framework, see
pci_pm_runtime_suspend/resume().
Where exactly it calls pci_pm_set_powerstate to set D3_hot ?
It's
pci_pm_runtime_suspend()-pci_finish_runtime_suspend()-pci_set_power_state()
.
There seems to be bug in the pci driver in the suspend path. it is not
saving the pci configuration space although code for same exists.
pci driver checks if client driver has saved if not it will exit from
suspend path.
check the code snippet below:
if (!pci_dev-state_saved pci_dev-current_state != PCI_D0
pci_dev-current_state != PCI_UNKNOWN) {
WARN_ONCE(pci_dev-current_state != prev,
PCI PM: State of device not saved by %pF\n,
pm-runtime_suspend);
return 0;
}
if (!pci_dev-state_saved) {
pci_save_state(pci_dev);
pci_finish_runtime_suspend(pci_dev);
}
I don't think this is a bug, but something the PCI framework requires
from drivers. That is if they set the power state to something else than
PCI_D0 or PCI_UNKNOWN they also have to save the state themselves.
I can't check this right now, but I haven't ever seen the above WARN and
by the look of it we are doing the right thing in the driver. That is
leave the power state in D0 and let the PCI framework handle the state
saving/power state transitioning.
--Imre
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DevSNB PCI Config Space Registers Reference
On Tue, Jun 10, 2014 at 03:51:03PM +, Nicolae Badiu wrote: Hi, Does anyone have access to the Sandy Bridge 2011 Intel HD Graphics PCI Config space register reference? I cannot seem to find it anywhere in the PRM docs. There is only a reference to a register called MMAPA at office 14h in all DevSNB manuals. I do see PCI config space documentation for Ivy Bridge and Haswell Intel HD Graphics. Yeah, this was missed in the snb release. Otherwise, pointing me in the right direction w/ regard to the drm-intel source code would also help. They are sprinkled all over a bit, and we definitely don't have an exhaustive set of #defines. If you need something specific and interpolation with ivb/hsw docs doesn't work, please just ping us. Usually best on irc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Access to B-spec for DevSNB
Thanks Ville, The commit I mentioned below talks about a register at location 2084h. This location is marked as Reserved in the DevSNB PRM docs and only referenced once in reference to bit 2084h[7]. It seems to be some sort of a debug register. I can also see three more subsequent registers at 208ch a.s.o., so I imagine all of this stuff must be documented in this so-called B-Spec (which I am unable to locate on the website). Thanks, Nick Date: Wed, 11 Jun 2014 13:07:04 +0300 From: ville.syrj...@linux.intel.com To: acav...@outlook.com CC: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] Access to B-spec for DevSNB On Wed, Jun 11, 2014 at 06:52:15AM +, Nicolae Badiu wrote: Hey, With regard to this commit: http://lists.freedesktop.org/archives/intel-gfx/2012-December/023210.html How can I get access to this B-Spec document? The public documents are here: https://01.org/linuxgraphics/documentation/driver-documentation-prms -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check the minimum pitch for the user framebuffer
On Tue, Jun 10, 2014 at 10:22:33PM +0100, Chris Wilson wrote:
Compute the smallest pitch required for a linear framebuffer and assert
that the user has declared a pitch that meets that minimum requirement.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cc62b140eb1c..ef34badbe69c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11808,6 +11808,8 @@ static int intel_framebuffer_init(struct drm_device
*dev,
{
int aligned_height;
int pitch_limit;
+ int depth;
+ int bpp;
int ret;
WARN_ON(!mutex_is_locked(dev-struct_mutex));
@@ -11823,6 +11825,15 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return -EINVAL;
}
+ drm_fb_get_bpp_depth(mode_cmd-pixel_format, bpp, depth);
+ if (mode_cmd-pitches[0]
intel_framebuffer_pitch_for_width(mode_cmd-width,
+ bpp)) {
Won't this foul up universal planes? Iirc we have a minimal pitch of 128b
somewhere, but cursors are happy with 64. Also not sure about
overlays/planes.
If this blows up I guess we need to patch up the setplane/cursor functions
correctly.
-Daniel
+ DRM_DEBUG(pitch (%d) must be at least the linear stride
(%d)\n,
+ mode_cmd-pitches[0],
+ intel_framebuffer_pitch_for_width(mode_cmd-width,
bpp));
+ return -EINVAL;
+ }
+
if (INTEL_INFO(dev)-gen = 5 !IS_VALLEYVIEW(dev)) {
pitch_limit = 32*1024;
} else if (INTEL_INFO(dev)-gen = 4) {
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Make the physical object coherent with GTT
Currently objects for which the hardware needs a contiguous physical
address are allocated a shadow backing storage to satisfy the contraint.
This shadow buffer is not wired into the normal obj-pages and so the
physical object is incoherent with accesses via the GPU, GTT and CPU. By
setting up the appropriate scatter-gather table, we can allow userspace
to access the physical object via either a GTT mmaping of or by rendering
into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
storage coherent with the contiguous shadow is not yet possible.
Fortuituously, CPU mmaps of objects requiring physical addresses are not
expected to be coherent anyway.
This allows the physical constraint of the GEM object to be transparent
to userspace and allow it to efficiently render into or update them via
the GTT and GPU.
v2: Fix leak of pci handle spotted by Ville
v3: Remove the now duplicate call to detach_phys_object during free.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_gem.c | 199 +++-
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 142 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 59e8ffe230a7..b1f072039865 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1025,6 +1025,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_CMD_PARSER_VERSION:
value = i915_cmd_parser_get_version();
break;
+ case I915_PARAM_HAS_COHERENT_PHYS_GTT:
+ value = 1;
+ break;
default:
DRM_DEBUG(Unknown parameter %d\n, param-param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0a9d1b85d529..c80ddcf8aa6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1715,10 +1715,10 @@ struct drm_i915_gem_object {
unsigned long user_pin_count;
struct drm_file *pin_filp;
- /** for phy allocated objects */
- drm_dma_handle_t *phys_handle;
-
union {
+ /** for phy allocated objects */
+ drm_dma_handle_t *phys_handle;
+
struct i915_gem_userptr {
uintptr_t ptr;
unsigned read_only :1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 25b5063388b2..6e8535ba72d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -209,40 +209,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
return 0;
}
-static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
+static int
+i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
{
- drm_dma_handle_t *phys = obj-phys_handle;
+ struct address_space *mapping = file_inode(obj-base.filp)-i_mapping;
+ char *vaddr = obj-phys_handle-vaddr;
+ struct sg_table *st;
+ struct scatterlist *sg;
+ int i;
- if (!phys)
- return;
+ if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
+ return -EINVAL;
+
+ for (i = 0; i obj-base.size / PAGE_SIZE; i++) {
+ struct page *page;
+ char *src;
+
+ page = shmem_read_mapping_page(mapping, i);
+ if (IS_ERR(page))
+ return PTR_ERR(page);
+
+ src = kmap_atomic(page);
+ memcpy(vaddr, src, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
+ kunmap_atomic(src);
+
+ page_cache_release(page);
+ vaddr += PAGE_SIZE;
+ }
+
+ i915_gem_chipset_flush(obj-base.dev);
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (st == NULL)
+ return -ENOMEM;
+
+ if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+ kfree(st);
+ return -ENOMEM;
+ }
- if (obj-madv == I915_MADV_WILLNEED) {
+ sg = st-sgl;
+ sg-offset = 0;
+ sg-length = obj-base.size;
+
+ sg_dma_address(sg) = obj-phys_handle-busaddr;
+ sg_dma_len(sg) = obj-base.size;
+
+ obj-pages = st;
+ obj-has_dma_mapping = true;
+ return 0;
+}
+
+static void
+i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj)
+{
+ int ret;
+
+ BUG_ON(obj-madv == __I915_MADV_PURGED);
+
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret) {
+ /* In the event of a disaster, abandon all caches and
+* hope for the best.
+*/
+ WARN_ON(ret != -EIO);
+
[Intel-gfx] [PATCH] drm/i915: Refactor the physical and virtual page hws setup
We duplicated the legacy physical HWS setup routine for no good reason.
Combine it with the more recent virtual HWS setup for simplicity.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c | 16 +--
drivers/gpu/drm/i915/intel_ringbuffer.c | 81 -
2 files changed, 39 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b1f072039865..97a8c69e115b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -104,17 +104,6 @@ void i915_update_dri1_breadcrumb(struct drm_device *dev)
}
}
-static void i915_write_hws_pga(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- u32 addr;
-
- addr = dev_priv-status_page_dmah-busaddr;
- if (INTEL_INFO(dev)-gen = 4)
- addr |= (dev_priv-status_page_dmah-busaddr 28) 0xf0;
- I915_WRITE(HWS_PGA, addr);
-}
-
/**
* Frees the hardware status page, whether it's a physical address or a virtual
* address set up by the X Server.
@@ -255,10 +244,7 @@ static int i915_dma_resume(struct drm_device *dev)
}
DRM_DEBUG_DRIVER(hw status page @ %p\n,
ring-status_page.page_addr);
- if (ring-status_page.gfx_addr != 0)
- intel_ring_setup_status_page(ring);
- else
- i915_write_hws_pga(dev);
+ intel_ring_setup_status_page(ring);
DRM_DEBUG_DRIVER(Enabled hardware status page\n);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e4cb950b0f74..d5a888973ecc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -444,17 +444,6 @@ u64 intel_ring_get_active_head(struct intel_engine_cs
*ring)
return acthd;
}
-static void ring_setup_phys_status_page(struct intel_engine_cs *ring)
-{
- struct drm_i915_private *dev_priv = ring-dev-dev_private;
- u32 addr;
-
- addr = dev_priv-status_page_dmah-busaddr;
- if (INTEL_INFO(ring-dev)-gen = 4)
- addr |= (dev_priv-status_page_dmah-busaddr 28) 0xf0;
- I915_WRITE(HWS_PGA, addr);
-}
-
static bool stop_ring(struct intel_engine_cs *ring)
{
struct drm_i915_private *dev_priv = to_i915(ring-dev);
@@ -520,10 +509,7 @@ static int init_ring_common(struct intel_engine_cs *ring)
}
}
- if (I915_NEED_GFX_HWS(dev))
- intel_ring_setup_status_page(ring);
- else
- ring_setup_phys_status_page(ring);
+ intel_ring_setup_status_page(ring);
reset:
/* Initialize the ring. This must happen _after_ we've cleared the ring
@@ -1026,39 +1012,48 @@ void intel_ring_setup_status_page(struct
intel_engine_cs *ring)
{
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = ring-dev-dev_private;
- u32 mmio = 0;
+ u32 mmio, addr;
- /* The ring status page addresses are no longer next to the rest of
-* the ring registers as of gen7.
-*/
- if (IS_GEN7(dev)) {
- switch (ring-id) {
- case RCS:
- mmio = RENDER_HWS_PGA_GEN7;
- break;
- case BCS:
- mmio = BLT_HWS_PGA_GEN7;
- break;
- /*
-* VCS2 actually doesn't exist on Gen7. Only shut up
-* gcc switch check warning
+ if (!I915_NEED_GFX_HWS(dev)) {
+ addr = dev_priv-status_page_dmah-busaddr;
+ if (INTEL_INFO(ring-dev)-gen = 4)
+ addr |= (dev_priv-status_page_dmah-busaddr 28)
0xf0;
+ mmio = HWS_PGA;
+ } else {
+ addr = ring-status_page.gfx_addr;
+ /* The ring status page addresses are no longer next to the
rest of
+* the ring registers as of gen7.
*/
- case VCS2:
- case VCS:
- mmio = BSD_HWS_PGA_GEN7;
- break;
- case VECS:
- mmio = VEBOX_HWS_PGA_GEN7;
- break;
+ if (IS_GEN7(dev)) {
+ switch (ring-id) {
+ default:
+ case RCS:
+ mmio = RENDER_HWS_PGA_GEN7;
+ break;
+ case BCS:
+ mmio = BLT_HWS_PGA_GEN7;
+ break;
+ /*
+* VCS2 actually doesn't exist on Gen7. Only
shut up
+* gcc switch check warning
+*/
+ case VCS2:
+ case VCS:
+
Re: [Intel-gfx] Access to B-spec for DevSNB
On Wed, Jun 11, 2014 at 06:52:15AM +, Nicolae Badiu wrote: Hey, With regard to this commit: http://lists.freedesktop.org/archives/intel-gfx/2012-December/023210.html How can I get access to this B-Spec document? Bspec is the internal name for the published programmer manuals. It should be in there, but occasionally something gets lost in the public doc releases. -Daniel Thanks, Nick -- [Intel-gfx] [PATCH 1/2] drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled Quoting from Bspec, 3D_CHICKEN1, bit 10 This bit needs to be set always to 1, Project: DevSNB Signed-off-by: Daniel Vetter daniel.vetter at ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t 3/7] README: update the section on modifying and rebuilding documentation
On 10 June 2014 15:38, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jun 10, 2014 at 03:30:53PM +0100, Thomas Wood wrote: Signed-off-by: Thomas Wood thomas.w...@intel.com --- README | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/README b/README index cfa186d..5e98565 100644 --- a/README +++ b/README @@ -108,16 +108,14 @@ docs/ reference documenation in docs/reference/ You need to have the gtk doc tools installed to generate this API documentation. - Note that the currrent gtk-docs integration sucks a bit wrt regenerating - the html files. You need at least + To regenerate the html files when updating documentation, use: $ make clean -C docs make -C docs - to regenerate them on any change. If you've added/changed/removed a - symbol or anything else that changes the overall structure or indexes, - you need a full rebuild: - - $ git clean -dfx ./autogen.sh --enable-gtk-doc make -C docs This is still requried afaik when you add new .c/.h files with api docs in them. -Daniel Running make clean make is enough for symbols to be added or removed, even in new source files. The sections file will still need to be updated to reflect the changes (e.g. new sections added when new files are added). + If you've added/changed/removed a symbol or anything else that changes + the overall structure or indexes, this needs to be reflected in + intel-gpu-tools-sections.txt. Entirely new sections will also need to be + added to intel-gpu-tools-docs.xml in the appropriate place. DEPENDENCIES This is a non-exchaustive list of package dependencies required for -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t 4/7] docs: add the sections file
On 10 June 2014 15:40, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jun 10, 2014 at 03:30:54PM +0100, Thomas Wood wrote: This file can contain custom changes to the control the documentation output and therefore should be included in the repository. Signed-off-by: Thomas Wood thomas.w...@intel.com Doesn't that mean we need to update this when adding new symbols? Imo forcing autogeneration is better since you can control the order also by moving functions around in the .h files. Or what exactly is this for? -Daniel There are further annotations that can be made in this file, which is why gtk-doc does not automatically overwrite it when symbols and sections are added or removed: https://developer.gnome.org/gtk-doc-manual/stable/metafiles_sections.html.en --- docs/reference/intel-gpu-tools/.gitignore | 1 - .../intel-gpu-tools/intel-gpu-tools-sections.txt | 378 + 2 files changed, 378 insertions(+), 1 deletion(-) create mode 100644 docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt diff --git a/docs/reference/intel-gpu-tools/.gitignore b/docs/reference/intel-gpu-tools/.gitignore index 9415974..9fadbfc 100644 --- a/docs/reference/intel-gpu-tools/.gitignore +++ b/docs/reference/intel-gpu-tools/.gitignore @@ -6,7 +6,6 @@ /intel-gpu-tools-decl-list.txt /intel-gpu-tools-decl.txt /intel-gpu-tools-overrides.txt -/intel-gpu-tools-sections.txt /intel-gpu-tools-undeclared.txt /intel-gpu-tools-undocumented.txt /intel-gpu-tools-unused.txt diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt b/docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt new file mode 100644 index 000..de6c76c --- /dev/null +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt @@ -0,0 +1,378 @@ +SECTION +FILEdebug/FILE +DEBUG_PROTOCOL_VERSION +COMMUNICATION_OFFSET +COMMUNICATION_QWORD +STATE_EU_MSG +STATE_CPU_ACK +STATE_OFFSET +STATE_QWORD +TX_OFFSET +TX_QWORD +RX_OFFSET +RX_QWORD +grf +mrf +cr +sr +DWORD8 +/SECTION + +SECTION +FILEdrmtest/FILE +mmap64 +ARRAY_SIZE +ALIGN +drm_get_card +drm_open_any +drm_open_any_render +gem_quiescent_gpu +do_or_die +do_ioctl +/SECTION + +SECTION +FILEigt_aux/FILE +igt_fork_signal_helper +igt_stop_signal_helper +igt_exchange_int +igt_permute_array +igt_progress +igt_check_boolean_env_var +igt_aub_dump_enabled +igt_init_aperture_trashers +igt_trash_aperture +igt_cleanup_aperture_trashers +igt_system_suspend_autoresume +igt_drop_root +igt_wait_for_keypress +igt_runtime_pm_status +igt_setup_runtime_pm +igt_get_runtime_pm_status +igt_wait_for_pm_status +intel_purge_vm_caches +intel_get_avail_ram_mb +intel_get_total_ram_mb +intel_get_total_swap_mb +intel_check_memory +CHECK_RAM +CHECK_SWAP +/SECTION + +SECTION +FILEigt_core/FILE +IGT_EXIT_TIMEOUT +IGT_EXIT_SKIP +IGT_EXIT_SUCCESS +igt_fixture +igt_subtest_init +igt_opt_handler_t +igt_subtest_init_parse_opts +igt_tokencat +igt_subtest +igt_subtest_f +igt_subtest_name +igt_only_list_subtests +igt_main +igt_simple_init +igt_simple_main +igt_skip +igt_success +igt_fail +igt_exit +igt_assert +igt_assert_f +igt_assert_cmpint +igt_require +igt_skip_on +igt_require_f +igt_skip_on_f +igt_fork +igt_waitchildren +igt_helper_process +igt_fork_helper +igt_wait_helper +igt_stop_helper +igt_exit_handler_t +igt_install_exit_handler +igt_enable_exit_handler +igt_disable_exit_handler +igt_run_in_simulation +SLOW_QUICK +igt_skip_on_simulation +igt_log_level +igt_log +igt_vlog +igt_debug +igt_info +igt_warn +igt_warn_on +igt_warn_on_f +igt_set_timeout +/SECTION + +SECTION +FILEigt_debugfs/FILE +igt_debugfs_open +igt_debugfs_fopen +igt_pipe_crc_t +igt_crc_t +intel_pipe_crc_source +igt_crc_is_null +igt_crc_equal +igt_crc_to_string +igt_require_pipe_crc +igt_pipe_crc_new +igt_pipe_crc_free +igt_pipe_crc_start +igt_pipe_crc_stop +igt_pipe_crc_get_crcs +igt_pipe_crc_collect_crc +DROP_UNBOUND +DROP_BOUND +DROP_RETIRE +DROP_ACTIVE +DROP_ALL +igt_drop_caches_set +igt_disable_prefault +igt_enable_prefault +igt_open_forcewake_handle +stop_ring_flags +igt_to_stop_ring_flag +igt_set_stop_rings +igt_get_stop_rings +/SECTION + +SECTION +FILEigt_fb/FILE +cairo_surface_t +cairo_t +igt_fb +igt_text_align +igt_create_fb_with_bo_size +igt_create_fb +igt_create_color_fb +igt_remove_fb +igt_get_cairo_ctx +igt_paint_color +igt_paint_color_alpha +igt_paint_color_gradient +igt_paint_test_pattern +igt_paint_image +igt_write_fb_to_png +igt_cairo_printf_line +igt_bpp_depth_to_drm_format +igt_drm_format_to_bpp +igt_format_str +igt_get_all_formats +/SECTION + +SECTION +FILEigt_kms/FILE +pipe +pipe_name +igt_plane +plane_name +sprite_name +port +port_name +kmstest_connector_config +kmstest_get_connector_default_mode +kmstest_get_connector_config +kmstest_free_connector_config +kmstest_dump_mode
Re: [Intel-gfx] [i-g-t 7/7] docs: add missing sections to intel-gpu-tools-docs.xml
On 10 June 2014 15:47, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jun 10, 2014 at 03:30:57PM +0100, Thomas Wood wrote: Signed-off-by: Thomas Wood thomas.w...@intel.com I've intentionally left these out since they're not really part of the core test library ... E.g. all public rendercopy functions are documented as part of the intel batchbuffer library. -Daniel These functions currently appear in the API index and therefore produce warnings that there is no link for them. If they are private then they can be left out of the documentation altogether and their headers added to the IGNORE_HEADERS directive instead. --- docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml | 4 1 file changed, 4 insertions(+) diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml index dcfff33..96cf77f 100644 --- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml @@ -15,6 +15,7 @@ chapter titleIntel GPU Tools/title +xi:include href=xml/debug.xml/ xi:include href=xml/drmtest.xml/ xi:include href=xml/igt_core.xml/ xi:include href=xml/igt_debugfs.xml/ @@ -22,9 +23,12 @@ xi:include href=xml/igt_fb.xml/ xi:include href=xml/igt_aux.xml/ xi:include href=xml/ioctl_wrappers.xml/ +xi:include href=xml/instdone.xml/ xi:include href=xml/intel_batchbuffer.xml/ xi:include href=xml/intel_chipset.xml/ xi:include href=xml/intel_io.xml/ +xi:include href=xml/media_fill.xml/ +xi:include href=xml/rendercopy.xml/ /chapter index id=api-index-full -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check the minimum pitch for the user framebuffer
On Tue, Jun 10, 2014 at 10:22:33PM +0100, Chris Wilson wrote:
Compute the smallest pitch required for a linear framebuffer and assert
that the user has declared a pitch that meets that minimum requirement.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cc62b140eb1c..ef34badbe69c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11808,6 +11808,8 @@ static int intel_framebuffer_init(struct drm_device
*dev,
{
int aligned_height;
int pitch_limit;
+ int depth;
+ int bpp;
int ret;
WARN_ON(!mutex_is_locked(dev-struct_mutex));
@@ -11823,6 +11825,15 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return -EINVAL;
}
+ drm_fb_get_bpp_depth(mode_cmd-pixel_format, bpp, depth);
+ if (mode_cmd-pitches[0]
intel_framebuffer_pitch_for_width(mode_cmd-width,
+ bpp)) {
+ DRM_DEBUG(pitch (%d) must be at least the linear stride
(%d)\n,
+ mode_cmd-pitches[0],
+ intel_framebuffer_pitch_for_width(mode_cmd-width,
bpp));
+ return -EINVAL;
+ }
How come framebuffer_check() in drm_crtc.c didn't catch this?
+
if (INTEL_INFO(dev)-gen = 5 !IS_VALLEYVIEW(dev)) {
pitch_limit = 32*1024;
} else if (INTEL_INFO(dev)-gen = 4) {
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check for a stalled page flip after each vblank
Long ago, back in the racy haydays of 915gm interrupt handling, page
flips would occasionally go astray and leave the hardware stuck, and the
display not updating. This annoyed people who relied on their systems
being able to display continuously updating information 24/7, and so
some code to detect when the driver missed the page flip completion
signal was added. Until recently, it was presumed that the interrupt
handling was now flawless, but once again Simon Farnsworth has found a
system whose display will stall. Reinstate the pageflip stall detection,
which works by checking to see if the hardware has been updated to the
new framebuffer address following each vblank. If the hardware is
scanning out from the new framebuffer, but we still think the flip is
pending, then we kick our driver into submision.
This is a continuation of the effort started with
commit 4e5359cd053bfb7d8dabe4a63624a5726848ffbc
Author: Simon Farnsworth simon.farnswo...@onelan.co.uk
Date: Wed Sep 1 17:47:52 2010 +0100
drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt
This now includes a belt-and-braces approach to make sure the driver
(or the hardware) doesn't miss an interrupt and cause us to stop
updating the display should the unthinkable happen and the pageflip fail - i.e.
that the user is able to continue submitting flips.
v2: Cleanup, refactor, and rename
v3: Only start counting vblanks after the flip command has been seen by
the hardware.
v4: Record the seqno after we touch the ring, or else there may be no
seqno allocated yet.
Reported-by: Simon Farnsworth si...@farnz.org.uk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +---
drivers/gpu/drm/i915/i915_irq.c | 85 +++-
drivers/gpu/drm/i915/intel_display.c | 124 ---
drivers/gpu/drm/i915/intel_drv.h | 5 ++
4 files changed, 150 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e8ea1efd3810..eae1a184 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -581,6 +581,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void
*data)
{
struct drm_info_node *node = m-private;
struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long flags;
struct intel_crtc *crtc;
@@ -595,6 +596,8 @@ static int i915_gem_pageflip_info(struct seq_file *m, void
*data)
seq_printf(m, No flip due on pipe %c (plane %c)\n,
pipe, plane);
} else {
+ u32 addr;
+
if (atomic_read(work-pending) INTEL_FLIP_COMPLETE) {
seq_printf(m, Flip queued on pipe %c (plane
%c)\n,
pipe, plane);
@@ -602,23 +605,29 @@ static int i915_gem_pageflip_info(struct seq_file *m,
void *data)
seq_printf(m, Flip pending (waiting for vsync)
on pipe %c (plane %c)\n,
pipe, plane);
}
+ seq_printf(m, Flip queued on %s at seqno %u, now %u\n,
+ work-ring-name,
+ work-flip_queued_seqno,
+ work-ring-get_seqno(work-ring, true));
+ seq_printf(m, Flip queued on frame %d, (was ready on
frame %d), now %d\n,
+ work-flip_queued_vblank,
+ work-flip_ready_vblank,
+ drm_vblank_count(dev, crtc-pipe));
if (work-enable_stall_check)
seq_puts(m, Stall check enabled, );
else
seq_puts(m, Stall check waiting for page flip
ioctl, );
seq_printf(m, %d prepares\n,
atomic_read(work-pending));
- if (work-old_fb_obj) {
- struct drm_i915_gem_object *obj =
work-old_fb_obj;
- if (obj)
- seq_printf(m, Old framebuffer
gtt_offset 0x%08lx\n,
-
i915_gem_obj_ggtt_offset(obj));
- }
+ if (INTEL_INFO(dev)-gen = 4)
+ addr =
I915_HI_DISPBASE(I915_READ(DSPSURF(crtc-plane)));
+ else
+ addr = I915_READ(DSPADDR(crtc-plane));
+
Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: Set D3_hot for vlv during runtime_suspend
On Wed, 2014-06-11 at 12:17 +0200, Daniel Vetter wrote:
On Wed, Jun 11, 2014 at 01:53:49PM +0530, Sagar Arun Kamble wrote:
This patch can be marked as abandoned.
Have verified locally that pci driver is taking care of D0ix transitions
and state save/restore.
That still leaves the question why you originally thought this is
required. What did blow up here in your testing?
Took reference from suspend path in our previous repo where driver was
setting and saving the state. For S0iX, Gfx is supposed to go into
D3_hot, so we explicitly set that state assuming its gfx driver
responsibility.
We should have done more testing with current driver to ensure it is
indeed going to D3_hot.
Thanks, Daniel
Thanks Imre for the clarification.
On Tue, 2014-06-10 at 20:51 +0300, Imre Deak wrote:
On Tue, 2014-06-10 at 23:05 +0530, Sagar Arun Kamble wrote:
On Tue, 2014-06-10 at 15:43 +0300, Imre Deak wrote:
On Tue, 2014-06-10 at 00:27 +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
To do a platform wide S0i3 transition, Gfx is required to go
to D3_hot state. pci_save_state and pci_restore_state needed to
avoid ring
hangs across D3_hot transitions.
Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM
DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM
DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 5a08c86..70bb456 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1412,6 +1412,11 @@ static int intel_runtime_suspend(struct
device *device)
* via the suspend path.
*/
intel_opregion_notify_adapter(dev, PCI_D1);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_save_state(pdev);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
+ }
DRM_DEBUG_KMS(Device suspended\n);
return 0;
@@ -1428,6 +1433,12 @@ static int intel_runtime_resume(struct
device *device)
DRM_DEBUG_KMS(Resuming device\n);
+ if (IS_VALLEYVIEW(dev)) {
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ pci_enable_device(pdev);
+ }
Setting the proper Dx state and saving/restoring the PCI config space
is
already done for us by the PCI runtime PM framework, see
pci_pm_runtime_suspend/resume().
Where exactly it calls pci_pm_set_powerstate to set D3_hot ?
It's
pci_pm_runtime_suspend()-pci_finish_runtime_suspend()-pci_set_power_state()
.
There seems to be bug in the pci driver in the suspend path. it is not
saving the pci configuration space although code for same exists.
pci driver checks if client driver has saved if not it will exit from
suspend path.
check the code snippet below:
if (!pci_dev-state_saved pci_dev-current_state != PCI_D0
pci_dev-current_state != PCI_UNKNOWN) {
WARN_ONCE(pci_dev-current_state != prev,
PCI PM: State of device not saved by %pF\n,
pm-runtime_suspend);
return 0;
}
if (!pci_dev-state_saved) {
pci_save_state(pci_dev);
pci_finish_runtime_suspend(pci_dev);
}
I don't think this is a bug, but something the PCI framework requires
from drivers. That is if they set the power state to something else than
PCI_D0 or PCI_UNKNOWN they also have to save the state themselves.
I can't check this right now, but I haven't ever seen the above WARN and
by the look of it we are doing the right thing in the driver. That is
leave the power state in D0 and let the PCI framework handle the state
saving/power state transitioning.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] docs: add private headers to IGNORE_HFILES
Signed-off-by: Thomas Wood thomas.w...@intel.com --- docs/reference/intel-gpu-tools/Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/reference/intel-gpu-tools/Makefile.am b/docs/reference/intel-gpu-tools/Makefile.am index daaa3f4..549f34b 100644 --- a/docs/reference/intel-gpu-tools/Makefile.am +++ b/docs/reference/intel-gpu-tools/Makefile.am @@ -58,7 +58,9 @@ EXTRA_HFILES= # Header files or dirs to ignore when scanning. Use base file/dir names # e.g. IGNORE_HFILES=gtkdebug.h gtkintl.h private_code -IGNORE_HFILES=gen6_render.h gen7_media.h gen7_render.h gen8_media.h gen8_render.h i830_reg.h i915_3d.h i915_pciids.h i915_reg.h intel_reg.h +IGNORE_HFILES=gen6_render.h gen7_media.h gen7_render.h gen8_media.h \ + gen8_render.h i830_reg.h i915_3d.h i915_pciids.h i915_reg.h \ + intel_reg.h debug.h instdone.h media_fill.h rendercopy.h # Images to copy into HTML directory. # e.g. HTML_IMAGES=$(top_srcdir)/gtk/stock-icons/stock_about_24.png -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Perform cmdline mode parsing during connector initialisation
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed by drm_fb_helper_initial_config() which is called after
i915.ko's custom initial_config() as a fallback method. So in order for
us to honour it, we need to move the cmdline parser earlier. If we
perform the connector cmdline parsing as soon as we initialise the
connector, that cmdline mode and forced status is then available even if
the fbdev helper is not compiled in or never called.
We also then expose the cmdline user mode in the connector mode lists.
v2: Rebase after connector-name upheaval.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 55
drivers/gpu/drm/drm_fb_helper.c| 64 ++
drivers/gpu/drm/drm_modes.c| 1 +
drivers/gpu/drm/drm_probe_helper.c | 17 ++
include/drm/drm_crtc.h | 1 +
include/drm/drm_fb_helper.h| 1 -
6 files changed, 77 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe94cc10cd35..b9de156515b6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -819,6 +819,59 @@ static void drm_mode_remove(struct drm_connector
*connector,
}
/**
+ * drm_connector_get_cmdline_mode - reads the user's cmdline mode
+ * @connector: connector to quwery
+ * @mode: returned mode
+ *
+ * The kernel supports per-connector configration of its consoles through
+ * use of the video= parameter. This function parses that option and
+ * extracts the user's specified mode (or enable/disable status) for a
+ * particular connector. This is typically only used during the early fbdev
+ * setup.
+ */
+static void drm_connector_get_cmdline_mode(struct drm_connector *connector)
+{
+ struct drm_cmdline_mode *mode = connector-cmdline_mode;
+ char *option = NULL;
+
+ if (fb_get_options(connector-name, option))
+ return;
+
+ if (!drm_mode_parse_command_line_for_connector(option,
+ connector,
+ mode))
+ return;
+
+ if (mode-force) {
+ const char *s;
+
+ switch (mode-force) {
+ case DRM_FORCE_OFF:
+ s = OFF;
+ break;
+ case DRM_FORCE_ON_DIGITAL:
+ s = ON - dig;
+ break;
+ default:
+ case DRM_FORCE_ON:
+ s = ON;
+ break;
+ }
+
+ DRM_INFO(forcing %s connector %s\n, connector-name, s);
+ connector-force = mode-force;
+ }
+
+ DRM_DEBUG_KMS(cmdline mode for connector %s %dx%d@%dHz%s%s%s\n,
+ connector-name,
+ mode-xres, mode-yres,
+ mode-refresh_specified ? mode-refresh : 60,
+ mode-rb ? reduced blanking : ,
+ mode-margins ? with margins : ,
+ mode-interlace ? interlaced : );
+}
+
+/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
* @connector: the connector to init
@@ -870,6 +923,8 @@ int drm_connector_init(struct drm_device *dev,
connector-edid_blob_ptr = NULL;
connector-status = connector_status_unknown;
+ drm_connector_get_cmdline_mode(connector);
+
list_add_tail(connector-head, dev-mode_config.connector_list);
dev-mode_config.num_connector++;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d5d8cea1a679..18988dc3de91 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -105,60 +105,6 @@ fail:
}
EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
-static int drm_fb_helper_parse_command_line(struct drm_fb_helper *fb_helper)
-{
- struct drm_fb_helper_connector *fb_helper_conn;
- int i;
-
- for (i = 0; i fb_helper-connector_count; i++) {
- struct drm_cmdline_mode *mode;
- struct drm_connector *connector;
- char *option = NULL;
-
- fb_helper_conn = fb_helper-connector_info[i];
- connector = fb_helper_conn-connector;
- mode = fb_helper_conn-cmdline_mode;
-
- /* do something on return - turn off connector maybe
Re: [Intel-gfx] [PATCH] drm/i915: Make the physical object coherent with GTT
On Wed, Jun 11, 2014 at 11:28:41AM +0100, Chris Wilson wrote:
Currently objects for which the hardware needs a contiguous physical
address are allocated a shadow backing storage to satisfy the contraint.
This shadow buffer is not wired into the normal obj-pages and so the
physical object is incoherent with accesses via the GPU, GTT and CPU. By
setting up the appropriate scatter-gather table, we can allow userspace
to access the physical object via either a GTT mmaping of or by rendering
into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
storage coherent with the contiguous shadow is not yet possible.
Fortuituously, CPU mmaps of objects requiring physical addresses are not
expected to be coherent anyway.
This allows the physical constraint of the GEM object to be transparent
to userspace and allow it to efficiently render into or update them via
the GTT and GPU.
v2: Fix leak of pci handle spotted by Ville
v3: Remove the now duplicate call to detach_phys_object during free.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Looks good. pread and cpu mmap would get garbage but that's nothing
new, and commit message says as much.
phys pread should be rather easy to add (not much different from
i915_gem_phys_pwrite()), but I guess no one has needed it since
it's not there.
Oh, should there be a i915_gem_object_wait_rendering() in phys pwrite?
But in any case this patch is:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_gem.c | 199
+++-
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 142 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 59e8ffe230a7..b1f072039865 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1025,6 +1025,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_CMD_PARSER_VERSION:
value = i915_cmd_parser_get_version();
break;
+ case I915_PARAM_HAS_COHERENT_PHYS_GTT:
+ value = 1;
+ break;
default:
DRM_DEBUG(Unknown parameter %d\n, param-param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0a9d1b85d529..c80ddcf8aa6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1715,10 +1715,10 @@ struct drm_i915_gem_object {
unsigned long user_pin_count;
struct drm_file *pin_filp;
- /** for phy allocated objects */
- drm_dma_handle_t *phys_handle;
-
union {
+ /** for phy allocated objects */
+ drm_dma_handle_t *phys_handle;
+
struct i915_gem_userptr {
uintptr_t ptr;
unsigned read_only :1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 25b5063388b2..6e8535ba72d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -209,40 +209,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev,
void *data,
return 0;
}
-static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
+static int
+i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
{
- drm_dma_handle_t *phys = obj-phys_handle;
+ struct address_space *mapping = file_inode(obj-base.filp)-i_mapping;
+ char *vaddr = obj-phys_handle-vaddr;
+ struct sg_table *st;
+ struct scatterlist *sg;
+ int i;
- if (!phys)
- return;
+ if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
+ return -EINVAL;
+
+ for (i = 0; i obj-base.size / PAGE_SIZE; i++) {
+ struct page *page;
+ char *src;
+
+ page = shmem_read_mapping_page(mapping, i);
+ if (IS_ERR(page))
+ return PTR_ERR(page);
+
+ src = kmap_atomic(page);
+ memcpy(vaddr, src, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
+ kunmap_atomic(src);
+
+ page_cache_release(page);
+ vaddr += PAGE_SIZE;
+ }
+
+ i915_gem_chipset_flush(obj-base.dev);
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (st == NULL)
+ return -ENOMEM;
+
+ if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+ kfree(st);
+ return -ENOMEM;
+ }
- if (obj-madv == I915_MADV_WILLNEED) {
+ sg = st-sgl;
+ sg-offset = 0;
+ sg-length = obj-base.size;
+
+ sg_dma_address(sg) = obj-phys_handle-busaddr;
+ sg_dma_len(sg) = obj-base.size;
+
+
Re: [Intel-gfx] [PATCH 49/50] drm/i915/bdw: Help out the ctx switch interrupt handler
On Fri, May 09, 2014 at 01:09:19PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see
gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking
for
contexts to squash together. Instead, share the burden by giving more
intelligence to the queue function. At most, the interrupt will iterate over
three elements.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index d9edd10..0aad721 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -410,9 +410,11 @@ int gen8_switch_context_queue(struct intel_engine *ring,
struct i915_hw_context *to,
u32 tail)
{
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *req = NULL;
unsigned long flags;
- bool was_empty;
+ struct drm_i915_gem_request *cursor;
+ int num_elements = 0;
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (req == NULL)
@@ -425,9 +427,24 @@ int gen8_switch_context_queue(struct intel_engine *ring,
spin_lock_irqsave(ring-execlist_lock, flags);
- was_empty = list_empty(ring-execlist_queue);
+ list_for_each_entry(cursor, ring-execlist_queue, execlist_link)
+ if (++num_elements 2)
+ break;
+
+ if (num_elements 2) {
+ struct drm_i915_gem_request *tail_req =
+ list_last_entry(ring-execlist_queue,
+ struct drm_i915_gem_request,
execlist_link);
+ if (to == tail_req-ctx) {
+ WARN(tail_req-elsp_submitted != 0,
+ More than 2 already-submitted reqs
queued\n);
+ list_del(tail_req-execlist_link);
+ queue_work(dev_priv-wq, tail_req-work);
+ }
+ }
Completely forgotten to mention this: ChrisI discussed this on irc and I
guess this issue will disappear if we track contexts instead of requests
in the scheduler. I guess this is an artifact of the gen7 scheduler you've
based this on, but even for that I think scheduling contexts (with preempt
point after each batch) is the right approach. But I haven't dug out the
scheduler patches again so might be wrong with that.
-Daniel
+
list_add_tail(req-execlist_link, ring-execlist_queue);
- if (was_empty)
+ if (num_elements == 0)
gen8_switch_context_unqueue(ring);
spin_unlock_irqrestore(ring-execlist_lock, flags);
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make the physical object coherent with GTT
On Wed, Jun 11, 2014 at 02:40:00PM +0300, Ville Syrjälä wrote: On Wed, Jun 11, 2014 at 11:28:41AM +0100, Chris Wilson wrote: Currently objects for which the hardware needs a contiguous physical address are allocated a shadow backing storage to satisfy the contraint. This shadow buffer is not wired into the normal obj-pages and so the physical object is incoherent with accesses via the GPU, GTT and CPU. By setting up the appropriate scatter-gather table, we can allow userspace to access the physical object via either a GTT mmaping of or by rendering into the GEM bo. However, keeping the CPU mmap of the shmemfs backing storage coherent with the contiguous shadow is not yet possible. Fortuituously, CPU mmaps of objects requiring physical addresses are not expected to be coherent anyway. This allows the physical constraint of the GEM object to be transparent to userspace and allow it to efficiently render into or update them via the GTT and GPU. v2: Fix leak of pci handle spotted by Ville v3: Remove the now duplicate call to detach_phys_object during free. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Looks good. pread and cpu mmap would get garbage but that's nothing new, and commit message says as much. phys pread should be rather easy to add (not much different from i915_gem_phys_pwrite()), but I guess no one has needed it since it's not there. For completeness, we should do it. But as you say, no one has yet requested the bits back from the phys object, and now if they really do desire they can at least use a GTT mmap. Oh, should there be a i915_gem_object_wait_rendering() in phys pwrite? Yes. But in any case this patch is: Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com I'll add the wait. -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 40/50] drm/i915/bdw: Handle context switch events
On Fri, May 09, 2014 at 01:09:10PM +0100, oscar.ma...@intel.com wrote:
From: Thomas Daniel thomas.dan...@intel.com
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to schedule new contexts on interrupt when a previously submitted
context completes (unless no contexts are queued, which means the GPU is
free).
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
v2: Unreferencing the context when we are freeing the request might free
the backing bo, which requires the struct_mutex to be grabbed, so defer
unreferencing and freeing to a bottom half.
v3:
- Ack the interrupt inmediately, before trying to handle it (fix for
missing interrupts by Bob Beckett robert.beck...@intel.com).
This interrupt handling change is interesting since it might explain our
irq handling woes on gen5+ with the two-level GT interrupt handling
scheme. Can you please roll this out as a prep patch for all the existing
gt interrupt sources we handle already for gen5+?
Thanks, Daniel
- Update the Context Status Buffer Read Pointer, just in case (spotted
by Damien Lespiau).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_irq.c | 38 +++-
drivers/gpu/drm/i915/intel_lrc.c| 102
+++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
5 files changed, 129 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f2aae6a..07b8bdc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1748,6 +1748,8 @@ struct drm_i915_gem_request {
/** execlist queue entry for this request */
struct list_head execlist_link;
+ /** Struct to handle this request in the bottom half of an interrupt */
+ struct work_struct work;
};
struct drm_i915_file_private {
@@ -2449,6 +2451,7 @@ static inline u32 intel_get_lr_contextid(struct
drm_i915_gem_object *ctx_obj)
int gen8_switch_context_queue(struct intel_engine *ring,
struct i915_hw_context *to,
u32 tail);
+void gen8_handle_context_events(struct intel_engine *ring);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a28cf6c..fbffead 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1300,6 +1300,7 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
struct drm_i915_private *dev_priv,
u32 master_ctl)
{
+ struct intel_engine *ring;
u32 rcs, bcs, vcs, vecs;
uint32_t tmp = 0;
irqreturn_t ret = IRQ_NONE;
@@ -1307,16 +1308,22 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
if (master_ctl (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
tmp = I915_READ(GEN8_GT_IIR(0));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(0), tmp);
ret = IRQ_HANDLED;
+
rcs = tmp GEN8_RCS_IRQ_SHIFT;
- bcs = tmp GEN8_BCS_IRQ_SHIFT;
+ ring = dev_priv-ring[RCS];
if (rcs GT_RENDER_USER_INTERRUPT)
- notify_ring(dev, dev_priv-ring[RCS]);
+ notify_ring(dev, ring);
+ if (rcs GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
+ gen8_handle_context_events(ring);
+
+ bcs = tmp GEN8_BCS_IRQ_SHIFT;
+ ring = dev_priv-ring[BCS];
if (bcs GT_RENDER_USER_INTERRUPT)
- notify_ring(dev, dev_priv-ring[BCS]);
- if ((rcs | bcs) GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
- DRM_DEBUG_DRIVER(TODO: Context switch\n);
- I915_WRITE(GEN8_GT_IIR(0), tmp);
+ notify_ring(dev, ring);
+ if (bcs GEN8_GT_CONTEXT_SWITCH_INTERRUPT)
+ gen8_handle_context_events(ring);
} else
DRM_ERROR(The master control interrupt lied (GT0)!\n);
}
@@ -1324,18 +1331,20 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
if (master_ctl (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
tmp = I915_READ(GEN8_GT_IIR(1));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(1), tmp);
ret = IRQ_HANDLED;
vcs = tmp
[Intel-gfx] [PATCH] drm/i915: Check the minimum pitch for the user framebuffer
Compute the smallest pitch required for a linear framebuffer and assert
that the user has declared a pitch that meets that minimum requirement.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fb6ca714af44..f6b67289d819 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11809,6 +11809,8 @@ static int intel_framebuffer_init(struct drm_device
*dev,
{
int aligned_height;
int pitch_limit;
+ int depth;
+ int bpp;
int ret;
WARN_ON(!mutex_is_locked(dev-struct_mutex));
@@ -11824,6 +11826,15 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return -EINVAL;
}
+ drm_fb_get_bpp_depth(mode_cmd-pixel_format, bpp, depth);
+ if (mode_cmd-pitches[0]
intel_framebuffer_pitch_for_width(mode_cmd-width,
+bpp)) {
+ DRM_DEBUG(pitch (%d) must be at least the linear stride
(%d)\n,
+ mode_cmd-pitches[0],
+ intel_framebuffer_pitch_for_width(mode_cmd-width,
bpp));
+ return -EINVAL;
+ }
+
if (INTEL_INFO(dev)-gen = 5 !IS_VALLEYVIEW(dev)) {
pitch_limit = 32*1024;
} else if (INTEL_INFO(dev)-gen = 4) {
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t 4/7] docs: add the sections file
On Wed, Jun 11, 2014 at 11:35:40AM +0100, Thomas Wood wrote: On 10 June 2014 15:40, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jun 10, 2014 at 03:30:54PM +0100, Thomas Wood wrote: This file can contain custom changes to the control the documentation output and therefore should be included in the repository. Signed-off-by: Thomas Wood thomas.w...@intel.com Doesn't that mean we need to update this when adding new symbols? Imo forcing autogeneration is better since you can control the order also by moving functions around in the .h files. Or what exactly is this for? -Daniel There are further annotations that can be made in this file, which is why gtk-doc does not automatically overwrite it when symbols and sections are added or removed: https://developer.gnome.org/gtk-doc-manual/stable/metafiles_sections.html.en Hm, I actually like the autogenerated one. Forcing people to do this by hand pretty much means that it will get lost in most cases - doing the api docs themselves is still often not done. So for now I'd actually prefer if we hack the Makefiles to unconditionally regen this, if possible. At least until we have a real use-case for this. -Daniel --- docs/reference/intel-gpu-tools/.gitignore | 1 - .../intel-gpu-tools/intel-gpu-tools-sections.txt | 378 + 2 files changed, 378 insertions(+), 1 deletion(-) create mode 100644 docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt diff --git a/docs/reference/intel-gpu-tools/.gitignore b/docs/reference/intel-gpu-tools/.gitignore index 9415974..9fadbfc 100644 --- a/docs/reference/intel-gpu-tools/.gitignore +++ b/docs/reference/intel-gpu-tools/.gitignore @@ -6,7 +6,6 @@ /intel-gpu-tools-decl-list.txt /intel-gpu-tools-decl.txt /intel-gpu-tools-overrides.txt -/intel-gpu-tools-sections.txt /intel-gpu-tools-undeclared.txt /intel-gpu-tools-undocumented.txt /intel-gpu-tools-unused.txt diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt b/docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt new file mode 100644 index 000..de6c76c --- /dev/null +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-sections.txt @@ -0,0 +1,378 @@ +SECTION +FILEdebug/FILE +DEBUG_PROTOCOL_VERSION +COMMUNICATION_OFFSET +COMMUNICATION_QWORD +STATE_EU_MSG +STATE_CPU_ACK +STATE_OFFSET +STATE_QWORD +TX_OFFSET +TX_QWORD +RX_OFFSET +RX_QWORD +grf +mrf +cr +sr +DWORD8 +/SECTION + +SECTION +FILEdrmtest/FILE +mmap64 +ARRAY_SIZE +ALIGN +drm_get_card +drm_open_any +drm_open_any_render +gem_quiescent_gpu +do_or_die +do_ioctl +/SECTION + +SECTION +FILEigt_aux/FILE +igt_fork_signal_helper +igt_stop_signal_helper +igt_exchange_int +igt_permute_array +igt_progress +igt_check_boolean_env_var +igt_aub_dump_enabled +igt_init_aperture_trashers +igt_trash_aperture +igt_cleanup_aperture_trashers +igt_system_suspend_autoresume +igt_drop_root +igt_wait_for_keypress +igt_runtime_pm_status +igt_setup_runtime_pm +igt_get_runtime_pm_status +igt_wait_for_pm_status +intel_purge_vm_caches +intel_get_avail_ram_mb +intel_get_total_ram_mb +intel_get_total_swap_mb +intel_check_memory +CHECK_RAM +CHECK_SWAP +/SECTION + +SECTION +FILEigt_core/FILE +IGT_EXIT_TIMEOUT +IGT_EXIT_SKIP +IGT_EXIT_SUCCESS +igt_fixture +igt_subtest_init +igt_opt_handler_t +igt_subtest_init_parse_opts +igt_tokencat +igt_subtest +igt_subtest_f +igt_subtest_name +igt_only_list_subtests +igt_main +igt_simple_init +igt_simple_main +igt_skip +igt_success +igt_fail +igt_exit +igt_assert +igt_assert_f +igt_assert_cmpint +igt_require +igt_skip_on +igt_require_f +igt_skip_on_f +igt_fork +igt_waitchildren +igt_helper_process +igt_fork_helper +igt_wait_helper +igt_stop_helper +igt_exit_handler_t +igt_install_exit_handler +igt_enable_exit_handler +igt_disable_exit_handler +igt_run_in_simulation +SLOW_QUICK +igt_skip_on_simulation +igt_log_level +igt_log +igt_vlog +igt_debug +igt_info +igt_warn +igt_warn_on +igt_warn_on_f +igt_set_timeout +/SECTION + +SECTION +FILEigt_debugfs/FILE +igt_debugfs_open +igt_debugfs_fopen +igt_pipe_crc_t +igt_crc_t +intel_pipe_crc_source +igt_crc_is_null +igt_crc_equal +igt_crc_to_string +igt_require_pipe_crc +igt_pipe_crc_new +igt_pipe_crc_free +igt_pipe_crc_start +igt_pipe_crc_stop +igt_pipe_crc_get_crcs +igt_pipe_crc_collect_crc +DROP_UNBOUND +DROP_BOUND +DROP_RETIRE +DROP_ACTIVE +DROP_ALL +igt_drop_caches_set +igt_disable_prefault +igt_enable_prefault +igt_open_forcewake_handle +stop_ring_flags +igt_to_stop_ring_flag +igt_set_stop_rings +igt_get_stop_rings +/SECTION + +SECTION +FILEigt_fb/FILE +cairo_surface_t +cairo_t +igt_fb +igt_text_align
Re: [Intel-gfx] [PATCH i-g-t] docs: add private headers to IGNORE_HFILES
On Wed, Jun 11, 2014 at 11:53:51AM +0100, Thomas Wood wrote: Signed-off-by: Thomas Wood thomas.w...@intel.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- docs/reference/intel-gpu-tools/Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/reference/intel-gpu-tools/Makefile.am b/docs/reference/intel-gpu-tools/Makefile.am index daaa3f4..549f34b 100644 --- a/docs/reference/intel-gpu-tools/Makefile.am +++ b/docs/reference/intel-gpu-tools/Makefile.am @@ -58,7 +58,9 @@ EXTRA_HFILES= # Header files or dirs to ignore when scanning. Use base file/dir names # e.g. IGNORE_HFILES=gtkdebug.h gtkintl.h private_code -IGNORE_HFILES=gen6_render.h gen7_media.h gen7_render.h gen8_media.h gen8_render.h i830_reg.h i915_3d.h i915_pciids.h i915_reg.h intel_reg.h +IGNORE_HFILES=gen6_render.h gen7_media.h gen7_render.h gen8_media.h \ + gen8_render.h i830_reg.h i915_3d.h i915_pciids.h i915_reg.h \ + intel_reg.h debug.h instdone.h media_fill.h rendercopy.h # Images to copy into HTML directory. # e.g. HTML_IMAGES=$(top_srcdir)/gtk/stock-icons/stock_about_24.png -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Make the physical object coherent with GTT
Currently objects for which the hardware needs a contiguous physical
address are allocated a shadow backing storage to satisfy the contraint.
This shadow buffer is not wired into the normal obj-pages and so the
physical object is incoherent with accesses via the GPU, GTT and CPU. By
setting up the appropriate scatter-gather table, we can allow userspace
to access the physical object via either a GTT mmaping of or by rendering
into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
storage coherent with the contiguous shadow is not yet possible.
Fortuituously, CPU mmaps of objects requiring physical addresses are not
expected to be coherent anyway.
This allows the physical constraint of the GEM object to be transparent
to userspace and allow it to efficiently render into or update them via
the GTT and GPU.
v2: Fix leak of pci handle spotted by Ville
v3: Remove the now duplicate call to detach_phys_object during free.
v4: Wait for rendering before pwrite. As this patch makes it possible to
render into the phys object, we should make it correct as well!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_gem.c | 206 +++-
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 149 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 59e8ffe230a7..b1f072039865 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1025,6 +1025,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_CMD_PARSER_VERSION:
value = i915_cmd_parser_get_version();
break;
+ case I915_PARAM_HAS_COHERENT_PHYS_GTT:
+ value = 1;
+ break;
default:
DRM_DEBUG(Unknown parameter %d\n, param-param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0a9d1b85d529..c80ddcf8aa6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1715,10 +1715,10 @@ struct drm_i915_gem_object {
unsigned long user_pin_count;
struct drm_file *pin_filp;
- /** for phy allocated objects */
- drm_dma_handle_t *phys_handle;
-
union {
+ /** for phy allocated objects */
+ drm_dma_handle_t *phys_handle;
+
struct i915_gem_userptr {
uintptr_t ptr;
unsigned read_only :1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 25b5063388b2..f9e158261c42 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -209,40 +209,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
return 0;
}
-static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
+static int
+i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
{
- drm_dma_handle_t *phys = obj-phys_handle;
+ struct address_space *mapping = file_inode(obj-base.filp)-i_mapping;
+ char *vaddr = obj-phys_handle-vaddr;
+ struct sg_table *st;
+ struct scatterlist *sg;
+ int i;
- if (!phys)
- return;
+ if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
+ return -EINVAL;
+
+ for (i = 0; i obj-base.size / PAGE_SIZE; i++) {
+ struct page *page;
+ char *src;
+
+ page = shmem_read_mapping_page(mapping, i);
+ if (IS_ERR(page))
+ return PTR_ERR(page);
+
+ src = kmap_atomic(page);
+ memcpy(vaddr, src, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
+ kunmap_atomic(src);
+
+ page_cache_release(page);
+ vaddr += PAGE_SIZE;
+ }
+
+ i915_gem_chipset_flush(obj-base.dev);
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (st == NULL)
+ return -ENOMEM;
+
+ if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+ kfree(st);
+ return -ENOMEM;
+ }
+
+ sg = st-sgl;
+ sg-offset = 0;
+ sg-length = obj-base.size;
- if (obj-madv == I915_MADV_WILLNEED) {
+ sg_dma_address(sg) = obj-phys_handle-busaddr;
+ sg_dma_len(sg) = obj-base.size;
+
+ obj-pages = st;
+ obj-has_dma_mapping = true;
+ return 0;
+}
+
+static void
+i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj)
+{
+ int ret;
+
+ BUG_ON(obj-madv == __I915_MADV_PURGED);
+
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret) {
+ /* In the event of a
Re: [Intel-gfx] [PATCH] drm/i915: Check the minimum pitch for the user framebuffer
On Wed, Jun 11, 2014 at 12:55:38PM +0100, Chris Wilson wrote: Compute the smallest pitch required for a linear framebuffer and assert that the user has declared a pitch that meets that minimum requirement. Wrong patch! -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 49/50] drm/i915/bdw: Help out the ctx switch interrupt handler
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 11, 2014 12:50 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 49/50] drm/i915/bdw: Help out the ctx switch
interrupt handler
On Fri, May 09, 2014 at 01:09:19PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see
gem_storedw_loop_*) we might end up iterating over too many elements
in interrupt time, looking for contexts to squash together. Instead,
share the burden by giving more intelligence to the queue function. At
most, the interrupt will iterate over three elements.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index d9edd10..0aad721 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -410,9 +410,11 @@ int gen8_switch_context_queue(struct
intel_engine *ring,
struct i915_hw_context *to,
u32 tail)
{
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *req = NULL;
unsigned long flags;
- bool was_empty;
+ struct drm_i915_gem_request *cursor;
+ int num_elements = 0;
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (req == NULL)
@@ -425,9 +427,24 @@ int gen8_switch_context_queue(struct
intel_engine
*ring,
spin_lock_irqsave(ring-execlist_lock, flags);
- was_empty = list_empty(ring-execlist_queue);
+ list_for_each_entry(cursor, ring-execlist_queue, execlist_link)
+ if (++num_elements 2)
+ break;
+
+ if (num_elements 2) {
+ struct drm_i915_gem_request *tail_req =
+ list_last_entry(ring-execlist_queue,
+ struct drm_i915_gem_request,
execlist_link);
+ if (to == tail_req-ctx) {
+ WARN(tail_req-elsp_submitted != 0,
+ More than 2 already-submitted reqs
queued\n);
+ list_del(tail_req-execlist_link);
+ queue_work(dev_priv-wq, tail_req-work);
+ }
+ }
Completely forgotten to mention this: ChrisI discussed this on irc and I
guess this issue will disappear if we track contexts instead of requests in
the
scheduler. I guess this is an artifact of the gen7 scheduler you've based this
on, but even for that I think scheduling contexts (with preempt point after
each batch) is the right approach. But I haven't dug out the scheduler patches
again so might be wrong with that.
-Daniel
H... I didn´t really base this on the scheduler. Some kind of queue to hold
context submissions until the hardware was ready was needed, and queuing
drm_i915_gem_requests seemed like a good choice at the time (by the way, in the
next version I am using a new struct intel_ctx_submit_request, since I don´t
need most of the fields in drm_i915_gem_requests, and I have to add a couple of
new ones anyway).
What do you mean by scheduling contexts? Notice that the requests I am
queuing basically just contain the context and the tail at the point it was
submitted for execution...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/50] drm/i915/bdw: Handle context switch events
-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Wednesday, June 11, 2014 12:52 PM To: Mateo Lozano, Oscar Cc: intel-gfx@lists.freedesktop.org; Daniel, Thomas Subject: Re: [Intel-gfx] [PATCH 40/50] drm/i915/bdw: Handle context switch events On Fri, May 09, 2014 at 01:09:10PM +0100, oscar.ma...@intel.com wrote: From: Thomas Daniel thomas.dan...@intel.com Handle all context status events in the context status buffer on every context switch interrupt. We only remove work from the execlist queue after a context status buffer reports that it has completed and we only attempt to schedule new contexts on interrupt when a previously submitted context completes (unless no contexts are queued, which means the GPU is free). Signed-off-by: Thomas Daniel thomas.dan...@intel.com v2: Unreferencing the context when we are freeing the request might free the backing bo, which requires the struct_mutex to be grabbed, so defer unreferencing and freeing to a bottom half. v3: - Ack the interrupt inmediately, before trying to handle it (fix for missing interrupts by Bob Beckett robert.beck...@intel.com). This interrupt handling change is interesting since it might explain our irq handling woes on gen5+ with the two-level GT interrupt handling scheme. Can you please roll this out as a prep patch for all the existing gt interrupt sources we handle already for gen5+? Thanks, Daniel Can do. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 49/50] drm/i915/bdw: Help out the ctx switch interrupt handler
On Wed, Jun 11, 2014 at 12:01:42PM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 11, 2014 12:50 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 49/50] drm/i915/bdw: Help out the ctx switch
interrupt handler
On Fri, May 09, 2014 at 01:09:19PM +0100, oscar.ma...@intel.com wrote:
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see
gem_storedw_loop_*) we might end up iterating over too many elements
in interrupt time, looking for contexts to squash together. Instead,
share the burden by giving more intelligence to the queue function. At
most, the interrupt will iterate over three elements.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index d9edd10..0aad721 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -410,9 +410,11 @@ int gen8_switch_context_queue(struct
intel_engine *ring,
struct i915_hw_context *to,
u32 tail)
{
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *req = NULL;
unsigned long flags;
- bool was_empty;
+ struct drm_i915_gem_request *cursor;
+ int num_elements = 0;
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (req == NULL)
@@ -425,9 +427,24 @@ int gen8_switch_context_queue(struct
intel_engine
*ring,
spin_lock_irqsave(ring-execlist_lock, flags);
- was_empty = list_empty(ring-execlist_queue);
+ list_for_each_entry(cursor, ring-execlist_queue, execlist_link)
+ if (++num_elements 2)
+ break;
+
+ if (num_elements 2) {
+ struct drm_i915_gem_request *tail_req =
+ list_last_entry(ring-execlist_queue,
+ struct drm_i915_gem_request,
execlist_link);
+ if (to == tail_req-ctx) {
+ WARN(tail_req-elsp_submitted != 0,
+ More than 2 already-submitted reqs
queued\n);
+ list_del(tail_req-execlist_link);
+ queue_work(dev_priv-wq, tail_req-work);
+ }
+ }
Completely forgotten to mention this: ChrisI discussed this on irc and I
guess this issue will disappear if we track contexts instead of requests in
the
scheduler. I guess this is an artifact of the gen7 scheduler you've based
this
on, but even for that I think scheduling contexts (with preempt point after
each batch) is the right approach. But I haven't dug out the scheduler
patches
again so might be wrong with that.
-Daniel
H... I didn´t really base this on the scheduler. Some kind of queue
to hold context submissions until the hardware was ready was needed, and
queuing drm_i915_gem_requests seemed like a good choice at the time (by
the way, in the next version I am using a new struct
intel_ctx_submit_request, since I don´t need most of the fields in
drm_i915_gem_requests, and I have to add a couple of new ones anyway).
What do you mean by scheduling contexts? Notice that the requests I am
queuing basically just contain the context and the tail at the point it
was submitted for execution...
Well I've thought we could just throw contexts at the hardware and throw
new ones at it when the old ones get stuck/are completed. But now I've
realized that since we do the cross-engine/ctx depency tracking in
software it's not quite that easy and we can't unconditionally update the
tail-pointer.
Still for the degenerate case of one ctx submitting batches exclusively
I've hoped just updating the tail pointer in the context and telling the
hw to reload the current context should have been enough. Or at least I've
hoped so, and that should take (mostly) care of the insane request
overload case your patch here addresses.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 49/50] drm/i915/bdw: Help out the ctx switch interrupt handler
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, June 11, 2014 2:58 PM
To: Mateo Lozano, Oscar
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 49/50] drm/i915/bdw: Help out the ctx switch
interrupt handler
On Wed, Jun 11, 2014 at 12:01:42PM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Wednesday, June 11, 2014 12:50 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 49/50] drm/i915/bdw: Help out the
ctx switch interrupt handler
On Fri, May 09, 2014 at 01:09:19PM +0100, oscar.ma...@intel.com
wrote:
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see
gem_storedw_loop_*) we might end up iterating over too many
elements in interrupt time, looking for contexts to squash
together. Instead, share the burden by giving more intelligence to
the queue function. At most, the interrupt will iterate over three
elements.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index d9edd10..0aad721 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -410,9 +410,11 @@ int gen8_switch_context_queue(struct
intel_engine *ring,
struct i915_hw_context *to,
u32 tail)
{
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct drm_i915_gem_request *req = NULL;
unsigned long flags;
- bool was_empty;
+ struct drm_i915_gem_request *cursor;
+ int num_elements = 0;
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (req == NULL)
@@ -425,9 +427,24 @@ int gen8_switch_context_queue(struct
intel_engine
*ring,
spin_lock_irqsave(ring-execlist_lock, flags);
- was_empty = list_empty(ring-execlist_queue);
+ list_for_each_entry(cursor, ring-execlist_queue,
execlist_link)
+ if (++num_elements 2)
+ break;
+
+ if (num_elements 2) {
+ struct drm_i915_gem_request *tail_req =
+ list_last_entry(ring-execlist_queue,
+ struct drm_i915_gem_request,
execlist_link);
+ if (to == tail_req-ctx) {
+ WARN(tail_req-elsp_submitted != 0,
+ More than 2 already-submitted
reqs
queued\n);
+ list_del(tail_req-execlist_link);
+ queue_work(dev_priv-wq, tail_req-work);
+ }
+ }
Completely forgotten to mention this: ChrisI discussed this on irc
and I guess this issue will disappear if we track contexts instead
of requests in the scheduler. I guess this is an artifact of the
gen7 scheduler you've based this on, but even for that I think
scheduling contexts (with preempt point after each batch) is the
right approach. But I haven't dug out the scheduler patches again so
might be wrong with that.
-Daniel
H... I didn´t really base this on the scheduler. Some kind of
queue to hold context submissions until the hardware was ready was
needed, and queuing drm_i915_gem_requests seemed like a good choice
at
the time (by the way, in the next version I am using a new struct
intel_ctx_submit_request, since I don´t need most of the fields in
drm_i915_gem_requests, and I have to add a couple of new ones anyway).
What do you mean by scheduling contexts? Notice that the requests I
am queuing basically just contain the context and the tail at the
point it was submitted for execution...
Well I've thought we could just throw contexts at the hardware and throw
new ones at it when the old ones get stuck/are completed. But now I've
realized that since we do the cross-engine/ctx depency tracking in software
it's not quite that easy and we can't unconditionally update the tail-pointer.
Exactly: unconditionally updating the tail-pointer also means the seqnos might
get executed out of order, which is not nice (at least until there is a
scheduler keeping track of the dependencies).
Still for the degenerate case of one ctx submitting batches exclusively I've
[Intel-gfx] [PATCH i-g-t] docs: always rebuild the sections file
Always rebuild the sections file since it currently doesn't contain any custom modifications. Signed-off-by: Thomas Wood thomas.w...@intel.com --- docs/reference/intel-gpu-tools/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/reference/intel-gpu-tools/Makefile.am b/docs/reference/intel-gpu-tools/Makefile.am index 549f34b..3368e3e 100644 --- a/docs/reference/intel-gpu-tools/Makefile.am +++ b/docs/reference/intel-gpu-tools/Makefile.am @@ -29,7 +29,7 @@ SCANGOBJ_OPTIONS= # Extra options to supply to gtkdoc-scan. # e.g. SCAN_OPTIONS=--deprecated-guards=GTK_DISABLE_DEPRECATED -SCAN_OPTIONS= +SCAN_OPTIONS=--rebuild-sections # Extra options to supply to gtkdoc-mkdb. # e.g. MKDB_OPTIONS=--xml-mode --output-format=xml @@ -93,7 +93,7 @@ EXTRA_DIST += # Files not to distribute # for --rebuild-types in $(SCAN_OPTIONS), e.g. $(DOC_MODULE).types # for --rebuild-sections in $(SCAN_OPTIONS) e.g. $(DOC_MODULE)-sections.txt -#DISTCLEANFILES += +DISTCLEANFILES = $(DOC_MODULE)-sections.txt # Comment this out if you want 'make check' to test you doc status # and run some sanity checks -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] BDW: Adding Reserved PCI IDs.
On Tue, Jun 10, 2014 at 11:08 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Jun 10, 2014 at 10:15:38AM -0700, Rodrigo Vivi wrote: These PCI IDs are reserved on BSpec and can be used at any time in the future. So let's add this now in order to avoid issues that we already faced on previous platforms, like finding out about new ids when user reported accelaration weren't enabled. I'm going to hold off applying this until the kernel patch lands (and we can cite its commit). It is much easier if this file remains a duplicate. Sure. Makes sense. I'm going to wait a rv-b there to update this one here. -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 -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3
On Wed, 11 Jun 2014 11:23:26 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jun 10, 2014 at 12:45:38PM -0700, Jesse Barnes wrote:
On Tue, 10 Jun 2014 21:33:27 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yes, that's what I do below... I even added it to the changelog:
http://patchwork.freedesktop.org/patch/27223/
Did you miss the later hunk in intel_display.c?
What we try to do here is enable swizzling if possible, which we can do
if no inherited fbs are tiled.
So I think I've done exactly what you repeated above, and documented
it. So you're going to need to repeat it with different words so I can
understand, if I'm still missing something.
In swizzle_detect:
...
if (GEN6+) {
if (preserve_bios_swizzle) {
if (I915_READ(DISP_ARB_CTL) DISP_TILE_SURFACE_SWIZZLING) {
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
...
} else {
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
...
}
} else {
/* existing/old logic to decide about swizzling */
}
}
...
Plus no shortcut in i915_gem_init_swizzling. Personally I'd also just use
a small helper function to compute preserve_bios_swizzle instead of
storing it in dev_priv (since we will only use it at exactly one place),
but that's a pure style preference.
Doesn't this amount to the same thing? I.e. we enable it if possible,
otherwise just report it as unswizzled? So you're just wanting a style
change here?
So presuming I read your code correctly there's two issues:
- The first thing you check in swizzle_detect is the hw swizzle bit in
DSP_ARB. If that's not set you force unswizzled. Since most BIOS don't
bother to set this (they use an untiled buffer after all) this means
you've effectively disabled swizzling on almost all machines. The goal
of keeping the old logic was that we actually want to enable swizzling
in some situations.
Ah damn, I had been thinking that bit_6_swizzle was the runtime call,
and that the init_swizzle call would go ahead and set it up properly.
I see that's too late though.
- If you have a machine which uses tiled framebuffers and enables
swizzling in the BIOS your code will a) drop the swizzle setup in
gem_init_hw, breaking resume b) not set the swizzle settings correctly
in swizzle_detect, breaking swap in/out and pwrite/pread. Not sure such
a machine exists, but still.
This would affect krh's MBA, which is why I wanted testing here...
anyway I'll spin a new one and ask krh to test again.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bdw: Do not write the Semaphore Sync Registers in GEN8+
From: Oscar Mateo oscar.ma...@intel.com
These do not exist anymore.
Spotted while reading through intel_ringbuffer.c
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 279488a..0eaaaec 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1746,14 +1746,15 @@ int intel_ring_cacheline_align(struct intel_engine_cs
*ring)
void intel_ring_init_seqno(struct intel_engine_cs *ring, u32 seqno)
{
- struct drm_i915_private *dev_priv = ring-dev-dev_private;
+ struct drm_device *dev = ring-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
BUG_ON(ring-outstanding_lazy_seqno);
- if (INTEL_INFO(ring-dev)-gen = 6) {
+ if (INTEL_INFO(dev)-gen == 6 || INTEL_INFO(dev)-gen == 7) {
I915_WRITE(RING_SYNC_0(ring-mmio_base), 0);
I915_WRITE(RING_SYNC_1(ring-mmio_base), 0);
- if (HAS_VEBOX(ring-dev))
+ if (HAS_VEBOX(dev))
I915_WRITE(RING_SYNC_2(ring-mmio_base), 0);
}
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/50] drm/i915/bdw: Handle context switch events
- Ack the interrupt inmediately, before trying to handle it (fix for missing interrupts by Bob Beckett robert.beck...@intel.com). This interrupt handling change is interesting since it might explain our irq handling woes on gen5+ with the two-level GT interrupt handling scheme. Can you please roll this out as a prep patch for all the existing gt interrupt sources we handle already for gen5+? Thanks, Daniel Can do. One question, though: why only the GT interrupts? what about DE, PM, etc...? It looks like the BSpec is pretty clear on this: 1 - Disable Master Interrupt Control 2 - Find the category of interrupt that is pending 3 - Find the source(s) of the interrupt and ***clear the Interrupt Identity bits (IIR)*** 4 - Process the interrupt(s) that had bits set in the IIRs 5 - Re-enable Master Interrupt Control ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3
On Wed, Jun 11, 2014 at 5:13 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: - If you have a machine which uses tiled framebuffers and enables swizzling in the BIOS your code will a) drop the swizzle setup in gem_init_hw, breaking resume b) not set the swizzle settings correctly in swizzle_detect, breaking swap in/out and pwrite/pread. Not sure such a machine exists, but still. This would affect krh's MBA, which is why I wanted testing here... anyway I'll spin a new one and ask krh to test again. Hm, I've thought the issue with the MBA is that it used tiled fbs, but non-swizzled. And then a mess ensued when we've enabled it. But yeah, unfortunately with the new logic we need to retest :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3
On Wed, 11 Jun 2014 17:39:29 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jun 11, 2014 at 5:13 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: - If you have a machine which uses tiled framebuffers and enables swizzling in the BIOS your code will a) drop the swizzle setup in gem_init_hw, breaking resume b) not set the swizzle settings correctly in swizzle_detect, breaking swap in/out and pwrite/pread. Not sure such a machine exists, but still. This would affect krh's MBA, which is why I wanted testing here... anyway I'll spin a new one and ask krh to test again. Hm, I've thought the issue with the MBA is that it used tiled fbs, but non-swizzled. And then a mess ensued when we've enabled it. But yeah, unfortunately with the new logic we need to retest :( Ah yeah I think you're right, either way, need more testing. Maybe we should have just gone with the first patch to never enable swizzling based on Art's assertion that it didn't matter. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] list-workarounds/chv: Add Cherryview to the list of valid platorms
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
scripts/list-workarounds | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/list-workarounds b/scripts/list-workarounds
index 68200dc..5a84ee8 100755
--- a/scripts/list-workarounds
+++ b/scripts/list-workarounds
@@ -17,7 +17,8 @@ def find_nth(haystack, needle, n):
n -= 1
return start
-valid_platforms = ('ctg', 'elk', 'ilk', 'snb', 'ivb', 'vlv', 'hsw', 'bdw')
+valid_platforms = ('ctg', 'elk', 'ilk', 'snb', 'ivb', 'vlv', 'hsw', 'bdw',
+ 'chv')
def parse_platforms(p):
l = p.split(',')
for p in l:
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sluggish performance after resume//Re: Bug Report - [Acer Aspire V5-122P] Unable to adjust screen brightness
On 10 June 2014 17:58, Ben Widawsky b...@bwidawsk.net wrote: On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: +Ben Widawsky Daniel Vetter On 06/09/2014 03:38 PM, Lewis Toohey wrote: On 3 June 2014 02:22, Aaron Lu aaron...@intel.com wrote: On 05/30/2014 09:12 PM, Lewis Toohey wrote: Aaron I am in the process of performing this bisection, however, I need a bit of advice. I have got a mix of results following suspend right through from (i) system reboot; (ii) low graphics mode error; (iii) restore but sluggish performance; and (iv) restore but *very* sluggish performance. Is the sluggish performance experienced with a GUI environment? What should qualify as a bad commit? Anything other than a perfect restore? I think ii/iii/iv all qualify as bad, if there is no such problem in previous kernels. And yes, a perfect restore is expected, assume the system is able to do a perfect restore with old kernels. Thanks, Aaron Many thanks Hi Aaron Firstly, yes the sluggish performance I was referring to is experienced in the GUI environment. Jerky graphics and CPU fan appears to max out and stay there. Old kernels (e.g. the Ubuntu default kernel) do not do this and just restore perfectly. I have completed the bisect as requested. Please find the full log below. I am slightly unconvinced, as building the previous commit in the log still seems to have the same problem, however, that commit is a merge and I don't really know what this means. Many thanks Bisect Log: git bisect start # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] include/linux/syscalls.h: add sys_renameat2() prototype git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix indenting in ncp_lookup() git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly return the vma from bind_to_vm git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement WaIncreaseL3CreditsForVLVB0:vlv git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the Global GTT VM first in the list of VM git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize PPGTT init git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax context alignment git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to error BO capture git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt lookups to not WARN git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't unconditionally try to deref aliasing ppgtt git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO The commit looks like related, I've added the commit author. Ben, Do you have any suggestions? Does the above commit have any chance of causing sluggish performance problem after a resume? Thanks, Aaron What this comment actually does is use MMIO writes for the page tables after a GPU hang/reset. (What a poorly named commit message). Can you please provide the full dmesg with the drm.debug=0x2? Hi Ben Thank you for responding. Just to verify that I have done this correctly, I added drm.debug=0x2 to the kernel command line (in Grub), booted, suspended and resumed, and then ran Dmesg. I wasn't sure exactly where to put it, so please find a copy of the output here: http://www.toohey.co.uk/dmesg I hope that is
Re: [Intel-gfx] Sluggish performance after resume//Re: Bug Report - [Acer Aspire V5-122P] Unable to adjust screen brightness
On 11 June 2014 08:03, Aaron Lu aaron...@intel.com wrote: On 06/11/2014 06:54 AM, Ben Widawsky wrote: On Tue, Jun 10, 2014 at 08:59:32PM +0100, Lewis Toohey wrote: On 10 June 2014 17:58, Ben Widawsky b...@bwidawsk.net wrote: On Tue, Jun 10, 2014 at 01:33:51PM +0800, Aaron Lu wrote: +Ben Widawsky Daniel Vetter On 06/09/2014 03:38 PM, Lewis Toohey wrote: Hi Aaron Firstly, yes the sluggish performance I was referring to is experienced in the GUI environment. Jerky graphics and CPU fan appears to max out and stay there. Old kernels (e.g. the Ubuntu default kernel) do not do this and just restore perfectly. I have completed the bisect as requested. Please find the full log below. I am slightly unconvinced, as building the previous commit in the log still seems to have the same problem, however, that commit is a merge and I don't really know what this means. Many thanks Bisect Log: git bisect start # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] include/linux/syscalls.h: add sys_renameat2() prototype git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix indenting in ncp_lookup() git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly return the vma from bind_to_vm git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement WaIncreaseL3CreditsForVLVB0:vlv git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the Global GTT VM first in the list of VM git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize PPGTT init git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax context alignment git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to error BO capture git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt lookups to not WARN git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't unconditionally try to deref aliasing ppgtt git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO The commit looks like related, I've added the commit author. Ben, Do you have any suggestions? Does the above commit have any chance of causing sluggish performance problem after a resume? What this comment actually does is use MMIO writes for the page tables after a GPU hang/reset. (What a poorly named commit message). Can you please provide the full dmesg with the drm.debug=0x2? Hi Ben Thank you for responding. Just to verify that I have done this correctly, I added drm.debug=0x2 to the kernel command line (in Grub), booted, suspended and resumed, and then ran Dmesg. I wasn't sure exactly where to put it, so please find a copy of the output here: http://www.toohey.co.uk/dmesg I hope that is helpful. If you need any further information please let me know. Many thanks I only see radeon stuff in that dmesg. But you did the right thing to grub. Oh yes, this is a AMD graphics card so the bisected commit can't be the culprit. No ideas now, Lewis, I'm afraid you will need try harder to find the bad commit. Thanks, Aaron OK, thank you both. I have a definite good point (v3.14) and a definite bad point (v3.15-rc1), so I just need to figure out why my bisection didn't yield the correct result... let me do some more experimentation and come back you. Many thanks -- Lewis le...@toohey.co.uk 0782 588 4158 ___ Intel-gfx mailing list
Re: [Intel-gfx] 3.15-rc5 freeze after wakeup
Hi, any update on this issue? It's still present in 3.15 release. Thanks. On Tue, May 20, 2014 at 2:41 AM, Dave Airlie airl...@linux.ie wrote: Hi, cc'iong intel-gfx. I've upgraded kernel on my PC to 3.15-rc5 and I got today freeze (recovery possibly only by power off/on) when waking from suspend. There is only warning in log but system was completely dead (no keys reaction ). May 14 15:53:15 nb kernel: [30404.485085] PM: Syncing filesystems ... done. May 14 15:53:15 nb kernel: [30404.711342] PM: Preparing system for mem sleep May 14 15:53:15 nb kernel: [30404.711610] Freezing user space processes ... (elapsed 0.001 seconds) done. May 14 15:53:15 nb kernel: [30404.713305] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. May 14 15:53:15 nb kernel: [30404.714431] PM: Entering mem sleep May 14 15:53:15 nb kernel: [30404.714881] Suspending console(s) (use no_console_suspend to debug) May 14 15:53:15 nb kernel: [30405.338766] sd 4:0:0:0: [sda] Synchronizing SCSI cache May 14 15:53:15 nb kernel: [30405.338893] sd 4:0:0:0: [sda] Stopping disk May 14 15:53:15 nb kernel: [30405.361653] nouveau [ DRM] evicting buffers... May 14 15:53:15 nb kernel: [30405.361654] nouveau [ DRM] waiting for kernel channels to go idle... May 14 15:53:15 nb kernel: [30405.361679] nouveau [ DRM] suspending client object trees... May 14 15:53:15 nb kernel: [30405.365746] [ cut here ] May 14 15:53:15 nb kernel: [30405.365765] WARNING: CPU: 1 PID: 21060 at drivers/gpu/drm/i915/intel_uncore.c:125 gen6_gt_check_fifodbg.isra.9+0x38/0x50 [i915]() May 14 15:53:15 nb kernel: [30405.365765] MMIO read or write has been dropped May 14 15:53:15 nb kernel: [30405.365782] Modules linked in: cdc_acm(F) mmc_block(F) pl2303(F) usbserial(F) usblp(F) usb_storage(F) ctr(F) ccm(F) rfcomm(F) bnep(F) snd_hda_codec_hdmi(F) x86_pkg_temp_thermal(F) intel_powerclamp(F) coretemp(F) kvm(F) uvcvideo(F) arc4(F) videobuf2_vmalloc(F) videobuf2_memops(F) videobuf2_core(F) crct10dif_pclmul(F) crc32_pclmul(F) ghash_clmulni_intel(F) nfsd(F) aesni_intel(F) iwlmvm(F) videodev(F) i915(F) aes_x86_64(F) lrw(F) gf128mul(F) glue_helper(F) mac80211(F) auth_rpcgss(F) nfs_acl(F) ablk_helper(F) cryptd(F) nouveau(F) snd_hda_codec_realtek(F) snd_hda_intel(F) joydev(F) snd_hda_codec(F) ttm(F) drm_kms_helper(F) snd_hwdep(F) snd_pcm(F) snd_page_alloc(F) snd_seq_midi(F) asus_nb_wmi(F) iwlwifi(F) drm(F) snd_seq_midi_event(F) nfs(F) snd_rawmidi(F) snd_seq(F) asus_wmi(F) sparse_keymap(F) mxm_wmi(F) snd_seq_device(F) btusb(F) i2c_algo_bit(F) mei_me(F) snd_timer(F) bluetooth(F) snd(F) cfg80211(F) lockd(F) sunrpc(F) mei(F) soundcore(F) microcode(F) rtsx_pci_ms(F) memstick(F) binfmt_misc(F) lpc_ich(F) fscache(F) psmouse(F) video(F) wmi(F) mac_hid(F) serio_raw(F) nls_iso8859_1(F) parport_pc(F) ppdev(F) lp(F) parport(F) rtsx_pci_sdmmc(F) ahci(F) r8169(F) libahci(F) rtsx_pci(F) mii(F) May 14 15:53:15 nb kernel: [30405.365795] CPU: 1 PID: 21060 Comm: kworker/u16:16 Tainted: GF W3.13.2 #5 May 14 15:53:15 nb kernel: [30405.365796] Hardware name: ASUSTeK COMPUTER INC. N56JR/N56JR, BIOS N56JR.204 10/31/2013 May 14 15:53:15 nb kernel: [30405.365804] Workqueue: i915 gen6_force_wake_work [i915] May 14 15:53:15 nb kernel: [30405.365806] 0009 88032964bd38 81715b4e 88032964bd80 May 14 15:53:15 nb kernel: [30405.365807] 88032964bd70 8106420d 8800363c8020 8800363c8028 May 14 15:53:15 nb kernel: [30405.365809] 0246 0200 88032964bdd0 May 14 15:53:15 nb kernel: [30405.365809] Call Trace: May 14 15:53:15 nb kernel: [30405.365813] [81715b4e] dump_stack+0x45/0x56 May 14 15:53:15 nb kernel: [30405.365815] [8106420d] warn_slowpath_common+0x7d/0xa0 May 14 15:53:15 nb kernel: [30405.365817] [8106427c] warn_slowpath_fmt+0x4c/0x50 May 14 15:53:15 nb kernel: [30405.365820] [810125b6] ? __switch_to+0x126/0x4c0 May 14 15:53:15 nb kernel: [30405.365827] [a06d93d8] gen6_gt_check_fifodbg.isra.9+0x38/0x50 [i915] May 14 15:53:15 nb kernel: [30405.365834] [a06d947b] __gen6_gt_force_wake_mt_put+0x2b/0x30 [i915] May 14 15:53:15 nb kernel: [30405.365840] [a06d91a7] gen6_force_wake_work+0x37/0x50 [i915] May 14 15:53:15 nb kernel: [30405.365842] [8107fef2] process_one_work+0x182/0x450 May 14 15:53:15 nb kernel: [30405.365843] [81080cb1] worker_thread+0x121/0x410 May 14 15:53:15 nb kernel: [30405.365845] [81080b90] ? rescuer_thread+0x3e0/0x3e0 May 14 15:53:15 nb kernel: [30405.365846] [81087962] kthread+0xd2/0xf0 May 14 15:53:15 nb kernel: [30405.365847] [81087890] ? kthread_create_on_node+0x190/0x190 May 14 15:53:15 nb kernel: [30405.365849] [817267fc] ret_from_fork+0x7c/0xb0 May 14 15:53:15 nb kernel: [30405.365850] [81087890] ?
[Intel-gfx] [PATCH i-g-t] docs: remove unused annotation glossary include
API annotations are not used anywhere in the documentation, so the annotation glossary is not built. Signed-off-by: Thomas Wood thomas.w...@intel.com --- docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml index dcfff33..68ca8d4 100644 --- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml @@ -35,6 +35,4 @@ titleIndex of deprecated API/title xi:include href=xml/api-index-deprecated.xmlxi:fallback //xi:include /index - - xi:include href=xml/annotation-glossary.xmlxi:fallback //xi:include /book -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 1/4] lib/igt_debugfs: Don't fail if debugfs is already mounted
From: Ville Syrjälä ville.syrj...@linux.intel.com Remove the igt_assert() from the debugfs mount. It will fail if debugfs is already mounted. With the assert in place it's very annying to use igt without i915 loaded (eg. to dump BIOS configured registers). Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- lib/igt_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c index f21f671..809d447 100644 --- a/lib/igt_debugfs.c +++ b/lib/igt_debugfs.c @@ -102,7 +102,7 @@ static bool __igt_debugfs_init(igt_debugfs_t *debugfs) igt_assert(stat(/sys/kernel/debug, st) == 0); - igt_assert(mount(debug, /sys/kernel/debug, debugfs, 0, 0) == 0); + mount(debug, /sys/kernel/debug, debugfs, 0, 0); find_minor: strcpy(debugfs-root, path); -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 4/4] tools/intel_poller: Add a new tool that will poll various display registers
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_poller can be used to poll various display registers
(IIR,scanline/pixel/flip/frame counter, live address, etc.).
It can be used to determine eg. at which scanline or pixel count certain
events occur.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Ideas for a better name are welcome!
lib/intel_reg.h| 22 +-
tools/Makefile.sources |1 +
tools/intel_poller.c | 1471
3 files changed, 1491 insertions(+), 3 deletions(-)
create mode 100644 tools/intel_poller.c
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 84e05e4..87a14c9 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2248,7 +2248,11 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#define PIPE_PIXEL_MASK0x00ff
#define PIPE_PIXEL_SHIFT 0
-
+/*
+ * g4x+ frame/flip counters
+ */
+#define PIPEAFRMCOUNT_G4X 0x70040
+#define PIPEAFLIPCOUNT_G4X 0x70044
/*
* Computing GMCH M and N values.
*
@@ -2296,20 +2300,24 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#define PIPEBSTAT 0x71024
#define PIPEBFRAMEHIGH 0x71040
#define PIPEBFRAMEPIXEL0x71044
+#define PIPEBFRMCOUNT_G4X 0x71040
+#define PIPEBFLIPCOUNT_G4X 0x71044
#define PIPEB_GMCH_DATA_M 0x71050
#define PIPEB_GMCH_DATA_N 0x71054
#define PIPEB_DP_LINK_M0x71060
#define PIPEB_DP_LINK_N0x71064
+#define PIPEC_DSL 0x72000
+
#define PIPECCONF 0x72008
#define PIPECGCMAXRED 0x72010
#define PIPECGCMAXGREEN0x72014
#define PIPECGCMAXBLUE 0x72018
#define PIPECSTAT 0x72024
-#define PIPECFRAMEHIGH 0x72040
-#define PIPECFRAMEPIXEL0x72044
+#define PIPECFRMCOUNT_G4X 0x72040
+#define PIPECFLIPCOUNT_G4X 0x72044
#define PIPEC_GMCH_DATA_M 0x72050
#define PIPEC_GMCH_DATA_N 0x72054
@@ -2370,12 +2378,15 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#define DSPASURF 0x7019C
#define DSPATILEOFF0x701A4
+#define DSPASURFLIVE 0x701AC
#define DSPBSURF 0x7119C
#define DSPBTILEOFF0x711A4
+#define DSPBSURFLIVE 0x711AC
#define DSPCSURF 0x7219C
#define DSPCTILEOFF0x721A4
+#define DSPCSURFLIVE 0x721AC
#define VGACNTRL 0x71400
# define VGA_DISP_DISABLE (1 31)
@@ -2879,6 +2890,11 @@ typedef enum {
#define DEIIR 0x44008
#define DEIER 0x4400c
+#define GEN8_DE_PIPE_ISR(pipe) (0x44400 + 0x10 * (pipe))
+#define GEN8_DE_PIPE_IMR(pipe) (0x44404 + 0x10 * (pipe))
+#define GEN8_DE_PIPE_IIR(pipe) (0x44408 + 0x10 * (pipe))
+#define GEN8_DE_PIPE_IER(pipe) (0x4440c + 0x10 * (pipe))
+
/* GT interrupt */
#define GT_SYNC_STATUS (1 2)
#define GT_USER_INTERRUPT (1 0)
diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index c2535e7..6f6ca4a 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -12,6 +12,7 @@ bin_PROGRAMS =\
intel_iosf_sb_write \
intel_opregion_decode \
intel_perf_counters \
+ intel_poller\
intel_stepping \
intel_reg_checker \
intel_reg_dumper\
diff --git a/tools/intel_poller.c b/tools/intel_poller.c
new file mode 100644
index 000..ebc594a
--- /dev/null
+++ b/tools/intel_poller.c
@@ -0,0 +1,1471 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include assert.h
+#include fcntl.h
+#include getopt.h
+#include unistd.h
+#include signal.h
+#include stdbool.h
+#include stdlib.h
+#include stdio.h
+#include
[Intel-gfx] [PATCH igt 2/4] lib/igt_debufs: Add IGT_NO_FORCEWAKE environment variable
From: Ville Syrjälä ville.syrj...@linux.intel.com
If IGT_NO_FORCEWAKE is set, skip the forcewake open. Useful when you
want to poke at register without otherwise disturbing the GPU.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
lib/igt_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 809d447..2f655a1 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -618,6 +618,8 @@ void igt_enable_prefault(void)
*/
int igt_open_forcewake_handle(void)
{
+ if (getenv(IGT_NO_FORCEWAKE))
+ return -1;
return igt_debugfs_open(i915_forcewake_user, O_WRONLY);
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 3/4] tools: Add intel_iosf_sb_{read, write} tools
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add generic tools to poke at IOSF sideband. The user needs to
manually specify SB port as well as the register.
TODO: Maybe add symbolic names for the units? Would avoid having
to trawl the docs for the magic hex value.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
lib/intel_io.h | 2 ++
lib/intel_iosf.c| 14 ++
tools/Makefile.sources | 2 ++
tools/intel_iosf_sb_read.c | 62 +
tools/intel_iosf_sb_write.c | 67 +
5 files changed, 147 insertions(+)
create mode 100644 tools/intel_iosf_sb_read.c
create mode 100644 tools/intel_iosf_sb_write.c
diff --git a/lib/intel_io.h b/lib/intel_io.h
index 78a6f4d..8293353 100644
--- a/lib/intel_io.h
+++ b/lib/intel_io.h
@@ -50,6 +50,8 @@ uint32_t intel_dpio_reg_read(uint32_t reg, int phy);
void intel_dpio_reg_write(uint32_t reg, uint32_t val, int phy);
uint32_t intel_flisdsi_reg_read(uint32_t reg);
void intel_flisdsi_reg_write(uint32_t reg, uint32_t val);
+uint32_t intel_iosf_sb_read(uint32_t port, uint32_t reg);
+void intel_iosf_sb_write(uint32_t port, uint32_t reg, uint32_t val);
int intel_punit_read(uint8_t addr, uint32_t *val);
int intel_punit_write(uint8_t addr, uint32_t val);
diff --git a/lib/intel_iosf.c b/lib/intel_iosf.c
index ca20638..2f1ef90 100644
--- a/lib/intel_iosf.c
+++ b/lib/intel_iosf.c
@@ -173,3 +173,17 @@ void intel_flisdsi_reg_write(uint32_t reg, uint32_t val)
{
vlv_sideband_rw(IOSF_PORT_FLISDSI, SB_CRWRDA_NP, reg, val);
}
+
+uint32_t intel_iosf_sb_read(uint32_t port, uint32_t reg)
+{
+ uint32_t val;
+
+ vlv_sideband_rw(port, SB_CRRDDA_NP, reg, val);
+
+ return val;
+}
+
+void intel_iosf_sb_write(uint32_t port, uint32_t reg, uint32_t val)
+{
+ vlv_sideband_rw(port, SB_CRWRDA_NP, reg, val);
+}
diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index 0f63845..c2535e7 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -8,6 +8,8 @@ bin_PROGRAMS = \
intel_gpu_top \
intel_gpu_time \
intel_gtt \
+ intel_iosf_sb_read \
+ intel_iosf_sb_write \
intel_opregion_decode \
intel_perf_counters \
intel_stepping \
diff --git a/tools/intel_iosf_sb_read.c b/tools/intel_iosf_sb_read.c
new file mode 100644
index 000..216defe
--- /dev/null
+++ b/tools/intel_iosf_sb_read.c
@@ -0,0 +1,62 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include err.h
+#include string.h
+#include intel_io.h
+#include intel_chipset.h
+
+static void usage(const char *name)
+{
+ printf(Warning : This program will work only on Valleyview\n
+ Usage: %s port reg\n
+ \t port/reg : in 0x format\n,
+ name);
+}
+
+int main(int argc, char *argv[])
+{
+ uint32_t port, reg, val;
+ struct pci_device *dev = intel_get_pci_device();
+
+ if (argc != 3 || !IS_VALLEYVIEW(dev-device_id)) {
+ usage(argv[0]);
+ return 1;
+ }
+
+ port = strtoul(argv[1], NULL, 16);
+ reg = strtoul(argv[2], NULL, 16);
+
+ intel_register_access_init(dev, 0);
+
+ val = intel_iosf_sb_read(port, reg);
+ printf(0x%02x/0x%04x : 0x%08x\n, port, reg, val);
+
+ intel_register_access_fini();
+
+ return 0;
+}
diff --git a/tools/intel_iosf_sb_write.c b/tools/intel_iosf_sb_write.c
new file mode 100644
index 000..0d3dea2
--- /dev/null
+++ b/tools/intel_iosf_sb_write.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of
Re: [Intel-gfx] [PATCH] drm/i915/vlv: drop punit freq staus read after setting idle
On Fri, Jun 06, 2014 at 08:03:20AM -0700, Jesse Barnes wrote: On Fri, 6 Jun 2014 11:29:24 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Thu, Jun 05, 2014 at 01:49:34PM -0700, Jesse Barnes wrote: This may take awhile (~10ms), and we don't need to make noise about it. References: https://bugs.freedesktop.org/show_bug.cgi?id=75244 Tested-by: huax...@intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ee27d74..4eebfd8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3227,10 +3227,6 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv) vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, dev_priv-rps.min_freq_softlimit); - if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS)) - GENFREQSTATUS) == 0, 5)) - DRM_ERROR(timed out waiting for Punit\n); - As I recall the entire point of this was to make sure the frequency really drops before we allow turning off the clock. I'm not sure if we can trust that the frequency (and more importantly the voltage) will drop if we allow turning off the clock before the transition is complete. well, we may need to increase the timeout then... let's see if that helps with the bug. FYI I played around with my BYT a bit and it doesn't appear to require this force gfx clock on part of the workaround. I was polling VLV_GTLC_SURVIVABILITY_REG and VLV_GTLC_PW_STATUS to make sure both render and media wells and the gfx clock remain off, and I was also monitoring vnn via svid. While that was going on I just rewrote PUNIT_REG_GPU_FREQ_REQ to make Punit change the frequency, and sure enough it did, and svid showed me that vnn had also changed. So it appears there's no need to have the gfx clock on to change its frequency on this BYT. I wonder if this part of the workaround was only needed on older parts. Deepak, any ideas? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: BDW: Adding Reserved PCI IDs.
On Tue, Jun 10, 2014 at 10:41:07AM -0700, Rodrigo Vivi wrote: These PCI IDs are reserved on BSpec and can be used at any time in the future. So let's add this now in order to avoid issues that we already faced on previous platforms, like finding out about new ids when user reported accelaration weren't enabled. v2: Reserved IDs doesn't have GT defined. So, creating a separated list. (Ben) Cc: Ben Widawsky b...@bwidawsk.net Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- include/drm/i915_pciids.h | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index 0572035..0968478 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -237,13 +237,25 @@ #define INTEL_BDW_GT3D_IDS(info) \ _INTEL_BDW_D_IDS(3, info) +#define INTEL_BDW_RSVDM_IDS(info) \ + INTEL_VGA_DEVICE(0x1632, info), \ + INTEL_VGA_DEVICE(0x1636, info), \ + INTEL_VGA_DEVICE(0x163B, info), \ + INTEL_VGA_DEVICE(0x163A, info) + +#define INTEL_BDW_RSVDD_IDS(info) \ + INTEL_VGA_DEVICE(0x163D, info), \ + INTEL_VGA_DEVICE(0x163E, info) + #define INTEL_BDW_M_IDS(info) \ INTEL_BDW_GT12M_IDS(info), \ - INTEL_BDW_GT3M_IDS(info) + INTEL_BDW_GT3M_IDS(info), \ + INTEL_BDW_RSVDM_IDS(info) #define INTEL_BDW_D_IDS(info) \ INTEL_BDW_GT12D_IDS(info), \ - INTEL_BDW_GT3D_IDS(info) + INTEL_BDW_GT3D_IDS(info), \ + INTEL_BDW_RSVDD_IDS(info) #define INTEL_CHV_IDS(info) \ INTEL_VGA_DEVICE(0x22b0, info), \ I thought we saved off the GT info, but now that I actually look at the code, we do not. Therefore, I actually think v1 is a better patch. In either case, both v1 and v2 are: Reviewed-by: Ben Widawsky b...@bwidawsk.net I apologize for the extra work. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/bdw: Enable resource streamer on Broadwell
On Tue, 6 May 2014 22:25:04 +0300 Abdiel Janulgue abdiel.janul...@linux.intel.com wrote: From: Abdiel Janulgue abdiel.janul...@linux.intel.com This is a re-spin of my resource streamer patchset from October adapted to enable the feature on Broadwell instead. The resource streamer is a hw-feature that helps in reducing commands being submitted by the CPU. Haswell initially has this feature. Unfortunately, HSW seems to have problems switching between non-RS and RS-enabled commands[1]. On BDW however it works seamlessly as expected. The i-g-t test comes next on a separate patch-series. -- [1] http://lists.freedesktop.org/archives/intel-gfx/2014-May/044577.html Abdiel Janulgue (2): drm/i915/bdw: Enable resource streamer bits on MI_BATCH_BUFFER_START drm/i915/bdw: Expose I915_EXEC_RESOURCE_STREAMER flag drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 drivers/gpu/drm/i915/i915_reg.h|1 + drivers/gpu/drm/i915/intel_ringbuffer.c|3 ++- drivers/gpu/drm/i915/intel_ringbuffer.h|1 + include/uapi/drm/i915_drm.h|7 ++- 5 files changed, 18 insertions(+), 2 deletions(-) These seem trivial enough... have you seen cases where you'd like to enable it in Mesa? If so, it probably makes sense to merge this patch so you can do your tuning and enabling on the Mesa side... -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Prefault the entire object on first page fault
On Tue, Jun 10, 2014 at 04:14:40AM -0700, Chris Wilson wrote:
Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the object is resident in the global GTT. The
downside is that we pay the entire cost of faulting the object upon the
first hit, for which we in return receive the benefit of removing the
per-page faulting overhead.
On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
Upload rate for 2 linear surfaces:8127MiB/s - 8134MiB/s
Upload rate for 2 tiled surfaces: 8607MiB/s - 8625MiB/s
Upload rate for 4 linear surfaces:8127MiB/s - 8127MiB/s
Upload rate for 4 tiled surfaces: 8611MiB/s - 8602MiB/s
Upload rate for 8 linear surfaces:8114MiB/s - 8124MiB/s
Upload rate for 8 tiled surfaces: 8601MiB/s - 8603MiB/s
Upload rate for 16 linear surfaces: 8110MiB/s - 8123MiB/s
Upload rate for 16 tiled surfaces:8595MiB/s - 8606MiB/s
Upload rate for 32 linear surfaces: 8104MiB/s - 8121MiB/s
Upload rate for 32 tiled surfaces:8589MiB/s - 8605MiB/s
Upload rate for 64 linear surfaces: 8107MiB/s - 8121MiB/s
Upload rate for 64 tiled surfaces:2013MiB/s - 3017MiB/s
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Goel, Akash akash.g...@intel.com
For reproducibility it would be nice to have the testcase info, assuming
it's something from i-g-t. Other than that, I think this change looks good.
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3aaf7e01235e..e1f68f06c2ef 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1704,14 +1704,26 @@ int i915_gem_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
if (ret)
goto unpin;
- obj-fault_mappable = true;
-
+ /* Finally, remap it using the new GTT offset */
pfn = dev_priv-gtt.mappable_base + i915_gem_obj_ggtt_offset(obj);
pfn = PAGE_SHIFT;
- pfn += page_offset;
- /* Finally, remap it using the new GTT offset */
- ret = vm_insert_pfn(vma, (unsigned long)vmf-virtual_address, pfn);
+ if (!obj-fault_mappable) {
+ int i;
+
+ for (i = 0; i obj-base.size PAGE_SHIFT; i++) {
+ ret = vm_insert_pfn(vma,
+ (unsigned long)vma-vm_start + i *
PAGE_SIZE,
+ pfn + i);
+ if (ret)
+ break;
+ }
+
+ obj-fault_mappable = true;
+ } else
+ ret = vm_insert_pfn(vma,
+ (unsigned long)vmf-virtual_address,
+ pfn + page_offset);
unpin:
i915_gem_object_ggtt_unpin(obj);
unlock:
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use remap_pfn_range() to prefault all PTE in a single pass
On Tue, Jun 10, 2014 at 04:14:41AM -0700, Chris Wilson wrote:
On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
Upload rate for 2 linear surfaces: 8134MiB/s - 8154MiB/s
Upload rate for 2 tiled surfaces: 8625MiB/s - 8632MiB/s
Upload rate for 4 linear surfaces: 8127MiB/s - 8134MiB/s
Upload rate for 4 tiled surfaces: 8602MiB/s - 8629MiB/s
Upload rate for 8 linear surfaces: 8124MiB/s - 8137MiB/s
Upload rate for 8 tiled surfaces: 8603MiB/s - 8624MiB/s
Upload rate for 16 linear surfaces: 8123MiB/s - 8128MiB/s
Upload rate for 16 tiled surfaces: 8606MiB/s - 8618MiB/s
Upload rate for 32 linear surfaces: 8121MiB/s - 8128MiB/s
Upload rate for 32 tiled surfaces: 8605MiB/s - 8614MiB/s
Upload rate for 64 linear surfaces: 8121MiB/s - 8127MiB/s
Upload rate for 64 tiled surfaces: 3017MiB/s - 5127MiB/s
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
The translation from vm_insert_pfn to remap_pfn_range looks correct. I don't
know
these APIs particularly well though. I wonder if there's any reason it would be
unsafe to call remap_pfn_range from .fault() since it seems to only be used in
.mmap() handlers in other places. Reading their implementations, nothing jumped
out, so I'll say
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
with the note that you may want to take a look just in case.
---
drivers/gpu/drm/i915/i915_gem.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e1f68f06c2ef..7128d389a6ff 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1709,21 +1709,19 @@ int i915_gem_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
pfn = PAGE_SHIFT;
if (!obj-fault_mappable) {
- int i;
-
- for (i = 0; i obj-base.size PAGE_SHIFT; i++) {
- ret = vm_insert_pfn(vma,
- (unsigned long)vma-vm_start + i *
PAGE_SIZE,
- pfn + i);
- if (ret)
- break;
- }
-
- obj-fault_mappable = true;
- } else
- ret = vm_insert_pfn(vma,
- (unsigned long)vmf-virtual_address,
- pfn + page_offset);
+ ret = remap_pfn_range(vma,
+ vma-vm_start,
+ pfn,
+ obj-base.size,
+ vma-vm_page_prot);
+ obj-fault_mappable = ret == 0;
+ } else {
+ ret = remap_pfn_range(vma,
+ (unsigned long)vmf-virtual_address,
+ pfn + page_offset,
+ PAGE_SIZE,
+ vma-vm_page_prot);
+ }
unpin:
i915_gem_object_ggtt_unpin(obj);
unlock:
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4
On Tue, 10 Jun 2014 17:26:45 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jun 10, 2014 at 05:41:49PM +0300, Imre Deak wrote: On Tue, 2014-06-10 at 15:57 +0200, Daniel Vetter wrote: On Tue, Jun 10, 2014 at 04:42:50PM +0300, Imre Deak wrote: On Wed, 2014-06-04 at 13:45 -0700, Jesse Barnes wrote: This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_pm.c | 20 drivers/gpu/drm/i915/intel_uncore.c | 2 +- 5 files changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 66c6ffb..7148eac 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -521,7 +521,7 @@ static int i915_drm_freeze(struct drm_device *dev) drm_irq_uninstall(dev); dev_priv-enable_hotplug_processing = false; - intel_disable_gt_powersave(dev); + intel_suspend_gt_powersave(dev); I realized now that we actually do need to enable RC6 explicitly. If we get here right after runtime resume, the deferred RC6 enabling might be still pending and so RC6 might not be enabled. Seems like we could just flush the enable if it was outstanding? Hm, for runtime pm we might schedule the delayed rps work with a 0 delay, just to get the gpu going faster. Just an aside. Also some runtime pm vs system suspend tests in igt would be good if we don't have them yet. And if we have them some analysis why this didn't blow up in testing (and something to address that gap if feasible). To clarify the above is about the new functionality to enable deeper system wide power states. Atm, we don't have a bug related to the above runtime resume-system suspend sequence, since we explicitly disable gt power saving/RC6. For deeper power states we have to do the opposite and leave RC6 enabled and that's what I commented on. Well I just want to make sure that we have test coverage. If Jesse has run all the rpm tests with piglit run -t rpm and it didn't blow up we need to fix this gap. I have not... I'm not sure how to test this though, as I think we'd need to measure c states or power when we do a suspend. If we checked for RC6 enable at resume, we'd probably race with the enable work queue. Either way, we should add some asserts to the suspend path to make sure all the conditions we need for minimum power are met. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4
On Wed, 11 Jun 2014 15:21:16 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Tue, 10 Jun 2014 17:26:45 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jun 10, 2014 at 05:41:49PM +0300, Imre Deak wrote: On Tue, 2014-06-10 at 15:57 +0200, Daniel Vetter wrote: On Tue, Jun 10, 2014 at 04:42:50PM +0300, Imre Deak wrote: On Wed, 2014-06-04 at 13:45 -0700, Jesse Barnes wrote: This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_pm.c | 20 drivers/gpu/drm/i915/intel_uncore.c | 2 +- 5 files changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 66c6ffb..7148eac 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -521,7 +521,7 @@ static int i915_drm_freeze(struct drm_device *dev) drm_irq_uninstall(dev); dev_priv-enable_hotplug_processing = false; - intel_disable_gt_powersave(dev); + intel_suspend_gt_powersave(dev); I realized now that we actually do need to enable RC6 explicitly. If we get here right after runtime resume, the deferred RC6 enabling might be still pending and so RC6 might not be enabled. Seems like we could just flush the enable if it was outstanding? Oh and I see we already have the flush in v4... do you think we might not actually arm the deferred enable work before we get here? I think the runtime_resume and suspend calls should be serialized, but if not we'd need some locking I guess... Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/bdw: Enable resource streamer on Broadwell
On 11.06.2014 11:10, Jesse Barnes wrote: On Tue, 6 May 2014 22:25:04 +0300 Abdiel Janulgue abdiel.janul...@linux.intel.com wrote: From: Abdiel Janulgue abdiel.janul...@linux.intel.com This is a re-spin of my resource streamer patchset from October adapted to enable the feature on Broadwell instead. The resource streamer is a hw-feature that helps in reducing commands being submitted by the CPU. Haswell initially has this feature. Unfortunately, HSW seems to have problems switching between non-RS and RS-enabled commands[1]. On BDW however it works seamlessly as expected. The i-g-t test comes next on a separate patch-series. -- [1] http://lists.freedesktop.org/archives/intel-gfx/2014-May/044577.html Abdiel Janulgue (2): drm/i915/bdw: Enable resource streamer bits on MI_BATCH_BUFFER_START drm/i915/bdw: Expose I915_EXEC_RESOURCE_STREAMER flag drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 drivers/gpu/drm/i915/i915_reg.h|1 + drivers/gpu/drm/i915/intel_ringbuffer.c|3 ++- drivers/gpu/drm/i915/intel_ringbuffer.h|1 + include/uapi/drm/i915_drm.h|7 ++- 5 files changed, 18 insertions(+), 2 deletions(-) These seem trivial enough... have you seen cases where you'd like to enable it in Mesa? If so, it probably makes sense to merge this patch so you can do your tuning and enabling on the Mesa side... I've had some Mesa patches since last year. Unfortunately, the changes didn't give any dramatic performance improvements. On the other hand, I admit: 1. I've only run it against GLBenchmark and Unigine benchmarks. Discussion with Portland folks seem to suggest that we need to have a comprehensive run with more benchmarks. 2. I only did the benchmarks in Haswell. Would be nice to see how it does on Broadwell. I agree though that further tuning of the performance needs to be done on the Mesa side. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] manage multiple entries of scratch page with scatterlist
Hi, I am working on a feature to implement support for gem objects to have variable size and realized a problem with the current implementation. Please advice me how to handle this situation efficiently. In this implementation the backing store of the object is replaced with scratch pages according to input range; Initially I store table entries in an array, replace relevant entries with scratch pages and I am using sg_alloc_table_from_pages() to create new sg_table which is assigned to the object. This implementation works as expected but I realized it is wasting memory as scratch page count increases. Consider the worst case scenario where all pages are replaced with scratch pages. The fn sg_alloc_table_from_pages() first computes the number of chunks based on the page frame numbers. PFNs that are consecutive form a chunk and it allocates scatterlists for each chunk which form the sg_table. In case of scratch pages they get the same pfn for each page and sg_alloc_table_from_pages() considers them not part of a chunk and it allocates scatterlist structure for each scratch page which takes lot of memory as the object size increases. I have to tried to modify sg_alloc_table_from_pages() implementation to check for scratch pfn and consider them as single chunk but after the update when iterating through for_each_sg_page() I am seeing different page addresses instead of all pointing to scratch page. Eg. In an object of size 8 pages, scratch_page = ea000112 and pfn: 0x00044800, the result I get is, page[0]: ea000112, pfn: 0x00044800, page[1]: ea0001120040, pfn: 0x00044801, page[2]: ea0001120080, pfn: 0x00044802, page[3]: ea00011200c0, pfn: 0x00044803, page[4]: ea0001120100, pfn: 0x00044804, page[5]: ea0001120140, pfn: 0x00044805, page[6]: ea0001120180, pfn: 0x00044806, page[7]: ea00011201c0, pfn: 0x00044807, How to manage multiple pages that have same pfn with a single scatterlist and still have it's length equal to (PAGE_SIZE*chunk_size)? I would really appreciate any suggestions to improve this implementation. regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: drop punit freq staus read after setting idle
On 6/11/2014 10:26 PM, Ville Syrjälä wrote: On Fri, Jun 06, 2014 at 08:03:20AM -0700, Jesse Barnes wrote: On Fri, 6 Jun 2014 11:29:24 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Thu, Jun 05, 2014 at 01:49:34PM -0700, Jesse Barnes wrote: This may take awhile (~10ms), and we don't need to make noise about it. References: https://bugs.freedesktop.org/show_bug.cgi?id=75244 Tested-by: huax...@intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ee27d74..4eebfd8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3227,10 +3227,6 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv) vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, dev_priv-rps.min_freq_softlimit); - if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS)) -GENFREQSTATUS) == 0, 5)) - DRM_ERROR(timed out waiting for Punit\n); - As I recall the entire point of this was to make sure the frequency really drops before we allow turning off the clock. I'm not sure if we can trust that the frequency (and more importantly the voltage) will drop if we allow turning off the clock before the transition is complete. well, we may need to increase the timeout then... let's see if that helps with the bug. FYI I played around with my BYT a bit and it doesn't appear to require this force gfx clock on part of the workaround. I was polling VLV_GTLC_SURVIVABILITY_REG and VLV_GTLC_PW_STATUS to make sure both render and media wells and the gfx clock remain off, and I was also monitoring vnn via svid. While that was going on I just rewrote PUNIT_REG_GPU_FREQ_REQ to make Punit change the frequency, and sure enough it did, and svid showed me that vnn had also changed. So it appears there's no need to have the gfx clock on to change its frequency on this BYT. I wonder if this part of the workaround was only needed on older parts. Deepak, any ideas? Yes ville, this was added initial for older parts and force gfx clock was part of the workaround. We have not verified this on newer parts. Let me check with hw guys to see if workaround still exits and when this was fixed. Thanks Deepak ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
