Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT
It is OK for me for all your comments, thanks!
Just one question need to confirm with you inline.
>A couple of comments below.
>
>
>On Thu, Jan 19, 2017 at 04:32:19PM +0800, Terrence Xu wrote:
>> GVT-g (Intel(r) Graphics Virtualization Technology) is a full GPU
>> virtualization solution with mediated pass-through support.
>>
>> This tool is for create basic Linux guest based on KVMGT with VFIO
>> framework, it including create vgpu, create guest, check IP address,
>> destroy guest, remove vgpu,check dmesg log, etc functions.
>>
>> v2: Treat this case as a free-standing tool, with detect & skip when
>> it's not running on GVT-g capable platform or running without the
>> required tools.
>>
>> Signed-off-by: Terrence Xu
>> Signed-off-by: Benyu Xu
>> ---
>> tools/Makefile.sources | 1 +
>> tools/intel_gvtg_test.c | 355
>>
>> 2 files changed, 356 insertions(+)
>> create mode 100644 tools/intel_gvtg_test.c
>>
>> diff --git a/tools/Makefile.sources b/tools/Makefile.sources index
>> e2451ea..05ef0b7 100644
>> --- a/tools/Makefile.sources
>> +++ b/tools/Makefile.sources
>> @@ -30,6 +30,7 @@ tools_prog_lists = \
>> intel_stepping \
>> intel_watermark \
>> intel_gem_info \
>> +intel_gvtg_test \
>> $(NULL)
>
>Check the indentation of that line.
>
>Please add intel_gvtg_test to tools/.gitignore.
>
>
>>
>> dist_bin_SCRIPTS = intel_gpu_abrt
>> diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c new
>> file mode 100644 index 000..4c89800
>> --- /dev/null
>> +++ b/tools/intel_gvtg_test.c
>> @@ -0,0 +1,355 @@
>> +/*
>> + * Copyright 2016 Intel Corporation
>> + * Terrence Xu
>> + *
>> + * 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 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.
>> + */
>> +
>> +/*
>> + * This program is intended for testing of validate GVT-g virtual
>> +machine
>> + * creation of allow for testing of KVMGT / XenGT.
>> + *
>> + * TODO:
>> + * Enable more GVT-g related test cases.
>> + */
>> +#ifdef HAVE_CONFIG_H
>> +#include "config.h"
>> +#endif
>> +
>> +#include "igt.h"
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define RANDOM(x) (rand() % x)
>> +
>> +static uint32_t devid;
>> +
>> +static unsigned char mac_addr[17] = {'0', '0', ':', '0', '0', ':',
>> +'0', '0', ':', '0', '0', ':', '0', '0', ':', '0', '0'}; static
>> +char uuid[40]; static char guest_ip[32];
>> +
>> +static char qemu_path[PATH_MAX] = {0}; static char
>hda_path[PATH_MAX]
>> += {0}; static char bios_path[PATH_MAX] = {0};
>> +
>> +static int super_system(const char *cmd, char *retmsg, int msg_len) {
>> +FILE *fp;
>> +int res = -1;
>> +if (cmd == NULL || retmsg == NULL || msg_len < 0) {
>> +igt_info("Error: %s system paramer invalid!\n", __func__);
>
>paramer -> parameter
>
>
>> +return 1;
>> +}
>> +fp = popen(cmd, "r");
>> +if (fp == NULL) {
>> +perror("popen");
>> +igt_info("Error: %s popen error: %s\n", __func__, strerror(errno));
>> +return 2;
>> +} else {
>> +memset(retmsg, 0, msg_len);
>> +while (fgets(retmsg, msg_len, fp)) {
>> +;
>> +};
>
>
>Remove that semicolon after while's body's closing brace.
>
>
>> +res = pclose(fp);
>> +if (res == -1) {
>> +igt_info("Error:%s close popen file pointer fp error!\n",
>> __func__);
>> +return 3;
>> +}
>> +retmsg[strlen(retmsg) - 1] = '\0';
>> +return 0;
>> +}
>> +}
>> +
>> +static int check_platform(void)
>> +{
>> +devid = intel_get_pci_device
Re: [Intel-gfx] [PATCH 1/2] drm: Add a new connector atomic property for link status
On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote:
> From: Manasi Navare
>
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduced, but we can't reduce
> the link below the requirements of the mode. Black screen follows.
>
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would
> also conflict with the idea of making setcrtc asynchronous in the
> future, returning before the actual mode setting and link training.
>
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on
> practical not theoretical capabilities. However, the changes for link
> training are pretty drastic, all for the sake of error handling and
> DP compliance, when the most common happy day scenario is the current
> approach of link training at mode setting time, using the optimal
> parameters for the mode. It is also not certain all hardware could do
> this without the pipe on; not even all our hardware can do this. Some
> of this can be solved, but not trivially.
>
> Both of the above ideas also fail to address link degradation *during*
> operation.
>
> The solution is to add a new "link-status" connector property in order
> to address link training failure in a way that:
> a) changes the current happy day scenario as little as possible, to
> avoid regressions, b) can be implemented the same way by all drm
> drivers, c) is still opt-in for the drivers and userspace, and opting
> out doesn't regress the user experience, d) doesn't prevent drivers
> from implementing better or alternate approaches, possibly without
> userspace involvement. And, of course, handles all the issues presented.
> In the usual happy day scenario, this is always "good". If something
> fails during or after a mode set, the kernel driver can set the link
> status to "bad" and issue a hotplug uevent for userspace to have it
> re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> again. If the theoretical capabilities of the link can't be reached,
> the mode list is trimmed based on that.
>
> v7 by Jani:
> * Rebase, simplify set property while at it, checkpatch fix
> v6:
> * Fix a typo in kernel doc (Sean Paul)
> v5:
> * Clarify doc for silent rejection of atomic properties by driver (Daniel
> Vetter)
> v4:
> * Add comments in kernel-doc format (Daniel Vetter)
> * Update the kernel-doc for link-status (Sean Paul)
> v3:
> * Fixed a build error (Jani Saarinen)
> v2:
> * Removed connector->link_status (Daniel Vetter)
> * Set connector->state->link_status in
> drm_mode_connector_set_link_status_property
> (Daniel Vetter)
> * Set the connector_changed flag to true if connector->state->link_status
> changed.
> * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
>
> Reviewed-by: Sean Paul
> Reviewed-by: Daniel Vetter
> Reviewed-by: Jani Nikula
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Cc: Sean Paul
> Signed-off-by: Manasi Navare
> Signed-off-by: Jani Nikula
Applied to drm-misc-next. Should we apply the single i915 patch to
drm-misc too, or wait for backmerges? That would only be after -rc1 and
after Dave pull in the currently pending stuff ...
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_atomic.c| 16
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> drivers/gpu/drm/drm_connector.c | 52
> +
> include/drm/drm_connector.h | 19 ++
> include/drm/drm_mode_config.h | 5
> include/uapi/drm/drm_mode.h | 4 +++
> 6 files changed, 111 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ff38592134f5..91fd8a9a7526 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -,6 +,20 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->tv.saturation = val;
> } else if (property == config->tv_hue_property) {
> state->tv.hue = val;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request here,
> + * only hw issues can do that.
> + *
> + * For an atomic property the userspace doesn't need to be able
> + * to understand all the properties, but needs to be able to
> + * restore the state it wants on VT switch. So if the userspace
> + * tries to change the link_status from GOOD to BAD, driver
> +
Re: [Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3
On Wed, Feb 15, 2017 at 03:52:59PM +0200, Mika Kuoppala wrote:
> Certain Baytrails, namely the 4 cpu core variants, have been
> plaqued by spurious system hangs, mostly occurring with light loads.
>
> Multiple bisects by various people point to a commit which changes the
> reclocking strategy for Baytrail to follow its bigger brethen:
> commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail")
>
> There is also a review comment attached to this commit from Deepak S
> on avoiding punit access on Cherryview and thus it was excluded on
> common reclocking path. By taking the same approach and omitting
> the punit access by not tweaking the thresholds when the hardware
> has been asked to move into different frequency, considerable gains
> in stability have been observed.
>
> With J1900 box, light render/video load would end up in system hang
> in usually less than 12 hours. With this patch applied, the cumulative
> uptime has now been 34 days without issues. To provoke system hang,
> light loads on both render and bsd engines in parallel have been used:
> glxgears >/dev/null 2>/dev/null &
> mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4
>
> So far, author has not witnessed system hang with above load
> and this patch applied. Reports from the tenacious people at
> kernel bugzilla are also promising.
>
> Considering that the punit access frequency with this patch is
> considerably less, there is a possibility that this will push
> the, still unknown, root cause past the triggering point on most loads.
>
> But as we now can reliably reproduce the hang independently,
> we can reduce the pain that users are having and use a
> static thresholds until a root cause is found.
>
> v3: don't break debugfs and simplification (Chris Wilson)
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
> Cc: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Len Brown
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: frit...@xbmc.org
> Cc: m...@iki.fi
> Cc: Ezequiel Garcia
> CC: Michal Feix
> Cc: Hans de Goede
> Cc: Deepak S
> Cc: Jarkko Nikula
> Cc: # v4.2+
> Acked-by: Daniel Vetter
> Signed-off-by: Mika Kuoppala
Had a couple of weekends to try and find an alternative explanation
(a root cause for the hangs would be nice!). If it is just the writes to
the RPS registers, are we safe on resume (etc)?
However, I've drawn a blank on explaining what the hw is doing wrong
(but found a couple of bugs in the byt manual RPS evaluation which
desire review), so
Acked-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dim: Handle / in branch names in rebuild-tip
My normalization hack fell over a topic branch :( Signed-off-by: Daniel Vetter --- dim | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dim b/dim index 457bf93d8a11..6d3b9734b348 100755 --- a/dim +++ b/dim @@ -502,7 +502,7 @@ function dim_rebuild_tip git merge --rerere-autoupdate --no-commit $sha1 >& /dev/null || true # normalize conflict markers if git grep -l '^>>> ' &> /dev/null ; then - git grep -l '^>>> ' | xargs sed -e "s/^>>> .*$/>>> $repo\/$branch/" -i + git grep -l '^>>> ' | xargs sed -e "s|^>>> .*$|>>> $repo\/$branch|" -i fi if [ -f $fixup_file ] ; then -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/8] lib: Define a common bit operations library
On Thu, Feb 09, 2017 at 09:34:49AM +0200, Joonas Lahtinen wrote: > On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote: > > Bring the test/set/clear bit functions we have into a single place. > > > > Signed-off-by: Michel Thierry > > Reviewed-by: Joonas Lahtinen Can we please have docs for this new library? Thanks, Danel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] i2c: designware: Never suspend i2c-busses used for accessing the system PMIC
Currently we are already setting a pm_runtime_disabled flag and disabling
runtime-pm for i2c-busses used for accessing the system PMIC on x86.
But this is not enough, there are ACPI opregions which may want to access
the PMIC during late-suspend and early-resume, so we need to completely
disable pm to be safe.
This commit renames the flag from pm_runtime_disabled to pm_disabled and
adds the following new behavior if the flag is set:
1) Call dev_pm_syscore_device(dev, true) which disables normal suspend /
resume and remove the pm_runtime_disabled check from dw_i2c_plat_resume
since that will now never get called. This fixes suspend_late handlers
which use ACPI PMIC opregions causing errors like these:
PM: Suspending system (freeze)
PM: suspend of devices complete after 1127.751 msecs
i2c_designware 808622C1:06: timeout waiting for bus ready
ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion]
acpi 80860F14:02: Failed to change power state to D3hot
PM: late suspend of devices failed
2) Set IRQF_NO_SUSPEND irq flag. This fixes resume_early handlers which
handlers which use ACPI PMIC opregions causing errors like these:
PM: resume from suspend-to-idle
i2c_designware 808622C1:06: controller timed out
ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion]
Signed-off-by: Hans de Goede
---
drivers/i2c/busses/i2c-designware-baytrail.c | 2 +-
drivers/i2c/busses/i2c-designware-core.c | 10 --
drivers/i2c/busses/i2c-designware-core.h | 4 ++--
drivers/i2c/busses/i2c-designware-platdrv.c | 10 --
4 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c
b/drivers/i2c/busses/i2c-designware-baytrail.c
index 1749a0f..b8cc226 100644
--- a/drivers/i2c/busses/i2c-designware-baytrail.c
+++ b/drivers/i2c/busses/i2c-designware-baytrail.c
@@ -170,7 +170,7 @@ int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
dev_info(dev->dev, "I2C bus managed by PUNIT\n");
dev->acquire_lock = baytrail_i2c_acquire;
dev->release_lock = baytrail_i2c_release;
- dev->pm_runtime_disabled = true;
+ dev->pm_disabled = true;
pm_qos_add_request(&dev->pm_qos, PM_QOS_CPU_DMA_LATENCY,
PM_QOS_DEFAULT_VALUE);
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 8c3ba42..3d86059 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -962,6 +962,7 @@ EXPORT_SYMBOL_GPL(i2c_dw_read_comp_param);
int i2c_dw_probe(struct dw_i2c_dev *dev)
{
struct i2c_adapter *adap = &dev->adapter;
+ unsigned long irq_flags;
int r;
u32 reg;
@@ -998,9 +999,14 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
adap->dev.parent = dev->dev;
i2c_set_adapdata(adap, dev);
+ if (dev->pm_disabled) {
+ dev_pm_syscore_device(dev->dev, true);
+ irq_flags = IRQF_NO_SUSPEND;
+ } else
+ irq_flags = IRQF_SHARED | IRQF_COND_SUSPEND;
+
i2c_dw_disable_int(dev);
- r = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr,
-IRQF_SHARED | IRQF_COND_SUSPEND,
+ r = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr, irq_flags,
dev_name(dev->dev), dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i: %d\n",
diff --git a/drivers/i2c/busses/i2c-designware-core.h
b/drivers/i2c/busses/i2c-designware-core.h
index a8e74ca..a4ac473 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -79,7 +79,7 @@
* @pm_qos: pm_qos_request used while holding a hardware lock on the bus
* @acquire_lock: function to acquire a hardware lock on the bus
* @release_lock: function to release a hardware lock on the bus
- * @pm_runtime_disabled: true if pm runtime is disabled
+ * @pm_disabled: true if power-management should be disabled for this i2c-bus
*
* HCNT and LCNT parameters can be used if the platform knows more accurate
* values than the one computed based only on the input clock frequency.
@@ -127,7 +127,7 @@ struct dw_i2c_dev {
struct pm_qos_request pm_qos;
int (*acquire_lock)(struct dw_i2c_dev *dev);
void(*release_lock)(struct dw_i2c_dev *dev);
- boolpm_runtime_disabled;
+ boolpm_disabled;
booldynamic_tar_update_enabled;
};
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index df0ff7d..8ed96dd 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -276,7 +276,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
[Intel-gfx] [PATCH 0/2] i2c: designware: PM fixes for i2c-bus used by system PMIC
Hi All, Note these 2 patches apply on top of my previous i2c-designware patches. Daniel Vetter should merge these soon (together with the dependent i915 patches) and then provide a stable branch to merge into the i2c subsys next branch. These will not apply cleanly without these patches in places, but otherwise they are pretty much stand alone and ready for review (and merging once the other patches are in place). Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] i2c: designware: Disable pm for PMIC i2c-bus even if there is no _SEM method
Cherrytrail devices use the dw i2c-bus with uid 7 to access their PMIC.
Even if the i2c-bus to the PMIC is not shared with the SoC's P-Unit
and i2c-designware-baytrail.c thus does not set the pm_disabled flag,
we still need to disable pm so that ACPI PMIC opregions can access the
PMIC during late-suspend and early-resume.
This fixes errors like these blocking suspend:
i2c_designware 808622C1:06: timeout waiting for bus ready
ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion]
acpi 80860F14:02: Failed to change power state to D3hot
PM: late suspend of devices failed
Signed-off-by: Hans de Goede
---
drivers/i2c/busses/i2c-designware-platdrv.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 8ed96dd..08d609e 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -94,7 +94,10 @@ static void dw_i2c_acpi_params(struct platform_device *pdev,
char method[],
static int dw_i2c_acpi_configure(struct platform_device *pdev)
{
struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
+ acpi_handle handle = ACPI_HANDLE(&pdev->dev);
const struct acpi_device_id *id;
+ struct acpi_device *adev;
+ const char *uid;
dev->adapter.nr = -1;
dev->tx_fifo_depth = 32;
@@ -114,6 +117,18 @@ static int dw_i2c_acpi_configure(struct platform_device
*pdev)
if (id && id->driver_data)
dev->flags |= (u32)id->driver_data;
+ if (acpi_bus_get_device(handle, &adev))
+ return -ENODEV;
+
+ /*
+* Cherrytrail I2C7 gets used for the PMIC which gets accessed
+* through ACPI opregions during late suspend / early resume
+* disable pm for it.
+*/
+ uid = adev->pnp.unique_id;
+ if ((dev->flags & MODEL_CHERRYTRAIL) && !strcmp(uid, "7"))
+ dev->pm_disabled = true;
+
return 0;
}
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating
On 22/02/2017 08:44, Chris Wilson wrote:
On Wed, Feb 22, 2017 at 08:29:06AM +, Tvrtko Ursulin wrote:
On 21/02/2017 15:01, Joonas Lahtinen wrote:
On pe, 2017-02-17 at 15:10 +, Chris Wilson wrote:
The object already stores (computed on the fly) the index to dma address
so use it instead of reallocating a large temporary array every time we
bind a rotated framebuffer.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
+rotate_pages(struct drm_i915_gem_object *obj,
+const struct intel_rotation_plane_info *p,
struct sg_table *st, struct scatterlist *sg)
{
unsigned int column, row;
- unsigned int src_idx;
- for (column = 0; column < width; column++) {
- src_idx = stride * (height - 1) + column;
- for (row = 0; row < height; row++) {
- st->nents++;
+ for (column = 0; column < p->width; column++) {
+ unsigned long src_idx =
+ p->stride * (p->height - 1) + column + p->offset;
+ for (row = 0; row < p->height; row++) {
+ struct scatterlist *src;
+ unsigned int n;
+
+ src = i915_gem_object_get_sg(obj, src_idx, &n);
i915_gem_object_get_sg has variable names obj, n, *offset, so I'd be
little concerned of sidetracking reader. Rename n into offset?
Or use i915_gem_object_get_dma_address in the sg_dma_adress_assignment
directly.
+ src_idx -= p->stride;
+
/* We don't need the pages, but need to initialize
* the entries so the sg list can be happily traversed.
* The only thing we need are DMA addresses.
*/
sg_set_page(sg, NULL, PAGE_SIZE, 0);
- sg_dma_address(sg) = in[offset + src_idx];
+ sg_dma_address(sg) = sg_dma_address(src) + n*PAGE_SIZE;
sg_dma_len(sg) = PAGE_SIZE;
- sg = sg_next(sg);
- src_idx -= stride;
I'm not sure why moving this line, might as well hoist all these to the
for() line.
+ sg = __sg_next(sg);
+
+ st->nents++;
}
}
@@ -3074,62 +3079,30 @@ static noinline struct sg_table *
intel_rotate_pages(struct intel_rotation_info *rot_info,
struct drm_i915_gem_object *obj)
{
- const unsigned long n_pages = obj->base.size / PAGE_SIZE;
- unsigned int size = intel_rotation_info_size(rot_info);
- struct sgt_iter sgt_iter;
- dma_addr_t dma_addr;
- unsigned long i;
- dma_addr_t *page_addr_list;
- struct sg_table *st;
+ const unsigned int size = intel_rotation_info_size(rot_info);
This is only used once, just inline it.
Reviewed-by: Joonas Lahtinen
Could use an A-b from Tvrtko.
I did not like it in another thread, well, better say I was
concerned about the increased memory use by the radix tree which
would then stick around for the obj->pages lifetime (long time for a
framebuffer I thought). While the temporary array allocations here
are not that big and very temporary.
I guess someone needs to bite the bullet and try and figure out how
exactly big is the radix tree for some mixes of more or less
coalesced sg entries.
I also think that's an argument for improving the general cache rather
than arguing against using it.
Well I wasn't concerned about the cache per se, but about whether it is
completely appropriate (best choice) to use it in this particular case.
Because as I said before, for 1920x1080x32 we are talking about a 16KiB
extremely short lived temporary allocation, vs the similar size for the
sg radix cache. But radix cache sticks around the the lifetime of
obj->mm.pages and it wouldn't otherwise be there since AFAICS in
practice no one really touches frame buffers in a way to trigger its
creation.
Those amounts of memory are not a concern, but again, is the
simplification of the code worth the conceptual downsides mentioned
above? Even if we considered 4K frame buffers, when both allocations go
to ~64KiB, would that change anything? I am not sure, probably not for me.
So I am still unsure that we should go with this change.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Report both waiters and success from intel_engine_wakeup()
On 24/02/2017 18:01, Chris Wilson wrote:
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in the fake_irq path, we are using the return value
as a check as to whether there are any waiters, and so we may
incorrectly stop the fake-irq if that waiter was currently running.
To handle the two different needs, return both bits of information!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 28 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 26 +++---
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 027c93e34c97..64e1b0c2d8b6 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,6 +26,32 @@
#include "i915_drv.h"
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
How come you decided to un-inline it? Changes shouldn't have made a big
difference to its size I would have thought.
+{
+ unsigned int ret = 0;
Optional bikeshed - maybe call it res or something, since ret is usually
used for < 0 || 0.
+
+ /* Note that for this not to dangerously chase a dangling pointer,
+* we must hold the rcu_read_lock here.
+*
+* Also note that tsk is likely to be in !TASK_RUNNING state so an
+* early test for tsk->state != TASK_RUNNING before wake_up_process()
+* is unlikely to be beneficial.
+*/
+ if (intel_engine_has_waiter(engine)) {
+ struct task_struct *tsk;
+
+ ret = ENGINE_WAKEUP_WAITER;
+
+ rcu_read_lock();
+ tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
+ if (tsk && !wake_up_process(tsk))
+ ret |= ENGINE_WAKEUP_ACTIVE;
+ rcu_read_unlock();
+ }
+
+ return ret;
+}
+
static unsigned long wait_timeout(void)
{
return round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES);
@@ -49,7 +75,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
* to process the pending interrupt (e.g, low priority task on a loaded
* system) and wait until it sleeps before declaring a missed interrupt.
*/
- if (!intel_engine_wakeup(engine)) {
+ if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
mod_timer(&b->hangcheck, wait_timeout());
return;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0f29e07a9581..7d753dc1b89d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -642,29 +642,9 @@ static inline bool intel_engine_has_waiter(const struct
intel_engine_cs *engine)
return rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh);
}
-static inline bool intel_engine_wakeup(const struct intel_engine_cs *engine)
-{
- bool wakeup = false;
-
- /* Note that for this not to dangerously chase a dangling pointer,
-* we must hold the rcu_read_lock here.
-*
-* Also note that tsk is likely to be in !TASK_RUNNING state so an
-* early test for tsk->state != TASK_RUNNING before wake_up_process()
-* is unlikely to be beneficial.
-*/
- if (intel_engine_has_waiter(engine)) {
- struct task_struct *tsk;
-
- rcu_read_lock();
- tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
- if (tsk)
- wakeup = wake_up_process(tsk);
- rcu_read_unlock();
- }
-
- return wakeup;
-}
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine);
+#define ENGINE_WAKEUP_WAITER BIT(0)
+#define ENGINE_WAKEUP_ACTIVE BIT(1)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Signal first fence from irq handler if complete
On 25/02/2017 10:05, Chris Wilson wrote:
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.
v2: No need for early exit in irq handler - it breaks the flow between
patches and prevents the tracepoint
v3: Restore rcu hold across irq signaling of request
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 13 ++--
drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
drivers/gpu/drm/i915/i915_gem_request.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 36 +---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 32 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +++
6 files changed, 54 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 56caab35f216..16c5e7a37eba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4063,9 +4063,9 @@ __i915_request_irq_complete(const struct
drm_i915_gem_request *req)
* is woken.
*/
if (engine->irq_seqno_barrier &&
- rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted)) {
- struct task_struct *tsk;
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ unsigned long flags;
/* The ordering of irq_posted versus applying the barrier
* is crucial. The clearing of the current irq_posted must
@@ -4087,17 +4087,16 @@ __i915_request_irq_complete(const struct
drm_i915_gem_request *req)
* the seqno before we believe it coherent since they see
* irq_posted == false but we are still running).
*/
- rcu_read_lock();
- tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
- if (tsk && tsk != current)
+ spin_lock_irqsave(&b->lock, flags);
+ if (b->first_wait && b->first_wait->tsk != current)
/* Note that if the bottom-half is changed as we
* are sending the wake-up, the new bottom-half will
* be woken by whomever made the change. We only have
* to worry about when we steal the irq-posted for
* ourself.
*/
- wake_up_process(tsk);
- rcu_read_unlock();
+ wake_up_process(b->first_wait->tsk);
+ spin_unlock_irqrestore(&b->lock, flags);
if (__i915_gem_request_completed(req, seqno))
return true;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index fbfeb5f8d069..77c3ee7a3fd0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1083,7 +1083,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
if (flags & I915_WAIT_LOCKED)
add_wait_queue(errq, &reset);
- intel_wait_init(&wait);
+ intel_wait_init(&wait, req);
restart:
do {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
b/drivers/gpu/drm/i915/i915_gem_request.h
index 5f73d8c0a38a..0efee879df23 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -32,10 +32,12 @@
struct drm_file;
struct drm_i915_gem_object;
+struct drm_i915_gem_request;
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
+ struct drm_i915_gem_request *request;
u32 seqno;
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc70e2c451b2..bc520ee8d6fe 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1033,12 +1033,42 @@ static void ironlake_rps_change_irq_handler(struct
drm_i915_private *dev_priv)
static void notify_ring(struct intel_engine_cs *engine)
{
- bool waiters;
+ struct drm_i915_gem_request *rq = NULL;
+ struct intel_wait *wait;
atomic_inc(&engine->irq_count);
set_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
- waiters = intel_engine_wakeup(engine);
- trace_intel_engine_notify(engine, waiters);
+
+ rcu_r
Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating
On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote: > > On 22/02/2017 08:44, Chris Wilson wrote: > >I also think that's an argument for improving the general cache rather > >than arguing against using it. > > Well I wasn't concerned about the cache per se, but about whether it > is completely appropriate (best choice) to use it in this particular > case. > > Because as I said before, for 1920x1080x32 we are talking about a > 16KiB extremely short lived temporary allocation, vs the similar > size for the sg radix cache. But radix cache sticks around the the > lifetime of obj->mm.pages and it wouldn't otherwise be there since > AFAICS in practice no one really touches frame buffers in a way to > trigger its creation. > > Those amounts of memory are not a concern, but again, is the > simplification of the code worth the conceptual downsides mentioned > above? Even if we considered 4K frame buffers, when both allocations > go to ~64KiB, would that change anything? I am not sure, probably > not for me. > > So I am still unsure that we should go with this change. Again, the complaint you have here are general concerns about caching the mapping. Avoiding using the cache instead of improving the cache seems the wrong approach. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating
On 27/02/2017 10:06, Chris Wilson wrote: On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote: On 22/02/2017 08:44, Chris Wilson wrote: I also think that's an argument for improving the general cache rather than arguing against using it. Well I wasn't concerned about the cache per se, but about whether it is completely appropriate (best choice) to use it in this particular case. Because as I said before, for 1920x1080x32 we are talking about a 16KiB extremely short lived temporary allocation, vs the similar size for the sg radix cache. But radix cache sticks around the the lifetime of obj->mm.pages and it wouldn't otherwise be there since AFAICS in practice no one really touches frame buffers in a way to trigger its creation. Those amounts of memory are not a concern, but again, is the simplification of the code worth the conceptual downsides mentioned above? Even if we considered 4K frame buffers, when both allocations go to ~64KiB, would that change anything? I am not sure, probably not for me. So I am still unsure that we should go with this change. Again, the complaint you have here are general concerns about caching the mapping. Avoiding using the cache instead of improving the cache seems the wrong approach. Depends what kind of improvments to the cache you have in mind. If you are thinking about size then I disagree, I think it is efficient enough already. But if you are thinking about the lifetime management then it is obvious from all that I have written so far that I would agree with that. Since the core of my "complaint" is the lifetime mismatch, and not the size. For lifetime I am not sure what you could do. Exposing the size of it, with maybe some other bits attached the the object, to the shrinker I think doesn't make much sense since the sizes are so small compared to the backing store sizes. Perhaps you could add an explicit reset of the cache after the rotation is done with it, but then the only remaining benefit will be avoiding greater than zero order allocations. I say the only one.. it would still be a good one. Just have no idea if this level of cache usage would satisfy you! Perhaps you could say what kind of optimisation you have in mind to save me guessing? :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/5] drm/i915: Defer enabling hangcheck to the first fake breadcrumb interrupt
On 24/02/2017 18:01, Chris Wilson wrote:
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the breadcrumbs after a reset simpler in the next patch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 36
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index ba5f72fb4890..d7511e89c8ab 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -75,17 +75,6 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
set_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings);
mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
-
- /* Ensure that even if the GPU hangs, we get woken up.
-*
-* However, note that if no one is waiting, we never notice
-* a gpu hang. Eventually, we will have to wait for a resource
-* held by the GPU and so trigger a hangcheck. In the most
-* pathological case, this will be upon memory starvation! To
-* prevent this, we also queue the hangcheck from the retire
-* worker.
-*/
- i915_queue_hangcheck(engine->i915);
}
static void intel_breadcrumbs_fake_irq(unsigned long data)
@@ -99,8 +88,21 @@ static void intel_breadcrumbs_fake_irq(unsigned long data)
* every jiffie in order to kick the oldest waiter to do the
* coherent seqno check.
*/
- if (intel_engine_wakeup(engine))
- mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
+ if (!intel_engine_wakeup(engine))
+ return;
+
+ mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
+
+ /* Ensure that even if the GPU hangs, we get woken up.
+*
+* However, note that if no one is waiting, we never notice
+* a gpu hang. Eventually, we will have to wait for a resource
+* held by the GPU and so trigger a hangcheck. In the most
+* pathological case, this will be upon memory starvation! To
+* prevent this, we also queue the hangcheck from the retire
+* worker.
+*/
+ i915_queue_hangcheck(engine->i915);
}
static void irq_enable(struct intel_engine_cs *engine)
@@ -179,13 +181,11 @@ static void __intel_breadcrumbs_enable_irq(struct
intel_breadcrumbs *b)
b->irq_enabled = true;
}
- if (!b->irq_enabled || use_fake_irq(b)) {
+ /* Ensure we never sleep indefinitely */
+ if (!b->irq_enabled || use_fake_irq(b))
mod_timer(&b->fake_irq, jiffies + 1);
- i915_queue_hangcheck(i915);
- } else {
- /* Ensure we never sleep indefinitely */
+ else
mod_timer(&b->hangcheck, wait_timeout());
- }
}
static void __intel_breadcrumbs_disable_irq(struct intel_breadcrumbs *b)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating
On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote: > > On 27/02/2017 10:06, Chris Wilson wrote: > >On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote: > >> > >>On 22/02/2017 08:44, Chris Wilson wrote: > >>>I also think that's an argument for improving the general cache rather > >>>than arguing against using it. > >> > >>Well I wasn't concerned about the cache per se, but about whether it > >>is completely appropriate (best choice) to use it in this particular > >>case. > >> > >>Because as I said before, for 1920x1080x32 we are talking about a > >>16KiB extremely short lived temporary allocation, vs the similar > >>size for the sg radix cache. But radix cache sticks around the the > >>lifetime of obj->mm.pages and it wouldn't otherwise be there since > >>AFAICS in practice no one really touches frame buffers in a way to > >>trigger its creation. > >> > >>Those amounts of memory are not a concern, but again, is the > >>simplification of the code worth the conceptual downsides mentioned > >>above? Even if we considered 4K frame buffers, when both allocations > >>go to ~64KiB, would that change anything? I am not sure, probably > >>not for me. > >> > >>So I am still unsure that we should go with this change. > > > >Again, the complaint you have here are general concerns about caching > >the mapping. Avoiding using the cache instead of improving the cache > >seems the wrong approach. > > Depends what kind of improvments to the cache you have in mind. If > you are thinking about size then I disagree, I think it is efficient > enough already. But if you are thinking about the lifetime > management then it is obvious from all that I have written so far > that I would agree with that. Since the core of my "complaint" is > the lifetime mismatch, and not the size. > > For lifetime I am not sure what you could do. Exposing the size of > it, with maybe some other bits attached the the object, to the > shrinker I think doesn't make much sense since the sizes are so > small compared to the backing store sizes. > > Perhaps you could add an explicit reset of the cache after the > rotation is done with it, but then the only remaining benefit will > be avoiding greater than zero order allocations. I say the only > one.. it would still be a good one. Just have no idea if this level > of cache usage would satisfy you! > > Perhaps you could say what kind of optimisation you have in mind to > save me guessing? :) I was thinking you would like an inactivity timer. Or we could have a separate shrinker, as that's the principal cache management system. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dsi: VLV/CHT Only wait for LP00 on MIPI PORT A
On some devices only MIPI PORT C is used, in this case checking the
MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
on VLV/CHT) will result in false positive "DSI LP not going Low" errors
as this checks the PORT A clk status.
In case both ports are used we have already checked the AFE_LATCHOUT
bit when going through the for_each_dsi_port() loop for PORT A and
checking the same bit again for PORT C is a no-op.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97061
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 1fcce2c..185b8eb 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -458,10 +458,12 @@ static void intel_dsi_clear_device_ready(struct
intel_encoder *encoder)
ULPS_STATE_ENTER);
usleep_range(2000, 2500);
- /* Wait till Clock lanes are in LP-00 state for MIPI Port A
-* only. MIPI Port C has no similar bit for checking
+ /*
+* On VLV/CHV, wait till Clock lanes are in LP-00 state for MIPI
+* Port A only. MIPI Port C has no similar bit for checking.
*/
- if (intel_wait_for_register(dev_priv,
+ if ((IS_GEN9_LP(dev_priv) || port == PORT_A) &&
+ intel_wait_for_register(dev_priv,
port_ctrl, AFE_LATCHOUT, 0,
30))
DRM_ERROR("DSI LP not going Low\n");
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i2c: designware: Never suspend i2c-busses used for accessing the system PMIC
On Mon, 27 Feb 2017 10:38:29 +0100,
Hans de Goede wrote:
>
> index a8e74ca..a4ac473 100644
> --- a/drivers/i2c/busses/i2c-designware-core.h
> +++ b/drivers/i2c/busses/i2c-designware-core.h
> @@ -79,7 +79,7 @@
> * @pm_qos: pm_qos_request used while holding a hardware lock on the bus
> * @acquire_lock: function to acquire a hardware lock on the bus
> * @release_lock: function to release a hardware lock on the bus
> - * @pm_runtime_disabled: true if pm runtime is disabled
> + * @pm_disabled: true if power-management should be disabled for this i2c-bus
> *
> * HCNT and LCNT parameters can be used if the platform knows more accurate
> * values than the one computed based only on the input clock frequency.
> @@ -127,7 +127,7 @@ struct dw_i2c_dev {
> struct pm_qos_request pm_qos;
> int (*acquire_lock)(struct dw_i2c_dev *dev);
> void(*release_lock)(struct dw_i2c_dev *dev);
> - boolpm_runtime_disabled;
> + boolpm_disabled;
> booldynamic_tar_update_enabled;
I couldn't find this dynamic_tar_update_enabled field in your previous
patchset. What am I missing?
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Dealing with 90° rotated display ?
== Series Details == Series: i915: Dealing with 90° rotated display ? URL : https://patchwork.freedesktop.org/series/20254/ State : success == Summary == Series 20254v1 i915: Dealing with 90° rotated display ? https://patchwork.freedesktop.org/api/1.0/series/20254/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC integration manifest 5ce5568 i915: Dealing with 90° rotated display ? == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3975/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915: Delay disabling the user interrupt for breadcrumbs
On 24/02/2017 18:01, Chris Wilson wrote:
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.
v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 137 ---
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +-
4 files changed, 97 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01dbba3813c7..0ad080984877 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2988,8 +2988,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wait_for(intel_execlists_idle(dev_priv), 10))
DRM_ERROR("Timeout waiting for engines to idle\n");
- for_each_engine(engine, dev_priv, id)
+ for_each_engine(engine, dev_priv, id) {
+ intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(&engine->batch_pool);
+ }
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7607aba35f26..ba0bb33e12ed 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1058,6 +1058,8 @@ static void notify_ring(struct intel_engine_cs *engine)
rq = wait->request;
wake_up_process(wait->tsk);
+ } else {
+ __intel_engine_disarm_breadcrumbs(engine);
}
spin_unlock(&engine->breadcrumbs.lock);
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index d7511e89c8ab..8e83be343057 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -36,8 +36,8 @@ unsigned int intel_engine_wakeup(struct intel_engine_cs
*engine)
wait = engine->breadcrumbs.first_wait;
if (wait) {
ret = ENGINE_WAKEUP_WAITER;
- if (!wake_up_process(wait->tsk))
- ret |= ENGINE_WAKEUP_ACTIVE;
+ if (wake_up_process(wait->tsk))
+ ret |= ENGINE_WAKEUP_ASLEEP;
Why did you want to reverse the bit and all?
}
spin_unlock_irqrestore(&engine->breadcrumbs.lock, flags);
@@ -54,7 +54,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct intel_breadcrumbs *b = &engine->breadcrumbs;
- if (!b->irq_enabled)
+ if (!b->irq_armed)
return;
if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
@@ -67,7 +67,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
* to process the pending interrupt (e.g, low priority task on a loaded
* system) and wait until it sleeps before declaring a missed interrupt.
*/
- if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
+ if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
mod_timer(&b->hangcheck, wait_timeout());
return;
}
@@ -80,6 +80,9 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
static void intel_breadcrumbs_fake_irq(unsigned long data)
{
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ struct intel_wait *wait;
+ unsigned long flags;
/*
* The timer persists in case we cannot enable interrupts,
@@ -88,10 +91,18 @@ static void intel_breadcrumbs_fake_irq(unsigned long data)
* every jiffie in order to kick the oldest waiter to do the
* coherent seqno check.
*/
- if (!intel_engine_wakeup(engine))
+
+ spin_lock_irqsave(&b->lock, flags);
+ wait = b->first_wait;
+ if (wait)
+ wake_up_process(wait->tsk);
+ else
+ __intel_engine_di
Re: [Intel-gfx] [PATCH 1/2] i2c: designware: Never suspend i2c-busses used for accessing the system PMIC
Hi,
On 27-02-17 11:25, Takashi Iwai wrote:
On Mon, 27 Feb 2017 10:38:29 +0100,
Hans de Goede wrote:
index a8e74ca..a4ac473 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -79,7 +79,7 @@
* @pm_qos: pm_qos_request used while holding a hardware lock on the bus
* @acquire_lock: function to acquire a hardware lock on the bus
* @release_lock: function to release a hardware lock on the bus
- * @pm_runtime_disabled: true if pm runtime is disabled
+ * @pm_disabled: true if power-management should be disabled for this i2c-bus
*
* HCNT and LCNT parameters can be used if the platform knows more accurate
* values than the one computed based only on the input clock frequency.
@@ -127,7 +127,7 @@ struct dw_i2c_dev {
struct pm_qos_request pm_qos;
int (*acquire_lock)(struct dw_i2c_dev *dev);
void(*release_lock)(struct dw_i2c_dev *dev);
- boolpm_runtime_disabled;
+ boolpm_disabled;
booldynamic_tar_update_enabled;
I couldn't find this dynamic_tar_update_enabled field in your previous
patchset. What am I missing?
My testing branch for all this stuff is based on intel-drm-next-queued, which
is still based on 4.10-rc$, and it seems that 4.11-rc1 will have this:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=12688dc21f71f4dcc9e2b8b5556b0c6cc8df1491
Removing the dynamic_tar_update_enabled member from that struct.
I will send out a new rebased version when 4.11-rc1 gets merged in
intel-drm-next-queued.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915: Simplify intel_engine_wakeup()
On 24/02/2017 18:01, Chris Wilson wrote:
Now the only use of the return value is ask whether or not we actually
woke a process up. With a single condition to report, we can go back to
using a boolean.
Argh! :) I guess it depends on whether you keep or not the open coded
intel_engine_wakeup's in the previous patch.
Regards,
Tvrtko
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 13 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +---
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 8e83be343057..84034ee827af 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,19 +26,16 @@
#include "i915_drv.h"
-unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+bool intel_engine_wakeup(struct intel_engine_cs *engine)
{
struct intel_wait *wait;
unsigned long flags;
- unsigned int ret = 0;
+ bool ret = false;
spin_lock_irqsave(&engine->breadcrumbs.lock, flags);
wait = engine->breadcrumbs.first_wait;
- if (wait) {
- ret = ENGINE_WAKEUP_WAITER;
- if (wake_up_process(wait->tsk))
- ret |= ENGINE_WAKEUP_ASLEEP;
- }
+ if (wait && wake_up_process(wait->tsk))
+ ret = true;
spin_unlock_irqrestore(&engine->breadcrumbs.lock, flags);
return ret;
@@ -67,7 +64,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
* to process the pending interrupt (e.g, low priority task on a loaded
* system) and wait until it sleeps before declaring a missed interrupt.
*/
- if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
+ if (!intel_engine_wakeup(engine)) {
mod_timer(&b->hangcheck, wait_timeout());
return;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3dd6eee4a08b..007628231ec3 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -642,9 +642,7 @@ static inline bool intel_engine_has_waiter(const struct
intel_engine_cs *engine)
return READ_ONCE(engine->breadcrumbs.first_wait);
}
-unsigned int intel_engine_wakeup(struct intel_engine_cs *engine);
-#define ENGINE_WAKEUP_WAITER BIT(0)
-#define ENGINE_WAKEUP_ASLEEP BIT(1)
+bool intel_engine_wakeup(struct intel_engine_cs *engine);
void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Report both waiters and success from intel_engine_wakeup()
On Mon, Feb 27, 2017 at 10:03:32AM +, Tvrtko Ursulin wrote:
>
> On 24/02/2017 18:01, Chris Wilson wrote:
> >The two users of the return value from intel_engine_wakeup() are
> >expecting different results. In the breadcrumbs hangcheck, we are using
> >it to determine whether wake_up_process() detected the waiter was
> >currently running (and if so we presume that it hasn't yet missed the
> >interrupt). However, in the fake_irq path, we are using the return value
> >as a check as to whether there are any waiters, and so we may
> >incorrectly stop the fake-irq if that waiter was currently running.
> >
> >To handle the two different needs, return both bits of information!
> >
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
> >Cc: Mika Kuoppala
> >---
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 28 +++-
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 26 +++---
> > 2 files changed, 30 insertions(+), 24 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >index 027c93e34c97..64e1b0c2d8b6 100644
> >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >@@ -26,6 +26,32 @@
> >
> > #include "i915_drv.h"
> >
> >+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
>
> How come you decided to un-inline it? Changes shouldn't have made a
> big difference to its size I would have thought.
Mainly in the later patches we move this away from any important paths.
> >+{
> >+unsigned int ret = 0;
>
> Optional bikeshed - maybe call it res or something, since ret is
> usually used for < 0 || 0.
Been adopting int err for those, but result is better than ret.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i2c: designware: Never suspend i2c-busses used for accessing the system PMIC
On Mon, Feb 27, 2017 at 11:25:01AM +0100, Takashi Iwai wrote:
> On Mon, 27 Feb 2017 10:38:29 +0100,
> Hans de Goede wrote:
> >
> > index a8e74ca..a4ac473 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.h
> > +++ b/drivers/i2c/busses/i2c-designware-core.h
> > @@ -79,7 +79,7 @@
> > * @pm_qos: pm_qos_request used while holding a hardware lock on the bus
> > * @acquire_lock: function to acquire a hardware lock on the bus
> > * @release_lock: function to release a hardware lock on the bus
> > - * @pm_runtime_disabled: true if pm runtime is disabled
> > + * @pm_disabled: true if power-management should be disabled for this
> > i2c-bus
> > *
> > * HCNT and LCNT parameters can be used if the platform knows more accurate
> > * values than the one computed based only on the input clock frequency.
> > @@ -127,7 +127,7 @@ struct dw_i2c_dev {
> > struct pm_qos_request pm_qos;
> > int (*acquire_lock)(struct dw_i2c_dev *dev);
> > void(*release_lock)(struct dw_i2c_dev *dev);
> > - boolpm_runtime_disabled;
> > + boolpm_disabled;
> > booldynamic_tar_update_enabled;
>
> I couldn't find this dynamic_tar_update_enabled field in your previous
> patchset. What am I missing?
It got reverted with 12688dc21f71f4 ("Revert "i2c: designware: detect
when dynamic tar update is possible"") around 4.10-rc7 time.
I also wondered that Hans didn't get a merge conflict somewhere.
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Add missing SKL ID
Michał Winiarski writes: > Used by production device: > Intel(R) Iris(TM) Graphics P555 > > Cc: Mika Kuoppala > Cc: Rodrigo Vivi > Signed-off-by: Michał Winiarski Reviewed-by: Mika Kuoppala > --- > include/drm/i915_pciids.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index a1dd21d..466c715 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -265,7 +265,8 @@ > INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \ > INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ > INTEL_VGA_DEVICE(0x1927, info), /* ULT GT3 */ \ > - INTEL_VGA_DEVICE(0x192B, info) /* Halo GT3 */ \ > + INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \ > + INTEL_VGA_DEVICE(0x192D, info) /* SRV GT3 */ > > #define INTEL_SKL_GT4_IDS(info) \ > INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \ > -- > 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only unwind the local pgtable layer if empty
== Series Details == Series: drm/i915: Only unwind the local pgtable layer if empty URL : https://patchwork.freedesktop.org/series/20256/ State : success == Summary == Series 20256v1 drm/i915: Only unwind the local pgtable layer if empty https://patchwork.freedesktop.org/api/1.0/series/20256/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC integration manifest 25b11d9 drm/i915: Only unwind the local pgtable layer if empty == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3976/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915: Delay disabling the user interrupt for breadcrumbs
On Mon, Feb 27, 2017 at 10:31:36AM +, Tvrtko Ursulin wrote:
>
> On 24/02/2017 18:01, Chris Wilson wrote:
> >A significant cost in setting up a wait is the overhead of enabling the
> >interrupt. As we disable the interrupt whenever the queue of waiters is
> >empty, if we are frequently waiting on alternating batches, we end up
> >re-enabling the interrupt on a frequent basis. We do want to disable the
> >interrupt during normal operations as under high load it may add several
> >thousand interrupts/s - we have been known in the past to occupy whole
> >cores with our interrupt handler after accidentally leaving user
> >interrupts enabled. As a compromise, leave the interrupt enabled until
> >the next IRQ, or the system is idle. This gives a small window for a
> >waiter to keep the interrupt active and not be delayed by having to
> >re-enable the interrupt.
> >
> >v2: Restore hangcheck/missed-irq detection for continuations
> >v3: Be more careful restoring the hangcheck timer after reset
> >v4: Be more careful restoring the fake irq after reset (if required!)
> >v5: Redo changes to intel_engine_wakeup()
> >
> >Signed-off-by: Chris Wilson
> >Cc: Tvrtko Ursulin
> >Cc: Mika Kuoppala
> >---
> > drivers/gpu/drm/i915/i915_gem.c | 4 +-
> > drivers/gpu/drm/i915/i915_irq.c | 2 +
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 137
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +-
> > 4 files changed, 97 insertions(+), 53 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 01dbba3813c7..0ad080984877 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2988,8 +2988,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
> > if (wait_for(intel_execlists_idle(dev_priv), 10))
> > DRM_ERROR("Timeout waiting for engines to idle\n");
> >
> >-for_each_engine(engine, dev_priv, id)
> >+for_each_engine(engine, dev_priv, id) {
> >+intel_engine_disarm_breadcrumbs(engine);
> > i915_gem_batch_pool_fini(&engine->batch_pool);
> >+}
> >
> > GEM_BUG_ON(!dev_priv->gt.awake);
> > dev_priv->gt.awake = false;
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >b/drivers/gpu/drm/i915/i915_irq.c
> >index 7607aba35f26..ba0bb33e12ed 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -1058,6 +1058,8 @@ static void notify_ring(struct intel_engine_cs *engine)
> > rq = wait->request;
> >
> > wake_up_process(wait->tsk);
> >+} else {
> >+__intel_engine_disarm_breadcrumbs(engine);
> > }
> > spin_unlock(&engine->breadcrumbs.lock);
> >
> >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >index d7511e89c8ab..8e83be343057 100644
> >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >@@ -36,8 +36,8 @@ unsigned int intel_engine_wakeup(struct intel_engine_cs
> >*engine)
> > wait = engine->breadcrumbs.first_wait;
> > if (wait) {
> > ret = ENGINE_WAKEUP_WAITER;
> >-if (!wake_up_process(wait->tsk))
> >-ret |= ENGINE_WAKEUP_ACTIVE;
> >+if (wake_up_process(wait->tsk))
> >+ret |= ENGINE_WAKEUP_ASLEEP;
>
> Why did you want to reverse the bit and all?
Because we need to keep the hangcheck alive whilst there is no waiter -
only when we declare the GT as idle do we disarm.
> > }
> > spin_unlock_irqrestore(&engine->breadcrumbs.lock, flags);
> >
> >@@ -54,7 +54,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
> > struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
> > struct intel_breadcrumbs *b = &engine->breadcrumbs;
> >
> >-if (!b->irq_enabled)
> >+if (!b->irq_armed)
> > return;
> >
> > if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
> >@@ -67,7 +67,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
> > * to process the pending interrupt (e.g, low priority task on a loaded
> > * system) and wait until it sleeps before declaring a missed interrupt.
> > */
> >-if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
> >+if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
> > mod_timer(&b->hangcheck, wait_timeout());
> > return;
> > }
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i2c: designware: Never suspend i2c-busses used for accessing the system PMIC
On Mon, 27 Feb 2017 11:32:45 +0100,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 11:25, Takashi Iwai wrote:
> > On Mon, 27 Feb 2017 10:38:29 +0100,
> > Hans de Goede wrote:
> >>
> >> index a8e74ca..a4ac473 100644
> >> --- a/drivers/i2c/busses/i2c-designware-core.h
> >> +++ b/drivers/i2c/busses/i2c-designware-core.h
> >> @@ -79,7 +79,7 @@
> >> * @pm_qos: pm_qos_request used while holding a hardware lock on the bus
> >> * @acquire_lock: function to acquire a hardware lock on the bus
> >> * @release_lock: function to release a hardware lock on the bus
> >> - * @pm_runtime_disabled: true if pm runtime is disabled
> >> + * @pm_disabled: true if power-management should be disabled for this
> >> i2c-bus
> >> *
> >> * HCNT and LCNT parameters can be used if the platform knows more
> >> accurate
> >> * values than the one computed based only on the input clock frequency.
> >> @@ -127,7 +127,7 @@ struct dw_i2c_dev {
> >>struct pm_qos_request pm_qos;
> >>int (*acquire_lock)(struct dw_i2c_dev *dev);
> >>void(*release_lock)(struct dw_i2c_dev *dev);
> >> - boolpm_runtime_disabled;
> >> + boolpm_disabled;
> >>booldynamic_tar_update_enabled;
> >
> > I couldn't find this dynamic_tar_update_enabled field in your previous
> > patchset. What am I missing?
>
> My testing branch for all this stuff is based on intel-drm-next-queued, which
> is still based on 4.10-rc$, and it seems that 4.11-rc1 will have this:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=12688dc21f71f4dcc9e2b8b5556b0c6cc8df1491
>
> Removing the dynamic_tar_update_enabled member from that struct.
>
> I will send out a new rebased version when 4.11-rc1 gets merged in
> intel-drm-next-queued.
Alright, thanks!
I'm testing the stuff right now. Since I didn't have the issue on my
machine, I can't say whether it fixes or not. But at least it
doesn't give any regression, so far ;)
I've put it to topic/i2c-dw-cherrytrail branch for anyone who wants to
try.
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Only unwind the local pgtable layer if empty
== Series Details == Series: series starting with [1/3] drm/i915: Only unwind the local pgtable layer if empty URL : https://patchwork.freedesktop.org/series/20257/ State : success == Summary == Series 20257v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20257/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC integration manifest 0f9969e drm/i915: Remove the vma from the drm_mm if binding fails 917eef9 drm/i915: Unwind vma->pages allocation upon failure 0fa7142 drm/i915: Only unwind the local pgtable layer if empty == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3977/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl: Add missing SKL ID
Used by production device: Intel(R) Iris(TM) Graphics P555 Cc: Cc: Mika Kuoppala Cc: Rodrigo Vivi Signed-off-by: Michał Winiarski Reviewed-by: Rodrigo Vivi Reviewed-by: Mika Kuoppala --- include/drm/i915_pciids.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index a1dd21d..466c715 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -265,7 +265,8 @@ INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \ INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ INTEL_VGA_DEVICE(0x1927, info), /* ULT GT3 */ \ - INTEL_VGA_DEVICE(0x192B, info) /* Halo GT3 */ \ + INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \ + INTEL_VGA_DEVICE(0x192D, info) /* SRV GT3 */ #define INTEL_SKL_GT4_IDS(info) \ INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \ -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Only unwind the local pgtable layer if empty
On 25 February 2017 at 23:25, Chris Wilson wrote:
> Only if we allocated the layer and the lower level failed should we
> remove this layer when unwinding. Otherwise we ignore the overlapping
> entries by overwritting the old layer with scratch.
overwriting
>
> Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4")
> Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
> Reported-by: Matthew Auld
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99948
https://bugs.freedesktop.org/show_bug.cgi?id=99947 ?
Tested-by: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include fence-hint for timeout warning
== Series Details == Series: drm/i915: Include fence-hint for timeout warning URL : https://patchwork.freedesktop.org/series/20264/ State : success == Summary == Series 20264v1 drm/i915: Include fence-hint for timeout warning https://patchwork.freedesktop.org/api/1.0/series/20264/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC integration manifest 24a83aa drm/i915: Include fence-hint for timeout warning == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3978/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb.
Op 23-02-17 om 16:24 schreef Sean Paul:
> On Tue, Feb 21, 2017 at 02:51:42PM +0100, Maarten Lankhorst wrote:
>> This introduces a slight behavioral change to rmfb. Instead of
>> disabling a crtc when the primary plane is disabled, we try to
>> preserve it.
>>
>> Apart from old versions of the vmwgfx xorg driver, there is
>> nothing depending on rmfb disabling a crtc. Since vmwgfx is
>> a legacy driver we can safely only disable the plane with atomic.
>> In the conversion to atomic the driver will reject the config
>> without primary plane.
>>
>> If this commit is rejected by the driver then we will still fall
>> back to the old behavior and turn off the crtc.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic.c | 22 --
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 285e1c23e8c9..0d5b0065208e 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -2070,7 +2070,7 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>> struct drm_connector *conn;
>> struct drm_connector_state *conn_state;
>> int i, ret = 0;
>> -unsigned plane_mask;
>> +unsigned plane_mask, disable_crtcs = false;
>>
>> state = drm_atomic_state_alloc(dev);
>> if (!state)
>> @@ -2097,7 +2097,13 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>> goto unlock;
>> }
>>
>> -if (plane_state->crtc->primary == plane) {
>> +/*
>> + * Some drivers do not support keeping crtc active with the
>> + * primary plane disabled. If we fail to commit with -EINVAL
>> + * then we will try to perform the same commit but with all
>> + * crtc's disabled for primary planes as well.
>> + */
>> +if (disable_crtcs && plane_state->crtc->primary == plane) {
>> struct drm_crtc_state *crtc_state;
>>
>> crtc_state = drm_atomic_get_existing_crtc_state(state,
>> plane_state->crtc);
>> @@ -2122,6 +2128,7 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>> plane->old_fb = plane->fb;
>> }
>>
>> +/* This list is only not empty when disable_crtcs is set. */
>> for_each_connector_in_state(state, conn, conn_state, i) {
>> ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
>>
>> @@ -2143,6 +2150,17 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
>>
>> drm_atomic_state_put(state);
>>
>> +if (ret == -EINVAL && !disable_crtcs) {
>> +disable_crtcs = true;
>> +
>> +state = drm_atomic_state_alloc(dev);
>> +if (state) {
>> +state->acquire_ctx = &ctx;
>> +goto retry;
> Re-using the retry label is a little fishy here. You need to re-allocate
> state,
> but we don't drop the locks, which makes things a little unbalanced (I realize
> modeset_lock will s/EALREADY/0/).
drm_modeset_lock can be called any arbitrary numer of times. I'm not worried
about it. :)
> Perhaps something like this above would be more clear:
>
> + drm_modeset_acquire_init(&ctx, 0);
> +retry:
> + plane_mask = 0;
> + ret = drm_modeset_lock_all_ctx(dev, &ctx);
> + if (ret)
> + goto unlock;
> +
> +retry_disable:
> + state = drm_atomic_state_alloc(dev);
> + if (!state)
> + return -ENOMEM;
> + state->acquire_ctx = &ctx;
> +
>
> Then you can do:
>
>
> + if (ret == -EINVAL && !disable_crtcs) {
> + disable_crtcs = true;
> + goto retry_disable;
> + }
>
> (you would also need to ensure you moved the state_put above the EDEADLK
> handling).
>
> Thoughts?
In general we try to call drm_atomic_state_clear instead of
drm_atomic_state_put, this would be a source of confusion for being different
from other users of atomic.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove the vma from the drm_mm if binding fails
On la, 2017-02-25 at 23:25 +, Chris Wilson wrote:
> As we track whether a vma has been inserted into the drm_mm using the
> vma->flags, if we fail to bind the vma into the GTT we do not update
> those bits and will attempt to reinsert the vma into the drm_mm on
> future passes. To prevent that, we want to unwind i915_vma_insert() if
> we fail in our attempt to bind.
>
> Fixes: 59bfa1248e22 ("drm/i915: Start passing around i915_vma from
> execbuffer")
> Testcase: igt/drv_selftest/live_gtt
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: # v4.9+
Reviewed-by: Joonas Lahtinen
One note below.
> @@ -541,7 +566,12 @@ int __i915_vma_do_pin(struct i915_vma *vma,
> GEM_BUG_ON(i915_vma_misplaced(vma, size, alignment, flags));
> return 0;
>
> -err:
> +err_remove:
> + if ((vma->flags & I915_VMA_BIND_MASK) == 0) {
This condition could be more symmetric.
Regards, Joonas
> + GEM_BUG_ON(vma->pages);
> + i915_vma_remove(vma);
> + }
> +err_unpin:
> __i915_vma_unpin(vma);
> return ret;
> }
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Do not write the replay bit of the ring mode register
On pe, 2017-02-24 at 11:48 -0800, Daniele Ceraolo Spurio wrote: > Reviewed-by: Daniele Ceraolo Spurio Pushed, thanks for the patch and review. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Remove the vma from the drm_mm if binding fails
On Mon, Feb 27, 2017 at 02:02:00PM +0200, Joonas Lahtinen wrote:
> On la, 2017-02-25 at 23:25 +, Chris Wilson wrote:
> > As we track whether a vma has been inserted into the drm_mm using the
> > vma->flags, if we fail to bind the vma into the GTT we do not update
> > those bits and will attempt to reinsert the vma into the drm_mm on
> > future passes. To prevent that, we want to unwind i915_vma_insert() if
> > we fail in our attempt to bind.
> >
> > Fixes: 59bfa1248e22 ("drm/i915: Start passing around i915_vma from
> > execbuffer")
> > Testcase: igt/drv_selftest/live_gtt
> > Signed-off-by: Chris Wilson
> > Cc: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: # v4.9+
>
> Reviewed-by: Joonas Lahtinen
>
> One note below.
>
> > @@ -541,7 +566,12 @@ int __i915_vma_do_pin(struct i915_vma *vma,
> > GEM_BUG_ON(i915_vma_misplaced(vma, size, alignment, flags));
> > return 0;
> >
> > -err:
> > +err_remove:
> > + if ((vma->flags & I915_VMA_BIND_MASK) == 0) {
>
> This condition could be more symmetric.
Done: if ((bound & I915_VMA_BIND_MASK) == 0) and made bound const to be
clear.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Only unwind the local pgtable layer if empty
On Mon, Feb 27, 2017 at 11:48:46AM +, Matthew Auld wrote:
> On 25 February 2017 at 23:25, Chris Wilson wrote:
> > Only if we allocated the layer and the lower level failed should we
> > remove this layer when unwinding. Otherwise we ignore the overlapping
> > entries by overwritting the old layer with scratch.
> overwriting
>
> >
> > Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4")
> > Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
> > Reported-by: Matthew Auld
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99948
> https://bugs.freedesktop.org/show_bug.cgi?id=99947 ?
Oops, bad cut'n'paste.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Unwind vma->pages allocation upon failure
On 25 February 2017 at 23:25, Chris Wilson wrote:
> If we fail to allocate the ppgtt range after allocating the pages for
> the vma, we should unwind the local allocation before reporting back the
> failure.
>
> Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/i915/uc: Introduce intel_uc_init_fw()
On pe, 2017-02-24 at 16:39 +0100, Arkadiusz Hiler wrote: > Instead of calling intel_guc_init() and intel_huc_init() one by one this > patch introduces intel_uc_init_fw() function that calls them both. > > Called functions are renamed accordingly. > > Trying to have subject_verb_object ordering and more descriptive names, > the intel_huc_init() and intel_guc_init() functions are renamed. > > For guc_init(): > * `intel_guc` is the subject, so those functions now take intel_guc > structure, instead of the dev_priv > * init is the verb > * fw is the object which better describes the function's role > > huc_init() change follows the same reasoning. > > v2: settle on intel_uc_fetch_fw name (M. Wajdeczko) > v3: yet another rename - intel_uc_init_fw (J. Lahtinen) > > Cc: Chris Wilson > Cc: Joonas Lahtinen > Cc: Michal Wajdeczko > Cc: Michal Winiarski > Signed-off-by: Arkadiusz Hiler Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/perf: improve invalid OA format debug message
On 22 February 2017 at 15:25, Robert Bragg wrote: > A minor improvement to debugging output > > Signed-off-by: Robert Bragg Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/skl: Add missing SKL ID (rev3)
== Series Details == Series: drm/i915/skl: Add missing SKL ID (rev3) URL : https://patchwork.freedesktop.org/series/3537/ State : success == Summary == Series 3537v3 drm/i915/skl: Add missing SKL ID https://patchwork.freedesktop.org/api/1.0/series/3537/revisions/3/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC integration manifest 69f1560 drm/i915/skl: Add missing SKL ID == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3979/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation
On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
> preparation (fetch + initial parsing).
>
> This change separates out select steps, so those can be called by
> the sanitize_options().
>
> Then, during the init_fw() we prepare the firmware if the firmware was
> selected.
>
> Cc: Michal Winiarski
> Cc: Joonas Lahtinen
> Signed-off-by: Arkadiusz Hiler
Reviewed-by: Joonas Lahtinen
One comment below.
> @@ -66,6 +66,16 @@ void intel_uc_sanitize_options(struct drm_i915_private
> *dev_priv)
> if (!i915.enable_guc_loading)
> i915.enable_guc_submission = 0;
> }
> +
> + if (i915.enable_guc_loading) {
> + if (HAS_HUC_UCODE(dev_priv))
> + intel_huc_select_fw(&dev_priv->huc);
> +
> + intel_guc_select_fw(&dev_priv->guc);
> +
> + if (!dev_priv->guc.fw.path)
> + i915.enable_guc_loading = 0;
Maybe make this (as suggested by Michal):
if (intel_guc_select_fw(&dev_priv->guc) < 0)
i915.enable_guc_loading = 0;
I think the select_fw is appropriate in this place once we introduce
the option to override the FW path, it'll part of sanitization.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915: Only unwind the local pgtable layer if empty
Only if we allocated the layer and the lower level failed should we
remove this layer when unwinding. Otherwise we ignore the overlapping
entries by overwriting the old layer with scratch.
Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4")
Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
Reported-by: Matthew Auld
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99947
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Tested-by: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6fdbd5ae4fcb..c3a121ab8914 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -716,10 +716,13 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
u32 pde;
gen8_for_each_pde(pt, pd, start, length, pde) {
+ GEM_BUG_ON(pt == vm->scratch_pt);
+
if (!gen8_ppgtt_clear_pt(vm, pt, start, length))
continue;
gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
+ GEM_BUG_ON(!pd->used_pdes);
pd->used_pdes--;
free_pt(vm, pt);
@@ -755,10 +758,13 @@ static bool gen8_ppgtt_clear_pdp(struct
i915_address_space *vm,
unsigned int pdpe;
gen8_for_each_pdpe(pd, pdp, start, length, pdpe) {
+ GEM_BUG_ON(pd == vm->scratch_pd);
+
if (!gen8_ppgtt_clear_pd(vm, pd, start, length))
continue;
gen8_ppgtt_set_pdpe(vm, pdp, vm->scratch_pd, pdpe);
+ GEM_BUG_ON(!pdp->used_pdpes);
pdp->used_pdpes--;
free_pd(vm, pd);
@@ -801,6 +807,8 @@ static void gen8_ppgtt_clear_4lvl(struct i915_address_space
*vm,
GEM_BUG_ON(!USES_FULL_48BIT_PPGTT(vm->i915));
gen8_for_each_pml4e(pdp, pml4, start, length, pml4e) {
+ GEM_BUG_ON(pdp == vm->scratch_pdp);
+
if (!gen8_ppgtt_clear_pdp(vm, pdp, start, length))
continue;
@@ -1089,6 +1097,7 @@ static int gen8_ppgtt_alloc_pd(struct i915_address_space
*vm,
gen8_ppgtt_set_pde(vm, pd, pt, pde);
pd->used_pdes++;
+ GEM_BUG_ON(pd->used_pdes > I915_PDES);
}
pt->used_ptes += gen8_pte_count(start, length);
@@ -1118,21 +1127,25 @@ static int gen8_ppgtt_alloc_pdp(struct
i915_address_space *vm,
gen8_initialize_pd(vm, pd);
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
pdp->used_pdpes++;
+ GEM_BUG_ON(pdp->used_pdpes > I915_PDPES_PER_PDP(vm));
mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
}
ret = gen8_ppgtt_alloc_pd(vm, pd, start, length);
- if (unlikely(ret)) {
- gen8_ppgtt_set_pdpe(vm, pdp, vm->scratch_pd, pdpe);
- pdp->used_pdpes--;
- free_pd(vm, pd);
- goto unwind;
- }
+ if (unlikely(ret))
+ goto unwind_pd;
}
return 0;
+unwind_pd:
+ if (!pd->used_pdes) {
+ gen8_ppgtt_set_pdpe(vm, pdp, vm->scratch_pd, pdpe);
+ GEM_BUG_ON(!pdp->used_pdpes);
+ pdp->used_pdpes--;
+ free_pd(vm, pd);
+ }
unwind:
gen8_ppgtt_clear_pdp(vm, pdp, from, start - from);
return -ENOMEM;
@@ -1166,15 +1179,17 @@ static int gen8_ppgtt_alloc_4lvl(struct
i915_address_space *vm,
}
ret = gen8_ppgtt_alloc_pdp(vm, pdp, start, length);
- if (unlikely(ret)) {
- gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
- free_pdp(vm, pdp);
- goto unwind;
- }
+ if (unlikely(ret))
+ goto unwind_pdp;
}
return 0;
+unwind_pdp:
+ if (!pdp->used_pdpes) {
+ gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
+ free_pdp(vm, pdp);
+ }
unwind:
gen8_ppgtt_clear_4lvl(vm, from, start - from);
return -ENOMEM;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915: Remove the vma from the drm_mm if binding fails
As we track whether a vma has been inserted into the drm_mm using the
vma->flags, if we fail to bind the vma into the GTT we do not update
those bits and will attempt to reinsert the vma into the drm_mm on
future passes. To prevent that, we want to unwind i915_vma_insert() if
we fail in our attempt to bind.
Fixes: 59bfa1248e22 ("drm/i915: Start passing around i915_vma from execbuffer")
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Joonas Lahtinen
Cc: # v4.9+
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_vma.c | 56 ++---
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 6e9eade304b8..505c1ea8d0f5 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -509,10 +509,35 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
return ret;
}
+static void
+i915_vma_remove(struct i915_vma *vma)
+{
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
+ GEM_BUG_ON(vma->flags & (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND));
+
+ drm_mm_remove_node(&vma->node);
+ list_move_tail(&vma->vm_link, &vma->vm->unbound_list);
+
+ /* Since the unbound list is global, only move to that list if
+* no more VMAs exist. */
+ if (--obj->bind_count == 0)
+ list_move_tail(&obj->global_link,
+ &to_i915(obj->base.dev)->mm.unbound_list);
+
+ /* And finally now the object is completely decoupled from this vma,
+* we can drop its hold on the backing storage and allow it to be
+* reaped by the shrinker.
+*/
+ i915_gem_object_unpin_pages(obj);
+ GEM_BUG_ON(atomic_read(&obj->mm.pages_pin_count) < obj->bind_count);
+}
+
int __i915_vma_do_pin(struct i915_vma *vma,
u64 size, u64 alignment, u64 flags)
{
- unsigned int bound = vma->flags;
+ const unsigned int bound = vma->flags;
int ret;
lockdep_assert_held(&vma->vm->i915->drm.struct_mutex);
@@ -521,18 +546,18 @@ int __i915_vma_do_pin(struct i915_vma *vma,
if (WARN_ON(bound & I915_VMA_PIN_OVERFLOW)) {
ret = -EBUSY;
- goto err;
+ goto err_unpin;
}
if ((bound & I915_VMA_BIND_MASK) == 0) {
ret = i915_vma_insert(vma, size, alignment, flags);
if (ret)
- goto err;
+ goto err_unpin;
}
ret = i915_vma_bind(vma, vma->obj->cache_level, flags);
if (ret)
- goto err;
+ goto err_remove;
if ((bound ^ vma->flags) & I915_VMA_GLOBAL_BIND)
__i915_vma_set_map_and_fenceable(vma);
@@ -541,7 +566,12 @@ int __i915_vma_do_pin(struct i915_vma *vma,
GEM_BUG_ON(i915_vma_misplaced(vma, size, alignment, flags));
return 0;
-err:
+err_remove:
+ if ((bound & I915_VMA_BIND_MASK) == 0) {
+ GEM_BUG_ON(vma->pages);
+ i915_vma_remove(vma);
+ }
+err_unpin:
__i915_vma_unpin(vma);
return ret;
}
@@ -654,9 +684,6 @@ int i915_vma_unbind(struct i915_vma *vma)
}
vma->flags &= ~(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND);
- drm_mm_remove_node(&vma->node);
- list_move_tail(&vma->vm_link, &vma->vm->unbound_list);
-
if (vma->pages != obj->mm.pages) {
GEM_BUG_ON(!vma->pages);
sg_free_table(vma->pages);
@@ -664,18 +691,7 @@ int i915_vma_unbind(struct i915_vma *vma)
}
vma->pages = NULL;
- /* Since the unbound list is global, only move to that list if
-* no more VMAs exist. */
- if (--obj->bind_count == 0)
- list_move_tail(&obj->global_link,
- &to_i915(obj->base.dev)->mm.unbound_list);
-
- /* And finally now the object is completely decoupled from this vma,
-* we can drop its hold on the backing storage and allow it to be
-* reaped by the shrinker.
-*/
- i915_gem_object_unpin_pages(obj);
- GEM_BUG_ON(atomic_read(&obj->mm.pages_pin_count) < obj->bind_count);
+ i915_vma_remove(vma);
destroy:
if (unlikely(i915_vma_is_closed(vma)))
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915: Unwind vma->pages allocation upon failure
If we fail to allocate the ppgtt range after allocating the pages for
the vma, we should unwind the local allocation before reporting back the
failure.
Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c3a121ab8914..875a48b9d05a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2312,7 +2312,7 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
vma->node.start,
vma->node.size);
if (ret)
- return ret;
+ goto err_pages;
}
appgtt->base.insert_entries(&appgtt->base,
@@ -2329,6 +2329,17 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
}
return 0;
+
+err_pages:
+ if (!(vma->flags & (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND))) {
+ if (vma->pages != vma->obj->mm.pages) {
+ GEM_BUG_ON(!vma->pages);
+ sg_free_table(vma->pages);
+ kfree(vma->pages);
+ }
+ vma->pages = NULL;
+ }
+ return ret;
}
static void aliasing_gtt_unbind_vma(struct i915_vma *vma)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
v2: remove second declaration, reorder (M. Wajdeczko)
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_guc_loader.c | 137 +---
drivers/gpu/drm/i915/intel_huc.c| 2 +-
drivers/gpu/drm/i915/intel_uc.c | 135 +++
drivers/gpu/drm/i915/intel_uc.h | 4 +-
4 files changed, 139 insertions(+), 139 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 9f09e26..20e3337 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -26,7 +26,6 @@
*Dave Gordon
*Alex Dai
*/
-#include
#include "i915_drv.h"
#include "intel_uc.h"
@@ -587,140 +586,6 @@ int intel_guc_init_hw(struct drm_i915_private *dev_priv)
return ret;
}
-void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
-struct intel_uc_fw *uc_fw)
-{
- struct pci_dev *pdev = dev_priv->drm.pdev;
- struct drm_i915_gem_object *obj;
- const struct firmware *fw = NULL;
- struct uc_css_header *css;
- size_t size;
- int err;
-
- DRM_DEBUG_DRIVER("before requesting firmware: uC fw fetch status %s\n",
- intel_uc_fw_status_repr(uc_fw->fetch_status));
-
- err = request_firmware(&fw, uc_fw->path, &pdev->dev);
- if (err)
- goto fail;
- if (!fw)
- goto fail;
-
- DRM_DEBUG_DRIVER("fetch uC fw from %s succeeded, fw %p\n",
- uc_fw->path, fw);
-
- /* Check the size of the blob before examining buffer contents */
- if (fw->size < sizeof(struct uc_css_header)) {
- DRM_NOTE("Firmware header is missing\n");
- goto fail;
- }
-
- css = (struct uc_css_header *)fw->data;
-
- /* Firmware bits always start from header */
- uc_fw->header_offset = 0;
- uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
- css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
-
- if (uc_fw->header_size != sizeof(struct uc_css_header)) {
- DRM_NOTE("CSS header definition mismatch\n");
- goto fail;
- }
-
- /* then, uCode */
- uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
- uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
-
- /* now RSA */
- if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
- DRM_NOTE("RSA key size is bad\n");
- goto fail;
- }
- uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size;
- uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
-
- /* At least, it should have header, uCode and RSA. Size of all three. */
- size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
- if (fw->size < size) {
- DRM_NOTE("Missing firmware components\n");
- goto fail;
- }
-
- /*
-* The GuC firmware image has the version number embedded at a
well-known
-* offset within the firmware blob; note that major / minor version are
-* TWO bytes each (i.e. u16), although all pointers and offsets are
defined
-* in terms of bytes (u8).
-*/
- switch (uc_fw->fw) {
- case INTEL_UC_FW_TYPE_GUC:
- /* Header and uCode will be loaded to WOPCM. Size of the two. */
- size = uc_fw->header_size + uc_fw->ucode_size;
-
- /* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
- if (size > intel_guc_wopcm_size(dev_priv)) {
- DRM_ERROR("Firmware is too large to fit in WOPCM\n");
- goto fail;
- }
- uc_fw->major_ver_found = css->guc.sw_version >> 16;
- uc_fw->minor_ver_found = css->guc.sw_version & 0x;
- break;
-
- case INTEL_UC_FW_TYPE_HUC:
- uc_fw->major_ver_found = css->huc.sw_version >> 16;
- uc_fw->minor_ver_found = css->huc.sw_version & 0x;
- break;
-
- default:
- DRM_ERROR("Unknown firmware type %d\n", uc_fw->fw);
- err = -ENOEXEC;
- goto fail;
- }
-
- if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
- uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {
- DRM_NOTE("uC firmware version %d.%d, required %d.%d\n",
- uc_fw->major_ver_found, uc_fw->minor_ver_found,
- uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted);
- err = -ENOEXEC;
- goto fail;
- }
-
- DRM_DEBUG_DRIVER("firmware version %d.%d OK (minimum %d.%d)\n",
- uc_fw->major_ver_found,
Re: [Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware
On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>
> Using the parameter disabled version checks and loads desired firmware
> instead of the default one.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Michal Winiarski
> Signed-off-by: Arkadiusz Hiler
> @@ -230,6 +232,14 @@ module_param_named(guc_log_level, i915.guc_log_level,
> int, 0400);
> MODULE_PARM_DESC(guc_log_level,
> "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
>
> +module_param_named(guc_firmware_path, i915.guc_firmware_path, charp, 0400);
I'm pretty sure this should be _unsafe, because it overrides the
version checks. Cc'd Jani for this.
> @@ -479,7 +479,11 @@ void intel_guc_select_fw(struct intel_guc *guc)
> guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
> guc->fw.fw = INTEL_UC_FW_TYPE_GUC;
>
> - if (IS_SKYLAKE(dev_priv)) {
> + if (i915.guc_firmware_path) {
> + guc->fw.path = i915.guc_firmware_path;
> + guc->fw.major_ver_wanted = 0;
> + guc->fw.minor_ver_wanted = 0;
Or, we could keep the wanted version number, only replace the path, and
spit out WARN/taint kernel if some other version was detected?
But I guess the main purpose is to override version (not provide
request_firmware workarounds), so my vote is to make the param _unsafe.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/guc: Extract param logic form guc_init_fw()
Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_init_fw() conditionally
and we do not have to do the internal checks.
v2: fix comment, notify when nuking GuC explicitly enabled (M. Wajdeczko)
v3: fix comment again, change the nuke message (M. Wajdeczko)
v4: update title to reflect new function name + rebase
v5: text && remove 2 uneccessary checks (M. Wajeczko)
Cc: Michal Winiarski
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Joonas Lahtinen
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/intel_guc_loader.c | 18 +-
drivers/gpu/drm/i915/intel_huc.c| 3 ---
drivers/gpu/drm/i915/intel_uc.c | 28 +++-
drivers/gpu/drm/i915/intel_uc.h | 1 +
5 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 56624bf..7964e7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -993,6 +993,8 @@ static void intel_sanitize_options(struct drm_i915_private
*dev_priv)
i915.semaphores = intel_sanitize_semaphores(dev_priv, i915.semaphores);
DRM_DEBUG_DRIVER("use GPU semaphores? %s\n", yesno(i915.semaphores));
+
+ intel_uc_sanitize_options(dev_priv);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 87b7a39..fb518e0 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -601,20 +601,7 @@ void intel_guc_init_fw(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
const char *fw_path;
- if (!HAS_GUC(dev_priv)) {
- i915.enable_guc_loading = 0;
- i915.enable_guc_submission = 0;
- } else {
- /* A negative value means "use platform default" */
- if (i915.enable_guc_loading < 0)
- i915.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
- if (i915.enable_guc_submission < 0)
- i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
- }
-
- if (!HAS_GUC_UCODE(dev_priv)) {
- fw_path = NULL;
- } else if (IS_SKYLAKE(dev_priv)) {
+ if (IS_SKYLAKE(dev_priv)) {
fw_path = I915_SKL_GUC_UCODE;
guc->fw.major_ver_wanted = SKL_FW_MAJOR;
guc->fw.minor_ver_wanted = SKL_FW_MINOR;
@@ -634,9 +621,6 @@ void intel_guc_init_fw(struct intel_guc *guc)
guc->fw.fetch_status = INTEL_UC_FIRMWARE_NONE;
guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
- /* Early (and silent) return if GuC loading is disabled */
- if (!i915.enable_guc_loading)
- return;
if (fw_path == NULL)
return;
if (*fw_path == '\0')
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 6f0811c..9707da3 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -162,9 +162,6 @@ void intel_huc_init_fw(struct intel_huc *huc)
huc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
huc->fw.fw = INTEL_UC_FW_TYPE_HUC;
- if (!HAS_HUC_UCODE(dev_priv))
- return;
-
if (IS_SKYLAKE(dev_priv)) {
fw_path = I915_SKL_HUC_UCODE;
huc->fw.major_ver_wanted = SKL_HUC_FW_MAJOR;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 5c204e6..7453a648 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -26,6 +26,27 @@
#include "intel_uc.h"
#include
+void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+{
+ if (!HAS_GUC(dev_priv)) {
+ if (i915.enable_guc_loading > 0)
+ DRM_INFO("Ignoring GuC options, no hardware");
+
+ i915.enable_guc_loading = 0;
+ i915.enable_guc_submission = 0;
+ } else {
+ /* A negative value means "use platform default" */
+ if (i915.enable_guc_loading < 0)
+ i915.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
+ if (i915.enable_guc_submission < 0)
+ i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
+
+ /* Can't enable guc submission without guc loaded */
+ if (!i915.enable_guc_loading)
+ i915.enable_guc_submission = 0;
+ }
+}
+
void intel_uc_init_early(struct drm_i915_private *dev_priv)
{
mutex_init(&dev_priv->guc.send_mutex);
@@ -33,7 +54,12 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
void intel_uc_init_fw(struct drm_i915_private *dev_priv)
{
- intel_huc_init_fw(&dev_priv->huc)
Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating
On ma, 2017-02-27 at 10:21 +, Chris Wilson wrote: > On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote: > > Perhaps you could say what kind of optimisation you have in mind to > > save me guessing? :) > > I was thinking you would like an inactivity timer. Or we could have a > separate shrinker, as that's the principal cache management system. My vote goes for merging and addressing the seen problems in the caching logic. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Only unwind the local pgtable layer if empty
== Series Details == Series: series starting with [CI,1/3] drm/i915: Only unwind the local pgtable layer if empty URL : https://patchwork.freedesktop.org/series/20303/ State : success == Summary == Series 20303v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20303/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC integration manifest 6867a9f drm/i915: Remove the vma from the drm_mm if binding fails 83cf468 drm/i915: Unwind vma->pages allocation upon failure c195b07 drm/i915: Only unwind the local pgtable layer if empty == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3980/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Add missing SKL ID
Michał Winiarski writes: > Used by production device: > Intel(R) Iris(TM) Graphics P555 > > Cc: > Cc: Mika Kuoppala > Cc: Rodrigo Vivi > Signed-off-by: Michał Winiarski > Reviewed-by: Rodrigo Vivi > Reviewed-by: Mika Kuoppala Pushed to dinq, thanks for patch and review. -Mika > --- > include/drm/i915_pciids.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index a1dd21d..466c715 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -265,7 +265,8 @@ > INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \ > INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ > INTEL_VGA_DEVICE(0x1927, info), /* ULT GT3 */ \ > - INTEL_VGA_DEVICE(0x192B, info) /* Halo GT3 */ \ > + INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \ > + INTEL_VGA_DEVICE(0x192D, info) /* SRV GT3 */ > > #define INTEL_SKL_GT4_IDS(info) \ > INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \ > -- > 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3
Chris Wilson writes:
> On Wed, Feb 15, 2017 at 03:52:59PM +0200, Mika Kuoppala wrote:
>> Certain Baytrails, namely the 4 cpu core variants, have been
>> plaqued by spurious system hangs, mostly occurring with light loads.
>>
>> Multiple bisects by various people point to a commit which changes the
>> reclocking strategy for Baytrail to follow its bigger brethen:
>> commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail")
>>
>> There is also a review comment attached to this commit from Deepak S
>> on avoiding punit access on Cherryview and thus it was excluded on
>> common reclocking path. By taking the same approach and omitting
>> the punit access by not tweaking the thresholds when the hardware
>> has been asked to move into different frequency, considerable gains
>> in stability have been observed.
>>
>> With J1900 box, light render/video load would end up in system hang
>> in usually less than 12 hours. With this patch applied, the cumulative
>> uptime has now been 34 days without issues. To provoke system hang,
>> light loads on both render and bsd engines in parallel have been used:
>> glxgears >/dev/null 2>/dev/null &
>> mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4
>>
>> So far, author has not witnessed system hang with above load
>> and this patch applied. Reports from the tenacious people at
>> kernel bugzilla are also promising.
>>
>> Considering that the punit access frequency with this patch is
>> considerably less, there is a possibility that this will push
>> the, still unknown, root cause past the triggering point on most loads.
>>
>> But as we now can reliably reproduce the hang independently,
>> we can reduce the pain that users are having and use a
>> static thresholds until a root cause is found.
>>
>> v3: don't break debugfs and simplification (Chris Wilson)
>>
>> References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
>> Cc: Chris Wilson
>> Cc: Ville Syrjälä
>> Cc: Len Brown
>> Cc: Daniel Vetter
>> Cc: Jani Nikula
>> Cc: frit...@xbmc.org
>> Cc: m...@iki.fi
>> Cc: Ezequiel Garcia
>> CC: Michal Feix
>> Cc: Hans de Goede
>> Cc: Deepak S
>> Cc: Jarkko Nikula
>> Cc: # v4.2+
>> Acked-by: Daniel Vetter
>> Signed-off-by: Mika Kuoppala
>
> Had a couple of weekends to try and find an alternative explanation
> (a root cause for the hangs would be nice!). If it is just the writes to
> the RPS registers, are we safe on resume (etc)?
>
> However, I've drawn a blank on explaining what the hw is doing wrong
> (but found a couple of bugs in the byt manual RPS evaluation which
> desire review), so
> Acked-by: Chris Wilson
Pushed, thanks.
-Mika
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.
v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 148 ---
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +-
4 files changed, 105 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01dbba3813c7..0ad080984877 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2988,8 +2988,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wait_for(intel_execlists_idle(dev_priv), 10))
DRM_ERROR("Timeout waiting for engines to idle\n");
- for_each_engine(engine, dev_priv, id)
+ for_each_engine(engine, dev_priv, id) {
+ intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(&engine->batch_pool);
+ }
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc520ee8d6fe..ca8c7b22748e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1060,6 +1060,8 @@ static void notify_ring(struct intel_engine_cs *engine)
rq = wait->request;
wake_up_process(wait->tsk);
+ } else {
+ __intel_engine_disarm_breadcrumbs(engine);
}
spin_unlock(&engine->breadcrumbs.lock);
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3855c8c39b35..ebb7bc0be9fb 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,19 +26,28 @@
#include "i915_drv.h"
-unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+static unsigned int __intel_engine_wakeup(struct intel_engine_cs *engine)
{
struct intel_wait *wait;
- unsigned long flags;
unsigned int result = 0;
- spin_lock_irqsave(&engine->breadcrumbs.lock, flags);
wait = engine->breadcrumbs.first_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
- if (!wake_up_process(wait->tsk))
- result |= ENGINE_WAKEUP_ACTIVE;
+ if (wake_up_process(wait->tsk))
+ result |= ENGINE_WAKEUP_ASLEEP;
}
+
+ return result;
+}
+
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+ unsigned int result = 0;
+
+ spin_lock_irqsave(&engine->breadcrumbs.lock, flags);
+ result = __intel_engine_wakeup(engine);
spin_unlock_irqrestore(&engine->breadcrumbs.lock, flags);
return result;
@@ -54,7 +63,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct intel_breadcrumbs *b = &engine->breadcrumbs;
- if (!b->irq_enabled)
+ if (!b->irq_armed)
return;
if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
* to process the pending interrupt (e.g, low priority task on a loaded
* system) and wait until it sleeps before declaring a missed interrupt.
*/
- if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
+ if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
mod_timer(&b->hangcheck, wait_timeout());
return;
}
@@ -80,6 +89,8 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
static void intel_breadcrumbs_fake_irq(unsigned long data)
{
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ unsigned long flags;
[Intel-gfx] [PATCH v5 1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in the fake_irq path, we are using the return value
as a check as to whether there are any waiters, and so we may
incorrectly stop the fake-irq if that waiter was currently running.
To handle the two different needs, return both bits of information! We
uninline it from the irq path in preparation for the next patch which
makes the irq hotpath special and relegates intel_engine_wakeup() to the
slow fixup paths.
v2: s/ret/result/
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 28 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 26 +++---
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 027c93e34c97..c8361f350350 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,6 +26,32 @@
#include "i915_drv.h"
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+ unsigned int result = 0;
+
+ /* Note that for this not to dangerously chase a dangling pointer,
+* we must hold the rcu_read_lock here.
+*
+* Also note that tsk is likely to be in !TASK_RUNNING state so an
+* early test for tsk->state != TASK_RUNNING before wake_up_process()
+* is unlikely to be beneficial.
+*/
+ if (intel_engine_has_waiter(engine)) {
+ struct task_struct *tsk;
+
+ result = ENGINE_WAKEUP_WAITER;
+
+ rcu_read_lock();
+ tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
+ if (tsk && !wake_up_process(tsk))
+ result |= ENGINE_WAKEUP_ACTIVE;
+ rcu_read_unlock();
+ }
+
+ return result;
+}
+
static unsigned long wait_timeout(void)
{
return round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES);
@@ -49,7 +75,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
* to process the pending interrupt (e.g, low priority task on a loaded
* system) and wait until it sleeps before declaring a missed interrupt.
*/
- if (!intel_engine_wakeup(engine)) {
+ if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
mod_timer(&b->hangcheck, wait_timeout());
return;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0f29e07a9581..7d753dc1b89d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -642,29 +642,9 @@ static inline bool intel_engine_has_waiter(const struct
intel_engine_cs *engine)
return rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh);
}
-static inline bool intel_engine_wakeup(const struct intel_engine_cs *engine)
-{
- bool wakeup = false;
-
- /* Note that for this not to dangerously chase a dangling pointer,
-* we must hold the rcu_read_lock here.
-*
-* Also note that tsk is likely to be in !TASK_RUNNING state so an
-* early test for tsk->state != TASK_RUNNING before wake_up_process()
-* is unlikely to be beneficial.
-*/
- if (intel_engine_has_waiter(engine)) {
- struct task_struct *tsk;
-
- rcu_read_lock();
- tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
- if (tsk)
- wakeup = wake_up_process(tsk);
- rcu_read_unlock();
- }
-
- return wakeup;
-}
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine);
+#define ENGINE_WAKEUP_WAITER BIT(0)
+#define ENGINE_WAKEUP_ACTIVE BIT(1)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/4] drm/i915: Defer enabling hangcheck to the first fake breadcrumb interrupt
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the breadcrumbs after a reset simpler in the next patch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 36
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index e7f4a4c923a2..3855c8c39b35 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -75,17 +75,6 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
set_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings);
mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
-
- /* Ensure that even if the GPU hangs, we get woken up.
-*
-* However, note that if no one is waiting, we never notice
-* a gpu hang. Eventually, we will have to wait for a resource
-* held by the GPU and so trigger a hangcheck. In the most
-* pathological case, this will be upon memory starvation! To
-* prevent this, we also queue the hangcheck from the retire
-* worker.
-*/
- i915_queue_hangcheck(engine->i915);
}
static void intel_breadcrumbs_fake_irq(unsigned long data)
@@ -99,8 +88,21 @@ static void intel_breadcrumbs_fake_irq(unsigned long data)
* every jiffie in order to kick the oldest waiter to do the
* coherent seqno check.
*/
- if (intel_engine_wakeup(engine))
- mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
+ if (!intel_engine_wakeup(engine))
+ return;
+
+ mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
+
+ /* Ensure that even if the GPU hangs, we get woken up.
+*
+* However, note that if no one is waiting, we never notice
+* a gpu hang. Eventually, we will have to wait for a resource
+* held by the GPU and so trigger a hangcheck. In the most
+* pathological case, this will be upon memory starvation! To
+* prevent this, we also queue the hangcheck from the retire
+* worker.
+*/
+ i915_queue_hangcheck(engine->i915);
}
static void irq_enable(struct intel_engine_cs *engine)
@@ -179,13 +181,11 @@ static void __intel_breadcrumbs_enable_irq(struct
intel_breadcrumbs *b)
b->irq_enabled = true;
}
- if (!b->irq_enabled || use_fake_irq(b)) {
+ /* Ensure we never sleep indefinitely */
+ if (!b->irq_enabled || use_fake_irq(b))
mod_timer(&b->fake_irq, jiffies + 1);
- i915_queue_hangcheck(i915);
- } else {
- /* Ensure we never sleep indefinitely */
+ else
mod_timer(&b->hangcheck, wait_timeout());
- }
}
static void __intel_breadcrumbs_disable_irq(struct intel_breadcrumbs *b)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/4] drm/i915: Signal first fence from irq handler if complete
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.
v2: No need for early exit in irq handler - it breaks the flow between
patches and prevents the tracepoint
v3: Restore rcu hold across irq signaling of request
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 13 ++--
drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
drivers/gpu/drm/i915/i915_gem_request.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 36 +---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 32 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +++
6 files changed, 54 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c5b3dd9f6f1..ca2c986a48cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4073,9 +4073,9 @@ __i915_request_irq_complete(const struct
drm_i915_gem_request *req)
* is woken.
*/
if (engine->irq_seqno_barrier &&
- rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted)) {
- struct task_struct *tsk;
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ unsigned long flags;
/* The ordering of irq_posted versus applying the barrier
* is crucial. The clearing of the current irq_posted must
@@ -4097,17 +4097,16 @@ __i915_request_irq_complete(const struct
drm_i915_gem_request *req)
* the seqno before we believe it coherent since they see
* irq_posted == false but we are still running).
*/
- rcu_read_lock();
- tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
- if (tsk && tsk != current)
+ spin_lock_irqsave(&b->lock, flags);
+ if (b->first_wait && b->first_wait->tsk != current)
/* Note that if the bottom-half is changed as we
* are sending the wake-up, the new bottom-half will
* be woken by whomever made the change. We only have
* to worry about when we steal the irq-posted for
* ourself.
*/
- wake_up_process(tsk);
- rcu_read_unlock();
+ wake_up_process(b->first_wait->tsk);
+ spin_unlock_irqrestore(&b->lock, flags);
if (__i915_gem_request_completed(req, seqno))
return true;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index fbfeb5f8d069..77c3ee7a3fd0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1083,7 +1083,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
if (flags & I915_WAIT_LOCKED)
add_wait_queue(errq, &reset);
- intel_wait_init(&wait);
+ intel_wait_init(&wait, req);
restart:
do {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
b/drivers/gpu/drm/i915/i915_gem_request.h
index 5f73d8c0a38a..0efee879df23 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -32,10 +32,12 @@
struct drm_file;
struct drm_i915_gem_object;
+struct drm_i915_gem_request;
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
+ struct drm_i915_gem_request *request;
u32 seqno;
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc70e2c451b2..bc520ee8d6fe 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1033,12 +1033,42 @@ static void ironlake_rps_change_irq_handler(struct
drm_i915_private *dev_priv)
static void notify_ring(struct intel_engine_cs *engine)
{
- bool waiters;
+ struct drm_i915_gem_request *rq = NULL;
+ struct intel_wait *wait;
atomic_inc(&engine->irq_count);
set_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
- waiters = intel_engine_wakeup(engine);
- trace_intel_engine_notify(engine, waiters);
+
+ rcu_read_lo
Re: [Intel-gfx] I915 dmesg warnings on Mac Mini, solo core edition
On Sun, 26 Feb 2017, Enrico Mioso wrote: > Hello. I am not using this computer actively and can't report easily > on the state of the screen. Still, I observed the following situation > in the system's dmesg: running the stock Archlinux Kernel. This is an > Apple MacMini system, booted via an EFI bootloader. Please file a bug over at [1], add drm.debug=14 module parameter and attach the dmesg with that on the bug. Please also try v4.10 kernel or drm-tip branch of https://cgit.freedesktop.org/drm-tip. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware
On Mon, 27 Feb 2017, Joonas Lahtinen wrote:
> On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
>> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>>
>> Using the parameter disabled version checks and loads desired firmware
>> instead of the default one.
>>
>> Cc: Chris Wilson
>> Cc: Joonas Lahtinen
>> Cc: Michal Winiarski
>> Signed-off-by: Arkadiusz Hiler
>
>
>
>> @@ -230,6 +232,14 @@ module_param_named(guc_log_level, i915.guc_log_level,
>> int, 0400);
>> MODULE_PARM_DESC(guc_log_level,
>> "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
>>
>> +module_param_named(guc_firmware_path, i915.guc_firmware_path, charp, 0400);
>
> I'm pretty sure this should be _unsafe, because it overrides the
> version checks. Cc'd Jani for this.
Yes, please. I replied the same thing to Chris' patches adding the same
thing.
BR,
Jani.
>
>> @@ -479,7 +479,11 @@ void intel_guc_select_fw(struct intel_guc *guc)
>> guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
>> guc->fw.fw = INTEL_UC_FW_TYPE_GUC;
>>
>> -if (IS_SKYLAKE(dev_priv)) {
>> +if (i915.guc_firmware_path) {
>> +guc->fw.path = i915.guc_firmware_path;
>> +guc->fw.major_ver_wanted = 0;
>> +guc->fw.minor_ver_wanted = 0;
>
> Or, we could keep the wanted version number, only replace the path, and
> spit out WARN/taint kernel if some other version was detected?
>
> But I guess the main purpose is to override version (not provide
> request_firmware workarounds), so my vote is to make the param _unsafe.
>
> Regards, Joonas
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Prepare for async get_pages
In the next patch, we will allow for obj->mm.__pages to be populated
asynchronously. This means that simply acquiring a pages_pin_count is no
longer sufficient to be sure the pages are there, we need to acquire the
pin (to prevent the pages from disappearing again) and then wait for the
completion.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 26 +++---
drivers/gpu/drm/i915/i915_gem_clflush.c | 4 +-
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 14 --
drivers/gpu/drm/i915/i915_gem_gtt.c | 23 +++--
drivers/gpu/drm/i915/i915_gem_object.c | 61
drivers/gpu/drm/i915/i915_gem_object.h | 47 ++
drivers/gpu/drm/i915/i915_gem_render_state.c | 2 +-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +-
drivers/gpu/drm/i915/i915_gem_userptr.c | 48 +--
drivers/gpu/drm/i915/i915_vma.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 45 +++--
drivers/gpu/drm/i915/selftests/i915_vma.c| 6 +--
drivers/gpu/drm/i915/selftests/mock_gtt.c| 2 +-
16 files changed, 203 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0316215221f8..ce3d83f924bf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -596,7 +596,7 @@ i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
return ret;
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
- if (obj->mm.pages)
+ if (i915_gem_object_has_pages(obj))
return -EBUSY;
GEM_BUG_ON(obj->ops != &i915_gem_object_ops);
@@ -2144,7 +2144,7 @@ void __i915_gem_object_invalidate(struct
drm_i915_gem_object *obj)
struct address_space *mapping;
lockdep_assert_held(&obj->mm.lock);
- GEM_BUG_ON(obj->mm.pages);
+ GEM_BUG_ON(i915_gem_object_has_pages(obj));
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
@@ -3867,7 +3867,7 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
if (err)
goto out;
- if (obj->mm.pages &&
+ if (i915_gem_object_has_pages(obj) &&
i915_gem_object_is_tiled(obj) &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
if (obj->mm.madv == I915_MADV_WILLNEED) {
@@ -3886,7 +3886,8 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
obj->mm.madv = args->madv;
/* if the object is no longer attached, discard its backing storage */
- if (obj->mm.madv == I915_MADV_DONTNEED && !obj->mm.pages)
+ if (obj->mm.madv == I915_MADV_DONTNEED &&
+ !i915_gem_object_has_pages(obj))
i915_gem_object_truncate(obj);
args->retained = obj->mm.madv != __I915_MADV_PURGED;
@@ -3928,6 +3929,8 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
obj->mm.madv = I915_MADV_WILLNEED;
INIT_RADIX_TREE(&obj->mm.get_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(&obj->mm.get_page.lock);
+ init_completion(&obj->mm.complete);
+ complete_all(&obj->mm.complete);
i915_gem_info_add_obj(to_i915(obj->base.dev), obj->base.size);
}
@@ -4071,7 +4074,7 @@ static void __i915_gem_free_objects(struct
drm_i915_private *i915,
if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
atomic_set(&obj->mm.pages_pin_count, 0);
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
- GEM_BUG_ON(obj->mm.pages);
+ GEM_BUG_ON(i915_gem_object_has_pages(obj));
if (obj->base.import_attach)
drm_prime_gem_destroy(&obj->base, NULL);
@@ -4772,7 +4775,16 @@ i915_gem_object_create_from_data(struct drm_i915_private
*dev_priv,
if (ret)
goto fail;
- sg = obj->mm.pages;
+ ret = i915_gem_object_wait_for_pages(obj);
+ if (ret)
+ goto fail_unpin;
+
+ sg = i915_gem_object_pages(obj);
+ if (IS_ERR(sg)) {
+ ret = PTR_ERR(sg);
+ goto fail_unpin;
+ }
+
bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
obj->mm.dirty = true; /* Backing store is now out of date */
i915_gem_object_unpin_pages(obj);
@@ -4785,6 +4797,8 @@ i915_gem_object_create_from_data(struct drm_i915_private
*dev_priv,
return obj;
+fail_unpin:
+ i915_gem_object_unpin_pages(obj);
fail:
i915_gem_object_put(obj);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index d925fb582ba7..d68817231e98 100644
--- a/d
[Intel-gfx] Start planning for handling async pages, binding, everything
Currently we have a heavyweight EAGAIN loop round tripping to userspace to handle asynchronous loading. However, we now have fences to handle asynchronous execution. Fun times ahead. For starters, let's move the current asynchronous get_pages onto a more secure footing. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Exercise backing storage of mock gem objects
Check that we can retrieve the right page for a random index, and that
we can map the whole object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_object.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 405 +
.../gpu/drm/i915/selftests/i915_mock_selftests.h | 1 +
3 files changed, 407 insertions(+)
create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_object.c
diff --git a/drivers/gpu/drm/i915/i915_gem_object.c
b/drivers/gpu/drm/i915/i915_gem_object.c
index f222980cee34..30a704ea7e3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/i915_gem_object.c
@@ -409,4 +409,5 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object
*obj,
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/huge_gem_object.c"
+#include "selftests/i915_gem_object.c"
#endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
new file mode 100644
index ..1328332150f6
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
@@ -0,0 +1,405 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "../i915_selftest.h"
+#include "i915_random.h"
+
+#include "mock_gem_device.h"
+
+#define PFN_BIAS 0x1000
+
+static void fake_free_pages(struct drm_i915_gem_object *obj,
+ struct sg_table *pages)
+{
+ sg_free_table(pages);
+ kfree(pages);
+}
+
+static struct sg_table *
+fake_get_pages(struct drm_i915_gem_object *obj)
+{
+#define GFP (GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY)
+ struct sg_table *pages;
+ struct scatterlist *sg;
+ struct rnd_state prng;
+ unsigned long pfn, rem;
+
+ prandom_seed_state(&prng, obj->scratch);
+
+ pages = kmalloc(sizeof(*pages), GFP);
+ if (!pages)
+ return ERR_PTR(-ENOMEM);
+
+ rem = obj->base.size >> PAGE_SHIFT;
+ if (sg_alloc_table(pages, obj->base.size >> PAGE_SHIFT, GFP)) {
+ kfree(pages);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ pfn = PFN_BIAS;
+ for (sg = pages->sgl; sg; sg = sg_next(sg)) {
+ unsigned int len = 1 + prandom_u32_state(&prng) % rem;
+
+ sg_set_page(sg, pfn_to_page(pfn), len * PAGE_SIZE, 0);
+
+ pfn += len;
+ rem -= len;
+ if (!rem) {
+ sg_mark_end(sg);
+ break;
+ }
+ }
+ GEM_BUG_ON(rem);
+
+ obj->mm.madv = I915_MADV_DONTNEED;
+ return pages;
+#undef GFP
+}
+
+static void fake_put_pages(struct drm_i915_gem_object *obj,
+ struct sg_table *pages)
+{
+ fake_free_pages(obj, pages);
+ obj->mm.dirty = false;
+ obj->mm.madv = I915_MADV_WILLNEED;
+}
+
+static const struct drm_i915_gem_object_ops fake_ops = {
+ .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE,
+ .get_pages = fake_get_pages,
+ .put_pages = fake_put_pages,
+};
+
+static struct drm_i915_gem_object *
+fake_object(struct drm_i915_private *i915, u64 size, u32 seed)
+{
+ struct drm_i915_gem_object *obj;
+
+ GEM_BUG_ON(!size);
+ GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
+
+ if (overflows_type(size, obj->base.size))
+ return ERR_PTR(-E2BIG);
+
+ obj = i915_gem_object_alloc(i915);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ drm_gem_private_object_init(&i915->drm, &obj->base, size);
+ i915_gem_object_init(obj, &fake_ops);
+
+ obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+ obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj->cache_level = I915_CACHE_NONE;
+
+ obj->scratch = seed;
+
+ return obj;
+}
+
+static unsigned int *order_forward(unsigned int count, struct rnd_state *prng)
+{
[Intel-gfx] [PATCH 1/3] drm/i915: Start splitting out i915_gem_object routines
To begin with move obj->mm related operations to i915_gem_object.c, in
preparation for future tweaks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h| 107 --
drivers/gpu/drm/i915/i915_gem.c| 385 +--
drivers/gpu/drm/i915/i915_gem_object.c | 412 +
drivers/gpu/drm/i915/i915_gem_object.h | 112 +-
.../selftests/{i915_gem_object.c => i915_gem.c}| 4 +-
.../gpu/drm/i915/selftests/i915_live_selftests.h | 2 +-
.../gpu/drm/i915/selftests/i915_mock_selftests.h | 2 +-
8 files changed, 529 insertions(+), 496 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gem_object.c
rename drivers/gpu/drm/i915/selftests/{i915_gem_object.c => i915_gem.c} (99%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d1d8ec49791c..1dbbcd3e23b1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -40,6 +40,7 @@ i915-y += i915_cmd_parser.o \
i915_gem_gtt.o \
i915_gem_internal.o \
i915_gem.o \
+ i915_gem_object.o \
i915_gem_render_state.o \
i915_gem_request.o \
i915_gem_shrinker.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d76f9d16cc2..b88c6c58a860 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3285,113 +3285,6 @@ static inline int __sg_page_count(const struct
scatterlist *sg)
return sg->length >> PAGE_SHIFT;
}
-struct scatterlist *
-i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
- unsigned int n, unsigned int *offset);
-
-struct page *
-i915_gem_object_get_page(struct drm_i915_gem_object *obj,
-unsigned int n);
-
-struct page *
-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
- unsigned int n);
-
-dma_addr_t
-i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
- unsigned long n);
-
-void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
-struct sg_table *pages);
-int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
-
-static inline int __must_check
-i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
-{
- might_lock(&obj->mm.lock);
-
- if (atomic_inc_not_zero(&obj->mm.pages_pin_count))
- return 0;
-
- return __i915_gem_object_get_pages(obj);
-}
-
-static inline void
-__i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
-{
- GEM_BUG_ON(!obj->mm.pages);
-
- atomic_inc(&obj->mm.pages_pin_count);
-}
-
-static inline bool
-i915_gem_object_has_pinned_pages(struct drm_i915_gem_object *obj)
-{
- return atomic_read(&obj->mm.pages_pin_count);
-}
-
-static inline void
-__i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
-{
- GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
- GEM_BUG_ON(!obj->mm.pages);
-
- atomic_dec(&obj->mm.pages_pin_count);
-}
-
-static inline void
-i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
-{
- __i915_gem_object_unpin_pages(obj);
-}
-
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
- I915_MM_NORMAL = 0,
- I915_MM_SHRINKER
-};
-
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
-void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
-
-enum i915_map_type {
- I915_MAP_WB = 0,
- I915_MAP_WC,
-};
-
-/**
- * i915_gem_object_pin_map - return a contiguous mapping of the entire object
- * @obj: the object to map into kernel address space
- * @type: the type of mapping, used to select pgprot_t
- *
- * Calls i915_gem_object_pin_pages() to prevent reaping of the object's
- * pages and then returns a contiguous mapping of the backing storage into
- * the kernel address space. Based on the @type of mapping, the PTE will be
- * set to either WriteBack or WriteCombine (via pgprot_t).
- *
- * The caller is responsible for calling i915_gem_object_unpin_map() when the
- * mapping is no longer required.
- *
- * Returns the pointer through which to access the mapped object, or an
- * ERR_PTR() on error.
- */
-void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
- enum i915_map_type type);
-
-/**
- * i915_gem_object_unpin_map - releases an earlier mapping
- * @obj: the object to unmap
- *
- * After pinning the object and mapping its pages, once you are finished
- * with your access, call i915_gem_object_unpin_map() to release the pin
- * upon the mapping. Once the pin count reaches zero, that mapping may be
- * removed.
- */
-static inline void i915_gem_object_unpin_map(struct drm_i915_gem_object *obj)
-{
-
Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices
+Mika & Andy
On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> Several cherrytrail devices (all of which ship with windows 10) hide the
> lpss pwm controller in ACPI, typically the _STA method looks like this:
>
> Method (_STA, 0, NotSerialized) // _STA: Status
> {
> If (OSID == One)
> {
> Return (Zero)
> }
>
> Return (0x0F)
> }
>
> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
> the machine behave differently depending on which OS it *thinks* it is
> booting, this gets set in a number of ways which we cannot control, on
> some newer machines it simple hardcoded to "One" aka win10.
>
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
>
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only use it when it needs it), this
> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> for the 80862288 device, fixing the lack of backlight control.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/acpi/bus.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 95855cb..483d4d0 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle
> handle,
> return status;
> }
>
> +/*
> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
> + * some recent windows drivers bind to one device but poke at multiple
> + * devices at the same time, so the others get hidden.
> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> + * devices. Note this MUST only be done for devices where this is safe.
> + */
> +static const struct acpi_device_id always_present_device_ids[] = {
> + /*
> + * Cherrytrail pwm directly poked by GPU driver in win10,
> + * but Linux uses a separate pwm driver, harmless if not used.
> + */
> + { "80862288", },
> + { }
> +};
> +
> int acpi_bus_get_status(struct acpi_device *device)
> {
> acpi_status status;
> unsigned long long sta;
>
> + /* acpi_match_device_ids checks status, so start with default */
> + acpi_set_device_status(device, ACPI_STA_DEFAULT);
This shouldn't be done in a "get" routine.
Ideally, a scan handler should do that or similar.
> + if (acpi_match_device_ids(device, always_present_device_ids) == 0) {
> + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] is in always
> present list setting status [%08x]\n",
> + device->pnp.bus_id, ACPI_STA_DEFAULT));
pr_debug() please. The ACPI_DEBUG_PRINT() stuff is basically for ACPICA
(yes, I know it is used elsewhere and no, it is not a good idea to do that).
> + return 0;
> + }
> + acpi_set_device_status(device, 0);
> +
> status = acpi_bus_get_status_handle(device->handle, &sta);
> if (ACPI_FAILURE(status))
> return -ENODEV;
>
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT
On 02/27/2017 10:13 AM, Xu, Terrence wrote: [Xu, Terrence] Yes the root is needed for all our "echo" related commands, can I suppose the case is running under root privilege? Or need to return "skip" when it is not under root privilege? Right, seems I was a bit confused there and there are other cases where root rights are required. Assuming root privileges is fine, especially if you're nice and warn the user if proper rights are not active. Can the tool be used as a normal user at all? -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs
On 27/02/2017 13:24, Chris Wilson wrote:
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.
v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 148 ---
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +-
4 files changed, 105 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01dbba3813c7..0ad080984877 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2988,8 +2988,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wait_for(intel_execlists_idle(dev_priv), 10))
DRM_ERROR("Timeout waiting for engines to idle\n");
- for_each_engine(engine, dev_priv, id)
+ for_each_engine(engine, dev_priv, id) {
+ intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(&engine->batch_pool);
+ }
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc520ee8d6fe..ca8c7b22748e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1060,6 +1060,8 @@ static void notify_ring(struct intel_engine_cs *engine)
rq = wait->request;
wake_up_process(wait->tsk);
+ } else {
+ __intel_engine_disarm_breadcrumbs(engine);
}
spin_unlock(&engine->breadcrumbs.lock);
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3855c8c39b35..ebb7bc0be9fb 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,19 +26,28 @@
#include "i915_drv.h"
-unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+static unsigned int __intel_engine_wakeup(struct intel_engine_cs *engine)
{
struct intel_wait *wait;
- unsigned long flags;
unsigned int result = 0;
- spin_lock_irqsave(&engine->breadcrumbs.lock, flags);
wait = engine->breadcrumbs.first_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
- if (!wake_up_process(wait->tsk))
- result |= ENGINE_WAKEUP_ACTIVE;
+ if (wake_up_process(wait->tsk))
+ result |= ENGINE_WAKEUP_ASLEEP;
}
+
+ return result;
+}
+
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+ unsigned int result = 0;
Can drop the init now.
+
+ spin_lock_irqsave(&engine->breadcrumbs.lock, flags);
+ result = __intel_engine_wakeup(engine);
spin_unlock_irqrestore(&engine->breadcrumbs.lock, flags);
return result;
@@ -54,7 +63,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct intel_breadcrumbs *b = &engine->breadcrumbs;
- if (!b->irq_enabled)
+ if (!b->irq_armed)
return;
if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
* to process the pending interrupt (e.g, low priority task on a loaded
* system) and wait until it sleeps before declaring a missed interrupt.
*/
- if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
+ if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
I did not get the explanation from the previous round on why you had to
reverse the active to asleep. Here it even looks wrong now, because I
thought you don't want to re-queue the hangcheck when there are no waiters?
mod_timer(&b->hangcheck, wait_timeout());
return;
}
@@ -80,6 +89,8 @@ static
[Intel-gfx] [CI 1/3] drm/i915: Remove redundant TLB invalidate on switching contexts
We are required to reload the TLBs around context switches
(MI_SET_CONTEXT specifically) and the recommendation is do that before
the MI_SET_CONTEXT so that it is serialised with the switch and not
forgotten:
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT entries).
This can be done by a pipeline PIPE_CONTROL with TLB inv bit set
immediately before MI_SET_CONTEXT.
However, we already do an unconditional TLB invalidate before every
batch so this condition is satifisfied.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 99c46f4dbde6..521e6f4705b1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -607,17 +607,6 @@ mi_set_context(struct drm_i915_gem_request *req, u32
hw_flags)
0;
int len;
- /* w/a: If Flush TLB Invalidation Mode is enabled, driver must do a TLB
-* invalidation prior to MI_SET_CONTEXT. On GEN6 we don't set the value
-* explicitly, so we rely on the value at ring init, stored in
-* itlb_before_ctx_switch.
-*/
- if (IS_GEN6(dev_priv)) {
- int ret = engine->emit_flush(req, EMIT_INVALIDATE);
- if (ret)
- return ret;
- }
-
/* These flags are for resource streamer on HSW+ */
if (IS_HASWELL(dev_priv) || INTEL_GEN(dev_priv) >= 8)
flags |= (HSW_MI_RS_SAVE_STATE_EN | HSW_MI_RS_RESTORE_STATE_EN);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915: Remove redundant TLB invalidate on switching ppgtt
We are required to reload the TLBs around ppgtt switches. However, we
already do an unconditional TLB invalidate before every batch and a flush
afterwards, so this condition is already satisfied without extra flushes
around the LRI instructions.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 875a48b9d05a..e0c9542a90c1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1464,13 +1464,8 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
{
struct intel_engine_cs *engine = req->engine;
u32 *cs;
- int ret;
/* NB: TLBs must be flushed and invalidated before a switch */
- ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
- if (ret)
- return ret;
-
cs = intel_ring_begin(req, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -1491,13 +1486,8 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
{
struct intel_engine_cs *engine = req->engine;
u32 *cs;
- int ret;
/* NB: TLBs must be flushed and invalidated before a switch */
- ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
- if (ret)
- return ret;
-
cs = intel_ring_begin(req, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -1510,13 +1500,6 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
*cs++ = MI_NOOP;
intel_ring_advance(req, cs);
- /* XXX: RCS is the only one to auto invalidate the TLBs? */
- if (engine->id != RCS) {
- ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
- if (ret)
- return ret;
- }
-
return 0;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915: Reduce context alignment
No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 17 -
drivers/gpu/drm/i915/i915_gem_context.h | 2 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 ++-
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 521e6f4705b1..baceca14f5e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -92,21 +92,6 @@
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
-/* This is a HW constraint. The value below is the largest known requirement
- * I've seen in a spec to date, and that was a workaround for a non-shipping
- * part. It should be safe to decrease this, but it's more future proof as is.
- */
-#define GEN6_CONTEXT_ALIGN (64<<10)
-#define GEN7_CONTEXT_ALIGN I915_GTT_MIN_ALIGNMENT
-
-static size_t get_context_alignment(struct drm_i915_private *dev_priv)
-{
- if (IS_GEN6(dev_priv))
- return GEN6_CONTEXT_ALIGN;
-
- return GEN7_CONTEXT_ALIGN;
-}
-
static int get_context_size(struct drm_i915_private *dev_priv)
{
int ret;
@@ -281,8 +266,6 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(&ctx->link, &dev_priv->context_list);
ctx->i915 = dev_priv;
- ctx->ggtt_alignment = get_context_alignment(dev_priv);
-
if (dev_priv->hw_context_size) {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 0ac750b90f3d..81268c9770a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -140,8 +140,6 @@ struct i915_gem_context {
*/
int priority;
- /** ggtt_alignment: alignment restriction for context objects */
- u32 ggtt_alignment;
/** ggtt_offset_bias: placement restriction for context objects */
u32 ggtt_offset_bias;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index f62afffef682..4a864f8c9387 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1431,7 +1431,8 @@ static int context_pin(struct i915_gem_context *ctx)
return ret;
}
- return i915_vma_pin(vma, 0, ctx->ggtt_alignment, PIN_GLOBAL | PIN_HIGH);
+ return i915_vma_pin(vma, 0, I915_GTT_MIN_ALIGNMENT,
+ PIN_GLOBAL | PIN_HIGH);
}
static int intel_ring_context_pin(struct intel_engine_cs *engine,
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Scrub vol. 1 (rev7)
== Series Details == Series: GuC Scrub vol. 1 (rev7) URL : https://patchwork.freedesktop.org/series/16856/ State : failure == Summary == In file included from drivers/gpu/drm/i915/i915_drv.h:60:0, from drivers/gpu/drm/i915/i915_gem_execbuffer.c:37: drivers/gpu/drm/i915/intel_uc.h:188:1: error: expected identifier or ‘(’ before ‘<<’ token <<< df1dec2d5faca106a651e75b02b845fa246ec77f ^ drivers/gpu/drm/i915/intel_uc.h:193:1: error: expected identifier or ‘(’ before ‘>>’ token >>> drm/i915/uc: Introduce intel_uc_init_fw() ^ LD drivers/pci/pcie/aer/built-in.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/intel_device_info.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_device_info.o] Error 1 scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/intel_csr.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_csr.o] Error 1 LD drivers/pci/pcie/built-in.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_gem_batch_pool.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_batch_pool.o] Error 1 scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_gem_evict.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_evict.o] Error 1 scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/intel_pipe_crc.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_pipe_crc.o] Error 1 scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_cmd_parser.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_cmd_parser.o] Error 1 scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_debugfs.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_debugfs.o] Error 1 LD drivers/acpi/acpica/built-in.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_ioc32.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_ioc32.o] Error 1 LD drivers/acpi/built-in.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_gem_clflush.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_clflush.o] Error 1 scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_gem_dmabuf.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_dmabuf.o] Error 1 LD drivers/scsi/scsi_mod.o LD drivers/usb/gadget/udc/udc-core.o LD drivers/usb/gadget/udc/built-in.o LD net/netlink/built-in.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/intel_runtime_pm.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_runtime_pm.o] Error 1 LD drivers/usb/gadget/built-in.o LD drivers/video/fbdev/core/fb.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_gem_execbuffer.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_execbuffer.o] Error 1 LD drivers/video/fbdev/core/built-in.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_gem_context.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_context.o] Error 1 LD drivers/tty/serial/8250/8250_base.o LD drivers/video/fbdev/built-in.o LD drivers/tty/serial/8250/built-in.o LD drivers/tty/serial/built-in.o scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/intel_pm.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_pm.o] Error 1 scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 make[1]: *** Waiting for unfinished jobs LD net/unix/unix.o AR lib/lib.a LD drivers/pci/built-in.o LD net/unix/built-in.o EXPORTS lib/lib-ksyms.o LD lib/built-in.o LD drivers/usb/core/usbcore.o LD drivers/video/console/built-in.o LD drivers/video/built-in.o LD drivers/usb/core/built-in.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD drivers/scsi/sd_mod.o LD drivers/scsi/built-in.o LD net/xfrm/built-in.o LD net/packet/built-in.o LD drivers/tty/vt/built-in.o CC arch/x86/kernel/cpu/capflags.o LD drivers/tty/built-in.o LD arch/x86/kernel/cpu/built-in.o LD fs/btrfs/btrfs.o LD arch/x86/kernel/built-in.o LD fs/btrfs/built-in.o LD net/ipv6/ipv6.o LD arch/x86/built-in.o LD net/ipv6/built-in.o LD drivers/usb/host/xhci-hcd.o LD drivers/md/md-mod.o LD drivers/md/built-in.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD fs/ext4/ext4.o LD fs/ext4/built-in.o LD fs/built-in.o LD net/core/built-in.o LD net/ipv4/built-in.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD net/built-in.o LD drivers
Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs
On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
>
> On 27/02/2017 13:24, Chris Wilson wrote:
> > if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
> >@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
> > * to process the pending interrupt (e.g, low priority task on a loaded
> > * system) and wait until it sleeps before declaring a missed interrupt.
> > */
> >-if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
> >+if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
>
> I did not get the explanation from the previous round on why you had
> to reverse the active to asleep. Here it even looks wrong now,
> because I thought you don't want to re-queue the hangcheck when
> there are no waiters?
No waiters: result = 0
Running waiter: result = WAKEUP_WAITER
Sleeping waiter: result = WAKEUP_WAITER | WAKEUP_ASLEEP
We only want to declare a mised irq if we wake up a sleeping waiter, and
keep the hangcheck timer running until the device is idle (when the irq
is disarmed).
How about:
if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
set_bit(missed_irq);
mod_timer(&b->fake_irq, jiffies + 1);
} else {
mod_timer(b->hangcheck, wait_timeout);
}
?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs
On Mon, Feb 27, 2017 at 02:06:58PM +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
> >
> > On 27/02/2017 13:24, Chris Wilson wrote:
> > > if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
> > >@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long
> > >data)
> > >* to process the pending interrupt (e.g, low priority task on a loaded
> > >* system) and wait until it sleeps before declaring a missed interrupt.
> > >*/
> > >- if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
> > >+ if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
> >
> > I did not get the explanation from the previous round on why you had
> > to reverse the active to asleep. Here it even looks wrong now,
> > because I thought you don't want to re-queue the hangcheck when
> > there are no waiters?
>
> No waiters: result = 0
> Running waiter: result = WAKEUP_WAITER
> Sleeping waiter: result = WAKEUP_WAITER | WAKEUP_ASLEEP
>
> We only want to declare a mised irq if we wake up a sleeping waiter, and
> keep the hangcheck timer running until the device is idle (when the irq
> is disarmed).
>
> How about:
>
> if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
> set_bit(missed_irq);
> mod_timer(&b->fake_irq, jiffies + 1);
> } else {
> mod_timer(b->hangcheck, wait_timeout);
> }
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index ebb7bc0be9fb..004eb4c0c531 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -72,18 +72,25 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
return;
}
- /* If the waiter was currently running, assume it hasn't had a chance
+ /* We keep the hangcheck time alive until we disarm the irq, even
+* if there are no waiters at present.
+*
+* If the waiter was currently running, assume it hasn't had a chance
* to process the pending interrupt (e.g, low priority task on a loaded
* system) and wait until it sleeps before declaring a missed interrupt.
+*
+* If the waiter was asleep (and not even pending a wakeup), then we
+* must have missed an interrupt as the GPU has stopped advancing
+* but we still have a waiter. Assuming all batches complete within
+* DRM_I915_HANGCHECK_JIFFIES [1.5s]!
*/
- if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
+ if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
+ DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
+ set_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings);
+ mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
+ } else {
mod_timer(&b->hangcheck, wait_timeout());
- return;
}
-
- DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
- set_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings);
- mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
}
static void intel_breadcrumbs_fake_irq(unsigned long data)
@@ -167,6 +174,10 @@ void intel_engine_disarm_breadcrumbs(struct
intel_engine_cs *engine)
spin_lock_irqsave(&b->lock, flags);
+ /* We only disarm the irq when we are idle (all requests completed),
+* so if there remains a sleeping waiter, it missed the request
+* completion.
+*/
if (__intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)
set_bit(engine->id, &engine->i915->gpu_error.missed_irq_rings);
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Defer unmasking RPS interrupts until after making adjustments
To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 29b10bab38b6..0dfd434584aa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1120,30 +1120,21 @@ static void gen6_pm_rps_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
container_of(work, struct drm_i915_private, rps.work);
- bool client_boost;
+ bool client_boost = false;
int new_delay, adj, min, max;
- u32 pm_iir;
+ u32 pm_iir = 0;
spin_lock_irq(&dev_priv->irq_lock);
- /* Speed up work cancelation during disabling rps interrupts. */
- if (!dev_priv->rps.interrupts_enabled) {
- spin_unlock_irq(&dev_priv->irq_lock);
- return;
+ if (dev_priv->rps.interrupts_enabled) {
+ pm_iir = fetch_and_zero(&dev_priv->rps.pm_iir);
+ client_boost = fetch_and_zero(&dev_priv->rps.client_boost);
}
-
- pm_iir = dev_priv->rps.pm_iir;
- dev_priv->rps.pm_iir = 0;
- /* Make sure not to corrupt PMIMR state used by ringbuffer on GEN6 */
- gen6_unmask_pm_irq(dev_priv, dev_priv->pm_rps_events);
- client_boost = dev_priv->rps.client_boost;
- dev_priv->rps.client_boost = false;
spin_unlock_irq(&dev_priv->irq_lock);
/* Make sure we didn't queue anything we're not going to process. */
WARN_ON(pm_iir & ~dev_priv->pm_rps_events);
-
if ((pm_iir & dev_priv->pm_rps_events) == 0 && !client_boost)
- return;
+ goto out;
mutex_lock(&dev_priv->rps.hw_lock);
@@ -1200,6 +1191,13 @@ static void gen6_pm_rps_work(struct work_struct *work)
}
mutex_unlock(&dev_priv->rps.hw_lock);
+
+out:
+ /* Make sure not to corrupt PMIMR state used by ringbuffer on GEN6 */
+ spin_lock_irq(&dev_priv->irq_lock);
+ if (dev_priv->rps.interrupts_enabled)
+ gen6_unmask_pm_irq(dev_priv, dev_priv->pm_rps_events);
+ spin_unlock_irq(&dev_priv->irq_lock);
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail
On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
compute everything from the UP_EI which does seem to correspond to the
desired interval.
v2: Fixup gen6_rps_pm_mask() as well
Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: # v4.1+
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 28 +---
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
3 files changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c5b3dd9f6f1..d70bbbd6a5fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1366,7 +1366,7 @@ struct intel_gen6_power_mgmt {
unsigned boosts;
/* manual wa residency calculations */
- struct intel_rps_ei up_ei, down_ei;
+ struct intel_rps_ei ei;
/*
* Protects RPS/RC6 register access and PCU communication.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc70e2c451b2..29b10bab38b6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1050,10 +1050,10 @@ static void vlv_c0_read(struct drm_i915_private
*dev_priv,
}
static bool vlv_c0_above(struct drm_i915_private *dev_priv,
-const struct intel_rps_ei *old,
const struct intel_rps_ei *now,
int threshold)
{
+ const struct intel_rps_ei *old = &dev_priv->rps.ei;
u64 time, c0;
unsigned int mul = 100;
@@ -1079,8 +1079,7 @@ static bool vlv_c0_above(struct drm_i915_private
*dev_priv,
void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
{
- vlv_c0_read(dev_priv, &dev_priv->rps.down_ei);
- dev_priv->rps.up_ei = dev_priv->rps.down_ei;
+ memset(&dev_priv->rps.ei, 0, sizeof(dev_priv->rps.ei));
}
static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)
@@ -1088,28 +1087,19 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private
*dev_priv, u32 pm_iir)
struct intel_rps_ei now;
u32 events = 0;
- if ((pm_iir & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED))
== 0)
+ if ((pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) == 0)
return 0;
vlv_c0_read(dev_priv, &now);
if (now.cz_clock == 0)
return 0;
- if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
- if (!vlv_c0_above(dev_priv,
- &dev_priv->rps.down_ei, &now,
- dev_priv->rps.down_threshold))
- events |= GEN6_PM_RP_DOWN_THRESHOLD;
- dev_priv->rps.down_ei = now;
- }
+ if (vlv_c0_above(dev_priv, &now, dev_priv->rps.up_threshold))
+ events |= GEN6_PM_RP_UP_THRESHOLD;
+ else if (!vlv_c0_above(dev_priv, &now, dev_priv->rps.down_threshold))
+ events |= GEN6_PM_RP_DOWN_THRESHOLD;
- if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
- if (vlv_c0_above(dev_priv,
-&dev_priv->rps.up_ei, &now,
-dev_priv->rps.up_threshold))
- events |= GEN6_PM_RP_UP_THRESHOLD;
- dev_priv->rps.up_ei = now;
- }
+ dev_priv->rps.ei = now;
return events;
}
@@ -4250,7 +4240,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
/* Let's track the enabled rps events */
if (IS_VALLEYVIEW(dev_priv))
/* WaGsvRC0ResidencyMethod:vlv */
- dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED |
GEN6_PM_RP_UP_EI_EXPIRED;
+ dev_priv->pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED;
else
dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ac0cd82f61e5..56472905d782 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4916,8 +4916,9 @@ static u32 gen6_rps_pm_mask(struct drm_i915_private
*dev_priv, u8 val)
{
u32 mask = 0;
+ /* We use UP_EI_EXPIRED interupts for both up/down in manual mode */
if (val > dev_priv->rps.min_freq_softlimit)
- mask |= GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD
| GEN6_PM_RP_DOWN_TIMEOUT;
+ mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD |
GEN6_PM_RP_DOWN_TIMEOUT;
if (val < dev_priv->rps.max_freq_softlimit)
mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_UP_THRESHOLD;
@@ -5027,7 +5028,7 @@ vo
Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices
Hi,
On 27-02-17 14:30, Rafael J. Wysocki wrote:
+Mika & Andy
On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
Several cherrytrail devices (all of which ship with windows 10) hide the
lpss pwm controller in ACPI, typically the _STA method looks like this:
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}
Return (0x0F)
}
Where OSID is some dark magic seen in all cherrytrail ACPI tables making
the machine behave differently depending on which OS it *thinks* it is
booting, this gets set in a number of ways which we cannot control, on
some newer machines it simple hardcoded to "One" aka win10.
This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.
Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only use it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the 80862288 device, fixing the lack of backlight control.
Signed-off-by: Hans de Goede
---
drivers/acpi/bus.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..483d4d0 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle handle,
return status;
}
+/*
+ * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
+ * some recent windows drivers bind to one device but poke at multiple
+ * devices at the same time, so the others get hidden.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for devices where this is safe.
+ */
+static const struct acpi_device_id always_present_device_ids[] = {
+ /*
+* Cherrytrail pwm directly poked by GPU driver in win10,
+* but Linux uses a separate pwm driver, harmless if not used.
+*/
+ { "80862288", },
+ { }
+};
+
int acpi_bus_get_status(struct acpi_device *device)
{
acpi_status status;
unsigned long long sta;
+ /* acpi_match_device_ids checks status, so start with default */
+ acpi_set_device_status(device, ACPI_STA_DEFAULT);
This shouldn't be done in a "get" routine.
With this you mean the acpi_match_device_ids() check I assume ?
(acpi_bus_get_status already calls acpi_set_device_status())
Ideally, a scan handler should do that or similar.
The problem is that drivers/acpi/scan.c: acpi_bus_attach()
calls acpi_bus_get_status() and if it does not set
the status to present acpi_bus_attach() exits without bothering
with attaching scan handlers, which is why I ended up doing this
here.
+ if (acpi_match_device_ids(device, always_present_device_ids) == 0) {
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] is in always present
list setting status [%08x]\n",
+ device->pnp.bus_id, ACPI_STA_DEFAULT));
pr_debug() please. The ACPI_DEBUG_PRINT() stuff is basically for ACPICA
(yes, I know it is used elsewhere and no, it is not a good idea to do that).
Ok, that is easy to fix :)
+ return 0;
+ }
+ acpi_set_device_status(device, 0);
+
status = acpi_bus_get_status_handle(device->handle, &sta);
if (ACPI_FAILURE(status))
return -ENODEV;
Thanks,
Rafael
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating
On 27/02/2017 10:21, Chris Wilson wrote: On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote: On 27/02/2017 10:06, Chris Wilson wrote: On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote: On 22/02/2017 08:44, Chris Wilson wrote: I also think that's an argument for improving the general cache rather than arguing against using it. Well I wasn't concerned about the cache per se, but about whether it is completely appropriate (best choice) to use it in this particular case. Because as I said before, for 1920x1080x32 we are talking about a 16KiB extremely short lived temporary allocation, vs the similar size for the sg radix cache. But radix cache sticks around the the lifetime of obj->mm.pages and it wouldn't otherwise be there since AFAICS in practice no one really touches frame buffers in a way to trigger its creation. Those amounts of memory are not a concern, but again, is the simplification of the code worth the conceptual downsides mentioned above? Even if we considered 4K frame buffers, when both allocations go to ~64KiB, would that change anything? I am not sure, probably not for me. So I am still unsure that we should go with this change. Again, the complaint you have here are general concerns about caching the mapping. Avoiding using the cache instead of improving the cache seems the wrong approach. Depends what kind of improvments to the cache you have in mind. If you are thinking about size then I disagree, I think it is efficient enough already. But if you are thinking about the lifetime management then it is obvious from all that I have written so far that I would agree with that. Since the core of my "complaint" is the lifetime mismatch, and not the size. For lifetime I am not sure what you could do. Exposing the size of it, with maybe some other bits attached the the object, to the shrinker I think doesn't make much sense since the sizes are so small compared to the backing store sizes. Perhaps you could add an explicit reset of the cache after the rotation is done with it, but then the only remaining benefit will be avoiding greater than zero order allocations. I say the only one.. it would still be a good one. Just have no idea if this level of cache usage would satisfy you! Perhaps you could say what kind of optimisation you have in mind to save me guessing? :) I was thinking you would like an inactivity timer. Or we could have a separate shrinker, as that's the principal cache management system. I thought about the shrinker myself. Even wrote some code to more accurately size the objects as part of the existing passes. But as I said the contribution of anything object and not backing store is so small that, even though it would conceptually be more correct and perhaps avoid some marginal over-shrinking, I am not sure it is worth doing it. Assuming of course that I got the sizing of the radix tree correct! I just hacked something up based on some debug dumping code from radix-tree.c. So the complication is there is no API to get the size of the radix tree (or the scatter list table) and we would have to add something, either internally to i915, or try and upstream it. Or we avoid that with your timer idea and just purge all caches which haven't been used in a while. Maybe from idle work or something. But for this immediate patch, would you be happy with adding and exporting i915_gem_object_reset_page_iter and calling it after rotation is done with accessing the pages? Benefit would be avoidance of drm_malloc_gfp if that bothers you most. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices
On Mon, 27 Feb 2017 15:25:32 +0100,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 14:30, Rafael J. Wysocki wrote:
> > +Mika & Andy
> >
> > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> >> Several cherrytrail devices (all of which ship with windows 10) hide the
> >> lpss pwm controller in ACPI, typically the _STA method looks like this:
> >>
> >> Method (_STA, 0, NotSerialized) // _STA: Status
> >> {
> >> If (OSID == One)
> >> {
> >> Return (Zero)
> >> }
> >>
> >> Return (0x0F)
> >> }
> >>
> >> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
> >> the machine behave differently depending on which OS it *thinks* it is
> >> booting, this gets set in a number of ways which we cannot control, on
> >> some newer machines it simple hardcoded to "One" aka win10.
> >>
> >> This causes the PWM controller to get hidden, which means Linux cannot
> >> control the backlight level on cht based tablets / laptops.
> >>
> >> Since loading the driver for this does no harm (the only in kernel user
> >> of it is the i915 driver, which will only use it when it needs it), this
> >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> >> for the 80862288 device, fixing the lack of backlight control.
> >>
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/acpi/bus.c | 25 +
> >> 1 file changed, 25 insertions(+)
> >>
> >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> >> index 95855cb..483d4d0 100644
> >> --- a/drivers/acpi/bus.c
> >> +++ b/drivers/acpi/bus.c
> >> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle
> >> handle,
> >>return status;
> >> }
> >>
> >> +/*
> >> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
> >> + * some recent windows drivers bind to one device but poke at multiple
> >> + * devices at the same time, so the others get hidden.
> >> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> >> + * devices. Note this MUST only be done for devices where this is safe.
> >> + */
> >> +static const struct acpi_device_id always_present_device_ids[] = {
> >> + /*
> >> + * Cherrytrail pwm directly poked by GPU driver in win10,
> >> + * but Linux uses a separate pwm driver, harmless if not used.
> >> + */
> >> + { "80862288", },
> >> + { }
> >> +};
> >> +
> >> int acpi_bus_get_status(struct acpi_device *device)
> >> {
> >>acpi_status status;
> >>unsigned long long sta;
> >>
> >> + /* acpi_match_device_ids checks status, so start with default */
> >> + acpi_set_device_status(device, ACPI_STA_DEFAULT);
> >
> > This shouldn't be done in a "get" routine.
>
> With this you mean the acpi_match_device_ids() check I assume ?
> (acpi_bus_get_status already calls acpi_set_device_status())
>
> > Ideally, a scan handler should do that or similar.
>
> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
> calls acpi_bus_get_status() and if it does not set
> the status to present acpi_bus_attach() exits without bothering
> with attaching scan handlers, which is why I ended up doing this
> here.
Oh, this is interesting, please let me join to the party.
We've hit a similar problem, but for other one: namely, it's INT0002
that is found on a few CHT devices. It's never bound properly by a
similar reason, where _STA is always zero on Linux:
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (SOCS <= 0x04)
{
Return (0x0F)
}
Else
{
Return (Zero)
}
}
The device is supposed to be a "virtual GPIO" stuff, and the driver
hasn't been upstreamed from Intel. Due to the lack of this driver
(and it's binding), the machine gets spurious IRQ#9 after the PM
resume, and it locks up at the second time of PM.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5,1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()
== Series Details == Series: series starting with [v5,1/4] drm/i915: Report both waiters and success from intel_engine_wakeup() URL : https://patchwork.freedesktop.org/series/20310/ State : failure == Summary == Series 20310v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20310/revisions/1/mbox/ Test gvt_basic: Subgroup invalid-placeholder-test: skip -> INCOMPLETE (fi-hsw-4770r) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:15 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s UTC integration manifest c311b6b drm/i915: Delay disabling the user interrupt for breadcrumbs 980339f drm/i915: Defer enabling hangcheck to the first fake breadcrumb interrupt 87cda8e drm/i915: Signal first fence from irq handler if complete 8c2c5a6 drm/i915: Report both waiters and success from intel_engine_wakeup() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3982/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5,1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()
On Mon, Feb 27, 2017 at 02:52:27PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v5,1/4] drm/i915: Report both waiters and > success from intel_engine_wakeup() > URL : https://patchwork.freedesktop.org/series/20310/ > State : failure > > == Summary == > > Series 20310v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/20310/revisions/1/mbox/ > > Test gvt_basic: > Subgroup invalid-placeholder-test: > skip -> INCOMPLETE (fi-hsw-4770r) CI lost communication with the host? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level
On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > Handle debugfs override edid and firmware edid at the low level to
> > transparently and completely replace the real edid. Previously, we
> > practically only used the modes from the override EDID, and none of the
> > other data. This also prevents actual EDID reads when the EDID is to be
> > overridden, but retains the DDC probe.
> >
> > Move firmware EDID loading from helper to core, as the functionality
> > moves to lower level as well. This will result in a change of module
> > parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
> > arguably makes more sense anyway.
> >
> > FIXME: validate override edid, deduplicate firmware edid validation.
> >
> > v2: move firmware loading to core
> >
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/Kconfig| 2 +-
> > drivers/gpu/drm/Makefile | 2 +-
> > drivers/gpu/drm/drm_edid.c | 15 +++
> > drivers/gpu/drm/drm_probe_helper.c | 19 +--
> > 4 files changed, 18 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 90bc65d07a35..f983ef60299c 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
> >
> > config DRM_LOAD_EDID_FIRMWARE
> > bool "Allow to specify an EDID data set instead of probing for it"
> > - depends on DRM_KMS_HELPER
> > + depends on DRM
> > help
> > Say Y here, if you want to use EDID data to be loaded from the
> > /lib/firmware directory or one of the provided built-in
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 92de3991fa56..a10ac095608f 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> > drm-$(CONFIG_OF) += drm_of.o
> > drm-$(CONFIG_AGP) += drm_agpsupport.o
> > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > +drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >
> > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > drm_simple_kms_helper.o drm_modeset_helper.o
> >
> > -drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> > drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index e1743ab276dc..4007998d5ce3 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector
> > *connector,
> > * level, drivers must make all reasonable efforts to expose it as an I2C
> > * adapter and use drm_get_edid() instead of abusing this function.
> > *
> > + * The EDID may be overridden using debugfs override_edid or firmare EDID
> > + * (drm_load_edid_firmware()), in this priority order. Having either of
> > them
> > + * bypasses actual EDID reads.
> > + *
> > * Return: Pointer to valid EDID or NULL if we couldn't find any.
> > */
> > struct edid *drm_do_get_edid(struct drm_connector *connector,
> > @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector
> > *connector,
> > {
> > int i, j = 0, valid_extensions = 0;
> > u8 *edid, *new;
> > + struct edid *override = NULL;
> > +
> > + if (connector->override_edid)
> > + override = drm_edid_duplicate((const struct edid *)
> > + connector->edid_blob_ptr->data);
> > +
> > + if (!override)
> > + override = drm_load_edid_firmware(connector);
> > +
> > + if (!IS_ERR_OR_NULL(override))
> > + return override;
> >
> > if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > return NULL;
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 358957118ca9..871326cbc465 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector,
> > bool force)
> > *drm_mode_probed_add(). New modes start their life with status as OK.
> > *Modes are added from a single source using the following priority
> > order.
> > *
> > - *- debugfs 'override_edid' (used for testing only)
> > - *- firmware EDID (drm_load_edid_firmware())
> > *- &drm_connector_helper_funcs.get_modes vfunc
> > *- if the connector status is connector_status_connected, standard
> > * VESA DM
Re: [Intel-gfx] [PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS
On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
> On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engine
> > the location of the color control surfae (CCS) which describes which
> > parts of the main surface are compressed and which are not. The location
> > of CCS is provided by userspace as just another plane with its own offset.
> >
> > By providing our own format information for the CCS formats, we should
> > be able to make framebuffer_check() do the right thing for the CCS
> > surface as well.
> >
> > Note that we'll return the same format info for both Y and Yf tiled
> > format as that's what happens with the non-CCS Y vs. Yf as well. If
> > desired, we could potentially return a unique pointer for each
> > pixel_format+tiling+ccs combination, in which case we immediately be
> > able to tell if any of that stuff changed by just comparing the
> > pointers. But that does sound a bit wasteful space wise.
> >
> > v2: Drop the 'dev' argument from the hook
> > v3: Include the description of the CCS surface layout
> >
> > Cc: Vandana Kannan
> > Cc: Daniel Vetter
> > Cc: Ben Widawsky
> > Cc: Jason Ekstrand
> > Reviewed-by: Ben Widawsky
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 36 ++
> > include/uapi/drm/drm_fourcc.h| 49
> >
> > 2 files changed, 85 insertions(+)
>
>
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 9e1bb7fabcde..4581e3d41e5c 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -230,6 +230,55 @@ extern "C" {
> > #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> >
> > /*
> > + * Intel color control surface (CCS) for render compression
> > + *
> > + * The framebuffer format must be one of the 8:8:8:8 RGB formats,
> > + * the main surface will be plane index 0 and will be Y/Yf-tiled,
> > + * the CCS will be plane index 1.
> > + *
>
> The paragraph below is...
>
> > + * Each byte of CCS contains 4 pairs of bits, with each pair of bits
> > + * matching an area of 8x4 pixels of the main surface. Which would seem
> > + * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
> > + * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
> > + * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
> > + * ---
> > + * | 01 | 23 |
> > + * --
> > + * | 45 | 67 |
> > + * ---
>
> ...almost correct. The hw docs state that each bit-pair of the CCS maps
> cacheline-pair, horizontally adjacent in the Y tile, of the primary surface.
> As
> a consequence, the remainder of the above paragraph is correct for 32-bit
> formats, but not others.
Which is why the comment says at the very top that the fb needs to
use a 8:8:8:8 format. IIRC that's the only thing the hardware supports.
>
> This is not a nitpick, because Vulkan and EGL users may want to share
> dma_bufs with a fat format like R32G32B32A32_UNORM, and want to have CCS
> enabled when possible. As long as the users use the dma_buf only the 3D
> engine, and don't submit it to KMS, it's all safe.
>
> For those users, we should document the bit-pair/cacheline-pair relationship
> correctly. And then preface the following detailed explanation and nice ascii
> diagrams by saying "this applies only to the 32-bit formats".
>
> Here's the relevant PRM quote:
>
> The Color Control Surface (CCS) contains the compression status
> of the cache-line pairs. The compression state of the cache-line
> pair is specified by 2 bits in the CCS. Each CCS cache-line
> represents an area on the main surface of 16x16 sets of 128 byte
> Y-tiled cache-line-pairs. CCS is always Y tiled.
>
> See this Mesa comment for more details:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/isl/isl.c?h=17.0#n211
>
> > + * Actually only the lower bit of the pair seems to have any effect.
> > + * No idea why. 0 in the lower bit would seem to mean not compressed,
> > + * and 1 is compressed. The interpreation of the main surface data
> > + * when the block is marked compressed is unknown as of now.
>
> If I recall correctly (it's been several months since I inspected the
> bits), the high bit is actually significant. Bit pattern 11 means that
> the data in primary surface's cacheline-pair is invalid; the 3D engine
> interprets the color of all pixels in that cacheline-pair to be the
> clear color stored in RENDER_SURFACE_STATE. Before the display engine
> can consume the surface, userspace is required to do a partial resolve,
> flushing the clear color into the primary surface. So it makes sense
> that the kernel would never observe that bit pattern in an incoming ccs
> surfac
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915: Start splitting out i915_gem_object routines
== Series Details == Series: series starting with [1/3] drm/i915: Start splitting out i915_gem_object routines URL : https://patchwork.freedesktop.org/series/20312/ State : warning == Summary == Series 20312v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20312/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-connector-state: pass -> SKIP (fi-ivb-3520m) Subgroup force-edid: pass -> SKIP (fi-ivb-3520m) Subgroup force-load-detect: pass -> SKIP (fi-ivb-3520m) Subgroup prune-stale-modes: pass -> SKIP (fi-ivb-3520m) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:256 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s UTC integration manifest 2f0647e drm/i915: Exercise backing storage of mock gem objects b8842c2 drm/i915: Start splitting out i915_gem_object routines == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3983/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] drm/i915/guc: Simplify intel_guc_init_hw()
On Fri, Feb 24, 2017 at 06:26:10PM +0100, Michal Wajdeczko wrote:
> On Fri, Feb 24, 2017 at 04:40:01PM +0100, Arkadiusz Hiler wrote:
> > Current version of intel_guc_init_hw() does a lot:
> > - cares about submission
> > - loads huc
> > - implement WA
> >
> > This change offloads some of the logic to intel_uc_init_hw(), which now
> > cares about the above.
> >
> > v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
> > v3: rename once again
> > v4: remove spurious comments and add some style (J. Lahtinen)
> >
> > Cc: Anusha Srivatsa
> > Cc: Michal Winiarski
> > Cc: Michal Wajdeczko
> > Cc: Daniele Ceraolo Spurio
> > Cc: Joonas Lahtinen
> > Signed-off-by: Arkadiusz Hiler
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 2 +-
> > drivers/gpu/drm/i915/intel_guc_loader.c | 144
> >
> > drivers/gpu/drm/i915/intel_uc.c | 110
> > drivers/gpu/drm/i915/intel_uc.h | 3 +
> > 4 files changed, 128 insertions(+), 131 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 5b36524..8943c4e 100644
> > @@ -443,42 +425,24 @@ int intel_guc_init_hw(struct drm_i915_private
> > *dev_priv)
> > {
>
> > - /* Loading forbidden, or no firmware to load? */
> > - if (!i915.enable_guc_loading) {
> > - err = 0;
> > - goto fail;
> > - } else if (fw_path == NULL) {
> > - /* Device is known to have no uCode (e.g. no GuC) */
> > - err = -ENXIO;
> > - goto fail;
> > + if (!fw_path) {
> > + return -ENXIO;
> > } else if (*fw_path == '\0') {
>
> Hmm, is this case still possible?
In this revision - yes, but unlikely.
HAS_GUC() is true but firmware for the device is not known (see
init_fw()). I think that the initial flow was designed in this case in
mind.
> > - /* Device has a GuC but we don't know what f/w to load? */
> > WARN(1, "No GuC firmware known for this platform!\n");
> > - err = -ENODEV;
> > - goto fail;
> > + return -ENODEV;
> > }
> >
> > - /* Fetch failed, or already fetched but failed to load? */
> > - if (guc_fw->fetch_status != INTEL_UC_FIRMWARE_SUCCESS) {
> > - err = -EIO;
> > - goto fail;
> > - } else if (guc_fw->load_status == INTEL_UC_FIRMWARE_FAIL) {
> > - err = -ENOEXEC;
> > - goto fail;
> > - }
> > -
> > - guc_interrupts_release(dev_priv);
> > - gen9_reset_guc_interrupts(dev_priv);
> > -
> > - /* We need to notify the guc whenever we change the GGTT */
> > - i915_ggtt_enable_guc(dev_priv);
> > + if (guc_fw->fetch_status != INTEL_UC_FIRMWARE_SUCCESS)
> > + return -EIO;
> > + else if (guc_fw->load_status == INTEL_UC_FIRMWARE_FAIL)
> > + return -ENOEXEC;
>
> Hmm, it looks like you're checking for load failure here, but actual
> load is about to start below ? Did I missed something ?
The status FIRMWARE_FAIL is not used at all in the GuC path (HuC) uses
it. Noted down to give it a closer look.
The check is gone, as it does not make sense, thanks.
> > guc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
>
> I guess this status can be set in guc_ucode_xfer() as it uses guc_fw object.
> >
> > @@ -486,104 +450,24 @@ int intel_guc_init_hw(struct drm_i915_private
> > *dev_priv)
> > intel_uc_fw_status_repr(guc_fw->fetch_status),
> > intel_uc_fw_status_repr(guc_fw->load_status));
> >
> > - err = i915_guc_submission_init(dev_priv);
> > - if (err)
> > - goto fail;
> > -
> > /*
> > * WaEnableuKernelHeaderValidFix:skl,bxt
> > * For BXT, this is only upto B0 but below WA is required for later
> > * steppings also so this is extended as well.
> > */
>
> Rebase issue?
Yeah. I've streamlined the whole thing to be:
--
int attempts;
const int guc_wa_hash_check_not_set_attempts = 3;
/* WaEnableuKernelHeaderValidFix:skl */
/* WaEnableGuCBootHashCheckNotSet:skl,bxt,kbl */
if (IS_GEN9(dev_priv))
attempts = guc_wa_hash_check_not_set_attempts;
else
attempts = 1;
while (attempts--) ...
--
and dropped the WA comments in the guc_init_hw()
> > +int intel_uc_init_hw(struct drm_i915_private *dev_priv)
> > +{
>
> > +fail:
> > + /*
> > +* We've failed to load the firmware :(
> > +*
> > +* Decide whether to disable GuC submission and fall back to
> > +* execlist mode, and whether to hide the error by returning
> > +* zero or to return -EIO, which the caller will treat as a
> > +* nonfatal error (i.e. it doesn't prevent driver load, but
> > +* marks the GPU as wedged until reset).
> > +*/
> > + DRM_ERROR("GuC init failed\n");
> > + if (i915.enable_guc_loading > 1 || i915.enable_guc_submission > 1)
>
> Nonzero i915.enable_guc_load
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, drm-misc-next-fixes-2017-02-27: Misc fixes for the 4.11 merge window. - vmwgfx drm_control node compat patch - rockchip&zte fixes - compat32 support for dma-buf ioctl (cc: stable ofc, since this is a massive fumble. oops) Nothing major outstanding afaik. Cheers, Daniel The following changes since commit 2220fc1ab363e6fab1f321430d69be17a8b92bd7: uapi: add missing install of dma-buf.h (2017-02-14 22:45:16 +0100) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-02-27 for you to fetch changes up to 888022c0473d079bff9b47fb50434b1f20f8f37f: dma-buf: add support for compat ioctl (2017-02-27 17:23:47 +0530) Misc fixes for the 4.11 merge window. - vmwgfx drm_control node compat patch - rockchip&zte fix - compat32 support for dma-buf ioctl (cc: stable ofc, since this is a massive fumble. oops) Arnd Bergmann (1): drm/rockchip: add extcon dependency for DP Christophe JAILLET (1): drm/rockchip: cdn-dp: Fix error handling Marek Szyprowski (1): dma-buf: add support for compat ioctl Shawn Guo (1): drm: zte: fix static checker warning on variable 'fmt' Thomas Hellstrom (1): drm/vmwgfx: Work around drm removal of control nodes drivers/dma-buf/dma-buf.c | 3 +++ drivers/gpu/drm/rockchip/Kconfig | 1 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +++- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 11 ++- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 ++-- drivers/gpu/drm/zte/zx_plane.c | 4 ++-- 6 files changed, 21 insertions(+), 6 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate on switching contexts
== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate on switching contexts URL : https://patchwork.freedesktop.org/series/20313/ State : success == Summary == Series 20313v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20313/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s UTC integration manifest 4106ba6 drm/i915: Reduce context alignment fc2a90b drm/i915: Remove redundant TLB invalidate on switching ppgtt a2956c8 drm/i915: Remove redundant TLB invalidate on switching contexts == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3984/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate on switching contexts
On Mon, Feb 27, 2017 at 03:52:12PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB > invalidate on switching contexts > URL : https://patchwork.freedesktop.org/series/20313/ > State : success > > == Summary == > > Series 20313v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/20313/revisions/1/mbox/ > > fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 > fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 > fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 > fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 > fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 > fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 > fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 > fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 > > f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s > UTC integration manifest > 4106ba6 drm/i915: Reduce context alignment > fc2a90b drm/i915: Remove redundant TLB invalidate on switching ppgtt > a2956c8 drm/i915: Remove redundant TLB invalidate on switching contexts Thanks for the review on these 3, pushed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level
On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > Handle debugfs override edid and firmware edid at the low level to
> > > transparently and completely replace the real edid. Previously, we
> > > practically only used the modes from the override EDID, and none of the
> > > other data. This also prevents actual EDID reads when the EDID is to be
> > > overridden, but retains the DDC probe.
> > >
> > > Move firmware EDID loading from helper to core, as the functionality
> > > moves to lower level as well. This will result in a change of module
> > > parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
> > > arguably makes more sense anyway.
> > >
> > > FIXME: validate override edid, deduplicate firmware edid validation.
> > >
> > > v2: move firmware loading to core
> > >
> > > Signed-off-by: Jani Nikula
> > > ---
> > > drivers/gpu/drm/Kconfig| 2 +-
> > > drivers/gpu/drm/Makefile | 2 +-
> > > drivers/gpu/drm/drm_edid.c | 15 +++
> > > drivers/gpu/drm/drm_probe_helper.c | 19 +--
> > > 4 files changed, 18 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index 90bc65d07a35..f983ef60299c 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
> > >
> > > config DRM_LOAD_EDID_FIRMWARE
> > > bool "Allow to specify an EDID data set instead of probing for it"
> > > - depends on DRM_KMS_HELPER
> > > + depends on DRM
> > > help
> > > Say Y here, if you want to use EDID data to be loaded from the
> > > /lib/firmware directory or one of the provided built-in
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 92de3991fa56..a10ac095608f 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> > > drm-$(CONFIG_OF) += drm_of.o
> > > drm-$(CONFIG_AGP) += drm_agpsupport.o
> > > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > > +drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > >
> > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
> > > \
> > > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > > drm_simple_kms_helper.o drm_modeset_helper.o
> > >
> > > -drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> > > drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index e1743ab276dc..4007998d5ce3 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct
> > > drm_connector *connector,
> > > * level, drivers must make all reasonable efforts to expose it as an I2C
> > > * adapter and use drm_get_edid() instead of abusing this function.
> > > *
> > > + * The EDID may be overridden using debugfs override_edid or firmare EDID
> > > + * (drm_load_edid_firmware()), in this priority order. Having either of
> > > them
> > > + * bypasses actual EDID reads.
> > > + *
> > > * Return: Pointer to valid EDID or NULL if we couldn't find any.
> > > */
> > > struct edid *drm_do_get_edid(struct drm_connector *connector,
> > > @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector
> > > *connector,
> > > {
> > > int i, j = 0, valid_extensions = 0;
> > > u8 *edid, *new;
> > > + struct edid *override = NULL;
> > > +
> > > + if (connector->override_edid)
> > > + override = drm_edid_duplicate((const struct edid *)
> > > + connector->edid_blob_ptr->data);
> > > +
> > > + if (!override)
> > > + override = drm_load_edid_firmware(connector);
> > > +
> > > + if (!IS_ERR_OR_NULL(override))
> > > + return override;
> > >
> > > if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > > return NULL;
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 358957118ca9..871326cbc465 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector,
> > > bool force)
> > > *drm_mode_probed_add(). New modes start their life with status as
> > > OK.
> > > *Modes are added from a single source using the following priority
> > > order.
> > > *
> > > - *- debugfs 'ov
Re: [Intel-gfx] [PATCH] drm/i915: Distinguish between timeout and error in sideband transactions
On Thu, 23 Feb 2017, Chris Wilson wrote:
> After initiating a sideband transaction, we only want to wait for the
> transaction to become idle. If, as we are, we wait for both the busy
> and error flag to clear, if an error is raised we just spin until the
> timeout. Once the hw is idle, we can then check to see if the hw flagged
> an error, and report it distinctly.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Much better indeed.
Reviewed-by: Jani Nikula
(The pedantic nitpick is that response status is really two bits, and
you could read them both and fail if they're not zero. But meh.)
> ---
> drivers/gpu/drm/i915/intel_sideband.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 9f782b5eb6e6..41712ea9f5f8 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -216,6 +216,7 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16
> reg,
> }
>
> I915_WRITE(SBI_ADDR, (reg << 16));
> + I915_WRITE(SBI_DATA, 0);
>
> if (destination == SBI_ICLK)
> value = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRRD;
> @@ -225,10 +226,15 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv,
> u16 reg,
>
> if (intel_wait_for_register(dev_priv,
> SBI_CTL_STAT,
> - SBI_BUSY | SBI_RESPONSE_FAIL,
> + SBI_BUSY,
> 0,
> 100)) {
> - DRM_ERROR("timeout waiting for SBI to complete read
> transaction\n");
> + DRM_ERROR("timeout waiting for SBI to complete read\n");
> + return 0;
> +
> + }
> + if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
> + DRM_ERROR("error during SBI read of reg %x\n", reg);
> return 0;
> }
>
> @@ -260,10 +266,16 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
> u16 reg, u32 value,
>
> if (intel_wait_for_register(dev_priv,
> SBI_CTL_STAT,
> - SBI_BUSY | SBI_RESPONSE_FAIL,
> + SBI_BUSY,
> 0,
> 100)) {
> - DRM_ERROR("timeout waiting for SBI to complete write
> transaction\n");
> + DRM_ERROR("timeout waiting for SBI to complete write\n");
> + return;
> + }
> +
> + if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
> + DRM_ERROR("error during SBI write of %x to reg %x\n",
> + value, reg);
> return;
> }
> }
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level
On Mon, Feb 27, 2017 at 05:19:21PM +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> > On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > > Handle debugfs override edid and firmware edid at the low level to
> > > > transparently and completely replace the real edid. Previously, we
> > > > practically only used the modes from the override EDID, and none of the
> > > > other data. This also prevents actual EDID reads when the EDID is to be
> > > > overridden, but retains the DDC probe.
> > > >
> > > > Move firmware EDID loading from helper to core, as the functionality
> > > > moves to lower level as well. This will result in a change of module
> > > > parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
> > > > arguably makes more sense anyway.
> > > >
> > > > FIXME: validate override edid, deduplicate firmware edid validation.
> > > >
> > > > v2: move firmware loading to core
> > > >
> > > > Signed-off-by: Jani Nikula
> > > > ---
> > > > drivers/gpu/drm/Kconfig| 2 +-
> > > > drivers/gpu/drm/Makefile | 2 +-
> > > > drivers/gpu/drm/drm_edid.c | 15 +++
> > > > drivers/gpu/drm/drm_probe_helper.c | 19 +--
> > > > 4 files changed, 18 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > > index 90bc65d07a35..f983ef60299c 100644
> > > > --- a/drivers/gpu/drm/Kconfig
> > > > +++ b/drivers/gpu/drm/Kconfig
> > > > @@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
> > > >
> > > > config DRM_LOAD_EDID_FIRMWARE
> > > > bool "Allow to specify an EDID data set instead of probing for
> > > > it"
> > > > - depends on DRM_KMS_HELPER
> > > > + depends on DRM
> > > > help
> > > > Say Y here, if you want to use EDID data to be loaded from the
> > > > /lib/firmware directory or one of the provided built-in
> > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > index 92de3991fa56..a10ac095608f 100644
> > > > --- a/drivers/gpu/drm/Makefile
> > > > +++ b/drivers/gpu/drm/Makefile
> > > > @@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> > > > drm-$(CONFIG_OF) += drm_of.o
> > > > drm-$(CONFIG_AGP) += drm_agpsupport.o
> > > > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > > > +drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > > >
> > > > drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> > > > drm_probe_helper.o \
> > > > drm_plane_helper.o drm_dp_mst_topology.o
> > > > drm_atomic_helper.o \
> > > > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > > > drm_simple_kms_helper.o drm_modeset_helper.o
> > > >
> > > > -drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > > > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > > > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> > > > drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index e1743ab276dc..4007998d5ce3 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct
> > > > drm_connector *connector,
> > > > * level, drivers must make all reasonable efforts to expose it as an
> > > > I2C
> > > > * adapter and use drm_get_edid() instead of abusing this function.
> > > > *
> > > > + * The EDID may be overridden using debugfs override_edid or firmare
> > > > EDID
> > > > + * (drm_load_edid_firmware()), in this priority order. Having either
> > > > of them
> > > > + * bypasses actual EDID reads.
> > > > + *
> > > > * Return: Pointer to valid EDID or NULL if we couldn't find any.
> > > > */
> > > > struct edid *drm_do_get_edid(struct drm_connector *connector,
> > > > @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct
> > > > drm_connector *connector,
> > > > {
> > > > int i, j = 0, valid_extensions = 0;
> > > > u8 *edid, *new;
> > > > + struct edid *override = NULL;
> > > > +
> > > > + if (connector->override_edid)
> > > > + override = drm_edid_duplicate((const struct edid *)
> > > > +
> > > > connector->edid_blob_ptr->data);
> > > > +
> > > > + if (!override)
> > > > + override = drm_load_edid_firmware(connector);
> > > > +
> > > > + if (!IS_ERR_OR_NULL(override))
> > > > + return override;
> > > >
> > > > if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > > > return NULL;
> > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > > b/drivers/gpu/drm/drm_probe_helper.c
> > > > index 358957118ca9..8
Re: [Intel-gfx] [PATCH resend 07/15] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON
On Sat, 25 Feb 2017 11:35:03 +0100 Hans de Goede wrote: > Hi, > > On 24-02-17 18:00, Bob Paauwe wrote: > > On Mon, 20 Feb 2017 15:08:37 +0100 > > Hans de Goede wrote: > > > >> MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons: > >> 1) The reset should already be asserted before intel_dsi_pre_enable() > >>gets called > >> 2) Most (some?) VBTs will ensure reset was asserted in their > >>MIPI_SEQ_DEASSERT_RESET themselves > >> > >> Signed-off-by: Hans de Goede > > > > Using words like "should" and some? don't inspire a lot of confidence > > that this is the right thing to do. Is there some way to verify that > > these two conditions are true? > > Well the i915 code should never call intel_dsi_[pre_]enable without > first having called intel_dsi_post_disable() which does: > > intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); > > Already, also this is undoing a recent (4.9 kernel IIRC) change, > before that the i915 did not call the MIPI_SEQ_ASSERT_RESET > sequence from the enable path. Also doing this is against the VBT > spec. > > Regards, > > Hans > So let's try to make the commit message state that. Using what you just wrote maybe something like: intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET, will always be called at some point before intel_dsi_pre_enable() making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundent. In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes against the VBT spec. With the commit message updated the change looks to be correct. > > > > > >> --- > >> drivers/gpu/drm/i915/intel_dsi.c | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c > >> b/drivers/gpu/drm/i915/intel_dsi.c > >> index 78d5884..4ebf308 100644 > >> --- a/drivers/gpu/drm/i915/intel_dsi.c > >> +++ b/drivers/gpu/drm/i915/intel_dsi.c > >> @@ -669,7 +669,6 @@ static void intel_dsi_pre_enable(struct intel_encoder > >> *encoder, > >>/* put device in ready state */ > >>intel_dsi_device_ready(encoder); > >> > >> - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); > >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); > >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); > >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); > > > > > > -- -- Bob Paauwe bob.j.paa...@intel.com IOTG / PED Software Organization Intel Corp. Folsom, CA (916) 356-6193 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight
On Sat, 25 Feb 2017 11:37:50 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:00, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:41 +0100
> > Hans de Goede wrote:
> >
> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
> >> we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
> >>
> >> Signed-off-by: Hans de Goede
> >
> > I'm not sure that the added comments are necessary. Maybe if there was
> > some explanation for why we're using two different mechanisms to
> > enable/disable backlight instead.
>
> That assumes I know why there are 2 mechanisms of I have to guess it
> is because on some boards only one of the mechanisms works, but that
> is just a guess. Just calling the VBT sequence should be enough on
> (most?) boards.
>
> Regards,
>
> Hans
I don't think I can describe why we have two mechanisms so just
dropping the comment would be my preference at this point.
It may be that calling the intel_panel_enable_backlight() will make
sure the sysfs entries are correct while the VBT sequence simply
modifies the hardware.
Possibly a good solution would be to enhance the code that executes the
VBT sequence to also call the intel_panel_enable_backlight(), but
that's not something to change here.
>
>
> >
> > Reviewed-by: Bob Paauwe
> >
> >> ---
> >> drivers/gpu/drm/i915/intel_dsi.c | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index 8408f59..a8d0948 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -687,12 +687,13 @@ static void intel_dsi_pre_enable(struct
> >> intel_encoder *encoder,
> >>msleep(100);
> >>
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> >> - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
> >>
> >>intel_dsi_port_enable(encoder);
> >>}
> >>
> >> + /* Enable backlight, both pwm and VBT */
> >>intel_panel_enable_backlight() (intel_dsi->attached_connector);
> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
> >> }
> >>
> >> static void intel_dsi_enable_nop(struct intel_encoder *encoder,
> >> @@ -718,6 +719,8 @@ static void intel_dsi_pre_disable(struct intel_encoder
> >> *encoder,
> >>
> >>DRM_DEBUG_KMS("\n");
> >>
> >> + /* Disable backlight, both VBT and pwm */
> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
> >>intel_panel_disable_backlight(intel_dsi->attached_connector);
> >>
> >>/*
> >> @@ -762,7 +765,6 @@ static void intel_dsi_post_disable(struct
> >> intel_encoder *encoder,
> >> * if disable packets are sent before sending shutdown packet then in
> >> * some next enable sequence send turn on packet error is observed
> >> */
> >> - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
> >>
> >>/* Transition to LP-00 */
> >
> >
> >
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH resend 12/15] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order
On Sat, 25 Feb 2017 11:42:09 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:42 +0100
> > Hans de Goede wrote:
> >
> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
> >> before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
> >> first.
> >>
> >> Since the v2 order has known issues, we use the v3 order everywhere,
> >> add a comment documenting this.
> >>
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/intel_dsi.c | 7 +++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index a8d0948..1914311 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -732,6 +732,11 @@ static void intel_dsi_pre_disable(struct
> >> intel_encoder *encoder,
> >>I915_WRITE(MIPI_DEVICE_READY(port), 0);
> >>}
> >>
> >> + /*
> >> + * XXX: According to the spec we should send SHUTDOWN before
> >> + * MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but testing in the field
> >> + * has shown that we should do this for v2 VBTs too?
> > drop the '?'
>
> I added that because I'm not 100% sure this is true, looking through git
> history (and android x86 kernel patch-sets) I managed to piece together that
> at one point in time the v2 sequence was used, but that yielded problems
> during some testing, what the commits do not tell if is that testing was
> using boards with v3 VBTs, but assuming v2 tables are out there in the
> wild then it seems that the v3 order works fine for v2 too.
>
> TLDR I'm not 100% sure about this hence the '?', my main goal with this
> patch is to document that we're deviating from the spec for v2 tables here.
If anyone else, Jani?, has more information about this, that would be
good to know.
I'd be OK with just stating that "field testing has shown that the v3
sequence works with v2 VBT's so just use that."
>
> >> + */
> >>if (is_vid_mode(intel_dsi)) {
> >>/* Send Shutdown command to the panel in LP mode */
> >>for_each_dsi_port(port, intel_dsi->ports)
> >> @@ -764,6 +769,8 @@ static void intel_dsi_post_disable(struct
> >> intel_encoder *encoder,
> >>/*
> >> * if disable packets are sent before sending shutdown packet then in
> >> * some next enable sequence send turn on packet error is observed
> >> + * XXX spec specifies SHUTDOWN before MIPI_SEQ_DISPLAY_OFF for
> >> + * v3 VBTs, but not for v2 VBTs?
> >> */
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
> >>
> >
> > Should XXX be replaced with something?
>
> XXX is used in many places in intel_dsi.c to indicate code which may need
> work / which may needs to be investigated further. I followed that and
> added XXX here since this code is deviating from the spec.
>
> Regards,
>
> Hans
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail
== Series Details == Series: series starting with [1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail URL : https://patchwork.freedesktop.org/series/20314/ State : success == Summary == Series 20314v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20314/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 4113d7e37104478a568ef924afe9b45db11587e6 drm-tip: 2017y-02m-27d-16h-28m-48s UTC integration manifest 444e23e drm/i915: Defer unmasking RPS interrupts until after making adjustments ecacd5c drm/i915: Stop using RP_DOWN_EI on Baytrail == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3986/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH resend 15/15] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode
On Sat, 25 Feb 2017 11:49:09 +0100
Hans de Goede wrote:
> HI,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:45 +0100
> > Hans de Goede wrote:
> >
> >> For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
> >> we should not also delay ourselves otherwise we get double delays.
> >>
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/intel_dsi.c | 19 +++
> >> 1 file changed, 15 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index a001e43..9e858c7 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -552,6 +552,17 @@ static void intel_dsi_prepare(struct intel_encoder
> >> *intel_encoder,
> >> struct intel_crtc_state *pipe_config);
> >> static void intel_dsi_unprepare(struct intel_encoder *encoder);
> >>
> >> +static void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec)
> >> +{
> >> + struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
> >> +
> >> + /* For v3 VBTs in vid-mode the delays are part of the VBT sequences */
> >> + if (is_vid_mode(intel_dsi) && dev_priv->vbt.dsi.seq_version >= 3)
> >> + return;
> >> +
> >> + msleep(msec);
> >> +}
> >> +
> >> /*
> >> * Panel enable/disable sequences from the VBT spec.
> >> *
> >> @@ -664,7 +675,7 @@ static void intel_dsi_pre_enable(struct intel_encoder
> >> *encoder,
> >>if (intel_dsi->gpio_panel)
> >>gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> >> - msleep(intel_dsi->panel_on_delay);
> >> + intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
> >>
> >>/* Deassert reset */
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> >> @@ -686,7 +697,7 @@ static void intel_dsi_pre_enable(struct intel_encoder
> >> *encoder,
> >>msleep(20); /* XXX */
> >>for_each_dsi_port(port, intel_dsi->ports)
> >>dpi_send_cmd(intel_dsi, TURN_ON, false, port);
> >> - msleep(100);
> >> + intel_dsi_msleep(intel_dsi, 100);
> >>
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> >>
> >> @@ -805,7 +816,7 @@ static void intel_dsi_post_disable(struct
> >> intel_encoder *encoder,
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
> >>
> >>/* Power off, try both CRC pmic gpio and VBT */
> >> - msleep(intel_dsi->panel_off_delay);
> >> + intel_dsi_msleep(intel_dsi, intel_dsi->panel_off_delay);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
> >>if (intel_dsi->gpio_panel)
> >>gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
> >> @@ -814,7 +825,7 @@ static void intel_dsi_post_disable(struct
> >> intel_encoder *encoder,
> >> * FIXME As we do with eDP, just make a note of the time here
> >> * and perform the wait before the next panel power on.
> >> */
> >
> > Should this comment be updated now?
>
> It is still valid for non-vidmode and v2 VBT panels, so I think it can
> be left as is.
>
> Regards,
>
> Hans
OK, that makes sense.
>
>
> >
> > Otherwise
> > Reviewed-by: Bob Paauwe
> >
> >> - msleep(intel_dsi->panel_pwr_cycle_delay);
> >> + intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> >> }
> >>
> >> static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
> >
> >
> >
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Distinguish between timeout and error in sideband transactions
On Mon, Feb 27, 2017 at 06:34:26PM +0200, Jani Nikula wrote: > On Thu, 23 Feb 2017, Chris Wilson wrote: > > After initiating a sideband transaction, we only want to wait for the > > transaction to become idle. If, as we are, we wait for both the busy > > and error flag to clear, if an error is raised we just spin until the > > timeout. Once the hw is idle, we can then check to see if the hw flagged > > an error, and report it distinctly. > > > > Signed-off-by: Chris Wilson > > Cc: Jani Nikula > > Much better indeed. > > Reviewed-by: Jani Nikula > > (The pedantic nitpick is that response status is really two bits, and > you could read them both and fail if they're not zero. But meh.) First goal is just figuring out what the warnings mean on the gvtg machines. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH resend 14/15] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)
On Sat, 25 Feb 2017 11:47:32 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:44 +0100
> > Hans de Goede wrote:
> >
> >> According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
> >> on enable for cmd-mode, just like we already call their counterparts
> >> on disable. Note: untested, my panel is a vid-mode panel.
> >>
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/intel_dsi.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index 90263d6..a001e43 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -680,6 +680,8 @@ static void intel_dsi_pre_enable(struct intel_encoder
> >> *encoder,
> >>if (is_cmd_mode(intel_dsi)) {
> >>for_each_dsi_port(port, intel_dsi->ports)
> >>I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(port), 8 * 4);
> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_ON);
> >
> > As with the TEAR_OFF, should this only be done for command mode? Or is
> > it just a no-op for video mode and doesn't matter?
>
> In this case we are actually in a "if (is_cmd_mode(intel_dsi)) {" code
> block (the if is visible in the diff context).
>
> Which I guess also shows that we really need to add the guard to the
> other path, so as to be consistent.
>
> Note as mentioned in the commit msg:
>
> untested, my panel is a vid-mode panel.
Oops, sorry. I think there's another block of code somewhere that
looks almost like this but was wrapped in an if (is_vid_mode) condition
and I confused the two.
So disregard my comment and add:
Reviewed-by: Bob Paauwe
>
> >
> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> >>} else {
> >>msleep(20); /* XXX */
> >>for_each_dsi_port(port, intel_dsi->ports)
> >
> >
> >
>
> Regards,
>
> Hans
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight
On Mon, 27 Feb 2017, Bob Paauwe wrote:
> On Sat, 25 Feb 2017 11:37:50 +0100
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 24-02-17 18:00, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:41 +0100
>> > Hans de Goede wrote:
>> >
>> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
>> >> we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
>> >>
>> >> Signed-off-by: Hans de Goede
>> >
>> > I'm not sure that the added comments are necessary. Maybe if there was
>> > some explanation for why we're using two different mechanisms to
>> > enable/disable backlight instead.
>>
>> That assumes I know why there are 2 mechanisms of I have to guess it
>> is because on some boards only one of the mechanisms works, but that
>> is just a guess. Just calling the VBT sequence should be enough on
>> (most?) boards.
>>
>> Regards,
>>
>> Hans
>
> I don't think I can describe why we have two mechanisms so just
> dropping the comment would be my preference at this point.
I think they're mostly alternatives, and only one or the other gets
used, but since the VBT sequence is rather generic, I think it's
possible one controls the SoC side and the other the panel side.
> It may be that calling the intel_panel_enable_backlight() will make
> sure the sysfs entries are correct while the VBT sequence simply
> modifies the hardware.
>
> Possibly a good solution would be to enhance the code that executes the
> VBT sequence to also call the intel_panel_enable_backlight(), but
> that's not something to change here.
Please leave it as it is.
BR,
Jani.
>
>>
>>
>> >
>> > Reviewed-by: Bob Paauwe
>> >
>> >> ---
>> >> drivers/gpu/drm/i915/intel_dsi.c | 6 --
>> >> 1 file changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>> >> b/drivers/gpu/drm/i915/intel_dsi.c
>> >> index 8408f59..a8d0948 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> >> @@ -687,12 +687,13 @@ static void intel_dsi_pre_enable(struct
>> >> intel_encoder *encoder,
>> >> msleep(100);
>> >>
>> >> intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
>> >> - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>> >>
>> >> intel_dsi_port_enable(encoder);
>> >> }
>> >>
>> >> + /* Enable backlight, both pwm and VBT */
>> >> intel_panel_enable_backlight() (intel_dsi->attached_connector);
>> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>> >> }
>> >>
>> >> static void intel_dsi_enable_nop(struct intel_encoder *encoder,
>> >> @@ -718,6 +719,8 @@ static void intel_dsi_pre_disable(struct
>> >> intel_encoder *encoder,
>> >>
>> >> DRM_DEBUG_KMS("\n");
>> >>
>> >> + /* Disable backlight, both VBT and pwm */
>> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>> >> intel_panel_disable_backlight(intel_dsi->attached_connector);
>> >>
>> >> /*
>> >> @@ -762,7 +765,6 @@ static void intel_dsi_post_disable(struct
>> >> intel_encoder *encoder,
>> >>* if disable packets are sent before sending shutdown packet then in
>> >>* some next enable sequence send turn on packet error is observed
>> >>*/
>> >> - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>> >> intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>> >>
>> >> /* Transition to LP-00 */
>> >
>> >
>> >
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH resend 12/15] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order
On Mon, 27 Feb 2017, Bob Paauwe wrote:
> On Sat, 25 Feb 2017 11:42:09 +0100
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 24-02-17 18:02, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:42 +0100
>> > Hans de Goede wrote:
>> >
>> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
>> >> before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
>> >> first.
>> >>
>> >> Since the v2 order has known issues, we use the v3 order everywhere,
>> >> add a comment documenting this.
>> >>
>> >> Signed-off-by: Hans de Goede
>> >> ---
>> >> drivers/gpu/drm/i915/intel_dsi.c | 7 +++
>> >> 1 file changed, 7 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>> >> b/drivers/gpu/drm/i915/intel_dsi.c
>> >> index a8d0948..1914311 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> >> @@ -732,6 +732,11 @@ static void intel_dsi_pre_disable(struct
>> >> intel_encoder *encoder,
>> >> I915_WRITE(MIPI_DEVICE_READY(port), 0);
>> >> }
>> >>
>> >> + /*
>> >> + * XXX: According to the spec we should send SHUTDOWN before
>> >> + * MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but testing in the field
>> >> + * has shown that we should do this for v2 VBTs too?
>> > drop the '?'
>>
>> I added that because I'm not 100% sure this is true, looking through git
>> history (and android x86 kernel patch-sets) I managed to piece together that
>> at one point in time the v2 sequence was used, but that yielded problems
>> during some testing, what the commits do not tell if is that testing was
>> using boards with v3 VBTs, but assuming v2 tables are out there in the
>> wild then it seems that the v3 order works fine for v2 too.
>>
>> TLDR I'm not 100% sure about this hence the '?', my main goal with this
>> patch is to document that we're deviating from the spec for v2 tables here.
>
> If anyone else, Jani?, has more information about this, that would be
> good to know.
I wish. The documentation on this is disgraceful.
> I'd be OK with just stating that "field testing has shown that the v3
> sequence works with v2 VBT's so just use that."
Ack.
>
>>
>> >> + */
>> >> if (is_vid_mode(intel_dsi)) {
>> >> /* Send Shutdown command to the panel in LP mode */
>> >> for_each_dsi_port(port, intel_dsi->ports)
>> >> @@ -764,6 +769,8 @@ static void intel_dsi_post_disable(struct
>> >> intel_encoder *encoder,
>> >> /*
>> >>* if disable packets are sent before sending shutdown packet then in
>> >>* some next enable sequence send turn on packet error is observed
>> >> + * XXX spec specifies SHUTDOWN before MIPI_SEQ_DISPLAY_OFF for
>> >> + * v3 VBTs, but not for v2 VBTs?
>> >>*/
>> >> intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>> >>
>> >
>> > Should XXX be replaced with something?
>>
>> XXX is used in many places in intel_dsi.c to indicate code which may need
>> work / which may needs to be investigated further. I followed that and
>> added XXX here since this code is deviating from the spec.
>>
>> Regards,
>>
>> Hans
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH resend 13/15] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable
On Sat, 25 Feb 2017, Hans de Goede wrote: > Hi, > > On 24-02-17 18:02, Bob Paauwe wrote: >> On Mon, 20 Feb 2017 15:08:43 +0100 >> Hans de Goede wrote: >> >>> For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before >>> MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop. >> >> Isn't this only for command mode? Or is there conflicting information >> on this? > > In my (limited) set of test hardware vidmode panel VBTs simply > do not define a MIPI_SEQ_TEAR_ON/OFF sequence. But it would probably > be a good idea to guard this with a "if (is_cmd_mode(intel_dsi))" > assuming we only want this for commandmode, which I think we do, > but it would be good to have this confirmed. Logically you wouldn't do tear on/off on video mode panels. But that's really not the point. I wouldn't be surprised if there were setups where someone noticed that this particular sequence gets run at an appropriate time on Windows, and shoved some other stuff there, completely unrelated to tear on/off. BR, Jani. > > I'll add the guard when I send out a v2 after we've clarified > some of the other review questions. > > Regards, > > Hans > > > >> >>> >>> Signed-off-by: Hans de Goede >>> --- >>> drivers/gpu/drm/i915/intel_dsi.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c >>> b/drivers/gpu/drm/i915/intel_dsi.c >>> index 1914311..90263d6 100644 >>> --- a/drivers/gpu/drm/i915/intel_dsi.c >>> +++ b/drivers/gpu/drm/i915/intel_dsi.c >>> @@ -772,6 +772,7 @@ static void intel_dsi_post_disable(struct intel_encoder >>> *encoder, >>> * XXX spec specifies SHUTDOWN before MIPI_SEQ_DISPLAY_OFF for >>> * v3 VBTs, but not for v2 VBTs? >>> */ >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_OFF); >>> intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); >>> >>> /* Transition to LP-00 */ >> >> >> -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dsi: VLV/CHT Only wait for LP00 on MIPI PORT A
On Mon, 27 Feb 2017 11:22:32 +0100
Hans de Goede wrote:
> On some devices only MIPI PORT C is used, in this case checking the
> MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
> on VLV/CHT) will result in false positive "DSI LP not going Low" errors
> as this checks the PORT A clk status.
>
> In case both ports are used we have already checked the AFE_LATCHOUT
> bit when going through the for_each_dsi_port() loop for PORT A and
> checking the same bit again for PORT C is a no-op.
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97061
> Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 1fcce2c..185b8eb 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -458,10 +458,12 @@ static void intel_dsi_clear_device_ready(struct
> intel_encoder *encoder)
> ULPS_STATE_ENTER);
> usleep_range(2000, 2500);
>
> - /* Wait till Clock lanes are in LP-00 state for MIPI Port A
> - * only. MIPI Port C has no similar bit for checking
> + /*
> + * On VLV/CHV, wait till Clock lanes are in LP-00 state for MIPI
> + * Port A only. MIPI Port C has no similar bit for checking.
>*/
> - if (intel_wait_for_register(dev_priv,
> + if ((IS_GEN9_LP(dev_priv) || port == PORT_A) &&
> + intel_wait_for_register(dev_priv,
> port_ctrl, AFE_LATCHOUT, 0,
> 30))
> DRM_ERROR("DSI LP not going Low\n");
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
== Series Details == Series: drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058 URL : https://patchwork.freedesktop.org/series/19959/ State : success == Summary == Series 19959v1 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058 https://patchwork.freedesktop.org/api/1.0/series/19959/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-skl-6700k) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 ea59cd057f94642a3e16f1059fc518faae14e0a8 drm-tip: 2017y-02m-27d-17h-23m-21s UTC integration manifest 841b1a1 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058 == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3987/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state
On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote: > On Wed, Feb 22, 2017 at 12:01:12AM +, Pandiyan, Dhinakaran wrote: > > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: > > > > > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: > > > >> Comparing this func to > > > >> drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it > > > >> doesn't seem to call drm_modeset_lock if the obj_state doesn't already > > > >> exist. I > > > >> don't understand the locking stuff toowell, I just noticed this > > > >> difference when > > > >> comparing this approach with what is done in the msm kms driver (where > > > >> we > > > >> have subclassed drm_atomic_state to msm_kms_state). > > > >> > > > >> Thanks, > > > >> Archit > > > >> > > > > > > > > > > > > The caller is expected to take care of any required locking. The > > > > driver-private objects are opaque from core's pov, so the core is not > > > > aware of necessary locks for that object type. > > > > > > I had a look at the rest of the series, and I couldn't easily understand > > > whether the caller code protects the MST related driver private state. Is > > > it expected to be protect via the drm_mode_config.connection_mutex lock? > > > > > > Thanks, > > > Archit > > > > > > > That's right, the connection_mutex takes care of the locking for the MST > > private state. I can add that as a comment to the caller's (MST helper) > > kernel doc with a > > > > WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)); > > Please don't add this as a comment, but as real code so it is checked at > runtime :-) Personally I wouldn't mention locking rules in kernel-doc, > that part tends to get outdated fast. Better to enforce with > runtime-checks. > -Daniel That's what I meant but evidently didn't type it that way:) I was going to add that the connection_mutex does the locking for MST state as a comment and put the WARN_ON() in code. -DK ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
