Re: [Intel-gfx] [PATCH] tests/gem_userptr_blits: Race between object creation and multi-threaded mm ops
Unfortunately Android threads do not support cancel and testcancel, so this Test cannot build for android. Do we really need a cancellation point, since we don't need to cancel the thread. Tvrtko's original solution seemed workable, if a bit less polished. Tim -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Chris Wilson Sent: Monday, July 14, 2014 2:28 PM To: Tvrtko Ursulin Cc: Intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] tests/gem_userptr_blits: Race between object creation and multi-threaded mm ops On Mon, Jul 14, 2014 at 02:13:22PM +0100, Tvrtko Ursulin wrote: On 07/14/2014 02:07 PM, Chris Wilson wrote: You don't have any cancellation points in the loop. (mmap may or may not be, it is not required to be.) But rather than use a global, just pass a pointer to a local struct. It doesn't need both a cancellation point and a flag. Should I just add pthread_testcancel in the loop and not have any flag at all? testcancel also neatly avoids the handwavely lack of mb(). Barrier for what? But it doesn't matter, I'll re-spin with testcancel. It just makes an assumption that the compiler and processor don't skip the read. Since it so simple to be pedagolically correct, it seems pointless to leave it using volatile. Oh, and igt_assert. But kill the asserts in mm_stress_thread() first. Why remove completely? My thinking was to use assert vs igt_assert to distinguish between assumptions about system behaviour, and igt_assert for assertions about tested functionality. If the assert fires you make the igt test runner angry. Might as well report a test failure rather than break down completely. I am not familiar with the test runner, but if it cannot handle a test failing in a way other than it expects it so it deserves to be angry. :) But OK, I'll change it. Actualy the SIGABRT will be delivered to the thread so you just get an ugly assert and a PASS if you do not propagate the failure... -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 mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_userptr_blits: Race between object creation and multi-threaded mm ops
On 07/18/2014 10:20 AM, Gore, Tim wrote: Unfortunately Android threads do not support cancel and testcancel, so this Test cannot build for android. Do we really need a cancellation point, since we don't need to cancel the thread. Tvrtko's original solution seemed workable, if a bit less polished. Solution with a flag is fine in my opinion, but I also need to get rid of asserts in the thread. This is was Chris was pointing out, I always forget that threads have too much independence so SIGBART in a thread won't kill the process. I've put it on my TODO for the lower priority tasks, since I would still like to propagate any failures in the thread to subtest fail. Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2 2/3] drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter
On 7/17/2014 5:25 PM, Chris Wilson wrote: On Wed, Jul 16, 2014 at 05:22:38PM +0100, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The context used to execute a batchbuffer is becoming increasingly important. Duplicating to avoid modifications to the original trace. I am sure we don't want both. The structure encoding is exposed to userspace so we are free to update the tracepoints within reason. As you can see by the next patch in the series, I plan to add a callback inside the trace. My original patch modified the existing trace, but (if I've understood correctly) Daniel asked for a duplicated trace to avoid adding the callback into the existing one. I would also like a better ctx identifier than its pointer. Using the pointer for tracking objects makes it more difficult to read traces (although it is easy for scripts). I use the VM pointer to track the ppgtt; that pointer is also printed by several other traces, including the ppgtt init/release ones that I've submitted for comments in this series. However, I don't mind changing the way we identify the ctx as long as I still have access to the VM pointer. I'll have a look at the possible ways of identifying the ctx and I'll try to find a better solution than the current one. thanks, Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
On Thu, Jul 17, 2014 at 02:31:14PM -0700, Ben Widawsky wrote:
- for_each_ring(useless, dev_priv, i) {
+ for_each_ring(to, dev_priv, i) {
u16 signal_offset =
(GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
u32 *tmp = error-semaphore_obj-pages[0];
+ int idx = intel_ring_sync_index(ring, to);
- ering-semaphore_mboxes[i] = tmp[signal_offset];
- ering-semaphore_seqno[i] = ring-semaphore.sync_seqno[i];
+ ering-semaphore_mboxes[idx] = tmp[signal_offset];
+ ering-semaphore_seqno[idx] = ring-semaphore.sync_seqno[idx];
}
}
This patch looks correct to me.
We're still looping over all the rings aren't we? we'll override the
array when ring == to?
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] Future preparation patches
On Fri, Jul 18, 2014 at 11:04:03AM +0530, sonika.jin...@intel.com wrote: From: Sonika Jindal sonika.jin...@intel.com This series prepares future platform enabling by changing HAS_PCH_SPLIT to more appropriate check since the code accessed may not have anything to do with having PCH or not. Hi Sonika, HAS_PCH_SPLIT() is true for Ironlake (gen 5) as it's paired with the Ibex Peak PCH. In various patches, the condition needs to be INTEL_INFO(dev)-gen 5 then. -- Damien Sonika Jindal (7): drm/i915: Allowing changing of wm latencies for other valid platforms drm/i915: Returning the right VGA control reg for other platforms drm/i915: Setting legacy palette correctly for different platforms drm/i915: Returning from increase/decrease of pllclock when invalid drm/i915: Writing proper check for reading of pipe status reg drm/i915: Replace HAS_PCH_SPLIT which incorrectly lets some platforms in drm/i915: Avoid incorrect returning for some platforms drivers/gpu/drm/i915/i915_debugfs.c |6 +++--- drivers/gpu/drm/i915/i915_drv.h |6 +++--- drivers/gpu/drm/i915/intel_display.c |8 drivers/gpu/drm/i915/intel_hdmi.c|4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-) -- 1.7.10.4 ___ 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 0/7] Future preparation patches
On 7/18/2014 4:26 PM, Damien Lespiau wrote: On Fri, Jul 18, 2014 at 11:04:03AM +0530, sonika.jin...@intel.com wrote: From: Sonika Jindal sonika.jin...@intel.com This series prepares future platform enabling by changing HAS_PCH_SPLIT to more appropriate check since the code accessed may not have anything to do with having PCH or not. Hi Sonika, HAS_PCH_SPLIT() is true for Ironlake (gen 5) as it's paired with the Ibex Peak PCH. In various patches, the condition needs to be INTEL_INFO(dev)-gen 5 then. I am sorry, my understanding was that HAS_PCH_SPLIT is equivalent to (gen 5 !(IS_VALLEYVIEW) ) So, is it like, HAS_PCH_SPLIT is equivalent to (gen =5 !(IS_VALEYVIEW)) -Sonika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Optimize the i915_gem_gtt_finish_object function
On Fri, Jul 18, 2014 at 1:16 AM, Ben Widawsky b...@bwidawsk.net wrote:
On Fri, Jul 11, 2014 at 10:20:08AM -0700, armin.c.re...@intel.com wrote:
From: Armin Reese armin.c.re...@intel.com
Signed-off-by: Armin Reese armin.c.re...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index afd4eef..7e2190e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1624,18 +1624,17 @@ static void ggtt_unbind_vma(struct i915_vma *vma)
void i915_gem_gtt_finish_object(struct drm_i915_gem_object *obj)
{
- struct drm_device *dev = obj-base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- bool interruptible;
-
- interruptible = do_idling(dev_priv);
+ if (!obj-has_dma_mapping) {
+ struct drm_device *dev = obj-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool interruptible = do_idling(dev_priv);
- if (!obj-has_dma_mapping)
dma_unmap_sg(dev-pdev-dev,
obj-pages-sgl, obj-pages-nents,
PCI_DMA_BIDIRECTIONAL);
- undo_idling(dev_priv, interruptible);
+ undo_idling(dev_priv, interruptible);
+ }
}
static void i915_gtt_color_adjust(struct drm_mm_node *node,
Note that this doesn't do much on platforms you care about.
To elaborate: This w/a is _only_ used on ironlake when the iommu is
enabled. Also the performance impact of it is so disastrous that any
kind of optimization is pointless.
-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 0/7] Future preparation patches
On Fri, Jul 18, 2014 at 04:53:34PM +0530, Jindal, Sonika wrote: On 7/18/2014 4:26 PM, Damien Lespiau wrote: On Fri, Jul 18, 2014 at 11:04:03AM +0530, sonika.jin...@intel.com wrote: From: Sonika Jindal sonika.jin...@intel.com This series prepares future platform enabling by changing HAS_PCH_SPLIT to more appropriate check since the code accessed may not have anything to do with having PCH or not. Hi Sonika, HAS_PCH_SPLIT() is true for Ironlake (gen 5) as it's paired with the Ibex Peak PCH. In various patches, the condition needs to be INTEL_INFO(dev)-gen 5 then. I am sorry, my understanding was that HAS_PCH_SPLIT is equivalent to (gen 5 !(IS_VALLEYVIEW) ) So, is it like, HAS_PCH_SPLIT is equivalent to (gen =5 !(IS_VALEYVIEW)) Yes, indeed! -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not unmap object unless no other VMAs reference it
On Thu, Jul 17, 2014 at 04:45:02PM -0700, Ben Widawsky wrote:
On Fri, Jul 11, 2014 at 10:20:07AM -0700, armin.c.re...@intel.com wrote:
From: Armin Reese armin.c.re...@intel.com
Signed-off-by: Armin Reese armin.c.re...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 87d0aac..676e5f4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2922,8 +2922,6 @@ int i915_vma_unbind(struct i915_vma *vma)
vma-unbind_vma(vma);
- i915_gem_gtt_finish_object(obj);
-
list_del_init(vma-mm_list);
/* Avoid an unnecessary call to unbind on rebind. */
if (i915_is_ggtt(vma-vm))
@@ -2934,8 +2932,10 @@ int i915_vma_unbind(struct i915_vma *vma)
/* Since the unbound list is global, only move to that list if
* no more VMAs exist. */
- if (list_empty(obj-vma_list))
+ if (list_empty(obj-vma_list)) {
+ i915_gem_gtt_finish_object(obj);
list_move_tail(obj-global_list, dev_priv-mm.unbound_list);
+ }
/* And finally now the object is completely decoupled from this vma,
* we can drop its hold on the backing storage and allow it to be
This patch is a fix, and therefore needs a commit message to explain the
bug that you're trying to fix. I will help.
Indeed, and thanks a lot for providing the commit message. I've added for
full ppgtt as requested and merged the patch to dinq.
Thanks, Daniel
When using an IOMMU, GEM objects are mapped by their DMA address as the
physical address is unknown. This depends on the underlying IOMMU
driver to map and unmap the physical pages properly as defined in
intel_iommu.c.
The current code will tell the IOMMU to unmap the GEM BO's pages on the
destruction of the first VMA that maps that BO. This is clearly wrong
as there may be other VMAs mapping that BO (using flink). The scanout
is one such example.
The patch fixes this issue by only unmapping the DMA maps when there are
no more VMAs mapping that object. This is equivalent to when an object
is considered unbound as can be seen by the code. On the first VMA that
again because bound, we will remap.
An alternate solution would be to move the dma mapping to object
creation and destrubtion. I am not sure if this is considered an
unfriendly thing to do.
Some notes to backporters:
The bug can never be hit without enabling the IOMMU. The existing code
will also do the right thing when the object is shared via dmabuf. The
failure should be demonstrable with flink. In cases when not using
intel_iommu_strict it is likely (likely, as defined by: off the top of
my head) on current workloads to *not* hit this bug since we often
teardown all VMAs for an object shared across multiple VMs. We also
finish access to that object before the first dma_unmapping.
intel_iommu_strict with flinked buffers is likely to hit this issue.
As a side note:
I was expecting this to be fixed as part of Daniels lifetime tracking
plans. I had imagined that would have a handler run when refcount hits 0
that can do the dma_unmap. Therefore I assume everything in that
list_empty() condition is a temporary hack.
This patch is:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
--
Ben Widawsky, Intel Open Source Technology Center
___
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] [RFC v2 2/3] drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter
On Fri, Jul 18, 2014 at 10:43:36AM +0100, Ceraolo Spurio, Daniele wrote: On 7/17/2014 5:25 PM, Chris Wilson wrote: On Wed, Jul 16, 2014 at 05:22:38PM +0100, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The context used to execute a batchbuffer is becoming increasingly important. Duplicating to avoid modifications to the original trace. I am sure we don't want both. The structure encoding is exposed to userspace so we are free to update the tracepoints within reason. As you can see by the next patch in the series, I plan to add a callback inside the trace. My original patch modified the existing trace, but (if I've understood correctly) Daniel asked for a duplicated trace to avoid adding the callback into the existing one. I guess there was a misunderstanding. I was worried about changing the tracepoint, but apparently Chris disagrees. The callback in the tracepoint is an unrelated issue and a no-go either way. -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] i915 / 3.15 intermittently boots into blank screeen
On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: Hi list, you were very helpful to nail down the interrupt storm issue a year ago, I hope we can track this down, too. I'm experiencing an issue with 3.15.5 on my Lenovo T400: When my machine boots, I can see some of the boot messages flying by (quite fast because the machine has a SSD). On a usual boot, the screen would go blank with the backlight off, come back on and other boot messages are visible in a different resolution. Finally the screen flickers once and shows the GDM login. Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. This happens with my custom built kernel 3.15.5 but not with the Debian standard kernel 3.2.0 and IIRC neither with my custom built 3.14 kernels. Would a drm debug log help and if so, what kernel parameters should I use to generate it? Your box seems to die in the initial modeset, which is done with the console_lock held. Which means any crashdumps in dmesg won't get out to netconsole or anything else unfortunately. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. -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 0/7] Future preparation patches
On Fri, Jul 18, 2014 at 02:04:56PM +0100, Damien Lespiau wrote: On Fri, Jul 18, 2014 at 04:53:34PM +0530, Jindal, Sonika wrote: On 7/18/2014 4:26 PM, Damien Lespiau wrote: On Fri, Jul 18, 2014 at 11:04:03AM +0530, sonika.jin...@intel.com wrote: From: Sonika Jindal sonika.jin...@intel.com This series prepares future platform enabling by changing HAS_PCH_SPLIT to more appropriate check since the code accessed may not have anything to do with having PCH or not. Hi Sonika, HAS_PCH_SPLIT() is true for Ironlake (gen 5) as it's paired with the Ibex Peak PCH. In various patches, the condition needs to be INTEL_INFO(dev)-gen 5 then. I am sorry, my understanding was that HAS_PCH_SPLIT is equivalent to (gen 5 !(IS_VALLEYVIEW) ) So, is it like, HAS_PCH_SPLIT is equivalent to (gen =5 !(IS_VALEYVIEW)) Yes, indeed! Since the patches need to be respun anyway, I vote for the introduction of HAS_GMCH_DISPLAY for the gen 5 || IS_VLV condition. Since vlv (i.e. byt + chv) have essentially inherited the gmch display block from gen3/4. I think that would help the readability of the code quite a bit. Comments? -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
[Intel-gfx] [PATCH] drm/i915: capture_reg_state interrupt registers for Gen8
After unclaimed register detection was enabled for BDW, I started seeing
warnings while reading registers 0x4400c (DEIER) and 0x4401c (GTIER).
From Gen8, DEIER has been split per display engine pipe, and GTIER has
been split in 4.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 19 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 37b3e42..9e6f201 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -315,6 +315,8 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 pipe_ier[I915_MAX_PIPES]; /* gen8 */
+ u32 gt_ier[4]; /* gen8 */
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 71aee43..1e57574 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -393,6 +393,16 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
if (INTEL_INFO(dev)-gen == 7)
err_printf(m, ERR_INT: 0x%08x\n, error-err_int);
+ if (INTEL_INFO(dev)-gen == 8) {
+ for (i = 0; i ARRAY_SIZE(error-pipe_ier); i++)
+ err_printf(m, PIPE_IER_%d: 0x%08x\n, i,
+ error-pipe_ier[i]);
+
+ for (i = 0; i ARRAY_SIZE(error-gt_ier); i++)
+ err_printf(m, GT_IER_%d: 0x%08x\n, i,
+ error-gt_ier[i]);
+ }
+
for (i = 0; i ARRAY_SIZE(error-ring); i++) {
err_printf(m, %s command stream:\n, ring_str(i));
i915_ring_error_state(m, dev, error-ring[i]);
@@ -1122,6 +1132,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i, pipe;
/* General organization
* 1. Registers specific to a single generation
@@ -1166,7 +1177,13 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
+ if (IS_GEN8(dev)) {
+ for_each_pipe(pipe)
+ error-pipe_ier[pipe] =
+ I915_READ(GEN8_DE_PIPE_IER(pipe));
+ for (i = 0; i 4; i++)
+ error-gt_ier[i] = I915_READ(GEN8_GT_IER(i));
+ } else if (HAS_PCH_SPLIT(dev))
error-ier = I915_READ(DEIER) | I915_READ(GTIER);
else {
if (IS_GEN2(dev))
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
On Thu, Jul 17, 2014 at 05:37:12PM +, Kay, Allen M wrote:
That sounds great. Tiejun could you confirm that with windows driver guys
too?
I believe windows driver can also assume specific CPU/PCH combos. I will
discuss this with native Windows driver guys. Preferably, the same code path
can be used for both native and virtualization cases to avoid frequent
breakage as most developers and QA do not test new code changes in
virtualization environment.
I have verified that Windows driver do not need to write to any MCH PCI
registers on HSW/BDW so the PCI write function can be removed. The MCH PCI
registers that need to be read, we are working with HW team to get them
mirrored in GPU MMIO registers in future HW.
For the MCH PCI registers that do need to be read - can you tell us which
ones those are?
Thank you!
Allen
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Michael S. Tsirkin
Sent: Thursday, July 03, 2014 1:28 PM
To: Jesse Barnes
Cc: peter.mayd...@linaro.org; xen-de...@lists.xensource.com; Ross Philipson;
Konrad Rzeszutek Wilk; airl...@linux.ie; daniel.vet...@ffwll.ch;
intel-gfx@lists.freedesktop.org; kelly.zyta...@amd.com;
qemu-de...@nongnu.org; Anthony Perard; Stefano Stabellini;
anth...@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel
IGD passthrough support
On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
On Thu, 3 Jul 2014 14:26:12 -0400
Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
With this long thread I lost a bit context about the
challenges that exists. But let me try summarizing it here -
which will hopefully get some consensus.
1). Fix IGD hardware to not use Southbridge magic addresses.
We can moan and moan but I doubt it is going to change.
There are two problems:
- Northbridge (i.e. MCH i.e. PCI host bridge) configuration
space addresses
Right. So in drivers/gpu/drm/i915/i915_dma.c:
1135 #define MCHBAR_I915 0x44
1136 #define MCHBAR_I965 0x48
1147 int reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965 :
MCHBAR_I915;
1152 if (INTEL_INFO(dev)-gen = 4)
1153 pci_read_config_dword(dev_priv-bridge_dev, reg
+ 4, temp_hi);
1154 pci_read_config_dword(dev_priv-bridge_dev, reg,
temp_lo);
1155 mchbar_addr = ((u64)temp_hi 32) | temp_lo;
and
1139 #define DEVEN_REG 0x54
1193 int mchbar_reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965
: MCHBAR_I915;
1202 if (IS_I915G(dev) || IS_I915GM(dev)) {
1203 pci_read_config_dword(dev_priv-bridge_dev,
DEVEN_REG, temp);
1204 enabled = !!(temp DEVEN_MCHBAR_EN);
1205 } else {
1206 pci_read_config_dword(dev_priv-bridge_dev,
mchbar_reg, temp);
1207 enabled = temp 1;
1208 }
- Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID;
some versions of the driver identify it by class, some versions
identify it by slot (1f.0).
Right, So in drivers/gpu/drm/i915/i915_drv.c the giant
intel_detect_pch which sets the pch_type based on :
432 if (pch-vendor == PCI_VENDOR_ID_INTEL) {
433 unsigned short id = pch-device
INTEL_PCH_DEVICE_ID_MASK;
434 dev_priv-pch_id = id;
435
436 if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE)
{
It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
The INTEL_PCH_DEVICE_ID_MASK is 0xff00
To solve the first, make a new machine type, PIIX4-based, and
pass through the registers you need. The patch must document
_exactly_ why the registers are safe to pass.
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
Hi Daniel, Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. Best regards jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [QA 07/18 ww29] Testing report for `drm-intel-testing` (was: Updated -next)
Summary We covered the platform: Broadwell, Baytrail-M, Haswell (mobile, desktop and ULT), Ivybridge, SandyBridge, IronLake. In this circle, 0 new bugs is filed. Finding We found four issues as below, but all of them can be fixed by latest -nightly or latest -fixes . So we didn't file bug. 1) BDW warning while hot plugging DP 2) HSW warning while hot plugging HDMI. 3) 4K Display can cause system hang on BDW E0 stepping cpu. 4) Xwindow rotation failed with multi-display on BDW. One blocking issue: Bug 81140https://bugs.freedesktop.org/show_bug.cgi?id=81140 - [BYT/HSW/BDW/BSW Bisected ]system sporadically boot fail Test Environment Kernel: (drm-intel-testing) dd90826b9a56396c1cc047875b49bb4f27257f9b Merge: 89a6894 50dd905 Author: Daniel Vetter daniel.vet...@ffwll.chmailto:daniel.vet...@ffwll.ch Date: Thu Jul 10 22:33:02 2014 +0200 New power related coverage are as following (Wendy owned). [PM_Turbo] Verify GFX Turbo featurepassed [PM_RC6] Measure RC6 feature's residency counter. Some machines failed because of BIOS. We can't find newer substitute BIOS. Thanks --Sun, Yi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] intel_gpu_top: don't fclose NULL output
--- tools/intel_gpu_top.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c index b5cfda0..fef7f96 100644 --- a/tools/intel_gpu_top.c +++ b/tools/intel_gpu_top.c @@ -711,7 +711,8 @@ int main(int argc, char **argv) } } - fclose(output); +if (output) +fclose(output); intel_register_access_fini(); return 0; -- 2.0.1 - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] intel_gpu_top: aim for 2000 samples per frame
The previous sample rate of ~167 per frame was rather low in relation to frequency of the events being measured and so for example the derived busy status could become quite unstable at times. --- tools/intel_gpu_top.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c index fef7f96..f60e58b 100644 --- a/tools/intel_gpu_top.c +++ b/tools/intel_gpu_top.c @@ -50,7 +50,8 @@ #define FORCEWAKE 0xA18C #define FORCEWAKE_ACK 0x130090 -#define SAMPLES_PER_SEC 1 +/* Aim for ~2000 samples per frame @ 60fps... */ +#define SAMPLES_PER_SEC (60 * 2000) #define SAMPLES_TO_PERCENT_RATIO(SAMPLES_PER_SEC / 100) #define MAX_NUM_TOP_BITS100 -- 2.0.1 - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] intel_reg: add RING_CCID current context ID reg
--- lib/intel_reg.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/intel_reg.h b/lib/intel_reg.h index 8a6e3f1..51430f4 100644 --- a/lib/intel_reg.h +++ b/lib/intel_reg.h @@ -671,6 +671,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. #define RING_NO_REPORT 0x #define RING_ENABLED_MASK 0x0001 +#define RING_CCID 0x150 +#define CCID_ADDR_MASK 0xF000 + /* BitBlt Instructions * -- 2.0.1 - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] intel_reg: rename RING_LEN RING_CTL
This register holds more than the length. This also renames the lsb to
RING_ENABLED.
---
lib/intel_reg.h | 7 ++-
tools/intel_gpu_top.c | 2 +-
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 56459ea..8a6e3f1 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -662,17 +662,14 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#define START_ADDR 0x03F8
#define I830_RING_START_MASK 0xF000
-#define RING_LEN 0x0C
+#define RING_CTL 0x0C
#define RING_NR_PAGES 0x001FF000
#define I830_RING_NR_PAGES 0x001FF000
#define RING_REPORT_MASK0x0006
#define RING_REPORT_64K 0x0002
#define RING_REPORT_128K0x0004
#define RING_NO_REPORT 0x
-#define RING_VALID_MASK 0x0001
-#define RING_VALID 0x0001
-#define RING_INVALID0x
-
+#define RING_ENABLED_MASK 0x0001
/* BitBlt Instructions
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 3115b5e..6e494b1 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -357,7 +357,7 @@ static uint32_t ring_read(struct ring *ring, uint32_t reg)
static void ring_init(struct ring *ring)
{
- ring-size = (((ring_read(ring, RING_LEN) RING_NR_PAGES) 12) + 1)
* 4096;
+ ring-size = (((ring_read(ring, RING_CTL) RING_NR_PAGES) 12) + 1)
* 4096;
}
static void ring_reset(struct ring *ring)
--
2.0.1
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] instdone: Add human readable names for HSW
---
lib/instdone.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/lib/instdone.c b/lib/instdone.c
index 99857e2..57b1635 100644
--- a/lib/instdone.c
+++ b/lib/instdone.c
@@ -381,23 +381,23 @@ init_g4x_instdone1(void)
static void
init_gen7_instdone(void)
{
- gen6_instdone1_bit(1 19, GAM);
+ gen6_instdone1_bit(1 19, Memory Arbiter (GAM));
gen6_instdone1_bit(1 18, GAFM);
- gen6_instdone1_bit(1 17, TSG);
- gen6_instdone1_bit(1 16, VFE);
+ gen6_instdone1_bit(1 17, Thread Spawner (TSG));
+ gen6_instdone1_bit(1 16, Video Front-End (VFE));
gen6_instdone1_bit(1 15, GAFS);
gen6_instdone1_bit(1 14, SVG);
- gen6_instdone1_bit(1 13, URBM);
- gen6_instdone1_bit(1 12, TDG);
- gen6_instdone1_bit(1 9, SF);
- gen6_instdone1_bit(1 8, CL);
- gen6_instdone1_bit(1 7, SOL);
- gen6_instdone1_bit(1 6, GS);
- gen6_instdone1_bit(1 5, DS);
- gen6_instdone1_bit(1 4, TE);
- gen6_instdone1_bit(1 3, HS);
- gen6_instdone1_bit(1 2, VS);
- gen6_instdone1_bit(1 1, VF);
+ gen6_instdone1_bit(1 13, Uni. Ret. Buf. Mgr. (URBM));
+ gen6_instdone1_bit(1 12, Thread Dispatcher (TDG));
+ gen6_instdone1_bit(1 9, FF Strips Fans (SF));
+ gen6_instdone1_bit(1 8, FF Clip Unit (CL));
+ gen6_instdone1_bit(1 7, FF Stream Output Logic (SOL));
+ gen6_instdone1_bit(1 6, FF Geometry Shader (GS));
+ gen6_instdone1_bit(1 5, FF Domain Shader (DS));
+ gen6_instdone1_bit(1 4, FF Tessellation Engine (TE));
+ gen6_instdone1_bit(1 3, FF Hull Shader (HS));
+ gen6_instdone1_bit(1 2, FF Vertex Shader (VS));
+ gen6_instdone1_bit(1 1, FF Vertex Fetch (VF));
}
static void
--
2.0.1
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] intel_gpu_top: hide absolute counter values
The absolute values of the pipeline statistic counters are more
distracting than they are useful.
---
tools/intel_gpu_top.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index e5582fd..0ef26f8 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -809,9 +809,8 @@ int main(int argc, char **argv)
printf(context = % PRIx32 :
%d%% active,
context-id, percent);
} else if
(!context-stats[stat_i].warped) {
- printf( %-15s: % PRIu64
(% PRIu64 /sec),
+ printf( %-15s: (% PRIu64
/sec),
stats_reg_names[stat_i],
-
context-stats[stat_i].end,
(context-stats[stat_i].end -
context-stats[stat_i].start));
} else {
--
2.0.1
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9] intel-gpu-top improvements
Since it seemed like a re-occurring complaint that developers didn't feel they could trust the numbers from intel-gpu-top I reviewed the implementation and came across a few issues that I've tried to address in this series. Just to let others know; I'm also experimenting with the possibility of collecting this data, and more, from the kernel via the perf interface (building on work originally done by Chris Wilson last year) so these may just be stop-gap improvements if those experiments pan out. - Robert Robert Bragg (9): intel_gpu_top: don't fclose NULL output intel_gpu_top: aim for 2000 samples per frame intel_gpu_top: ignore out of range ring pointers intel_gpu_top: read max/current gt freq via sysfs intel_reg: rename RING_LEN RING_CTL intel_reg: add RING_CCID current context ID reg instdone: Add human readable names for HSW intel_gpu_top: account for per context statistics intel_gpu_top: hide absolute counter values lib/instdone.c| 28 +-- lib/intel_reg.h | 8 +- tools/intel_gpu_top.c | 519 ++ 3 files changed, 368 insertions(+), 187 deletions(-) -- 2.0.1 - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] intel_gpu_top: read max/current gt freq via sysfs
---
tools/intel_gpu_top.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7574ef0..3115b5e 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -39,6 +39,9 @@
#include sys/time.h
#include sys/wait.h
#include string.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
#ifdef HAVE_TERMIOS_H
#include termios.h
#endif
@@ -127,6 +130,24 @@ gettime(void)
}
static int
+read_file_int(const char *file)
+{
+ char buf[32];
+ int fd, n;
+
+ fd = open(file, 0);
+ if (fd 0)
+ return -1;
+ n = read(fd, buf, sizeof (buf) - 1);
+ close(fd);
+ if (n 0)
+ return -1;
+
+ buf[n] = '\0';
+ return strtol(buf, 0, 0);
+}
+
+static int
top_bits_sort(const void *a, const void *b)
{
struct top_bit * const *bit_a = a;
@@ -280,6 +301,16 @@ print_clock_info(struct pci_device *pci_dev)
print_clock(render, render_clock);
printf( );
print_clock(display, display_clock);
+ } else {
+ int max_render_clock;
+ int cur_render_clock;
+
+ max_render_clock =
read_file_int(/sys/class/drm/card0/gt_max_freq_mhz);
+ cur_render_clock =
read_file_int(/sys/class/drm/card0/gt_cur_freq_mhz);
+
+ print_clock(max render, max_render_clock);
+ printf( );
+ print_clock(current render, cur_render_clock);
}
--
2.0.1
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] intel_gpu_top: ignore out of range ring pointers
---
tools/intel_gpu_top.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index f60e58b..7574ef0 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -344,6 +344,15 @@ static void ring_sample(struct ring *ring)
ring-head = ring_read(ring, RING_HEAD) HEAD_ADDR;
ring-tail = ring_read(ring, RING_TAIL) TAIL_ADDR;
+ /* We sometimes read spurious, out of range pointers which
+* we want to ignore. We treat them as idle for now... */
+ if (ring-head ring-size || ring-tail ring-size)
+ {
+ fprintf(stderr, Ignoring spurious ring pointer\n);
+ ring-idle++;
+ return;
+ }
+
if (ring-tail == ring-head)
ring-idle++;
--
2.0.1
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] intel_gpu_top: account for per context statistics
The pipeline statistics counters represent per context values and so we
can't assume that a snapshot taken once per second will correspond to the
same context as the last snapshot.
We now read the statistics counters for every sample and before and
after each sample we read the current context id to give us a way
of detecting if the context changes.
There is now a slightly clearer separation between collecting sample
data into a fixed sized array and then handling analytics once per
second before printing/outputing the results.
Signed-off-by: Robert Bragg robert.br...@intel.com
---
tools/intel_gpu_top.c | 490 --
1 file changed, 315 insertions(+), 175 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 6e494b1..e5582fd 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -24,6 +24,7 @@
* Authors:
*Eric Anholt e...@anholt.net
*Eugeni Dodonov eugeni.dodo...@intel.com
+ *Robert Bragg robert.br...@intel.com
*
*/
@@ -67,8 +68,6 @@ struct top_bit {
} top_bits[MAX_NUM_TOP_BITS];
struct top_bit *top_bits_sorted[MAX_NUM_TOP_BITS];
-static uint32_t instdone, instdone1;
-
static const char *bars[] = {
,
▏,
@@ -118,8 +117,57 @@ const char *stats_reg_names[STATS_COUNT] = {
PS depth pass,
};
-uint64_t stats[STATS_COUNT];
-uint64_t last_stats[STATS_COUNT];
+struct pipeline_stat {
+ uint64_t start;
+ uint64_t end;
+ unsigned warped:1;
+};
+
+#define MAX_CONTEXTS 10
+struct context {
+ uint32_t id;
+ struct pipeline_stat stats[STATS_COUNT];
+ int n_samples;
+} contexts[MAX_CONTEXTS];
+struct context *contexts_sorted[MAX_CONTEXTS];
+
+enum rings {
+RING_RENDER,
+RING_BSD,
+RING_BSD6,
+RING_BLIT,
+MAX_RINGS
+};
+
+static struct ring {
+ const char *name;
+ uint32_t mmio;
+ int size;
+
+ /* used for analytics... */
+ uint64_t full;
+ uint64_t idle;
+ int n_samples;
+} rings[MAX_RINGS] = {
+ { .name = render,.mmio = 0x2030 },
+ { .name = bitstream, .mmio = 0x4030 },
+ { .name = bitstream, .mmio = 0x12030 },
+ { .name = blitter, .mmio = 0x22030 }
+};
+
+struct ring_sample {
+uint32_t ccid_start;
+uint32_t ccid_end;
+uint32_t head, tail;
+};
+
+struct sample {
+ uint64_t timestamp;
+ struct ring_sample ring_samples[MAX_RINGS];
+ uint32_t instdone;
+ uint32_t instdone1;
+ uint64_t stats[STATS_COUNT];
+};
static unsigned long
gettime(void)
@@ -163,18 +211,20 @@ top_bits_sort(const void *a, const void *b)
return -1;
}
-static void
-update_idle_bit(struct top_bit *top_bit)
+static int
+contexts_sort(const void *a, const void *b)
{
- uint32_t reg_val;
+ struct context * const * context_a = a;
+ struct context * const * context_b = b;
+ int a_samples = (*context_a)-n_samples;
+ int b_samples = (*context_b)-n_samples;
- if (top_bit-bit-reg == INSTDONE_1)
- reg_val = instdone1;
+ if (a_samples b_samples)
+ return 1;
+ else if (a_samples == b_samples)
+ return 0;
else
- reg_val = instdone;
-
- if ((reg_val top_bit-bit-bit) == 0)
- top_bit-count++;
+ return -1;
}
static void
@@ -342,14 +392,6 @@ print_percentage_bar(float percent, int cur_line_len)
printf(%*s, PERCENTAGE_BAR_END - cur_line_len, );
}
-struct ring {
- const char *name;
- uint32_t mmio;
- int head, tail, size;
- uint64_t full;
- int idle;
-};
-
static uint32_t ring_read(struct ring *ring, uint32_t reg)
{
return INREG(ring-mmio + reg);
@@ -360,72 +402,36 @@ static void ring_init(struct ring *ring)
ring-size = (((ring_read(ring, RING_CTL) RING_NR_PAGES) 12) + 1)
* 4096;
}
-static void ring_reset(struct ring *ring)
-{
- ring-idle = ring-full = 0;
-}
-
-static void ring_sample(struct ring *ring)
-{
- int full;
-
- if (!ring-size)
- return;
-
- ring-head = ring_read(ring, RING_HEAD) HEAD_ADDR;
- ring-tail = ring_read(ring, RING_TAIL) TAIL_ADDR;
-
- /* We sometimes read spurious, out of range pointers which
-* we want to ignore. We treat them as idle for now... */
- if (ring-head ring-size || ring-tail ring-size)
- {
- fprintf(stderr, Ignoring spurious ring pointer\n);
- ring-idle++;
- return;
- }
-
- if (ring-tail == ring-head)
- ring-idle++;
-
- full = ring-tail - ring-head;
- if (full 0)
- full += ring-size;
- ring-full += full;
-}
-
static void ring_print_header(FILE *out, struct ring *ring)
{
-fprintf(out, %.6s%%\tops\t,
-ring-name
- );
+ fprintf(out, %9s%% %6s, ring-name, ops);
}
-static void
[Intel-gfx] [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
This optimization is to remove the ring itself from the list and the logic to
do that
is at intel_ring_sync_index as below:
/*
* rcs - 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
* vcs - 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
* bcs - 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
* vecs - 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
* vcs2 - 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
*/
v2: Skip when from == to (Damien).
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9faebbc..6608bee 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -764,7 +764,7 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
struct intel_engine_cs *ring,
struct drm_i915_error_ring *ering)
{
- struct intel_engine_cs *useless;
+ struct intel_engine_cs *to;
int i;
if (!i915_semaphore_is_enabled(dev_priv-dev))
@@ -776,13 +776,17 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
dev_priv-semaphore_obj,
dev_priv-gtt.base);
- for_each_ring(useless, dev_priv, i) {
+ for_each_ring(to, dev_priv, i) {
u16 signal_offset =
(GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
u32 *tmp = error-semaphore_obj-pages[0];
+ int idx = intel_ring_sync_index(ring, to);
- ering-semaphore_mboxes[i] = tmp[signal_offset];
- ering-semaphore_seqno[i] = ring-semaphore.sync_seqno[i];
+ if (ring-id == to-id)
+ return;
+
+ ering-semaphore_mboxes[idx] = tmp[signal_offset];
+ ering-semaphore_seqno[idx] = ring-semaphore.sync_seqno[idx];
}
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
On Fri, Jul 18, 2014 at 01:39:29AM -0700, Rodrigo Vivi wrote:
semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
This optimization is to remove the ring itself from the list and the logic to
do that
is at intel_ring_sync_index as below:
/*
* rcs - 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
* vcs - 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
* bcs - 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
* vecs - 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
* vcs2 - 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
*/
v2: Skip when from == to (Damien).
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9faebbc..6608bee 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -764,7 +764,7 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
struct intel_engine_cs *ring,
struct drm_i915_error_ring *ering)
{
- struct intel_engine_cs *useless;
+ struct intel_engine_cs *to;
int i;
if (!i915_semaphore_is_enabled(dev_priv-dev))
@@ -776,13 +776,17 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
dev_priv-semaphore_obj,
dev_priv-gtt.base);
- for_each_ring(useless, dev_priv, i) {
+ for_each_ring(to, dev_priv, i) {
u16 signal_offset =
(GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
u32 *tmp = error-semaphore_obj-pages[0];
+ int idx = intel_ring_sync_index(ring, to);
- ering-semaphore_mboxes[i] = tmp[signal_offset];
- ering-semaphore_seqno[i] = ring-semaphore.sync_seqno[i];
+ if (ring-id == to-id)
+ return;
continue; ? you need to skip ring, but you also need to fill the array
when to-id ring-id.
I guess you should also be able to short-circuit the iteration sooner as
well, no need to do the computations. I believe if (ring == to) would
work as well.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
This optimization is to remove the ring itself from the list and the logic to
do that
is at intel_ring_sync_index as below:
/*
* rcs - 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
* vcs - 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
* bcs - 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
* vecs - 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
* vcs2 - 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
*/
v2: Skip when from == to (Damien).
v3: avoid computing idx when from == to (Damien).
use ring == to instead of ring-id == to-id (Damien).
use continue instead of return (Rodrigo).
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9faebbc..1efcf1f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -764,8 +764,8 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
struct intel_engine_cs *ring,
struct drm_i915_error_ring *ering)
{
- struct intel_engine_cs *useless;
- int i;
+ struct intel_engine_cs *to;
+ int i, idx;
if (!i915_semaphore_is_enabled(dev_priv-dev))
return;
@@ -776,13 +776,18 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
dev_priv-semaphore_obj,
dev_priv-gtt.base);
- for_each_ring(useless, dev_priv, i) {
+ for_each_ring(to, dev_priv, i) {
u16 signal_offset =
(GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
u32 *tmp = error-semaphore_obj-pages[0];
- ering-semaphore_mboxes[i] = tmp[signal_offset];
- ering-semaphore_seqno[i] = ring-semaphore.sync_seqno[i];
+ if (ring == to)
+ continue;
+
+ idx = intel_ring_sync_index(ring, to);
+
+ ering-semaphore_mboxes[idx] = tmp[signal_offset];
+ ering-semaphore_seqno[idx] = ring-semaphore.sync_seqno[idx];
}
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
On Fri, Jul 18, 2014 at 02:05:16AM -0700, Rodrigo Vivi wrote:
semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
This optimization is to remove the ring itself from the list and the logic to
do that
is at intel_ring_sync_index as below:
/*
* rcs - 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
* vcs - 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
* bcs - 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
* vecs - 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
* vcs2 - 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
*/
v2: Skip when from == to (Damien).
v3: avoid computing idx when from == to (Damien).
use ring == to instead of ring-id == to-id (Damien).
use continue instead of return (Rodrigo).
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
I guess there are still some details that look weird:
- idx's scope could be reduced to the loop
- there's still some code that is executed on the skipped iteration
that doesn't need to be.
But I believe we shouldn't overflow now at least, so, whether you can be
bothered with those last 2 comments or not:
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
---
drivers/gpu/drm/i915/i915_gpu_error.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9faebbc..1efcf1f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -764,8 +764,8 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
struct intel_engine_cs *ring,
struct drm_i915_error_ring *ering)
{
- struct intel_engine_cs *useless;
- int i;
+ struct intel_engine_cs *to;
+ int i, idx;
if (!i915_semaphore_is_enabled(dev_priv-dev))
return;
@@ -776,13 +776,18 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
dev_priv-semaphore_obj,
dev_priv-gtt.base);
- for_each_ring(useless, dev_priv, i) {
+ for_each_ring(to, dev_priv, i) {
u16 signal_offset =
(GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
u32 *tmp = error-semaphore_obj-pages[0];
- ering-semaphore_mboxes[i] = tmp[signal_offset];
- ering-semaphore_seqno[i] = ring-semaphore.sync_seqno[i];
+ if (ring == to)
+ continue;
+
+ idx = intel_ring_sync_index(ring, to);
+
+ ering-semaphore_mboxes[idx] = tmp[signal_offset];
+ ering-semaphore_seqno[idx] = ring-semaphore.sync_seqno[idx];
}
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
This optimization is to remove the ring itself from the list and the logic to
do that
is at intel_ring_sync_index as below:
/*
* rcs - 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
* vcs - 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
* bcs - 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
* vecs - 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
* vcs2 - 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
*/
v2: Skip when from == to (Damien).
v3: avoid computing idx when from == to (Damien).
use ring == to instead of ring-id == to-id (Damien).
use continue instead of return (Rodrigo).
v4: avoid all unecessary computation (Damien).
reduce idx to loop scope (Damien).
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9faebbc..0b3f694 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -764,7 +764,7 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
struct intel_engine_cs *ring,
struct drm_i915_error_ring *ering)
{
- struct intel_engine_cs *useless;
+ struct intel_engine_cs *to;
int i;
if (!i915_semaphore_is_enabled(dev_priv-dev))
@@ -776,13 +776,20 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
dev_priv-semaphore_obj,
dev_priv-gtt.base);
- for_each_ring(useless, dev_priv, i) {
- u16 signal_offset =
- (GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
- u32 *tmp = error-semaphore_obj-pages[0];
+ for_each_ring(to, dev_priv, i) {
+ int idx;
+ u16 signal_offset;
+ u32 *tmp;
- ering-semaphore_mboxes[i] = tmp[signal_offset];
- ering-semaphore_seqno[i] = ring-semaphore.sync_seqno[i];
+ if (ring == to)
+ continue;
+
+ signal_offset = (GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
+ tmp = error-semaphore_obj-pages[0];
+ idx = intel_ring_sync_index(ring, to);
+
+ ering-semaphore_mboxes[idx] = tmp[signal_offset];
+ ering-semaphore_seqno[idx] = ring-semaphore.sync_seqno[idx];
}
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 / 3.15 intermittently boots into blank screeen
On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann j...@hz6.de wrote: Am 18.07.2014 15:27, schrieb Daniel Vetter: On Thu, Jul 17, 2014 at 10:31:30PM +0200, Jan Niggemann wrote: I'm experiencing an issue with 3.15.5 on my Lenovo T400: Since 3.15 (or 3.14, can't say for sure), the boot starts normally, but the first mode change doesn't occur, resulting in a black screen with backlight on. The system is entirely unresponsive and I can only press the power button until to switch it off. I think the only way to move forward here is to double-check that 3.14 works and 3.15 is broken by recompiling with the same .config (occasionally config changes cause regressions). And then do a full git bisect to find the offending commit. thank you for the feedback. I still have all my custom built kernels, I will test 3.14.0 through 3.14.8 to make sure those were OK and report back. You only need to test 3.14.0, since the backported fixes only contain a very small subset of all patches for 3.15. So it's more efficient to then switch to git bisect between 3.14 and 3.15 directly (after you've confirmed that 3.15.0 is indeed busted). -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
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Oops, missed the -fixes train. But in any case nothing really shocking in here, 2 reverts, 1 quirk and a regression fix a WARN. Cheers, Daniel The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab: Linux 3.16-rc5 (2014-07-13 14:04:33 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-07-18 for you to fetch changes up to c6930992948adf0f8fc1f6ff1da51c5002a2cf95: Revert drm/i915: reverse dp link param selection, prefer fast over wide again (2014-07-14 23:16:54 +0200) Daniel Vetter (2): Revert drm/i915: Don't set the 8to6 dither flag when not scaling drm/i915: Track the primary plane correctly when reassigning planes Dave Airlie (1): Revert drm/i915: reverse dp link param selection, prefer fast over wide again Scot Doyle (1): drm/i915: Ignore VBT backlight presence check on HP Chromebook 14 drivers/gpu/drm/i915/intel_display.c | 4 drivers/gpu/drm/i915/intel_dp.c | 4 ++-- drivers/gpu/drm/i915/intel_lvds.c| 7 +++ drivers/gpu/drm/i915/intel_panel.c | 8 4 files changed, 17 insertions(+), 6 deletions(-) -- 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] [PULL] drm-intel-next
Hi Dave, drm-intel-next-2014-07-11: - fbc improvements when stolen memory is tight (Ben) - cdclk handling improvements for vlv/chv (Ville) - proper fix for stuck primary planes on gmch platforms with cxsr (ImreEbgert Eich) - gen8 hw semaphore support (Ben) - more execlist prep work from Oscar Mateo - locking fixes for primary planes (Matt Roper) - code rework to support runtime pm for dpms on hsw/bdw (Paulo, Imre me), but not yet enabled because some fixes from Paulo haven't made the cut - more gpu boost tuning from Chris - as usual piles of little things all over Cheers, Daniel The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1: Linux 3.16-rc4 (2014-07-06 12:37:51 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-07-11 for you to fetch changes up to 7b3c29f6fd374640266d82aafe6929761469e27b: drm/i915: Make the RPS interrupt generation mask handle the vlv wa (2014-07-10 22:30:40 +0200) - fbc improvements when stolen memory is tight (Ben) - cdclk handling improvements for vlv/chv (Ville) - proper fix for stuck primary planes on gmch platforms with cxsr (ImreEbgert Eich) - gen8 hw semaphore support (Ben) - more execlist prep work from Oscar Mateo - locking fixes for primary planes (Matt Roper) - code rework to support runtime pm for dpms on hsw/bdw (Paulo, Imre me), but not yet enabled because some fixes from Paulo haven't made the cut - more gpu boost tuning from Chris - as usual piles of little things all over Ben Widawsky (11): drm/i915: Move compressed_fb to static allocation drm/i915: Extract CFB threshold calculation drm/i915: Try harder to get FBC drm/i915: gen specific ring init drm/i915: Make semaphore updates more precise drm/i915/bdw: implement semaphore signal drm/i915/bdw: implement semaphore wait drm/i915: Extract semaphore error collection drm/i915/bdw: collect semaphore error state drm/i915: semaphore debugfs drm/i915/bdw: poll semaphores Chris Wilson (7): drm/i915: Show cursor size in debugfs/i915_display_info drm/i915: Restrict GPU boost to the RCS engine drm/i915: Disable RCS flips on Ivybridge drm/i915: Use mmio flips to change tiling mode on Baytrail drm/i915: HWS must be in the mappable region for g33 drm/i915: Move RPS evaluation interval counters to i915-rps drm/i915: Make the RPS interrupt generation mask handle the vlv wa Damien Lespiau (1): drm/i915: Don't cast a pointer to void* unnecessarily Daniel Vetter (19): Merge patches merged by Jani while I was on vacation. Merge tag 'v3.16-rc4' into drm-intel-next-queued drm/i915: Support pf CRC source on haswell transcoder edp drm/i915: Check hw state in assert_can_disable_lcpll drm/i915: Remove spll_refcount for hsw drm/i915: Clean up WRPLL/SPLL #defines drm/i915: Move the SPLL enabling into hsw_crt_pre_enable drm/i915: Move SPLL disabling into hsw_crt_post_disable drm/i915: Add a debugfs file for the shared dpll state drm/i915: Move ddi_pll_sel into the pipe config drm/i915: State readout and cross-checking for ddi_pll_sel drm/i915: Precompute static ddi_pll_sel values in encoders drm/i915: Basic shared dpll support for WRPLLs drm/i915: Document that the pll-mode_set hook is optional drm/i915: State readout support for WRPLLs drm/i915: -disable hook for WRPLLs drm/i915: -enable hook for WRPLLs drm/i915: Switch to common shared dpll framework for WRPLLs drm/i915: Only touch WRPLL hw state in enable/disable hooks Dave Airlie (1): drm/i915: rework digital port IRQ handling (v2) Deepak S (1): drm/i915/vlv: WA for Turbo and RC6 to work together. Egbert Eich (1): DRM/i915: Remove magic to prevent blank screen on gen4 chipsets Fabian Frederick (1): drm/i915: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN Imre Deak (6): drm/i915: gmch: factor out intel_set_memory_cxsr drm/i915: gmch: set SR WMs to valid values before enabling them drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP drm/i915: ddi: move pch setup after encoder-pre_enable drm/i915: ddi: move pch cleanup before encoder-post_disable Jesse Barnes (1): drm/i915: correct BLC vs PWM enable/disable ordering John Harrison (1): drm/i915: Corrected 'file_priv' to 'file' in 'i915_driver_preclose()' Matt Roper (5): drm/i915: Don't try to look up object for non-existent fb drm/i915: Introduce intel_fb_obj() macro drm/i915: Make use of intel_fb_obj() (v2) drm/i915: Add missing locking to primary plane handlers drm/i915: Add a couple WARN()'s
[Intel-gfx] [PULL] topic/core-stuff
Hi Dave, Just flushing out my random drm patches queue. Nothing fancy in here at all. Cheers, Daniel The following changes since commit b957f457fbce30cc4901dc28f2b56f2b15dfe84a: drm/radeon: use helpers (2014-07-18 14:25:23 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-07-18 for you to fetch changes up to 008f40451d0e59f220a4fa13aaf75d04303a01a1: drm: Check for connection_mutex in drm_select_eld (2014-07-18 15:39:30 +0200) Damien Lespiau (2): drm/dp-mst-helper: Avoid reading uninitialized value drm/dp-mst-helper: Don't use uninitialized fields of the sideband message header Fabian Frederick (1): drivers/gpu/drm/drm_buffer.c: remove unnecessary null test before kfree Matt Roper (1): drm/plane-helper: Use proper plane init function Sean Paul (1): drm: Check for connection_mutex in drm_select_eld Thierry Reding (1): drm: Fix function names in kerneldoc drivers/gpu/drm/drm_buffer.c | 6 +- drivers/gpu/drm/drm_crtc.c| 6 +++--- drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++- drivers/gpu/drm/drm_edid.c| 1 + drivers/gpu/drm/drm_plane_helper.c| 7 --- 5 files changed, 12 insertions(+), 12 deletions(-) -- 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] No boot console/Plane B assertion value on 945GM hardware [FIXED!]
Hi Daniel, hi others, Can you please boot with drm.debug=0xe and grab a new dmesg with the backtrace? Ok, thanks for looking into this, and sorry for taking so long. I'm back now and had now finally some availability to check this issue again with the latest kernel. Seems to be fixed, boots now fine with a console. Thanks! Greetings from Sapporo (- which explains my unavailability), Ok, enjoy your stay then ;-) Did. Was ground-shaking. Ehem. We had an earthquake. (-: Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
For the MCH PCI registers that do need to be read - can you tell us which ones those are? In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW. Some of the registers are needed by Ironlake GFX driver which we probably can remove. I did a trace recently on Broadwell, the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4). Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e. case 0x00:/* vendor id */ case 0x02:/* device id */ case 0x08:/* revision id */ case 0x2c:/* sybsystem vendor id */ case 0x2e:/* sybsystem id */ case 0x50:/* SNB: processor graphics control register */ case 0x52:/* processor graphics control register */ case 0xa0:/* top of memory */ case 0xb0:/* ILK: BSM: should read from dev 2 offset 0x5c */ case 0x58:/* SNB: PAVPC Offset */ case 0xa4:/* SNB: graphics base of stolen memory */ case 0xa8:/* SNB: base of GTT stolen memory */ Allen -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Friday, July 18, 2014 6:45 AM To: Kay, Allen M Cc: Michael S. Tsirkin; Jesse Barnes; peter.mayd...@linaro.org; xen-de...@lists.xensource.com; Ross Philipson; airl...@linux.ie; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; kelly.zyta...@amd.com; qemu-de...@nongnu.org; Anthony Perard; Stefano Stabellini; anth...@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support On Thu, Jul 17, 2014 at 05:37:12PM +, Kay, Allen M wrote: That sounds great. Tiejun could you confirm that with windows driver guys too? I believe windows driver can also assume specific CPU/PCH combos. I will discuss this with native Windows driver guys. Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment. I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed. The MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW. For the MCH PCI registers that do need to be read - can you tell us which ones those are? Thank you! Allen -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Michael S. Tsirkin Sent: Thursday, July 03, 2014 1:28 PM To: Jesse Barnes Cc: peter.mayd...@linaro.org; xen-de...@lists.xensource.com; Ross Philipson; Konrad Rzeszutek Wilk; airl...@linux.ie; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; kelly.zyta...@amd.com; qemu-de...@nongnu.org; Anthony Perard; Stefano Stabellini; anth...@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote: On Thu, 3 Jul 2014 14:26:12 -0400 Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote: On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote: On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote: Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto: With this long thread I lost a bit context about the challenges that exists. But let me try summarizing it here - which will hopefully get some consensus. 1). Fix IGD hardware to not use Southbridge magic addresses. We can moan and moan but I doubt it is going to change. There are two problems: - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses Right. So in drivers/gpu/drm/i915/i915_dma.c: 1135 #define MCHBAR_I915 0x44 1136 #define MCHBAR_I965 0x48 1147 int reg = INTEL_INFO(dev)-gen = 4 ? MCHBAR_I965 : MCHBAR_I915; 1152 if (INTEL_INFO(dev)-gen = 4) 1153 pci_read_config_dword(dev_priv-bridge_dev, reg + 4, temp_hi); 1154 pci_read_config_dword(dev_priv-bridge_dev, reg, temp_lo); 1155 mchbar_addr = ((u64)temp_hi 32) | temp_lo; and 1139 #define
Re: [Intel-gfx] [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
On Fri, Jul 18, 2014 at 02:19:40AM -0700, Rodrigo Vivi wrote:
semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
This optimization is to remove the ring itself from the list and the logic to
do that
is at intel_ring_sync_index as below:
/*
* rcs - 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
* vcs - 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
* bcs - 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
* vecs - 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
* vcs2 - 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
*/
v2: Skip when from == to (Damien).
v3: avoid computing idx when from == to (Damien).
use ring == to instead of ring-id == to-id (Damien).
use continue instead of return (Rodrigo).
v4: avoid all unecessary computation (Damien).
reduce idx to loop scope (Damien).
Cc: Damien Lespiau damien.lesp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9faebbc..0b3f694 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -764,7 +764,7 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
struct intel_engine_cs *ring,
struct drm_i915_error_ring *ering)
{
- struct intel_engine_cs *useless;
+ struct intel_engine_cs *to;
int i;
if (!i915_semaphore_is_enabled(dev_priv-dev))
@@ -776,13 +776,20 @@ static void gen8_record_semaphore_state(struct
drm_i915_private *dev_priv,
dev_priv-semaphore_obj,
dev_priv-gtt.base);
- for_each_ring(useless, dev_priv, i) {
- u16 signal_offset =
- (GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
- u32 *tmp = error-semaphore_obj-pages[0];
+ for_each_ring(to, dev_priv, i) {
+ int idx;
+ u16 signal_offset;
+ u32 *tmp;
- ering-semaphore_mboxes[i] = tmp[signal_offset];
- ering-semaphore_seqno[i] = ring-semaphore.sync_seqno[i];
+ if (ring == to)
+ continue;
+
+ signal_offset = (GEN8_SIGNAL_OFFSET(ring, i) PAGE_MASK) / 4;
+ tmp = error-semaphore_obj-pages[0];
+ idx = intel_ring_sync_index(ring, to);
+
+ ering-semaphore_mboxes[idx] = tmp[signal_offset];
+ ering-semaphore_seqno[idx] = ring-semaphore.sync_seqno[idx];
}
}
Just elaborate on previous email from your v1, now that you've fixed the
error state printing, I would have rather not skip the check and instead
expand the array. This would help us find stray, or unexpected writes
with either future bugs, or buggy hardware.
I'm not asking for a v5 (but I did ask you to make a note of what we
miss in the commit message when I responded to v1... but that's okay
too). I am simply explaining the earlier mail in case it was unclear. If
a v5 *does* need to happen anyway, that is still my preference, but I
don't care too much.
(Also, I think v2 in your commit message was (Ben), not (Damien) but
perhaps I missed a conversation somewhere)
Reviewed-by: Ben Widawsky b...@bwidawsk.net
P.S.
I'd be in favor of adding BUG_ON(idx = I915_NUM_RINGS) before return in
intel_ring_sync_index().
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
