[Intel-gfx] [PATCH 4/7] drm/i915: Do one shot unclaimed mmio detection less frequently
We have done unclaimed register access check in normal
(mmio_debug=0) mode once per write. This adds probability
of finding the exact sequence where we did the bad access, but
also adds burden to each write.
As we have mmio_debug available for more fine grained analysis,
give up accuracy of detecting correct spot at the first occurrence
by doing the one shot detection and arming of mmio_debug in hangcheck
and in modeset. This removes the write path performance burden.
v2: Remove gratuitous DRM_DEBUG and return value, comments (Chris)
Cc: Chris Wilson
Cc: Paulo Zanoni
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_irq.c | 11 ++-
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_uncore.c | 37 ++--
4 files changed, 40 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82c43b6..554092e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -723,6 +723,8 @@ struct intel_uncore {
i915_reg_t reg_post;
u32 val_reset;
} fw_domain[FW_DOMAIN_ID_COUNT];
+
+ int unclaimed_mmio_check;
};
/* Iterate over initialised fw domains */
@@ -2732,6 +2734,7 @@ extern void intel_uncore_early_sanitize(struct drm_device
*dev,
bool restore_forcewake);
extern void intel_uncore_init(struct drm_device *dev);
extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
+extern void intel_uncore_arm_unclaimed_mmio_detection(struct drm_i915_private
*dev_priv);
extern void intel_uncore_fini(struct drm_device *dev);
extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore);
const char *intel_uncore_forcewake_domain_to_str(const enum
forcewake_domain_id id);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a20dc64..5128422 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2165,11 +2165,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
if (!intel_irqs_enabled(dev_priv))
return IRQ_NONE;
- /* We get interrupts on unclaimed registers, so check for this before we
-* do any I915_{READ,WRITE}. */
- if (intel_uncore_unclaimed_mmio(dev_priv))
- DRM_ERROR("Unclaimed register before interrupt\n");
-
/* disable master interrupt before clearing iir */
de_ier = I915_READ(DEIER);
I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
@@ -2990,6 +2985,12 @@ static void i915_hangcheck_elapsed(struct work_struct
*work)
if (!i915.enable_hangcheck)
return;
+ /* As enabling the GPU requires fairly extensive mmio access,
+* periodically arm the mmio checker to see if we are triggering
+* any invalid access.
+*/
+ intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
+
for_each_ring(ring, dev_priv, i) {
u64 acthd;
u32 seqno;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 471f120..7dcabda 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13545,6 +13545,19 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_state_free(state);
+ /* As one of the primary mmio accessors, KMS has a high likelihood
+* of triggering bugs in unclaimed access. After we finish
+* modesetting, see if an error has been flagged, and if so
+* enable debugging for the next modeset - and hope we catch
+* the culprit.
+*
+* XXX note that we assume display power is on at this point.
+* This might hold true now but we need to add pm helper to check
+* unclaimed only when the hardware is on, as atomic commits
+* can happen also when the device is completely off.
+*/
+ intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 3d8af69..51d3036 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -626,22 +626,6 @@ hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv,
}
}
-static void
-hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
-{
- static bool mmio_debug_once = true;
-
- if (i915.mmio_debug || !mmio_debug_once)
- return;
-
- if (check_for_unclaimed_mmio(dev_priv)) {
- DRM_DEBUG("Unclaimed register detected, "
- "enabling oneshot unclaimed register reporting. "
- "Please use i915.mmio_debug=N for more
information.\n");
- i915.mmio_debu
Re: [Intel-gfx] [PATCH] drm/i915: Add Backlight Control using DPCD for eDP connectors (v4) (fwd)
It looks like at least the call to drm_dp_dpcd_writeb should be indented.
Please check.
julia
-- Forwarded message --
Date: Wed, 16 Dec 2015 07:15:44 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Add Backlight Control using DPCD for
eDP connectors (v4)
CC: kbuild-...@01.org
In-Reply-To: <1450205963-32436-1-git-send-email-yetundex.adeb...@intel.com>
TO: Yetunde Adebisi
CC: intel-gfx@lists.freedesktop.org, Yetunde Adebisi
, Jani Nikula
CC: Yetunde Adebisi , Jani Nikula
Hi Yetunde,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20151215]
[cannot apply to v4.4-rc5]
url:
https://github.com/0day-ci/linux/commits/Yetunde-Adebisi/drm-i915-Add-Backlight-Control-using-DPCD-for-eDP-connectors-v4/20151216-030252
base: git://anongit.freedesktop.org/drm-intel for-linux-next
:: branch date: 4 hours ago
:: commit date: 4 hours ago
>> drivers/gpu/drm/i915/intel_dp_aux_backlight.c:158:2-53: code aligned with
>> following code on line 161
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout f26dfdeaa8719aa796eaf7a642dffac78d56bfc2
vim +158 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
f26dfdea Yetunde Adebisi 2015-12-15 152DRM_DEBUG_KMS("AUX
Backlight Control Supported!\n");
f26dfdea Yetunde Adebisi 2015-12-15 153
set_aux_backlight_enable(intel_dp, true);
f26dfdea Yetunde Adebisi 2015-12-15 154if
((intel_dp_dpcd_read_wake(&intel_dp->aux,
f26dfdea Yetunde Adebisi 2015-12-15 155
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf, 1) == 1) &&
f26dfdea Yetunde Adebisi 2015-12-15 156((dpcd_buf &
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
f26dfdea Yetunde Adebisi 2015-12-15 157
DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
f26dfdea Yetunde Adebisi 2015-12-15 @158
drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
f26dfdea Yetunde Adebisi 2015-12-15 159
(dpcd_buf | DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
f26dfdea Yetunde Adebisi 2015-12-15 160
f26dfdea Yetunde Adebisi 2015-12-15 @161return true;
f26dfdea Yetunde Adebisi 2015-12-15 162}
f26dfdea Yetunde Adebisi 2015-12-15 163return false;
f26dfdea Yetunde Adebisi 2015-12-15 164 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> -Original Message- > From: Kristian Høgsberg [mailto:hoegsb...@gmail.com] > Sent: Tuesday, December 15, 2015 4:09 AM > To: Song, Ruiling ; k...@bitplanet.net; Winiarski, > Michal > Cc: intel-gfx@lists.freedesktop.org; mesa-...@lists.freedesktop.org; Ben > Widawsky ; dri-de...@lists.freedesktop.org; Yang, > Rong R > Subject: RE: [Intel-gfx] [RFC libdrm] intel: Add support for softpin > > Kristian Høgsberg writes: > > > "Song, Ruiling" writes: > > > >>> -Original Message- > >>> From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf > Of > >>> Kristian H?gsberg > >>> Sent: Monday, December 14, 2015 1:34 PM > >>> To: Song, Ruiling > >>> Cc: Winiarski, Michal ; intel- > >>> g...@lists.freedesktop.org; mesa-...@lists.freedesktop.org; Ben > Widawsky > >>> ; dri-de...@lists.freedesktop.org > >>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin > >>> > >>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling > >>> wrote: > >>> >> -Original Message- > >>> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > >>> Behalf > >>> >> Of Micha? Winiarski > >>> >> Sent: Wednesday, September 9, 2015 10:07 PM > >>> >> To: intel-gfx@lists.freedesktop.org > >>> >> Cc: Ben Widawsky ; dri- > >>> de...@lists.freedesktop.org; > >>> >> mesa-...@lists.freedesktop.org > >>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin > >>> >> > >>> >> Softpin allows userspace to take greater control of GPU virtual > address > >>> >> space and eliminates the need of relocations. It can also be used to > >>> >> mirror addresses between GPU and CPU (shared virtual memory). > >>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list > >>> >> of > >>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs > are > >>> >> created. Self-relocs don't make any sense for softpinned objects and > can > >>> >> indicate a programming errors, thus are forbidden. Softpinned > objects > >>> >> are marked by asterisk in debug dumps. > >>> >> > >>> >> Cc: Thomas Daniel > >>> >> Cc: Kristian Høgsberg > >>> >> Cc: Zou Nanhai > >>> >> Cc: Michel Thierry > >>> >> Cc: Ben Widawsky > >>> >> Cc: Chris Wilson > >>> >> Signed-off-by: Michał Winiarski > >>> >> --- > >>> >> include/drm/i915_drm.h| 4 +- > >>> >> intel/intel_bufmgr.c | 9 +++ > >>> >> intel/intel_bufmgr.h | 1 + > >>> >> intel/intel_bufmgr_gem.c | 176 > >>> >> -- > >>> >> intel/intel_bufmgr_priv.h | 7 ++ > >>> >> 5 files changed, 173 insertions(+), 24 deletions(-) > >>> > > >>> > Will anybody help to push the patch to libdrm? Beignet highly depend > on > >>> this to implement ocl2.0 svm. > >>> > >>> Is the kernel patch upstream? > >> > >> Yes, the kernel patch already merged, see: > >> http://cgit.freedesktop.org/drm- > intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750 > >> > >> I find below line of code in libdrm does not match the kernel version. The > kernel patch defined as: > >> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as > (1<<3). > > > > I have the two 48 bit patches merge here. I'll pull in Michał's patch, > > update the kernel header and then push it all. > > All pushed now. Thanks. We have tried some basic OpenCL tests. Both patches work! I have another question, does KMD allow soft-pin a bo at zero address? I have tried to pin a bo with the size of 64KB at zero address in Beignet. It can succeed. But I met some random failure with bo_exec() returning -EINVAL. I am trying to figure out why. So I want to confirm is it allowed by KMD? Thanks! Ruiling ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] PM / runtime: Add new helper for conditional usage count incrementation
On Tuesday, December 15, 2015 10:06:33 AM Alan Stern wrote:
> On Mon, 14 Dec 2015, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki
> >
> > Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
> > that will increment the device's runtime PM usage counter and
> > return 'true' if its status is RPM_ACTIVE and its usage counter
> > is greater than 0 at the same time ('false' will be returned
> > otherwise).
> >
> > This is useful for things that should only be done if the device
> > is active (from the runtime PM perspective) and used by somebody
> > (as indicated by the usage counter) already and they are not worth
> > bothering otherwise.
>
>
> > --- linux-pm.orig/drivers/base/power/runtime.c
> > +++ linux-pm/drivers/base/power/runtime.c
> > @@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
> > EXPORT_SYMBOL_GPL(__pm_runtime_resume);
> >
> > /**
> > + * pm_runtime_get_if_in_use - Conditionally bump up the device's usage
> > counter.
> > + * @dev: Device to handle.
> > + *
> > + * Increment the device's runtime PM usage counter and return 'true' if its
> > + * runtime PM status is RPM_ACTIVE and its usage counter is already
> > different
> > + * from zero at the same time. Otherwise, return 'false'.
>
> The phrasing of this comment is slightly ambiguous (it's not clear
> whether the "if" clause applies to both the increment and the return
> or just the return). IMO it would be somewhat better to write:
>
> If the runtime PM status is RPM_ACTIVE and the runtime PM usage
> counter is nonzero, increment the counter and return 'true'.
> Otherwise return false without changing the counter.
Yes, that sounds better, thanks!
I'll resend the patch with that modification.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] PM / runtime: Add new helper for conditional usage count incrementation
On Tuesday, December 15, 2015 03:28:54 PM Ulf Hansson wrote:
> On 14 December 2015 at 23:22, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
>
> As we already have pm_runtime_set_active() and pm_runtime_active(),
> changing the new function name to "pm_runtime_get_if_active" may be
> better!?
"In use" is supposed to mean "active and reference counted".
> > that will increment the device's runtime PM usage counter and
> > return 'true' if its status is RPM_ACTIVE and its usage counter
> > is greater than 0 at the same time ('false' will be returned
> > otherwise).
> >
> > This is useful for things that should only be done if the device
> > is active (from the runtime PM perspective) and used by somebody
> > (as indicated by the usage counter) already and they are not worth
> > bothering otherwise.
> >
> > Requested-by: Imre Deak
> > Acked-by: Imre Deak
> > Signed-off-by: Rafael J. Wysocki
> > ---
> > Documentation/power/runtime_pm.txt |5 +
> > drivers/base/power/runtime.c | 21 +
> > include/linux/pm_runtime.h |5 +
> > 3 files changed, 31 insertions(+)
> >
> > Index: linux-pm/drivers/base/power/runtime.c
> > ===
> > --- linux-pm.orig/drivers/base/power/runtime.c
> > +++ linux-pm/drivers/base/power/runtime.c
> > @@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
> > EXPORT_SYMBOL_GPL(__pm_runtime_resume);
> >
> > /**
> > + * pm_runtime_get_if_in_use - Conditionally bump up the device's usage
> > counter.
> > + * @dev: Device to handle.
> > + *
> > + * Increment the device's runtime PM usage counter and return 'true' if its
> > + * runtime PM status is RPM_ACTIVE and its usage counter is already
> > different
> > + * from zero at the same time. Otherwise, return 'false'.
> > + */
> > +bool pm_runtime_get_if_in_use(struct device *dev)
> > +{
> > + unsigned long flags;
> > + bool retval;
> > +
> > + spin_lock_irqsave(&dev->power.lock, flags);
> > + retval = dev->power.runtime_status == RPM_ACTIVE
> > + && atomic_inc_not_zero(&dev->power.usage_count);
>
> Don't we also need to check that runtime PM is enabled (&&
> !dev->power.disable_depth), or the user of this function don't care
> about that?
The user probably cares, but calling this for devices with runtime PM
disabled doesn't really make sense to me (the status is not meaningful
then).
> > + spin_unlock_irqrestore(&dev->power.lock, flags);
> > + return retval;
> > +}
> > +EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
> > +
>
> [...]
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 07/10] drm/i915: add support for checking if we hold an RPM reference
Atm, we assert that the device is not suspended until the point when the
device is truly put to a suspended state. This is fine, but we can catch
more problems if we check that RPM refcount is non-zero. After that one
drops to zero we shouldn't access the device any more, even if the actual
device suspend may be delayed. Change assert_rpm_wakelock_held()
accordingly to check for a non-zero RPM refcount in addition to the
current device-not-suspended check.
For the new asserts to work we need to annotate every place explicitly in
the code where we expect that the device is powered. The places where we
only assume this, but may not hold an RPM reference:
- driver load
We assume the device to be powered until we enable RPM. Make this
explicit by taking an RPM reference around the load function.
- system and runtime sudpend/resume handlers
These handlers are called when the RPM reference becomes 0 and know the
exact point after which the device can get powered off. Disable the
RPM-reference-held check for their duration.
- the IRQ, hangcheck and RPS work handlers
These handlers are flushed in the system/runtime suspend handler
before the device is powered off, so it's guaranteed that they won't
run while the device is powered off even though they don't hold any
RPM reference. Disable the RPM-reference-held check for their duration.
In all these cases we still check that the device is not suspended.
These explicit annotations also have the positive side effect of
documenting our assumptions better.
This caught additional WARNs from the atomic modeset path, those should
be fixed separately.
v2:
- remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville)
v3:
- use a new dedicated RPM wakelock refcount to also catch cases where
our own RPM get/put functions were not called (Chris)
- assert also that the new RPM wakelock refcount is 0 in the RPM
suspend handler (Chris)
- change the assert error message to be more meaningful (Chris)
- prevent false assert errors and check that the RPM wakelock is 0 in
the RPM resume handler too
- prevent false assert errors in the hangcheck work too
- add a device not suspended assert check to the hangcheck work
v4:
- rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts
and wakelock_count to wakeref_count
- disable the wakeref asserts in the IRQ handlers and RPS work too
- update/clarify commit message
v5:
- mark places we plan to change to use proper RPM refcounting with
separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris)
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson (v3)
---
drivers/gpu/drm/i915/i915_dma.c | 7 +++
drivers/gpu/drm/i915/i915_drv.c | 39 +++--
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 75 ++---
drivers/gpu/drm/i915/intel_drv.h| 49 +
drivers/gpu/drm/i915/intel_pm.c | 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++
7 files changed, 168 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 84e2b20..077d64c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -896,6 +896,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
intel_pm_setup(dev);
+ intel_runtime_pm_get(dev_priv);
+
intel_display_crc_init(dev);
i915_dump_device_info(dev_priv);
@@ -1085,6 +1087,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
i915_audio_component_init(dev_priv);
+ intel_runtime_pm_put(dev_priv);
+
return 0;
out_power_well:
@@ -1120,6 +1124,9 @@ free_priv:
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
kmem_cache_destroy(dev_priv->objects);
+
+ intel_runtime_pm_put(dev_priv);
+
kfree(dev_priv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8ddfcce..61267e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -580,6 +580,8 @@ static int i915_drm_suspend(struct drm_device *dev)
dev_priv->modeset_restore = MODESET_SUSPENDED;
mutex_unlock(&dev_priv->modeset_restore_lock);
+ disable_rpm_wakeref_asserts(dev_priv);
+
/* We do a lot of poking in a lot of registers, make sure they work
* properly. */
intel_display_set_init_power(dev_priv, true);
@@ -592,7 +594,7 @@ static int i915_drm_suspend(struct drm_device *dev)
if (error) {
dev_err(&dev->pdev->dev,
"GEM idle failed, resume might fail\n");
- return error;
+ goto out;
}
intel_guc_suspend(dev);
@@ -635,7 +637,10 @@ static int i915_drm_suspend(struct drm_device *dev)
if (HAS_CSR(dev_priv))
flush_work(&de
[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
between commit:
8fbf9d92a7bc ("drm/vmwgfx: Implement the cursor_set2 callback v2")
from Linus' tree and commit:
d7955fcff889 ("drm/vmwgfx: Constify function pointer structs")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 78693a0a598c,2def684e61a4..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@@ -294,8 -294,8 +294,8 @@@ static int vmw_ldu_crtc_set_config(stru
return vmw_ldu_commit_list(dev_priv);
}
- static struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
+ static const struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
- .cursor_set = vmw_du_crtc_cursor_set,
+ .cursor_set2 = vmw_du_crtc_cursor_set2,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
.destroy = vmw_ldu_crtc_destroy,
diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 7ba5a00b3b68,ecac70af032a..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@@ -530,8 -530,8 +530,8 @@@ out_no_fence
return ret;
}
- static struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
+ static const struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
- .cursor_set = vmw_du_crtc_cursor_set,
+ .cursor_set2 = vmw_du_crtc_cursor_set2,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
.destroy = vmw_sou_crtc_destroy,
diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 58c38e7723d8,87fc00af8d28..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@@ -1040,8 -1040,8 +1040,8 @@@ out_finish
/*
* Screen Target CRTC dispatch table
*/
- static struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
+ static const struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
- .cursor_set = vmw_du_crtc_cursor_set,
+ .cursor_set2 = vmw_du_crtc_cursor_set2,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
.destroy = vmw_stdu_crtc_destroy,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.
Is this something close to what we wanted to optimize for edp resume time and
using wall clock.
-Original Message-
From: Kumar, Abhay
Sent: Tuesday, December 15, 2015 2:17 PM
To: Intel-gfx@lists.freedesktop.org
Cc: Kumar, Abhay
Subject: [PATCH] drm/i915: edp resume/On time optimization.
From: Abhay Kumar
Make resume codepath not to wait for panel_power_cycle_delay(t11_t12) if this
time is already spent in suspend/poweron time.
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++ drivers/gpu/drm/i915/intel_dp.c |
18 ++ drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f00a3c9..d2a5a89 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2395,6 +2395,9 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
+
+ /* storing panel power off time */
+ do_gettimeofday(&intel_dp->panel_power_off_timestamp);
}
if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) diff --git
a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index
0f1eb96..1ca01b1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2032,6 +2032,9 @@ static void edp_panel_on(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
i915_reg_t pp_ctrl_reg;
+ u32 panel_power_off_duration;
+ u32 temp_power_cycle_delay;
+
lockdep_assert_held(&dev_priv->pps_mutex);
@@ -2045,8 +2048,22 @@ static void edp_panel_on(struct intel_dp *intel_dp)
"eDP port %c panel power already on\n",
port_name(dp_to_dig_port(intel_dp)->port)))
return;
+ /* taking the diffrence of currrent time and panel power off time
+ and then make panel to wait for T12 if needed */
+ do_gettimeofday(&intel_dp->panel_power_on_timestamp);
+
+ panel_power_off_duration =
(intel_dp->panel_power_on_timestamp.tv_sec-intel_dp->panel_power_off_timestamp.tv_sec)
* 100 +
intel_dp->panel_power_on_timestamp.tv_usec-intel_dp->panel_power_off_timestamp.tv_usec;
+ panel_power_off_duration = panel_power_off_duration / 1000 ;
+ temp_power_cycle_delay = intel_dp->panel_power_cycle_delay;
+
+ if(panel_power_off_duration >= intel_dp->panel_power_cycle_delay) {
+ intel_dp->panel_power_cycle_delay = 0;
+ } else {
+ intel_dp->panel_power_cycle_delay =
intel_dp->panel_power_cycle_delay - panel_power_off_duration;
+ }
wait_panel_power_cycle(intel_dp);
+ intel_dp->panel_power_cycle_delay = temp_power_cycle_delay;
pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
pp = ironlake_get_pp_control(intel_dp);
@@ -5127,6 +5144,7 @@ static void intel_dp_init_panel_power_timestamps(struct
intel_dp *intel_dp)
intel_dp->last_power_cycle = jiffies;
intel_dp->last_power_on = jiffies;
intel_dp->last_backlight_off = jiffies;
+ do_gettimeofday(&intel_dp->panel_power_off_timestamp);
}
static void
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 76dfa28..66ed2cb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -769,6 +769,8 @@ struct intel_dp {
unsigned long last_power_cycle;
unsigned long last_power_on;
unsigned long last_backlight_off;
+ struct timeval panel_power_off_timestamp;
+ struct timeval panel_power_on_timestamp;
struct notifier_block edp_notifier;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correct MI_STORE_DWORD_INDEX usage
On Wed, Dec 16, 2015 at 12:18:20AM +, Chris Wilson wrote: > On Tue, Dec 15, 2015 at 04:13:49PM -0800, Ben Widawsky wrote: > > This has been incorrect since the original commit from Oscar Mateo here: > > commit 4da46e1e5bb7e7396fad172cdaffbe496562f3d8 > > Author: Oscar Mateo > > Date: Thu Jul 24 17:04:27 2014 +0100 > > > > drm/i915/bdw: GEN-specific logical ring emit request > > > > The command's offset field is only 10 bits, and this is correct in all the > > other > > add_request commands. It's highly likely this this patch makes no functional > > difference because the hardware will hopefully ignore 31:12 anyway. > > Technically > > the existing code is wrong because the docs say the upper bits are MBZ. > > Ultimately, the patch just clears up the confusion. > > > > NOTE: This patch was compile tested only. > > NOTE2: The modern docs call it MI_STORE_DATA_INDEX not MI_STORE_DWORD_INDEX > > It doesn't use MI_STORE_DATA_INDEX, but a write to a specific memory > address (MI_STORE_DWORD_IMM) as it is not storing in the per-context HWS > but a global (per-engine) page. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre You're right. I just noticed the cmd = MI_STORE_DWORD_IMM_GEN4. Sorry about that. -- 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] [PATCH] drm/i915: Correct MI_STORE_DWORD_INDEX usage
On Tue, Dec 15, 2015 at 04:13:49PM -0800, Ben Widawsky wrote: > This has been incorrect since the original commit from Oscar Mateo here: > commit 4da46e1e5bb7e7396fad172cdaffbe496562f3d8 > Author: Oscar Mateo > Date: Thu Jul 24 17:04:27 2014 +0100 > > drm/i915/bdw: GEN-specific logical ring emit request > > The command's offset field is only 10 bits, and this is correct in all the > other > add_request commands. It's highly likely this this patch makes no functional > difference because the hardware will hopefully ignore 31:12 anyway. > Technically > the existing code is wrong because the docs say the upper bits are MBZ. > Ultimately, the patch just clears up the confusion. > > NOTE: This patch was compile tested only. > NOTE2: The modern docs call it MI_STORE_DATA_INDEX not MI_STORE_DWORD_INDEX It doesn't use MI_STORE_DATA_INDEX, but a write to a specific memory address (MI_STORE_DWORD_IMM) as it is not storing in the per-context HWS but a global (per-engine) page. -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 07/10] drm/i915: add support for checking if we hold an RPM reference
On Wed, Dec 16, 2015 at 12:52:34AM +0200, Imre Deak wrote: > On Tue, 2015-12-15 at 21:07 +, Chris Wilson wrote: > > My current thinking is that the hangcheck/RPS tasks are wrong - and > > that > > we do actually have explicit wakerefs that should cover their > > lifetimes > > (but we fail to actually terminate them when we drop the associated > > wakeref). > > > > With respect to the current state (cancelling the work in > > rpm_suspend), > > the assert disabling is correct, but I think we should be indicating > > that we papering over a "bug" more strongly. > > > > i.e. something like DISABLE_RPM_WAKEREF_ASSERT(); > > But the other cases are still legitimate, so we'd keep the lower case > name for those and define the above macro as an alias simply to > emphasize the difference? Yes. If you could put it in tags that would be a bonus. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Correct MI_STORE_DWORD_INDEX usage
This has been incorrect since the original commit from Oscar Mateo here:
commit 4da46e1e5bb7e7396fad172cdaffbe496562f3d8
Author: Oscar Mateo
Date: Thu Jul 24 17:04:27 2014 +0100
drm/i915/bdw: GEN-specific logical ring emit request
The command's offset field is only 10 bits, and this is correct in all the other
add_request commands. It's highly likely this this patch makes no functional
difference because the hardware will hopefully ignore 31:12 anyway. Technically
the existing code is wrong because the docs say the upper bits are MBZ.
Ultimately, the patch just clears up the confusion.
NOTE: This patch was compile tested only.
NOTE2: The modern docs call it MI_STORE_DATA_INDEX not MI_STORE_DWORD_INDEX
Cc: Oscar Mateo
Cc: Damien Lespiau
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_lrc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3aa6147..90d4dbb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1793,7 +1793,6 @@ static void bxt_a_set_seqno(struct intel_engine_cs *ring,
u32 seqno)
static int gen8_emit_request(struct drm_i915_gem_request *request)
{
struct intel_ringbuffer *ringbuf = request->ringbuf;
- struct intel_engine_cs *ring = ringbuf->ring;
u32 cmd;
int ret;
@@ -1811,8 +1810,7 @@ static int gen8_emit_request(struct drm_i915_gem_request
*request)
intel_logical_ring_emit(ringbuf, cmd);
intel_logical_ring_emit(ringbuf,
- (ring->status_page.gfx_addr +
- (I915_GEM_HWS_INDEX <<
MI_STORE_DWORD_INDEX_SHIFT)));
+ I915_GEM_HWS_INDEX <<
MI_STORE_DWORD_INDEX_SHIFT);
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
--
2.6.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm/i915: disable power well support on platforms without runtime PM support
On Tue, 2015-12-15 at 22:57 +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> > All platforms with power well support have runtime PM support, so
> > simplify things by explicitly disabling power well support on
> > platforms
> > without runtime PM support. This results in holding the init power
> > domain
> > reference whenever the driver is loaded in addition to an RPM
> > reference,
> > which reflects the reality better and makes it possible to simplify
> > things by removing the HAS_RUNTIME_PM special casing from more
> > places in
> > a follow-up patch.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 9945040..f4ff5f5 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1908,6 +1908,11 @@ static int
> > sanitize_disable_power_well_option(const struct drm_i915_private
> > *dev_priv,
> > int disable_power_well)
> > {
> > + if (!HAS_RUNTIME_PM(dev_priv)) {
> > + DRM_DEBUG_KMS("No runtime PM support, disabling
> > display power well support\n");
> > + return 0;
> > + }
>
> Feels a bit too magic to me. Needs a comment at least, otherwise
> someone
> is going to change disable_power_well back into something you can
> disable
> at runtime and then all the old stuff might break.
>
> Grabbing an extra rpm reference explicitly for this purpose might be
> less confusing.
Ok, agreed. But making power well support depend on RPM still ok with
you? I can add then the extra RPM get/put only for !HAS_RUNTIME_PM.
>
> > +
> > if (disable_power_well >= 0)
> > return !!disable_power_well;
> >
> > --
> > 2.5.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] drm/i915: add support for checking if we hold an RPM reference
On Tue, 2015-12-15 at 21:07 +, Chris Wilson wrote: > On Tue, Dec 15, 2015 at 08:10:35PM +0200, Imre Deak wrote: > > Atm, we assert that the device is not suspended until the point > > when the > > device is truly put to a suspended state. This is fine, but we can > > catch > > more problems if we check that RPM refcount is non-zero. After that > > one > > drops to zero we shouldn't access the device any more, even if the > > actual > > device suspend may be delayed. Change assert_rpm_wakelock_held() > > accordingly to check for a non-zero RPM refcount in addition to the > > current device-not-suspended check. > > > > For the new asserts to work we need to annotate every place > > explicitly in > > the code where we expect that the device is powered. The places > > where we > > only assume this, but may not hold an RPM reference: > > - driver load > > We assume the device to be powered until we enable RPM. Make this > > explicit by taking an RPM reference around the load function. > > - system and runtime sudpend/resume handlers > > These handlers are called when the RPM reference becomes 0 and > > know the > > exact point after which the device can get powered off. Disable > > the > > RPM-reference-held check for their duration. > > - the IRQ, hangcheck and RPS work handlers > > These handlers are flushed in the system/runtime suspend handler > > before the device is powered off, so it's guaranteed that they > > won't > > run while the device is powered off even though they don't hold > > any > > RPM reference. Disable the RPM-reference-held check for their > > duration. > > My current thinking is that the hangcheck/RPS tasks are wrong - and > that > we do actually have explicit wakerefs that should cover their > lifetimes > (but we fail to actually terminate them when we drop the associated > wakeref). > > With respect to the current state (cancelling the work in > rpm_suspend), > the assert disabling is correct, but I think we should be indicating > that we papering over a "bug" more strongly. > > i.e. something like DISABLE_RPM_WAKEREF_ASSERT(); But the other cases are still legitimate, so we'd keep the lower case name for those and define the above macro as an alias simply to emphasize the difference? > -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.
From: Abhay Kumar
Make resume codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f00a3c9..d2a5a89 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2395,6 +2395,9 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
+
+ /* storing panel power off time */
+ do_gettimeofday(&intel_dp->panel_power_off_timestamp);
}
if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0f1eb96..1ca01b1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2032,6 +2032,9 @@ static void edp_panel_on(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
i915_reg_t pp_ctrl_reg;
+ u32 panel_power_off_duration;
+ u32 temp_power_cycle_delay;
+
lockdep_assert_held(&dev_priv->pps_mutex);
@@ -2045,8 +2048,22 @@ static void edp_panel_on(struct intel_dp *intel_dp)
"eDP port %c panel power already on\n",
port_name(dp_to_dig_port(intel_dp)->port)))
return;
+ /* taking the diffrence of currrent time and panel power off time
+ and then make panel to wait for T12 if needed */
+ do_gettimeofday(&intel_dp->panel_power_on_timestamp);
+
+ panel_power_off_duration =
(intel_dp->panel_power_on_timestamp.tv_sec-intel_dp->panel_power_off_timestamp.tv_sec)
* 100 +
intel_dp->panel_power_on_timestamp.tv_usec-intel_dp->panel_power_off_timestamp.tv_usec;
+ panel_power_off_duration = panel_power_off_duration / 1000 ;
+ temp_power_cycle_delay = intel_dp->panel_power_cycle_delay;
+
+ if(panel_power_off_duration >= intel_dp->panel_power_cycle_delay) {
+ intel_dp->panel_power_cycle_delay = 0;
+ } else {
+ intel_dp->panel_power_cycle_delay =
intel_dp->panel_power_cycle_delay - panel_power_off_duration;
+ }
wait_panel_power_cycle(intel_dp);
+ intel_dp->panel_power_cycle_delay = temp_power_cycle_delay;
pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
pp = ironlake_get_pp_control(intel_dp);
@@ -5127,6 +5144,7 @@ static void intel_dp_init_panel_power_timestamps(struct
intel_dp *intel_dp)
intel_dp->last_power_cycle = jiffies;
intel_dp->last_power_on = jiffies;
intel_dp->last_backlight_off = jiffies;
+ do_gettimeofday(&intel_dp->panel_power_off_timestamp);
}
static void
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 76dfa28..66ed2cb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -769,6 +769,8 @@ struct intel_dp {
unsigned long last_power_cycle;
unsigned long last_power_on;
unsigned long last_backlight_off;
+ struct timeval panel_power_off_timestamp;
+ struct timeval panel_power_on_timestamp;
struct notifier_block edp_notifier;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/7] tests/gem_mmap_gtt: Deal with tile sizes on gen2/3
On Tue, Dec 15, 2015 at 07:19:24PM -0200, Paulo Zanoni wrote:
> 2015-12-15 19:08 GMT-02:00 Ville Syrjälä :
> > On Tue, Dec 15, 2015 at 06:51:56PM -0200, Paulo Zanoni wrote:
> >> 2015-12-14 18:15 GMT-02:00 :
> >> > From: Ville Syrjälä
> >> >
> >> > Gen2/3 platforms have some unusual tile dimensions. Account
> >> > for them to make the test work correctly.
> >> >
> >> > Signed-off-by: Ville Syrjälä
> >> > ---
> >> > tests/gem_mmap_gtt.c | 20 +---
> >> > 1 file changed, 17 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
> >> > index 4d146426535b..b9c413b6160b 100644
> >> > --- a/tests/gem_mmap_gtt.c
> >> > +++ b/tests/gem_mmap_gtt.c
> >> > @@ -253,6 +253,18 @@ test_write_gtt(int fd)
> >> > munmap(src, OBJECT_SIZE);
> >> > }
> >> >
> >> > +static int tile_width(uint32_t devid, int tiling)
> >> > +{
> >> > + if (intel_gen(devid) == 2)
> >> > + return 128;
> >> > + else if (tiling == I915_TILING_X)
> >> > + return 512;
> >> > + else if (IS_915(devid))
> >> > + return 512;
> >> > + else
> >> > + return 128;
> >> > +}
> >> > +
> >>
> >> Would this be useful: http://patchwork.freedesktop.org/patch/66846/ ?
> >> I mean, we could export some subfunction out of the original patch.
> >
> > I suppose we might try to consolidate. One snag is that for display
> > stuff we want to use the modifiers, but I'm not sure we want to pollute
> > any fence stuff with those.
> >
> > BTW your Yf width is not correct for 8/64 bpp (width*height != 4k).
>
> Hmmm, so I guess we need to discover if the Kernel's i915_tiling_ok()
> needs to be fixed.
No. That functions is all about fences. Fences and Yf don't mix.
>
> >
> >>
> >> > static void
> >> > test_huge_bo(int fd, int huge, int tiling)
> >> > {
> >> > @@ -261,7 +273,8 @@ test_huge_bo(int fd, int huge, int tiling)
> >> > char *tiled_pattern;
> >> > char *linear_pattern;
> >> > uint64_t size, last_offset;
> >> > - int pitch = tiling == I915_TILING_Y ? 128 : 512;
> >> > + uint32_t devid = intel_get_drm_devid(fd);
> >> > + int pitch = tile_width(devid, tiling);
> >> > int i;
> >> >
> >> > switch (huge) {
> >> > @@ -327,6 +340,7 @@ test_huge_bo(int fd, int huge, int tiling)
> >> > static void
> >> > test_huge_copy(int fd, int huge, int tiling_a, int tiling_b)
> >> > {
> >> > + uint32_t devid = intel_get_drm_devid(fd);
> >> > uint64_t huge_object_size, i;
> >> > uint32_t bo, *pattern_a, *pattern_b;
> >> > char *a, *b;
> >> > @@ -357,7 +371,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
> >> > tiling_b)
> >> >
> >> > bo = gem_create(fd, huge_object_size);
> >> > if (tiling_a)
> >> > - igt_require(__gem_set_tiling(fd, bo, tiling_a, tiling_a
> >> > == I915_TILING_Y ? 128 : 512) == 0);
> >> > + igt_require(__gem_set_tiling(fd, bo, tiling_a,
> >> > tile_width(devid, tiling_a)) == 0);
> >> > a = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ |
> >> > PROT_WRITE);
> >> > igt_require(a);
> >> > gem_close(fd, bo);
> >> > @@ -367,7 +381,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
> >> > tiling_b)
> >> >
> >> > bo = gem_create(fd, huge_object_size);
> >> > if (tiling_b)
> >> > - igt_require(__gem_set_tiling(fd, bo, tiling_b, tiling_b
> >> > == I915_TILING_Y ? 128 : 512) == 0);
> >> > + igt_require(__gem_set_tiling(fd, bo, tiling_b,
> >> > tile_width(devid, tiling_b)) == 0);
> >> > b = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ |
> >> > PROT_WRITE);
> >> > igt_require(b);
> >> > gem_close(fd, bo);
> >> > --
> >> > 2.4.10
> >> >
> >> > ___
> >> > Intel-gfx mailing list
> >> > Intel-gfx@lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >>
> >>
> >>
> >> --
> >> Paulo Zanoni
> >
> > --
> > Ville Syrjälä
> > Intel OTC
>
>
>
> --
> Paulo Zanoni
--
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 i-g-t 2/7] tests/gem_mmap_gtt: Deal with tile sizes on gen2/3
2015-12-15 19:08 GMT-02:00 Ville Syrjälä :
> On Tue, Dec 15, 2015 at 06:51:56PM -0200, Paulo Zanoni wrote:
>> 2015-12-14 18:15 GMT-02:00 :
>> > From: Ville Syrjälä
>> >
>> > Gen2/3 platforms have some unusual tile dimensions. Account
>> > for them to make the test work correctly.
>> >
>> > Signed-off-by: Ville Syrjälä
>> > ---
>> > tests/gem_mmap_gtt.c | 20 +---
>> > 1 file changed, 17 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
>> > index 4d146426535b..b9c413b6160b 100644
>> > --- a/tests/gem_mmap_gtt.c
>> > +++ b/tests/gem_mmap_gtt.c
>> > @@ -253,6 +253,18 @@ test_write_gtt(int fd)
>> > munmap(src, OBJECT_SIZE);
>> > }
>> >
>> > +static int tile_width(uint32_t devid, int tiling)
>> > +{
>> > + if (intel_gen(devid) == 2)
>> > + return 128;
>> > + else if (tiling == I915_TILING_X)
>> > + return 512;
>> > + else if (IS_915(devid))
>> > + return 512;
>> > + else
>> > + return 128;
>> > +}
>> > +
>>
>> Would this be useful: http://patchwork.freedesktop.org/patch/66846/ ?
>> I mean, we could export some subfunction out of the original patch.
>
> I suppose we might try to consolidate. One snag is that for display
> stuff we want to use the modifiers, but I'm not sure we want to pollute
> any fence stuff with those.
>
> BTW your Yf width is not correct for 8/64 bpp (width*height != 4k).
Hmmm, so I guess we need to discover if the Kernel's i915_tiling_ok()
needs to be fixed.
>
>>
>> > static void
>> > test_huge_bo(int fd, int huge, int tiling)
>> > {
>> > @@ -261,7 +273,8 @@ test_huge_bo(int fd, int huge, int tiling)
>> > char *tiled_pattern;
>> > char *linear_pattern;
>> > uint64_t size, last_offset;
>> > - int pitch = tiling == I915_TILING_Y ? 128 : 512;
>> > + uint32_t devid = intel_get_drm_devid(fd);
>> > + int pitch = tile_width(devid, tiling);
>> > int i;
>> >
>> > switch (huge) {
>> > @@ -327,6 +340,7 @@ test_huge_bo(int fd, int huge, int tiling)
>> > static void
>> > test_huge_copy(int fd, int huge, int tiling_a, int tiling_b)
>> > {
>> > + uint32_t devid = intel_get_drm_devid(fd);
>> > uint64_t huge_object_size, i;
>> > uint32_t bo, *pattern_a, *pattern_b;
>> > char *a, *b;
>> > @@ -357,7 +371,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
>> > tiling_b)
>> >
>> > bo = gem_create(fd, huge_object_size);
>> > if (tiling_a)
>> > - igt_require(__gem_set_tiling(fd, bo, tiling_a, tiling_a ==
>> > I915_TILING_Y ? 128 : 512) == 0);
>> > + igt_require(__gem_set_tiling(fd, bo, tiling_a,
>> > tile_width(devid, tiling_a)) == 0);
>> > a = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ |
>> > PROT_WRITE);
>> > igt_require(a);
>> > gem_close(fd, bo);
>> > @@ -367,7 +381,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
>> > tiling_b)
>> >
>> > bo = gem_create(fd, huge_object_size);
>> > if (tiling_b)
>> > - igt_require(__gem_set_tiling(fd, bo, tiling_b, tiling_b ==
>> > I915_TILING_Y ? 128 : 512) == 0);
>> > + igt_require(__gem_set_tiling(fd, bo, tiling_b,
>> > tile_width(devid, tiling_b)) == 0);
>> > b = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ |
>> > PROT_WRITE);
>> > igt_require(b);
>> > gem_close(fd, bo);
>> > --
>> > 2.4.10
>> >
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>>
>> --
>> Paulo Zanoni
>
> --
> Ville Syrjälä
> Intel OTC
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/7] tests/gem_mmap_gtt: Deal with tile sizes on gen2/3
On Tue, Dec 15, 2015 at 06:51:56PM -0200, Paulo Zanoni wrote:
> 2015-12-14 18:15 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > Gen2/3 platforms have some unusual tile dimensions. Account
> > for them to make the test work correctly.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > tests/gem_mmap_gtt.c | 20 +---
> > 1 file changed, 17 insertions(+), 3 deletions(-)
> >
> > diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
> > index 4d146426535b..b9c413b6160b 100644
> > --- a/tests/gem_mmap_gtt.c
> > +++ b/tests/gem_mmap_gtt.c
> > @@ -253,6 +253,18 @@ test_write_gtt(int fd)
> > munmap(src, OBJECT_SIZE);
> > }
> >
> > +static int tile_width(uint32_t devid, int tiling)
> > +{
> > + if (intel_gen(devid) == 2)
> > + return 128;
> > + else if (tiling == I915_TILING_X)
> > + return 512;
> > + else if (IS_915(devid))
> > + return 512;
> > + else
> > + return 128;
> > +}
> > +
>
> Would this be useful: http://patchwork.freedesktop.org/patch/66846/ ?
> I mean, we could export some subfunction out of the original patch.
I suppose we might try to consolidate. One snag is that for display
stuff we want to use the modifiers, but I'm not sure we want to pollute
any fence stuff with those.
BTW your Yf width is not correct for 8/64 bpp (width*height != 4k).
>
> > static void
> > test_huge_bo(int fd, int huge, int tiling)
> > {
> > @@ -261,7 +273,8 @@ test_huge_bo(int fd, int huge, int tiling)
> > char *tiled_pattern;
> > char *linear_pattern;
> > uint64_t size, last_offset;
> > - int pitch = tiling == I915_TILING_Y ? 128 : 512;
> > + uint32_t devid = intel_get_drm_devid(fd);
> > + int pitch = tile_width(devid, tiling);
> > int i;
> >
> > switch (huge) {
> > @@ -327,6 +340,7 @@ test_huge_bo(int fd, int huge, int tiling)
> > static void
> > test_huge_copy(int fd, int huge, int tiling_a, int tiling_b)
> > {
> > + uint32_t devid = intel_get_drm_devid(fd);
> > uint64_t huge_object_size, i;
> > uint32_t bo, *pattern_a, *pattern_b;
> > char *a, *b;
> > @@ -357,7 +371,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
> > tiling_b)
> >
> > bo = gem_create(fd, huge_object_size);
> > if (tiling_a)
> > - igt_require(__gem_set_tiling(fd, bo, tiling_a, tiling_a ==
> > I915_TILING_Y ? 128 : 512) == 0);
> > + igt_require(__gem_set_tiling(fd, bo, tiling_a,
> > tile_width(devid, tiling_a)) == 0);
> > a = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ |
> > PROT_WRITE);
> > igt_require(a);
> > gem_close(fd, bo);
> > @@ -367,7 +381,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
> > tiling_b)
> >
> > bo = gem_create(fd, huge_object_size);
> > if (tiling_b)
> > - igt_require(__gem_set_tiling(fd, bo, tiling_b, tiling_b ==
> > I915_TILING_Y ? 128 : 512) == 0);
> > + igt_require(__gem_set_tiling(fd, bo, tiling_b,
> > tile_width(devid, tiling_b)) == 0);
> > b = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ |
> > PROT_WRITE);
> > igt_require(b);
> > gem_close(fd, bo);
> > --
> > 2.4.10
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
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 07/10] drm/i915: add support for checking if we hold an RPM reference
On Tue, Dec 15, 2015 at 08:10:35PM +0200, Imre Deak wrote: > Atm, we assert that the device is not suspended until the point when the > device is truly put to a suspended state. This is fine, but we can catch > more problems if we check that RPM refcount is non-zero. After that one > drops to zero we shouldn't access the device any more, even if the actual > device suspend may be delayed. Change assert_rpm_wakelock_held() > accordingly to check for a non-zero RPM refcount in addition to the > current device-not-suspended check. > > For the new asserts to work we need to annotate every place explicitly in > the code where we expect that the device is powered. The places where we > only assume this, but may not hold an RPM reference: > - driver load > We assume the device to be powered until we enable RPM. Make this > explicit by taking an RPM reference around the load function. > - system and runtime sudpend/resume handlers > These handlers are called when the RPM reference becomes 0 and know the > exact point after which the device can get powered off. Disable the > RPM-reference-held check for their duration. > - the IRQ, hangcheck and RPS work handlers > These handlers are flushed in the system/runtime suspend handler > before the device is powered off, so it's guaranteed that they won't > run while the device is powered off even though they don't hold any > RPM reference. Disable the RPM-reference-held check for their duration. My current thinking is that the hangcheck/RPS tasks are wrong - and that we do actually have explicit wakerefs that should cover their lifetimes (but we fail to actually terminate them when we drop the associated wakeref). With respect to the current state (cancelling the work in rpm_suspend), the assert disabling is correct, but I think we should be indicating that we papering over a "bug" more strongly. i.e. something like DISABLE_RPM_WAKEREF_ASSERT(); -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 02/10] drm/i915: disable power well support on platforms without runtime PM support
On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> All platforms with power well support have runtime PM support, so
> simplify things by explicitly disabling power well support on platforms
> without runtime PM support. This results in holding the init power domain
> reference whenever the driver is loaded in addition to an RPM reference,
> which reflects the reality better and makes it possible to simplify
> things by removing the HAS_RUNTIME_PM special casing from more places in
> a follow-up patch.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 9945040..f4ff5f5 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1908,6 +1908,11 @@ static int
> sanitize_disable_power_well_option(const struct drm_i915_private *dev_priv,
> int disable_power_well)
> {
> + if (!HAS_RUNTIME_PM(dev_priv)) {
> + DRM_DEBUG_KMS("No runtime PM support, disabling display power
> well support\n");
> + return 0;
> + }
Feels a bit too magic to me. Needs a comment at least, otherwise someone
is going to change disable_power_well back into something you can disable
at runtime and then all the old stuff might break.
Grabbing an extra rpm reference explicitly for this purpose might be
less confusing.
> +
> if (disable_power_well >= 0)
> return !!disable_power_well;
>
> --
> 2.5.0
--
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 i-g-t 2/7] tests/gem_mmap_gtt: Deal with tile sizes on gen2/3
2015-12-14 18:15 GMT-02:00 :
> From: Ville Syrjälä
>
> Gen2/3 platforms have some unusual tile dimensions. Account
> for them to make the test work correctly.
>
> Signed-off-by: Ville Syrjälä
> ---
> tests/gem_mmap_gtt.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
> index 4d146426535b..b9c413b6160b 100644
> --- a/tests/gem_mmap_gtt.c
> +++ b/tests/gem_mmap_gtt.c
> @@ -253,6 +253,18 @@ test_write_gtt(int fd)
> munmap(src, OBJECT_SIZE);
> }
>
> +static int tile_width(uint32_t devid, int tiling)
> +{
> + if (intel_gen(devid) == 2)
> + return 128;
> + else if (tiling == I915_TILING_X)
> + return 512;
> + else if (IS_915(devid))
> + return 512;
> + else
> + return 128;
> +}
> +
Would this be useful: http://patchwork.freedesktop.org/patch/66846/ ?
I mean, we could export some subfunction out of the original patch.
> static void
> test_huge_bo(int fd, int huge, int tiling)
> {
> @@ -261,7 +273,8 @@ test_huge_bo(int fd, int huge, int tiling)
> char *tiled_pattern;
> char *linear_pattern;
> uint64_t size, last_offset;
> - int pitch = tiling == I915_TILING_Y ? 128 : 512;
> + uint32_t devid = intel_get_drm_devid(fd);
> + int pitch = tile_width(devid, tiling);
> int i;
>
> switch (huge) {
> @@ -327,6 +340,7 @@ test_huge_bo(int fd, int huge, int tiling)
> static void
> test_huge_copy(int fd, int huge, int tiling_a, int tiling_b)
> {
> + uint32_t devid = intel_get_drm_devid(fd);
> uint64_t huge_object_size, i;
> uint32_t bo, *pattern_a, *pattern_b;
> char *a, *b;
> @@ -357,7 +371,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
> tiling_b)
>
> bo = gem_create(fd, huge_object_size);
> if (tiling_a)
> - igt_require(__gem_set_tiling(fd, bo, tiling_a, tiling_a ==
> I915_TILING_Y ? 128 : 512) == 0);
> + igt_require(__gem_set_tiling(fd, bo, tiling_a,
> tile_width(devid, tiling_a)) == 0);
> a = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ | PROT_WRITE);
> igt_require(a);
> gem_close(fd, bo);
> @@ -367,7 +381,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int
> tiling_b)
>
> bo = gem_create(fd, huge_object_size);
> if (tiling_b)
> - igt_require(__gem_set_tiling(fd, bo, tiling_b, tiling_b ==
> I915_TILING_Y ? 128 : 512) == 0);
> + igt_require(__gem_set_tiling(fd, bo, tiling_b,
> tile_width(devid, tiling_b)) == 0);
> b = __gem_mmap__gtt(fd, bo, huge_object_size, PROT_READ | PROT_WRITE);
> igt_require(b);
> gem_close(fd, bo);
> --
> 2.4.10
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/7] tests/gem_mmap_gtt: Deal with tile sizes on gen2/3
On Mon, Dec 14, 2015 at 09:52:10PM +, Chris Wilson wrote: > On Mon, Dec 14, 2015 at 10:15:51PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Gen2/3 platforms have some unusual tile dimensions. Account > > for them to make the test work correctly. > > iirc, for the purposes of the test, we could just set the stride to 512 > and be done with it. The idea behind the test is to simply require a > fence register and then since we compare the same tiling pattern in > both, the actual tiling is irrevelant. (I wonder if using different > strides is of any value, not sure that it is - it doesn't change any > code paths). Well, it definitely didn't work with 512 for the X tiled. Let's see. 512 bytes is four tiles horizontally on gen2, but we only allocate two tiles for the object (4k). Then we walk over the mapping meaning we first hit 128 bytes of the first tile, then 128 bytes of the second tile. Then we walk into oblivion, which I suppose means the scratch page. So we do that until we've written 4k bytes, meaning we only manage to write something to the top halves of the two tiles we actually allocated. -- 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] [MIPI SEQ PARSING v3 09/13] drm/i915: Added the generic gpio sequence support and gpio table
On Tue, Dec 01, 2015 at 04:17:12AM +0530, Deepak M wrote: > The generic gpio is sequence is parsed from the VBT and the > GPIO table is updated with the North core, South core and > SUS core elements. > > v2: Move changes in sideband.c file to new patch(Jani), rebase > v3: Moved the Macro`s to intel_dsi_panel_vbt.c (Jani) > > Cc: Jani Nikula > Signed-off-by: Deepak M > --- > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 589 > +++-- > 1 file changed, 553 insertions(+), 36 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > index bc33e3a..13f0fb7 100644 > --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > @@ -59,30 +59,356 @@ static inline struct vbt_panel *to_vbt_panel(struct > drm_panel *panel) > > #define NS_KHZ_RATIO 100 > > -#define GPI0_NC_0_HV_DDI0_HPD 0x4130 > -#define GPIO_NC_0_HV_DDI0_PAD 0x4138 > -#define GPIO_NC_1_HV_DDI0_DDC_SDA 0x4120 > -#define GPIO_NC_1_HV_DDI0_DDC_SDA_PAD 0x4128 > -#define GPIO_NC_2_HV_DDI0_DDC_SCL 0x4110 > -#define GPIO_NC_2_HV_DDI0_DDC_SCL_PAD 0x4118 > -#define GPIO_NC_3_PANEL0_VDDEN 0x4140 > -#define GPIO_NC_3_PANEL0_VDDEN_PAD 0x4148 > -#define GPIO_NC_4_PANEL0_BLKEN 0x4150 > -#define GPIO_NC_4_PANEL0_BLKEN_PAD 0x4158 > -#define GPIO_NC_5_PANEL0_BLKCTL 0x4160 > -#define GPIO_NC_5_PANEL0_BLKCTL_PAD 0x4168 > -#define GPIO_NC_6_PCONF00x4180 > -#define GPIO_NC_6_PAD 0x4188 > -#define GPIO_NC_7_PCONF00x4190 > -#define GPIO_NC_7_PAD 0x4198 > -#define GPIO_NC_8_PCONF00x4170 > -#define GPIO_NC_8_PAD 0x4178 > -#define GPIO_NC_9_PCONF00x4100 > -#define GPIO_NC_9_PAD 0x4108 > -#define GPIO_NC_10_PCONF0 0x40E0 > -#define GPIO_NC_10_PAD 0x40E8 > -#define GPIO_NC_11_PCONF0 0x40F0 > -#define GPIO_NC_11_PAD 0x40F8 > +#define HV_DDI0_HPD_GPIONC_0_PCONF0 0x4130 > +#define HV_DDI0_HPD_GPIONC_0_PAD0x4138 Hmm. All of this seems to be VLV specific. CHV uses totally different looking registers for this stuff. There should be a comment before the defines that that effect. Also do we have some checks somewhere to make sure we don't accidentally use these on CHV? One thing to note is that there's always the same four registers for each pin, so we could maybe keep this list a bit shorted by defining just the base offset, and then have some generic macros to give us the PCONF0 and PAD_VAL registers based on it. Eg. #define GPIO_PCONF0(base) ((base) + 0x0) #define GPIO_PAD_VAL(base) ((base) + 0x8) I rather wish we could just use the regular pinctrl+gpio stuff for this. We're sort of hand rolling our own versions of that here. But I guess we'd then still have to remap from our numbers to theirs, so not really any better in the end I suppose. > +#define HV_DDI0_DDC_SDA_GPIONC_1_PCONF0 0x4120 > +#define HV_DDI0_DDC_SDA_GPIONC_1_PAD0x4128 > +#define HV_DDI0_DDC_SCL_GPIONC_2_PCONF0 0x4110 > +#define HV_DDI0_DDC_SCL_GPIONC_2_PAD0x4118 > +#define PANEL0_VDDEN_GPIONC_3_PCONF00x4140 > +#define PANEL0_VDDEN_GPIONC_3_PAD 0x4148 > +#define PANEL0_BKLTEN_GPIONC_4_PCONF0 0x4150 > +#define PANEL0_BKLTEN_GPIONC_4_PAD 0x4158 > +#define PANEL0_BKLTCTL_GPIONC_5_PCONF0 0x4160 > +#define PANEL0_BKLTCTL_GPIONC_5_PAD 0x4168 > +#define HV_DDI1_HPD_GPIONC_6_PCONF0 0x4180 > +#define HV_DDI1_HPD_GPIONC_6_PAD0x4188 > +#define HV_DDI1_DDC_SDA_GPIONC_7_PCONF0 0x4190 > +#define HV_DDI1_DDC_SDA_GPIONC_7_PAD0x4198 > +#define HV_DDI1_DDC_SCL_GPIONC_8_PCONF0 0x4170 > +#define HV_DDI1_DDC_SCL_GPIONC_8_PAD0x4178 > +#define PANEL1_VDDEN_GPIONC_9_PCONF00x4100 > +#define PANEL1_VDDEN_GPIONC_9_PAD 0x4108 > +#define PANEL1_BKLTEN_GPIONC_10_PCONF0 0x40E0 > +#define PANEL1_BKLTEN_GPIONC_10_PAD 0x40E8 > +#define PANEL1_BKLTCTL_GPIONC_11_PCONF0 0x40F0 > +#define PANEL1_BKLTCTL_GPIONC_11_PAD0x40F8 > +#define GP_INTD_DSI_TE1_GPIONC_12_PCONF00x40C0 > +#define GP_INTD_DSI_TE1_GPIONC_12_PAD 0x40C8 > +#define HV_DDI2_DDC_SDA_GPIONC_13_PCONF00x41A0 > +#define HV_DDI2_DDC_SDA_GPIONC_13_PAD 0x41A8 > +#define HV_DDI2_DDC_SCL_GPIONC_14_PCONF00x41B0 > +#define HV_DDI2_DDC_SCL_GPIONC_14_PAD 0x41B8 > +#define GP_CAMERASB00_GPIONC_15_PCONF0 0x4010 > +#define GP_CAMERASB00_GPIONC_15_PAD 0x4018 > +#define GP_CAMERASB01_GPIONC_16_PCONF0 0x4040 > +#define GP_CAMERASB01_GPIONC_16_PAD 0x4048 > +#define GP_CAMERASB02_GPIONC_17_PCONF0 0x4080 > +#define GP_CAMERAS
Re: [Intel-gfx] [MIPI SEQ PARSING v3 08/13] drm/i915: Extend gpio read/write to other cores
On Tue, Dec 01, 2015 at 04:17:11AM +0530, Deepak M wrote:
> Adding a argument to the gpio read/write functions
> which accepts the block name.
>
> v2: rebase
> v3: rebase
>
> Cc: Jani Nikula
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/i915_drv.h| 5 +++--
> drivers/gpu/drm/i915/i915_reg.h| 5 +
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
> drivers/gpu/drm/i915/intel_sideband.c | 9 +
> 4 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 59a39d1..ca865f4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3379,8 +3379,9 @@ int sandybridge_pcode_write(struct drm_i915_private
> *dev_priv, u32 mbox, u32 val
> u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
> u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> +u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32
> reg);
> +void vlv_gpio_write(struct drm_i915_private *dev_priv, u8 core_offset,
> + u32 reg, u32 val);
> u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8bd2699..e29f7ef 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -572,6 +572,11 @@
> #define IOSF_PORT_DPIO 0x12
> #define IOSF_PORT_DPIO_2 0x1a
> #define IOSF_PORT_GPIO_NC 0x13
> +#define IOSF_PORT_GPIO_SC 0x48
We already have another name for this (IOSF_PORT_GPS_CORE).
No idea why someone added the '_' in the middle of it. Now it
makes me think it has something to do with GPS rather than
GPIOs.
I'd be fine with using your new names instead, but the old
define should be removed, as should the unused
vlv_gps_core_{read,write}() functions.
> +#define IOSF_PORT_GPIO_SUS 0xA8
> +#define MAX_GPIO_NUM_NC26
> +#define MAX_GPIO_NUM_SC128
> +#define MAX_GPIO_NUM 172
These contant don't seem to have much to do with the actual
hardware (eg. there seem to be at lest 32 pads in NC). Rather
I take it they're constants defines by the VBT spec? If so
they should not be defined here.
> #define IOSF_PORT_CCK 0x14
> #define IOSF_PORT_CCU 0xA9
> #define IOSF_PORT_GPS_CORE 0x48
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index eb0697b..bc33e3a 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -275,14 +275,14 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
> *intel_dsi, const u8 *data)
> if (!gtable[gpio].init) {
> /* program the function */
> /* FIXME: remove constant below */
> - vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
> + vlv_gpio_write(dev_priv, IOSF_PORT_GPIO_NC, function,
> 0x2000CC00);
Side note:
Anyone ever figured out what this value actually means? Looking at
pinctrl-baytrail it seems that the right func_pin_mux value would maybe
depend on the specific pin you're dealing with. Would be nice if you
could add some defines or something for this stuff too. But that's
material for a separate patch clearly.
> gtable[gpio].init = 1;
> }
>
> val = 0x4 | action;
0x4 could also use a define.
>
> /* pull up/down */
> - vlv_gpio_nc_write(dev_priv, pad, val);
> + vlv_gpio_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
> mutex_unlock(&dev_priv->sb_lock);
>
> return data;
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 8831fc5..3e0cbe6 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8
> addr)
> return val;
> }
>
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
> +u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32 reg)
> {
> u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
> + vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), core_offset,
> SB_CRRDDA_NP, reg, &val);
> return val;
> }
>
> -void vlv_gpio_nc_write(struct drm_i915_private *de
Re: [Intel-gfx] [PATCH] drm/i915: Add Backlight Control using DPCD for eDP connectors (v4)
Hi Yetunde, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20151215] [cannot apply to v4.4-rc5] url: https://github.com/0day-ci/linux/commits/Yetunde-Adebisi/drm-i915-Add-Backlight-Control-using-DPCD-for-eDP-connectors-v4/20151216-030252 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x013-12141150 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/i915_drv.c:247:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:249:10: also defined here drivers/gpu/drm/i915/i915_drv.c:278:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:278:9: also defined here drivers/gpu/drm/i915/i915_drv.c:283:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:283:9: also defined here drivers/gpu/drm/i915/i915_drv.c:289:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:290:10: also defined here drivers/gpu/drm/i915/i915_drv.c:294:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:295:10: also defined here drivers/gpu/drm/i915/i915_drv.c:299:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:300:10: also defined here drivers/gpu/drm/i915/i915_drv.c:305:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:306:10: also defined here drivers/gpu/drm/i915/i915_drv.c:321:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:323:10: also defined here drivers/gpu/drm/i915/i915_drv.c:327:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:329:10: also defined here drivers/gpu/drm/i915/i915_drv.c:348:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:351:10: also defined here drivers/gpu/drm/i915/i915_drv.c:355:9: sparse: Initializer entry defined twice drivers/gpu/drm/i915/i915_drv.c:358:10: also defined here In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2646, from drivers/gpu/drm/i915/i915_drv.c:34: >> drivers/gpu/drm/i915/intel_drv.h:756:19: error: 'EDP_DISPLAY_CTL_CAP_SIZE' >> undeclared here (not in a function) uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; ^ -- In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2646, from drivers/gpu/drm/i915/i915_irq.c:36: >> drivers/gpu/drm/i915/intel_drv.h:756:19: error: 'EDP_DISPLAY_CTL_CAP_SIZE' >> undeclared here (not in a function) uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; ^ -- drivers/gpu/drm/i915/intel_drv.h:756:26: sparse: undefined identifier 'EDP_DISPLAY_CTL_CAP_SIZE' drivers/gpu/drm/i915/intel_drv.h:756:26: sparse: bad constant expression type In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2646, from drivers/gpu/drm/i915/intel_runtime_pm.c:32: >> drivers/gpu/drm/i915/intel_drv.h:756:19: error: 'EDP_DISPLAY_CTL_CAP_SIZE' >> undeclared here (not in a function) uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; ^ -- drivers/gpu/drm/i915/intel_ringbuffer.c:1987:31: sparse: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_ringbuffer.c:1987:31:expected void const *addr drivers/gpu/drm/i915/intel_ringbuffer.c:1987:31:got void [noderef] *virtual_start drivers/gpu/drm/i915/intel_ringbuffer.c:2033:40: sparse: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915/intel_ringbuffer.c:2033:40:expected void [noderef] *virtual_start drivers/gpu/drm/i915/intel_ringbuffer.c:2033:40:got unsigned int [usertype] * In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2646, from drivers/gpu/drm/i915/intel_ringbuffer.c:32: >> drivers/gpu/drm/i915/intel_drv.h:756:19: error: 'EDP_DISPLAY_CTL_CAP_SIZE' >> undeclared here (not in a function) uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; ^ -- drivers/gpu/drm/i915/intel_drv.h:756:26: sparse: undefined identifier 'EDP_DISPLAY_CTL_CAP_SIZE' drivers/gpu/drm/i915/intel_drv.h:756:26: sparse: bad constant expression type drivers/gpu/drm/i915/intel_dp.c:3895:47: sparse: cannot size expression drivers/gpu/drm/i915/intel_dp.c:3898:69: sparse: cannot size expression drivers/gpu/drm/i915/intel_dp.c:3899:65: sparse: cannot size expression drivers/gpu/dr
[Intel-gfx] [PATCH 06/10] drm/i915: use assert_rpm_wakelock_held instead of opencoding it
Signed-off-by: Imre Deak Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/intel_runtime_pm.c | 10 -- drivers/gpu/drm/i915/intel_uncore.c | 2 +- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index bca7ca7..603d410 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -538,8 +538,7 @@ static void assert_can_enable_dc5(struct drm_i915_private *dev_priv) WARN_ONCE((I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5), "DC5 already programmed to be enabled.\n"); - WARN_ONCE(dev_priv->pm.suspended, - "DC5 cannot be enabled, if platform is runtime-suspended.\n"); + assert_rpm_wakelock_held(dev_priv); assert_csr_loaded(dev_priv); } @@ -553,8 +552,7 @@ static void assert_can_disable_dc5(struct drm_i915_private *dev_priv) if (dev_priv->power_domains.initializing) return; - WARN_ONCE(dev_priv->pm.suspended, - "Disabling of DC5 while platform is runtime-suspended should never happen.\n"); + assert_rpm_wakelock_held(dev_priv); } static void gen9_enable_dc5(struct drm_i915_private *dev_priv) @@ -2238,7 +2236,7 @@ void intel_runtime_pm_get(struct drm_i915_private *dev_priv) struct device *device = &dev->pdev->dev; pm_runtime_get_sync(device); - WARN(dev_priv->pm.suspended, "Device still suspended.\n"); + assert_rpm_wakelock_held(dev_priv); } /** @@ -2263,7 +2261,7 @@ void intel_runtime_pm_get_noresume(struct drm_i915_private *dev_priv) struct drm_device *dev = dev_priv->dev; struct device *device = &dev->pdev->dev; - WARN(dev_priv->pm.suspended, "Getting nosync-ref while suspended.\n"); + assert_rpm_wakelock_held(dev_priv); pm_runtime_get_noresume(device); } diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 3c63d94..277e60a 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -404,7 +404,7 @@ void intel_uncore_forcewake_get(struct drm_i915_private *dev_priv, if (!dev_priv->uncore.funcs.force_wake_get) return; - WARN_ON(dev_priv->pm.suspended); + assert_rpm_wakelock_held(dev_priv); spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); __intel_uncore_forcewake_get(dev_priv, fw_domains); -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix context/engine cleanup order
On 14/12/15 22:17, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 05:13:43PM +, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 04:30:04PM +, Nick Hoath wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 900ffd0..7df3c7a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -431,17 +431,22 @@ void i915_gem_context_fini(struct drm_device *dev)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
}
- for (i = 0; i < I915_NUM_RINGS; i++) {
+ for (i = I915_NUM_RINGS; --i >= 0;) {
struct intel_engine_cs *ring = &dev_priv->ring[i];
if (ring->last_context)
i915_gem_context_unreference(ring->last_context);
- ring->default_context = NULL;
ring->last_context = NULL;
}
i915_gem_context_unreference(dctx);
+
+ for (i = I915_NUM_RINGS; --i >= 0;) {
+ struct intel_engine_cs *ring = &dev_priv->ring[i];
+
+ ring->default_context = NULL;
+ }
}
Why?
Ok, as you say intel_lrc needs to iterate over all rings to look at the
default context in context_free. Feels odd, and breaks the onion of
context_init / context_fini. The pecularity is in lrc and I would push
the oddness back there.
That engine->default_context is pinned and mapped is only because of the
HWS and for no other reason does it exist (seqno writes are to address
not relative the per-context HWS index). You could simply allocate a
page for each engine and use that as the global HWS irrespective of
contexts.
-Chris
The default (render) context has to be pinned anyway (nowadays), because
the GuC can access it asynchronously if it decides to reset an engine.
Also we use it when we need to give the GuC a valid LRCA for things that
aren't requests, e.g. suspend/resume et al.
Having a default context that's created and owned by the driver is an
old (pre-execlist) decision, and it allows us to switch away from all
user-visible contexts for idling. Leaving it pinned at all times means
we don't risk being unable to find space when we're trying to idle in
order to reclaim space!
Seqno writes are relative to the global HWSP independent of which
context is doing them. User code could be using the PPHWSP for its own
purposes.
I agree that it might be nicer to have a separate object for the global
HWSP, as we do in legacy mode. That would cost an extra page per engine,
but meh.
However a simpler solution for now might be to put a flag inside the
default context, rather than the LRC code deducing that that it's the
default one because the engine structure points back at it. That removes
the dependency of the LRC-specific code on knowing what the ring
(engine!) management code is doing :)
I'll discuss with Nick tomorrow, and I think we'll find a neater patch :)
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add Backlight Control using DPCD for eDP connectors (v4)
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd
v3: Correct some formatting mistakes
v4: Updated to use AUX backlight control if PWM control is not possible (Jani)
This patch depends on http://patchwork.freedesktop.org/patch/64253/
Cc: Bob Paauwe
Cc: Jani Nikula
Acked-by: Jesse Barnes
Signed-off-by: Yetunde Adebisi
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_dp.c | 17 ++-
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 180 ++
drivers/gpu/drm/i915/intel_drv.h | 6 +
drivers/gpu/drm/i915/intel_panel.c| 4 +
5 files changed, 202 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..41250cc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -77,6 +77,7 @@ i915-y += dvo_ch7017.o \
dvo_tfp410.o \
intel_crt.o \
intel_ddi.o \
+ intel_dp_aux_backlight.o \
intel_dp_link_training.o \
intel_dp_mst.o \
intel_dp.o \
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8071247..bd40d33 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3156,7 +3156,7 @@ static void chv_dp_post_pll_disable(struct intel_encoder
*encoder)
* Sinks are *supposed* to come up within 1ms from an off state, but we're also
* supposed to retry 3 times per the spec.
*/
-static ssize_t
+ssize_t
intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
void *buffer, size_t size)
{
@@ -3823,7 +3823,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- uint8_t rev;
if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3859,6 +3858,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
}
+
+ /* Read the eDP Display control capabilities registers */
+ memset(intel_dp->edp_dpcd, 0, sizeof(intel_dp->edp_dpcd));
+ if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
+ (intel_dp_dpcd_read_wake(&intel_dp->aux,
DP_EDP_DPCD_REV,
+ intel_dp->edp_dpcd,
sizeof(intel_dp->edp_dpcd)) ==
+
sizeof(intel_dp->edp_dpcd)))
+ DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int)
sizeof(intel_dp->edp_dpcd),
+ intel_dp->edp_dpcd);
}
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
@@ -3866,10 +3874,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
/* Intermediate frequency support */
- if (is_edp(intel_dp) &&
- (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
- (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_EDP_DPCD_REV, &rev, 1)
== 1) &&
- (rev >= 0x03)) { /* eDp v1.4 or higher */
+ if (is_edp(intel_dp) && (intel_dp->edp_dpcd[0] >= 0x03)) { /* eDp v1.4
or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
new file mode 100644
index 000..58e98fe
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -0,0 +1,180 @@
+/*
+ * Copyright © 2015 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) shal
[Intel-gfx] [PATCH 03/10] drm/i915: refactor RPM disabling due to RC6 being disabled
We can make the RPM dependency on RC6 explciit in the code by taking an
actual RPM reference, instead of avoiding to drop the initial one. This
will also enable us to remove the HAS_RUNTIME_PM special casing from
more places in the next patch.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 15 +++
drivers/gpu/drm/i915/intel_runtime_pm.c | 9 -
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 99f2642..f93c4b9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6015,7 +6015,17 @@ static void intel_init_emon(struct drm_device *dev)
void intel_init_gt_powersave(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
i915.enable_rc6 = sanitize_rc6_option(dev, i915.enable_rc6);
+ /*
+* RPM depends on RC6 to save restore the GT HW context, so make RC6 a
+* requirement.
+*/
+ if (!i915.enable_rc6) {
+ DRM_INFO("RC6 disabled, disabling runtime PM support\n");
+ intel_runtime_pm_get(dev_priv);
+ }
if (IS_CHERRYVIEW(dev))
cherryview_init_gt_powersave(dev);
@@ -6025,10 +6035,15 @@ void intel_init_gt_powersave(struct drm_device *dev)
void intel_cleanup_gt_powersave(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
if (IS_CHERRYVIEW(dev))
return;
else if (IS_VALLEYVIEW(dev))
valleyview_cleanup_gt_powersave(dev);
+
+ if (!i915.enable_rc6)
+ intel_runtime_pm_put(dev_priv);
}
static void gen6_suspend_rps(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index f4ff5f5..342baa9 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2311,15 +2311,6 @@ void intel_runtime_pm_enable(struct drm_i915_private
*dev_priv)
if (!HAS_RUNTIME_PM(dev))
return;
- /*
-* RPM depends on RC6 to save restore the GT HW context, so make RC6 a
-* requirement.
-*/
- if (!intel_enable_rc6(dev)) {
- DRM_INFO("RC6 disabled, disabling runtime PM support\n");
- return;
- }
-
pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
pm_runtime_mark_last_busy(device);
pm_runtime_use_autosuspend(device);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters
The device should be on for the whole duration of the update, so check
for this.
v2:
- use the existing dev_priv directly everywhere (Ville)
v3:
- check also that we are in an RPM atomic section (Chris)
- add the assert to i915_ggtt_insert_entries/clear_range too (Chris)
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7cfa1b9..c14b8f8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2351,6 +2351,9 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
int i = 0;
struct sg_page_iter sg_iter;
dma_addr_t addr = 0; /* shut up gcc */
+ int rpm_atomic_seq;
+
+ rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
for_each_sg_page(st->sgl, &sg_iter, st->nents, 0) {
addr = sg_dma_address(sg_iter.sg) +
@@ -2377,6 +2380,8 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
*/
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
+
+ assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
/*
@@ -2397,6 +2402,9 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
int i = 0;
struct sg_page_iter sg_iter;
dma_addr_t addr = 0;
+ int rpm_atomic_seq;
+
+ rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
for_each_sg_page(st->sgl, &sg_iter, st->nents, 0) {
addr = sg_page_iter_dma_address(&sg_iter);
@@ -2421,6 +2429,8 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
*/
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
+
+ assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
static void gen8_ggtt_clear_range(struct i915_address_space *vm,
@@ -2435,6 +2445,9 @@ static void gen8_ggtt_clear_range(struct
i915_address_space *vm,
(gen8_pte_t __iomem *) dev_priv->gtt.gsm + first_entry;
const int max_entries = gtt_total_entries(dev_priv->gtt) - first_entry;
int i;
+ int rpm_atomic_seq;
+
+ rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
if (WARN(num_entries > max_entries,
"First entry = %d; Num entries = %d (max=%d)\n",
@@ -2447,6 +2460,8 @@ static void gen8_ggtt_clear_range(struct
i915_address_space *vm,
for (i = 0; i < num_entries; i++)
gen8_set_pte(>t_base[i], scratch_pte);
readl(gtt_base);
+
+ assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
static void gen6_ggtt_clear_range(struct i915_address_space *vm,
@@ -2461,6 +2476,9 @@ static void gen6_ggtt_clear_range(struct
i915_address_space *vm,
(gen6_pte_t __iomem *) dev_priv->gtt.gsm + first_entry;
const int max_entries = gtt_total_entries(dev_priv->gtt) - first_entry;
int i;
+ int rpm_atomic_seq;
+
+ rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
if (WARN(num_entries > max_entries,
"First entry = %d; Num entries = %d (max=%d)\n",
@@ -2473,6 +2491,8 @@ static void gen6_ggtt_clear_range(struct
i915_address_space *vm,
for (i = 0; i < num_entries; i++)
iowrite32(scratch_pte, >t_base[i]);
readl(gtt_base);
+
+ assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
static void i915_ggtt_insert_entries(struct i915_address_space *vm,
@@ -2480,11 +2500,17 @@ static void i915_ggtt_insert_entries(struct
i915_address_space *vm,
uint64_t start,
enum i915_cache_level cache_level, u32
unused)
{
+ struct drm_i915_private *dev_priv = vm->dev->dev_private;
unsigned int flags = (cache_level == I915_CACHE_NONE) ?
AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
+ int rpm_atomic_seq;
+
+ rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
intel_gtt_insert_sg_entries(pages, start >> PAGE_SHIFT, flags);
+ assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+
}
static void i915_ggtt_clear_range(struct i915_address_space *vm,
@@ -2492,9 +2518,16 @@ static void i915_ggtt_clear_range(struct
i915_address_space *vm,
uint64_t length,
bool unused)
{
+ struct drm_i915_private *dev_priv = vm->dev->dev_private;
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
+ int rpm_atomic_seq;
+
+ rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
intel_gtt_clear_range(first_entry, num_entries);
+
+ assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
static int ggtt_bind_vma(struct i915_vma *vma,
--
2.5.0
_
[Intel-gfx] [PATCH 02/10] drm/i915: disable power well support on platforms without runtime PM support
All platforms with power well support have runtime PM support, so
simplify things by explicitly disabling power well support on platforms
without runtime PM support. This results in holding the init power domain
reference whenever the driver is loaded in addition to an RPM reference,
which reflects the reality better and makes it possible to simplify
things by removing the HAS_RUNTIME_PM special casing from more places in
a follow-up patch.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 9945040..f4ff5f5 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1908,6 +1908,11 @@ static int
sanitize_disable_power_well_option(const struct drm_i915_private *dev_priv,
int disable_power_well)
{
+ if (!HAS_RUNTIME_PM(dev_priv)) {
+ DRM_DEBUG_KMS("No runtime PM support, disabling display power
well support\n");
+ return 0;
+ }
+
if (disable_power_well >= 0)
return !!disable_power_well;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915: add support for checking RPM atomic sections
In some cases we want to check whether we hold an RPM wakelock reference
for the whole duration of a sequence. To achieve this add a new RPM atomic
sequence
counter that we increment any time the wakelock refcount drops to zero.
Check whether the sequence number stays the same during the atomic
section and that we hold the wakelock at the beginning of the section.
Motivated by Chris.
v2-v3:
- unchanged
v4:
- swap the order of atomic_read() and assert_rpm_wakelock_held() in
assert_rpm_atomic_begin() to avoid race
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson (v3)
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_drv.h| 17 +
drivers/gpu/drm/i915/intel_pm.c | 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ++-
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2894716..00ce627 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1603,6 +1603,7 @@ struct skl_wm_level {
*/
struct i915_runtime_pm {
atomic_t wakeref_count;
+ atomic_t atomic_seq;
bool suspended;
bool irqs_enabled;
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d8e4aca..88d37eb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1446,6 +1446,23 @@ assert_rpm_wakelock_held(struct drm_i915_private
*dev_priv)
"RPM wakelock ref not held during HW access");
}
+static inline int
+assert_rpm_atomic_begin(struct drm_i915_private *dev_priv)
+{
+ int seq = atomic_read(&dev_priv->pm.atomic_seq);
+
+ assert_rpm_wakelock_held(dev_priv);
+
+ return seq;
+}
+
+static inline void
+assert_rpm_atomic_end(struct drm_i915_private *dev_priv, int begin_seq)
+{
+ WARN_ONCE(atomic_read(&dev_priv->pm.atomic_seq) != begin_seq,
+"HW access outside of RPM atomic section\n");
+}
+
/**
* disable_rpm_wakeref_asserts - disable the RPM assert checks
* @dev_priv: i915 device instance
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6c08537..6eb9606 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7248,4 +7248,5 @@ void intel_pm_setup(struct drm_device *dev)
dev_priv->pm.suspended = false;
atomic_set(&dev_priv->pm.wakeref_count, 0);
+ atomic_set(&dev_priv->pm.atomic_seq, 0);
}
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 82c55a9..cee54ea 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2283,7 +2283,8 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv)
struct device *device = &dev->pdev->dev;
assert_rpm_wakelock_held(dev_priv);
- atomic_dec(&dev_priv->pm.wakeref_count);
+ if (atomic_dec_and_test(&dev_priv->pm.wakeref_count))
+ atomic_inc(&dev_priv->pm.atomic_seq);
pm_runtime_mark_last_busy(device);
pm_runtime_put_autosuspend(device);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: clarify comment about mandatory RPM put/get during driver load/unload
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 2c2151f..9945040 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1975,9 +1975,15 @@ int intel_power_domains_init(struct drm_i915_private
*dev_priv)
*/
void intel_power_domains_fini(struct drm_i915_private *dev_priv)
{
- /* The i915.ko module is still not prepared to be loaded when
+ /*
+* The i915.ko module is still not prepared to be loaded when
* the power well is not enabled, so just enable it in case
-* we're going to unload/reload. */
+* we're going to unload/reload.
+* The following also reacquires the RPM reference the core passed
+* to the driver during loading, which is dropped in
+* intel_runtime_pm_enable(). We have to hand back the control of the
+* device to the core with this reference held.
+*/
intel_display_set_init_power(dev_priv, true);
/* Remove the refcount we took to keep power well support disabled. */
@@ -2313,6 +2319,11 @@ void intel_runtime_pm_enable(struct drm_i915_private
*dev_priv)
pm_runtime_mark_last_busy(device);
pm_runtime_use_autosuspend(device);
+ /*
+* The core calls the driver load handler with an RPM reference held.
+* We drop that here and will reacquire it during unloading in
+* intel_power_domains_fini().
+*/
pm_runtime_put_autosuspend(device);
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Add non claimed mmio checking for vlv/chv
On Tue, Dec 15, 2015 at 07:45:42PM +0200, Mika Kuoppala wrote:
> Imre mentioned that chv might also have capability to
> track unclaimed mmio accesses. Ville added that
> both chv and vlv has this capability and he had already
> made this way back [1]. Mimic what Ville's patch does
> but adapt on top of less frequent mmio accesses by
> omitting checking always on reg writes.
>
> This patch is untested as of now.
>
> v2: overflow handling and posting omitted (Ville)
>
> References: [1]
> http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Signed-off-by: Mika Kuoppala
lgtm
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +
> drivers/gpu/drm/i915/intel_uncore.c | 31 +++
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 007ae83..0a98889 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1711,6 +1711,11 @@ enum skl_disp_power_wells {
> #define FPGA_DBG _MMIO(0x42300)
> #define FPGA_DBG_RM_NOCLAIM(1<<31)
>
> +#define CLAIM_ER _MMIO(VLV_DISPLAY_BASE + 0x2028)
> +#define CLAIM_ER_CLR (1 << 31)
> +#define CLAIM_ER_OVERFLOW (1 << 16)
> +#define CLAIM_ER_CTR_MASK 0x
> +
> #define DERRMR _MMIO(0x44050)
> /* Note that HBLANK events are reserved on bdw+ */
> #define DERRMR_PIPEA_SCANLINE (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index b6910eb..61179ae 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -335,13 +335,10 @@ static void intel_uncore_ellc_detect(struct drm_device
> *dev)
> }
>
> static bool
> -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +fpga_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> {
> u32 dbg;
>
> - if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> - return false;
> -
> dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
> if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
> return false;
> @@ -351,6 +348,32 @@ check_for_unclaimed_mmio(struct drm_i915_private
> *dev_priv)
> return true;
> }
>
> +static bool
> +vlv_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +{
> + u32 cer;
> +
> + cer = __raw_i915_read32(dev_priv, CLAIM_ER);
> + if (likely(!(cer & (CLAIM_ER_OVERFLOW | CLAIM_ER_CTR_MASK
> + return false;
> +
> + __raw_i915_write32(dev_priv, CLAIM_ER, CLAIM_ER_CLR);
> +
> + return true;
> +}
> +
> +static bool
> +check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +{
> + if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> + return fpga_check_for_unclaimed_mmio(dev_priv);
> +
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + return vlv_check_for_unclaimed_mmio(dev_priv);
> +
> + return false;
> +}
> +
> static void __intel_uncore_early_sanitize(struct drm_device *dev,
> bool restore_forcewake)
> {
> --
> 2.5.0
--
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 9/9] drm/i915: Fail the execbuff using stolen objects as batchbuffers
On 15/12/15 14:54, Chris Wilson wrote: On Tue, Dec 15, 2015 at 02:41:47PM +, Dave Gordon wrote: On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Using stolen backed objects as a batchbuffer may result into a kernel panic during relocation. Added a check to prevent the panic and fail the execbuffer call. It is not recommended to use stolen object as a batchbuffer. Signed-off-by: Ankitprasad Sharma --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 48ec484..d342f10 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -462,7 +462,9 @@ i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj, if (obj->active && pagefault_disabled()) return -EFAULT; - if (use_cpu_reloc(obj)) + if (obj->stolen) + ret = -EINVAL; I'd rather reject ALL "weird" gem objects at the first opportunity, so that none of the execbuffer code has to worry about stolen, phys, dmabuf, etc ... if (obj->ops != &i915_gem_object_ops)) ret = -EINVAL; /* No exotica please */ No. All GEM objects are supposed to be first-class so that they are interchangeable through all aspects of the API (that becomes even more important with dma-buf interoperation). We have had to relax that for a couple of special categories (basically CPU mmapping) for certain clases that are not struct file backed. Though in principle, a gemfs would work just fine. The only restrictions we should ideally impose are those determined by hardware. -Chris I don't think it's reasonable to place objects that the kernel driver cares about -- i.e. understands and decodes -- in memory areas that it does not manage, and which may be subject to arbitrary uncontrolled access by external hardware and/or processes. And I thought we couldn't kmap stolen anyway? .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: add support for checking if we hold an RPM reference
Atm, we assert that the device is not suspended until the point when the
device is truly put to a suspended state. This is fine, but we can catch
more problems if we check that RPM refcount is non-zero. After that one
drops to zero we shouldn't access the device any more, even if the actual
device suspend may be delayed. Change assert_rpm_wakelock_held()
accordingly to check for a non-zero RPM refcount in addition to the
current device-not-suspended check.
For the new asserts to work we need to annotate every place explicitly in
the code where we expect that the device is powered. The places where we
only assume this, but may not hold an RPM reference:
- driver load
We assume the device to be powered until we enable RPM. Make this
explicit by taking an RPM reference around the load function.
- system and runtime sudpend/resume handlers
These handlers are called when the RPM reference becomes 0 and know the
exact point after which the device can get powered off. Disable the
RPM-reference-held check for their duration.
- the IRQ, hangcheck and RPS work handlers
These handlers are flushed in the system/runtime suspend handler
before the device is powered off, so it's guaranteed that they won't
run while the device is powered off even though they don't hold any
RPM reference. Disable the RPM-reference-held check for their duration.
In all these cases we still check that the device is not suspended.
These explicit annotations also have the positive side effect of
documenting our assumptions better.
This caught additional WARNs from the atomic modeset path, those should
be fixed separately.
v2:
- remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville)
v3:
- use a new dedicated RPM wakelock refcount to also catch cases where
our own RPM get/put functions were not called (Chris)
- assert also that the new RPM wakelock refcount is 0 in the RPM
suspend handler (Chris)
- change the assert error message to be more meaningful (Chris)
- prevent false assert errors and check that the RPM wakelock is 0 in
the RPM resume handler too
- prevent false assert errors in the hangcheck work too
- add a device not suspended assert check to the hangcheck work
v4:
- rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts
and wakelock_count to wakeref_count
- disable the wakeref asserts in the IRQ handlers and RPS work too
- update/clarify commit message
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson (v3)
---
drivers/gpu/drm/i915/i915_dma.c | 7
drivers/gpu/drm/i915/i915_drv.c | 39 --
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 73 ++---
drivers/gpu/drm/i915/intel_drv.h| 41 ++
drivers/gpu/drm/i915/intel_pm.c | 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++
7 files changed, 158 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 84e2b20..077d64c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -896,6 +896,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
intel_pm_setup(dev);
+ intel_runtime_pm_get(dev_priv);
+
intel_display_crc_init(dev);
i915_dump_device_info(dev_priv);
@@ -1085,6 +1087,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
i915_audio_component_init(dev_priv);
+ intel_runtime_pm_put(dev_priv);
+
return 0;
out_power_well:
@@ -1120,6 +1124,9 @@ free_priv:
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
kmem_cache_destroy(dev_priv->objects);
+
+ intel_runtime_pm_put(dev_priv);
+
kfree(dev_priv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8ddfcce..61267e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -580,6 +580,8 @@ static int i915_drm_suspend(struct drm_device *dev)
dev_priv->modeset_restore = MODESET_SUSPENDED;
mutex_unlock(&dev_priv->modeset_restore_lock);
+ disable_rpm_wakeref_asserts(dev_priv);
+
/* We do a lot of poking in a lot of registers, make sure they work
* properly. */
intel_display_set_init_power(dev_priv, true);
@@ -592,7 +594,7 @@ static int i915_drm_suspend(struct drm_device *dev)
if (error) {
dev_err(&dev->pdev->dev,
"GEM idle failed, resume might fail\n");
- return error;
+ goto out;
}
intel_guc_suspend(dev);
@@ -635,7 +637,10 @@ static int i915_drm_suspend(struct drm_device *dev)
if (HAS_CSR(dev_priv))
flush_work(&dev_priv->csr.work);
- return 0;
+out:
+ enable_rpm_wakeref_asserts(dev_priv);
+
+ return error;
}
static int i9
[Intel-gfx] [PATCH 05/10] drm/i915: add assert_rpm_wakelock_held helper
As a preparation for follow-up patches add a new helper that checks
whether we hold an RPM reference, since this is what we want most of
the cases. Atm this helper will only check for the HW suspended state, a
follow-up patch will do the actual change to check the refcount instead.
One exception is the forcewake release timer function, where it's
guaranteed that the HW is on even though the RPM refcount drops to zero.
This guarantee is provided by flushing the timer in the runtime suspend
handler. So leave the assert_device_not_suspended check in place there.
Also rename assert_device_suspended for consistency and export these
helpers as a preparation for the follow-up patches.
No functional change.
v3:
- change the assert warning message to be more meaningful (Chris)
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_drv.h| 14 ++
drivers/gpu/drm/i915/intel_uncore.c | 20 +++-
2 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 798463e..9837a25 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1430,6 +1430,20 @@ void intel_display_power_get(struct drm_i915_private
*dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
+
+static inline void
+assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
+{
+ WARN_ONCE(dev_priv->pm.suspended,
+ "Device suspended during HW access\n");
+}
+
+static inline void
+assert_rpm_wakelock_held(struct drm_i915_private *dev_priv)
+{
+ assert_rpm_device_not_suspended(dev_priv);
+}
+
void intel_runtime_pm_get(struct drm_i915_private *dev_priv);
void intel_runtime_pm_get_noresume(struct drm_i915_private *dev_priv);
void intel_runtime_pm_put(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 0226776..3c63d94 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -50,12 +50,6 @@ intel_uncore_forcewake_domain_to_str(const enum
forcewake_domain_id id)
return "unknown";
}
-static void
-assert_device_not_suspended(struct drm_i915_private *dev_priv)
-{
- WARN_ONCE(dev_priv->pm.suspended, "Device suspended\n");
-}
-
static inline void
fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
{
@@ -235,7 +229,7 @@ static void intel_uncore_fw_release_timer(unsigned long arg)
struct intel_uncore_forcewake_domain *domain = (void *)arg;
unsigned long irqflags;
- assert_device_not_suspended(domain->i915);
+ assert_rpm_device_not_suspended(domain->i915);
spin_lock_irqsave(&domain->i915->uncore.lock, irqflags);
if (WARN_ON(domain->wake_count == 0))
@@ -627,7 +621,7 @@ hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
#define GEN2_READ_HEADER(x) \
u##x val = 0; \
- assert_device_not_suspended(dev_priv);
+ assert_rpm_wakelock_held(dev_priv);
#define GEN2_READ_FOOTER \
trace_i915_reg_rw(false, reg, val, sizeof(val), trace); \
@@ -669,7 +663,7 @@ __gen2_read(64)
u32 offset = i915_mmio_reg_offset(reg); \
unsigned long irqflags; \
u##x val = 0; \
- assert_device_not_suspended(dev_priv); \
+ assert_rpm_wakelock_held(dev_priv); \
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags)
#define GEN6_READ_FOOTER \
@@ -802,7 +796,7 @@ __gen6_read(64)
#define VGPU_READ_HEADER(x) \
unsigned long irqflags; \
u##x val = 0; \
- assert_device_not_suspended(dev_priv); \
+ assert_rpm_device_not_suspended(dev_priv); \
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags)
#define VGPU_READ_FOOTER \
@@ -829,7 +823,7 @@ __vgpu_read(64)
#define GEN2_WRITE_HEADER \
trace_i915_reg_rw(true, reg, val, sizeof(val), trace); \
- assert_device_not_suspended(dev_priv); \
+ assert_rpm_wakelock_held(dev_priv); \
#define GEN2_WRITE_FOOTER
@@ -869,7 +863,7 @@ __gen2_write(64)
u32 offset = i915_mmio_reg_offset(reg); \
unsigned long irqflags; \
trace_i915_reg_rw(true, reg, val, sizeof(val), trace); \
- assert_device_not_suspended(dev_priv); \
+ assert_rpm_wakelock_held(dev_priv); \
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags)
#define GEN6_WRITE_FOOTER \
@@ -1045,7 +1039,7 @@ __gen6_write(64)
#define VGPU_WRITE_HEADER \
unsigned long irqflags; \
trace_i915_reg_rw(true, reg, val, sizeof(val), trace); \
- assert_device_not_suspended(dev_priv); \
+ assert_rpm_device_not_suspended(dev_priv); \
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags)
#define VGPU_WRITE_FOOTER \
--
2.5.0
_
[Intel-gfx] [PATCH 08/10] drm/i915: check that we hold an RPM wakelock ref before we put it
v2-v3: - unchanged v4: - keep the corresponding check in the get helper (Chris) Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 29157fb..82c55a9 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -2282,6 +2282,7 @@ void intel_runtime_pm_put(struct drm_i915_private *dev_priv) struct drm_device *dev = dev_priv->dev; struct device *device = &dev->pdev->dev; + assert_rpm_wakelock_held(dev_priv); atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(device); -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
We don't really need to check this flag in the get/put/assert helpers,
as on platforms without RPM support we won't ever enable RPM. That means
pm.suspend will be always false and the assert will be always true.
Do this to simplify the code and to let us extend the RPM asserts to all
platforms for a better coverage.
Motivated by Ville.
v2-v3:
- unchanged
v4:
- remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too
made possible by the previous two patches
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson (v3)
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 12
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 342baa9..bca7ca7 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2237,9 +2237,6 @@ void intel_runtime_pm_get(struct drm_i915_private
*dev_priv)
struct drm_device *dev = dev_priv->dev;
struct device *device = &dev->pdev->dev;
- if (!HAS_RUNTIME_PM(dev))
- return;
-
pm_runtime_get_sync(device);
WARN(dev_priv->pm.suspended, "Device still suspended.\n");
}
@@ -2266,9 +2263,6 @@ void intel_runtime_pm_get_noresume(struct
drm_i915_private *dev_priv)
struct drm_device *dev = dev_priv->dev;
struct device *device = &dev->pdev->dev;
- if (!HAS_RUNTIME_PM(dev))
- return;
-
WARN(dev_priv->pm.suspended, "Getting nosync-ref while suspended.\n");
pm_runtime_get_noresume(device);
}
@@ -2286,9 +2280,6 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv)
struct drm_device *dev = dev_priv->dev;
struct device *device = &dev->pdev->dev;
- if (!HAS_RUNTIME_PM(dev))
- return;
-
pm_runtime_mark_last_busy(device);
pm_runtime_put_autosuspend(device);
}
@@ -2308,9 +2299,6 @@ void intel_runtime_pm_enable(struct drm_i915_private
*dev_priv)
struct drm_device *dev = dev_priv->dev;
struct device *device = &dev->pdev->dev;
- if (!HAS_RUNTIME_PM(dev))
- return;
-
pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
pm_runtime_mark_last_busy(device);
pm_runtime_use_autosuspend(device);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index fcf04fe..0226776 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -53,8 +53,7 @@ intel_uncore_forcewake_domain_to_str(const enum
forcewake_domain_id id)
static void
assert_device_not_suspended(struct drm_i915_private *dev_priv)
{
- WARN_ONCE(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
- "Device suspended\n");
+ WARN_ONCE(dev_priv->pm.suspended, "Device suspended\n");
}
static inline void
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 00/10] drm/i915: improve the RPM device suspended assert
This is v4 of [1]. It has the following changes: - fix module reload that got broken in v3 due to removal of HAS_RUNTIME_PM (added patch 1-3 + revised patch 4) - disable the wakeref asserts in the IRQ handlers and RPS work too (revised patch 7) Imre Deak (10): drm/i915: clarify comment about mandatory RPM put/get during driver load/unload drm/i915: disable power well support on platforms without runtime PM support drm/i915: refactor RPM disabling due to RC6 being disabled drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers drm/i915: add assert_rpm_wakelock_held helper drm/i915: use assert_rpm_wakelock_held instead of opencoding it drm/i915: add support for checking if we hold an RPM reference drm/i915: check that we hold an RPM wakelock ref before we put it drm/i915: add support for checking RPM atomic sections drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters drivers/gpu/drm/i915/i915_dma.c | 7 drivers/gpu/drm/i915/i915_drv.c | 39 -- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_gem_gtt.c | 33 +++ drivers/gpu/drm/i915/i915_irq.c | 73 ++--- drivers/gpu/drm/i915/intel_drv.h| 72 drivers/gpu/drm/i915/intel_pm.c | 17 drivers/gpu/drm/i915/intel_runtime_pm.c | 57 - drivers/gpu/drm/i915/intel_uncore.c | 23 --- 9 files changed, 270 insertions(+), 53 deletions(-) -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Add non claimed mmio checking for vlv/chv
Imre mentioned that chv might also have capability to
track unclaimed mmio accesses. Ville added that
both chv and vlv has this capability and he had already
made this way back [1]. Mimic what Ville's patch does
but adapt on top of less frequent mmio accesses by
omitting checking always on reg writes.
This patch is untested as of now.
v2: overflow handling and posting omitted (Ville)
References: [1]
http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_uncore.c | 31 +++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 007ae83..0a98889 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1711,6 +1711,11 @@ enum skl_disp_power_wells {
#define FPGA_DBG _MMIO(0x42300)
#define FPGA_DBG_RM_NOCLAIM (1<<31)
+#define CLAIM_ER _MMIO(VLV_DISPLAY_BASE + 0x2028)
+#define CLAIM_ER_CLR (1 << 31)
+#define CLAIM_ER_OVERFLOW(1 << 16)
+#define CLAIM_ER_CTR_MASK0x
+
#define DERRMR _MMIO(0x44050)
/* Note that HBLANK events are reserved on bdw+ */
#define DERRMR_PIPEA_SCANLINE(1<<0)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b6910eb..61179ae 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -335,13 +335,10 @@ static void intel_uncore_ellc_detect(struct drm_device
*dev)
}
static bool
-check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+fpga_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
{
u32 dbg;
- if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
- return false;
-
dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
return false;
@@ -351,6 +348,32 @@ check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
return true;
}
+static bool
+vlv_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+{
+ u32 cer;
+
+ cer = __raw_i915_read32(dev_priv, CLAIM_ER);
+ if (likely(!(cer & (CLAIM_ER_OVERFLOW | CLAIM_ER_CTR_MASK
+ return false;
+
+ __raw_i915_write32(dev_priv, CLAIM_ER, CLAIM_ER_CLR);
+
+ return true;
+}
+
+static bool
+check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+{
+ if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
+ return fpga_check_for_unclaimed_mmio(dev_priv);
+
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ return vlv_check_for_unclaimed_mmio(dev_priv);
+
+ return false;
+}
+
static void __intel_uncore_early_sanitize(struct drm_device *dev,
bool restore_forcewake)
{
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Consolidate unclaimed mmio detection
Access the unclaimed reg detection register through
one helper which also does cleanup. Note that we now access
the register only if the platform has the actual non claimed
access bit. This prevents reading the register with gens that
doesn't have the register or the unclaimed bit,
when debug_mmio > 0.
Note that we post after clearing the bit. This makes sure
that the next unclaimed write access would get detected
also if it happened right after clearing, and not fold
into the previous detection.
v2: s/unclaimed_reg_access/check_for_unclaimed_mmio (Chris)
debug log on unclaimed detection on uncore init (Joonas)
v3: remove posting read (Ville)
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Paulo Zanoni
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index fcf04fe..fb13b5c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -334,13 +334,31 @@ static void intel_uncore_ellc_detect(struct drm_device
*dev)
}
}
+static bool
+check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+{
+ u32 dbg;
+
+ if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
+ return false;
+
+ dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
+ if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
+ return false;
+
+ __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+
+ return true;
+}
+
static void __intel_uncore_early_sanitize(struct drm_device *dev,
bool restore_forcewake)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- if (HAS_FPGA_DBG_UNCLAIMED(dev))
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+ /* clear out unclaimed reg detection bit */
+ if (check_for_unclaimed_mmio(dev_priv))
+ DRM_DEBUG("unclaimed mmio detected on uncore init, clearing\n");
/* clear out old GT FIFO errors */
if (IS_GEN6(dev) || IS_GEN7(dev))
@@ -601,10 +619,9 @@ hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv,
if (!i915.mmio_debug)
return;
- if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
+ if (check_for_unclaimed_mmio(dev_priv)) {
WARN(1, "Unclaimed register detected %s %s register 0x%x\n",
when, op, i915_mmio_reg_offset(reg));
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
i915.mmio_debug--; /* Only report the first N failures */
}
}
@@ -617,11 +634,10 @@ hsw_unclaimed_reg_detect(struct drm_i915_private
*dev_priv)
if (i915.mmio_debug || !mmio_debug_once)
return;
- if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
+ if (check_for_unclaimed_mmio(dev_priv)) {
DRM_DEBUG("Unclaimed register detected, "
"enabling oneshot unclaimed register reporting. "
"Please use i915.mmio_debug=N for more
information.\n");
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
i915.mmio_debug = mmio_debug_once--;
}
}
@@ -1589,11 +1605,6 @@ bool intel_has_gpu_reset(struct drm_device *dev)
void intel_uncore_check_errors(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
- (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM)) {
+ if (check_for_unclaimed_mmio(to_i915(dev)))
DRM_ERROR("Unclaimed register before interrupt\n");
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
- }
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2)
On Thu, Dec 03, 2015 at 11:37:36AM -0800, Matt Roper wrote:
> If we fail to reconstruct the BIOS fb (e.g., because the FB is too
> large), we'll be left with plane state that indicates the primary plane
> is visible yet has a NULL fb. This mismatch causes problems later on
> (e.g., for the watermark code). Since we've failed to reconstruct the
> BIOS FB, the best solution is to just disable the primary plane and
> pretend the BIOS never had it enabled.
>
> v2: Add intel_pre_disable_primary() call (Maarten)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Signed-off-by: Matt Roper
> Reviewed-by: Maarten Lankhorst
+drm-intel-fixes
We're still waiting for the rest of the series to be reviewed, but this
first patch already has Maarten's r-b and should probably go into -fixes.
Possibly stable as well if we get confirmation that this also fixes any
of the bugzillas listed below?
Matt
> ---
> As previously noted, this might also fix some GPU hangs on older platforms
> (unconfirmed). Potential bugzillas include:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=89319
> https://bugs.freedesktop.org/show_bug.cgi?id=87677
> https://bugs.freedesktop.org/show_bug.cgi?id=89146
> https://bugs.freedesktop.org/show_bug.cgi?id=91653
>
> This should probably go into -fixes (and possibly stable if we get
> confirmation
> on any of those bugzillas?)
>
> drivers/gpu/drm/i915/intel_display.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4959adb..e5c0807 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -116,6 +116,7 @@ static void skylake_pfit_enable(struct intel_crtc *crtc);
> static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force);
> static void ironlake_pfit_enable(struct intel_crtc *crtc);
> static void intel_modeset_setup_hw_state(struct drm_device *dev);
> +static void intel_pre_disable_primary(struct drm_crtc *crtc);
>
> typedef struct {
> int min, max;
> @@ -2597,6 +2598,8 @@ intel_find_initial_plane_obj(struct intel_crtc
> *intel_crtc,
> struct drm_i915_gem_object *obj;
> struct drm_plane *primary = intel_crtc->base.primary;
> struct drm_plane_state *plane_state = primary->state;
> + struct drm_crtc_state *crtc_state = intel_crtc->base.state;
> + struct intel_plane *intel_plane = to_intel_plane(primary);
> struct drm_framebuffer *fb;
>
> if (!plane_config->fb)
> @@ -2633,6 +2636,18 @@ intel_find_initial_plane_obj(struct intel_crtc
> *intel_crtc,
> }
> }
>
> + /*
> + * We've failed to reconstruct the BIOS FB. Current display state
> + * indicates that the primary plane is visible, but has a NULL FB,
> + * which will lead to problems later if we don't fix it up. The
> + * simplest solution is to just disable the primary plane now and
> + * pretend the BIOS never had it enabled.
> + */
> + to_intel_plane_state(plane_state)->visible = false;
> + crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
> + intel_pre_disable_primary(&intel_crtc->base);
> + intel_plane->disable_plane(primary, &intel_crtc->base);
> +
> return;
>
> valid_fb:
> --
> 2.1.4
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Record the ringbuffer associated with the request
On 14/12/15 11:28, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 11:14:31AM +, Dave Gordon wrote:
On 11/12/15 22:59, Chris Wilson wrote:
The request tells us where to read the ringbuf from, so use that
information to simplify the error capture. If no request was active at
the time of the hang, the ring is idle and there is no information
inside the ring pertaining to the hang.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3e137fc701cf..6eefe9c36931 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -995,7 +995,7 @@ static void i915_gem_record_rings(struct drm_device *dev,
for (i = 0; i < I915_NUM_RINGS; i++) {
struct intel_engine_cs *ring = &dev_priv->ring[i];
- struct intel_ringbuffer *rbuf;
+ struct intel_ringbuffer *rbuf = NULL;
error->ring[i].pid = -1;
@@ -1039,26 +1039,17 @@ static void i915_gem_record_rings(struct drm_device
*dev,
}
rcu_read_unlock();
}
+
+ rbuf = request->ringbuf;
}
- if (i915.enable_execlists) {
- /* TODO: This is only a small fix to keep basic error
-* capture working, but we need to add more information
-* for it to be useful (e.g. dump the context being
-* executed).
-*/
- if (request)
- rbuf = request->ctx->engine[ring->id].ringbuf;
- else
- rbuf =
ring->default_context->engine[ring->id].ringbuf;
- } else
- rbuf = ring->buffer;
-
- error->ring[i].cpu_ring_head = rbuf->head;
- error->ring[i].cpu_ring_tail = rbuf->tail;
-
- error->ring[i].ringbuffer =
- i915_error_ggtt_object_create(dev_priv, rbuf->obj);
+ if (rbuf) {
+ error->ring[i].cpu_ring_head = rbuf->head;
+ error->ring[i].cpu_ring_tail = rbuf->tail;
+ error->ring[i].ringbuffer =
+ i915_error_ggtt_object_create(dev_priv,
+ rbuf->obj);
+ }
error->ring[i].hws_page =
i915_error_ggtt_object_create(dev_priv,
ring->status_page.obj);
I think the code you deleted is intended to capture the *default*
ringbuffer if there is no request active -- sometimes we will switch
an engine to the default context (and therefore ringbuffer) when
there's no work to be done.
So answer the question, why? I don't have a use for it. This code in
particular is nothing more than a hack for execlists and in no way
reflects my intentions for the postmortem debugging tool.
Another option that's sometimes useful is to capture the ringbuffer
pointed to by the START register. This helps in finding situations
where the driver and the GPU disagree about what should be in
progress.
That is a possibitly, except is no more interesting than inspecting the
START vs expected (and requires the stop_machine rework to walk the
lists without crashing).
I've got a few patches that update some of the error capture that's
always been missing in execlist mode (like, actually capturing the
active context), and add some more decoding of what we do capture.
No decoding. That is easier done in userspace. And I sent patches to do
more capturing many, many months ago, along with fixing up most of the
invalid ppgtt state.
-Chris
Anyway, the removal of the unnecessary execlist/non-execlist is
worthwhile, so
Reviewed-by: Dave Gordon
and then maybe I'll rework the default and/or START capture on top of
this later.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Allow userspace to request no-error-capture upon GPU hangs
On 11/12/15 22:59, Chris Wilson wrote:
igt likes to inject GPU hangs into its command streams. However, as we
expect these hangs, we don't actually want them recorded in the dmesg
output or stored in the i915_error_state (usually). To accomodate this
allow userspace to set a flag on the context that any hang emanating
from that context will not be recorded. We still do the error capture
(otherwise how do we find the guilty context and know its intent?) as
part of the reason for random GPU hang injection is to exercise the race
conditions between the error capture and normal execution.
v2: Split out the request->ringbuf error capture changes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 8 ++--
drivers/gpu/drm/i915/i915_gem_context.c | 13 +
drivers/gpu/drm/i915/i915_gpu_error.c | 13 -
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b33091c2c39e..c511b3cbf9b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -493,6 +493,7 @@ struct drm_i915_error_state {
struct timeval time;
char error_msg[128];
+ bool simulated;
int iommu;
u32 reset_count;
u32 suspend_count;
@@ -845,7 +846,9 @@ struct i915_ctx_hang_stats {
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
The #defines below need a comment, at the very least:
/* Bits in struct intel_context::flags below */
otherwise we can't tell where they are appropriate.
With that fixed, then
Reviewed-by: Dave Gordon
-#define CONTEXT_NO_ZEROMAP (1<<0)
+#define CONTEXT_NO_ZEROMAP (1<<0)
+#define CONTEXT_NO_ERROR_CAPTURE (1<<1)
+
/**
* struct intel_context - as the name implies, represents a context.
* @ref: reference count.
@@ -870,11 +873,12 @@ struct intel_context {
int user_handle;
uint8_t remap_slice;
struct drm_i915_private *i915;
- int flags;
struct drm_i915_file_private *file_priv;
struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
+ unsigned flags;
+
/* Legacy ring buffer submission */
struct {
struct drm_i915_gem_object *rcs_state;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 900ffd044db8..d9998ab9d94d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -938,6 +938,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev,
void *data,
else
args->value = to_i915(dev)->gtt.base.total;
break;
+ case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
+ args->value = !!(ctx->flags & CONTEXT_NO_ERROR_CAPTURE);
+ break;
default:
ret = -EINVAL;
break;
@@ -983,6 +986,16 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
ctx->flags |= args->value ? CONTEXT_NO_ZEROMAP : 0;
}
break;
+ case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
+ if (args->size) {
+ ret = -EINVAL;
+ } else {
+ if (args->value)
+ ctx->flags |= CONTEXT_NO_ERROR_CAPTURE;
+ else
+ ctx->flags &= ~CONTEXT_NO_ERROR_CAPTURE;
+ }
+ break;
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 6eefe9c36931..6db6d7e02aea 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1040,6 +1040,7 @@ static void i915_gem_record_rings(struct drm_device *dev,
rcu_read_unlock();
}
+ error->simulated |= request->ctx->flags &
CONTEXT_NO_ERROR_CAPTURE;
rbuf = request->ringbuf;
}
@@ -1336,12 +1337,14 @@ void i915_capture_error_state(struct drm_device *dev,
bool wedged,
i915_error_capture_msg(dev, error, wedged, error_msg);
DRM_INFO("%s\n", error->error_msg);
- spin_lock_irqsave(&dev_priv->gpu_error.lock, flags);
- if (dev_priv->gpu_error.first_error == NULL) {
- dev_priv->gpu_error.first_error = error;
- error = NULL;
+ if (!error->simulated) {
+ spin_lock_irqsave(&dev_priv->gpu_error.lock, flags);
+ if (dev_priv->gpu_error.first_error == NULL) {
+ dev_priv->gpu_error.first_error = error;
+ error = NULL;
+ }
+ spin_unlock_
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Support for pread/pwrite from/to non shmem backed objects
On 11/12/15 18:15, Daniel Vetter wrote:
On Wed, Dec 09, 2015 at 07:39:56PM +, Dave Gordon wrote:
On 09/12/15 16:15, Tvrtko Ursulin wrote:
Hi,
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.
v2: Drop locks around slow_user_access, prefault the pages before
access (Chris)
v3: Rebased to the latest drm-intel-nightly (Ankit)
v4: Moved page base & offset calculations outside the copy loop,
corrected data types for size and offset variables, corrected if-else
braces format (Tvrtko/kerneldocs)
v5: Enabled pread/pwrite for all non-shmem backed objects including
without tiling restrictions (Ankit)
v6: Using pwrite_fast for non-shmem backed objects as well (Chris)
v7: Updated commit message, Renamed i915_gem_gtt_read to
i915_gem_gtt_copy,
added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)
v8: Updated v7 commit message, mutex unlock around pwrite slow path for
non-shmem backed objects (Tvrtko)
Testcase: igt/gem_stolen
Signed-off-by: Ankitprasad Sharma
---
drivers/gpu/drm/i915/i915_gem.c | 151
+---
1 file changed, 127 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
[snip!]
static int
i915_gem_shmem_pread(struct drm_device *dev,
struct drm_i915_gem_object *obj,
@@ -737,17 +830,14 @@ i915_gem_pread_ioctl(struct drm_device *dev,
void *data,
goto out;
}
-/* prime objects have no backing filp to GEM pread/pwrite
- * pages from.
- */
-if (!obj->base.filp) {
-ret = -EINVAL;
-goto out;
-}
-
trace_i915_gem_object_pread(obj, args->offset, args->size);
-ret = i915_gem_shmem_pread(dev, obj, args, file);
+/* pread for non shmem backed objects */
+if (!obj->base.filp && obj->tiling_mode == I915_TILING_NONE)
+ret = i915_gem_gtt_copy(dev, obj, args->size,
+args->offset, args->data_ptr);
+else
+ret = i915_gem_shmem_pread(dev, obj, args, file);
Hm, it will end up calling i915_gem_shmem_pread for non-shmem backed
objects if tiling is set. Sounds wrong to me unless I am missing something?
Which GEM objects have obj->base.filp set? Is it ONLY regular gtt-type
obj->base.filp is for shmem backed stuff. gtt is irrelevant for backing
storage, well except if you can't read the shmem stuff directly with the
cpu the only way is to go through a gtt device mapping.
-Daniel
So obj->base.filp is set for both phys and shmem (default) object types;
I called the latter a "gtt" type just because the get/put_pages()
functions have "gtt" in their names). But I note that the naming of GEM
object vfuncs (and vfunc tables) isn't consistent :( Maybe they should
be named "i915_gem_object_{get,put}_pages_shmem()", and the table would
then be i915_gem_object_shmem_ops :)
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Documentation style guide
On Tue, Dec 15, 2015 at 02:56:10PM +, Dave Gordon wrote: > On 14/12/15 15:39, Thierry Reding wrote: > >On Wed, Dec 09, 2015 at 05:08:02PM +0100, Daniel Vetter wrote: > >>Every time I type or review docs this seems a bit different. Try to > >>document the common style so we can try to unify at least new docs. > >> > >>v2: Spelling fixes from Pierre, Laurent and Jani. > >> > >>v3: More spelling fixes from Lukas. > >> > >>Cc: Pierre Moreau > >>Cc: Jani Nikula > >>Cc: Laurent Pinchart > >>Cc: Lukas Wunner > >>Acked-by: Laurent Pinchart > >>Signed-off-by: Daniel Vetter > >>Link: > >>http://patchwork.freedesktop.org/patch/msgid/1449564561-3896-1-git-send-email-daniel.vet...@ffwll.ch > >>--- > >> Documentation/DocBook/gpu.tmpl | 37 + > >> 1 file changed, 37 insertions(+) > >> > >>diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl > >>index 749b8e2f2113..c66d6412f573 100644 > >>--- a/Documentation/DocBook/gpu.tmpl > >>+++ b/Documentation/DocBook/gpu.tmpl > >>@@ -124,6 +124,43 @@ > >> > >>[Insert diagram of typical DRM stack here] > >> > >>+ > >>+Style Guidelines > >>+ > >>+ For consistency this documentation uses American English. > >>Abbreviations > >>+ are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, > >>and so > >>+ on. To aid in reading, documentations make full use of the markup > > > >"..., the documentation makes full use of..." and perhaps "makes use of > >the full set of markup characters that kerneldoc provides". > > > >>+ characters kerneldoc provides: @parameter for function parameters, > >>@member > >>+ for structure members, &structure to reference structures and > >>+ function() for functions. These all get automatically hyperlinked if > >>+ kerneldoc for the referenced objects exists. When referencing > >>entries in > >>+ function vtables please use ->vfunc(). Note that kerneldoc does > >>+ not support referencing struct members directly, so please add a > >>reference > >>+ to the vtable struct somewhere in the same paragraph or at least > >>section. > >>+ > >>+ > >>+ Except in special situations (to separate locked from unlocked > >>variants) > >>+ locking requirements for functions aren't documented in the > >>kerneldoc. > >>+ Instead locking should be check at runtime using e.g. > > > >"should be checked" > > > >>+ WARN_ON(!mutex_is_locked(...));. Since it's much easier > >>to > >>+ ignore documentation than runtime noise this provides more value. > >>And on > >>+ top of that runtime checks do need to be updated when the locking > >>rules > >>+ change, increasing the chances that they're correct. Within the > > A few commas to delimit subclauses would make this more readable: > > Since it's much easier to ignore documentation than runtime noise, this > provides more value. And on top of that, runtime checks have to be updated > when the locking rules change, thus increasing the chances that they're > correct. > > >>+ documentation the locking rules should be explained in the relevant > >>+ structures: Either in the comment for the lock explaining what it > >>+ protects, or data fields need a note about which lock protects them, > >>or > >>+ both. > > > >I think you're supposed to have the "or" only in the final subsentence: > > > > "either ... protects, data fields need ..., or both." > > Within the documentation, the locking rules should be explained in comments > on the relevant structures; these comments may be with the lock, explaining > what it protects, or with the data, noting which lock protects it, or both > -- in which case they should agree! > > >>+ > >>+ > >>+ Functions which have a non-void return value should > >>have a > >>+ section called "Returns" explaining the expected return values in > >>+ different cases and their meanings. Currently there's no consensus > >>whether > >>+ that section name should be all upper-case or not, and whether it > >>should > >>+ end in a colon or not. Go with the file-local style. Other common > >>section > > > >I thought the colon was necessary for kerneldoc to turn it into a > >section? > > > >Overall, long overdue, so thanks for writing it up: > > > >Acked-by: Thierry Reding Unfortunately pull request with this already went to Dave before I could take your feedback into account. Anyone up for a quick follow-up patch that I could vacuum up in time for 4.5 (i.e. until Thu latest)? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 i-g-t v2] tests: update .gitignore and add a Makefile rule to create it
On 10 December 2015 at 09:27, Morton, Derek J wrote: >> >> >>-Original Message- >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >>Daniel Vetter >>Sent: Thursday, December 10, 2015 9:07 AM >>To: Wood, Thomas >>Cc: intel-gfx@lists.freedesktop.org >>Subject: Re: [Intel-gfx] [PATCH i-g-t v2] tests: update .gitignore and add a >>Makefile rule to create it >> >>On Mon, Dec 07, 2015 at 03:12:15PM +, Thomas Wood wrote: >>> v2: generate the .gitignore file with the default target >>> >>> Signed-off-by: Thomas Wood >> >>Hm, committing files that the build system updates is generally a bad idea. I >>think if we do this, we should remove the .gitignore here. Not sure how that >>will work in general. >> >>But since I screw this up every 2nd time I really like the idea. >>-Daniel > > This does not apply to the android build system so .gitignore would never be > generated during android builds. However the android build system does not > put the test binaries in the same place as the source code so perhaps it does > not matter. I had kept the file in the repository because it wouldn't be generated by the Android build system. However, since it doesn't apply to Android builds, I'll remove .gitignore from the repository and then it will always be created by the automake build system. > > //Derek > >> >>> --- >>> tests/.gitignore | 13 +++-- >>> tests/Makefile.am | 4 >>> 2 files changed, 11 insertions(+), 6 deletions(-) >>> >>> diff --git a/tests/.gitignore b/tests/.gitignore index >>> 6377007..f127bfc 100644 >>> --- a/tests/.gitignore >>> +++ b/tests/.gitignore >>> @@ -1,7 +1,6 @@ >>> -# Please keep sorted alphabetically >>> core_auth >>> -core_get_client_auth >>> core_getclient >>> +core_get_client_auth >>> core_getstats >>> core_getversion >>> core_prop_blob >>> @@ -27,6 +26,7 @@ gem_close_race >>> gem_concurrent_all >>> gem_concurrent_blit >>> gem_cpu_reloc >>> +gem_create >>> gem_cs_prefetch >>> gem_cs_tlb >>> gem_ctx_bad_destroy >>> @@ -51,9 +51,9 @@ gem_exec_nop >>> gem_exec_params >>> gem_exec_parse >>> gem_fd_exhaustion >>> +gem_fenced_exec_thrash >>> gem_fence_thrash >>> gem_fence_upload >>> -gem_fenced_exec_thrash >>> gem_flink_basic >>> gem_flink_race >>> gem_gpgpu_fill >>> @@ -94,14 +94,16 @@ gem_render_linear_blits gem_render_tiled_blits >>> gem_request_retire gem_reset_stats >>> +gem_ringfill >>> gem_ring_sync_copy >>> gem_ring_sync_loop >>> -gem_ringfill >>> gem_seqno_wrap >>> gem_set_tiling_vs_blt >>> gem_set_tiling_vs_gtt >>> gem_set_tiling_vs_pwrite >>> +gem_stolen >>> gem_storedw_batches_loop >>> +gem_storedw_loop >>> gem_streaming_writes >>> gem_stress >>> gem_threaded_access_tiled >>> @@ -167,6 +169,5 @@ prime_nv_test >>> prime_self_import >>> prime_udl >>> template >>> -test-list.txt >>> testdisplay >>> -gem_storedw_loop >>> +test-list.txt >>> diff --git a/tests/Makefile.am b/tests/Makefile.am index >>> c4f1f01..2b25cd3 100644 >>> --- a/tests/Makefile.am >>> +++ b/tests/Makefile.am >>> @@ -32,6 +32,10 @@ dist_pkgdata_DATA = \ >>> $(IMAGES) \ >>> $(NULL) >>> >>> +all-local: .gitignore >>> +.gitignore: Makefile.sources >>> +@echo "$(pkglibexec_PROGRAMS) $(HANG) test-list.txt" | sed >>> +'s/\s\+/\n/g' | sort > $@ >>> + >>> pkgdata_DATA = test-list.txt >>> >>> EXTRA_PROGRAMS = $(HANG) >>> -- >>> 1.9.1 >>> >>> ___ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >>-- >>Daniel Vetter >>Software Engineer, Intel Corporation >>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 v3] drm/i915/guc: Move GuC wq_check_space to alloc_request_extras
On 11/12/15 01:17, yu@intel.com wrote:
From: Alex Dai
Split GuC work queue space checking from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle the error.
v1: Move wq_reserve_space to ring_reserve_space
v2: Move wq_reserve_space to alloc_request_extras (Chris Wilson)
v3: The work queue head pointer is cached by driver now. So we can
quickly return if space is available.
s/reserve/check/g (Dave Gordon)
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_guc_submission.c | 34 ++
drivers/gpu/drm/i915/intel_guc.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 6 ++
3 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 226e9c0..cb8e1f71 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -207,6 +207,9 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
/* Update the tail so it is visible to GuC */
desc->tail = gc->wq_tail;
+ /* Cache the head where GuC is processing */
+ gc->wq_head = desc->head;
+
This could be at the end of this function, thus:
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
db_exc.cookie = db_ret.cookie + 1;
if (db_exc.cookie == 0)
db_exc.cookie = 1;
}
+ /* Finally, update the cached copy of the GuC's WQ head */
+ gc->wq_head = desc->head;
+
kunmap_atomic(base);
return ret;
}
which might increase the chance that we will get an updated value and
thus avoid having to spinwait on the next check().
/* current cookie */
db_cmp.db_status = GUC_DOORBELL_ENABLED;
db_cmp.cookie = gc->cookie;
@@ -472,28 +475,30 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,
sizeof(desc) * client->ctx_index);
}
-/* Get valid workqueue item and return it back to offset */
-static int guc_get_workqueue_space(struct i915_guc_client *gc, u32 *offset)
+int i915_guc_wq_check_space(struct i915_guc_client *gc)
{
struct guc_process_desc *desc;
void *base;
u32 size = sizeof(struct guc_wq_item);
int ret = -ETIMEDOUT, timeout_counter = 200;
+ if (!gc)
+ return 0;
+
+ /* Quickly return if wq space is available since last time we cache the
+* head position. */
+ if (CIRC_SPACE(gc->wq_tail, gc->wq_head, gc->wq_size) >= size)
+ return 0;
+
base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, 0));
desc = base + gc->proc_desc_offset;
while (timeout_counter-- > 0) {
- if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
- *offset = gc->wq_tail;
+ gc->wq_head = desc->head;
- /* advance the tail for next workqueue item */
- gc->wq_tail += size;
- gc->wq_tail &= gc->wq_size - 1;
-
- /* this will break the loop */
- timeout_counter = 0;
+ if (CIRC_SPACE(gc->wq_tail, gc->wq_head, gc->wq_size) >= size) {
ret = 0;
+ break;
}
if (timeout_counter)
@@ -512,11 +517,8 @@ static int guc_add_workqueue_item(struct i915_guc_client
*gc,
struct guc_wq_item *wqi;
void *base;
u32 tail, wq_len, wq_off = 0;
- int ret;
- ret = guc_get_workqueue_space(gc, &wq_off);
- if (ret)
- return ret;
+ wq_off = gc->wq_tail;
Conversely, I'd prefer the updates below to be here instead; also the
check that I mentioned last time:
+ u32 space = CIRC_SPACE(gc->wq_tail, gc->wq_head, gc->wq_size);
+ if (WARN_ON(space < sizeof(struct guc_wq_item))
+ return -ENOSPC; /* shouldn't happen */
+
+ /* postincrement WQ tail for next time */
+ wq_off = gc->wq_tail;
+ gc->wq_tail += sizeof(struct guc_wq_item);
+ gc->wq_tail &= gc->wq_size - 1;
/* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we
* should not have the case where structure wqi is across page, neither
@@ -551,6 +553,10 @@ static int guc_add_workqueue_item(struct i915_guc_client
*gc,
kunmap_atomic(base);
+ /* advance the tail for next workqueue item */
+ gc->wq_tail += sizeof(struct guc_wq_item);
+ gc->wq_tail &= gc->wq_size - 1;
(moved to above)
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 0e048bf..5cf555d 100644
--- a/drivers/gpu/drm/
[Intel-gfx] [RFC 6/7] drm/i915/panel: setup pwm backlight based on connector type
Use the connector type instead of VBT directly to decide which backlight
mechanism to use on VLV/CHV. (Indirectly, this is the same thing, but
hides the VBT use.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 72183a057c79..381f6da6e2e9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1758,7 +1758,6 @@ intel_panel_init_backlight_funcs(struct intel_panel
*panel)
struct intel_connector *intel_connector =
container_of(panel, struct intel_connector, panel);
struct drm_device *dev = intel_connector->base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
if (IS_BROXTON(dev)) {
panel->backlight.setup = bxt_setup_backlight;
@@ -1785,7 +1784,8 @@ intel_panel_init_backlight_funcs(struct intel_panel
*panel)
panel->backlight.get = pch_get_backlight;
panel->backlight.hz_to_pwm = pch_hz_to_pwm;
} else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
- if (dev_priv->vbt.has_mipi) {
+ if (intel_connector->base.connector_type ==
+ DRM_MODE_CONNECTOR_DSI) {
panel->backlight.setup = pwm_setup_backlight;
panel->backlight.enable = pwm_enable_backlight;
panel->backlight.disable = pwm_disable_backlight;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/7] start hiding away vbt structure from the driver
The VBT is a monster and it keeps growing. Originally we've extracted
bits and pieces out of there, and added them cleanly to our own
structures in dev_priv->vbt, with our own macros. Later on we've been
slipping and we have copied stuff from VBT verbatim, using the same
structs and defines as in VBT.
Start abstracting the VBT more, hiding away the VBT specific stuff that
should not be fiddled with outside of intel_bios.c. Make it more
explicit when we're doing so. At this stage, mostly just fork the
private parts into intel_bios_private.h. As prep work, move some stuff
to intel_bios.c to limit the amount of macros needing to be exposed
across the whole driver.
I think this is the right direction, but this has plenty of bikeshedding
potential. Therefore here's an early RFC. This is based on [1] but the
conflicts are small.
BR,
Jani.
[1] http://mid.gmane.org/cover.1450089383.git.jani.nik...@intel.com
Jani Nikula (7):
drm/i915: move drmP.h include to i915_drv.h
drm/i915: move VBT based TV presence check to intel_bios.c
drm/i915: move VBT based LVDS presence check to intel_bios.c
drm/i915: move VBT based eDP port check to intel_bios.c
drm/i915: move VBT based DSI presence check to intel_bios.c
drm/i915/panel: setup pwm backlight based on connector type
drm/i915/bios: hide away VBT specific things in a private bios header
drivers/gpu/drm/i915/i915_drv.h|6 +-
drivers/gpu/drm/i915/intel_bios.c | 156 ++-
drivers/gpu/drm/i915/intel_bios.h | 1226
.../i915/{intel_bios.h => intel_bios_private.h}| 230 +---
drivers/gpu/drm/i915/intel_dp.c| 21 +-
drivers/gpu/drm/i915/intel_dsi.c | 23 +-
drivers/gpu/drm/i915/intel_lvds.c | 53 +-
drivers/gpu/drm/i915/intel_panel.c |4 +-
drivers/gpu/drm/i915/intel_tv.c| 43 +-
9 files changed, 438 insertions(+), 1324 deletions(-)
rewrite drivers/gpu/drm/i915/intel_bios.h (76%)
rename drivers/gpu/drm/i915/{intel_bios.h => intel_bios_private.h} (81%)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/7] drm/i915: move VBT based LVDS presence check to intel_bios.c
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 50
drivers/gpu/drm/i915/intel_lvds.c | 53 +--
3 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a748b2c0d168..bb5c9e4b0af0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3359,6 +3359,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
int intel_bios_init(struct drm_device *dev);
bool intel_bios_is_valid_vbt(const void *buf, size_t size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
+bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 6e3e647834af..264451167644 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1386,3 +1386,53 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv)
return false;
}
+
+/**
+ * intel_bios_is_lvds_present - is LVDS present in VBT
+ * @dev_priv: i915 device instance
+ * @i2c_pin: i2c pin for LVDS if present
+ *
+ * Return true if LVDS is present. If no child devices were parsed from VBT,
+ * assume LVDS is present.
+ */
+bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 *i2c_pin)
+{
+ int i;
+
+ if (!dev_priv->vbt.child_dev_num)
+ return true;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ union child_device_config *uchild = dev_priv->vbt.child_dev + i;
+ struct old_child_dev_config *child = &uchild->old;
+
+ /* If the device type is not LFP, continue.
+* We have to check both the new identifiers as well as the
+* old for compatibility with some BIOSes.
+*/
+ if (child->device_type != DEVICE_TYPE_INT_LFP &&
+ child->device_type != DEVICE_TYPE_LFP)
+ continue;
+
+ if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
+ *i2c_pin = child->i2c_pin;
+
+ /* However, we cannot trust the BIOS writers to populate
+* the VBT correctly. Since LVDS requires additional
+* information from AIM blocks, a non-zero addin offset is
+* a good indicator that the LVDS is actually present.
+*/
+ if (child->addin_offset)
+ return true;
+
+ /* But even then some BIOS writers perform some black magic
+* and instantiate the device without reference to any
+* additional data. Trust that if the VBT was written into
+* the OpRegion then they have validated the LVDS's existence.
+*/
+ if (dev_priv->opregion.vbt)
+ return true;
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 0da0240caf81..80f8684e5137 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -772,57 +772,6 @@ static const struct dmi_system_id intel_no_lvds[] = {
{ } /* terminating entry */
};
-/*
- * Enumerate the child dev array parsed from VBT to check whether
- * the LVDS is present.
- * If it is present, return 1.
- * If it is not present, return false.
- * If no child dev is parsed from VBT, it assumes that the LVDS is present.
- */
-static bool lvds_is_present_in_vbt(struct drm_device *dev,
- u8 *i2c_pin)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- int i;
-
- if (!dev_priv->vbt.child_dev_num)
- return true;
-
- for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
- union child_device_config *uchild = dev_priv->vbt.child_dev + i;
- struct old_child_dev_config *child = &uchild->old;
-
- /* If the device type is not LFP, continue.
-* We have to check both the new identifiers as well as the
-* old for compatibility with some BIOSes.
-*/
- if (child->device_type != DEVICE_TYPE_INT_LFP &&
- child->device_type != DEVICE_TYPE_LFP)
- continue;
-
- if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
- *i2c_pin = child->i2c_pin;
-
- /* However, we cannot trust the BIOS writers to populate
-* the VBT correctly. Since LVDS requires additional
-* information from AIM blocks, a non-zero addin offset is
-* a good indicator that the LVDS is actually present.
-
[Intel-gfx] [RFC 2/7] drm/i915: move VBT based TV presence check to intel_bios.c
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 38 ++
drivers/gpu/drm/i915/intel_tv.c | 43 +--
3 files changed, 40 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b2cf3b2c127f..a748b2c0d168 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3358,6 +3358,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
/* intel_bios.c */
int intel_bios_init(struct drm_device *dev);
bool intel_bios_is_valid_vbt(const void *buf, size_t size);
+bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index dc3a0fb1946c..6e3e647834af 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1348,3 +1348,41 @@ intel_bios_init(struct drm_device *dev)
return 0;
}
+
+/**
+ * intel_bios_is_tv_present - is integrated TV present in VBT
+ * @dev_priv: i915 device instance
+ *
+ * Return true if TV is present. If no child devices were parsed from VBT,
+ * assume TV is present.
+ */
+bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv)
+{
+ union child_device_config *p_child;
+ int i;
+
+ if (!dev_priv->vbt.child_dev_num)
+ return true;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ p_child = dev_priv->vbt.child_dev + i;
+ /*
+* If the device type is not TV, continue.
+*/
+ switch (p_child->old.device_type) {
+ case DEVICE_TYPE_INT_TV:
+ case DEVICE_TYPE_TV:
+ case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
+ break;
+ default:
+ continue;
+ }
+ /* Only when the addin_offset is non-zero, it is regarded
+* as present.
+*/
+ if (p_child->old.addin_offset)
+ return true;
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 948cbff6c62e..29e68859b9b7 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1529,47 +1529,6 @@ static const struct drm_encoder_funcs intel_tv_enc_funcs
= {
.destroy = intel_encoder_destroy,
};
-/*
- * Enumerate the child dev array parsed from VBT to check whether
- * the integrated TV is present.
- * If it is present, return 1.
- * If it is not present, return false.
- * If no child dev is parsed from VBT, it assumes that the TV is present.
- */
-static int tv_is_present_in_vbt(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- union child_device_config *p_child;
- int i, ret;
-
- if (!dev_priv->vbt.child_dev_num)
- return 1;
-
- ret = 0;
- for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
- p_child = dev_priv->vbt.child_dev + i;
- /*
-* If the device type is not TV, continue.
-*/
- switch (p_child->old.device_type) {
- case DEVICE_TYPE_INT_TV:
- case DEVICE_TYPE_TV:
- case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
- break;
- default:
- continue;
- }
- /* Only when the addin_offset is non-zero, it is regarded
-* as present.
-*/
- if (p_child->old.addin_offset) {
- ret = 1;
- break;
- }
- }
- return ret;
-}
-
void
intel_tv_init(struct drm_device *dev)
{
@@ -1585,7 +1544,7 @@ intel_tv_init(struct drm_device *dev)
if ((I915_READ(TV_CTL) & TV_FUSE_STATE_MASK) == TV_FUSE_STATE_DISABLED)
return;
- if (!tv_is_present_in_vbt(dev)) {
+ if (!intel_bios_is_tv_present(dev_priv)) {
DRM_DEBUG_KMS("Integrated TV is not present.\n");
return;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 5/7] drm/i915: move VBT based DSI presence check to intel_bios.c
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 33 -
drivers/gpu/drm/i915/intel_dsi.c | 23 ++-
3 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 824459c49ba6..5a7399507b84 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1480,7 +1480,6 @@ struct intel_vbt_data {
/* MIPI DSI */
struct {
- u16 port;
u16 panel_id;
struct mipi_config *config;
struct mipi_pps_data *pps;
@@ -3361,6 +3360,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
+bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index bde97d4b6651..f45ebf7bdc31 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1153,7 +1153,6 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
&&p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {
DRM_DEBUG_KMS("Found MIPI as LFP\n");
dev_priv->vbt.has_mipi = 1;
- dev_priv->vbt.dsi.port = p_child->common.dvo_port;
}
child_dev_ptr = dev_priv->vbt.child_dev + count;
@@ -1469,3 +1468,35 @@ bool intel_bios_is_port_edp(struct drm_i915_private
*dev_priv, enum port port)
return false;
}
+
+/**
+ * intel_bios_is_dsi_present - is DSI present in VBT
+ * @dev_priv: i915 device instance
+ * @port: port for DSI if present
+ *
+ * Return true if DSI is present, and return the port in %port.
+ */
+bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv,
+ enum port *port)
+{
+ union child_device_config *p_child;
+ int i;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ p_child = dev_priv->vbt.child_dev + i;
+
+ if (!(p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT))
+ continue;
+
+ switch (p_child->common.dvo_port) {
+ case DVO_PORT_MIPIA:
+ case DVO_PORT_MIPIB:
+ case DVO_PORT_MIPIC:
+ case DVO_PORT_MIPID:
+ *port = p_child->common.dvo_port - DVO_PORT_MIPIA;
+ return true;
+ }
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 44742fa2f616..696629557a99 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1117,9 +1117,15 @@ void intel_dsi_init(struct drm_device *dev)
DRM_DEBUG_KMS("\n");
/* There is no detection method for MIPI so rely on VBT */
- if (!dev_priv->vbt.has_mipi)
+ if (!intel_bios_is_dsi_present(dev_priv, &port))
return;
+ if (port != PORT_A && port != PORT_C) {
+ DRM_DEBUG_KMS("VBT has unsupported DSI port %c\n",
+ port_name(port));
+ return;
+ }
+
if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
dev_priv->mipi_mmio_base = VLV_MIPI_BASE;
} else {
@@ -1158,16 +1164,15 @@ void intel_dsi_init(struct drm_device *dev)
intel_connector->unregister = intel_connector_unregister;
/* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
- if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIA) {
- intel_encoder->crtc_mask = (1 << PIPE_A);
- intel_dsi->ports = (1 << PORT_A);
- } else if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIC) {
- intel_encoder->crtc_mask = (1 << PIPE_B);
- intel_dsi->ports = (1 << PORT_C);
- }
+ if (port == PORT_A)
+ intel_encoder->crtc_mask = 1 << PIPE_A;
+ else
+ intel_encoder->crtc_mask = 1 << PIPE_B;
if (dev_priv->vbt.dsi.config->dual_link)
- intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
+ intel_dsi->ports = (1 << PORT_A) | (1 << PORT_C);
+ else
+ intel_dsi->ports = 1 << port;
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi->ports) {
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 7/7] drm/i915/bios: hide away VBT specific things in a private bios header
We've been accumulating code across the driver that depends on the VBT
specific structures and defines. The VBT is an uncontrollable
beast. Encourage encapsulation of the VBT data by hiding the structures
and defines in a private header only to be included from intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c |2 +-
drivers/gpu/drm/i915/intel_bios.h | 1224
.../i915/{intel_bios.h => intel_bios_private.h}| 230 +---
3 files changed, 262 insertions(+), 1194 deletions(-)
rewrite drivers/gpu/drm/i915/intel_bios.h (76%)
rename drivers/gpu/drm/i915/{intel_bios.h => intel_bios_private.h} (81%)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index f45ebf7bdc31..f985b6e7fb43 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -29,7 +29,7 @@
#include
#include
#include "i915_drv.h"
-#include "intel_bios.h"
+#include "intel_bios_private.h"
#defineSLAVE_ADDR1 0x70
#defineSLAVE_ADDR2 0x72
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
dissimilarity index 76%
index 54eac1003a1e..929b74bf3593 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -1,968 +1,256 @@
-/*
- * Copyright © 2006 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.
- *
- * Authors:
- *Eric Anholt
- *
- */
-
-#ifndef _I830_BIOS_H_
-#define _I830_BIOS_H_
-
-struct vbt_header {
- u8 signature[20]; /**< Always starts with 'VBT$' */
- u16 version;/**< decimal */
- u16 header_size;/**< in bytes */
- u16 vbt_size; /**< in bytes */
- u8 vbt_checksum;
- u8 reserved0;
- u32 bdb_offset; /**< from beginning of VBT */
- u32 aim_offset[4]; /**< from beginning of VBT */
-} __packed;
-
-struct bdb_header {
- u8 signature[16]; /**< Always 'BIOS_DATA_BLOCK' */
- u16 version;/**< decimal */
- u16 header_size;/**< in bytes */
- u16 bdb_size; /**< in bytes */
-} __packed;
-
-/* strictly speaking, this is a "skip" block, but it has interesting info */
-struct vbios_data {
- u8 type; /* 0 == desktop, 1 == mobile */
- u8 relstage;
- u8 chipset;
- u8 lvds_present:1;
- u8 tv_present:1;
- u8 rsvd2:6; /* finish byte */
- u8 rsvd3[4];
- u8 signon[155];
- u8 copyright[61];
- u16 code_segment;
- u8 dos_boot_mode;
- u8 bandwidth_percent;
- u8 rsvd4; /* popup memory size */
- u8 resize_pci_bios;
- u8 rsvd5; /* is crt already on ddc2 */
-} __packed;
-
-/*
- * There are several types of BIOS data blocks (BDBs), each block has
- * an ID and size in the first 3 bytes (ID in first, size in next 2).
- * Known types are listed below.
- */
-#define BDB_GENERAL_FEATURES 1
-#define BDB_GENERAL_DEFINITIONS 2
-#define BDB_OLD_TOGGLE_LIST 3
-#define BDB_MODE_SUPPORT_LIST4
-#define BDB_GENERIC_MODE_TABLE 5
-#define BDB_EXT_MMIO_REGS6
-#define BDB_SWF_IO 7
-#define BDB_SWF_MMIO 8
-#define BDB_PSR 9
-#define BDB_MODE_REMOVAL_TABLE 10
-#define BDB_CHILD_DEVICE_TABLE 11
-#define BDB_DRIVER_FEATURES 12
-#define BDB_DRIVER_PERSISTENCE 13
-#define BDB_EXT_TABLE_PTRS 14
-#define BDB_DOT_CLOCK_OVERRIDE 15
-#define BDB_DISPLAY_SELECT 16
-/* 17 rsvd */
-#define BDB_DRIVER_ROTATION 18
-#define BDB_DISPLAY_REMOVE 19
-#define BDB_OEM_CUSTOM 20
-#define BDB_EFP_LIST21 /* workarounds for VGA hsync/vsync */
-#define BDB_SDVO_LVDS_OPTIONS 22
-#define BDB_SDVO_PANEL_DTDS 23
-#define BDB_SDVO_LVDS_PNP_IDS
[Intel-gfx] [RFC 1/7] drm/i915: move drmP.h include to i915_drv.h
The intel_bios.h header doesn't even need it, but other headers included
from i915_drv.h do. Let's untangle the mess a bit.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cfac7398568..b2cf3b2c127f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -33,6 +33,7 @@
#include
#include
+#include
#include "i915_reg.h"
#include "intel_bios.h"
#include "intel_ringbuffer.h"
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 689eb42f863c..54eac1003a1e 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -28,8 +28,6 @@
#ifndef _I830_BIOS_H_
#define _I830_BIOS_H_
-#include
-
struct vbt_header {
u8 signature[20]; /**< Always starts with 'VBT$' */
u16 version;/**< decimal */
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/7] drm/i915: move VBT based eDP port check to intel_bios.c
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 33 +
drivers/gpu/drm/i915/intel_dp.c | 21 +
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb5c9e4b0af0..824459c49ba6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3360,6 +3360,7 @@ int intel_bios_init(struct drm_device *dev);
bool intel_bios_is_valid_vbt(const void *buf, size_t size);
bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
+bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 264451167644..bde97d4b6651 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1436,3 +1436,36 @@ bool intel_bios_is_lvds_present(struct drm_i915_private
*dev_priv, u8 *i2c_pin)
return false;
}
+
+/**
+ * intel_bios_is_port_edp - is the device in given port eDP
+ * @dev_priv: i915 device instance
+ * @port: port to check
+ *
+ * Return true if the device in %port is eDP.
+ */
+bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port)
+{
+ union child_device_config *p_child;
+ static const short port_mapping[] = {
+ [PORT_B] = DVO_PORT_DPB,
+ [PORT_C] = DVO_PORT_DPC,
+ [PORT_D] = DVO_PORT_DPD,
+ [PORT_E] = DVO_PORT_DPE,
+ };
+ int i;
+
+ if (!dev_priv->vbt.child_dev_num)
+ return false;
+
+ for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+ p_child = dev_priv->vbt.child_dev + i;
+
+ if (p_child->common.dvo_port == port_mapping[port] &&
+ (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
+ (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
+ return true;
+ }
+
+ return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 31ba24114065..598fe6ff9412 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5070,14 +5070,6 @@ put_power:
bool intel_dp_is_edp(struct drm_device *dev, enum port port)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- union child_device_config *p_child;
- int i;
- static const short port_mapping[] = {
- [PORT_B] = DVO_PORT_DPB,
- [PORT_C] = DVO_PORT_DPC,
- [PORT_D] = DVO_PORT_DPD,
- [PORT_E] = DVO_PORT_DPE,
- };
/*
* eDP not supported on g4x. so bail out early just
@@ -5089,18 +5081,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port
port)
if (port == PORT_A)
return true;
- if (!dev_priv->vbt.child_dev_num)
- return false;
-
- for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
- p_child = dev_priv->vbt.child_dev + i;
-
- if (p_child->common.dvo_port == port_mapping[port] &&
- (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
- (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
- return true;
- }
- return false;
+ return intel_bios_is_port_edp(dev_priv, port);
}
void
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm] intel: Restore formatting of offsets in debug statements
Using lower_32_bits and upper_32_bits macros was accidentally dropped in:
commit 8b4d57e7b75cb0bd01d11ad7f597909034a316aa
Author: Michał Winiarski
Date: Wed Sep 9 16:07:10 2015 +0200
intel: Add support for softpin
Let's restore previous, more readable format.
Cc: Kristian Høgsberg Kristensen
Signed-off-by: Michał Winiarski
---
intel/intel_bufmgr_gem.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 265516f..dc28200 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -438,16 +438,18 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem
*bufmgr_gem)
drm_intel_bo_gem *target_gem =
(drm_intel_bo_gem *) target_bo;
- DBG("%2d: %d %s(%s)@0x%016llx -> "
- "%d (%s)@0x%016llx + 0x%08x\n",
+ DBG("%2d: %d %s(%s)@0x%08x %08x -> "
+ "%d (%s)@0x%08x %08x + 0x%08x\n",
i,
bo_gem->gem_handle,
bo_gem->is_softpin ? "*" : "",
bo_gem->name,
- (unsigned long long) bo_gem->relocs[j].offset,
+ upper_32_bits(bo_gem->relocs[j].offset),
+ lower_32_bits(bo_gem->relocs[j].offset),
target_gem->gem_handle,
target_gem->name,
- (unsigned long long) target_bo->offset64,
+ upper_32_bits(target_bo->offset64),
+ lower_32_bits(target_bo->offset64),
bo_gem->relocs[j].delta);
}
@@ -456,14 +458,15 @@ drm_intel_gem_dump_validation_list(drm_intel_bufmgr_gem
*bufmgr_gem)
drm_intel_bo_gem *target_gem =
(drm_intel_bo_gem *) target_bo;
DBG("%2d: %d %s(%s) -> "
- "%d *(%s)@0x%016lx\n",
+ "%d *(%s)@0x%08x %08x\n",
i,
bo_gem->gem_handle,
bo_gem->is_softpin ? "*" : "",
bo_gem->name,
target_gem->gem_handle,
target_gem->name,
- target_bo->offset64);
+ upper_32_bits(target_bo->offset64),
+ lower_32_bits(target_bo->offset64));
}
}
}
@@ -2242,10 +2245,12 @@ drm_intel_update_buffer_offsets2 (drm_intel_bufmgr_gem
*bufmgr_gem)
* has relocated our object... Indicating a programming
error
*/
assert(!bo_gem->is_softpin);
- DBG("BO %d (%s) migrated: 0x%016llx -> 0x%016llx\n",
+ DBG("BO %d (%s) migrated: 0x%08x %08x -> 0x%08x %08x\n",
bo_gem->gem_handle, bo_gem->name,
- (unsigned long long) bo->offset64,
- (unsigned long long)
bufmgr_gem->exec2_objects[i].offset);
+ upper_32_bits(bo->offset64),
+ lower_32_bits(bo->offset64),
+ upper_32_bits(bufmgr_gem->exec2_objects[i].offset),
+ lower_32_bits(bufmgr_gem->exec2_objects[i].offset));
bo->offset64 = bufmgr_gem->exec2_objects[i].offset;
bo->offset = bufmgr_gem->exec2_objects[i].offset;
}
--
2.5.0
___
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: fix the SDE irq dmesg warnings properly
On Mon, Dec 14, 2015 at 04:54:02PM +0200, Ville Syrjälä wrote: > On Sun, Dec 13, 2015 at 12:49:45PM +, Chris Wilson wrote: > > i7-5557U nuc currently connected to HDMI. > > Sigh. Do those correcpond to AUX attempts by any chance? IIRC that was where > Jani saw the problem on his BDW. > > Oh and maybe you can try Jani's debug patch > https://bugs.freedesktop.org/show_bug.cgi?id=92084#c20 > to show us what the hotplug register says during these fails? Sure, just only happens when plugged in, so likely be a while before I allow it back into the warmth. -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] PM / runtime: Add new helper for conditional usage count incrementation
On Mon, 14 Dec 2015, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
> that will increment the device's runtime PM usage counter and
> return 'true' if its status is RPM_ACTIVE and its usage counter
> is greater than 0 at the same time ('false' will be returned
> otherwise).
>
> This is useful for things that should only be done if the device
> is active (from the runtime PM perspective) and used by somebody
> (as indicated by the usage counter) already and they are not worth
> bothering otherwise.
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
> EXPORT_SYMBOL_GPL(__pm_runtime_resume);
>
> /**
> + * pm_runtime_get_if_in_use - Conditionally bump up the device's usage
> counter.
> + * @dev: Device to handle.
> + *
> + * Increment the device's runtime PM usage counter and return 'true' if its
> + * runtime PM status is RPM_ACTIVE and its usage counter is already different
> + * from zero at the same time. Otherwise, return 'false'.
The phrasing of this comment is slightly ambiguous (it's not clear
whether the "if" clause applies to both the increment and the return
or just the return). IMO it would be somewhat better to write:
If the runtime PM status is RPM_ACTIVE and the runtime PM usage
counter is nonzero, increment the counter and return 'true'.
Otherwise return false without changing the counter.
> --- linux-pm.orig/Documentation/power/runtime_pm.txt
> +++ linux-pm/Documentation/power/runtime_pm.txt
> @@ -371,6 +371,11 @@ drivers/base/power/runtime.c and include
> - increment the device's usage counter, run pm_runtime_resume(dev) and
>return its result
>
> + bool pm_runtime_get_if_in_use(struct device *dev);
> +- increment the device's usage counter and return 'true' if its runtime
> PM
> + status is 'active' and its usage counter is greater than 0 at the same
> + time; return 'false' otherwise
Same thing here.
Alan Stern
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Use insert_page for pwrite_fast
Hi Ankitprasad,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.4-rc5 next-20151215]
url:
https://github.com/0day-ci/linux/commits/ankitprasad-r-sharma-intel-com/drm-i915-Allow-use-of-get_dma_address-for-stolen-backed-objects/20151215-191838
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_gtt_pwrite_fast':
>> drivers/gpu/drm/i915/i915_gem.c:824:18: error: 'struct i915_address_space'
>> has no member named 'insert_page'
i915->gtt.base.insert_page(&i915->gtt.base,
^
>> drivers/gpu/drm/i915/i915_gem.c:825:10: error: implicit declaration of
>> function 'i915_gem_object_get_dma_address'
>> [-Werror=implicit-function-declaration]
i915_gem_object_get_dma_address(obj, offset >> PAGE_SHIFT),
^
cc1: some warnings being treated as errors
vim +824 drivers/gpu/drm/i915/i915_gem.c
818 u32 page_base = node.start;
819 unsigned page_offset = offset_in_page(offset);
820 unsigned page_length = PAGE_SIZE - page_offset;
821 page_length = remain < page_length ? remain :
page_length;
822 if (node.allocated) {
823 wmb();
> 824 i915->gtt.base.insert_page(&i915->gtt.base,
> 825
> i915_gem_object_get_dma_address(obj, offset >> PAGE_SHIFT),
826 node.start,
827 I915_CACHE_NONE,
828 0);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Introduce intel_uncore_unclaimed_mmio
Ville Syrjälä writes:
> On Tue, Dec 15, 2015 at 04:25:07PM +0200, Mika Kuoppala wrote:
>> Currently interrupt code is the only place checking
>> for the unclaimed register access prior to actual register
>> macros using the same functionality. Rename the function
>> and make it return bool so that the possible error message
>> context is clear in the caller side. The motivation is to allow
>> usage of unclaimed detection on arbitrary places.
>>
>> v2: rebase, s/access/mmio, s/dev/dev_priv
>>
>> Signed-off-by: Mika Kuoppala
>> Reviewed-by: Chris Wilson
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 2 +-
>> drivers/gpu/drm/i915/i915_irq.c | 3 ++-
>> drivers/gpu/drm/i915/intel_uncore.c | 5 ++---
>> 3 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 9124085..82c43b6 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2731,7 +2731,7 @@ extern void intel_uncore_sanitize(struct drm_device
>> *dev);
>> extern void intel_uncore_early_sanitize(struct drm_device *dev,
>> bool restore_forcewake);
>> extern void intel_uncore_init(struct drm_device *dev);
>> -extern void intel_uncore_check_errors(struct drm_device *dev);
>> +extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
>> extern void intel_uncore_fini(struct drm_device *dev);
>> extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool
>> restore);
>> const char *intel_uncore_forcewake_domain_to_str(const enum
>> forcewake_domain_id id);
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 86664d1..a20dc64 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -2167,7 +2167,8 @@ static irqreturn_t ironlake_irq_handler(int irq, void
>> *arg)
>>
>> /* We get interrupts on unclaimed registers, so check for this before we
>> * do any I915_{READ,WRITE}. */
>> -intel_uncore_check_errors(dev);
>> +if (intel_uncore_unclaimed_mmio(dev_priv))
>> +DRM_ERROR("Unclaimed register before interrupt\n");
>
> bdw+ too? Or do those work differently?
bdw too yes. But we throw the irq arming out in 4/7
completely.
-Mika
>
>>
>> /* disable master interrupt before clearing iir */
>> de_ier = I915_READ(DEIER);
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>> b/drivers/gpu/drm/i915/intel_uncore.c
>> index 95e7803..34b60cb 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -1606,8 +1606,7 @@ bool intel_has_gpu_reset(struct drm_device *dev)
>> return intel_get_gpu_reset(dev) != NULL;
>> }
>>
>> -void intel_uncore_check_errors(struct drm_device *dev)
>> +bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv)
>> {
>> -if (check_for_unclaimed_mmio(to_i915(dev)))
>> -DRM_ERROR("Unclaimed register before interrupt\n");
>> +return check_for_unclaimed_mmio(dev_priv);
>> }
>> --
>> 2.5.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
Re: [Intel-gfx] [PATCH 7/7] drm/i915/chv: Add non claimed mmio checking
Ville Syrjälä writes:
> On Tue, Dec 15, 2015 at 04:25:12PM +0200, Mika Kuoppala wrote:
>> Imre mentioned that chv might also have capability to
>> track unclaimed mmio accesses. And it has, so take it
>> into use.
>
> VLV too.
>
> My old patch:
> http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html
>
>>
>> Cc: Imre Deak
>> Cc: Ville Syrjälä
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 4
>> drivers/gpu/drm/i915/intel_uncore.c | 34 ++
>> 2 files changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 007ae83..24686ab 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -1711,6 +1711,10 @@ enum skl_disp_power_wells {
>> #define FPGA_DBG_MMIO(0x42300)
>> #define FPGA_DBG_RM_NOCLAIM (1<<31)
>>
>> +#define CLAIM_ER_MMIO(0x182028)
>> +#define CLAIM_ER_CLR (1<<31)
>
> Looks like you forgot the overflow bit.
>
>> +#define CLAIM_ER_CTR_MASK (0x)
>
> Needless parens.
>
>> +
>> #define DERRMR _MMIO(0x44050)
>> /* Note that HBLANK events are reserved on bdw+ */
>> #define DERRMR_PIPEA_SCANLINE (1<<0)
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>> b/drivers/gpu/drm/i915/intel_uncore.c
>> index 02bad32..ea8fcd4 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -335,13 +335,10 @@ static void intel_uncore_ellc_detect(struct drm_device
>> *dev)
>> }
>>
>> static bool
>> -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
>> +fpga_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
>> {
>> u32 dbg;
>>
>> -if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
>> -return false;
>> -
>> dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
>> if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
>> return false;
>> @@ -354,6 +351,35 @@ check_for_unclaimed_mmio(struct drm_i915_private
>> *dev_priv)
>> return true;
>> }
>>
>> +static bool
>> +chv_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
>> +{
>> +u32 cer;
>> +
>> +cer = __raw_i915_read32(dev_priv, CLAIM_ER);
>> +if (likely(!(cer & CLAIM_ER_CTR_MASK)))
>> +return false;
>> +
>> +__raw_i915_write32(dev_priv, CLAIM_ER, CLAIM_ER_CLR);
>> +
>> +/* We want to clear it asap, so post */
>> +__raw_i915_read32(dev_priv, CLAIM_ER);
>
> __raw_posting_read()
>
> But not sure why we'd want to do this read really. Seems like pointless
> overhead.
>
I saw the bit stick for a short time even after write. That lead
me to think that perhaps the detection logic in hw rearms
based on this bit. So by flushing it quickly we dont coalesce
the potential next write into the previous detect.
Also as this is now in the slow path (mmio_debug==0),
the extra overhead should not be an issue.
But pointless overhead is, pointless. My worries about coalescing
the detect bit might be theoretical at best, so I dont mind removing
the posting.
-Mika
> The other thing is that this only detect unclaimed RM cycles, so display
> registers only. Might be nice to only do the checks when accessing
> display registers so that we don't add overhead to the GT stuff.
> I think the same holds for HSW+ actually.
>
>> +
>> +return true;
>> +}
>> +
>> +static bool
>> +check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
>> +{
>> +if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
>> +return fpga_check_for_unclaimed_mmio(dev_priv);
>> +
>> +if (IS_CHERRYVIEW(dev_priv))
>> +return chv_check_for_unclaimed_mmio(dev_priv);
>> +
>> +return false;
>> +}
>> +
>> static void __intel_uncore_early_sanitize(struct drm_device *dev,
>>bool restore_forcewake)
>> {
>> --
>> 2.5.0
>
> --
> 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: Documentation style guide
On 14/12/15 15:39, Thierry Reding wrote: On Wed, Dec 09, 2015 at 05:08:02PM +0100, Daniel Vetter wrote: Every time I type or review docs this seems a bit different. Try to document the common style so we can try to unify at least new docs. v2: Spelling fixes from Pierre, Laurent and Jani. v3: More spelling fixes from Lukas. Cc: Pierre Moreau Cc: Jani Nikula Cc: Laurent Pinchart Cc: Lukas Wunner Acked-by: Laurent Pinchart Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1449564561-3896-1-git-send-email-daniel.vet...@ffwll.ch --- Documentation/DocBook/gpu.tmpl | 37 + 1 file changed, 37 insertions(+) diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 749b8e2f2113..c66d6412f573 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -124,6 +124,43 @@ [Insert diagram of typical DRM stack here] + +Style Guidelines + + For consistency this documentation uses American English. Abbreviations + are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so + on. To aid in reading, documentations make full use of the markup "..., the documentation makes full use of..." and perhaps "makes use of the full set of markup characters that kerneldoc provides". + characters kerneldoc provides: @parameter for function parameters, @member + for structure members, &structure to reference structures and + function() for functions. These all get automatically hyperlinked if + kerneldoc for the referenced objects exists. When referencing entries in + function vtables please use ->vfunc(). Note that kerneldoc does + not support referencing struct members directly, so please add a reference + to the vtable struct somewhere in the same paragraph or at least section. + + + Except in special situations (to separate locked from unlocked variants) + locking requirements for functions aren't documented in the kerneldoc. + Instead locking should be check at runtime using e.g. "should be checked" + WARN_ON(!mutex_is_locked(...));. Since it's much easier to + ignore documentation than runtime noise this provides more value. And on + top of that runtime checks do need to be updated when the locking rules + change, increasing the chances that they're correct. Within the A few commas to delimit subclauses would make this more readable: Since it's much easier to ignore documentation than runtime noise, this provides more value. And on top of that, runtime checks have to be updated when the locking rules change, thus increasing the chances that they're correct. + documentation the locking rules should be explained in the relevant + structures: Either in the comment for the lock explaining what it + protects, or data fields need a note about which lock protects them, or + both. I think you're supposed to have the "or" only in the final subsentence: "either ... protects, data fields need ..., or both." Within the documentation, the locking rules should be explained in comments on the relevant structures; these comments may be with the lock, explaining what it protects, or with the data, noting which lock protects it, or both -- in which case they should agree! + + + Functions which have a non-void return value should have a + section called "Returns" explaining the expected return values in + different cases and their meanings. Currently there's no consensus whether + that section name should be all upper-case or not, and whether it should + end in a colon or not. Go with the file-local style. Other common section I thought the colon was necessary for kerneldoc to turn it into a section? Overall, long overdue, so thanks for writing it up: Acked-by: Thierry Reding ___ 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 7/7] drm/i915/chv: Add non claimed mmio checking
On Tue, Dec 15, 2015 at 04:44:25PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 04:25:12PM +0200, Mika Kuoppala wrote:
> > Imre mentioned that chv might also have capability to
> > track unclaimed mmio accesses. And it has, so take it
> > into use.
>
> VLV too.
>
> My old patch:
> http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html
>
> >
> > Cc: Imre Deak
> > Cc: Ville Syrjälä
> > Signed-off-by: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > drivers/gpu/drm/i915/intel_uncore.c | 34 ++
> > 2 files changed, 34 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 007ae83..24686ab 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1711,6 +1711,10 @@ enum skl_disp_power_wells {
> > #define FPGA_DBG _MMIO(0x42300)
> > #define FPGA_DBG_RM_NOCLAIM (1<<31)
> >
> > +#define CLAIM_ER _MMIO(0x182028)
> > +#define CLAIM_ER_CLR (1<<31)
>
> Looks like you forgot the overflow bit.
>
> > +#define CLAIM_ER_CTR_MASK(0x)
>
> Needless parens.
>
> > +
> > #define DERRMR _MMIO(0x44050)
> > /* Note that HBLANK events are reserved on bdw+ */
> > #define DERRMR_PIPEA_SCANLINE(1<<0)
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 02bad32..ea8fcd4 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -335,13 +335,10 @@ static void intel_uncore_ellc_detect(struct
> > drm_device *dev)
> > }
> >
> > static bool
> > -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> > +fpga_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> > {
> > u32 dbg;
> >
> > - if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> > - return false;
> > -
> > dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
> > if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
> > return false;
> > @@ -354,6 +351,35 @@ check_for_unclaimed_mmio(struct drm_i915_private
> > *dev_priv)
> > return true;
> > }
> >
> > +static bool
> > +chv_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> > +{
> > + u32 cer;
> > +
> > + cer = __raw_i915_read32(dev_priv, CLAIM_ER);
> > + if (likely(!(cer & CLAIM_ER_CTR_MASK)))
> > + return false;
> > +
> > + __raw_i915_write32(dev_priv, CLAIM_ER, CLAIM_ER_CLR);
> > +
> > + /* We want to clear it asap, so post */
> > + __raw_i915_read32(dev_priv, CLAIM_ER);
>
> __raw_posting_read()
>
> But not sure why we'd want to do this read really. Seems like pointless
> overhead.
>
> The other thing is that this only detect unclaimed RM cycles, so display
> registers only. Might be nice to only do the checks when accessing
> display registers so that we don't add overhead to the GT stuff.
> I think the same holds for HSW+ actually.
Oh, after reading some more it doesn't look like you're adding the
checks to the register accesses for chv. So no overhead there.
I think one natural place for some explicit unclaimer reg checks would
be the disp2d power well enable/disable, since a disabled power well
might be the cause for the error. IIRC another could be simply a bogus
register offset.
>
> > +
> > + return true;
> > +}
> > +
> > +static bool
> > +check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> > +{
> > + if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> > + return fpga_check_for_unclaimed_mmio(dev_priv);
> > +
> > + if (IS_CHERRYVIEW(dev_priv))
> > + return chv_check_for_unclaimed_mmio(dev_priv);
> > +
> > + return false;
> > +}
> > +
> > static void __intel_uncore_early_sanitize(struct drm_device *dev,
> > bool restore_forcewake)
> > {
> > --
> > 2.5.0
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> 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
Re: [Intel-gfx] [PATCH 9/9] drm/i915: Fail the execbuff using stolen objects as batchbuffers
On Tue, Dec 15, 2015 at 02:41:47PM +, Dave Gordon wrote: > On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote: > >From: Ankitprasad Sharma > > > >Using stolen backed objects as a batchbuffer may result into a kernel > >panic during relocation. Added a check to prevent the panic and fail > >the execbuffer call. It is not recommended to use stolen object as > >a batchbuffer. > > > >Signed-off-by: Ankitprasad Sharma > >--- > > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >index 48ec484..d342f10 100644 > >--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >@@ -462,7 +462,9 @@ i915_gem_execbuffer_relocate_entry(struct > >drm_i915_gem_object *obj, > > if (obj->active && pagefault_disabled()) > > return -EFAULT; > > > >-if (use_cpu_reloc(obj)) > >+if (obj->stolen) > >+ret = -EINVAL; > > I'd rather reject ALL "weird" gem objects at the first opportunity, > so that none of the execbuffer code has to worry about stolen, phys, > dmabuf, etc ... > > if (obj->ops != &i915_gem_object_ops)) > ret = -EINVAL; /* No exotica please */ No. All GEM objects are supposed to be first-class so that they are interchangeable through all aspects of the API (that becomes even more important with dma-buf interoperation). We have had to relax that for a couple of special categories (basically CPU mmapping) for certain clases that are not struct file backed. Though in principle, a gemfs would work just fine. The only restrictions we should ideally impose are those determined by hardware. -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] [QA 2015-12-04 ww50] Testing report for `drm-intel-testing`
Hello, We launched Intel GPU Tools on 7 platforms: Skylake-Y, Braswell-M, Broadwell-U, Baytrail-M, Haswell-U, Ivy Bridge and Sandy Bridge to validate tag drm-intel-testing-2015-12-04 (kernel 4.4-rc3). Unusual numbers of tests are fail on BSW and SKL, they must be executed again (managed as not run at the moment). On the other platforms, we have 33 progress and 15 regressions when comparing the results from kernel tag drm-intel-testing-2015-11-20. We reproduced a lot of known bugs. Results: `` | Avail | Black | Skip | Not |Exec | Exec | Pass of | Pass of | able | listed| | Run | | % | Total % | executed % -- SKL-Y Basic | 131 | 0 | 2 | 24| 105 | 80.15%| 80.15% | 100% Others | 5566 | 3780 | 194 | 620 | 1093 | 19.64%| 12.22% | 62.21% -- BSW-M Basic | 131 | 0 | 4 | 0 | 127 | 96.95%| 90.84% | 93.70% Others | 5566 | 3780 | 435 | 250 | 786 | 14.12%| 12.85% | 90.97% -- BDW-U Basic | 131 | 0 | 4 | 0 | 127 | 96.95%| 92.37% | 92.28% Others | 5566 | 3780 | 595 | 0 | 1191 | 21.40%| 19.83% | 92.70% -- HSW-U Basic | 131 | 0 | 11| 0 | 120 | 91.60%| 87.02% | 95.00% Others | 5566 | 3780 | 690 | 0 | 1096 | 19.69%| 17.79% | 90.33% -- IVB Basic | 131 | 0 | 6 | 0 | 125 | 95.42%| 95.42% | 100.00% Others | 5566 | 3780 | 922 | 0 | 864 | 15.52%| 14.66% | 94.44% -- SNB Basic | 131 | 0 | 12| 0 | 119 | 90.83%| 90.84% | 100.00% Others | 5566 | 3780 | 916 | 0 | 870 | 15.63%| 14.86% | 95.06% -- BYT-M Basic | 131 | 122 | 7 | 1 | 123 | 93.89%| 93.13% | 99.19% Others | 5566 | 3780 | 736 | 0 | 1182 | 21.23%| 19.67% | 92.64% -- Tag drm-intel-testing-2015-11-20 results: `` | Avail | Black | Skip | Not |Exec | Exec | Pass of | Pass of | able | listed| | Run | | % | Total % | executed % -- SKL-Y Basic | 131 | 0 | 2 | 0 | 129 | 98.47%| 93.89% | 95.35% Others | 5542 | 3780 | 271 | 0 | 1491 | 26.90%| 24.11% | 89.60% -- BSW-M Basic | 131 | 0 | 4 | 0 | 127 | 96.95%| 90.84% | 93.70% Others | 5542 | 3780 | 380 | 340 | 1042 | 18.80%| 12.94% | 68.81% -- BDW-U Basic | 131 | 0 | 4 | 0 | 127 | 96.95%| 92.37% | 95.28% Others | 5542 | 3780 | 574 | 0 | 1188 | 21.44%| 19.99% | 93.27% -- HSW-U Basic | 131 | 0 | 11| 0 | 120 | 91.60%| 87.02% | 95.00% Others | 5542 | 3780 | 677 | 0 | 1085 | 19.58%| 17.72% | 90.51% -- IVB Basic | 131 | 0 | 6 | 0 | 125 | 95.42%| 94.66% | 99.20% Others | 5542 | 3780 | 902 | 0 | 860 | 15.52%| 14.71% | 94.77% -- SNB Basic | 131 | 0 | 13| 0 | 118 | 90.08%| 90.08% | 100.00% Others | 5542 | 3780 | 895 | 0 | 867 | 15.64%| 14.85% | 94.93% -- BYT-M Basic | 131 | 0 | 7 | 0
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Consolidate unclaimed mmio detection
Chris Wilson writes: > On Tue, Dec 15, 2015 at 04:25:06PM +0200, Mika Kuoppala wrote: >> Access the unclaimed reg detection register through >> one helper which also does cleanup. Note that we now access >> the register only if the platform has the actual non claimed >> access bit. This prevents reading the register with gens that >> doesn't have the register or the unclaimed bit, >> when debug_mmio > 0. >> >> Note that we post after clearing the bit. This makes sure >> that the next unclaimed write access would get detected >> also if it happened right after clearing, and not fold >> into the previous detection. > > I didn't like 6 (adding checks to rpm get/put), and I didn't see the > removal of the check from the interrupt? Or adding it to the modesetting > code? > > Did I just miss those? > They should be included in 4/7. -Mika > The other patches (1-5?) (aside from adding chv as I haven't validated the > registers myself) are > Reviewed-by: Chris Wilson > -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 4/7] drm/i915: Do one shot unclaimed mmio detection less frequently
On Tue, Dec 15, 2015 at 04:25:09PM +0200, Mika Kuoppala wrote:
> We have done unclaimed register access check in normal
> (mmio_debug=0) mode once per write. This adds probability
> of finding the exact sequence where we did the bad access, but
> also adds burden to each write.
>
> As we have mmio_debug available for more fine grained analysis,
> give up accuracy of detecting correct spot at the first occurrence
> by doing the one shot detection and arming of mmio_debug in hangcheck
> and in modeset. This removes the write path performance burden.
>
> Note that in hangcheck when we arm the fine grained debug
> facilities, there is no context even if the unclaimed access
> is already set and thus notifying in this point has no added value.
> In contrary, in display path, we add a debug message if the bit
> was set on arming.
>
> Cc: Chris Wilson
> Cc: Paulo Zanoni
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/i915_irq.c | 10 -
> drivers/gpu/drm/i915/intel_display.c | 3 +++
> drivers/gpu/drm/i915/intel_uncore.c | 40
> +++-
> 4 files changed, 32 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 82c43b6..625aae9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -723,6 +723,8 @@ struct intel_uncore {
> i915_reg_t reg_post;
> u32 val_reset;
> } fw_domain[FW_DOMAIN_ID_COUNT];
> +
> + int unclaimed_mmio_check;
> };
>
> /* Iterate over initialised fw domains */
> @@ -2732,6 +2734,7 @@ extern void intel_uncore_early_sanitize(struct
> drm_device *dev,
> bool restore_forcewake);
> extern void intel_uncore_init(struct drm_device *dev);
> extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
> +extern bool intel_uncore_arm_unclaimed_mmio_detection(struct
> drm_i915_private *dev_priv);
> extern void intel_uncore_fini(struct drm_device *dev);
> extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool
> restore);
> const char *intel_uncore_forcewake_domain_to_str(const enum
> forcewake_domain_id id);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a20dc64..725a340 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2165,11 +2165,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> *arg)
> if (!intel_irqs_enabled(dev_priv))
> return IRQ_NONE;
>
> - /* We get interrupts on unclaimed registers, so check for this before we
> - * do any I915_{READ,WRITE}. */
> - if (intel_uncore_unclaimed_mmio(dev_priv))
> - DRM_ERROR("Unclaimed register before interrupt\n");
> -
> /* disable master interrupt before clearing iir */
> de_ier = I915_READ(DEIER);
> I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> @@ -2990,6 +2985,11 @@ static void i915_hangcheck_elapsed(struct work_struct
> *work)
> if (!i915.enable_hangcheck)
> return;
>
> + /* Periodic arming of mmio_debug if hw detects mmio
> + * access to out of range or to an unpowered block
> + */
> + intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
It's a bit weird to have this here since it'll only detect display
register accesses AFAIK. But I guess it's cheaper that adding a
dedicated timer or anything for it.
> +
> for_each_ring(ring, dev_priv, i) {
> u64 acthd;
> u32 seqno;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 471f120..3a9229b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13545,6 +13545,9 @@ static int intel_atomic_commit(struct drm_device *dev,
>
> drm_atomic_state_free(state);
>
> + if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> + DRM_DEBUG_DRIVER("%s return with unclaimed access\n", __func__);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 34b60cb..911f189 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -629,22 +629,6 @@ hsw_unclaimed_reg_debug(struct drm_i915_private
> *dev_priv,
> }
> }
>
> -static void
> -hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
> -{
> - static bool mmio_debug_once = true;
> -
> - if (i915.mmio_debug || !mmio_debug_once)
> - return;
> -
> - if (check_for_unclaimed_mmio(dev_priv)) {
> - DRM_DEBUG("Unclaimed register detected, "
> - "enabling oneshot unclaimed register reporting. "
> - "Please use i915.mmio_debug=N for more
> information.\n");
> - i915.mmio_debug =
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Do one shot unclaimed mmio detection less frequently
On Tue, Dec 15, 2015 at 04:25:09PM +0200, Mika Kuoppala wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 471f120..3a9229b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13545,6 +13545,9 @@ static int intel_atomic_commit(struct drm_device *dev,
>
> drm_atomic_state_free(state);
>
> + if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> + DRM_DEBUG_DRIVER("%s return with unclaimed access\n", __func__);
DRM_DEBUG() already includes the "%s" _func__.
This would seem to duplicate the DRM_DEBUG from
intel_uncore_arm_unclaimed_mmio_detection() which as you point out
should have been DRM_DEBUG_DRIVER() in the first place.
Minor quible aside (and because this turned up late!),
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Introduce intel_uncore_unclaimed_mmio
On Tue, Dec 15, 2015 at 04:25:07PM +0200, Mika Kuoppala wrote:
> Currently interrupt code is the only place checking
> for the unclaimed register access prior to actual register
> macros using the same functionality. Rename the function
> and make it return bool so that the possible error message
> context is clear in the caller side. The motivation is to allow
> usage of unclaimed detection on arbitrary places.
>
> v2: rebase, s/access/mmio, s/dev/dev_priv
>
> Signed-off-by: Mika Kuoppala
> Reviewed-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_irq.c | 3 ++-
> drivers/gpu/drm/i915/intel_uncore.c | 5 ++---
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9124085..82c43b6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2731,7 +2731,7 @@ extern void intel_uncore_sanitize(struct drm_device
> *dev);
> extern void intel_uncore_early_sanitize(struct drm_device *dev,
> bool restore_forcewake);
> extern void intel_uncore_init(struct drm_device *dev);
> -extern void intel_uncore_check_errors(struct drm_device *dev);
> +extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
> extern void intel_uncore_fini(struct drm_device *dev);
> extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool
> restore);
> const char *intel_uncore_forcewake_domain_to_str(const enum
> forcewake_domain_id id);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 86664d1..a20dc64 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2167,7 +2167,8 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> *arg)
>
> /* We get interrupts on unclaimed registers, so check for this before we
>* do any I915_{READ,WRITE}. */
> - intel_uncore_check_errors(dev);
> + if (intel_uncore_unclaimed_mmio(dev_priv))
> + DRM_ERROR("Unclaimed register before interrupt\n");
bdw+ too? Or do those work differently?
>
> /* disable master interrupt before clearing iir */
> de_ier = I915_READ(DEIER);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 95e7803..34b60cb 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1606,8 +1606,7 @@ bool intel_has_gpu_reset(struct drm_device *dev)
> return intel_get_gpu_reset(dev) != NULL;
> }
>
> -void intel_uncore_check_errors(struct drm_device *dev)
> +bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv)
> {
> - if (check_for_unclaimed_mmio(to_i915(dev)))
> - DRM_ERROR("Unclaimed register before interrupt\n");
> + return check_for_unclaimed_mmio(dev_priv);
> }
> --
> 2.5.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
Re: [Intel-gfx] [PATCH 7/7] drm/i915/chv: Add non claimed mmio checking
On Tue, Dec 15, 2015 at 04:25:12PM +0200, Mika Kuoppala wrote:
> Imre mentioned that chv might also have capability to
> track unclaimed mmio accesses. And it has, so take it
> into use.
VLV too.
My old patch:
http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html
>
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_uncore.c | 34 ++
> 2 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 007ae83..24686ab 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1711,6 +1711,10 @@ enum skl_disp_power_wells {
> #define FPGA_DBG _MMIO(0x42300)
> #define FPGA_DBG_RM_NOCLAIM(1<<31)
>
> +#define CLAIM_ER _MMIO(0x182028)
> +#define CLAIM_ER_CLR (1<<31)
Looks like you forgot the overflow bit.
> +#define CLAIM_ER_CTR_MASK (0x)
Needless parens.
> +
> #define DERRMR _MMIO(0x44050)
> /* Note that HBLANK events are reserved on bdw+ */
> #define DERRMR_PIPEA_SCANLINE (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 02bad32..ea8fcd4 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -335,13 +335,10 @@ static void intel_uncore_ellc_detect(struct drm_device
> *dev)
> }
>
> static bool
> -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +fpga_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> {
> u32 dbg;
>
> - if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> - return false;
> -
> dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
> if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
> return false;
> @@ -354,6 +351,35 @@ check_for_unclaimed_mmio(struct drm_i915_private
> *dev_priv)
> return true;
> }
>
> +static bool
> +chv_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +{
> + u32 cer;
> +
> + cer = __raw_i915_read32(dev_priv, CLAIM_ER);
> + if (likely(!(cer & CLAIM_ER_CTR_MASK)))
> + return false;
> +
> + __raw_i915_write32(dev_priv, CLAIM_ER, CLAIM_ER_CLR);
> +
> + /* We want to clear it asap, so post */
> + __raw_i915_read32(dev_priv, CLAIM_ER);
__raw_posting_read()
But not sure why we'd want to do this read really. Seems like pointless
overhead.
The other thing is that this only detect unclaimed RM cycles, so display
registers only. Might be nice to only do the checks when accessing
display registers so that we don't add overhead to the GT stuff.
I think the same holds for HSW+ actually.
> +
> + return true;
> +}
> +
> +static bool
> +check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +{
> + if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> + return fpga_check_for_unclaimed_mmio(dev_priv);
> +
> + if (IS_CHERRYVIEW(dev_priv))
> + return chv_check_for_unclaimed_mmio(dev_priv);
> +
> + return false;
> +}
> +
> static void __intel_uncore_early_sanitize(struct drm_device *dev,
> bool restore_forcewake)
> {
> --
> 2.5.0
--
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 9/9] drm/i915: Fail the execbuff using stolen objects as batchbuffers
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Using stolen backed objects as a batchbuffer may result into a kernel panic during relocation. Added a check to prevent the panic and fail the execbuffer call. It is not recommended to use stolen object as a batchbuffer. Signed-off-by: Ankitprasad Sharma --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 48ec484..d342f10 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -462,7 +462,9 @@ i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj, if (obj->active && pagefault_disabled()) return -EFAULT; - if (use_cpu_reloc(obj)) + if (obj->stolen) + ret = -EINVAL; I'd rather reject ALL "weird" gem objects at the first opportunity, so that none of the execbuffer code has to worry about stolen, phys, dmabuf, etc ... if (obj->ops != &i915_gem_object_ops)) ret = -EINVAL; /* No exotica please */ .Dave. + else if (use_cpu_reloc(obj)) ret = relocate_entry_cpu(obj, reloc, target_offset); else if (obj->map_and_fenceable) ret = relocate_entry_gtt(obj, reloc, target_offset); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Consolidate unclaimed mmio detection
On Tue, Dec 15, 2015 at 04:25:06PM +0200, Mika Kuoppala wrote: > Access the unclaimed reg detection register through > one helper which also does cleanup. Note that we now access > the register only if the platform has the actual non claimed > access bit. This prevents reading the register with gens that > doesn't have the register or the unclaimed bit, > when debug_mmio > 0. > > Note that we post after clearing the bit. This makes sure > that the next unclaimed write access would get detected > also if it happened right after clearing, and not fold > into the previous detection. I didn't like 6 (adding checks to rpm get/put), and I didn't see the removal of the check from the interrupt? Or adding it to the modesetting code? Did I just miss those? The other patches (1-5?) (aside from adding chv as I haven't validated the registers myself) are Reviewed-by: Chris Wilson -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 6/7] drm/i915: Add unclaimed mmio check to runtime pm get/put
On Tue, Dec 15, 2015 at 04:25:11PM +0200, Mika Kuoppala wrote: > This is a natural boundary to peek if our power domain > management is accurate. No, I have plans for this to be very frequent. In that bold plan, the suspend/resume boundary is more sensible. -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] PM / runtime: Add new helper for conditional usage count incrementation
On 14 December 2015 at 23:22, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
As we already have pm_runtime_set_active() and pm_runtime_active(),
changing the new function name to "pm_runtime_get_if_active" may be
better!?
> that will increment the device's runtime PM usage counter and
> return 'true' if its status is RPM_ACTIVE and its usage counter
> is greater than 0 at the same time ('false' will be returned
> otherwise).
>
> This is useful for things that should only be done if the device
> is active (from the runtime PM perspective) and used by somebody
> (as indicated by the usage counter) already and they are not worth
> bothering otherwise.
>
> Requested-by: Imre Deak
> Acked-by: Imre Deak
> Signed-off-by: Rafael J. Wysocki
> ---
> Documentation/power/runtime_pm.txt |5 +
> drivers/base/power/runtime.c | 21 +
> include/linux/pm_runtime.h |5 +
> 3 files changed, 31 insertions(+)
>
> Index: linux-pm/drivers/base/power/runtime.c
> ===
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -966,6 +966,27 @@ int __pm_runtime_resume(struct device *d
> EXPORT_SYMBOL_GPL(__pm_runtime_resume);
>
> /**
> + * pm_runtime_get_if_in_use - Conditionally bump up the device's usage
> counter.
> + * @dev: Device to handle.
> + *
> + * Increment the device's runtime PM usage counter and return 'true' if its
> + * runtime PM status is RPM_ACTIVE and its usage counter is already different
> + * from zero at the same time. Otherwise, return 'false'.
> + */
> +bool pm_runtime_get_if_in_use(struct device *dev)
> +{
> + unsigned long flags;
> + bool retval;
> +
> + spin_lock_irqsave(&dev->power.lock, flags);
> + retval = dev->power.runtime_status == RPM_ACTIVE
> + && atomic_inc_not_zero(&dev->power.usage_count);
Don't we also need to check that runtime PM is enabled (&&
!dev->power.disable_depth), or the user of this function don't care
about that?
> + spin_unlock_irqrestore(&dev->power.lock, flags);
> + return retval;
> +}
> +EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
> +
[...]
Kind regards
Uffe
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: Detect and clear unclaimed access on resume
If something, the usual suspect being bios, access hw
behind our back, don't let it slide into situation where
normal register access will detect this and spit out
a warn on into dmesg. On some bdw bioses this happens
during igt/bat run always and as there is not much we can
do about it, its better just to detect and flush this
explicitly on resume and only print a debug message.
v2: use DRM_DEBUG_DRIVER (Chris)
v3: s/access/mmio, s/prior/prior to, s/dev/dev_priv
Testcase: igt/pm_rpm/basic-rte
Cc: Chris Wilson
Cc: Paulo Zanoni
Cc: Daniel Vetter
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8ddfcce..3f2a1d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1478,6 +1478,9 @@ static int intel_runtime_suspend(struct device *device)
}
intel_uncore_forcewake_reset(dev, false);
+ if (intel_uncore_unclaimed_mmio(dev_priv))
+ DRM_ERROR("Unclaimed access detected prior to suspending\n");
+
dev_priv->pm.suspended = true;
/*
@@ -1523,6 +1526,8 @@ static int intel_runtime_resume(struct device *device)
intel_opregion_notify_adapter(dev, PCI_D0);
dev_priv->pm.suspended = false;
+ if (intel_uncore_unclaimed_mmio(dev_priv))
+ DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
intel_guc_resume(dev);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Add unclaimed mmio check to runtime pm get/put
This is a natural boundary to peek if our power domain management is accurate. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 2c2151f..5eea177 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -2230,6 +2230,7 @@ void intel_runtime_pm_get(struct drm_i915_private *dev_priv) return; pm_runtime_get_sync(device); + WARN_ON(intel_uncore_arm_unclaimed_mmio_detection(dev_priv)); WARN(dev_priv->pm.suspended, "Device still suspended.\n"); } @@ -2275,6 +2276,8 @@ void intel_runtime_pm_put(struct drm_i915_private *dev_priv) struct drm_device *dev = dev_priv->dev; struct device *device = &dev->pdev->dev; + WARN_ON(intel_uncore_arm_unclaimed_mmio_detection(dev_priv)); + if (!HAS_RUNTIME_PM(dev)) return; -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: Introduce intel_uncore_unclaimed_mmio
Currently interrupt code is the only place checking
for the unclaimed register access prior to actual register
macros using the same functionality. Rename the function
and make it return bool so that the possible error message
context is clear in the caller side. The motivation is to allow
usage of unclaimed detection on arbitrary places.
v2: rebase, s/access/mmio, s/dev/dev_priv
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
drivers/gpu/drm/i915/intel_uncore.c | 5 ++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9124085..82c43b6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2731,7 +2731,7 @@ extern void intel_uncore_sanitize(struct drm_device *dev);
extern void intel_uncore_early_sanitize(struct drm_device *dev,
bool restore_forcewake);
extern void intel_uncore_init(struct drm_device *dev);
-extern void intel_uncore_check_errors(struct drm_device *dev);
+extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
extern void intel_uncore_fini(struct drm_device *dev);
extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore);
const char *intel_uncore_forcewake_domain_to_str(const enum
forcewake_domain_id id);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 86664d1..a20dc64 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2167,7 +2167,8 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
/* We get interrupts on unclaimed registers, so check for this before we
* do any I915_{READ,WRITE}. */
- intel_uncore_check_errors(dev);
+ if (intel_uncore_unclaimed_mmio(dev_priv))
+ DRM_ERROR("Unclaimed register before interrupt\n");
/* disable master interrupt before clearing iir */
de_ier = I915_READ(DEIER);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 95e7803..34b60cb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1606,8 +1606,7 @@ bool intel_has_gpu_reset(struct drm_device *dev)
return intel_get_gpu_reset(dev) != NULL;
}
-void intel_uncore_check_errors(struct drm_device *dev)
+bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv)
{
- if (check_for_unclaimed_mmio(to_i915(dev)))
- DRM_ERROR("Unclaimed register before interrupt\n");
+ return check_for_unclaimed_mmio(dev_priv);
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915: Streamline unclaimed reg debug trace
Remove char* assignments and add branching hint and
also constify the parameters.
This results in a 35 bytes shorter fast path, so author
boldly assumes it helps without doing in-depth assembly
analysis.
v2: use WARN's branching (Chris), commit name (Joonas)
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 911f189..02bad32 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -614,19 +614,19 @@ ilk_dummy_write(struct drm_i915_private *dev_priv)
static void
hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv,
- i915_reg_t reg, bool read, bool before)
+ const i915_reg_t reg,
+ const bool read,
+ const bool before)
{
- const char *op = read ? "reading" : "writing to";
- const char *when = before ? "before" : "after";
-
- if (!i915.mmio_debug)
+ if (likely(!i915.mmio_debug))
return;
- if (check_for_unclaimed_mmio(dev_priv)) {
- WARN(1, "Unclaimed register detected %s %s register 0x%x\n",
-when, op, i915_mmio_reg_offset(reg));
+ if (WARN(check_for_unclaimed_mmio(dev_priv),
+"Unclaimed register detected %s %s register 0x%x\n",
+before ? "before" : "after",
+read ? "reading" : "writing to",
+i915_mmio_reg_offset(reg)))
i915.mmio_debug--; /* Only report the first N failures */
- }
}
#define GEN2_READ_HEADER(x) \
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/chv: Add non claimed mmio checking
Imre mentioned that chv might also have capability to
track unclaimed mmio accesses. And it has, so take it
into use.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_uncore.c | 34 ++
2 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 007ae83..24686ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1711,6 +1711,10 @@ enum skl_disp_power_wells {
#define FPGA_DBG _MMIO(0x42300)
#define FPGA_DBG_RM_NOCLAIM (1<<31)
+#define CLAIM_ER _MMIO(0x182028)
+#define CLAIM_ER_CLR (1<<31)
+#define CLAIM_ER_CTR_MASK(0x)
+
#define DERRMR _MMIO(0x44050)
/* Note that HBLANK events are reserved on bdw+ */
#define DERRMR_PIPEA_SCANLINE(1<<0)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 02bad32..ea8fcd4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -335,13 +335,10 @@ static void intel_uncore_ellc_detect(struct drm_device
*dev)
}
static bool
-check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+fpga_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
{
u32 dbg;
- if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
- return false;
-
dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
return false;
@@ -354,6 +351,35 @@ check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
return true;
}
+static bool
+chv_check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+{
+ u32 cer;
+
+ cer = __raw_i915_read32(dev_priv, CLAIM_ER);
+ if (likely(!(cer & CLAIM_ER_CTR_MASK)))
+ return false;
+
+ __raw_i915_write32(dev_priv, CLAIM_ER, CLAIM_ER_CLR);
+
+ /* We want to clear it asap, so post */
+ __raw_i915_read32(dev_priv, CLAIM_ER);
+
+ return true;
+}
+
+static bool
+check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+{
+ if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
+ return fpga_check_for_unclaimed_mmio(dev_priv);
+
+ if (IS_CHERRYVIEW(dev_priv))
+ return chv_check_for_unclaimed_mmio(dev_priv);
+
+ return false;
+}
+
static void __intel_uncore_early_sanitize(struct drm_device *dev,
bool restore_forcewake)
{
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Consolidate unclaimed mmio detection
Access the unclaimed reg detection register through
one helper which also does cleanup. Note that we now access
the register only if the platform has the actual non claimed
access bit. This prevents reading the register with gens that
doesn't have the register or the unclaimed bit,
when debug_mmio > 0.
Note that we post after clearing the bit. This makes sure
that the next unclaimed write access would get detected
also if it happened right after clearing, and not fold
into the previous detection.
v2: s/unclaimed_reg_access/check_for_unclaimed_mmio (Chris)
debug log on unclaimed detection on uncore init (Joonas)
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Paulo Zanoni
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c | 38 +
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index fcf04fe..95e7803 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -334,13 +334,34 @@ static void intel_uncore_ellc_detect(struct drm_device
*dev)
}
}
+static bool
+check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
+{
+ u32 dbg;
+
+ if (!HAS_FPGA_DBG_UNCLAIMED(dev_priv))
+ return false;
+
+ dbg = __raw_i915_read32(dev_priv, FPGA_DBG);
+ if (likely(!(dbg & FPGA_DBG_RM_NOCLAIM)))
+ return false;
+
+ __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+
+ /* We want to clear it asap, so post */
+ __raw_i915_read32(dev_priv, FPGA_DBG);
+
+ return true;
+}
+
static void __intel_uncore_early_sanitize(struct drm_device *dev,
bool restore_forcewake)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- if (HAS_FPGA_DBG_UNCLAIMED(dev))
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+ /* clear out unclaimed reg detection bit */
+ if (check_for_unclaimed_mmio(dev_priv))
+ DRM_DEBUG("unclaimed mmio detected on uncore init, clearing\n");
/* clear out old GT FIFO errors */
if (IS_GEN6(dev) || IS_GEN7(dev))
@@ -601,10 +622,9 @@ hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv,
if (!i915.mmio_debug)
return;
- if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
+ if (check_for_unclaimed_mmio(dev_priv)) {
WARN(1, "Unclaimed register detected %s %s register 0x%x\n",
when, op, i915_mmio_reg_offset(reg));
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
i915.mmio_debug--; /* Only report the first N failures */
}
}
@@ -617,11 +637,10 @@ hsw_unclaimed_reg_detect(struct drm_i915_private
*dev_priv)
if (i915.mmio_debug || !mmio_debug_once)
return;
- if (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM) {
+ if (check_for_unclaimed_mmio(dev_priv)) {
DRM_DEBUG("Unclaimed register detected, "
"enabling oneshot unclaimed register reporting. "
"Please use i915.mmio_debug=N for more
information.\n");
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
i915.mmio_debug = mmio_debug_once--;
}
}
@@ -1589,11 +1608,6 @@ bool intel_has_gpu_reset(struct drm_device *dev)
void intel_uncore_check_errors(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
- (__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM)) {
+ if (check_for_unclaimed_mmio(to_i915(dev)))
DRM_ERROR("Unclaimed register before interrupt\n");
- __raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
- }
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Do one shot unclaimed mmio detection less frequently
We have done unclaimed register access check in normal
(mmio_debug=0) mode once per write. This adds probability
of finding the exact sequence where we did the bad access, but
also adds burden to each write.
As we have mmio_debug available for more fine grained analysis,
give up accuracy of detecting correct spot at the first occurrence
by doing the one shot detection and arming of mmio_debug in hangcheck
and in modeset. This removes the write path performance burden.
Note that in hangcheck when we arm the fine grained debug
facilities, there is no context even if the unclaimed access
is already set and thus notifying in this point has no added value.
In contrary, in display path, we add a debug message if the bit
was set on arming.
Cc: Chris Wilson
Cc: Paulo Zanoni
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_irq.c | 10 -
drivers/gpu/drm/i915/intel_display.c | 3 +++
drivers/gpu/drm/i915/intel_uncore.c | 40 +++-
4 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82c43b6..625aae9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -723,6 +723,8 @@ struct intel_uncore {
i915_reg_t reg_post;
u32 val_reset;
} fw_domain[FW_DOMAIN_ID_COUNT];
+
+ int unclaimed_mmio_check;
};
/* Iterate over initialised fw domains */
@@ -2732,6 +2734,7 @@ extern void intel_uncore_early_sanitize(struct drm_device
*dev,
bool restore_forcewake);
extern void intel_uncore_init(struct drm_device *dev);
extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
+extern bool intel_uncore_arm_unclaimed_mmio_detection(struct drm_i915_private
*dev_priv);
extern void intel_uncore_fini(struct drm_device *dev);
extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore);
const char *intel_uncore_forcewake_domain_to_str(const enum
forcewake_domain_id id);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a20dc64..725a340 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2165,11 +2165,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
if (!intel_irqs_enabled(dev_priv))
return IRQ_NONE;
- /* We get interrupts on unclaimed registers, so check for this before we
-* do any I915_{READ,WRITE}. */
- if (intel_uncore_unclaimed_mmio(dev_priv))
- DRM_ERROR("Unclaimed register before interrupt\n");
-
/* disable master interrupt before clearing iir */
de_ier = I915_READ(DEIER);
I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
@@ -2990,6 +2985,11 @@ static void i915_hangcheck_elapsed(struct work_struct
*work)
if (!i915.enable_hangcheck)
return;
+ /* Periodic arming of mmio_debug if hw detects mmio
+* access to out of range or to an unpowered block
+*/
+ intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
+
for_each_ring(ring, dev_priv, i) {
u64 acthd;
u32 seqno;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 471f120..3a9229b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13545,6 +13545,9 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_state_free(state);
+ if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
+ DRM_DEBUG_DRIVER("%s return with unclaimed access\n", __func__);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 34b60cb..911f189 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -629,22 +629,6 @@ hsw_unclaimed_reg_debug(struct drm_i915_private *dev_priv,
}
}
-static void
-hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
-{
- static bool mmio_debug_once = true;
-
- if (i915.mmio_debug || !mmio_debug_once)
- return;
-
- if (check_for_unclaimed_mmio(dev_priv)) {
- DRM_DEBUG("Unclaimed register detected, "
- "enabling oneshot unclaimed register reporting. "
- "Please use i915.mmio_debug=N for more
information.\n");
- i915.mmio_debug = mmio_debug_once--;
- }
-}
-
#define GEN2_READ_HEADER(x) \
u##x val = 0; \
assert_device_not_suspended(dev_priv);
@@ -924,7 +908,6 @@ hsw_write##x(struct drm_i915_private *dev_priv, i915_reg_t
reg, u##x val, bool t
gen6_gt_check_fifodbg(dev_priv); \
} \
hsw_unclaimed_reg_debug(dev_priv, reg, false, false); \
- hsw_unclaimed_reg_detect(dev_pr
Re: [Intel-gfx] [PATCH 11/11] drm/i915/opregion: handle VBT sizes bigger than 6 KB
On Mon, Dec 14, 2015 at 04:34:34PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 04:19:50PM +0200, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2015 at 12:50:55PM +0200, Jani Nikula wrote:
> > > The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
> > > mailbox may specify an alternate location for VBT instead of mailbox #4.
> > > Use the alternate location if available and valid, falling back to
> > > mailbox #4 otherwise.
> > >
> > > Signed-off-by: Jani Nikula
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_opregion.c | 25 +++--
> > > 2 files changed, 24 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index ca8c2a64bc6d..8cfac7398568 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -457,6 +457,7 @@ struct intel_opregion {
> > > u32 swsci_gbda_sub_functions;
> > > u32 swsci_sbcb_sub_functions;
> > > struct opregion_asle *asle;
> > > + void *rvda;
> > > const void *vbt;
> > > u32 vbt_size;
> > > u32 *lid_state;
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_opregion.c
> > > index e89ee2383fe1..a139889dd45b 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -837,6 +837,10 @@ void intel_opregion_fini(struct drm_device *dev)
> > >
> > > /* just clear all opregion memory pointers now */
> > > memunmap(opregion->header);
> > > + if (opregion->rvda) {
> > > + memunmap(opregion->rvda);
> > > + opregion->rvda = NULL;
> > > + }
> > > opregion->header = NULL;
> > > opregion->acpi = NULL;
> > > opregion->swsci = NULL;
> > > @@ -987,12 +991,29 @@ int intel_opregion_setup(struct drm_device *dev)
> > > ` DRM_DEBUG_DRIVER("ASLE extension supported\n");
> > >
> > > if (!dmi_check_system(intel_no_opregion_vbt)) {
> > > - const void *vbt = base + OPREGION_VBT_OFFSET;
> > > - u32 vbt_size = OPREGION_ASLE_EXT_OFFSET - OPREGION_VBT_OFFSET;
> > > + const void *vbt = NULL;
> > > + u32 vbt_size = 0;
> > > +
> > > + if (opregion->header->opregion_ver >= 2 && opregion->asle &&
> > > + opregion->asle->rvda && opregion->asle->rvds) {
> >
> > Either I'm blind or you didn't actually add rvda/rvds to struct
> > opregion_asle.
>
> Oh I se they went in seprately as
> c85f6c91ec42 ("drm/i915: add VBT address and size fields to ASLE mailbox
> struct")
>
> OK, so apart from the few minor bikesheds I listed it all looks good to
> me. For the series
> Reviewed-by: Ville Syrjälä
r-b still holds for the patches with the revised debug prints.
>
> >
> > Also the spec seems confused as usual. Some parts if it refer to this
> > as RVDA others as RVBT. Although RVBT also seems to be what the mbox #4
> > contents are called in another place, and to add insult to injury that
> > place also has the offset and size all wrong. Sigh.
> >
> > Anyway, apart from the missing rvda/rvds definititions the rest looks OK.
> >
> > > + opregion->rvda = memremap(opregion->asle->rvda,
> > > + opregion->asle->rvds,
> > > + MEMREMAP_WB);
> > > + vbt = opregion->rvda;
> > > + vbt_size = opregion->asle->rvds;
> > > + }
> > >
> > > if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> > > opregion->vbt = vbt;
> > > opregion->vbt_size = vbt_size;
> > > + DRM_DEBUG_DRIVER("VBT from RVDA\n");
> > > + } else {
> > > + vbt = base + OPREGION_VBT_OFFSET;
> > > + vbt_size = OPREGION_ASLE_EXT_OFFSET -
> > > OPREGION_VBT_OFFSET;
> > > + if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> > > + opregion->vbt = vbt;
> > > + opregion->vbt_size = vbt_size;
> > > + }
> > > }
> > > }
> > >
> > > --
> > > 2.1.4
> > >
> > > ___
> > > 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
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> 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
Re: [Intel-gfx] [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame counter as hex
On Tue, Dec 15, 2015 at 12:03:11PM +, Morton, Derek J wrote: > > > > > >-Original Message- > >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > >Of ville.syrj...@linux.intel.com > >Sent: Monday, December 14, 2015 8:16 PM > >To: intel-gfx@lists.freedesktop.org > >Subject: [Intel-gfx] [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame > >counter as hex > > > >From: Ville Syrjälä > > > >With the kernel fixed to dump out the crc frame counts in hex, we must > >follow suit. > > > >Signed-off-by: Ville Syrjälä > >--- > > 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 > >2c3b1cfe2370..5e71f50d7326 100644 > >--- a/lib/igt_debugfs.c > >+++ b/lib/igt_debugfs.c > >@@ -484,7 +484,7 @@ static bool pipe_crc_init_from_string(igt_crc_t *crc, > >const char *line) > > int n; > > > > crc->n_words = 5; > >-n = sscanf(line, "%8u %8x %8x %8x %8x %8x", &crc->frame, &crc->crc[0], > >+n = sscanf(line, "%8x %8x %8x %8x %8x %8x", &crc->frame, &crc->crc[0], > > What will happen for kernels that have not been 'fixed'? Android is always > behind drm_nightly. Is there any way of knowing whether this value is in hex > or decimal and read it accordingly? What tests will be affected if this is > wrong? You might know if it's hex if the number happes to have a-f in it. Othwerwise you can't tell since we don't use a 0x prefix. Another option is to fix the size assumptions about the string on both kernel and igt side. And a third option would be to have the kernel return 'count & 0xff' which would fit in the 8 characters allotted. igt wouldn't need to be changed in this case. That might actually make some sense since on gen3/4 the hw frame counter is only 24 bits. If userspace would have to deal with wraparound it could just assume that it occurs at 2^24. Actually now that I think about the current tests are probably broken if the counter wraps sooner than 2^32. But since the interface can't even carry such large frame counter numbers the test will simply fail in other ways until the kernel gets fixed. > > //Derek > > >&crc->crc[1], &crc->crc[2], &crc->crc[3], &crc->crc[4]); > > return n == 6; > > } > >-- > >2.4.10 > > > >___ > >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
Re: [Intel-gfx] [PATCH i-g-t 4/7] tests/gem_mmap_gtt: Make the small-bo tiling tests work on old platforms
On Tue, Dec 15, 2015 at 02:01:24PM +0200, Ville Syrjälä wrote: > On Tue, Dec 15, 2015 at 01:29:59PM +0200, Ville Syrjälä wrote: > > On Tue, Dec 15, 2015 at 11:16:52AM +, Chris Wilson wrote: > > > On Tue, Dec 15, 2015 at 12:57:15PM +0200, Ville Syrjälä wrote: > > > > On Tue, Dec 15, 2015 at 09:57:22AM +, Chris Wilson wrote: > > > > > On Tue, Dec 15, 2015 at 11:41:44AM +0200, Ville Syrjälä wrote: > > > > > > On Mon, Dec 14, 2015 at 08:54:35PM +, Chris Wilson wrote: > > > > > > > On Mon, Dec 14, 2015 at 08:49:38PM +, Chris Wilson wrote: > > > > > > > > On Mon, Dec 14, 2015 at 10:15:53PM +0200, > > > > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > > > > > Several factors conspire against us when trying to execute > > > > > > > > > the tiled small-bo tests: > > > > > > > > > - pre-gen4 require power of two fences, with natural alignment > > > > > > > > > - the entire gtt may be mappable > > > > > > > > > - we put a guard page at the end of gtt > > > > > > > > > > > > > > > > > > What all that means is that when we try to use a tiled object > > > > > > > > > half > > > > > > > > > the size of the mappable area, we can only fit it in the > > > > > > > > > first half > > > > > > > > > of the gtt. That leads to a SIGBUS when we try to fault in the > > > > > > > > > object when there's already something (eg. fbdev) occupying > > > > > > > > > the > > > > > > > > > first half of gtt. > > > > > > > > > > > > > > > > > > So in order to make the tests run on old machines, let's > > > > > > > > > further > > > > > > > > > halve the object size when things look too tight. > > > > > > > > > > > > > > > > That defeats the point of the test. The idea is to have the two > > > > > > > > objects > > > > > > > > that just don't fit, but only just. > > > > > > > > > > > > > > i.e. the test is meant to show that the kernel heuristics for > > > > > > > using > > > > > > > partial vma do not prevent the page-fault-of-doom. > > > > > > > > > > > > So just skip then? > > > > > > > > > > The kernel has a bug that partial vma was supposed to address. > > > > > > > > I'm not sure partial vma has any benefit in this case. Sure, you could > > > > them mmap the thing but unless we teach the GPU to also use partial > > > > mappings it won't do any good since we just can't fit the thing into > > > > the gtt. > > > > > > For gen2, not being able to fit into mappable is an issue for the GPU as > > > well, sure. But for userspace being oblivious and *always* being able to > > > use mmaping of a bo, it is a big deal. (Being oblivious helps with > > > robustness in the stack, X/display-server-de-jour should not die just > > > because of a resource conflict - now X should catch the fault and handle > > > it, give or take bugs, avoiding that error path entirely is even better.) > > > > Yeah, I suppose it would be nice not to SIGBUS even if userspace is > > trying something a bit crazy. It would just get an error later from > > execbuf when trying to use the bo with the GPU. So I guess the right > > fix would be to fall back to partial vma if we fail to bind the full > > vma. > > Hmm, actaully no. This was about tiled objects, and we don't do > tiled+partial at all currently. Would need to teach the code to do that > first. It's is one and the same fix ;) (Ok, same patchset!) -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 7/8] drm/i915: Support for pread/pwrite from/to non shmem backed objects
On Tue, Dec 15, 2015 at 04:26:07PM +0530, ankitprasad.r.sha...@intel.com wrote:
> +static int
> +i915_gem_gtt_copy(struct drm_device *dev,
> +struct drm_i915_gem_object *obj, uint64_t size,
> +uint64_t data_offset, uint64_t data_ptr)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + char __user *user_data;
> + uint64_t remain;
> + uint64_t offset, page_base;
> + int page_offset, page_length, ret = 0;
> +
> + ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
> + if (ret)
> + goto out;
Note that the interfaces this is used for (PRIME) can easily allocate
objects larger than the mappable GTT which promptly fails. If only we
had been working on a per-page GTT accessor...
-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 i-g-t 5/7] lib/debugfs: Read the crc frame counter as hex
> > >-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >ville.syrj...@linux.intel.com >Sent: Monday, December 14, 2015 8:16 PM >To: intel-gfx@lists.freedesktop.org >Subject: [Intel-gfx] [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame counter >as hex > >From: Ville Syrjälä > >With the kernel fixed to dump out the crc frame counts in hex, we must follow >suit. > >Signed-off-by: Ville Syrjälä >--- > 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 >2c3b1cfe2370..5e71f50d7326 100644 >--- a/lib/igt_debugfs.c >+++ b/lib/igt_debugfs.c >@@ -484,7 +484,7 @@ static bool pipe_crc_init_from_string(igt_crc_t *crc, >const char *line) > int n; > > crc->n_words = 5; >- n = sscanf(line, "%8u %8x %8x %8x %8x %8x", &crc->frame, &crc->crc[0], >+ n = sscanf(line, "%8x %8x %8x %8x %8x %8x", &crc->frame, &crc->crc[0], What will happen for kernels that have not been 'fixed'? Android is always behind drm_nightly. Is there any way of knowing whether this value is in hex or decimal and read it accordingly? What tests will be affected if this is wrong? //Derek > &crc->crc[1], &crc->crc[2], &crc->crc[3], &crc->crc[4]); > return n == 6; > } >-- >2.4.10 > >___ >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 i-g-t 4/7] tests/gem_mmap_gtt: Make the small-bo tiling tests work on old platforms
On Tue, Dec 15, 2015 at 01:29:59PM +0200, Ville Syrjälä wrote: > On Tue, Dec 15, 2015 at 11:16:52AM +, Chris Wilson wrote: > > On Tue, Dec 15, 2015 at 12:57:15PM +0200, Ville Syrjälä wrote: > > > On Tue, Dec 15, 2015 at 09:57:22AM +, Chris Wilson wrote: > > > > On Tue, Dec 15, 2015 at 11:41:44AM +0200, Ville Syrjälä wrote: > > > > > On Mon, Dec 14, 2015 at 08:54:35PM +, Chris Wilson wrote: > > > > > > On Mon, Dec 14, 2015 at 08:49:38PM +, Chris Wilson wrote: > > > > > > > On Mon, Dec 14, 2015 at 10:15:53PM +0200, > > > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > > > Several factors conspire against us when trying to execute > > > > > > > > the tiled small-bo tests: > > > > > > > > - pre-gen4 require power of two fences, with natural alignment > > > > > > > > - the entire gtt may be mappable > > > > > > > > - we put a guard page at the end of gtt > > > > > > > > > > > > > > > > What all that means is that when we try to use a tiled object > > > > > > > > half > > > > > > > > the size of the mappable area, we can only fit it in the first > > > > > > > > half > > > > > > > > of the gtt. That leads to a SIGBUS when we try to fault in the > > > > > > > > object when there's already something (eg. fbdev) occupying the > > > > > > > > first half of gtt. > > > > > > > > > > > > > > > > So in order to make the tests run on old machines, let's further > > > > > > > > halve the object size when things look too tight. > > > > > > > > > > > > > > That defeats the point of the test. The idea is to have the two > > > > > > > objects > > > > > > > that just don't fit, but only just. > > > > > > > > > > > > i.e. the test is meant to show that the kernel heuristics for using > > > > > > partial vma do not prevent the page-fault-of-doom. > > > > > > > > > > So just skip then? > > > > > > > > The kernel has a bug that partial vma was supposed to address. > > > > > > I'm not sure partial vma has any benefit in this case. Sure, you could > > > them mmap the thing but unless we teach the GPU to also use partial > > > mappings it won't do any good since we just can't fit the thing into > > > the gtt. > > > > For gen2, not being able to fit into mappable is an issue for the GPU as > > well, sure. But for userspace being oblivious and *always* being able to > > use mmaping of a bo, it is a big deal. (Being oblivious helps with > > robustness in the stack, X/display-server-de-jour should not die just > > because of a resource conflict - now X should catch the fault and handle > > it, give or take bugs, avoiding that error path entirely is even better.) > > Yeah, I suppose it would be nice not to SIGBUS even if userspace is > trying something a bit crazy. It would just get an error later from > execbuf when trying to use the bo with the GPU. So I guess the right > fix would be to fall back to partial vma if we fail to bind the full > vma. Hmm, actaully no. This was about tiled objects, and we don't do tiled+partial at all currently. Would need to teach the code to do that first. > > > > > Using "sparse" resources so that we can arbitrary sized objects is > > something I'd like. But we have so much "whole-object-at-once" baked > > into the code, it will be a challenge. > > -Chris > > > > -- > > Chris Wilson, Intel Open Source Technology Centre > > -- > Ville Syrjälä > Intel OTC > ___ > 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
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Add support for stealing purgable stolen pages
On Tue, Dec 15, 2015 at 04:26:06PM +0530, ankitprasad.r.sha...@intel.com wrote:
> +static int
> +stolen_evict(struct drm_i915_private *dev_priv, u64 size)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_i915_gem_object *obj;
> - struct drm_mm_node *stolen;
> - int ret;
> + struct list_head unwind, evict;
> + struct i915_stolen_node *iter;
> + int ret, active;
lockdep_assert_held(&dev_priv->dev->struct_mutex);
would be nice as I just spent a moment refreshing what locks we
required.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Clearing buffer objects via CPU/GTT
On Tue, Dec 15, 2015 at 04:26:03PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> This patch adds support for clearing buffer objects via CPU/GTT. This
> is particularly useful for clearing out the non shmem backed objects.
> Currently intend to use this only for buffers allocated from stolen
> region.
>
> v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
> variable assignments (Tvrtko)
>
> v3: Map object page by page to the gtt if the pinning of the whole object
> to the ggtt fails, Corrected function name (Chris)
>
> v4: Clear the buffer page by page, and not map the whole object in the gtt
> aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.
>
> v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
> updated barrier positioning (Chris)
>
> Testcase: igt/gem_stolen
>
> Signed-off-by: Ankitprasad Sharma
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 42
> +
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a10b866..e195fee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2897,6 +2897,7 @@ int i915_gem_obj_prepare_shmem_read(struct
> drm_i915_gem_object *obj,
> int *needs_clflush);
>
> int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
> +int i915_gem_object_clear(struct drm_i915_gem_object *obj);
>
> static inline int __sg_page_count(struct scatterlist *sg)
> {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fe8b14d..b25f28c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5288,3 +5288,45 @@ fail:
> drm_gem_object_unreference(&obj->base);
> return ERR_PTR(ret);
> }
> +
> +/**
> + * i915_gem_object_clear() - Clear buffer object via CPU/GTT
> + * @obj: Buffer object to be cleared
> + *
> + * Return: 0 - success, non-zero - failure
> + */
> +int i915_gem_object_clear(struct drm_i915_gem_object *obj)
> +{
> + int ret, i;
> + char __iomem *base;
> + size_t size = obj->base.size;
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct drm_mm_node node;
> +
> + lockdep_assert_held(&obj->base.dev->struct_mutex);
> + memset(&node, 0, sizeof(node));
> + ret = insert_mappable_node(i915, &node);
> + if (ret)
> + goto out;
> +
> + i915_gem_object_pin_pages(obj);
> + base = io_mapping_map_wc(i915->gtt.mappable, node.start);
> + for (i = 0; i < size/PAGE_SIZE; i++) {
> + i915->gtt.base.insert_page(&i915->gtt.base,
> +i915_gem_object_get_dma_address(obj,
> i),
> +node.start,
> +I915_CACHE_NONE, 0);
> + wmb();
> + memset_io(base, 0, 4096);
> + wmb();
> + }
> +
> + io_mapping_unmap(base);
> + i915->gtt.base.clear_range(&i915->gtt.base,
> + node.start, node.size,
> + true);
> + drm_mm_remove_node(&node);
Since you have insert_mappable_node()
remove_mappable_node() would be a nice counterpart for the above.
-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] drm/i915: Get runtime pm ref on i915_drop_caches_set
On ti, 2015-12-15 at 13:35 +0200, Mika Kuoppala wrote:
> Some igt tests wants to drop caches by writing to this debugfs
> entry. The call to shrinker may ensure and it wants to update
> the fence registers, so hardware access happens. This access
> can happen in a spot where the block containing these registers
> might bepowered down.
>
> To avoid getting unclaimed register access trace noise due
> to this, take a runtime pm reference during i915_drop_caches set.
>
> v2: pm_ref and mutex lock ordering (Chris)
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 24318b7..d96709a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4833,11 +4833,13 @@ i915_drop_caches_set(void *data, u64 val)
>
> DRM_DEBUG("Dropping caches: 0x%08llx\n", val);
>
> + intel_runtime_pm_get(dev_priv);
> +
> /* No need to check and wait for gpu resets, only libdrm
> auto-restarts
>* on ioctls on -EAGAIN. */
> ret = mutex_lock_interruptible(&dev->struct_mutex);
> if (ret)
> - return ret;
> + goto pm_put;
>
> if (val & DROP_ACTIVE) {
> ret = i915_gpu_idle(dev);
> @@ -4856,7 +4858,9 @@ i915_drop_caches_set(void *data, u64 val)
>
> unlock:
> mutex_unlock(&dev->struct_mutex);
> -
> +pm_put:
> + intel_runtime_pm_put(dev_priv);
> +
> return ret;
> }
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Migrate stolen objects before hibernation
On Tue, Dec 15, 2015 at 04:26:08PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Chris Wilson
> +static int
> +copy_content(struct drm_i915_gem_object *obj,
> + struct drm_i915_private *i915,
> + struct address_space *mapping)
> +{
> + struct drm_mm_node node;
> + int ret, i;
> +
> + ret = i915_gem_object_set_to_gtt_domain(obj, false);
> + if (ret)
> + return ret;
> +
> + /* stolen objects are already pinned to prevent shrinkage */
> + memset(&node, 0, sizeof(node));
> + ret = insert_mappable_node(i915, &node);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
> + struct page *page;
> + void *__iomem src;
> + void *dst;
> +
> + i915->gtt.base.insert_page(&i915->gtt.base,
> +i915_gem_object_get_dma_address(obj,
> i),
> +node.start,
> +I915_CACHE_NONE,
> +0);
> +
> + page = shmem_read_mapping_page(mapping, i);
> + if (IS_ERR(page)) {
> + ret = PTR_ERR(page);
> + break;
> + }
> +
> + src = io_mapping_map_atomic_wc(i915->gtt.mappable, node.start);
> + dst = kmap_atomic(page);
> + wmb();
> + memcpy_fromio(dst, src, PAGE_SIZE);
> + wmb();
> + kunmap_atomic(dst);
> + io_mapping_unmap_atomic(src);
> +
> + page_cache_release(page);
> + }
> +
> + wmb();
After moving the barriers, this one is redundant.
> + i915->gtt.base.clear_range(&i915->gtt.base,
> +node.start, node.size,
> +true);
> + drm_mm_remove_node(&node);
> + obj->base.read_domains = I915_GEM_DOMAIN_CPU;
> + obj->base.write_domain = I915_GEM_DOMAIN_CPU;
On the error path, we shouldn't be marking new domains as the object
reverts back to the previous set of pages.
If you do a bit of rearranging of the goto err, you could just put
return i915_gem_object_set_to_cpu_domain(obj, true);
It will be mostly a no-op over the current set read/write domains (but
should help in case it ever is not).
> +int
> +i915_gem_freeze(struct drm_device *dev)
> +{
> + /* Called before i915_gem_suspend() when hibernating */
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct drm_i915_gem_object *obj, *tmp;
> + struct list_head *phase[] = {
> + &i915->mm.unbound_list, &i915->mm.bound_list, NULL
> + }, **p;
> + int ret;
> +
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> + return ret;
> +
> + /* Across hibernation, the stolen area is not preserved.
> + * Anything inside stolen must copied back to normal
> + * memory if we wish to preserve it.
> + */
> + for (p = phase; *p; p++) {
Since we are making changes, might as well push this loop to
i915_gem_stolen_freeze() and i915_gem_stolen.c. Probably best to push
the i915_gem_object_stolen_migrate_to_shemfs() there as well.
-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 10/10] drm/i915: Use MI_BATCH_BUFFER_START on 830/845
On Tue, Dec 15, 2015 at 11:22:29AM +, Chris Wilson wrote: > On Tue, Dec 15, 2015 at 01:05:56PM +0200, Ville Syrjälä wrote: > > On Tue, Dec 15, 2015 at 10:24:13AM +, Chris Wilson wrote: > > > The other question, does this obsolete our work around? Can I be that > > > optimisitic? > > > > The CS TLB one? I think I tried it at some point, and things till > > failed. But stuff fails even with the w/a (like I said piglit will > > hang the GPU eventually), so I can't be sure that I actually tested > > the CS TLB fail. I think I need to retest at some point. > > > > As far as the docs go, I only remember it mentioning some TLB fail > > affecting the blitter. I guess the CS TLB fail isn't actually > > documented anywhere? > > It's hard to be sure since the issue is only mentioned obliquely in > bspec. I strongly suspect there is only one set of TLB on the device, so > I think it is the same. But I never did figure out what flush they > meant, as all the chipset or MI level flushes never seemed to do anything > to improve the situation. Programming Environment 1.4.9.4 claims that there are several TLBs. But not sure if that really holds for all devices. It also has the following table: GTT TLBs TLB| Normal Invalidation Mechanism | Invalidated by Page Table Enable bit || of PGTBL_CTL register? ... Command Stream | Through a Page Table PTE write | Yes Which might hint that PGTBL_CTL might be the way to force invalidate them. But IIRC you may have once said that you already tried it. In any case, even if it would work we'd need to make sure no GTT access is happening when toggling the bit (assuming we'd have to toggle it). -- 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 1/6] drm/i915: Get runtime pm ref on i915_drop_caches_set
Chris Wilson writes: > On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote: >> When we drop caches, this debugfs entry does hardware access later in >> the chain, when fences are updated, so it needs a runtime pm ref. >> >> Dropping caches is used by some igt/bat tests, so this fixes >> some unclaimed register access traces. >> >> Signed-off-by: Mika Kuoppala >> --- >> drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c >> b/drivers/gpu/drm/i915/i915_debugfs.c >> index 24318b7..bd8ba7e 100644 >> --- a/drivers/gpu/drm/i915/i915_debugfs.c >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c >> @@ -4839,6 +4839,8 @@ i915_drop_caches_set(void *data, u64 val) >> if (ret) >> return ret; >> >> +intel_runtime_pm_get(dev_priv); > > The current idea of the very coarse granularity of rpm_get() is to do it > before struct_mutex (since rpm_get resume may try to acquire the mutex > iirc). > > Ok, fixing that may be bolting the stable door after the horse bolted, > but we should nevertheless. In my opinion, it would be more productive > to work with Imre on making rpm fine grained so that we don't so many > and can actually place the wakelock around the hardware access itself, > not every single path that *may* touch hardware. Please consider 1/6 v2 as it is needed to avoid random unclaimed accesses during igt/bat if the drop caches is used in wrong spot. We can forget the rest. -Mika > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Get runtime pm ref on i915_drop_caches_set
Some igt tests wants to drop caches by writing to this debugfs
entry. The call to shrinker may ensure and it wants to update
the fence registers, so hardware access happens. This access
can happen in a spot where the block containing these registers
might bepowered down.
To avoid getting unclaimed register access trace noise due
to this, take a runtime pm reference during i915_drop_caches set.
v2: pm_ref and mutex lock ordering (Chris)
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24318b7..d96709a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4833,11 +4833,13 @@ i915_drop_caches_set(void *data, u64 val)
DRM_DEBUG("Dropping caches: 0x%08llx\n", val);
+ intel_runtime_pm_get(dev_priv);
+
/* No need to check and wait for gpu resets, only libdrm auto-restarts
* on ioctls on -EAGAIN. */
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
- return ret;
+ goto pm_put;
if (val & DROP_ACTIVE) {
ret = i915_gpu_idle(dev);
@@ -4856,7 +4858,9 @@ i915_drop_caches_set(void *data, u64 val)
unlock:
mutex_unlock(&dev->struct_mutex);
-
+pm_put:
+ intel_runtime_pm_put(dev_priv);
+
return ret;
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/7] tests/gem_mmap_gtt: Make the small-bo tiling tests work on old platforms
On Tue, Dec 15, 2015 at 11:16:52AM +, Chris Wilson wrote: > On Tue, Dec 15, 2015 at 12:57:15PM +0200, Ville Syrjälä wrote: > > On Tue, Dec 15, 2015 at 09:57:22AM +, Chris Wilson wrote: > > > On Tue, Dec 15, 2015 at 11:41:44AM +0200, Ville Syrjälä wrote: > > > > On Mon, Dec 14, 2015 at 08:54:35PM +, Chris Wilson wrote: > > > > > On Mon, Dec 14, 2015 at 08:49:38PM +, Chris Wilson wrote: > > > > > > On Mon, Dec 14, 2015 at 10:15:53PM +0200, > > > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > From: Ville Syrjälä > > > > > > > > > > > > > > Several factors conspire against us when trying to execute > > > > > > > the tiled small-bo tests: > > > > > > > - pre-gen4 require power of two fences, with natural alignment > > > > > > > - the entire gtt may be mappable > > > > > > > - we put a guard page at the end of gtt > > > > > > > > > > > > > > What all that means is that when we try to use a tiled object half > > > > > > > the size of the mappable area, we can only fit it in the first > > > > > > > half > > > > > > > of the gtt. That leads to a SIGBUS when we try to fault in the > > > > > > > object when there's already something (eg. fbdev) occupying the > > > > > > > first half of gtt. > > > > > > > > > > > > > > So in order to make the tests run on old machines, let's further > > > > > > > halve the object size when things look too tight. > > > > > > > > > > > > That defeats the point of the test. The idea is to have the two > > > > > > objects > > > > > > that just don't fit, but only just. > > > > > > > > > > i.e. the test is meant to show that the kernel heuristics for using > > > > > partial vma do not prevent the page-fault-of-doom. > > > > > > > > So just skip then? > > > > > > The kernel has a bug that partial vma was supposed to address. > > > > I'm not sure partial vma has any benefit in this case. Sure, you could > > them mmap the thing but unless we teach the GPU to also use partial > > mappings it won't do any good since we just can't fit the thing into > > the gtt. > > For gen2, not being able to fit into mappable is an issue for the GPU as > well, sure. But for userspace being oblivious and *always* being able to > use mmaping of a bo, it is a big deal. (Being oblivious helps with > robustness in the stack, X/display-server-de-jour should not die just > because of a resource conflict - now X should catch the fault and handle > it, give or take bugs, avoiding that error path entirely is even better.) Yeah, I suppose it would be nice not to SIGBUS even if userspace is trying something a bit crazy. It would just get an error later from execbuf when trying to use the bo with the GPU. So I guess the right fix would be to fall back to partial vma if we fail to bind the full vma. > > Using "sparse" resources so that we can arbitrary sized objects is > something I'd like. But we have so much "whole-object-at-once" baked > into the code, it will be a challenge. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- 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 10/10] drm/i915: Use MI_BATCH_BUFFER_START on 830/845
On Tue, Dec 15, 2015 at 01:05:56PM +0200, Ville Syrjälä wrote: > On Tue, Dec 15, 2015 at 10:24:13AM +, Chris Wilson wrote: > > The other question, does this obsolete our work around? Can I be that > > optimisitic? > > The CS TLB one? I think I tried it at some point, and things till > failed. But stuff fails even with the w/a (like I said piglit will > hang the GPU eventually), so I can't be sure that I actually tested > the CS TLB fail. I think I need to retest at some point. > > As far as the docs go, I only remember it mentioning some TLB fail > affecting the blitter. I guess the CS TLB fail isn't actually > documented anywhere? It's hard to be sure since the issue is only mentioned obliquely in bspec. I strongly suspect there is only one set of TLB on the device, so I think it is the same. But I never did figure out what flush they meant, as all the chipset or MI level flushes never seemed to do anything to improve the situation. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/11] drm/i915/opregion: handle VBT sizes bigger than 6 KB
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
mailbox may specify an alternate location for VBT instead of mailbox #4.
Use the alternate location if available and valid, falling back to
mailbox #4 otherwise.
v2: Update debug logging (Ville)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_opregion.c | 27 ---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca8c2a64bc6d..8cfac7398568 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -457,6 +457,7 @@ struct intel_opregion {
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
struct opregion_asle *asle;
+ void *rvda;
const void *vbt;
u32 vbt_size;
u32 *lid_state;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 53164a05ff7a..4a8db5522432 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -837,6 +837,10 @@ void intel_opregion_fini(struct drm_device *dev)
/* just clear all opregion memory pointers now */
memunmap(opregion->header);
+ if (opregion->rvda) {
+ memunmap(opregion->rvda);
+ opregion->rvda = NULL;
+ }
opregion->header = NULL;
opregion->acpi = NULL;
opregion->swsci = NULL;
@@ -987,13 +991,30 @@ int intel_opregion_setup(struct drm_device *dev)
DRM_DEBUG_DRIVER("ASLE extension supported\n");
if (!dmi_check_system(intel_no_opregion_vbt)) {
- const void *vbt = base + OPREGION_VBT_OFFSET;
- u32 vbt_size = OPREGION_ASLE_EXT_OFFSET - OPREGION_VBT_OFFSET;
+ const void *vbt = NULL;
+ u32 vbt_size = 0;
+
+ if (opregion->header->opregion_ver >= 2 && opregion->asle &&
+ opregion->asle->rvda && opregion->asle->rvds) {
+ opregion->rvda = memremap(opregion->asle->rvda,
+ opregion->asle->rvds,
+ MEMREMAP_WB);
+ vbt = opregion->rvda;
+ vbt_size = opregion->asle->rvds;
+ }
if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
- DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion\n");
+ DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion
(RVDA)\n");
opregion->vbt = vbt;
opregion->vbt_size = vbt_size;
+ } else {
+ vbt = base + OPREGION_VBT_OFFSET;
+ vbt_size = OPREGION_ASLE_EXT_OFFSET -
OPREGION_VBT_OFFSET;
+ if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
+ DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion
(Mailbox #4)\n");
+ opregion->vbt = vbt;
+ opregion->vbt_size = vbt_size;
+ }
}
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/11] drm/i915/debugfs: add a separate debugfs file for VBT
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion,
thus unavailable in i915_opregion, so add a separate file for the VBT.
v2: Drop the locking as unneeded (Chris)
v3: Rebase
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_opregion.c | 1 +
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a9e1f18c36d1..0fc38bb7276c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1857,6 +1857,19 @@ out:
return 0;
}
+static int i915_vbt(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_opregion *opregion = &dev_priv->opregion;
+
+ if (opregion->vbt)
+ seq_write(m, opregion->vbt, opregion->vbt_size);
+
+ return 0;
+}
+
static int i915_gem_framebuffer_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5325,6 +5338,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_ips_status", i915_ips_status, 0},
{"i915_sr_status", i915_sr_status, 0},
{"i915_opregion", i915_opregion, 0},
+ {"i915_vbt", i915_vbt, 0},
{"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
{"i915_context_status", i915_context_status, 0},
{"i915_dump_lrc", i915_dump_lrc, 0},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10e47167c594..ca8c2a64bc6d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -458,6 +458,7 @@ struct intel_opregion {
u32 swsci_sbcb_sub_functions;
struct opregion_asle *asle;
const void *vbt;
+ u32 vbt_size;
u32 *lid_state;
struct work_struct asle_work;
};
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index e1795de440db..53164a05ff7a 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -993,6 +993,7 @@ int intel_opregion_setup(struct drm_device *dev)
if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion\n");
opregion->vbt = vbt;
+ opregion->vbt_size = vbt_size;
}
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
